This document was uploaded by user and they confirmed that they have the permission to share
it. If you are author or own the copyright of this book, please report to us by using this DMCA
report form. Report DMCA
Changes from the previous issue Major changes from the previous issue of this Guide are:
Alarms: New PDSD and MGTA alarms: see page 145 to page 156, and page 161.
Tables There were changes to the following tables: adm_client page 463 hlr_config page 471 pds_config page 523 pipc page 527 hlr_definitions page 493 (Note: this table has been renamed to pds_defs) voicemail page 560 ussd page 534
USSD Information There were changes to the USSD description in USSD Information on page 627
Using this Guide This guide describes the Linux version of the Home Location Register (HLR) in a GSM network. It is for network staff who manage and maintain the GSM HLR. If you want to...
You should see...
See a definition of an acronym or abbreviation.
Appendix N, Abbreviations on page 689.
Find out if this is the correct Document for the HLR system you are using.
Accessing the Administration Interface on page 176 and the VIEW:INFO command description on page 448. Also see Displaying Hardware/Software Versions on page 125.
Find out what changes have been made to this Guide since the previous issue.
Changes from the previous issue on page 1.
Get an overview of the HLR.
Chapter 1, Overview of the HLR.
Connect to an HLR node and use the HLR accounts.
Chapter 4, Support Interfaces.
Identify problems with the HLR.
Chapter 5, Identifying Problems.
Deal with alarms raised by the HLR.
Chapter 7, Alarms.
Correct problems on the HLR.
Chapter 6, Using Support Interfaces.
Use the Administration Interface.
Chapter 9, Administration Interface.
Use the Table Maintenance Interface.
Chapter 24, Table Maintenance.
Comment on this document.
the Reader’s Comments form at the back of the Guide and return it to the address given.
Important Notes
Note that this Guide: • Describes the HLR configuration as shipped by Vodafone. It may be supplemented or even replaced by local documentation. • Provides advice on how to identify and fix common problems with the HLR. However, it cannot cover every circumstance that could affect the system. If this Guide does not describe a problem you encounter, check first with your local operating procedures before taking any other action.
2
Home Location Register (Linux) V1.1 Support Guide
xviii
Using this Guide
Levels of Support There are three levels of support - First, Second and Third. Higher levels of support require greater expertise, and run a higher risk of damage if unauthorised personnel access the platform, or support staff make mistakes. • First line support is the responsibility of the network operator, and typically provided using the Remote Engineer account, which grants limited access to the system. • Second and Third line support are provided by Vodafone in the United Kingdom, using the pds_manager account, which grants command-line access to the system. See The pds_manager Account on page 83 for details. Note: Some network operators provide their own Second-line support. Depending on the severity of the problem, you may need to escalate or report the problem to the next level of support.
Escalating and Reporting Problems If you cannot solve a problem using either the procedures in this Document or your local operating procedures you should pass it to the next line of support (see Levels of Support above). Either: • escalate the problem - pass it on immediately • report the problem - pass it on: - immediately, if it occurs during normal working hours. - at the start of the next working day, if it occurs out of normal working hours. Whether you escalate or report a problem depends on its severity. Escalate only those problems that have a serious impact on network operation or quality of service. Report all other problems. Whether you escalate or report a problem you should provide as much information as possible: • details of any relevant alarms • what you have done so far to investigate the problem • any other relevant information.
Home Location Register (Linux) V1.1 Support Guide
2
Using this Guide
xix
Alarm Reporting You should consult your local OMC documentation for more information on your alarm interface. Figure 44 on page 134 shows some of the alternatives for distributing alarms.
ISAAC This Guide assumes that you are using Vodafone’s International Subscriber Administration And Control system (ISAAC) to provide GSM Administration Centre (ADC) functionality in your network. If you are using a different ADC system, the subscriber administration interface may be different. See your local documentation for details.
2
Home Location Register (Linux) V1.1 Support Guide
xx
Using this Guide
Conventions Used in this Document The following type faces have special uses in this Guide: Typeface
Used For
variable
a variable which you should substitute with the required value.
system output
command, file and directory names, file contents, system prompts and responses.
0HQXWH[W
menu options, GUI window text, and alarm codes and text.
user input
text which you should type in exactly as shown.
The following abbreviations are used to represent keystrokes: Abbreviation
Means
CTRL+X
Hold down the CTRL key and then press the second key (X in this example).
SHIFT+X
Hold down the SHIFT key and then press the second key (X in this example).
Home Location Register (Linux) V1.1 Support Guide
2
1
Chapter 1
Overview of the HLR This chapter provides: • A quick summary of the role of the HLR in the GSM network. See Introduction to the HLR on page 2. • Brief descriptions of the services that the HLR provides to the GSM network. See Network Services Provided by the HLR on page 6.
2
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
Introduction to the HLR This section explains: • What HLR means and its purpose • External connections to the HLR • Network signalling that involves the HLR (see page 3) • Data in the HLR (see page 4)
What HLR Means
HLR means Home Location Register.
Why the HLR is Needed
A network typically has millions of subscribers and the network must contain, somewhere, a database with a record for each individual subscriber. This database is known as an HLR. A record contains which network services a subscriber can use, such as speech and short messages, and the current location of the subscriber. Network services can be enabled or disabled by the network operator. When a subscriber receives a call, the HLR provides the subscriber’s current location so the call can be connected, or diverts the call to the subscriber’s mailbox so that the caller can leave a message. The HLR must therefore keep track of subscribers as they move around. The subscriber database is usually spread over many HLRs because one is not big enough to hold every subscriber, and would represent a significant risk if it should fail.
Figure 1. How the HLR Connects to Network Entities Mailbox Location Register
MSC/VLR Alarm Monitoring and Admin. Commands
HLR
SGSN
Short Message Service Centre
SEP
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
3
Network Signalling and the HLR The HLR receives and sends messages in the following cases:
Subscriber Changes Location
When a subscriber moves from one VLR to another, the new VLR sends an update location message to the HLR to inform the HLR of the subscriber’s new location, and the HLR downloads data, such as the services that the subscriber can use, to the VLR. Update Location Mobile Handset IMSI (Update Location)
Incoming Call
Send Subscriber Data to VLR
An incoming call finds the called subscriber using a send routing information message to the HLR. The HLR signals to the VLR that the subscriber is registered on, and that VLR replies with a roaming number, which enables the network to connect the call. Incoming call to an MSISDN
Provide Roaming Number
Send Routing Information
VLR
HLR Roaming Number
Roaming Number
Location Based Services
HLR
A request for location information is made by sending a send routing information for LCS (location services) message to the HLR, which returns the address of the VLR that the subscriber is registered on. Request location Send Routing Information for LCS information for an MSISDN
HLR
VLR address
A VLR address is not returned for certain types of subscriber, for example if the MSISDN sent to the HLR is a published number for a linked subscription.
Forward a Call
If a subscriber diverts calls to a forwarding number or a mailbox number, the HLR stores the forwarding or mailbox number. Incoming calls are then connected using this number. Send Routing Information Incoming call to an MSISDN
HLR Forwarding or Mailbox Number
2
Home Location Register (Linux) V1.1 Support Guide
4
Chapter 1 Overview of the HLR
Linked Subscriptions
A linked subscription contains two or more mobile handsets that are called using a single published number. Calls to the published number are connected to whichever handset is nominated to receive calls. The diagram below shows the linked subscription configuration for the UK network.
HLR (nominated number) Send Routing Information
Incoming call to an MSISDN
HLR (published number)
SEP
Roaming Number
Consequences of an HLR Failure If an HLR fails, mobile handsets on that HLR (perhaps 1,000,000 subscribers or beyond) cannot receive calls because the incoming call cannot find them. Handset authentication will not be possible for outgoing calls, but MSCs are usually allowed to reuse authentication triplets and permit the call. Handsets on that HLR cannot register on a new VLR and will, therefore, be unable to make or receive calls if they move to a new VLR location.
Summary of Subscriber and Configuration Data Subscriber Data IMSI
Published MSISDN
List of ODBs
VLR Characteristics
Location Data
GPRS Settings
List of Basic Services
Tracing Settings
Message Waiting Data
Call Forwarding Settings
List of Supplementary Services
CAMEL Settings
Configuration Data Address String Convert Table (ASCVT)
Used to convert address strings to international format.
B Number Table
Numbers to check for IN originated calls.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
2
5
Bearer Capabilities Table (BCA)
Bearer Capability is sent to the VLR during call setup to establish correct characteristics for the type incoming call. The BCA table has various entries for text, speech and data.
C Number Behaviour Table
forward-to number translation that can be applied to individual subscribers.
C Number Table
Numbers that cannot be forwarded to.
HLR Configuration Table
The HLR is configurable to adapt to changes in number prefixes and network services.
SIGTRAN Configuration Table
SIGTRAN configuration information.
E.164 Conversion Numbers Table
E.164 conversion numbers.
Master Key and Transport Key Tables
Tables used for subscriber key encryption (SKE).
Mobile Station Roaming NumberPrefix Table
Lists prefixes of roaming numbers used by subscribers.
Network Entity Table
Configuration of other entities in the network, including global titles and logging setup.
PDS Configuration Table
Global title of the HLR, used when sending messages to other entities, logging masks and a default IMSI used when an exported subscriber causes a message to be sent to another network.
Service Provider Table
Lists a code, text containing name and telephone number, and voicemail message code for all service providers.
SS7 Configuration and SS7 Event Configuration Tables
Define SS7 links, destinations and events.
Timer Table
Configures all HLR timers, such as delays between Voicemail alerts.
Unstructured Supplementary Service Table
Contains unstructured supplementary service names, and the key presses and response syntax for each service.
Home Location Register (Linux) V1.1 Support Guide
6
Chapter 1 Overview of the HLR
Network Services Provided by the HLR This section describes the services that the HLR provides to the network: • Anonymous Call Reject (ACR) on page 6 • Call Forwarding on page 7 • CAMEL on page 13 • Control of Access to Premium Rate/Content on page 61 • Explicit Call Transfer on page 11 • General Packet Radio Service (GPRS) on page 29 • Home Zone Charging on page 33 • Location Based Services on page 36 • Mobile Number Portability (MNP) on page 40 • MultiSIM on page 46 • Service Provider Services on page 56 • Video Telephony on page 64
Anonymous Call Reject (ACR) Note: Although USSD tokens have been added for the ACR service, this service is not yet available to subscribers. A subscriber might not want to receive calls from callers who have withheld their calling line identity, or CLI. One possible use of this service is to prevent nuisance calls. ACR is a Vodafone proprietary supplementary service and is enabled and disabled by the subscriber using USSD commands. ACR is not downloaded to the VLR or sent to the GMSC, because anonymous calls can be rejected at the HLR.
Handling Anonymous Calls
A call to a customer who has the ACR service activated fails at the HLR if the CLI is withheld by the CLI Restriction supplementary service (see Calling Line Identity Restriction on page 632), or if a caller’s number is withheld. The caller’s number includes checking the calling party number (CgPN), and the generic number (GN) or presentation number (PN) or both (see Displayed Number on page 631). The HLR returns a CallBarred error to the SRI request if calling party information has been withheld. The handling of the CallBarred error depends on the network. Vodafone UK adds extra information to the
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
7
CallBarred error to indicate the reason that the call was rejected. This reason is then translated by the MSC into a message telling the caller why the call failed.
ACR and Last caller Information
The HLR does not update last caller information if a call attempt fails because the caller’s number was withheld. As a result, no record exists that the call was made.
ACR and OVERRIDE
The purpose of the OVERRIDE service is to display the caller’s number, even if the caller withheld that number. It therefore does not make sense for a customer with OVERRIDE to use the ACR service to reject anonymous calls. The HLR does not prevent a subscriber having both ACR and OVERRIDE services but a call does not fail due to ACR for a customer with OVERRIDE.
Interaction of ACR and CAMEL
Because ACR is a supplementary service, CAMEL takes precedence over ACR, so that CAMEL services will still be invoked even if a caller’s number is withheld. Note: The PDS HLR does not differentiate between call types (determined by basic service group) when ACR is provisioned. Note: Voicemail alerts will be blocked if the CLI is determined to be withheld. The USSD commands used to control the ACR service are defined in Anonymous Call Reject (ACR) on page 635.
Call Forwarding Mobile handset menus allow subscribers to forward calls to a new number, known as a forward-to number or C number. All calls can be forwarded, or calls can be forwarded depending on certain conditions, such as if the called party is busy with another call. In order to forward calls, a subscriber must have the necessary call forwarding supplementary services provisioned (see Supplementary Services on page 594).
Standard Forward-To Numbers
A standard forward-to number conforms to the E.164 standard. E.164 standard numbers have up to 15 digits, consisting of a country code, a national destination code and a subscriber number: 44 385 106099
Country code
2
National destination code
Subscriber number
Home Location Register (Linux) V1.1 Support Guide
8
Non-Standard Forward-To Numbers
Chapter 1 Overview of the HLR
forward-to numbers that do not conform to E.164 can be used in a subscriber’s home network if the following conditions are met: • The subscriber has the Ability to Register Special/Extended Numbers in Call-forwards (ARSENIC) supplementary service • The FTN length is within the range defined by FTN_SE_MIN_LEN, FTN_SE_MAX_LEN in the hlr_config Table Roamed subscribers can forward to non-E.164 numbers provided the network where they are registered supports CAMEL phase 2. The subscriber must have: • The ARSENIC supplementary service • CAMEL subscription data, including a CCH of 2 or above (CAMEL Capability Handling, which identifies a CAMEL phase) • The translation information (TIF_CSI) flag, which controls whether the subscriber can register non-E.164 forward-to numbers, must be TRUE
Divert Dependence on VLRs
Diverts that use ARSENIC or CAMEL require that the VLR supports these capabilities. If not, a subscriber’s handset might indicate that a divert has been registered, but the divert will not work. Also, the VIEW:SUB (page 231) command might indicate that diverts have been registered even though the diverts could not be downloaded to the VLR because the VLR does not support ARSENIC or the required phase of CAMEL.
Number Translation for Call Forwarding Translation of forward-to numbers depends on whether the forward-to number (C number) is a standard E.164 number or not.
Standard Forward-To Numbers
Standard diverts are not translated if a subscriber has a CNUM_BHVR value of 0 (zero). If CNUM_BHVR is not zero, the forward-to number is translated according to the C Number Behaviour Table (cnum_bhvr) (see page 469).
Non-Standard Forward-To Numbers
Non standard forward-to numbers are not translated by the C number behaviour table. Number translation is done by another network entity (the SEP in the Vodafone UK network) as the call is being set up.
Forward-To Number Behaviour Modes The HLR categorises forward-to numbers into behaviour modes GSM, SMSB, RECALL and SE.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
9
GSM applies to standard forward-to numbers, SMSB is a divert for the (Respond Plus) short message bureau service, RECALL is for the Voicemail service and SE means special/extended (and applies to non-standard forward-to numbers). SE diverts are further categorised into behaviour modes by the value of the SE_FLAGS parameter, as described in Table 1 below. Table 1. Special/Extended Forward-to Number Behaviour Modes SE Behaviour Mode
Conditions
Description
Subscriber does not have the Mobile Virtual Private Network Full Number Plan (MVPN_FNP) supplementary service
SE_CAMEL
FTN is the same as the subscriber’s MSISDN or published number (PNUM) or FTN is barred in the [CNUMSE] section of the C Number Table (cnum)
CAMEL_ONLY
The FTN will not be registered if the FTN is barred in the [CNUMCAMEL] section of the C Number Table (cnum). The FTN can only be downloaded as CAMEL. This means the subscriber must be registered on a CAMEL 2 supporting network, have a CCH of 2 or above and have a TIF_CSI value of TRUE.
Subscriber has the Mobile Virtual Private Network Full Number Plan (MVPN_FNP) supplementary service or FTN is barred in the [CNUMCAMEL] section of the C Number Table (cnum)
SE_ONLY
FTN cannot be downloaded as CAMEL. Diverts use the Ability to Register Special/ Extended Numbers in Call-forwards (ARSENIC) supplementary service and work only in the home network.
The basic behaviour mode (GSM, SMSB, RECALL or SE) can be set using the REGISTER:SS command (see page 322). If the behaviour mode is set to SE, SE_FLAGS is set as described in Table 1. Other behaviour modes for non-standard forward-to numbers cannot be overridden using an administration command, they are derived internally by the HLR according to the subscriber’s supplementary services, the C number table, and the forward-to number itself.
Barring Forward-To Numbers The HLR prevents subscribers registering certain forward-to numbers, such as emergency numbers, using the C Number Table (cnum) (see page 469). If a forward-to number is not special/extended, the call is checked for incoming and outgoing bars before it is allowed to continue. If a forward-to number is special/extended, the HLR cannot bar an outgoing call that depends on the location of the final outgoing number, such as bar outgoing international calls (BOIC). The final outgoing
2
Home Location Register (Linux) V1.1 Support Guide
10
Chapter 1 Overview of the HLR
number is determined by the CAMEL server (SEP in the UK network), so the HLR cannot check the location of the call destination. However, such calls can be barred by the CAMEL server.
Default Call Forwarding Default Call Forwarding allows calls to be forwarded to default numbers when the normal call diverts are not set. A different default number can be specified for each divert: • busy • no reply • not reachable Default Call Forwarding is implemented using the supplementary services DCFB, DCFNRC, and DCFNRY.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
11
Explicit Call Transfer Explicit call transfer (ECT) allows a party involved in two calls to connect those two calls together and then disconnect. This can be used for call transfer, where party A, who has a call in progress with party B, calls party C, connects B to C and then disconnects. Call transfer is illustrated in Figure 2 below. Figure 2. Explicit Call Transfer Call Answered
A
B
A
B
Call Answered or Alerting
C
C
Call transfer is a supplementary service, called ECT, that requires basic service TS11 (see Basic and Supplementary Services on page 591). Most of the call transfer functionality is provided by the MSCs. Explicit call transfer uses the following operator determined bars (ODBs): ODBECT, ODBECTC, ODBECTCI, ODBECTCZ, ODBECTC2 and ODBECTSM. See Operator Determined Bars on page 647. The ECT supplementary service can be specified in the <ss_code> field of the ADD:CAMEL (page 332) and UPDATE:CAMEL (page 375) commands. Specifying ECT as an <ss_code> enables CAMEL services when ECT is invoked.Network signalling for call transfer is shown in Figure 3 below.
2
Home Location Register (Linux) V1.1 Support Guide
12
Chapter 1 Overview of the HLR
Figure 3. Signalling for Call Transfer Handset A
MSC A
ECT request
VLR A
MSC B
Handset B
Call C
Call C
info request info ack
Checks performed in VLR and MSC. If OK, connect calls.
CAMEL means Customised Applications for Mobile networks Enhanced Logic. CAMEL allows the home network to monitor and control calls when a subscriber is roamed. CAMEL services are specific to individual subscribers and are, therefore, linked to a specific IMSI or MSISDN. CAMEL allows numbers dialled to be modified during call set-up, and monitoring of call answer and disconnect. CAMEL has been standardised in various phases, with progressively increasing capabilities, and not all of them are implemented in the HLR (see CAMEL Phases on page 14 and Vodafone Services and CAMEL on page 17).
CAMEL Network Entities
CAMEL services introduce two new entities into the GSM network, the service switching function (gsmSSF) and the service control function (gsmSCF). The service switching function is implemented in existing MSCs and, in the UK network, the service control function is implemented in the Vodafone Service Execution Platform (SEP). gsmSCF (SEP in the UK) gsmSSF
MSC/VLR
HLR
Subscription Information
CAMEL subscription information indicates how and when to trigger CAMEL enquiries. CAMEL subscription information (CSI) is grouped according to services, such as SS-CSI for supplementary services and O-CSI for mobile originated (outgoing) calls.
CAMEL in this Guide
Subscriber data for CAMEL services is administered using the commands described in Chapter 19, CAMEL Commands on page 331.
Release call Connect to other destination continue unchanged Anytime interrogation (ATI) of the HLR for subscriber location and state Note: CAMEL can release a call at any time, regardless of calling or called party actions, provided that CAMEL has ongoing control of the call. If the CAMEL dialogue has ended, CAMEL cannot affect the call.
Incoming
GMSC
CAMEL
Note: A CAMEL dialogue is started by a trigger detection point (TDP). Event detection points (EDPs), such as answer or busy, occur during the CAMEL dialogue. Trigger detection points, outgoing calls: • Collected information Trigger detection points, incoming calls: • Terminating attempt authorized Event detection points: • Answer (notify and continue) • Disconnect (notify or report and wait for instructions to release connect or continue)
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
Phase 2 (GSM release ‘97)
2
Subscription Information • SS-CSI (supplementary service CSI) for: * Explicit call transfer * Multiparty * Call deflection • TIF-CSI (translation information flag CSI) for registering a short forward-to number • U-CSI/UG-CSI (forward outgoing USSD/originate USSD to the subscriber via HLR), allowing the subscriber to interact with CAMEL services
15
Signalling and Detection Points
Functions
Signalling: same as phase 1.
• Inserting announcements and receiving DTMF digits (entering a PIN number after an announcement, for example) • Subscriber location down to cell ID • CAMEL sets alerting pattern • Download call duration • Set charging information in VMSC (outgoing call) or GMSC (incoming call)
Event detection points: • Abandon • Answer • Busy (used for busy and not reachable) • Disconnect • No answer • Route select failure (originating only)
Home Location Register (Linux) V1.1 Support Guide
16
Phase 3 (3G release ‘99)
Chapter 1 Overview of the HLR
Subscription Information • D-CSI (subscribed dialled services) • N-CSI (services on a per network basis) • VT-CSI (incoming calls trigger at the VMSC, which gives CAMEL more call information) • GPRS-CSI (CAMEL controls GPRS sessions) • MOSMS-CSI (CAMEL controls outgoing SMS messages) • M-CSI (informs CAMEL of mobility management events)
Signalling and Detection Points
Functions
Signalling:
• Anytime modification and more powerful interrogation of HLR data. Includes: * Anytime modification (ATM) of CSI, call forwarding, call barring or ODB data * Anytime subscription interrogation (ATSI), which checks bars, call forwarding and CAMEL subscription information (CS) * Notify subscriber data change (NSDC). The CAMEL server maintains a copy of subscriber data and the HLR notifies the server if bars, call forwarding or CSIs change. • Anytime interrogation (ATI) of the gateway mobile location centre (GMLC) • CAMEL can suppress supplementary services on a per-call basis • CAMEL can withhold CLI • CAMEL can alter or remove CUG information • CAMEL can be informed of progress of a Call Completion to Busy Subscriber (CCBS), which is the GSM equivalent of ringing back if the called number is busy
incoming CAMEL (more call information is available at VMSC than GMSC) CAMEL home network
GMSC
VMSC visited network
Trigger detection points, outgoing calls (additional to those in phase 2): • Analysed information • Route select failure (also a phase 2 event detection point) Trigger detection points, incoming calls (additional to those in phase 2): • Terminating no answer • Terminating busy Event detection points: same as phase 2.
Signalling: same as phase 3. Event detection points (additional to those in phase 3): • Alerting • Change of position • Mid-call
(3G release 6)
Home Location Register (Linux) V1.1 Support Guide
• Call party handling • Control of incoming short messages • Retrieval of location information, Any Time Interrogation of SGSNs (in addition to MSCs)
• Enhanced subscribed dialled services
2
Chapter 1 Overview of the HLR
17
Vodafone Services and CAMEL Phase
Subscription Information
1
• O-CSI identifies: * CAMEL support is required * CAMEL services environments used to support CAMEL * Operator specific service information • T-CSI is not used because incoming calls do not use CAMEL (Vodafone UK only)
Signalling and Detection Points
Visited network Outgoing
VMSC
CAMEL
Vodafone Service • PAYT roaming: *An outgoing call attempt by a roamed prepay subscriber triggers an enquiry to the SEP * Incoming calls to roamed pre-pay subscribers do not use CAMEL, they use the TICKROAM supplementary service (Vodafone UK only)
SEP
2
• O-CSI identifies everything in phase 1 plus: * Checking a called number before making a CAMEL enquiry * Checking the length of a called number before making a CAMEL enquiry * forward-to numbers that do not have the standard E.164 format * Phase of CAMEL to use • TIF-CSI (translation information flag CSI) for: * Register a short forward-to number (VLR must support CAMEL phase 2) * A TIF-CSI value of TRUE allows a subscriber to register FTNs that are non-standard because they are not in E.164 format. Modifying the TIF_CSI from TRUE to FALSE makes any non-standard CAMEL FTNs quiescent. • SS-CSI (supplementary service CSI) for: * Explicit call transfer * Multiparty * Call deflection
2
same as phase 1.
• Forward-to numbers in non-standard format • CAMEL enquiry triggered by called number • CAMEL enquiry triggered by called number length • Multiparty calls
Home Location Register (Linux) V1.1 Support Guide
18
Chapter 1 Overview of the HLR
Phase
Subscription Information
3
The Vodafone HLR supports the following subscription information for CAMEL phase 3, but no services currently use phase 3: • D-CSI (subscribed dialled services) • GPRS-CSI (CAMEL controls GPRS sessions) • M-CSI (informs CAMEL of mobility management events) • MOSMS-CSI (CAMEL controls outgoing SMS messages) • T-CSI (terminating CAMEL subscription information) • U-CSI (informs CAMEL of USSD events on a per subscriber basis) • UG-CSI U-CSI (informs CAMEL of USSD events and applies to all subscribers) • VT-CSI (incoming calls trigger at the VMSC, which gives CAMEL more call information)
4
Vodafone services using CAMEL phase 4 have not yet been implemented.
Signalling and Detection Points
Vodafone Service No Vodafone services use CAMEL phase 3.
Incoming CAMEL (more call information is available at VMSC than GMSC) CAMEL Home network
GMSC
VMSC Visited network
same as phase 3.
Vodafone services using CAMEL phase 4 have not yet been implemented.
CAMEL Signalling The CAMEL standard allows control of both outgoing calls (known as mobile originated) and incoming calls (known as mobile terminated).
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
19
Figure 4. Mobile Originated (Outgoing) Calls BSS
MSC
call setup
VLR
send info for outgoing call
complete call, send O-CSI data
gsmSSF
gsmSCF
VLR checks CAMEL subscription. Outgoing bars are checked, except for conditional ones such as ODBOICXHC (outgoing international calls except to home country), because CAMEL processing may change the called number
call proceeding comfort message MSC receives O-CSI data, so must invoke CAMEL before proceeding with invoke gsmSSF
gsmSSF invoked
detection point collected information (includes all information about the call) initial detection point (DP)
connect connect
MSC changes call parameters as per connect message and checks conditional bars send info for outgoing call
complete call using roaming number
gsmSCF can arm detection point, such as “call answer”, which allows CAMEL to maintain control of the call, followed by: • Connect - changes have been made to call data • Continue - no changes have been made to call data • Release - end the call
initial addressing message to destination exchange
2
Home Location Register (Linux) V1.1 Support Guide
20
Chapter 1 Overview of the HLR
Figure 5. Mobile Terminated (Incoming) Calls GMSC
gsmSSF
gsmSCF
HLR
VLR
VMSC
initial addressing message from originating exchange IAM includes call information send routing information (SRI)
The SRI contains the CAMEL phases supported by GMSC
SRI acknowledgement including T-CSI data, O-CSI TDP4 data, CAMEL2 criteria and D-CSI data
Note: If T-CSI is returned and the subscriber has the retrieve subscriber state and location information flag set, subscriber state and location information is returned in the SRI ack message.
invoke gsmSSF
HLR checks the Network Entity (netent) Table, the unsupported application context learning list (UAL list) and the supported CAMEL phases in the SRI message and uses the lowest of the three as the CAMEL phase supported by the GMSC. The HLR then returns the correct CAMEL subscription information. Note: If the subscriber has the Terminating IN Category Key in Home network (HOMETICK) or Terminating IN Category Key when Roamed (ROAMTICK) attribute, then this service is invoked instead of CAMEL
MSC receives CSI data, so invokes CAMEL before proceeding with the call
gsmSSF invoked
DP termination attempt authorized
contains all of the call information
Initial DP
contains all of the call information
T-CSI data has already been downloaded and CAMEL processing completed. Suppress T-CSI prevents T-CSI data being downloaded again.
connect (can include charging information) connect
Note: SRI can contain parameters for suppression of announcements and alerting pattern. The HLR
send routing information
suppress T-CSI provide roaming number
send routing information acknowledge, including roaming number
The PRN message includes the supported CAMEL phases
provide roaming number acknowledge
initial addressing message to visited MSC
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
21
Downloaded CAMEL Data For mobile originated (outgoing) calls, CAMEL subscription information must be held in the visited VLR (or SGSN for a GPRS subscriber), because the HLR in the home network is not involved in signalling for outgoing calls. For mobile terminated (incoming) calls, if CAMEL is invoked at the VLR in the visited network rather than at the GMSC in the home network, CAMEL data must be held in the visited VLR. Table 2 lists CAMEL subscription information (CSI) downloaded to the visited VLR or SGSN in response to, say, an update location message. Table 2. CAMEL Data Downloaded to a VLR or SGSN CAMEL CSI
Description
Downloaded To
O-CSI
Used to invoke CAMEL for mobile originated calls
VLR and GMSC
T-CSI
Used to invoke CAMEL for mobile terminated calls
GMSC only
GPRS-CSI
Used to invoke CAMEL for GPRS sessions
SGSN
MOSMS-CSI
Used to invoke CAMEL for outgoing SMS messages. The HLR does not distinguish between an SGSN and VLR when invoking unsupported behaviour bars
SGSN and VLR
D-CSI
Used to invoke CAMEL for dialled subscribed services
VLR and GMSC
VT-CSI
Used to invoke CAMEL at the VLR in the visited network for mobile terminated (incoming) calls
VLR
M-CSI
Used to invoke CAMEL for mobility management
VLR
SS-CSI
Used to invoke CAMEL for supplementary services
VLR
2
Home Location Register (Linux) V1.1 Support Guide
22
Chapter 1 Overview of the HLR
CAMEL download can be affected by CAMEL support in the network or the combination of services a subscriber has. Operator determined bars might be applied or CAMEL data might not be downloaded at all. Factors that affect CAMEL download are: • The CAMEL phase supported by the visited VLR or SGSN where a subscriber is registered. See How VLR and SGSN CAMEL Support Affects Services on page 22. • The interaction between different trigger detection points within a single type of CAMEL subscription information. See Interaction of Multiple CAMEL Trigger Detection Points on page 23. • The interaction between different types of CSI. See Interaction Between Multiple CAMEL Subscription Types on page 24. • Whether the subscriber has the Originating IN Category Key (OICK) supplementary service. See CAMEL Interaction with OICK on page 25. • Whether the subscriber has the Terminating IN Category Key (TICK) supplementary service. See CAMEL Interaction with TICK on page 26.
How VLR and SGSN CAMEL Support Affects Services For CAMEL services to work, the visited VLR or SGSN must support the phase of CAMEL that the service requires. Therefore, the CAMEL phase supported by the VLR will affect what CAMEL data is downloaded, in response to an UpdateLocation message for example.
CAMEL Capability Handling
Each CAMEL trigger detection point (TDP) has a CAMEL Capability Handling (CCH) attribute, which defines a minimum CAMEL phase for support of the TDP, a threshold above which the TDP is fully supported and a maximum above which a TDP is not supported. A TDP also includes two lists of bars, one used if the VLR or SGSN does not support the minimum CAMEL phase defined by CCH and one list used if the VLR or SGSN supports at least the minimum but less than the phase required for full support.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
23
Figure 6. How CAMEL Capability Handling (CCH) Controls Data Download maximum CAMEL service fully supported
CAMEL data downloaded, no bars
threshold
CAMEL data downloaded LC_UNSUPP_BH bars invoked
CAMEL service partly supported
CAMEL data not downloaded NO_SVC_UNSUPP_BH bars invoked
minimum CAMEL service not supported
CCH increasing For example, if a TDP has a CCH of {2 3 4} and the VLR where the subscriber is registered in the visited network supports CAMEL phase 2, CAMEL data is downloaded but the bars defined by LC_UNSUPP_BH are invoked. If the subscriber then moves to a VLR that supports CAMEL phase 3 or 4, the TDP will be fully supported and no bars will be invoked.
Interaction of Multiple CAMEL Trigger Detection Points For the purpose of downloading CAMEL data to a VLR, trigger detection points (TDPs) are grouped by the CAMEL subscription information (CSI) type they apply to. For example, the TDPs OCSI_2 and OCSI_4 are for originating calls and the TDPs for GPRS are GPRSCSI_1, GPRSCSI_2, GPRSCSI_11, GPRSCSI_12, and GPRSCSI_14. For a particular CAMEL subscription information (CSI) type, the HLR can use only one CAMEL capability handling (CCH) value. Therefore, if a subscriber has more than one TDP from the same CSI type, all TDPs behave as though the network supports the lowest of the maximums defined by the CCH value for each TDP.
2
Home Location Register (Linux) V1.1 Support Guide
24
Chapter 1 Overview of the HLR
For example, if OCSI_2 has a CCH of {1 1 2} and OCSI_4 has a CCH of {2 3 4}, a maximum CAMEL phase of 2 is assumed. Even if a subscriber registers on a VLR that supports CAMEL phase 3.
CCH = {1 1 2}
OCSI_2 Lowest maximum is 2, so VLR support of CAMEL phase 2 is assumed OCSI_4 CCH = {2 3 4}
The effect of a VLR supporting a lower CAMEL phase than required is described in How VLR and SGSN CAMEL Support Affects Services on page 22.
Interaction Between Multiple CAMEL Subscription Types Adding a new CSI type to a subscriber can adversely affect an existing CAMEL service. For example, a subscriber with the OCSI_2 TDP can register on a VLR that supports CAMEL phase 1 or greater and make calls.
OCSI_2 CCH = {1 1 2}
VLR Supports CAMEL Phase 2
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
25
If the same subscriber is then given the mobile originated SMS CSI, the VLR does not support the required phase of CAMEL (phase 3) and bars are invoked, which might prevent the subscriber making calls.
MOSMS_CSI CCH = {3 3 3}
invokes NO_SVC_UNSUPP_BH bars
VLR Supports CAMEL Phase 2
OCSI_2 CCH = {1 1 2}
CAMEL Interaction with OICK If the subscriber has Originating IN Category Key (OICK) and is in an OICK supporting network, OICK will always be downloaded. Regardless of whether the subscriber has CAMEL O-CSI data, OICK overrides O-CSI data at all CAMEL phases so that OICK services are provided but mobile originating CAMEL services are not. For example, CAMEL 2 FTNs (see Non-Standard Forward-To Numbers on page 8) cannot be downloaded if the subscriber has OICK and the network supports OICK. Even though OICK overrides O-CSI data, O-CSI TDP4 has its own unsupported behaviour that is invoked independently of OICK and might adversely affect OICK behaviour if a network entity does not have the CAMEL support needed by O-CSI TDP4. Some service reduction is therefore a risk if a subscriber has both OICK and O-CSI TDP4. If a subscriber has OICK but OICK is not supported by the VLR, download depends on the CAMEL support of the VLR. Interaction between CAMEL O-CSI data and OICK is shown in the table below. Subscriber has OICK, VLR does not Support OICK
Subscriber has OICK, VLR Supports OICK
O-CSI not supported
Invoke unsupported OICK
OICK downloaded, O-CSI not downloaded
O-CSI supported or partially supported
Ignore OICK data and refer to CAMEL O-CSI data to invoke bars.
OICK downloaded, O-CSI not downloaded
Unlike CAMEL services for mobile originated calls, CAMEL services for mobile originated SMS messages, for mobility management and for supplementary services can be downloaded alongside OICK.
2
Home Location Register (Linux) V1.1 Support Guide
26
Chapter 1 Overview of the HLR
Therefore, any bars invoked as a result of insufficient CAMEL support for MOSMS-CSI might adversely affect OICK services.
CAMEL Interaction with TICK If the SendRoutingInformation message to the HLR indicates that the GMSC supports the Ericsson proprietary Terminating IN Category Key (TICK) functionality, and the subscriber has a non-zero HOMETICK or ROAMTICK attribute, then T-CSI data is not sent to the GMSC. TICK processing in invoked regardless of whether the subscriber has O-CSI, T-CSI or D-CSI. TICK functionality can be supported in the home network or in a visited network, but whether TICK processing is invoked, and the kind of TICK processing invoked, depends on the subscriber’s HOMETICK and ROAMTICK attributes. Values of zero indicate that the subscriber does not have TICK, and no processing should be invoked. ROAMTICK is used for the pre-pay roaming service, so pre-pay subscribers who are able to roam cannot use CAMEL services for mobile terminated calls or dialled subscribed services. Vodafone UK does not use any of these CAMEL services. O-CSI data is returned to the GMSC during a mobile terminated call to allow a mobile originated CAMEL service to modify the terminated call. For example, O-CSI data is used if the HLR forwards calls to non-standard numbers.
CAMEL Support Checking by Unsupported Application Context Learning (UAL) The CAMEL phases not supported by a VLR or an SGSN are specified in the Network Entity (netent) Table (see page 509). If signalling between the HLR and a VLR or SGSN indicates that a certain phase is not supported, the unsupported application context learning (UAL) list will keep track of this lower CAMEL support. Note, however, that if an entity subsequently supports a higher phase, the UAL list will not change to reflect the higher support. Similarly, if an SGSN or VLR does not return supported CAMEL phase information, then the UAL list will record that CAMEL is not supported. The HLR will not attempt to download CAMEL data again until the UAL_RETRY period specified in the PDS Configuration (pds_config) Table (see page 523) has elapsed and CAMEL support is rechecked.
CAMEL Phase One Example - PAYT Roaming A pre-pay subscriber who roams to a network that supports CAMEL can make outgoing calls in the same way as a contract subscriber. An outgoing call follows these steps:
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
27
1. Pre-pay subscriber registers on visited network (Figure 7) 2. Vodafone HLR downloads CAMEL data to the visited MSC where the subscriber is registered 3. Pre-pay subscriber makes an outgoing call (Figure 8) 4. Visited MSC forwards call information to a SEP in the Vodafone UK network 5. SEP checks the cost of connecting the called number against subscriber credit and whether roaming is allowed to the visited MSC 6. call is connected or released Figure 7 shows downloading CAMEL service data to the visited MSC. Figure 7. The HLR and CAMEL - Downloading CAMEL Service Data to a VMSC Home PLMN
Visited PLMN
update location
HLR
VMSC
CAMEL Service Data
subscriber registers subscriber data (including CAMEL data)
CAMEL service environment (CSE), SEP in the UK
Figure 8 shows how CAMEL is used to control an outgoing call.
2
Home Location Register (Linux) V1.1 Support Guide
28
Chapter 1 Overview of the HLR
Figure 8. HLR and CAMEL - Modifying an Outgoing Call
Home PLMN
HLR
CAMEL Service Data
Visited PLMN
VMSC forward call data for processing
CAMEL Service Data
outgoing call
connect call
CAMEL service environment (CSE), SEP in the UK initial addressing message to destination exchange
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
29
General Packet Radio Service (GPRS) The general packet radio service (GPRS) provides data services, such as e-mail and remote access to corporate networks, to mobile subscribers. GPRS uses the same radio equipment and HLR as the rest of the GSM network, but is otherwise completely separate (see Figure 9). Figure 9. The HLR and GPRS
GSM Network VLR Radio Equipment
HLR
SGSN GPRS Network
Other Network
The HLR stores two subscriber locations, one for GPRS and one for the rest of the GSM network. The HLR also keeps a list of the packet data services for a subscriber in a similar way to the list of basic and supplementary services. Mobile originated GPRS is supported, but mobile terminated is not. However, both mobile originated and mobile terminated short message service (SMS) are supported for GPRS.
2
Home Location Register (Linux) V1.1 Support Guide
30
Chapter 1 Overview of the HLR
Linked Subscriptions Two options are available to subscribers who want two or more mobile handsets in the same subscription, a MultiSIM subscription (see page 46) or a linked subscription. Linked subscriptions have two variants called automotive twin SIM (ATS) and mutually exclusive secondary SIM (MESS). Callers to a linked subscription dial a single published number which is routed, by the network, to one of the handsets belonging to the linked subscription. Which handset receives calls is nominated by the subscriber. Figure 10 shows the network configuration for the UK. Figure 10. Routing to a Linked Subscription
HLR (nominated number) Send Routing Information
Incoming call to a published MSISDN
HLR (published number)
SEP
Roaming Number
As an example, the linked subscription (ATS only) USSD codes for the UK Vodafone network are listed in Table 3. Table 3. Example Linked Subscription USSD Codes To
Enter the Code
The Successful Response is
Nominate yourself
*131#
SIM ID is nominated
Nominate another member
*131*ID#
SIM ID is nominated
See who is nominated
*#131#
SIM ID is nominated
Find out your member ID
*#130#
I am SIM ID
ID is the member ID
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
ATS Linked Subscription
31
An ATS linked subscription allows incoming calls to use either the published number for the linked subscription, or the MSISDN of any member. Members of an ATS subscription are able to make and receive calls at any time, regardless of whether other members have calls in progress. ATS MSISDN Call
Published Number Nominated
Call
MESS Linked Subscription
MSISDN
A MESS linked subscription allows calls to the published number only. The MSISDNs of individual members will not usually be known to callers, but any calls to these MSISDNs, a wrong number for example, will be treated as though the called subscriber does not exist. Only the nominated subscriber can make or receive calls, even if a non-nominated member has a secondary number, a fax number for example. However, members can, at any time, control diverts, set calling line identification restriction, activate and deactivate SMS and carry out other similar operations. MESS
MSISDN (hidden) Published Number
Nominated
MSISDN (hidden) Call not allowed
Administration Commands for Linked Subscriptions A linked subscription is created in two steps. 1. Create a subscription with the LINKED supplementary service. This subscription has no associated handset, it simply provides an MSISDN that can be used as the published number (PNUM) to link other subscriptions together.
2
Home Location Register (Linux) V1.1 Support Guide
32
Chapter 1 Overview of the HLR
2. Link existing subscriptions to the published number in step 1. The subscription with the LINKED supplementary service is created as follows. CREATE:SUB,000000000000110,07712345678,TS11; PROVISION:SS,IMSI,000000000000110,LINKED; Specify that the published number is downloaded to the VLR. UPDATE:SUB,MSISDN,00000000012,DNLD_P,PNUM; Specify that the published number is returned in response to an enquiry for a subscriber’s own MSISDN. UPDATE:SUB,MSISDN,00000000012,OWNM_P,PNUM; Subscribers are then added to this linked subscription using an UPDATE:SUB command. For example, to add the subscription with MSISDN 077 11111111, the following command is used. UPDATE:SUB,MSISDN,07711111111,PNUM,07712345678;
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
33
Home Zone Charging GSM allows a network operator to define geographical areas, known as zones, within the home or other network. The area served by a single VLR or SGSN can be divided into several zones, or larger areas can be defined containing areas served by one or more VLRs or SGSNs. These geographical areas can be outside the home network but all zones must be in one network. Home zone charging is based on GSM regional subscriptions. Home zone charging uses the regional subscription data to allow call charges to vary with the location of the subscriber. For example, a subscriber could be given cheaper calls when at home or in the office.
Home Zone Charging in this Guide
Each subscriber has an individual zone code list which is added and updated using the UPDATE:ZONELIST command (see page 228). The zone codes for a subscriber can be viewed using the VIEW:SUB command (see page 231) and a VLR or SGSN can be checked for support of regional subscriptions using the VIEW:NETWORK command (see page 409). Services that are not supported by a VLR or SGSN are defined in the Network Entity (netent) Table (see page 509) and in the Unsupported Application Context Learning (UAL) list.
Defining Zones
Zone codes are specified in a list that starts with a country code (CC) and national destination code (NDC) combination followed by the codes themselves. The first check made by home zone charging is that the CC-NDC combination matches the CC and NDC of the global title of the VLR or SGSN where a subscriber is registered. In the Vodafone UK network, for example, many VLR global titles start 447785. Zones are then defined within this CC-NDC area based on GSM cells, but do not use cell IDs. Each cell is assigned one or more zone codes which can be compared with a subscriber’s zone code list. For home zone charging, the comparison is used to determine call costs based on a subscriber’s zone data as shown in the example in Figure 11 on page 34.
2
Home Location Register (Linux) V1.1 Support Guide
34
Chapter 1 Overview of the HLR
Figure 11. Assigning Zone Codes in the Home Network
Cell ID = 2 zone code(s): 100 Cell ID = 3 VLR or SGSN global title: 447785 123456
Cell ID = 1
zone code(s): 200
zone code(s): 100 subscriber: CC-NDC: 447785 zone code 100
Cell ID = 4 zone code(s): 200
The subscriber registered on this VLR or SGSN is charged a different rate when in cells 1 and 2 than when in cells 3 and 4 Note: Cell sizes can vary with environmental conditions, and zones for GPRS and GSM services do not necessarily cover the same physical areas.
Signalling for Home Zone Charging The HLR stores regional subscription data for each subscriber, which is downloaded when a subscriber registers on a VLR. The VLR compares the subscriber’s regional subscription data with its own to determine how a subscriber will be charged, or whether the subscriber will be allowed to register at all. Note: The VLR determines how regional subscription data is used, for charging or roaming control for example, not the HLR. Signalling for regional subscription data is shown in Figure 12 below. If an attempt to download regional subscription data results in an error, the Unsupported Application Context Learning (UAL) table is updated to indicate that the VLR/SGSN does not support regional subscriptions.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
35
Figure 12. Home Zone Charging Signalling mobile handset
VLR / SGSN
register
HLR
UpdateLocation or UpdateLocationGPRS HLR checks: download subscriber data, including regional subscription data
that the country code (CC) and national dialling code (NDC) of the zone code matches those of the VLR/SGSN global title the entry in the NETENT table for the VLR/SGSN to ensure that regional subscription (REGSUB) is not an unsupported service
VLR/SGSN compares subscriber’s regional subscription data with its own to determine whether to bar registration or apply zone related charging.
Network Support Required for Home Zone Charging
2
the unsupported application context learning (UAL) table to ensure that regional subscription in not an unsupported service
Home zone is an Ericsson proprietary capability and requires Ericsson VLR and SGSN versions that support home zone charging.
Home Location Register (Linux) V1.1 Support Guide
36
Chapter 1 Overview of the HLR
Location Based Services The HLR is compliant to the 3GPP R99 standards for location services and supports Location Services using different methods, such as Time of Arrival (TOA), Enhanced Observed Time Difference (E-OTD) and Assisted Global Positioning System (A-GPS). • Privacy data of subscribers will be controllable through USSD • Subscriber privacy profile is extended substantially from two Boolean flags (PAI, and PAI_CTRL) to a structure called the Subscriber Location Privacy Profile (SLPP) (see the description of Subscriber Location Privacy Profile (SLPP) on page 37), which specifies which networks or services are allowed to locate each subscriber. • HLR handling of the AnyTimeInterrogation (ATI) and SRIforLocationServices messages for exported subscribers allow support of number portability for location services. Therefore, subscribers who have moved to Vodafone from other networks and subscribers who have moved their accounts from Vodafone to another network can use location services. • A subscriber controls privacy data using a USSD commands, which are described in Positioning Services on page 643. Figure 13. Network Entities for Location Services HLR in other network
Forwarded ATI or SRIforLCS
Entity in other network
ATI
TCP/IP interface
LES
HLR Relayed USSD requests and responses
Download subscriber location privacy profile (SLPP) USSD requests and responses
SRIforLCS
GMLC
MSC/VLR
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
37
Mobile Terminated Location Requests The LES requests positioning of a subscriber through the GMLC from the HLR and MSC. If the GMLC does not contain the VMSC or IMSI of a subscriber, it interrogates the HLR using an SRIforLCS message. The HLR responds with SRIforLCSack. The GMLC then sends a ProvideSubscriberLocation (PSL) message to the VMSC. The VMSC responds with the location in PSLack. Figure 14. Requesting the Position of a Subscriber LES
1. Request Subscriber Position
4. Provide Subscriber Location
MSC/VLR
6. Return Subscriber Position
2. SRIforLCS
GMLC 5. Provide Subscriber Location Acknowledgement
HLR
3. SRIforLCS Acknowledgement
Subscriber Location Privacy Profile (SLPP) The subscriber privacy profile is no longer simply the PAI flag (see page 221), it is a structure that can allow or disallow selected services and networks. The subscriber location privacy profile is downloaded to the VLR when the HLR updates subscriber information. The SLPP contains two types of information: • A list of clients that are allowed to request location information from the HLR. • A list of mobile location centres (MLCs). This list can be used to optionally restrict the MLCs that are allowed to communicate with the HLR. The SLPP data is not stored in the HLR database: it is retrieved from a data table on the HLR and sent to the VLR. The HLR can be configured to download flags, SLPP or both, but the default configuration is to download SLPP only. 2
Home Location Register (Linux) V1.1 Support Guide
38
Chapter 1 Overview of the HLR
The SLPP data is not stored in the HLR database. Instead, the existing PAI flag is read from the HLR database and this indicates either "positioning allowed" or "positioning not allowed". One of two SLPP profiles is then downloaded, to either allow or disallow location services. SLPP profiles are defined by entries in the hlr_config Table, which are described in Configuration of Location Based Services on page 490. The same profiles are used for all subscribers and are configurable using table maintenance.
Privacy in the Location Enabling Server (LES) Subscribers send USSD commands to query or change the privacy flag in the LES. The HLR uses a mask to convert the USSD string into a text message, which it sends to the LES over TCP/IP using HTTP. The LES returns a text response to the HLR over the same interface; the HLR converts this to a USSD using another text mask. The HLR then sends this USSD response to the subscriber. The following USSDs control location privacy: • Query privacy Flag – the subscriber sends this USSD to see whether privacy is enable or disabled for them. • Enable Location Services Flag – the subscriber sends this USSD to set its privacy flag. • Disable Location Services Flag – the subscriber sends this USSD to clear its privacy flag. • Initialise Location Services – create an entry on the LES for the subscriber. The USSD commands are described in Positioning Services on page 643. The subscriber controls whether position information is returned by the MSC/VLR to the GMPC by enabling or disabling positioning using USSD commands (see Positioning Services on page 643). However, the mobile positioning centre can override the PAI flag and SLPP Data using a positioning override indicator (POI) flag and force the MSC/VLR to return positioning data to the GMLC. This override is useful for emergency centres to find a subscriber’s location even though that subscriber has disallowed positioning.
Registering Subscribers with the LES Initially, all subscribers are unknown to the LES. When a subscriber sends a Query or Modify USSD, the LES responds with "Unknown Subscriber". The HLR converts this to a USSD response message asking the subscriber to use the "Initialise" service to create an entry for them in the LES. Once the entry is created, the subscriber can use the Query and Modify USSDs.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
39
The LES needs to initialise each subscriber once only, and the subscribers must provision themselves by responding to a message such as "Welcome to Location Services. Use *#123 to start using the service". Once the subscriber has done this, the LES will have an entry for the subscriber and the subscriber will never have to use this message again. If they do, the LES will re-initialise the subscriber in a similar way to the first initialisation, with location services allowed.
Mobile Number Portability (MNP) When an AnyTimeInterrogation (ATI) or SRIforLocationServices (SRIforLCS) request is received at the HLR for an exported subscriber, the HLR will forward these requests onto the network where the subscriber resides. The Network Entity (netent) Table (see page 509) determines whether the HLR replies to ATI or SRIforLCS messages from other networks using the ALLOW_ATI and ALLOW_POS attributes.
Location Based Services and this Guide Providing Location Information to Other Entities
The ALLOW_ATI and ALLOW_POS attributes in the Network Entity (netent) Table determine whether the HLR responds to AnytimeInterrogation or SRIforLCS messages from other networks.
Subscriber Control of Service
Subscribers use USSD commands to enable or disable positioning services, as described in Positioning Services on page 643.
Subscriber Location Privacy Profile (SLPP)
A number of entries in the hlr_config Table define the Subscriber Location Privacy Profile (SLPP): LCS_CLI, ADDRESS address, GMLC_RES restriction, NOTIFY_USER notification and LCS_GMLC_ID.
Positioning Data Downloaded to the VLR
Each VLR listed in the Network Entity (netent) Table has an LCS_DOWNLOAD attribute that specifies whether the HLR should download the positioning allowed indicator (PAI) flag, the subscriber location privacy profile (SLPP) data, or both, to the VLR. LCS_DOWNLOAD in the hlr_config Table specifies whether the HLR should download the positioning allowed indicator (PAI) flag, the subscriber location privacy profile (SLPP) data, or both, to a VLR that does not have an LCS_DOWNLOAD attribute defined in the Network Entity (netent) Table.
2
Home Location Register (Linux) V1.1 Support Guide
40
Chapter 1 Overview of the HLR
Mobile Number Portability (MNP) Allowing subscribers to move from one mobile network to another, known as Mobile Number Portability (MNP), is a regulatory requirement and must be provided by UK network operators. Subscribers must be able to change networks easily and cheaply to encourage operators to compete in the areas of services, quality and prices. Because migrated subscribers are given a new SIM and IMSI by their new network, migration affects only services that depend on the subscriber’s MSISDN, which are: • incoming voice calls • incoming SMS messages • attempt to set message waiting data • requests for location information HLR Data Changes When a Subscriber Migrates on page 41 describes the effect of MNP on the HLR. Signalling for Subscribers Migrated from Vodafone to Another Network on page 41 describes incoming call signalling for subscribers who have left Vodafone. Signalling for Subscribers Migrated from Another Network to Vodafone on page 42 describes incoming call signalling for subscribers who have joined Vodafone from another network. Signalling for SMS and Message Waiting Data on page 43 describes the effect of MNP on short messages and on message waiting data, which is used, for example, by Voicemail.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
41
HLR Data Changes When a Subscriber Migrates Subscribers can either migrate to Vodafone from another network, or from Vodafone to another network. The effect of migration is shown in Table 4. Table 4. Effect of Subscriber Migration Account Move
Other Network Vodafone
Vodafone
Other Network
SIM and MSISDN
HLR Changes
• Vodafone SIM • Vodafone IMSI • Other network’s MSISDN is assigned to the Vodafone SIM
• Create a new subscriber using the MSISDN from the subscriber’s previous network (see CREATE:SUB on page 206) • MSISDNs from other networks (which appear as the calling line identity (CLI) when subscribers make calls) might be restricted to particular Vodafone HLRs • see Signalling for Subscribers Migrated from Another Network to Vodafone on page 42 for handling of an incoming call
• Other network’s SIM • Other network’s IMSI • Vodafone MSISDN
• add Vodafone MSISDN to the list of service request numbers (SRNs) (see CREATE:SRN on page 290) • add a corresponding MSISDN, which identifies the subscriber and has a 44799x prefix (see Table 5) for the Other Network, to the list of service access numbers (SANs) • the Other Network uses the Vodafone MSISDN (which appears as the calling line identity (CLI) when the subscriber makes calls) • see Signalling for Subscribers Migrated from Vodafone to Another Network on page 41 for handling of an incoming call
Table 5. UK Networks and MNP Prefix Network
Prefix
O2
447991
T-Mobile
447992
Orange
447993
Vodafone
447994
Dolphin Telecom
447995
Hutchison 3G
447996
BT MVNO (“Quad-7”)
447997
Signalling for Subscribers Migrated from Vodafone to
2
Home Location Register (Linux) V1.1 Support Guide
42
Chapter 1 Overview of the HLR
Another Network If a call is made to a subscriber who has moved account to another network, the HLR must forward the call to the subscriber’s new network. Figure 15 shows signalling for an incoming call for a subscriber who has moved account to another network. The HLR processing involved is called donor direct routing override function, or D-DROF. Figure 15. Incoming Call to Subscriber Migrated to Other Network Vodafone
Other Network
3. MSISDN not found. Compare MSISDN with SRN list, find corresponding SAN
HLR
HLR 4. Send routing information acknowledge contains intermediate routing number (IRN) = SAN = 44799x + MSISDN
2. Send routing information for MSISDN
44799x is a prefix for number portability specified by the regulatory authority. x identifies the network (see Table 5) 1. Incoming call
GMSC
6. Remove 44799x prefix
5. IRN and connect voice circuit. Vodafone has no further involvement in call
GMSC
Signalling for Subscribers Migrated from Another Network to Vodafone If a subscriber has moved to Vodafone from another network, incoming calls to that subscriber must be forced to connect to a Vodafone GMSC.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
43
Calls can be connected to the Vodafone network in one of two ways: • Like Vodafone, the Other Network performs donor DROF, as shown in Figure 15. No special processing is required in the Vodafone network other than removing the 447994 prefix that indicates a number moved to Vodafone from another network. • Unlike Vodafone, the Other Network does not perform donor DROF. The Vodafone network must perform recipient direct routing override function (R-DROF), as shown in Figure 16. Note: Although donor DROF (Figure 15) reduces signalling between networks, it places a processing burden on the network that has lost the migrated subscriber. Therefore, recipient DROF (Figure 16) is mandatory and donor DROF is optional. In the UK, only Vodafone and Orange perform donor DROF. Figure 16. Incoming Call to Subscriber Migrated to Vodafone Vodafone
Other Network
3. MSISDN has moved to Vodafone, forward SRI
4. Forward SRI
HLR
8. Send routing information for MSISDN
FMSC
signalling relay function
SRF
5. send routing information acknowledge contains intermediate routing number (IRN) = 447994 + MSISDN The prefix of the MSISDN is changed as specified by entries MNP_PFX_1 MNP_PFX_2 MNP_PFX_3 in the hlr_config Table.
2. Send routing information for MSISDN
7. Remove 447994 prefix
GMSC
6. IRN and connect voice circuit. Other Network has no further involvement in call
1. Incoming call
GMSC
Signalling for SMS and Message Waiting Data Roamed subscribers can receive messages via the Short Message Service (SMS) only if they roam to a network that has a roaming agreement with both Vodafone and the Other Network.
2
Home Location Register (Linux) V1.1 Support Guide
44
Chapter 1 Overview of the HLR
If a subscriber has moved from another network to Vodafone, send routing information (SRI) for SMS messages and set message waiting data messages are processed as normal, except for removing the roaming prefix if necessary (Figure 17). Figure 17. Incoming SMS or MWD to Subscriber Migrated to Vodafone Vodafone
Other Network
2. Remove 447994 prefix and forward SRI for SMS or set MWD to HLR
HLR
1. Incoming send routing information for SMS (SRISM) or set MWD (SRIMWD)
GMSC
3. Process SRI for SMS or set MWD in normal way
If a subscriber has moved from Vodafone to another network, the HLR must add a 44799x prefix (see Table 5) to re-route the message. Figure 18. Incoming SMS or MWD to Subscriber Migrated to Other Network Other Network
Vodafone 3. MSISDN not found. Compare MSISDN with SRN list, find corresponding SAN
HLR
2. SRI for SMS or set MWD
1. Incoming SRI for SMS or set MWD
GMSC
FMSC
HLR
4. SRI for SMS or set MWD for 44799x + SAN (MSISDN) 44799x is a prefix for number portability specified by the regulatory authority. x identifies the network (see
Signalling for Location Based Services The HLR might receive requests for location information from a GMLC.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
45
If a subscriber has moved from another network to Vodafone, AnyTimeInterrogation messages and SRIforLocationServices (SRIforLCS) messages and set message waiting data messages are processed as normal, except for removing the roaming prefix if necessary (Figure 19). Figure 19. Incoming ATI or SRIforLCS to Subscriber Migrated to Vodafone Vodafone
Other Network
2. Remove 447994 prefix and forward SRIfor for SMS or set MWD to HLR
HLR
1. Incoming ATI or SRIforLCS
GMSC
3. Process ATI or SRIforLCS in normal way
If a subscriber has moved from Vodafone to another network, the HLR must add a 44799x prefix (see Table 5) to re-route the message. Figure 20. Incoming ATI or SRIforLCS to Subscriber Migrated to Other Network Other Network
Vodafone 3. MSISDN not found. Compare MSISDN with SRN list, find corresponding SAN
HLR
2. ATI or SRIforLCS
HLR
4. ATI or SRIforLCS for 44799x + SAN (MSISDN)
1. Incoming ATI or SRIforLCS
GMSC
2
FMSC
44799x is a prefix for number portability specified by the regulatory authority. x identifies the network (see
Home Location Register (Linux) V1.1 Support Guide
46
Chapter 1 Overview of the HLR
MultiSIM The MultiSIM service allows one subscriber to have several mobile handsets, all of which are called using the same published number. For example, the subscriber can choose to receive calls via a car phone or a mobile handset in a similar way to linked subscriptions (see page 30). Unlike linked subscriptions, all data used by the MultiSIM service is stored within the HLR, which means that no signalling to other network elements is required to provide the service. Only one set of subscription data is held and is duplicated for each SIM in the MultiSIM subscription. Up to 10 SIMs can be linked in one MultiSIM subscription, and each SIM is given an identifier, called a SIM ID, which is a number from 0 to 9.
Receiving Calls
The handset that will receive calls is nominated by the subscriber by entering a USSD command (see MultiSIM Service on page 638). Outgoing calls can be made from any handset at any time. Although a particular handset will usually be used for a particular basic service (for example voice, fax or data), the HLR does not restrict which handset can be nominated to receive calls for which basic service group (BSG). The administration interface can update the nomination for a SIM for a particular BSG, for example to correct problems or investigate faults. The subscriber can interrogate the HLR using USSDs to find out both the currently nominated SIM ID, and the ID of the mobile that sent the nomination request. The response includes a list of which SIMs are nominated for which BSGs since BSGs can be allocated to different SIMs.
Published Numbers
A MultiSIM subscription has only one set of MSISDNs (one for speech, one for data and so on), each SIM does not have its own MSISDN and can be reached only when nominated to do so by the subscriber and only using the published MSISDN. Any existing subscription can be converted into a MultiSIM subscription by simply adding SIMs to it. The published number for the subscription does not change. An IMSI, and therefore a SIM, cannot belong to more than one subscription. To move a SIM from one MultiSIM subscription to another, the SIM must be removed and then added to the MultiSIM subscription.
Basic Service Groups
USSDs are used to nominate the handset that sends the USSD (called grab) or to nominate a handset other than the one sending the USSD (called grant) by including the SIM ID of the handset to nominate. The nominated handset can also be changed using the NOMINATED_SIM attribute in the UPDATE:SUB administration command (see page 215). USSD nomination changes can grab and grant a nomination to a SIM for any or all BSGs.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
47
For a description of USSD commands for MultiSIM, see MultiSIM Service on page 638.
Stolen SIMs
If a SIM is stolen, it must be removed from the subscription; the SIM cannot be barred.
Overlapping IMSI It is possible to apply an overlapping IMSI as for a normal SIM. This will apply to an individual SIM in the group, and will allow the old SIM record to be deleted once the new SIM has been used or when the REPLACE:OVERLAP administration command has been used (see page 276).
Last Caller Number
The last caller number can be identified as for a normal subscription, on top of which MultiSIM introduces data that identifies the SIM ID that the call was routed to. This helps customer care identify and trace service problems.
Tracing activity
A trace on a subscription is selected by identifying an MSISDN, which results in a trace of information for all SIMs related to that MSISDN.
VAMPIRE and MIS
In the Vodafone UK network, the HLR logs the nomination change data to the VAMPIRE interface for use by Customer Care and Service Provider Support. This is very similar to the logging currently provided by the SEP.
Administration Commands for MultiSIM The administration command below creates a MultiSIM subscription with two members. The first member already has a subscription and has an MSISDN of 077 12 345678. The second member has an IMSI of 234 15 1021000899. The following ADD:SIM command adds the second member to the first member’s subscription. Both SIMS have the same MSISDN and both can make calls. ADD:SIM,MSISDN,07712345678,234151021000899,1; The last parameter is the sim_id. The first member has a sim_id of 0, and then the next SIM can have a SIM ID of between 1and 9. If the sim_id is not specified, the next available one is used. All calls made to the MSISDN will route to the nominated SIM for the SPEECH basic service group. Different SIMS can be nominated for different basic service groups, such as SMS, FAX and DATA; for example, a subscriber might have 10 SIMS each nominated to receive different services. SIM 0 is the default and receives all calls unless the nomination for a basic service group is changed using one of the USSD commands described in MultiSIM Service on page 638.
2
Home Location Register (Linux) V1.1 Support Guide
48
Chapter 1 Overview of the HLR
Incoming Call to MultiSIM Subscription The older linked subscription services are checked before MultiSIM and therefore take precedence over MultiSIM. The HLR checks the number of SIMs in a subscription, and if this number is greater than 1, the HLR looks up the nominated IMSI and uses it in the ProvideRoamingNumber message sent to the VLR. Figure 21. Signalling for an Incoming Call SMSC
HLR
SRI (send routing information) for MSISDN
MSC/VLR
> 1 SIM, so use the nominated IMSI
PRN (provide roaming number) for nominated IMSI
Roaming number (RN) SRI result (roaming number)
Incoming SMS to a MultiSIM Subscription The diagram below shows signalling for an SMS sent to a MultiSIM subscriber. The HLR returns the IMSI and the location of the nominated SIM.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
49
Figure 22. Signalling for an Incoming SMS GMSC
HLR
SRI (send routing information) for MSISDN
VLR
> 1 SIM, so use the nominated IMSI
SRISM result (nominated IMSI)
FSM (nominated IMSI)
FSM result
Alert Service Centre for a MultiSIM Subscription For a MultiSIM subscription, the decision whether to alert service centres (such as text message centres) that a subscriber is ready to receive messages must consider which SIM is nominated. Service centres can be alerted in the following situations: • A handset is switched on and registers with a VLR, which sends a NoteSubscriberPresent/ReadyForSM message to the HLR. • A subscriber moves to a new VLR, which sends an UpdateLocation message to the HLR. • The nominated SIM is changed, either by a USSD or by an administration command. • The message waiting data (MWD) expires on the HLR (see SET:MWD on page 433). For both the NoteSubscriberPresent and UpdateLocation cases, the HLR checks whether the subscription has more than one SIM and if so, whether the IMSI in the message is the nominated IMSI. If the IMSI is part of a MultiSIM subscription and the IMSI in the message is the nominated IMSI, then the SIM is ready to receive messages and an AlertServiceCentre message is sent. If the IMSI is part of a MultiSIM subscription but is not the nominated SIM, then service centres are not alerted.
2
Home Location Register (Linux) V1.1 Support Guide
50
Chapter 1 Overview of the HLR
If the nominated SIM changes, then the HLR checks for any message waiting data for the new nominated SIM. If the SIM has message waiting data, the relevant service centres are alerted. Figure 23. Signalling for Alerting a Service Centre MSC/VLR
HLR
NoteSubscriberPresent ReadyForSM (IMSI)
Service Centre
If > 1 SIM, message waiting data exists and IMSI is the nominated IMSI Alert Service Centre (MSISDN)
UpdateLocation (IMSI) If > 1 SIM, message waiting data exists and IMSI is the nominated IMSI Alert Service Centre (MSISDN)
USSD nominate IMSI (grab or grant)
If > 1 SIM and message waiting data exists for new nominated IMSI, and new nominated IMSI is reachable Alert Service Centre (MSISDN)
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
51
PrePay Service Support The HLR interacts with the prepay system in the following cases: • Mobile Originated SMS Messages on page 51 • Mobile Terminated SMS Messages on page 53 • Mobile Terminated Calls on page 55 Whether the HLR send messages to the prepay system depends on the following attributes in the hlr_config Table: • CIC_IF_MO_SMS • CIC_IF_MT_CALL • CIC_IF_MT_SMS • SMS_REALTIME_BILLING And also on whether the subscriber has the PREPAY_IC supplementary service (see page 597).
Mobile Originated SMS Messages When a prepay subscriber sends an SMS message, the HLR must check that the subscriber has credit before allowing the SMS to be delivered. The message used to check for credit depends on three factors: • Whether the subscriber has the PREPAY_IC supplementary service • Which of the CIC_IF_MO_SMS and SMS_REALTIME_BILLING attributes the HLR has in the hlr_config Table • Whether the sendRoutingInformationforSM message contains the PAYT extension container
MO Message Submitted
2
The HLR sends an MOSMSSubmitted message to the PAM after receiving a sendRoutingInformationforSM MAP message, for a mobile originated SMS.
Home Location Register (Linux) V1.1 Support Guide
52
Chapter 1 Overview of the HLR
MOSMSSubmitted is sent only if the HLR has SMS_REALTIME_BILLING in the hlr_config Table and the SRIforSM message contains the PAYT extension. SMSC
SRIforSM
SRIforSM Res
MOSMSSubmitted
HLR
PAM MOSMSSubmittedResp
Check Incoming Call
The HLR sends a CheckIncomingCall to the PAM after receiving a sendRoutingInformationforSM MAP message, for a mobile originated SMS. CheckIncomingCall is sent only if the subscriber has the PREPAY_IC supplementary service provisioned and the HLR is configured with CIC_IF_MO_SMS in the hlr_config Table, or the HLR is configured with SMS_REALTIME_BILLING in the hlr_config Table, and the sendRoutingInformationforSM does not contain the PAYT extension container.
SMSC
SRIforSM
SRIforSM Res
CheckIncomingCall
HLR
PAM CheckIncomingCallResp
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
53
Mobile Terminated SMS Messages When a prepay subscriber is sent an SMS message, the HLR must check that the subscriber has credit before delivering the SMS, in case the subscriber is required to have airtime credit, or the SMS is to be reverse-charged. The message used to check for credit depends on three factors: • Whether the subscriber has the PREPAY_IC supplementary service • Which of the CIC_IF_MT_SMS and SMS_REALTIME_BILLING attributes the HLR has in the hlr_config Table • Whether the sendRoutingInformationforSM message contains the PAYT extension container
MT Message Submitted
The HLR sends a MTSMSSubmitted message to the PAM after receiving a sendRoutingInformationforSM MAP message, for a mobile originated SMS. MTSMSSubmitted is sent only if the HLR has SMS_REALTIME_BILLING in the hlr_config Table and the SRIforSM message contains the PAYT extension. SMS – GMSC SRIforSM
SRIforSMRes
MTSMSSubmitted
HLR
PAM MTSMSSubmittedResp
Check Incoming Call
The HLR sends a CheckIncomingCall message to the PAM after receiving a sendRoutingInformationforSM MAP message, for a mobile terminated SMS. The HLR sends the CheckIncomingCall message only if the subscriber has the PREPAY_IC supplementary service provisioned and the HLR is configured with CIC_IF_MT_SMS in the hlr_config Table, or the HLR is configured with SMS_REALTIME_BILLING in the hlr_config Table, and the sendRoutingInformationforSM message does not contain the PAYT extension container.
2
Home Location Register (Linux) V1.1 Support Guide
54
Chapter 1 Overview of the HLR
SMSC
SRIforSM
SRIforSM Res
CheckIncomingCall
HLR
PAM CheckIncomingCallResp
MT Message Delivered
The HLR sends an MTSMSDelivered message to the PAM after receiving a reportSMDeliveryStatus MAP message for a mobile terminated SMS. The HLR sends the MTSMSDelivered message only if the reportSMDelivery status reports successful delivery and debit required. The subscriber must also have the PREPAY_IC supplementary service provisioned and the HLR must be configured with SMS_REALTIME_BILLING in the hlr_config Table.
SMS – GMSC
1. ReportSMDeliveryStatus
SRIforSM Res
MTSMSDelivered
HLR
PAM MTSMSDeliveredResp
Note: At this point the SMS has already been delivered, so the HLR can no longer control whether the subscriber receives the SMS.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
55
Mobile Terminated Calls When a prepay subscriber receives a call, the HLR must check that the subscriber has credit before connecting the call, in case the subscriber is required to have airtime credit, or is barred. The HLR checks for credit by sending a CheckIncomingCall message to the PAM.
Check Incoming Call
The HLR sends a CheckIncomingCall message to the PAM after receiving a sendRoutingInformation MAP message for a mobile terminated call. The HLR sends the CheckIncomingCall message only if the subscriber has the PREPAY_IC supplementary service provisioned and the HLR is configured with CIC_IF_MT_CALL in the hlr_config Table.
SMSC
SRIforSM
SRIforSM Res
CheckIncomingCall
HLR
PAM CheckIncomingCallResp
2
Home Location Register (Linux) V1.1 Support Guide
56
Chapter 1 Overview of the HLR
Service Provider Services In addition to selling phones with its own brand, Vodafone supplies off-the-shelf phones in boxes, which work on the Vodafone network, to be sold by other organizations, known as service providers, or SPs. These boxes carry the service provider’s brand and, if a customer calls a help line for example, must appear to be a product of the service provider, not of Vodafone. To enable customers to hear network announcements and receive service specific to the service provider that supplied their telephone, the HLR can route calls to the SP’s customer care centres, IVRs and credit lines. A subscriber’s service provider is identified by the SPCODE subscriber attribute (see page 222). The HLR is involved in the following interactions between subscriber and service provider: • Routing Calls to Service Provider Bar on page 56 • Call Service Provider Using a Short Code on page 57 • USSD Signalling for Service Provider Enquiry on page 58 • Signalling for Voicemail Personalization on page 59
Routing Calls to Service Provider Bar This feature enables a service provider to re-route outgoing calls from a customer. It can be used, for example, to bar calls from contract customers who are overdue in settling their account: outgoing calls from this customer are re-routed to the service provider’s customer care division, who can encourage them to settle their account. The service provider places the bar using ISAAC. This causes the HLR to download a particular OICK value to the MSC. The OICK value causes outgoing calls to trigger an enquiry from the MSC to an IN platform that can modify the call parameters. In the Vodafone UK network, this IN platform is the SEP. This enquiry allows the call to be re-routed, to customer care for a service provider for example, as shown in Figure 24 on page 57.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
57
Figure 24. Route to Service Provider Bar Mobile Handset
MSC
SEP
HLR
outgoing call
SRI with route to SP bar (RTSPB) prefix ATI
ATI result
SRI result (SP number)
Note: The SEP could send enquiries to other network platforms, as well as the HLR, before deciding how to route the call.
Default Call Forwarding This feature allows a service provider to set default values for the three voice call forward diverts: • busy • no reply • not reachable This can be used to ensure that unanswered calls are diverted to the subscriber’s voicemail service, for example. A default voice divert is only active when there is no corresponding active divert.
Call Service Provider Using a Short Code Subscribers can call their service provider using a short code. The dialled short code is translated into the service provider’s number by a separate IN platform, which is the SEP in the Vodafone UK network. Figure 25 on page 58 shows signalling for short code dialling to a service provider.
2
Home Location Register (Linux) V1.1 Support Guide
58
Chapter 1 Overview of the HLR
Figure 25. Short Code Dialling to a Service Provider Mobile Handset
MSC
SEP
HLR
dial service provider’s short code SRI with short code prefix ATI
ATI result (service provider’s ID) SRI result (SP number)
USSD Signalling for Service Provider Enquiry Subscribers can enter a USSD code to find out the name and contact telephone number of their service provider. The USSD for service provider information is relayed to the SEP for processing, as shown in Figure 26 on page 59.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
59
Figure 26. USSD for Service Provider Information mobile handset
MSC
HLR
SEP
USSD for Service Provider Information USSD for Service Provider Information USSD for Service Provider Information
ATI for Service Provider Information
ATI result (service provider’s ID)
USSD Text
USSD Text Text
The HLR holds service provider information in the Service Provider (sp) Table (see page 532), which the SEP can use, or modify if necessary, to pass to the subscriber.
Signalling for Voicemail Personalization When a subscriber is connected to the Vodafone network, a mailbox is allocated for their voicemail and is personalised using a Vodafone message, which is played when a subscriber accesses the mailbox. For service providers other than Vodafone, the message includes the name of the service provider. The network entity that personalizes the mailbox is the MLR, but because it must personalise a voicemail box using a message for the correct service provider, and the service provider is stored in the HLR, the MLR sends an enquiry to the HLR.
2
Home Location Register (Linux) V1.1 Support Guide
60
Chapter 1 Overview of the HLR
Figure 27. Personalise Mailbox with Service Provider Message ISAAC
MXE
MLR
HLR
CREATE:MAILBOX create mailbox ATI
ATI result Personalise
Acknowledge Set diverts
Acknowledge OK
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
61
Control of Access to Premium Rate/Content The HLR can bar voice calls and SMS messages if a subscriber is not configured to access premium rate or content (such as adult content). Access control in the HLR restricts access to content from voice calls, SMS, MMS and the internet. The HLR uses the ODBOPENT bar for voice and the ODBOPENTSMS bar for SMS and MMS. ISAAC interprets voice, SMS and MMS bars as ODBOPENT. Subscribers can request that the adult content bar be removed, provided that they can prove their age.
Control by Charging Rate A subscriber can choose to block all premium rate SMS messages, and thereby ensure that they are never charged for such messages. The charging rate of an SMS message is indicated in the SRIforSM message sent from the SMSC to the HLR. This rate is looked up in the SMS Barring (smsbar) Table (page 529) to determine whether any charging bars apply; if they do, a call barred response is returned to the SMSC, and the SMS is not delivered. Barring allows SMS charging to be categorized into two levels, high and low, which correspond to bars ODBPREMSMSHI and ODBPREMSMSLO. These bars are not provisioned by default, the subscriber must ask the network operator to add them.
Control by Content The content of an SMS message is indicated in the SRIforSM message sent from the SMSC to the HLR. This content type is then looked up in the SMS Barring (smsbar) Table (see page 529) to determine whether any content bars apply. If a subscriber has an applicable content bar, a call barred response is returned to the SMSC, and the SMS is not delivered.
Control by Source and Destination Note: This barring method is applied if the HLR cannot bar according to the charging rate or the content. The source or destination of an SMS message is indicated, in the form of a short code, in the SRIforSM message sent from the SMSC to the HLR. This short code is then looked up in the SMS Barring (smsbar) Table to determine whether any content bars apply. If a subscriber has an applicable content bar, a call barred response is returned to the SMSC, and the SMS is not delivered.
2
Home Location Register (Linux) V1.1 Support Guide
62
Chapter 1 Overview of the HLR
Access Control Signalling Control is provided by signalling between the HLR and the Short Message Service Centre (SMSC). Figure 28. Barring for Mobile Terminated (MT) SMS Messages
send SMS
SMSC
SRIforSM
Content Provider
SRIforSM message contains the originating short code, which identifies the Content Provider, the content and the charging information. Content Provider short codes, content, and charging types are listed in the SMS Barring (smsbar) Table (see page 529). If any of the relevant information is missing from the SRIforSM, the HLR bars on shortcode by price or content.
HLR
If subscriber has content or premium rate bars, the HLR returns a call barred result to the SMSC, and the SMS is not delivered. A monthly report lists SMS messages that were not delivered so that the Content Provider cannot claim the charges for them.
Figure 29. Barring for Mobile Originated (MO) SMS Messages send SMS
Content Provider
SMSC
SRIforSM message containing the destination short code which identifies the Content Provider, and content and charging information.
If subscriber has content or premium rate bars, the HLR returns a call barred result to the SMSC, and the SMS is not delivered. The subscriber is then sent a class 0 SMS message containing the RESPONSE entry in the SMS Barring (smsbar) Table (see page 529).
Content Provider short codes, content, and charging types are listed in the SMS Barring (smsbar) Table (see page 529).
HLR
Informing the Subscriber that Content was Barred The subscriber is sent a class 0 SMS message containing the RESPONSE entry in the SMS Barring (smsbar) Table (see page 530).
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 1 Overview of the HLR
63
A class 0 message is displayed immediately on the subscriber’s handset, without the subscriber having to retrieve it. The SMS is not submitted to the Vodafone SMSC, it is sent directly from the HLR (via the visited MSC). If this SMS does not get through, no further attempts are made.
Limitations of Access Control Subscribers may still be able to receive adult content SMS messages from, or send them to, another network. This is inherent in the interaction between the SMSC and the HLR.
Access Control While Roaming Both mobile originated and mobile terminated SMS and MMS messages continue to be controlled while a subscriber is roaming because these messages are still controlled by the Vodafone SMSC/ MMSC.
2
Home Location Register (Linux) V1.1 Support Guide
64
Chapter 1 Overview of the HLR
Video Telephony Subscribers to the third generation (UMTS) network have the capability to make calls that use both voice and pictures, known as video telephony. Video telephony is provided by basic service BS30, which can be provided using the ADD:SERVICE administration command.
Network Requirements
Video telephony requires the following: • the subscriber has service BS30 • the VLR supports BS30 • the VLR supports application contexts: - V3_AND_ABOVE - NETWORK_LOC_UP_V3 - SUBSCRIBER_DATA_MNGT_V3 VLR support of basic services is listed under UNSUPP_BS in the [PROFILE <profile_name>] section of the Network Entity (netent) Table (see page 509). VLR support of application contexts is listed under UNSUPP_AC in the Network Entity (netent) Table.
Unsupported If a VLR is upgraded, the Network Entity (netent) Table might indicate that the VLR does not support video telephony even though it does. Application Context Learning The HLR periodically checks network entities and maintains an unsupported application context learning (UAL) list containing up to date capabilities of network entities without having to update the NETENT table. The period between updates of the UAL list is specified by the UAL_RETRY parameter in the PDS Configuration (pds_config) Table (see page 523).
Home Location Register (Linux) V1.1 Support Guide
2
65
Chapter 2
HLR Interfaces The HLR has these interfaces, illustrated in Figure 30 on page 66: • Administration centre interface, which allows subscriber data to be controlled. • Operations and Maintenance Centre interface used to report platform alarms, and allow support staff to connect to the platform to check operation and correct faults. Figure 31 on page 68 shows the alarms interface in more detail. • SIGTRAN Network interface, which handles the messages used in the GSM network to send call routing and short message routing requests, USSD commands and other events to and from other network entities. Figure 30 on page 66 shows the interface with the SIGTRAN network in more detail. • Some HLR parameters can be configured by the subscriber via USSD commands, and other interfaces provide regular off-node backups of the subscriber database, and logging of signalling events.
2
Home Location Register (Linux) V1.1 Support Guide
66
Chapter 2 HLR Interfaces
Figure 30. HLR Interfaces and Accounts Administration Centre (ADC) Number and Service Administration
IP to ISAAC admin port
HLR
ISAAC
Operations and Maintenance (O&M)
Customer Care
TCPIP
IN_VIEW
SNMP First-Line Support
SNMP agent
Alarms
MMI Second-Line Support Manage system, including network configuration
Table 6 describes the network elements connected to the HLR.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 2 HLR Interfaces
67
Table 6. Network Elements Connected to the HLR Name
Network Component
Function
ADC
Administration Centre
Manages subscriber data and connections to the HLR.
CGSN
Combined GPRS Support Node
Effectively synonymous with SGSN.
GMPC
Gateway Mobile Positioning Centre
Connection to the Internet portal to authenticate and find the position of a mobile subscriber.
GMSC
Gateway Mobile Switching Centre
Controls routing of mobile terminated calls.
IVS
IN_VIEW Server
Used by customer care and support staff in the Operations and Maintenance Centre (OMC) to view data on the HLR.
LES
Location Enabling Server
Controls privacy of subscribers using location-based services.
MCS
Missed Call Server
Runs the application supporting the missed calls SMS service, delivering text message notifications of missed calls due to being busy or not reachable or due to voicemail slamdown.
MLR
Mailbox Location Register
Manages mailbox allocation and subscriber message services.
MMSC
MultiMedia Message Centre
Manages the multimedia message service.
OMC
Operations and Maintenance Centre
Monitors the operation of the HLR.
OTA
Over The Air server
Sends special SMS messages to subscribers to change their handset settings (via the SIM).
PAM
Prepayment Account Manager
Holds and manages credit for prepay subscribers.
PCM
Prepayment Call Manager
Routes messages to the PAM that holds a particular prepay subscriber’s account.
SAP
Service Access Point
Used as a lookup to determine the MLR to which a subscriber’s voicemail mailbox is connected.
SCCP Relay
Signalling Connection Control Part Relay
Controls IMSI-based message routing to the HLR.
SDN/ ISR
SMS Distribution Node/ Intelligent SMS router
Load-balances SMS traffic between SMSCs.
SEP
Service Execution Point
Generic entity that manages network services.
SGSN
Serving GPRS Support Node
General Packet Radio Service (GPRS) network entity geographically close to the subscriber. Keeps a copy of subscriber data.
SMSC
Short Message Service Centre
Manages the short message service.
SRP
Service Relay Point
Determines on which SEP a subscriber is connected.
VLR
Visitor Location Register
GSM network entity geographically close to the subscriber. Keeps a copy of subscriber data.
2
Home Location Register (Linux) V1.1 Support Guide
68
Chapter 2 HLR Interfaces
Alarms Interfaces The HLR interfaces with an Operations and Maintenance (OMC) centre are illustrated in Figure 31 below. Figure 31. Alarms Interface
HLR SNMP feed for TeMIP
print to pds_alarms
TeMIP Operations and Maintenance (O & M) Interfaces
Support
Manage System, including network configuration
Home Location Register (Linux) V1.1 Support Guide
Set up test phones
2
Chapter 2 HLR Interfaces
69
SNMP Agent The SNMP agent provides to the upper layers of NMS information concerning the hardware, the operating system and the application. In order to achieve this, the SNMP agent has a hierarchic architecture composed of master agent, a PM (Performance Monitoring) subagent and a FM (Fault Management) subagent. The SNMP master agent is the SNMP front end that handles all the interactions with the SNMP manager. This master agent processes all the requests concerning the hardware and operating system, and forwards the PM- or FM-related ones to the PM or FM subagent respectively using the AgentX protocol. The subagents process such requests and deliver the responses back to the master agent, which in turn does the same with the originating SNMP manager. The PM subagent deals with the application layer variables, which are monitored at a higher layer in NMS. The PM subagent obtains those variables from the application by means of the Pulse interface. The FM subagent’s task is to provide NMS with the fault management information from the application. This information is obtained from the PDS application through the syslogd interface. Use the following commands to manage the SNMP master agent and subagents: Agent
Command
Arguments
SNMP Master Agent
snmpd
PM Subagent
pmsnmpx
FM Subagent
fmsnmpx
start to start the agent stop to stop the agent restart to restart the agent condrestart to restart the agent only if it is already running reload to reload the agent’s configuration files status to show the status of the agent
See the man pages for more information about these commands. For more about SNMP on the HLR, see the documents HLR SNMP Agent User’s Manual and PDS SNMP Agent Developer’s Manual.
2
Home Location Register (Linux) V1.1 Support Guide
70
Chapter 2 HLR Interfaces
Credit checking for prepay calls and SMS
Subscriber location privacy control
PAM PAM PCM
PAM PAM PAM
TCP/IP Network Interface LES
Home Location Register (Linux) V1.1 Support Guide
2
71
Chapter 3
System Architecture The HLR uses a standard hardware and software platform called the Linux VodaSCP, which has the architecture shown in Figure 32.
Figure 32. HLR Architecture HLR application
2
SIGTRAN stack
Linux
Core Packet Network
Data network
SIGTRAN network
O&M
Home Location Register (Linux) V1.1 Support Guide
72
Chapter 3 System Architecture
Software The software consists of: • the Red Hat Enterprise Linux operating system. • SIGTRAN communications software, which provides the interface to the SIGTRAN signalling network (see Chapter 8, SIGTRAN Configuration). • HLR application software and database, which provides the HLR functionality.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 3 System Architecture
73
Hardware The hardware is an HP computer system, which provides the processing power and the following network interfaces: • SIGTRAN connections to other network entities such as the VLR/ MSC and SCCP Relay. • inter-computer (Ethernet) connections to the OMC and ADC. The interfaces can be used either with Vodafone’s own ADC (ISAAC) and OMC (TeMIP via TCP/IP, or with any other compatible ADC or OMC.
2
Home Location Register (Linux) V1.1 Support Guide
74
Chapter 3 System Architecture
Directory Structure All nodes have the same directory structure. All directories are local to each node, with no shared disk space in the cluster. Figure 33. Platform Directory Structure E n trie s a re m a d e in th e in itta b file a n d s y s lo g d file to e n s u re th e a p p lic a tio n is s ta rte d a t s y s te m b o o t, a n d c o rre c t lo g g in g o p e ra tio n . v o d a fo n e
e tc
in itta b s y s lo g d .c o n f opt
pds p d s 1 _ x .x .x snm p conf m ib s s n m p d .c o n f
hom e sysconf
pds_ m anager opt
c ro n .d in it.d
v o d a fo n e
lo g ro ta te .d
pds p d s 1 x .x .x
p ro file .d udev b in d a ta
x in it.d re g is te r_ b a c k u p sdf ta b le s c u rre n t w o rk in g
e tc lib e x e c s ta te lo g m an m an s y s c o n fs c rip ts
var
ta b le s e ts lo g
te m p la te s pds p d s 1 _ x .x .x aux a v a ila b ility _ y e a r_ n o .d a t p d s _ a la rm s p d s _ a la rm s .n p d s _ s ta rtu p p d s _ s ta rtu p .n P D S .lo g P D S .lo g .n p ro c e s s _ n a m e ...
ru n p d s 1 _ x .x .x lib opt
v o d a fo n e p d s 1 _ x .x .x d a ta b a s e file s ... pds_ on sdf ta b le s re g is te r_ b a c k u p = s y m b o lic lin k
Directory Paths Defined in PDS The following paths are defined: logdir
/opt/vodafone/pds/log
cfgdir
opt/vodafone/pds/etc
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 3 System Architecture
2
75
comdir
/opt/vodafone/pds/bin
exedir
/opt/vodafone/pds/libexec
shrdir
/opt/vodafone/pds/data
statedir
/opt/vodafone/pds/state
sdfdir
/opt/vodafone/pds/data/sdf
sdmdir
/tmp
Home Location Register (Linux) V1.1 Support Guide
76
Chapter 3 System Architecture
Logical Databases Each HLR database has a logical database name (referred to as log_db_name in configuration file templates). This name identifies the database in the network consisting of multiple HLRs, and enables future DR Triad features to move the database from one HLR to another without losing its identify. Note: log_db_name is case-sensitive. You are recommended to use only uppercase characters, as the rest of the database file names are written in uppercase. In this release, each Linux HLR will handle only one logical database. In future releases, each HLR node will be able to serve/slave multiple databases in DR Triad configuration. For more information about logical databases, see Appendix D, Backing-up the HLR Database.
Database File Names The database file names are: $shrdir/ _HLRD_FILE
Fault Tolerance The following features provide the HLR’s fault tolerance:
Component Duplication
Most HLR components are duplicated within the system, so if one fails the system can continue to operate.
Cutovers
The HLR is designed to operate in a cluster in live/standby configuration. If the live HLR node should fail the standby node becomes live and take up all the load. The failed node attempts to recover automatically and become the new standby node.
Database Backups
The HLR application writes subscriber data from memory to disk at regular intervals. This ensures that, even if there is a total power loss, the HLR database will restart from a recent copy.
The HLR also writes the subscriber data into two alternating backup files that are checked for consistency. The last consistent copy is not overwritten until a new consistent copy exists. This ensures that, in the event of database corruption, a recent consistent copy will exist. Note: A manual backup facility must be set up by the system manager. See External Backup Procedure on page 589 for details.
Alarms
2
The HLR application sends an alarm to the OMC whenever any system components fail. See Chapter 7, Alarms for details of the alarms generated by the HLR.
Home Location Register (Linux) V1.1 Support Guide
78
Home Location Register (Linux) V1.1 Support Guide
Chapter 3 System Architecture
2
79
Chapter 4
Support Interfaces This chapter describes the HLR User Interface, including how to: • connect to an HLR node. See The Remote Engineer Interface below. • log on to and use Remote Engineer and pds_manager. See The Remote Engineer Interface on page 80 and The pds_manager Account on page 83.
Connecting to the HLR You can connect to the HLR in two ways: • The Remote Engineer web page (see page 80) gives first-line support staff access to a restricted menu of facilities. • The pds_manager account (see page 83) gives second-line support staff full operating-system access to the HLR’s commands, data and diagnostic utilities. It also gives access to the Administration interface for users managing the HLR database.
2
Home Location Register (Linux) V1.1 Support Guide
80
Chapter 4 Support Interfaces
The Remote Engineer Interface The Remote Engineer interface consists of a set of web pages that provides a menu of options which lets first-line support staff control the HLR and obtain status information about it.
Creating Remote Engineer Logins: User Manager Remote Engineer logins are created using the User Manager web page. This page allows users to create logins/passwords for the Remote Engineer web page, and assign roles to the logins. The role assigned determines what tasks the Remote Engineer user can perform. To log on to the User Manager web site: 1. Enter the following URL in your web browser: http://platform.vfl.vodafone:8080/user-manager/ Replace platform with the name of the platform. 2. Enter your login and password, and then click /RJ,Q. The main menu is displayed (see Figure 34). Figure 34. User Manager Main Menu
Click $GG8VHU to add new Remote Engineer users.
Logging On to the Remote Engineer Web Site To do this: 1. Enter the following URL in your web browser:
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 4 Support Interfaces
81
http://platform .vfl.vodafone:8080/remote-eng/do/ systemOverview Replace platform with the name of the platform. 2. Enter your login and password, and then click /RJ,Q. The main menu is displayed (see Figure 35). Note: The items that appear on the main menu depend on the role that has been assigned to the login in User Manager. The page title displays the name of the IN node you are managing. To manage a different node on the same platform, select it in the dropdown menu at the top of the page. Figure 35. Remote Engineer Main Menu
Logging Off from Remote Engineer To log off, click /RJ2XW in the banner at the top of the page.
2
Home Location Register (Linux) V1.1 Support Guide
82
Chapter 4 Support Interfaces
Figure 36. Logging out of Remote Engineer
Using the Remote Engineer Menu The Main Menu has two main sections: • System details Allows you to view aspects of the system (for example, show processes) • Actions Allows you to manage the system (for example, restart the software) The options are summarised in Table 7. Table 7. Remote Engineer Main Menu Main Menu Option
Function
6\VWHPGHWDLOV 3URFHVVHV
Display the processes running on the system, including CPU and memory usage. Allows you to filter the processes displayed. See Showing HLR Processes.
+DUGZDUH6RIWZDUH 9HUVLRQV
Display details of the hardware and system software, including installation dates.
,QVWDOO+LVWRU\
View a list of all software packages installed, and when they were installed.
1RGH6WDWLVWLFV
Display graphs of CPU utilisation, network I/O, block device I/O, memory allocation, and disk utilization.
$YDLODELOLW\5HSRUWV
Display statistics on downtime and outages.
7DEOH9LHZ
Displays the contents of the configuration tables described in Chapter 24, Table Maintenance.
$FWLRQV 5HVWDUW3'6
Restart the PDS software.
5XQGEFKHFN
Run the dbcheck utility.
5XQGEYLHZ
Run the dbview utility.
5XQVUQYLHZ
Run the srnview utility.
&UHDWH6,*75$16')V
Create SIGTRAN Screen Definition Files. See Appendix A, Using PULSE.
&UHDWH1HWZRUN(QWLW\ 6')V
Create Network Entity Screen Definition Files. Appendix A, Using PULSE.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 4 Support Interfaces
83
The pds_manager Account The pds_manager account provides direct access to the HLR, allowing you to: • use diagnostic utilities such as PULSE • examine data files • access the Administration and Table Maintenance interfaces • check the traffic between the HLR and the SIGTRAN network. Access to the pds_manager account may be controlled by local operating procedures.
Logging On to pds_manager To log on the pds_manager: 1. Enter the following command: ssh pds_manager@nodename 2. At the Password: prompt, enter the pds_manager account password. The system prompt is displayed. If the banner shows anything other than S/W RELEASE VNNNN, report to the next line of support that the platform software is not an approved release.
Logging Off from pds_manager To log off, enter exit
Accessing the Administration Interface For how to access the administration interface from the pds_manager account, see Accessing the Administration Interface on page 176.
2
Home Location Register (Linux) V1.1 Support Guide
84
Home Location Register (Linux) V1.1 Support Guide
Chapter 4 Support Interfaces
2
85
Chapter 5
Identifying Problems This chapter describes how to deal with problems on the HLR, including how to: • identify the problem, and the steps you should take to investigate and fix it. See below. • deal with common problems. See page 87. • check event log files. See page 95. Use this chapter in conjunction with the following chapters in this guide: • Chapter 6, Using Support Interfaces, describes all the procedures and commands you may need to use. • Chapter 7, Alarms, describes every critical and major HLR alarm.
Identifying and Investigating Problems Problems with the HLR may be indicated by: • HLR alarms raised on TeMIP. Alarms indicate specific problems on specific HLRs. If an alarm is shown, find the description of the alarm in Chapter 7, Alarms and follow the instructions given there. Flooding of TeMIP by alarms is described on page 94. • Complaints from: - Customers connected to a specific HLR about interruptions to service. - Administration staff that they cannot access the HLR interface. If complaints are received about interruptions to services or access to the HLR, follow the procedure in Figure 37 on page 86.
2
Home Location Register (Linux) V1.1 Support Guide
86
Chapter 5 Identifying Problems
Figure 37. First-line Problem Investigation Procedure START
Make test calls to check if the HLR is providing any service to the network. See page 99.
Do all test calls succeed?
NO
Check the status of HLR’s connections to the SIGTRAN network. See page 114
YES
All network connections OK?
NO
Identify and fix the cause of any network problems. See page 91
NO
Restart the HLR as required. See page 115
YES Check the status of the HLR software processes. See page 100
Are all processes OK?
YES
Is network service affected?
YES
Escalate the problem to second-line support. See page xviii
NO If the mobile equipment is not blacklisted, report the problem to second-line support.
Home Location Register (Linux) V1.1 Support Guide
STOP
2
Chapter 5 Identifying Problems
87
Possible Problems This section describes possible problems and how to deal with them. It assumes that you have access to the pds_manager account. The problems covered are: • Software Start-up Failure on page 88 • Computer Failure on page 91 • Data Network Communication Failure on page 91 • SIGTRAN Network Connection Failure on page 91 • Database Corruption on page 93 • Alarm Flooding on page 94.
2
Home Location Register (Linux) V1.1 Support Guide
88
Chapter 5 Identifying Problems
Software Start-up Failure Software start-up failure must be dealt with by second-line support. If the HLR application fails to start correctly: 1. Check that the node has not run out of disk space. See below. 2. Examine the start-up log files to find out more about the source of the problem. See page 89. 3. Check that the node’s resources are not exhausted.
Lack of Disk Space When the HLR restarts it creates a log file for each process in the / opt/vodafone/pds/log/aux directory. If the disk is full, then the HLR processes will not be able to start. Check the amount of disk space by using the command df An example output from this command is shown below: Filesystem
1K-blocks
Used
Availabl e
Use%
Mounted on
/dev/mapper/ rootvglv_root
20642428
521280
19072572
3%
/
/dev/cciss/ c0d0p1
101086
22757
73110
24%
/boot
none
8126960
441576
7685384
6%
/dev/shm
/dev/mapper/ rootvg-lv_vf
20642428
269048
19324804
2%
/opt/ vodafone
/dev/mapper/ rootvg-lv_tmp
4128448
41652
3877084
2%
/tmp
/dev/mapper/ rootvg-lv_usr
5160576
1650552
3247880
34%
/usr
/dev/mapper/ rootvg-lv_var
4128448
640668
3278068
17%
/var
To view more detail about the file usage on each disk, use the following command: du -a|more
aux log files
The disk used by the aux log is mounted on /var. If this disk is full or nearly full it is necessary to purge the aux files using the command:
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 5 Identifying Problems
89
aux_purge -k 3 This retains the aux files for the last three startup instances. Note that aux files are purged automatically each night, so if there are excessive files, there must be an underlying fault which will require escalating to the next level of support.
Core dump files
The location and naming convention for core dump files is in: /proc/sys/kernel/core_pattern The default setting is: /var/lib/cores.in/%h.%p-%e.core Where %h = host name, %p = process name, %e is process id. The daemon corewatchd processes the core dump files when they are created. The daemon configuration is in: /etc/sysconfig/corewatchd The daemon calls the Perl script /usr/libexec/corewatch/ process_core.pl, which zips the core dump file and puts it in /var/ lib/cores.out/. Therefore, with the corewatch service running, you should never see a core dump file in cores.in. Note: While a process has a core dump, no new dumps will be created. When you have finished analysing the core dump file, remember to remove it.
Start-Up Log Files Whenever the HLR is restarted, each PDS process writes output to the /opt/vodafone/pds/log/pds_startup file through the system logger (syslog). If you have software startup problems, examine this file for the cause of the problem. To monitor system startup in real time, enter the following command: tail -f /opt/vodafone/pds/log/pds_startup This prints startup information live to the terminal. Press CTRL+C to stop the feed. The tail command starts by printing the last 10 or so lines followed by the live feed. If you want to view more history to start with, add -n number_of_lines to the tail command as follows: tail -f -n 1000 /opt/vodafone/pds/log/pds_startup
2
Home Location Register (Linux) V1.1 Support Guide
90
Chapter 5 Identifying Problems
The startup file is rotated daily. The previous files are called pds_startup.1 (from yesterday), pds_startup.2 (the day before), and so on up to pds_startup.5 (although the limit is configurable).To analyse these files, use a text editor.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 5 Identifying Problems
91
Computer Failure If an HLR node fails, you cannot log on to it. If the live node fails, an automatic cutover will take place. See page 104. Escalate the problem to the relevant support team. The HLR application starts automatically when the node is restarted.
Data Network Communication Failure Data network communication failures are caused by problems with: • the HLR’s local Ethernet • the communication path to the ADC and OMC beyond the local Ethernet. These could have one or more of the following effects: • If the link to the OMC fails, no HLR alarms are received or displayed by the OMC. The first sign of network problems may be customer complaints. • If the link to the ADC fails, no subscriber administration operations can take place. (If ISAAC is in use, this causes the ISAAC queue to stall.) HLRs have a dual Ethernet, so service can continue unless both Ethernets fail (although failure on one Ethernet might disrupt traffic on the other one). Any network communication failures must be fixed urgently. Escalate the problem to your network support department.
SIGTRAN Network Connection Failure The HLR’s SIGTRAN connections can fail in several ways. These include: • Interface Card Failure on page 92 • External CPN Failure Faults in the CPN are beyond the scope of this document. See your local operating procedures and documentation for more information.
2
Home Location Register (Linux) V1.1 Support Guide
92
Chapter 5 Identifying Problems
Interface Card Failure Interface cards provide connections to the CPN. Each card has physical ports, which are handled by SIGTRAN as follows: • Each communication port is connected to the red or blue CPN network. • Each M3UA association is mapped to either the red or blue CPN. Each remote endpoint is reachable through both the red and blue networks, so service should not be affected, although traffic on the remaining association will increase. Symptoms of interface card problems are: • M3UA associations being shown as down. See Showing M3UA Association on page 106 for more details on checking M3UA availability. • If test calls are unsuccessful, check the status of all ports on the node (see Showing M3UA Association on page 106).
Investigation Procedure pds_ manager
Use PULSE to check the status of the HLR’s SIGTRAN network connections and the card associated with each link. If the port is not operating correctly, the fault is probably in the interface card or CPN. If an interface card is not operating normally, escalate the problem to the department responsible for maintaining HLR hardware. When a port is returned to service: • Several SIGTRAN event alarms (A3, or Minor) may be shown (if events have been enabled). • The M3UA association is shown as established. See Showing M3UA Association on page 106 for how to check M3UA availability.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 5 Identifying Problems
93
Database Corruption Database corruption may cause one or more alarms, indicating specific areas of corruption and/or consistency check failures (see Chapter 7, Alarms). Escalate these alarms to third-line support. If the database cannot be fixed, it will have to be recovered from the most recent backup copy (see page 118). See Appendix D, Backing-up the HLR Database for information on database securing and the HLR’s backup mechanisms.
Removing Disks
2
The HLR’s disks contain information vital to network security. If, following a major disk failure, the database cannot be restored, it must be copied from backup to a new disk. The disks must never be taken off-site from the HLR installation. Any failed disks must be physically destroyed on-site using the local procedures for sensitive media.
Home Location Register (Linux) V1.1 Support Guide
94
Chapter 5 Identifying Problems
Alarm Flooding Alarms that occur frequently and repeatedly can fill (flood) the TeMIP display making it difficult for operators to see other alarms. Alarms must be dealt with from the TeMIP user interface. Alarms that flood TeMIP should be reported rather than escalated. Alarms should be escalated rather than reported if: • they are database corruption alarms • hundreds of SIGTRAN-related alarms occur in each hour.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 5 Identifying Problems
95
Event Log Files An event is a message exchanged by the HLR across its interface to: • the SIGTRAN network • the ADC (normally ISAAC). The OMCS process logs these events in a series of binary files in the /var/log/pds directory. The current log file is named PDS.log, and old log files are named PDS.log.log_file_no. The log file number is incremented each time a new log is written. For example, PDS.log, PDS.log.1, PDS.log.2 and so on. The maximum value of log_file_no is configurable (default = 9): once this maximum is reached, the oldest file is overwritten. Log files can be rotated manually using the pds rotate command: see the relevant man page for more information. See Appendix K, Event Log Files for examples of how to interpret event log files.
Viewing Event Log Files To access the event log files you must first log in to the HLR using pds_manager. See Chapter 4, Support Interfaces for details of how to do this. Event log files are written in binary format. Therefore, to view a log file, or create a text version of it, you must use the logview utility (see Using logview to examine log files below). You can use logview in real time, to view events as they are being logged, or you can use it to examine historical log files.
Using logview in real time
To view start the display of logs as they are being written, enter: logview -n nodename where nodename is the name of the platform. To end the display, enter CTRL+c.
2
Home Location Register (Linux) V1.1 Support Guide
96
Chapter 5 Identifying Problems
An example of the logs displayed is:
Using logview to examine log files
You can view the log file directly, or create a text version of it. To view the file, enter: logview log_file | less where log_file is the full path and file name of the file you want to view. Use the arrow keys to navigate through the document, and use q to quit. Create a text version of a log file using the command: logview log_file -o output • output is the name of a text file. • log_file is the name of the log file that you want to create a text version of. You can now view the text copy of the log file using a text editor or print it to a printer. Full options are available in the logview man pages. To view the current log file, you must first force the OMCS process to create a new current log file. To do this, use the following command: pds rotate This causes the OMCS process to rotate its backup log files, and rename the current log file to PDS.log.1.
Home Location Register (Linux) V1.1 Support Guide
2
97
Chapter 6
Using Support Interfaces This chapter describes procedures you use to check that the HLR is working properly. For more information about how to diagnose problems with the HLR and when to use these procedures, see Chapter 5, Identifying Problems.
Problem Solving Procedures The following information is provided for each problem solving procedure: • The purpose of the procedure • Availability (if applicable) - on which node(s) the procedure can be used • Procedure - what to do • Results - the expected results of the procedure. The procedures are grouped into the following sections: • Checking HLR Status on page 98. • Controlling the HLR on page 114. • Checking and Managing the HLR on page 120.
When to Use PULSE Procedures in this section use Remote Engineer or the pds_manager account, but you can also use the PULSE utility to obtain information about the traffic between the HLR and the SIGTRAN network. See Appendix A, Using PULSE for details.
When to Use Remote Engineer Remote Engineer is a web-based, password-controlled monitoring utility. It provides limited access to the platform, and so avoids the risk of adversely affecting network services. Remote Engineer also provides quick, point-and-click access to many common support tasks.
2
Home Location Register (Linux) V1.1 Support Guide
98
Chapter 6 Using Support Interfaces
Checking HLR Status Use the following procedures to determine the status of the HLR. • Making IncomingTest Calls. Is the HLR providing any service to the network? See page 99. • Showing HLR Processes. Check that the HLR application is running correctly. See page 100. • Showing M3UA Association. Check the HLR’s SIGTRAN associations. See page 106 and Using PULSE on page 569. • Controlling the HLR. Check the HLR’s remote destinations. See page 114 and Using PULSE on page 569.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
99
Making IncomingTest Calls Incoming test calls let you check the HLR’s network service by using the communications path to and from the HLR, and its basic functionality. Note: Outgoing calls are not effective tests of the GSM HLR. Switching a test mobile off and on and then making a call does not necessarily involve any communication with the HLR. The test SIM may still be registered on the VLR even when the mobile phone is switched off. An outgoing test call may succeed even if the HLR has failed. To make incoming test calls, you need: • a GSM mobile phone, containing a test SIM with an IMSI that is connected on this HLR. Dial *#101# to make sure that the test SIM is on the correct HLR. • another phone (mobile or fixed) to make the test call.
Procedure Repeat the procedure at least ten times. 1. Switch on the mobile phone containing the test SIM. 2. Using the other phone, call the test SIM’s number. If the call connection works, the mobile phone with the test SIM will ring.
Results After making test calls, take action as follows: • If all the test calls fail, the HLR is not providing any service to the network. Immediately check the status of the HLR’s connections to the SIGTRAN network. See Showing M3UA Association on page 106. • If some of the calls fail, the HLR is still working but some subscribers may be experiencing interruptions to or loss of service. Check the status of the HLR’s connections to the SIGTRAN network. See Showing M3UA Association on page 106. • If all test calls succeed, the HLR is servicing the network. If you are investigating a problem, report that test calls succeeded to second-line support.
2
Home Location Register (Linux) V1.1 Support Guide
100
Chapter 6 Using Support Interfaces
Showing HLR Processes Certain processes must be running on the HLR for it to work properly. Use this procedure to show the HLR processes running on an HLR node and check that they are all present. Both live and standby nodes run the same processes, so it is not possible to distinguish between live and standby nodes by listing processes. See Checking for the Live Node on page 121 for how to distinguish between nodes.
Availability Use on either a live or standby node.
Results A list of HLR processes running on the node is displayed: Figure 38 on page 101 shows an example of the ss pds command. Figure 39 on page 102 shows an example of displaying processes using the Remote Engineer web page. You can filter the processes in the display by command name. You can also specify how often the display is refreshed. If processes are consistently showing 75% or greater CPU usage, there may be a system problem.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
101
Figure 38. Extract from ss pds command output
The columns in the output are as follows: • PID: Process ID, unique for each process. • PGID: Process Group ID. The same PGID will be used for MGTA and all its children (1462 in the above example). Another one is used for pds_boot, pds_i_boot and the alarm server process (2690 in the above example). • STAT is process status. See the man page for ps for the meaning of each character. • COMMAND is the name of the executable. • STARTED is the date and time when started. If started on the current day, only the time is displayed. • %CPU and %MEM are the percentages of resource usage for CPU and physical memory. • VSZ, SZ and RSS are different measures of memory utilization.See the man page for ps for the exact meaning. • # is the incarnation number assigned by pds_i_boot.
Incarnation number
2
Each time pds_i_boot is started it picks a new incarnation number based on the contents of the pds/log/aux directory. If the directory is empty, it will start with "1".
Home Location Register (Linux) V1.1 Support Guide
102
Chapter 6 Using Support Interfaces
When pds_i_boot starts other processes, it uses this number for each process. Each time it restarts the processes, it increments the number. In the example, pds_i_boot was started with 21 and has restarted the other processes several times as can be seen by the number "47". If, however, the child processes restart very quickly, pds_i_boot will only increment the number three times and then reuse the number until the system has run for at least 10 seconds without restart. When you examine the contents of pds/log/pds_startup, each process displays its incarnation number in brackets, for example: ... MGTA(47) ...... Figure 39. Remote Engineer Show Processes on Node
If the HLR is working properly, the processes shown in Table 8 will be running. If any of these processes are not running, take the action indicated.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
103
Table 8. Processes on a Stable HLR Software Component HLR
The I/O count for the pds_i_hlra processes should increase over a few seconds.
Action Required if Any Processes are Missing If any processes are missing, the HLR has failed.
• The two pds boot processes ensure that the platform restarts after a shutdown, or power outage. • The alarm server process handles the generation of platform alarms for all other processes. • The mgta process monitors processes, to detect failures. If a process fails, MGTA starts a secure to disk and stops all processes, which are subsequently restarted by pds boot. • The omcs process handles logging for all processes. • The s7mp process handles configuration and reconfiguration of the SIGTRAN stack. • The hssp process is the SIGTRAN stack implementation. • The mp (maintenance) process backs up the HLR database to disk and verifies the backup. • The hlrd process provides the database functionality. • The hlra process provides the HLR application functionality. • The adm process provides the administration interface. • The two snmp processes supply fault and performance metrics via SNMP to a suitable off node client. • The tcpip process handles TCPIP client connections to other systems like the Location Enabling Server (LES) and also inter-HLR connectivity used for database synchronization. Note: The Pid should remain the same each time the display is checked. If it does not, the process is unstable, and further investigation should be carried out.
2
Home Location Register (Linux) V1.1 Support Guide
104
Chapter 6 Using Support Interfaces
Automatic Cutovers (Live Node) If any fatal event occurs or any HLR process fails on the live node: 1. The standby node automatically takes over as the new live node. 2. The failed node restarts automatically and becomes the new standby node. Figure 40 on page 105 shows the sequence of events during a cutover. After a cutover, check that: 1. The appropriate processes are running on both the live and standby nodes (see page 100). 2. Any administrative interfaces with other systems (for example: the ISAAC queue or interface to the X.25 administration manager (XAM), which maps X.25 request packets to HLR administration commands) are redirected to the new live node. See your local operating procedures for information about how to do this. If the automatic cutover fails, manually cutover the HLR to activate the standby node. See page 116. Note: If the HLR fails to start successfully on the standby node, the original live node attempts to become the live node again when it recovers. If the HLR still fails to start correctly, see Software Start-up Failure on page 88 for more information on how to diagnose the fault.
DBSYNC
The live and standby node have no shared disk. The database is synchronized from live to standby on a regular basis. In most cutover cases, the live node will send the last database updates to the standby node before shutting down. In some failure cases (particularly failure of the live database process), the standby node will go live without the latest changes. In most cases this will be no more than one second of data changes lost.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
105
Automatic Restarts (Standby Nodes) The HLR automatically restarts for any fatal reasons, such as an internal software error or a process dying unexpectedly. Note: A restart on the live node triggers an automatic cutover, causing the sequence of events described on page 104. The restart is handled by the pds_i_boot process, which performs system housekeeping and restarts the HLR. Figure 40 on page 105 shows the sequence of events during an automatic restart (of a standby node). Figure 40. Sequence of Events during an Automatic Restart of a Standby Node NODE A (Standby)
OMC Alarms
HLR processes start to disappear
600 Process fail (NODE A)
Time
No HLR processes present except pds_boot
Up to 15 minutes (to allow any failed HLR process to dump)
608 Node going live
All HLR standby processes present
(NODE A) 30 secs
601 Startup complete (NODE A) Note: Alarm 601 does not appear on the standby node
2
Home Location Register (Linux) V1.1 Support Guide
106
Chapter 6 Using Support Interfaces
Showing M3UA Association Use this procedure to show the status of M3UA associations. The procedure uses PULSE (see Appendix A, Using PULSE). You navigate through the PULSE screens by selecting the letter corresponding to the moption you require. In this procedure, x,y means select the x option from the PULSE main menu, followed by the y option. The procedure differs according to whether the HLR is connected in a peer-to-peer (IPSP) mode, or through a signalling gateway. The meanings of the State columns in the displays are given in List of possible States in IPSP mode and List of possible States in Signalling Gateway mode.
Peer-to-Peer (IPSP) Mode First check that the point code is accessible. Start PULSE and select d,j:
If the point code is accessible, then it is possible for the HLR to signal to the remote PC. This is not the same as having all SIGTRAN links available.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
107
To check if all SIGTRAN links are available for IPSP to IPSP (peer-to-peer mode), start PULSE and navigate to the association states by selecting d,g:
For signalling between the HLR and MSC, at least one connection must have the connection state ESTABLISHED, and both the local and remote ASP states must be ACTIVE. The point codes correspond to the remote entity. In this case there are two connections to point code 108. Check the IPSP M3UA statistics by selecting f,a:
2
Home Location Register (Linux) V1.1 Support Guide
108
Chapter 6 Using Support Interfaces
Choose the letter of the PC you wish to view. A normal Ericsson MSC should have two ASPs with one connection to each:
Option a shows the first M3UA connection. The connection’s state mirrors that shown on the Connections PULSE screen, and should be ESTABLISHED. The Last reset shows the time and date the connection was created. No PDUs sent/recd and No Bytes sent/recd should be seen to increase every 5 seconds if signalling is being exchanged on this connection. Note that, in overload conditions, the frequency of statistics gathering decreases in order to free CPU for the application.
List of possible States in IPSP mode
Table 9. Point Code States ACCESSIBLE
Point Code is accessible
CONGESTED
Point Code is accessible but congested
INACCESSIBLE
Point Code is not accessible
Table 10. Lcl ASP States DOWN
Local ASP down
INACTIVE
Local ASP inactive
ACTIVE
Local ASP active
PENDING
Local ASP pending
INSUF RES AC
Insufficient resource
INVALID
Internal software error
ALT ASP ACTIVE
Alternative ASP active
FAILURE
Local ASP failed
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
109
Table 11. Connection States DOWN
Connection down
BEING ESTABLISH
Connection being established
ESTABLISHED
Connection established
CONG LEVEL 1
Connection in congestion, level 1
CONG LEVEL 2
Connection in congestion, level 2
CONG LEVEL 3
Connection in congestion, level 3
RESTARTED
Connection restarted at remote end
INV STATE
Internal software error. Requires platform restart. Escalate to Second Line Support.
Table 12. State UPD Types API IND
Last activity was a management API
INVALID
Connection down
STATS REQ
Last activity was a statistics request
integer
These values are incremented by SIGTRAN events
Table 13. Rem ASP States
2
ASP DELETED
ASP deleted (not configured)
ADD REM ASP REQ
Add remote ASP requested
REM ASP CREATED
Remote ASP created
REM AS CREATED
Remote AS created
WAIT FOR ADD TO AS
Waiting for add ASP to AS response from stack
ADD ASP TO AS REQ
Add ASP to AS requested
SET EXCHG MODE REQ
Set exchange mode requested
CONF OPTIONAL PARAM REQ
Configure optional parameters requested
ADD RC TO AS REQ
Add routing context to local AS requested
CONNECT REQUESTED
Connect requested to remote ASP
WAIT FOR CONNECT
Waiting for connection up
ASP UP REQUESTED
Send ASPUP requested
ASP UP SENT
ASPUP sent
Home Location Register (Linux) V1.1 Support Guide
110
Chapter 6 Using Support Interfaces
Table 13. Rem ASP States WAIT FOR REG
Wait for application registration
WAIT FOR REG IN ASPIA
Wait for application registration in ASPIA state
ASPDN REC
ASPDN received
ASPAC REQUESTED
Send ASPAC requested
WAIT ASPAC ERROR WAIT ASPUP
Wait for ASPAC to be received
ASPAC SENT
ASPAC sent
ASP ACTIVE
Remote ASP active
ASPIA REC
ASPIA received
ASPIA REQUESTED
Send ASPIA requested
ASPIA SENT
ASPIA sent
DOWN REQUESTED
Send Connection Down requested
DOWN SENT
Connection Down sent
DISC REQUESTED
Send Disconnect requested
DISC SENT
Disconnect sent
WAIT CFG AS RESP
Wait for configure AS response
RMV ASP FROM AS REQ
Remove remote ASP from remote AS request
DEL REM ASP REQ
Delet remote ASP requested
WAIT DELETE ERR
Internal software error. Requires platform restart. Escalate to Second Line Support.
WAIT FOR ASPIA ERR WAIT ASPUP ERROR1 WAIT ASPUP ERROR2 WAIT FOR CONN ERR
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
111
Signalling Gateway Mode Start PULSE and navigate to the association states ASP - SG by selecting d,i:
The signalling gateway ID matches the IDs given in the hsscfg file. There must be at least one connection to a signalling gateway in order to allow any PCs defined on that gateway to work. View M3UA statistics via the signalling gateway by selecting d,h:
2
Home Location Register (Linux) V1.1 Support Guide
112
Chapter 6 Using Support Interfaces
Select the page of interest, for example, a:
☞
Further screenshot tbs when signalling gateways are working??? Check with Will.
List of possible States in Signalling Gateway mode
In addition to the following table, Table 9, Table 10, Table 11 and Table 12 also apply to Signalling Gateway mode. Table 14. Rem SGP States DEL REM SGP REQ
Selete remote SGP request
SGP DELETED
Remote SGP deleted
ADD REM SGP REQ
Add remote SGP request
REM SGP CREATED
Remote SGP created
REM SG CREATED
Remote SG created
WAIT FOR ADD TO SG
Waiting for ADD remote SGP to remote SG response
ADD SGP TO SG REQ
Add remote SGP to remote SG request
CONF OPTIONAL PARAM REQ
Configure optional parameters request
ADD RC TO AS REQ
Add routing context to local AS request
CONNECT REQUESTED
Send Connect requested
WAIT FOR CONNECT
Waiting for connect
ASP UP REQUESTED
Send ASPUP requested
ASP UP SENT
ASPUP sent
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
113
Table 14. Rem SGP States WAIT FOR REG
Wait for application registration
ASPAC REQUESTED
Send ASPAC requested
ASPDN REC
ASPDN received
ASPAC SENT
ASPAC sent
ASP ACTIVE
ASP active
ASPIA REQUESTED
Send ASPIA requested
ASPIA SENT
ASPIA sent
ASP DOWN REQUESTED
Send ASPDN requested
ASP DOWN SENT
ASPDN sent
DISCONNECT REQUESTED
Send Disconnect requested
DISCONNECT SENT
Disconnect sent
WAIT FOR CFG SG RESP
Waiting for Configure SG response
RMV SGP FROM SG REQ
Send Remove remote SGP from remote SG request
WAIT FOR CONNECT ERROR
Internal software error. Requires platform restart. Escalate to Second Line Support.
WAIT FOR L_ASPUP ERROR WAIT FOR L_ASPAC ERROR
2
Home Location Register (Linux) V1.1 Support Guide
114
Chapter 6 Using Support Interfaces
Controlling the HLR Use the following procedures to control the HLR. • Restarting the HLR Application. Restart the HLR processes that make up the application. See page 115. • Cutting-over the HLR. Cutover the HLR from the live to the standby side. See page 116. pds_manager account users can also use the following procedures: • Stopping the HLR Application. Stop the HLR processes. See page 117. • Restoring the HLR Database. Recover the database from a backup. See page 118.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
115
Restarting the HLR Application Restart the HLR application if any required HLR processes are not running (see Table 8 on page 103). The restart: 1. Stops any PDS processes currently running. 2. Starts the alarm server and MGTA process. The MGTA process then starts all the other pds_i_xxx processes listed in Table 8 on page 103.
Availability Use this procedure on any node. Restarting the HLR application on the live node causes an automatic cutover (see page 104).
Results When the restart is complete, Alarm 2601: Node Out of Live Service CEASE should be displayed, and the correct PDS processes should be running. Check this using Showing HLR Processes on page 100. If the 6WDUWXSFRPSOHWHalarm is displayed, there must subsequently be a /RJLFDOGDWDEDVHQDPHFKDQJLQJVWDWHWR$&7,9( alarm, to indicate at least one logical database has started successfully. If the alarm is not displayed, there may not be any databases defined in the PDS_DEFS table. If the alarm indicates a state change to INACTIVE, the database has not started successfully.
☞
2
what are the equivalent Linux alarms in above para??
Home Location Register (Linux) V1.1 Support Guide
116
Chapter 6 Using Support Interfaces
Cutting-over the HLR Cutover the HLR from the live node to the standby node: • if an automatic cutover (see page 105) has failed. • as required. For example as part of a software upgrade procedure, or if restoring the database from a backup copy.
Availability Use this procedure on the live node. Note: Check that the HLR on the standby node is working properly (see page 100 and page 106) before you attempt to cutover to it.
Results The cutover should start the sequence of events shown in Figure 40 on page 105. After a cutover: 1. Check that the appropriate processes are running on both the live and standby nodes. See Showing HLR Processes on page 100. 2. Ensure that any administrative interfaces to or from other systems (for example: the ISAAC queue or interface to the X.25 administration manager (XAM), which maps X.25 request packets to HLR administration commands) are redirected to the new live node. See your local operating procedures. 3. If the 601 Startup complete alarm is displayed, there must subsequently be a 2425 Logical database name changing state to ACTIVE alarm, to indicate at least one logical database has started successfully. If the alarm is not displayed, there may not be any databases defined in the PDS_DEFS table. If the alarm indicates a state change to INACTIVE, the database has not started successfully. Note: If the HLR fails to start successfully on the standby node, the original live node attempts to become the live node again when it recovers. If the HLR still fails to start correctly, see Software Start-up Failure on page 88 for more information on how to diagnose the fault.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
117
Stopping the HLR Application You should stop the HLR application if there are severe system problems. This procedure stops the HLR application on a node without immediately restarting it.
Availability Use this procedure on any node. Stopping the HLR on the live node triggers an automatic cutover if the standby node is running correctly, (see page 104).
Procedure Remote Engineer You cannot stop the HLR processes from the Remote Engineer web page. If you want to restart the HLR application, use the procedure described on page 115. If you want to stop the HLR application without restarting it, escalate the problem to second-line support.
pds_manager
1. Enter the commands: pds stop
Results All HLR processes on the node will stop. Check this using Showing HLR Processes on page 100: the MGTA process and all its children should not be listed, although the pds_boot, pds_i_boot, and some other processes may still be shown.
2
Home Location Register (Linux) V1.1 Support Guide
118
Chapter 6 Using Support Interfaces
Restoring the HLR Database This procedure restores the HLR database from the most recent backup copy. If no backup copy exists, or if the backup copies are also corrupted, a previous version of the database must be restored, either from the register_backup_dir directory, or from external backups. See Appendix D, Backing-up the HLR Database for more information. Note: Any changes made to HLR subscriber data since the backup copy was created are lost when the database is restored: • Changes made because of network activity (such as subscriber controlled supplementary services), are permanently lost. • The administration centre (the ISAAC system in Vodafone UK) must be informed, so that they can regenerate any changes since the database was backed up.
Availability Use this procedure on the live and the standby node.
Procedure Remote Engineer You cannot restore the HLR database from the Remote Engineer account. If the HLR database needs to be restored, escalate the problem to second-line support.
pds_manager
1. On the standby node, enter the command: pds stop 2. Repeat this command on the live node. Any HLR processes currently running will now be stopped. 3. Set your default directory to /opt/vodafone/pds/data using the command: cd /opt/vodafone/pds/data 4. Determine which is the most recent valid backup copy of the database by looking at the name of the backup indicator file logical_db_name_GOODBACKUPIS.BKn in the /opt/ vodafone/pds/data directory. See Table 57 on page 587. 5. Rename the existing database using the command: mv LOG1_HLRD_FILE LOG1_HLRD_FILE.REPLACED
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
119
6. Copy the most recent backup of the database to the disk image using the command: mv backup_file LOG1_HLRD_FILE backup_file is either LOG1_HLRD_SAVED.BK1 or LOG1_HLRD_SAVED.BK2. Note: If the disk has insufficient free space for the database file, delete the corrupt database REPLACED_HLRD_FILE and then copy the most recent backup to disk. 7. Use pds start to start the live node. When restart on the live node is complete, a 2601: Node Out of Live Service CEASEalarm appears. 8. Use pds start to start the standby node. 9. Check that the correct PDS processes are running. (See Showing HLR Processes on page 100.) If the alarm is not displayed or the right processes do not appear, the application has failed to start correctly. See Software Start-up Failure on page 88 for more information on how to diagnose the fault. 10.Check (using PULSE) that the database is served on the live node, and slaved on the slave node. If the standby node fails to slave, stop the node, delete/rename its database file and all backups, and restart the standby node. It will create a new copy of the database file and new backups. 11.Tell the ADC that the database has been restored, so that they can regenerate any changes made to HLR subscriber data since the backup copy was created.
Results The HLR database has been restored and no further corruption alarms should appear.
2
Home Location Register (Linux) V1.1 Support Guide
120
Chapter 6 Using Support Interfaces
Checking and Managing the HLR Use the following procedures to check and manage the HLR from the Remote Engineer account. • Checking for the Live Node. Check whether a node is the live or standby node. See page 121. • The following procedures access the Remote Engineer Utility, providing HLR status and performance information. - Displaying System Status Graphs on page 122 - Showing HLR Processes on page 100 • Displaying Hardware/Software Versions. Check the software on the HLR. See page 125. • Showing Install History. Check a log of software installation. See page 126. • Displaying an Availability Report. View a log of platform down time and reasons for outages. See page 127. • Setting the System Date and Time. Set the local time on the HLR. See page 129. • Viewing Service Request Numbers. View the SRN and SAN information. See page 130. • Viewing HLR Tables. View the contents of the HLR’s tables. See page 131.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
121
Checking for the Live Node A text file called pds_l_live in the pds/state directory indicates the live state as TRUE or FALSE.
Availability Use this procedure on either node.
Procedure Remote Engineer The banner displayed above the Remote Engineer main menu indicates whether the current node is live or standby.
pds_manager
Enter: cat /opt/vodafone/pds/state/pds_l_live
Results The value stored in pds/state/pds_1_live is one of the following: • TRUE – this is the live node. • FALSE – this is the standby node.
2
Home Location Register (Linux) V1.1 Support Guide
122
Chapter 6 Using Support Interfaces
Displaying System Status Graphs You can display system statistics in graphical form. These are updated in real-time and allow you to check the system performance.
Availability Use this procedure on any node.
Procedure Remote Engineer Click 1RGH6WDWLVWLFV
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
123
Results A set of graphs is displayed, as listed below. Click GD\, ZHHN, PRQWK, or \HDU to determine the time period over which the data is gathered. • &388WLOL]DWLRQ shows system loading in terms of CPU usage. If this is consistently 75% or more, the node is reaching its processing capacity and the system may need reconfiguring. Alternatively, a process may be stuck in a loop.
• 1HWZRUN,2(kbytes/sec) shows the utilization of all network connections (SIGTRAN, admin, and O&M).
• %ORFN'HYLFH,2is the utilization of disk I/O.
• 0HPRU\$OORFDWLRQis the total memory available, and current memory
2
Home Location Register (Linux) V1.1 Support Guide
124
Chapter 6 Using Support Interfaces
usage.
• 'LVN8WLOL]DWLRQis the total disk space available, and current disk usage.
Results Details of the hardware (including BIOS and PCI devices) are shown, together with details of the operating system.
2
Home Location Register (Linux) V1.1 Support Guide
126
Chapter 6 Using Support Interfaces
Showing Install History This displays a log of software installed on the platform.
Procedure Remote Engineer Click ,QVWDOO+LVWRU\
Results The software installation log file is displayed.
The right-hand half of the software installation log lists the names of installed software packages. The left-hand half of the log file comprises the installation date.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
127
Displaying an Availability Report For each month in the year, the availability report lists the amount of time the platform was serving the network. Note: The availability report does not necessarily show service availability because a disaster recovery platform might be covering for a failed or shutdown platform.
Availability The availability report relates to the individual node. The report is produced by the pds_i_mgta process.
The availability report is in the directory /opt/vodafone/pds/log. To view the availability report, enter: cd /opt/vodafone/pds/log less availability_yyyy.dat where yyyy is a year (2006 or later).
Results For each month in the year, the availability report lists the total number of seconds in the month, followed by the number of seconds of uptime and downtime. Uptime and downtime are also shown as a percentage of the total time in the month.
List of Outages
The summary of uptime and downtime are followed by a list of all outages which caused the downtime, the length of the downtime in seconds and the reason for the outage.
Scheduled and Unscheduled Outages
Downtime is subdivided into scheduled and unscheduled outages, to indicate how much network service time is lost because of platform problems. If the platform is stopped by support staff using pds stop or any other support command, the downtime is classed as scheduled. An example availability report is shown in Figure 41 on page 128.
2
Home Location Register (Linux) V1.1 Support Guide
128
Chapter 6 Using Support Interfaces
Figure 41. Example Availability Report
Entries in brackets are text typed in when the pds stop command prompts for a reason why the command is being used.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
129
Setting the System Date and Time The HLR uses Network Time Protocol (NTP) software to synchronise its system time to a reference source providing co-ordinated universal time (UTC). You need to set the system time when configuring a new HLR or when the local time changes. For more on system times and how to set them, see Appendix C, Time Synchronization.
Availability Use this procedure only on the standby nodes.
2
Home Location Register (Linux) V1.1 Support Guide
130
Chapter 6 Using Support Interfaces
Viewing Service Request Numbers This procedure describes viewing the HLR’s Service Request Numbers (SRNs) and Service Access Numbers (SANs). The HLR keeps a list of Service Request Numbers (SRNs) and their corresponding Service Access Numbers (SANs). These are used for services such as directory enquiries and information numbers and also for numbers exported to another network (see Mobile Number Portability (MNP) on page 40). SRNs are allocated by the HLR. When the HLR receives a Send Routing Information request for a SRN, it returns the SAN in place of the roaming number. For more information on SRNs, see Service Request Number Commands on page 289.
☞
??changes needed for logical databases???
Availability Use this procedure only on a live node.
Procedure Remote Engineer Click 6\VWHP8WLOLWLHV /LYH%(3RQO\ > 6HUYLFH1XPEHU 0/5RQO\ The service request numbers and corresponding service access number are displayed. Figure 42 shows an example. Figure 42. Service Request Number View Example GSM HLRDatabase SRN Dump:V0400 Node:SLIGO2 SRN 447785123456 447785123457 447785123455 23451234567890 12345678 123456789012 1234567890123 12345678901234
10-MAR-2004 10:47
SAN 447785123456 447785123457 447785123455 23451234567895 12345678901 12345678901 12345678901 12345678901
Press to continue
Note: Since mobile number portability (MNP) uses an SRN for every subscriber exported to another network, the output from this command might be a very long list.
pds_manager
Enter the following commands: cd /opt/vodafone/pds ./libexec/hlru_srnview logical_db_name
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 6 Using Support Interfaces
131
Viewing HLR Tables Use this option to list the tables present on the HLR and display their contents. For full details of HLR tables see Chapter 24, Table Maintenance.
Procedure Remote Engineer Click 7DEOH9LHZ
Results The Table View is displayed, an example is shown in Figure 43. Figure 43. Table View Menu HLR on AHLR01 THIS IS THE LIVE NODE Table View Menu
(Currently selected table is ASCVT)
FACILITY
OPTION
View Table.........................................1 Display status of Table............................2 Change table viewed................................3 Return to previous menu............................4 Choose Option : Currently available tables are: ASCVT BNUM USSD BCA IO_CONVERT MSRNPFX
CNUM HLR_CONFIG TKEY
MKEY PDS_CONFIG NETENT SP CNUM_BHVR SS7CFG
Note: of For the TKEY and MKEY tables, The 7DEOH9LHZoption only displays the first field in the specified table. Use the drop-down menu to select the table you want to view, and click 6KRZ.
pds_manager
Enter the following commands: cd /opt/vodafone/pds ./libexec/hlru_tableview -table=tablename logical_db_name
2
Home Location Register (Linux) V1.1 Support Guide
132
Home Location Register (Linux) V1.1 Support Guide
Chapter 6 Using Support Interfaces
2
133
Chapter 7
Alarms This chapter describes the HLR alarms. It contains: • A description of the HLR alarm classes (see page 135). • Details of every A1 and A2 HLR alarm (see page 138).
2
Home Location Register (Linux) V1.1 Support Guide
134
Chapter 7 Alarms
Alarm Distribution The alarm architecture is shown in Figure 44. The syslogd process reads alarms generated by the PDS applications, and writes them to the alarm clients. Alarms can be distributed to: • a file. All alarms are written, in text format, to /var/log/pds/ pds_alarms. This file is rotated daily: old files are renamed /var/ log/pds/pds_alarms.n, where n is a number indicating how old the file is (in days). The rotation is controlled by the logrotate utility, configured in /etc/logrotate.d/syslog. • the SNMP alarm client. Alarms read by this client are filtered to exclude Minor (A3) alarms. This client is mainly for First Line Support staff. See SNMP Agent for more information on SNMP. • A TCP/IP client such as TeMIP. PDS processes and alarm clients and servers are arranged as shown in Figure 44 below. How alarms are distributed is configured when the HLR software is installed or upgraded, and cannot then be changed by the network operator. Alarm distribution is not limited to one route; a system can be configured to use any combination of the distribution options. Figure 44. Alarm Distribution PDS processes
Alarm Server Process
syslogd
TCP/IP socket server for TeMIP
File
Home Location Register (Linux) V1.1 Support Guide
SNMP
2
Chapter 7 Alarms
135
Alarm Classes HLRA and HLRD alarms are classified as either A1, A2 or A3.
A1 - Critical Alarm A critical alarm indicates an HLR component failure which may prevent the HLR from providing any service to the network. Critical alarms require immediate attention to rectify the fault.
A2 - Major Alarm A major alarm indicates an HLR component failure which may disrupt the HLR’s service to the network.
A3 - Minor Alarm A minor alarm indicates either: • an HLR component failure, which is unlikely to cause any disruption of the HLR’s service to the network. • an information message.
2
Home Location Register (Linux) V1.1 Support Guide
136
Chapter 7 Alarms
Alarm Types There are four alarm types: • Event alarms Event alarms signal an event, such as a failed signal. These are ‘fire and forget’ alarms. • Condition alarms These alarms indicate a condition, and can be raised or ceased, indicating a change of state. An example of a condition alarm is a signal overload: this would be raised when the platform could no longer queue new transactions, and would be ceased once the resource to queue new transactions was restored. • Instance alarms These alarms are similar to condition alarms, but there may be a number of instances of the same condition. For example, a failed SIGTRAN Association is an instance alarm: there would be one instance for each SIGTRAN Association that is configured. • Summary alarms These alarms encapsulate several instances of a condition in a single condition, and is intended to be used by First Line Support staff only. Each instance of the summary alarm has a corresponding Minor (A3) condition alarm, but the summary alarm is only triggered when a predefined number of the individual alarms are triggered. An example summary alarm is Database Resource Exhausted. Each database pool corresponds to an instance of the condition, generating its own Minor condition alarm. On the first of these Minor alarms, a Summary alarm is raised, and is only ceased when all instances have ceased.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
137
Viewing Alarms You can view alarms by viewing one of the alarms files, or you can see alarms as they are generated, in realtime.
Viewing alarms in realtime
To view alarms as they are generated, issue the following command:
Viewing alarm files
You can view alarms on the live node by viewing the file /var/log/ pds/pds_alarms, using any standard utility for viewing text files. For example:
tail -f /var/log/pds/pds_alarms
less /var/log/pds/pds_alarms To see historical alarms, replace the file name with /var/log/pds/ pds_alarms.n, where n is between 1 and 9, and lower values indicate more recent alarms.
Example
Below is an extract from an example alarms file:
Alarm: 297 (Component: HLRA Event: 7 Severity: A3) Time: 10-SEP-2001 13:16:48.62 Data: TC-U_Abort caused in UPDATE_LOCATIONISD,IMSI:234150000000000,MSISDN:44385100101,LA:4206,RA:GT(106)VLR.TT0.E164.+443 85000300 Alarm: 292 (Component: HLRA Event: 2 Severity: A3) Time: 10-SEP-2001 13:21:05.58 Data: An Unsupported Service Failure caused by UPDATE_LOCATION(ISD result),LA:GT()HLR.TT0.E164.+44385016199,RA:GT(106)VLR.TT0.E164.+44385000300,me ssage:
2
Home Location Register (Linux) V1.1 Support Guide
138
Chapter 7 Alarms
Alarm Descriptions This section lists all the A1 and A2 HLR alarms in ascending order by alarm code. For each alarm, the information in Table 15 is provided. Table 15. Alarm Descriptions Format Item
Description
Alarm Code
The identifying alarm number.
Alarm Text
Either: • the summary alarm text • the phrase Internal software diagnostic message, used to describe a group of similar alarms without specifying the exact text of each.
Alarm Class
The alarm class. See page 135 for a definition of the HLR alarm classes.
Alarm Type
The type of alarm: see Alarm Types.
Full Text
The full text of the alarm.
Description
A description of what the alarm means, its possible causes, and its effects.
Response
Information on how to identify and rectify the problem. Where appropriate, response information is provided separately for: • First line support staff who access the HLR using the Remote Engineer account. • Second line support staff: who access the HLR using the pds_manager account.
2236
AUTH_SEQUENCE_NUM_CHANGED
Class: Type: Full text: Description:
A2 Event Authentication sequence number manually changed The 3G authentication sequence number has been manually changed. This may have been done for legitimate reasons if a sequence number had become desynchronised with that on a subscriber’s handset. This is alarmed as there may have been a security breach. There is no service loss.
Response:
First Line Support: Report to Second Line Support. Second Line Support: If the Authentication Sequence number has been changed manually for good reason then ignore this message. If the manual change is not accounted for, report to the appropriate security department.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
2305
139
AUTH_SEED_CHANGED
Class: Type: Full text: Description:
A2 Event Authentication seed changed The authentication seed for generating random numbers (as part of authentication triplets) has been manually changed. This may have been done for legitimate reasons. This is alarmed as there may have been a security breach. There is no service loss.
Response:
First Line Support: Report to Second Line Support. Second Line Support: If the Authentication Seed has been changed or reset for good reason then ignore this message. If the manual change is not accounted for, report to the appropriate security department.
2306
SKE_LOGGING_ON
Class: Type: Full text: Description:
A2 Condition SKE Logging on Logging of Subscriber Key Encryption is on. This may present a security risk. This is caused by configuration at node-start time. The node must be restarted for any configuration changes to take effect. This does not correspond to any service loss.
Response:
First Line Support: Check logging is required. If not, it will need to be disabled and the platform cutover during low traffic hours. Report to Second Line Support. Second Line Support: If SKE Logging is not required, this should be turned off to prevent a security risk. This would require a reconfiguration and restart at the next convinient point. Report to Third Line Support.
2
Home Location Register (Linux) V1.1 Support Guide
140
Chapter 7 Alarms
2326
ADMIN_TASKS_EXHAUSTED
Class: Type: Full text: Description:
A1 Condition Administration tasks exhausted There are a no free administration tasks available. There is an imminent risk that the platform will subsequently become overloaded by Provisioning Traffic. This may be caused by a performance degradation of the application or live database server, a platform resource problem, a hardware fault or an abnormally high loading of provisioning traffic. There is a loss of provisioning capabilities. This corresponds to a major service loss.
Response:
First Line Support: Escalate to Second Line Support. Second Line Support: Check level of Admin overloading by navigating PULSE as follows: ’Details’, ’ADMA’, ’Seizer’ and checking the number of tasks in use. Also check the number/rate of Admin commands received from each client as follows: ’Details’, ’ADMP’. Prepare to disconnect any Admin users with abnormally high numbers of commands, if appropriate. If problem persists, escalate to Third Line Support.
2327
ADMIN_TASKS_LOW
Class: Type: Full text: Description:
A2 Condition Administration tasks low There are a low number of free administration tasks available. There is considerable risk that all administration tasks will be exhausted and subsequently overloaded by Provisioning Traffic. This may be caused by a performance degradation of the application or live database server, a platform resource problem, a hardware fault or an abnormally high loading of provisioning traffic. There is no service loss though there is an imminent risk of loss of provisioning capabilities. This would correspond to a major service loss.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
Response:
141
First Line Support: Report to Second Line Support. Second Line Support: Check level of Admin overloading by navigating PULSE as follows: ’Details’, ’ADMA’, ’Seizer’ and checking the number of tasks in use. Also check the number/rate of Admin commands received from each client as follows: ’Details’, ’ADMP’. Prepare to disconnect any Admin users with abnormally high numbers of commands, if appropriate. If problem persists, report to Third Line Support.
2350
LIVE_DATABASE_RESOURCE_EXHAUSTED
Class: Type: Full text: Description:
A1 Summary Live database resource exhausted The live database has no remaining capacity. Further updates will be disabled. (Updates may result from signals traffic or subscriber provisioning. The latter is more likely to fill capacity, particularly if new subscribers are created.) This is a major service loss. It will be impossible to add further subscribers and it is likely that subscriber data will not be able to be updated. Signals may also be affected.
Response:
First Line Support: Escalate to Second Line Support. Do not allow any SDM to this platform. Second Line Support: Execute an SDM as a matter of urgency to move subscriber data from this HLR to an HLR that has sufficient capacity. Check database capacity on the SDM destination using the database utility, DBVIEW.
2351
DATABASE_SERVER_TASKS_EXHAUSTED
Class: Type: Full text: Description:
2
A1 Condition Live database server tasks exhausted The live database server is overloaded with tasks, and can process no new tasks.
Home Location Register (Linux) V1.1 Support Guide
142
Chapter 7 Alarms
There is serious service degradation that may soon lead to critical service loss. First Line Support: Escalate to Second Line Support. Second Line Support:
Response:
Check Platform loading by analysing HLRA tasks, Signals load and Admin load using PULSE: Navigate to ’Details’, ’HLRA’, ’HLRA Control’, ’View Tasks’ to check HLRA tasks; ’Details’, ’SS7I’, ’Throttle Control’ to check the Signals Loading; ’Details’, ’ADMA’, ’Seizer’ to check the Admin loading. Also check system on the command line. Check for any locked subscribers using the database utility, Sublocks. Escalate to Third Line Support.
2352
DATABASE_SERVER_TASKS_LOW
Class: Type: Full text: Description:
A2 Condition Live database server tasks low The live database server is nearly overloaded with tasks. There is considerable risk that the database may become overloaded and unable to cope with any new tasks. There is no service loss, although there is a considerable risk of serious service degradation and subsequent service loss.
Response:
First Line Support: Escalate to Second Line Support. Second Line Support: Check Platform loading by analysing HLRA tasks, Signals load and Admin load using PULSE: Navigate to ’Details’, ’HLRA’, ’HLRA Control’, ’View Tasks’ to check HLRA tasks; ’Details’, ’SS7I’, ’Throttle Control’ to check the Signals Loading; ’Details’, ’ADMA’, ’Seizer’ to check the Admin loading. Also check system on the command line. Check for any locked subscribers using the database utility, Sublocks. If the problem persists, escalate to Third Line Support.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
2353
143
LIVE_DATABASE_ RESOURCE_LOW
Class: Type: Full text: Description:
A2 Summary Live database resource low The live database is low on capacity. There is a high risk that further updates to the database will render it full. (Updates may result from signals traffic or subscriber provisioning. The latter is more likely to fill capacity, particularly if new subscribers are created.) There is no loss of service, although a risk to major service loss is high.
Response:
First Line Support: Report to Second Line Support. Do not allow any SDM to this platform. Second Line Support: Do not allow any SDM to this platform. Stop any SDM that may be in progress. Check database capacity on the SDM destination using DBVIEW. Prepare to redistribute subscribers from this node using SDM.
2354
LIVE_DATABASE_NOT_SECURED
Class: Type: Full text: Description:
Response:
A2 Condition Secured Live Database is out of date The Live Database has not been secured recently. This means that the database copy on disk may be out of date, and should be considered a risk of service degradation. First Line Support: Escalate to Second Line Support. Second Line Support: Monitor the rate at which secures are made, and when the last secure was made. Do this by navigating PULSE as follows: ’Details’, ’HLRD’, ’DB Secure’ (use option ’8’ to navigate between required pages). This will also indicate how long secures are taking. Check disk performance and performance of HLRD process. If problem persists, escalate to Third Line Support.
2
Home Location Register (Linux) V1.1 Support Guide
144
Chapter 7 Alarms
2357
BACKUP_DATABASE_CORRUPT
Class: Type: Full text: Description:
A1 Condition Backup database corrupt The backup database is corrupt, indicating that the live database is also likely to be corrupt. This will have an unpredictable effect on the function of the platform. This should be considered a critical loss of service.
Response:
First Line Support: Escalate to Second Line Support. Second Line Support: Prepare to resort to the last good backup database at the nearest opportunity. The last good backup will be slightly out-of-date and so ISAAC commands may need to be replayed from the time at which it was created. Escalate to Third Line Support.
2371
LIVE_DATABASE_NOT_BACKED_UP
Class: Type: Full text: Description:
Response:
A2 Condition Secured Live Database Backup is out of date The backup of the live database has not been recently secured to disk. This means that if the live database file is lost, the backup file may not accurately represent an up-to-date picture of subscription data. This should be considered a minor risk to service degradation. First Line Support: Escalate to Second Line Support. Second Line Support: Monitor the rate at which backups are made, and when the last backup was made. Do this by navigating PULSE as follows: ’Details’, ’HLRD’, ’DB Secure’ (use option ’8’ to navigate between required pages). This will also indicate how long secures are taking. Check disk performance and performance of HLRD process. If problem persists, escalate to Third Line Support.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
2397
145
Invalid database ID
Class:
A1
Type ☞
please supply alarm types for alarms 2397-2426 Full Text:
Invalid database id: this node: Logical_Db/Db_Version/ Db_init_time, server Physical_HLR: Logical_Db/Db_Version/ Db_init_time
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
An attempt was made to synchronize two databases (master and slave) which have different database IDs.This is detected at the slave having received the database id from the active database.
Response:
First-line support: Report the alarm to second-line support. Second-line support: Check configuration. Report to third-line support.
2398 Class: Full Text:
Invalid sequence number A1 Invalid database sequence number Logical_Db
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
An active database is loaded with a sequence number of zero. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Escalate to the alarm to third-line support.
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
The load operation for a database failed for any reason.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2401 Class: Full Text:
Logical database name file error A1 Logical database name file error
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
The attempt to write to the log_db_name.NAME file in the PDS_L_SHRDIR directory failed.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2402 Class: Full Text:
Database server failed A1 Database server failed Logical_Db
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
147
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
An attempt to create a database server (for the interface with database utilities) failed. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Escalate the alarm to third-line support.
A database operation was attempted when the database was frozen on account of control being switched from it (active to slave) to another database being promoted (slave to active). It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Escalate the alarm to third-line support.
2404 Class: Full Text:
Invalid journal A1 Invalid journal Logical_Db
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A journal was received where the sequence number has not incremented correctly, or where the database ID is invalid. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support:
2
Home Location Register (Linux) V1.1 Support Guide
148
Chapter 7 Alarms
Escalate the alarm to third-line support.
2405 Class: Full Text:
Corrupt journal A1 Corrupt journal Logical_Db
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A journal was received containing invalid size information. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Escalate the alarm to third-line support.
2406 Class: Full Text:
Change to server despite incomplete transaction A1 Change to server despite incomplete transaction Logical_Db
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
The communications failed when a database was being handed over from an active database to a slave which is synchronizing off it.In spite of this alarm being raised, the slave will take over as an active database.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2407 Class: Full Text:
No database agent task available A1 No database agent task available
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
149
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
Insufficient database agent tasks were available to allow a logical server database to communicate with the required slaves, as specified in the PDS_DEFS table.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2408 Class: Full Text:
Number of used database agents has exceeded its threshold A1 The number of used database agents has exceeded its threshold
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
The number of database agent tasks in use for a logical database exceeded the upper threshold defined in the node configuration file.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2409 Class: Full Text:
Number of used database agents has returned within its lower threshold A1 The number of used database agents has returned within its lower threshold
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
The number of database agent tasks in use for a logical database returned within the lower threshold defined in the node configuration file, having previously exceeded the upper threshold.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support:
2
Home Location Register (Linux) V1.1 Support Guide
150
Chapter 7 Alarms
Determine the problem, and escalate to third-line support if necessary.
2410 Class: Full Text:
An invalid database agent index has been received A1 An invalid database agent index has been received
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
There was an error in the database agent seizer such that an invalid database agent task index was received. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Escalate the alarm to third-line support.
2411 Class: Full Text:
Database sync request from invalid slave A1 Database sync request from invalid slave Logical_Db slave_physical_name
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A database sync request was received by an active database from a slave which is not listed in its PDS_DEFS table as a valid slave for this server.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2412 Class: Full Text:
Unknown service A1 Unknown service Logical_Db
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
151
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A slave database was not able to locate a physical machine running the same logical database as a server.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
The database manager task for a slave database timeed out when communicating with an active database.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary. When the problem is resolved, ensure that DB synchronization has been re-established, by checking the relevant PULSE counters. This is particularly important in the live-standby case, to ensure the standby is synchronized.
2414 Class: Full Text:
Server signal discarded in slave mode A1 Server signal discarded since not in server state, trigger = trigger_name, received by routine routine_name
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A database operation was attempted when the database is running as a slave. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support.
2
Home Location Register (Linux) V1.1 Support Guide
152
Chapter 7 Alarms
Second-line support: Escalate the alarm to third-line support.
2415 Class: Full Text:
Database sync request for invalid logical database A1 Database sync request for invalid logical database updating_Db_name Agent_Logical_Db_name Physical_node_name
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
An attempt was made to initiate DB sync by a slave to a server where the logical database names differ. It is raised by the active database having received a sync request for a logical database with the wrong name. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Escalate the alarm to third-line support.
An attempt was made to carry out page updating, but no map had yet been secured; this is a problem since page updating uses the last secured map to carry out synchronization.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
2417 Class: Full Text:
153
Page update fail A1 Page update fail Logical_Db
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
Page updating failed because the secured map being used was overwritten during the page updating process, or an invalid page number was identified during the request map processing.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
An attempt was made to synchronize a database to a slave which already has a database file in PDS_L_SHRDIR, but which is uninitialized (for example, it was created during a previous sync, but page updating did not complete).
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
The database manager task for an active database timed out when communicating with a slave database.
2
Home Location Register (Linux) V1.1 Support Guide
154
Chapter 7 Alarms
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary. When the problem is resolved, ensure that DB synchronization has been re-established, by checking the relevant PULSE counters. This is particularly important in the live-standby case, to ensure the standby is synchronized.
2420 Class: Full Text:
Newer copy of database exists A1 A newer copy of database Logical_Db exists on node Slave_physical_name. This node will cut over now...
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A newer copy of a database exists on the standby node, thus causing a cutover (so long as the yield to slave limit has not been exceeded: see the PDS_CONFIG table for more details).
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2421 Class: Full Text:
Synchronisation to server will overwrite data A1 Synchronisation of Logical_Db to server Physical_node will overwrite data for sequence numbers start_Seq to end_Seq
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A server, when processing the map received from a slave, discovered that it is necessary to overwrite data on the slave.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
2422 Class:
155
Internal software error A1
Component:
MGTA (PDS_Pnnnn_MGTA)
Description:
There is an internal software error within the MGTA component. It will be raised in the following cases • Too many application processes registering on startup • Too many database processes registering on startup • Too many slaves in PDS_DEFS table • Duplicate slaves in the PDS_DEFS table
Response:
First-line support: Report the alarm to second-line support. Second-line support: If the problem persists, report to third-line support.
2423 Class: Full Text:
Active database too old, update deferred A1 Active database too old, update deferred until later for Logical_Db
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
A server, when processing the map received from a slave, discovered that the slave has an unacceptable amount of data needing to be overwritten. The slave will defer the update until the server has the same sequence number as the slave.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2424 Class: Full Text:
2
Database ID logical error A1 Database id logical name error: file name: Logical_Db, file
Home Location Register (Linux) V1.1 Support Guide
156
Chapter 7 Alarms
content: Db_name Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
The database logical name in the .BIN file does not correspond to that in the file name. It is raised when trying to load such a database in either active or slave modes.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Determine the problem, and escalate to third-line support if necessary.
2425 Class: Full Text:
Logical database name changing state to state A1 Logical database Logical_Db changing state to active_slave_inactive
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
This alarm will be raised when entering a new database state (active, slave, inactive). When a database is promoted to server, then this alarm will be raised immediately. When a database is removed, it will be raised following the secure. When a database is changed to slave, it will be raised after initial handshaking. It will be carried out at this time rather than immediately so as to avoid raising the alarm repeatedly if this handshaking fails and is thus retried. An INACTIVE alarm is raised when the database is a slave running on the standby server. The SLAVE alarm is raised only when it goes live.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Check whether the database should have changed state. If not, escalate the alarm to third-line support.
2426
Last secured map error for logical database
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
Class: Full Text:
157
name A1 Last secured map error for logical database Logical_Db
Component:
PDSD (PDS_Pnnnn_PDSD)
Description:
The last secured map was detected to be in use when it was not expected to be. It is tantamount to an internal software error.
Response:
First-line support: Escalate the alarm to second-line support. Second-line support: Escalate the alarm to third-line support.
2464
ASP_UNAVAILABLE
Class: Type:
A2 Instance
Full text:
:Application server process unavailable,
Description:
The indicated SIGTRAN ASP is unavailable. This may be due to a broken SIGTRAN association, or due to the remote ASP being out of service. This may be caused by an association fault or a fault in the remote entity. This should not be considered as a major service loss by itself. It will result in a reduction in traffic capacity and redundancy to/from the corresponding destination entity.
Response:
First Line Support: Check SIGTRAN TCPIP/IP interface hardware. Check destination platform, and for any network problems. If problem cannot be resolved, report to Second Line Support. ASP states can be analysed using PULSE: navigate to ’Sigtran’, ’Association States’. Second Line Support: Check SIGTRAN TCPIP/IP interface hardware. Check destination platform, and for any network problems. If problem cannot be resolved, report to Third Line Support. ASP states can be analysed using PULSE: navigate to ’Sigtran’, ’Association States’.
2
Home Location Register (Linux) V1.1 Support Guide
158
Chapter 7 Alarms
2465
DESTINATION_ UNAVAILABLE
Class: Type: Full text: Description:
A2 Instance :Destination unavailable, <destination identifier> The indicated Application Server (that is, destination) is unavailable. This may be due all of its ASPs (or a critical number of them) being unavailable, or a combination of association faults. This is a loss of service to/from the indicated remote entity.
Response:
First Line Support: Check SIGTRAN TCPIP/IP interface hardware. Check destination platform and for any network problems. If problem cannot be resolved, escalate to Second Line Support. Second Line Support: Check SIGTRAN TCPIP/IP interface hardware. Check destination platform, and for any network problems. If problem cannot be resolved, escalate to Third Line Support.
2466
DESTINATION_ CONGESTED
Class: Type: Full text: Description:
A2 Instance :Destination congested, <destination identifier> The indicated Application Server (that is, destination) is congested. This may be due to all of its ASPs (or a critical number of them) being congested, or a combination of association faults. This is a reduction in service to/from the indicated remote entity.
Response:
First Line Support: Check SIGTRAN TCPIP/IP interface hardware. Check destination platform and network. If problem persists and cannot be resolved, escalate to Second Line Support. Second Line Support: Check SIGTRAN TCPIP/IP interface hardware. Check destination platform, and for any network problems. If problem persists and cannot be resolved, escalate to Third Line Support.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
2467
159
ASSOCIATION_ FAULT
Class: Type: Full text: Description:
A2 Instance :Association fault, A fault has occurred with the indicated SIGTRAN SCTP association. This implies a hardware or configuration fault. The fault may not necessarily be on this platform. This should not be considered as a service loss, although there may be a loss of redundancy. This could be caused by a network or hardware fault, or a configuration error.
Response:
First Line Support: Check SIGTRAN TCP/IP interface hardware. Check destination platform, and for any network problems. If problem cannot be resolved, report to Second Line Support. Second Line Support: Check SIGTRAN TCP/IP interface hardware. Check destination platform, and for any network problems. If problem cannot be resolved, report to Third Line Support.
2468
ALL_DESTINATIONS_UNAVAILABLE
Class: Type: Full text: Description:
A1 Condition All destinations unavailable All remote Application Servers (that is, destinations) are unavailable. This is unlikely to be caused by a fault in all destination entities. This may be an application fault or a network problem. This is a critical service outage.
Response:
First Line Support: Check SIGTRAN TCP/IP interface hardware. Check for major network faults. Check local platform. Escalate to Second Line Support. Second Line Support: Check SIGTRAN TCP/IP interface hardware. Check for major network faults. Check local platform. Escalate to Third Line Support.
2
Home Location Register (Linux) V1.1 Support Guide
160
Chapter 7 Alarms
2601
NO_LIVE_SERVICE
Class: Type: Full text: Description:
A1 Condition Node out of live service () This node is allocated for live service but is not providing any. This indicates a total service loss for the entire platform. This alarm is not intended to indicate whether the application is stopped. However, it may indicate that the application is stopping, starting or in a failed state. The reason in the alarm text will indicate the exact state. The alarm client is responsible for monitoring whether the application is running (this may be through the use of the Heartbeat alarm).
Response:
First Line Support: Check the reason for the node being out of service. If a cutover has occurred or the node has been manually started, allow enough time for the application to activate and provide service. If a cutover occurred, report to Second Line Support. If the alarm is not cleared after a short period or if it is persistently raised, escalate to Second Line Support. Second Line Support: Check the reason for the node being out of service. If a cutover has ocurred or the node has been manually started, allow enough time for the application to activate and provide service. If a cutover occurred, report to Third Line Support. If the alarm is not cleared after a short period, or if it is persistently raised, escalate to Third Line Support.
2603
NO_STANDBY_SERVICE
Class: Type: Full text: Description:
A2 Condition Node out of standby service (). This node is allocated for standby service but is not providing any. This indicates a lack of redundancy for platform service. This alarm is not intended to indicate whether the application is stopped. However, it may indicate that the application is stopping, starting or in a failed state. The reason in the alarm text will indicate the exact state.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
161
The alarm client is responsible for monitoring whether the application is running (this may be through the use of the Heartbeat minor alarm). This indicates no service loss, but does indicate a significant risk of total service loss if the other node of the platform fails.
Response:
First Line Support: If a cutover has occurred or the node has been manually started/ restarted, allow enough time for the application to activate and provide standby service. If the alarm is not cleared after a short period or if it is persistently raised, escalate to Second Line Support. If the alarm was caused by an automatic restart (that is, failure) of the standby node then report to Second Line Support. Second Line Support: If a cutover has ocurred or the node has been manually started/ restarted, allow enough time for the application to activate and provide standby service. If the alarm is not cleared after a short period or if it is persistently raised, escalate to Third Line Support. If the alarm was caused by an automatic restart (that is, failure) of the standby node, then report to Third Line Support.
2611
Not enough database processes
Class:
A1
Type ☞
please supply alarm type
Component:
MGTA (PDS_Pnnnn_MGTA)
Description:
There are not enough database processes to support the contents of the PDS_DEFS table. Note that sufficient processes are needed to allow any existing logical databases to close (which may take a little time since this involves a secure to disk) and any new logical databases to start.
Response:
First-line support: Report the alarm to second-line support. Second-line support: If the problem persists, report to third-line support.
2
Home Location Register (Linux) V1.1 Support Guide
162
Chapter 7 Alarms
2679
APPLICATION_TASKS_LOW
Class: Type: Full text: Description:
A2 Condition Application tasks low There are a low number of free application tasks available. There is considerable risk that all application tasks will be exhausted and subsequently become overloaded by Signals traffic. This may be caused by a performance degradation of the live database server, a platform resource problem, a hardware fault, or one or more remote entities taking a long time to respond to the HLR (or failing to respond and thus timing out). There is no service loss though there is imminent risk of serious service degradation and subsequent service loss.
Response:
First Line Support: Report to Second Line Support.
2680
APPLICATION_TASKS_EXHAUSTED
Class: Type: Full text: Description:
A1 Condition Application tasks exhausted There are no free application tasks available. There is an imminent risk that the platform will subsequently become overloaded by Signals traffic. This may be caused by a performance degradation of the live database server, a platform resource problem, a hardware fault, or one or more remote entities taking a long time to respond to the HLR (or failing to respond and thus timing out). There is serious service degradation and imminent risk of a total service loss.
Response:
First Line Support: Escalate to Second Line Support.
2701
TCPIP_TASKS_EXHAUSTED
Class: Type:
A2 Condition
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
Full text: Description:
163
TCP/IP tasks exhausted There are no free tasks for handling TCP/IP transactions. The platform has become overloaded by TCP/IP traffic. There is s service loss for TCP/IP traffic and those application-based services that depend upon it. This constitutes a minor service loss. Some services such as Location Services and Automatic Device Detection may be lost.
Response:
First Line Support: Escalate to Second Line Support. Second Line Support: Check level of transactions that may use TCP/IP transactions, to try to understand TCP/IP transaction loading. If problem persists, then escalate to Third Line Support.
2702
TCPIP_TASKS_LOW
Class: Type: Full text: Description:
A2 Condition TCP/IP tasks low There is a low number of free tasks for handling TCP/IP transactions. There is an imminent risk that the platform will subsequently become unable to handle further TCP/IP transactions. There is no service loss, although there is a risk of imminent service loss for TCP/IP traffic and those application-based services that depend on it. This would constitute a minor service loss. Some services such as Location Services and Automatic Device Detection may be affected by this.
Response:
First Line Support: Report to Second Line Support. Second Line Support: Check level of transactions that may use TCP/IP transactions, to try to understand TCP/IP transaction loading. If problem persists, then report to Third Line Support.
2
Home Location Register (Linux) V1.1 Support Guide
164
Chapter 7 Alarms
2721
TRAFFIC_OVERLOAD
Class: Type: Full text: Description:
A1 Condition Signal traffic overload The rate of incoming signals traffic is too high for the performance of the application. The application is overloaded and can process no new signals. New signals are discarded. This may be caused by abnormally high levels of traffic, possibly as a result of having provisioned too many subscribers on this platform. It may equally be caused by platform resource problems, a hardware fault, or excessive network traffic caused by a nationally or internationally significant event. There is total loss of signal traffic service. This constitutes a critical service loss.
Response:
First Line Support: Escalate to Second Line Support. Second Line Support: Check the number of subscribers in the live database using the database utility, DBVIEW. If this is abnormally high, consider executing an SDM for some of these, to reduce the load. Check for uneven distribution of signals load across source nodes. Also check for hardware faults and system performance on the command line (particularly check HLRA and HLRD process performances). If problem persists, escalate to Third Line Support.
2722
HIGH_TRAFFIC_LOAD
Class: Type: Full text: Description:
A2 Condition High signal traffic load The rate of incoming signals traffic is very high for the performance of the application. The application is close to becoming overloaded. This may be caused by abnormally high levels of traffic, possibly as a result of having provisioned too many subscribers on this platform. It may equally be caused by platform resource problems, a hardware fault., or excessive network traffic caused by a nationally or internationally significant event.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 7 Alarms
165
There is no service loss though there is an imminent risk of total signal traffic service loss. This would constitute a critical service loss.
Response:
First Line Support: Report to Second Line Support. Second Line Support: Check the number of subscribers in the live database using the Database utility, DBVIEW. If this is abnormally high, consider executing an SDM for some of these to reduce the load. Check for uneven distribution of signals load across source nodes. Also check for hardware faults and system performance on the command line (particularly check HLRA and HLRD process performances). If problem persists, report to Third Line Support.
4000
APPLICATION_WARNING
Class: Type: Full text: Description:
A2 Event Application warning: <event> This alarm is used as a ’catch all’ for general events that need to be captured. This does not indicate any service loss, although the event may imply a maintenance issue that could potentially lead to a more serious failure.
Response:
First Line Support: Report to Second Line Support. Second Line Support: Report to Third Line Support.
Class: Type: Full text: Description:
2
SLAVE_DATABASE_CORRUPT A2 Instance DR-triad slave database corrupt A DR-Triad Slave Database is corrupted. This means that there may be no redundancy for the corresponding Master Database on another HLR in the Triad.
Home Location Register (Linux) V1.1 Support Guide
166
Chapter 7 Alarms
This indicates no loss of service, but does indicate a high risk that the corresponding Master HLR node has no Disaster Recovery capability.
Response:
Check there is another good slave database for the corresponding Master HLR. Report to Second Line Support.
ALARMS_RESET Class: Type: Full text: Description:
A2 Clear All Alarms reset This alarm will be used by the SNMP agent as a trigger to cease all raised alarms and those corresponding values in the MIB. This will be transmitted on application startup by the Alarm Server (see below). It is the first alarm transmitted. This indicates no service loss and will be invisible to First Line Support. Other alarm interfaces should also use this alarm to cease all raised alarms.
Response:
Not applicable.
Home Location Register (Linux) V1.1 Support Guide
2
167
Chapter 8
SIGTRAN Configuration SIGTRAN is a high speed signalling transport mechanism that allows SS7 traffic to be carried over IP. This means that overloading of C7 Signalling Transfer Points (STPs) connecting the HLRs, SCCP Relays and MSCs can be avoided, as the link is now over the IP network. SIGTRAN removes the bottleneck limiting the number of subscribers an IN node can handle. This leads to a doubling in the number of subscribers that each database can hold. The SIGTRAN configuration table is described in hsscfg Table on page 495.
Stack Layers and Implementation SIGTRAN consists of general signalling layers at the bottom of the stack and specific communications layers at the top. The layers used depend on the stacks used by the remote entity and the type of deployment and control required. The layer at the bottom of the stack is the Stream Control Transmission Protocol (SCTP) which runs over IP. The M3UA layer is used to connect the HLR to the MSCs based on the Point Code of the entity (see Figure 45). Figure 45. M3UA and M2UA layers SCCP
SCCP
M3UA
MTP3
End-to-end communications
SCTP
MTP2
Communications between adjacent nodes
SIGTRAN provides APIs to any upper layers (such as SCCP) so that they can function in the normal manner. The IP layer deals with addressing and getting packets to the destination. SCTP provides connections to the remote system. M3UA replaces the MTP3 and MTP2 layers, and instead interfaces to SCTP, accepting point codes and other data that SCCP sends. M3UA uses the concept of Application Servers (AS) and Application Server Processes (ASP) as end-points. The HLR and SCCP Relay is the AS while the HLRA and SCCPA processes represent the ASP.
2
Home Location Register (Linux) V1.1 Support Guide
168
Chapter 8 SIGTRAN Configuration
The ASP on the live side is active (ASP-ACTIVE state) as is the AS. The ASP on the stand-by side is in the ASP-INACTIVE state. The following ASP states apply: • DOWN • INACTIVE • ACTIVE The AS has the following states: • DOWN • INACTIVE • ACTIVE • PENDING During a cutover, the new live side becomes ASP-ACTIVE and the old live side becomes ASP-INACTIVE. The SCTP layer on each node maintains the connection to 2 Ethernet cards providing IP connectivity, thus independently linking the connection to the remote systems.
SIGTRAN Processes
A new process called HSSP maintained by MGTA controls the SIGTRAN functionality.
Signalling Gateway (SG) Mode The HLR can talk to entities that do not have SIGTRAN capability, by operating in SG mode. The HLR has the ability to communicate over SIGTRAN to both remote IPSPs (IPSP-IPSP mode) and remote SGs (ASP-SG mode). A remote IPSP is, for example, an SCCP Relay or an MSC that has an application running over M3UA. A remote SG contains remote SGPs, and they in turn talk to classical SS7 entities. Figure 46 illustrates how an HLR can communicate with an SCCP Relay in IPSP-IPSP mode, and with non-SIGTRAN entities in ASP-SG mode.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 8 SIGTRAN Configuration
169
Figure 46.
HLR
IP network
Signalling Gateway
SS7 network
SCCPR
2
Home Location Register (Linux) V1.1 Support Guide
170
Chapter 8 SIGTRAN Configuration
SIGTRAN and the Vodafone Application The SIGTRAN software supplied by Flextronics provides: • an interface that allows the HLR application to send and receive messages. • an interface that allows the Vodafone S7MP process to control and configure SIGTRAN (see Vodafone pds_i_s7mp Process on page 170).
SIGTRAN on the VodaSCP Platform
Figure 47 below shows how SIGTRAN fits in with the HLR application.
Figure 47. How SIGTRAN fits in with the HLRR
HSSP Process HLR Application HLRA
SIGTRAN Management Application S7MP
SIGTRAN counter tables
SIGTRAN API functions
SIGTRAN Management API functions
SIGTRAN Stack
Pulse Utility
Vodafone pds_i_s7mp Process The S7MP process, pds_i_s7mp, starts at system startup and communicates with the SIGTRAN process pds_i_hssp.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 8 SIGTRAN Configuration
171
The S7MP process uses the SIGTRAN configuration table hsscfg.dat to configure the SIGTRAN stack on the platform. During system startup, pds_i_s7mp: • Configures the HSSP process via the management API to create the necessary remote entites in the local SIGTRAN stack. Depending on whether each remote ASP is configured as a client or server: • Via the management API, triggers the sending of ASPUP and ASPAC to bring the SIGTRAN associations live. • Waits for incoming ASPUP and ASPAC. When the platform is in service, pds_i_s7mp: • Monitors SIGTRAN events passed back to it via the management API. • Acts on SIGTRAN events by raising alarms. • Regularly retrieves statistical information from the SIGTRAN stack and updates the SIGTRAN counters for use by the PULSE utility.
2
Home Location Register (Linux) V1.1 Support Guide
172
Chapter 8 SIGTRAN Configuration
SIGTRAN Startup and Configuration Management process MGTA starts each of the PDS processes, activates each process and expects to get an acknowledgement response from each one in turn. If an acknowledgement response is not received within the expected time period, the platform will restart. The S7MP process reads the hsscfg.dat file, and once the HSSP ready signal is received, S7MP configures the SIGTRAN stack. The HLRA application registers with the HSSP process once the database is loaded into memory. The S7MP process receives an indication from the stack that the application is available, and will then acknowledge ASPAC requests from clients, or send ASPUP/ASPAC requests to servers, so bringing the SIGTRAN signalling up, and the platform into service. Figure 48. SIGTRAN Startup MGTA startup sequence 1
OMCS
2
S7MP HSSP Ready signal
3
HSSP
4
MP
5
HLRD
6
ADM
7
HLRA
Home Location Register (Linux) V1.1 Support Guide
Application registration
2
Chapter 8 SIGTRAN Configuration
173
Updating SIGTRAN Configuration Files SIGTRAN configuration changes are made by editing the SIGTRAN Configuration Table (hsscfg) (see page 495) using the table change procedure described in Changing Tables on page 456. Remote AS/ASPs can be added or removed without stopping and restarting the system. Any other changes require a complete system stop and restart as described in Restarting the HLR Application on page 115. After editing the SIGTRAN Configuration Table, the VERIFY:TABLE command (see page 462) checks the syntax of remote AS and ASPs and generates error messages if the syntax of the edited table is incorrect. When the REPLACE:TABLE command (see page 461) is used for the updated SIGTRAN Configuration Table, the new table is checked to determine whether the system must be restarted, as shown below: Figure 49. Updating SIGTRAN Configuration replace:table,hsscfg
Compare new configuration with the Table in Memory
System restart needed?
Yes
Refuse table replace with an error message indicating that a pds restart is required
No
Send SIGTRAN configuration changes to PDS management process (pds_i_mgta)
Copy hsscfg table to Table in Memory and Table File
Remote Engineer The SIGTRAN configuration files cannot be updated from the Remote Engineer account.
2
Home Location Register (Linux) V1.1 Support Guide
174
Home Location Register (Linux) V1.1 Support Guide
Chapter 8 SIGTRAN Configuration
2
175
Chapter 9
Administration Interface This chapter describes the HLR Administration Interface used to manage the HLR subscriber database. It includes: • Client Types below. • Accessing the Administration Interface on page 176. • Command Notation on page 177. • Command Syntax on page 178. • Response Syntax on page 179.
Client Types Several clients use the administration interface, including: • Interactive session. • Administration Replication for forwarding commands from master to slave nodes. • ISAAC, the International Subscriber Administration and Control System used to maintain IMSI details. • IN_VIEW, the utility used to browse subscriber details. • Network test. • MMI. • TM, for table maintenance • PIRR, the Packet Inspection, Rating and Reservation element, which can use the ADD:BAR and REMOVE:BAR commands to disconnect data sessions, when a PrePay subscriber’s credit runs out for example. Every admp process has a client type associated with it, and the client type is specified on the command line when an admp process is started. Client types are defined in the adm_client data table.
2
Home Location Register (Linux) V1.1 Support Guide
176
Chapter 9 Administration Interface
Accessing the Administration Interface To access the Administration Interface enter: admp (-c ) (-t ) where: Parameter
Values
Default
Description
client_type
Client name string
INTERACTIVE
Client types are listed in the adm_client Table. The adm_client Table lists the commands the client is allowed to use and the default timeout.
transport_type
INTERACTIVE TCPIP
INTERACTIVE
INTERACTIVE - an interactive session, such as is used by support staff. TCPIP - connection through the TCP/IP interface.
The command prompt is displayed: (node_name)adm> node_name is the name of the HLR node. To exit, enter: exit
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 9 Administration Interface
177
Command Notation The commands in this appendix are written using the following notation: • Literal items - text you should type exactly as shown is written in upper-case. For example: VIEW:SUB Note: You can enter administration commands using either upper or lower case letters. • Variables (except for dates and times) are shown in lower-case italic text. Underscores are used instead of spaces between words. For example: service_id • Optional items (parts of the command or response lines that may be omitted, such as flags) are enclosed in parentheses. For example: (prefix) • Alternative items, where you must choose one literal or variable from a list, are separated by vertical bars, |. For example: INCOMING|OUTGOING means choose either INCOMING or OUTGOING, but not both. • Braces {} surrounding a parameter show that you can enter more than one, each separated from the next by a comma. Note: All commands and responses occupy a single line in the Interface. However, some of the format descriptions in this appendix are so long that they are shown on two lines.
2
Home Location Register (Linux) V1.1 Support Guide
178
Chapter 9 Administration Interface
Command Syntax Commands on the HLR have the format: verb:object{,(parameter)};(comment) Note: The general commands, EXIT, HELP and INFO, do not have the above format. - object is what the command acts on; for example a record in the HLR database. - verb describes the action performed on the object; for example: VIEW displays details of an object. - parameter modifies the action of the verb. They are mostly variables and literal flags. Separate parameters with a comma. - comment is any character string. • A command can have up to 20 parameters. • The command line must not exceed 256 characters, including comments. • All commands must end with a semi-colon. Any text on the same line, but following the semi-colon terminator is treated as a comment and ignored by the parser. • Each missing optional parameter must be replaced by a comma, except for any immediately before the terminating semi-colon. Note: Likewise, commas are not displayed for missing optional parameters at the ends of command responses. • Tabs and spaces are ignored, except where they are part of a parameter.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 9 Administration Interface
179
Response Syntax The general form of response to an administration command is: C2:message_id{,user_message}; C1:status_code,error_code; - status_code is a 5-digit code indicating that a command was successful, or that it failed because, for example, the command was not known or contained a syntax error. See Table 16 below. - error_code is a 5-digit code indicating that the command was successful, or that it failed for a data-related reason, such as a lack of space in the database. See Table 17 on page 180. - message_id is a 5-digit code that indicates the kind of information returned by the command (location information or supplementary services for example), or a reason for failure. See Table 18 on page 186. - user_message is data returned by the command.
Response Codes C1 Messages
C1 messages are known as command completion messages and show that the command has been processed. Table 16. C1 status_code Values
status_code
error_code
Text and Meaning
00000
See Table 17
Success - the command worked correctly.
00001
Non serious error - a minor error occurred.
00002
Serious error - a major error occurred.
00003
00001
Syntax violation - command is not correct for the platform’s information protocol.
00004
00001
Unknown command - the command verb or object type is not recognised.
00005
00001
Invalid command for this user type - you are not authorised to use this command.
00006
00000 – too few parameters 00001 – too many parameters
Incorrect number of parameters - you have entered too many or too few parameters.
00007
Specifies position of first invalid parameter
Invalid parameter value - the value specified is not supported.
00008
00001
Internal software error.
2
Home Location Register (Linux) V1.1 Support Guide
180
Chapter 9 Administration Interface
The error_code relates the command failure to the subscriber data. Table 17 describes the HLR error_code values. Table 17. C1 error_code Values error_code
Message
Meaning/Action
00000
Success
The command has completed successfully.
00001
Subscriber IMSI already in use
The IMSI is already in the database, check the IMSI to be used.
00002
Record not found
The specified item is not in the database.
00004
Subscriber MSISDN already in use
The MSISDN is already in the database, check the MSISDN to be used.
00006
Unable to create subscriber
The database is full. Contact your support services immediately.
00007
Subscriber MSISDN /IMSI mismatch
The IMSI and MSISDN for the subscriber do not match. Specify the correct identity for the subscriber’s number.
00008
Overlapping IMSI not pending for any subscriber
The IMSI specified is not waiting to be used by a subscriber, it is the current IMSI for the subscriber.
00009
Overlapping IMSI already in use
The IMSI is already in the database, check the IMSI to be used.
00011
Subscriber already has overlapping IMSI
The subscriber has already been assigned an overlapping IMSI.
00012
Subscriber IMSI/overlapping IMSI mismatch.
The IMSI and the Overlapping IMSI for the subscriber do not match. Specify the correct identity for the subscriber.
00019
Service request number already in use
The SRN is already in the database, check the SRN to be used.
00021
Service request number/service access number mismatch
The SRN and SAN do not match. Specify the numbers so that they match.
00022
Duplicate Zone Codes Specified
The same zone code was specified twice in a zone code list. Make sure that all zone codes in the list are different.
00023
Data missing error
You have not specified the forward-to number in the command. Specify the FTN value in the command.
00024
Unexpected data value error
One of the parameters specified is out of range or has an illegal value. For example: forward-to number is disallowed or the timer does not have a value that is a multiple of 5. Re-enter the command giving the correct parameter values.
Either: The basic service group specified contained no basic services subscribed to by the subscriber and applicable to the supplementary service concerned. Or: The request is inappropriate to the supplementary service specified.
00026
SS error status
The service is not provisioned.
00027
Bearer service not provisioned
The basic service or basic service group specified contains no basic service subscribed to by the subscriber.
00028
Teleservice not provisioned
The basic service or basic service group specified contains no basic service subscribed to by the subscriber.
00029
Subscriber has maximum zone lists
The number of zone lists allowed for a subscriber was exceeded. A zone list identifies geographical areas as part of regional subscription data (used for home zone charging). One zone list corresponds to one country code (CC) and national destination code (NDC) combination.
00033
Cannot update authentication algorithm and key separately
You must specify both the algorithm and key in the command or omit both of them.
00036
Subscriber already has P number
The published number already exists in the database.
00038
Duplicate MSISDN specified
The MSISDN is the same as one already in the database. Specify another number for the MSISDN.
00039
Unable to add overlapping IMSI
00041
Unable to add MSISDN
The database is full. Contact your support services immediately.
00043
Unable to create service request number
00044
Unable to add P number
00046
Incorrect number of MSISDNs specified
You have specified the wrong number of MSISDNs for the template. Specify the correct number for the template.
00047
Cannot remove main MSISDN
You cannot remove the main MSISDN without deleting the entire subscriber record.
2
The database is full. Contact your support services immediately.
The database is full or the VLR interworking connection has failed. An alarm will display what has happened. Escalate the problem to your support services.
00050
Unable to activate supplementary service
00051
Unable to deactivate supplementary service
00053
Cannot copy template with PNUM
Attempt to create a subscriber using a template with a PNUM that is already in the database. Use a different value for PNUM.
00055
Unable to access subscriber record
The record is locked in another update, try again later. If the problem persists, treat as error_code 00099.
00058
CSI TDP combination not in use by subscriber
An attempt was made to remove information associated with a CAMEL trigger detection point (TDP) but the TDP is not used by the subscriber.
00059
BC title not known
The BC title specified is not known by the HLR. Specify the correct text for the BC title.
00060
Unable to initiate Cancel Location
The cancel location has failed, re-enter the command.
00061
HLR updated but Subscriber Data download failed
The HLR database has been updated, but the subscriber is still registered on the VLR.
00062
Invalid identifier for encryption key or integrity key
The encryption key or integrity key identifier is invalid. Check that the value of the identifier is correct.
00063
Integrity key not held in HLR table
The transport key corresponding to the key identifier cannot be found or is invalid. Check that the key identifier is correct.
00064
Integrity check algorithm not found for given key
The algorithm corresponding to the key identifier cannot be found. Check that the value of the key identifier is correct.
00065
Integrity check failed
The authentication data integrity check has failed. Contact your support services immediately.
00066
Encryption key not held in HLR table
The transport key corresponding to the key identifier cannot be found or is invalid. Check that the key identifier is correct.
00067
Encryption algorithm not found for given key
The algorithm corresponding to the key identifier cannot be found. Check that the value of the key identifier is correct.
00068
Encryption/decryption algorithm internal error
An internal error has occurred when decrypting the subscriber key. Contact your support services immediately.
There is a software fault, report it to your support services.
00100
Cannot remove published DN
The published MSISDN is not in the database.
00101
Invalid parameter value
An invalid parameter value was specified.
00114
Configurable CAMEL GSMSCF GT unavailable
The HLR received a request to update the CAMEL GSMSCF Global Title to the configurable value defined in the hlr_config table. This field was not present when the table was loaded, so the command failed.
00115
Sequence number should be updated to a higher value
The HLR received a request to update the sequence number to a value lower than or equal to the subscriber sequence number. Check the value of the sequence number.
00116
Unable to allocate resource
The database is full. Contact your support services immediately.
00118
Subscriber already has maximum number of PDP contexts
An attempt to provide a subscriber with a GPRS service failed because the subscriber already has the maximum number of services, defined by MAX_PDP in the hlr_config table (see page 477).
00119
Incorrect address for PDP type
The address specified for a PDP context did not match the TYPE attribute of the context. Check that the address is correct.
00120
Context ID not in use by subscriber
An attempt was made to change a PDP context that the subscriber does not have. Check that the context is correct.
00121
Unable to enable PDP context, type not set
A PDP context cannot be enabled unless the type of address the PDP context uses has been specified. Make sure that the address type is correct.
00122
Subscriber already has the maximum number of service centres
When using the SET:MWD command, an attempt was made to set more than the maximum permitted number of MSISDNs.
00123
Subscriber already has the maximum number of MSISDNs
When using the ADD:MSISDN command, an attempt was made to set more than the maximum permitted number of MWD records.
00124
Invalid CCH and CAMEL data combination
An attempt is being made to add CAMEL data for CAMEL subscription information (CSI) that cannot have that data, because of its CAMEL capability handling (CCH) values (see page 334 for an example). To add the data, first change the CCH to appropriate values.
00125
Attempt to remove mandatory CSI data
An attempt was made to remove mandatory data associated with particular CAMEL subscription information (CSI).
For CAMEL 3, a particular CSI is not allowed to have more than 5 associated basic service criteria values.
00127
SIM ID is already in use
The SIM identity specified for the new SIM (an integer from 0 to 9) is used by another SIM in the MultiSIM subscription.
00128
Unable to allocate a new SIM
The new SIM cannot be added. Either the subscription already has 10 SIMs (the maximum allowed), or the HLR database has run out of resource. If the subscriber does not already have 10 SIMs, contact your support services immediately.
00129
SIM ID does not match IMSI
The SIM identity specified does not match the identity stored in the HLR for that IMSI.
00130
Unable to initiate alert
00131
SIM still has nomination
The SIM cannot be removed because it is the last SIM left in the subscription or because it is still nominated for one or more basic services.
00132
SIM ID not in use
The SIM identity specified has not been assigned to an IMSI.
00133
Unable to set encryption ROAMED
Encryption cannot be disabled for a roamed subscriber.
00134
Encryption already at specified state
An attempt was made to enable encryption for a subscriber with encryption already enabled, or disable encryption for a subscriber with encryption already disabled.
00135
Unable to set/cancel TIMER
The HLR is unable to set a timer. This is an internal software error. Contact your support services immediately.
00137
Unable to set trace
00142
HLR file not found.
The SDM configuration file is not found. The SDM cannot be performed.
00143
SDM file not found.
The specified SDM configuration file is not found. The SDM cannot be performed.
00144
Invalid HLR node file format.
The SDM configuration file is badly formatted. The SDM cannot be performed.
00145
Invalid SDM file format.
The specified SDM configuration file is badly formatted. The SDM cannot be performed.
00146
Unknown destination HLR.
The destination HLR is not specified in the SDM configuration file. The SDM cannot be performed.
00147
Invalid HLR configuration data.
The HLR configuration data in hlr_config is invalid.
00148
Failed to create template IMSI.
The Template IMSI could not be created for the SDM. The SDM cannot be performed.
The SDM cannot allocate enough tasks. The SDM cannot be performed.
00150
Failure to establish TCPIP link.
The TCPIP link for forwarding SDM Admin commands to the destination HLR could not be established.
00151
TCPIP link failure.
TCPIP link failure when source HLR communicating with either destination HLR or SCCPR.
00152
Failed to open log file.
SDM log file could not be opened.
00153
Cannot delete template IMSI.
Failure to delete template IMSI following SDM.
00154
Cannot SDM to specified HLR.
Cannot SDM to specified HLR since source and destination HLR must be different.
00155
Emlpp default priority greater than maximum allowed.
00156
Unable to reset recache bit and initiate trigger to NBS.
00157
Could not update data for pending SIM.
00158
Unknown off node PIPC service.
00165
Admin Forward got bad response.
The response received by the source HLR from the destination HLR was not recognized.
00166
Admin Forward got no response.
The source HLR received no response from the destination HLR.
00167
Invalid database.
The database specified is not active.
00168
Admin Forward failed because of TCP error.
The source HLR was unable to forward the command to the destination HLR because of a network error.
00169
Admin Forward disallowed for this command.
This command cannot be forwarded.
00170
Soft SDM Aborted.
Soft SDM was aborted manually, by changing the SDM_STOP flag in the hlr_config table to TRUE during Soft SDM.
00171
Soft SDM Disabled.
Soft SDM is disallowed, because the value of the SDM_STOP flag in the hlr_config table was set to TRUE before Soft SDM was started.
00172
MSISDN has no country code.
The MSISDN used to format the divert contains the wrong country code, indicating that published number of a linked subscription is wrong in the member record.
00173
ISDN cannot be formatted.
The length of the divert is more than 15 digits. This is probably because the prefix defined in the [DIVERT_FORMAT] section of the voicemail table is too long.
2
Home Location Register (Linux) V1.1 Support Guide
186
C2 Messages
Chapter 9 Administration Interface
C2 messages are known as user messages and have the format: C2:message_id,{user_message}; user_message is the data returned in response to the command and Table 18 lists message_id values. For details of the user message responses, see the Response section of the VIEW:SUB command. Table 18. Supported message_id Values message_id
Associated user_message
00001 00002 00003
Access denied - maximum number of users exceeded Access denied - platform not running Access denied - software failure Session aborted by application Session disconnected for admin reconfiguration
00010
IMSI View
00011
, where type is IMSI or MSISDN, and value is the corresponding value.
00012
Supplementary Services View
00013
General Subscriber Data View
00014
Voicemail Information
00015
MSISDN Basic Services View
00016
Subscriber Basic Services View
00017
Subscriber Supplementary Service Status View
00018
Service Centres View
00019
Last Caller Information View
00020
Network Entity View
00023
Published Number View
00024
Trace Information
00028
IMSI or MSISDN information
00029
PDP Context Information
00030
Home Zone Information
00040
Location View
00041
Ericsson PSI Information
00042
Provide Subscriber Information (PSI) Information
00043
IN Service View
00044
O-CSI CAMEL Information
00045
GPRS-CSI CAMEL Information
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 9 Administration Interface
187
Table 18. Supported message_id Values (Continued)
2
message_id
Associated user_message
00046
MOSMS-CSI CAMEL Information
00047
T-CSI CAMEL Information
00048
D-CSI CAMEL Information
00049
VT-CSI CAMEL Information
00050
M-CSI CAMEL Information
00051
SS-CSI CAMEL Information
00052
U-CSI CAMEL Information
Home Location Register (Linux) V1.1 Support Guide
188
Home Location Register (Linux) V1.1 Support Guide
Chapter 9 Administration Interface
2
189
Chapter 10
List of HLR Administration Commands
The table below lists the administration commands for the HLR, apart from table maintenance commands: these are described in Chapter 24. Command
Description
See
ACTIVATE:SS
Activate a supplementary service. For example, call barring.
page 327
ADD:BAR
Add an individual operator determined bar for a subscriber.
page 435
ADD:CAMEL
Add CAMEL data for a subscriber
page 332
ADD:MSISDN
Add an MSISDN to a subscriber record.
page 280
ADD:OVERLAP
Add an overlapping IMSI to a subscriber record.
page 274
ADD:PDP
Add a single blank PDP context to a subscriber.
page 298
ADD:PNUM
Add a published (P) number to a subscriber record.
page 416
ADD:SERVICE
Adds a basic service to a subscriber record.
page 310
ADD:SIM
Add a SIM to an existing subscription
page 194
AUCUPDATE:SUB
Update the authentication data in the integrated HLR/AUC database.
page 266
COMPLETE:SDM
Completes the process of moving subscribers from one HLR to another, by deleting them from the source HLR.
page 422
COPY:SUB
Create a subscriber record from an existing subscriber template.
page 208
CREATE:SRN
Create a service request number (SRN) in the database.
page 290
CREATE:SUB
Create a subscriber record in the database.
page 206
DEACTIVATE:SS
Deactivate a supplementary service.
page 329
DELETE:SRN
Deletes a service request number from the database.
page 291
DELETE:SUB
Delete a subscriber record and all associated records, for example MSISDN information, from the database.
page 211
ERASE:SS
Erase a supplementary service.
page 325
EXECUTE:SDM
Moves a subscriber or range of subscribers to a different HLR.
page 420
INITIATE:ALERT
Unlock the short message service
page 426
INITIATE:CANCEL
Initiate a cancel location for a specified subscriber on a specified VLR (or SGSN).
page 428
INITIATE:RESET
Send a Reset MAP message to a specified VLR from a specified HLR.
page 430
LOCK:SUB
Lock a subscriber record in the database.
page 213
2
Home Location Register (Linux) V1.1 Support Guide
190
Chapter 10 List of HLR Administration Commands
Command
Description
See
PROVISION:SS
Gives a subscriber the ability to use a supplementary service.
page 318
REGISTER:SS
Register and activate an individual call forwarding service.
page 322
REMOVE:BAR
Remove an individual operator determined bar for a subscriber.
page 437
REMOVE:CAMEL
Remove CAMEL subscription information from a subscriber.
page 373
REMOVE:MSISDN
Remove an MSISDN from a subscriber record.
page 282
REMOVE:OVERLAP
Remove an overlapping IMSI from the database.
page 278
REMOVE:PDP
Remove a PDP Context from a subscriber.
page 306
REMOVE:PNUM
Remove a published number (P number) from a subscriber record.
page 418
REMOVE:SERVICE
Remove a basic service from a subscriber’s record.
page 312
REMOVE:SIM
Remove a SIM from a MultiSIM subscription
page 196
REPLACE:OVERLAP
Force an overlapping IMSI to become the current IMSI and delete the existing IMSI.
page 276
RESET:SEED
Reset the initial random number generated by the HLR, using a random means.
page 439
ROLLBACK:SDM
Rolls back moving subscribers between HLRs, in case of failure.
page 423
SET:CAMEL
Sets CAMEL data for subscriber.
page 362
SET:MWD
Forces message waiting data to be associated with an MSISDN.
page 433
SET:PDP
Set PDP data.
page 300
SET:SEED
Set the next ‘random’ number generated by the HLR to a specific value.
page 440
SET:TRACE
Log transaction or SS7 events to log files.
page 269
UNLOCK:SUB
Unlock a subscriber record in the database.
page 214
UPDATE:CAMEL
Modify subscriber information associated with CAMEL services.
page 375
UPDATE:IMEI
Change the values of the IMEI fields.
page 441
UPDATE:LCN
Updates the last calling information for a subscriber.
page 443
UPDATE:LOCATION
Updates the location information for a subscriber.
page 445
UPDATE:MSISDN
Update the bearer capability (BC) title associated with the MSISDN.
page 284
UPDATE:PDP
Populate a new PDP context with data, or change an existing profile.
page 302
UPDATE:SIM
Specify whether SIM is 2G or 3G, or update authentication parameters or message waiting information.
page 198
UPDATE:SRN
Update service request number (SRN) attributes.
page 292
UPDATE:SUB
Update subscriber attributes in the database.
page 215
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 10 List of HLR Administration Commands
191
Command
Description
See
UPDATE:ZONELIST
Update the zone code list used for home zone charging.
page 228
VIEW:INFO
Display information about the platform.
page 448
VIEW:MSISDN
Display the attributes of a specified MSISDN.
page 286
VIEW:NETWORK
Display data associated with a network entity.
page 409
VIEW:SRN
Display the Service Access Number (SAN) associated with the service request number in the database and its Trace Status.
page 294
VIEW:SUB
Display subscriber attributes in the database.
page 231
WITHDRAW:SS
Remove a supplementary service from a subscriber.
page 320
2
Home Location Register (Linux) V1.1 Support Guide
192
Chapter 10 List of HLR Administration Commands
Home Location Register (Linux) V1.1 Support Guide
2
193
Chapter 11
SIM Commands
Subscriber Identity Modules (SIMs) can be one of two types, those for the second generation (2G) network and those for the third generation (3G) UMTS network. Authentication works differently in the two network types, and authentication information for a SIM can be configured via the administration interface.
2
Command
Description
Page
ADD:SIM
Adds a SIM to an existing subscription (see MultiSIM on page 46)
page 194
REMOVE:SIM
Remove a SIM from a MultiSIM subscription
page 196
UPDATE:SIM
Change the SIM type, SIM identity or authentication parameters
page 198
Home Location Register (Linux) V1.1 Support Guide
194
Chapter 11 SIM Commands
ADD:SIM Add a SIM to a MultiSIM subscription (see MultiSIM on page 46). The added SIM has the same published number (MSISDN) as the existing subscription.
Syntax ADD:SIM,IMSI|MSISDN,,, (<sim_id>);
Parameters Parameter
Meaning
IMSI|MSISDN
Indicates whether is an IMSI or an MSISDN
MSISDN or IMSI that identifies an existing subscription. The new SIM is added to this existing subscription
The IMSI of the new SIM
<sim_id>
Integer from 0 to 9. Specifies the SIM identity of the added SIM. If <sim_id> is not specified, then the first free ID is used.
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 11 SIM Commands
195
Errors <error_code>
<error_message>
00001
Subscriber IMSI already in use. A new IMSI was specified that is used by an existing subscriber.
00002
Record not found.
00099
Internal software error.
00127
SIM ID is already in use. The SIM identity specified for the new SIM (an integer from 0 to 9) is used by another SIM in the MultiSIM subscription.
00128
Unable to allocate a new SIM. The new SIM cannot be added. Either the subscription already has 10 SIMs (the maximum allowed), or the HLR database has run out of resource.
Example In this example, an IMSI is successfully added to a subscription: ADD:SIM,MSISDN,123412341234,123451234512346,3; GSM HLR - SIM Added Subscriber IMSI
- 123451234512346
In this example, the MSISDN specified does not exist: ADD:SIM,MSISDN,123412341233,123451234512347,1; C1:00002,00005,Subscriber MSISDN not in use;
2
Home Location Register (Linux) V1.1 Support Guide
196
Chapter 11 SIM Commands
REMOVE:SIM Remove a SIM from a MultiSIM subscription (see MultiSIM on page 46) subscription.
Syntax REMOVE:SIM,,(<sim_id>);
Parameters Parameter
Meaning
IMSI that identifies the SIM to remove
<sim_id>
Integer from 0 to 9. Specifies the SIM identity of the SIM to remove
If <sim_id> is specified, the SIM will be removed only if <sim_id> matches the one stored in the HLR for the specified . If <sim_id> is not specified, the SIM with the specified will be deleted regardless of its SIM identity. Note: It is not possible to remove a SIM that is still nominated for any basic service groups (BSGs). To remove a SIM that is still nominated, you must first remove its nominations. It is not, therefore, possible to remove the last SIM in a subscription, because its nominations cannot be removed.
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 11 SIM Commands
197
Errors <error_code>
<error_message>
00002
Record not found.
00099
Internal software error. An internal error has occurred; escalate to the next line of support.
00129
<sim_id> does not match IMSI. The SIM identity specified does not match the identity stored in the HLR for that IMSI.
00131
SIM still has nomination.
Example This example shows an attempt to remove a SIM, but with the wrong SIM identity specified: REMOVE:SIM,123451234512346,1; C1:00002,00129,SIM ID does not match IMSI;
The SIM is successfully removed without specifying the SIM ID: REMOVE:SIM,123451234512346; GSM HLR - SIM Removed Subscriber IMSI
- (none)
An attempt to remove the last SIM in the subscription fails: REMOVE:SIM,123451234512345; C1:00002,00131,Unable to remove nominated SIM;
2
Home Location Register (Linux) V1.1 Support Guide
198
Chapter 11 SIM Commands
UPDATE:SIM The UPDATE:SIM command can change the type of a SIM, its SIM identity (used for MultiSIM subscriptions) and its authentication attributes.
Syntax UPDATE:SIM,,,, {()};
Parameters Parameter
Meaning
IMSI or overlapping IMSI associated with the SIM
Attribute name indicating the SIM type, SIM identity, or an authentication attribute to change. See the table below.
Value for . See the table below.
Table 19. Authentication Attributes Attribute
Values
Default
Description
AUTH
NONE or a series of values that configure authentication
(mandatory)
NONE disables authentication. See Authentication Parameters on page 200 for a description of authentication parameters.
CS_IND
0 to 15
0
Circuit switched used to identify authentication vectors stored on a third generation SIM (USIM). A USIM can store up to 16 vectors. This index can be manually updated to keep sequence numbers in the correct order if subscriber data is moved between network entities.
MCEF
TRUE/FALSE
FALSE
Memory Capacity Exceeded Flag. Indicates whether delivery of a mobile terminated short message failed because of lack of capacity in the mobile station (handset). • no alerts are sent if this flag is set • this flag does not prevent the HLR returning routing information for a short message
Mobile station Not Reachable Flag. Indicates whether delivery of a non-GPRS mobile terminated short message failed because a subscriber was absent. • if this flag is set, the HLR does not return an MSC address as routing information • this flag is cleared if the HLR receives an alert stimulus, so this flag does not prevent alerts
MNRG
TRUE/FALSE
FALSE
Mobile station Not Reachable for GPRS. Indicates whether delivery of a GPRS mobile terminated short message failed because a subscriber was absent. • if this flag is set, the HLR does not return an SGSN address as routing information • this flag is cleared if the HLR receives an alert stimulus, so this flag does not prevent alerts
Mobile station not reachable reason for a GPRS subscriber. Value indicates why the previous SMS delivery attempt failed. For the numerical value in the subscriber database for each reason, see SMS Absence Reasons on page 623. NO_GSM_PAGE_RESP - No paging response via MSC IMSI_DETACHED - IMSI detached ROAM_RESTRICT - Roaming restriction DEREG_GSM - Deregistered in the HLR for non-GPRS MSPURGED_GSM - MS purged for non-GPRS NO_GPRS_PAGE_RESP - No paging response via the SGSN GPRS_DETACHED - GPRS detached DEREG_GPRS - Deregistered in the HLR for GPRS MSPURGES_GPRS - MS purged for GPRS UNK_GSM_SUB - Unidentified subscriber via the MSC UNK_GPRS_SUB - Unidentified subscriber via the SGSN NONE - (not GSM standard)
Mobile station not reachable reason for a GSM subscriber. Value indicates why the previous SMS delivery attempt failed. For the numerical value in the subscriber database for each reason, see SMS Absence Reasons on page 623. NO_GSM_PAGE_RESP - No paging response via MSC IMSI_DETACHED - IMSI detached ROAM_RESTRICT - Roaming restriction DEREG_GSM - Deregistered in the HLR for non-GPRS MSPURGED_GSM - MS purged for non-GPRS NO_GPRS_PAGE_RESP - No paging response via the SGSN GPRS_DETACHED - GPRS detached DEREG_GPRS - Deregistered in the HLR for GPRS MSPURGES_GPRS - MS purged for GPRS UNK_GSM_SUB - Unknown subscriber via the MSC UNK_GPRS_SUB - Unknown subscriber via the SGSN NONE - (not GSM standard)
PS_IND
0 to 15
0
Packet switched index similar to CS_IND.
SIMTYPE
SIM/USIM
SIM
Type of SIM SIM - second generation (2G) network USIM - third generation (3G) network
SIMID
0 to 9
(none)
SIM identity of one SIM in a MultiSIM subscription. A MultiSIM subscription can have up to 10 SIMs
SQN
0 to 243-1
0
Sequence number for SIM (2G) or USIM (3G) subscriber authentication
Authentication Parameters
The command that specifies authentication parameters for a subscriber has two forms, depending whether subscriber key encryption (SKE) is used. If subscriber key encryption is used, enter: UPDATE:SIM,,AUTH,,<encrypted_ki> ,<encryption_key_identifier>,,; If SKE is not used, enter: UPDATE:SIM,,AUTH,,;
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 11 SIM Commands
Parameter
201
Values
Default
Description
(mandatory)
Subscriber’s IMSI or overlapping IMSI.
1, 2, 3 or NONE
(mandatory)
1 - A38 algorithm, version 1 2 - test algorithm 3 - UMTS algorithm NONE - removes authentication from the subscriber
32 character text string containing characters 0 to 9 and A to F
(mandatory if SKE not used)
Authentication key.
<encrypted_ki>
32 character text string containing characters 0 to 9 and A to F
(mandatory if SKE used)
Encrypted authentication key.
<encryption_key_id entifier>
0x0000 to 0xFFFF
(mandatory if SKE used)
Encryption key identifier.
0x00000000 to 0xFFFFFFFF
(mandatory if SKE used)
Integrity checksum.
0x0000 to 0xFFFF
(mandatory if SKE used)
Integrity key identifier.
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
2
Home Location Register (Linux) V1.1 Support Guide
202
Chapter 11 SIM Commands
Errors <error_code>
<error_message>
00002
Record not found.
00033
Cannot update authentication algorithm and key separately.
00055
Unable to access subscriber record.
00061
HLR updated but Subscriber Data download failed.
00062
Invalid identifier for encryption key or integrity key .1
00063
Integrity key not held in HLR table. 1
00064
Integrity check algorithm not found for given key. 1
00065
Integrity check failed. 1
00066
Encryption key not held in HLR table. 1
00067
Encryption algorithm not found for given key. 1
00068
Encryption / decryption algorithm internal error.
00099
Internal software error.
00115
Sequence number should be updated to a higher value
00127
SIM ID already in use. The SIM identity specified in the command is already used by another SIM in the subscription.
00129
SIM ID does not match IMSI.
00131
SIM still has nomination. 1
Only if SKE is operational.
Example UMTS SIM
To specify a third generation (3G) SIM, enter: UPDATE:SIM,000001111122222,SIMTYPE,USIM; GSM PDS - SIM Updated Subscriber IMSI
SIM Identity
- 000001111122222
To specify a SIM identity, which is used in MultiSIM subscriptions, enter: UPDATE:SIM,000001111122222,SIMID,5; GSM PDS - SIM Updated Subscriber IMSI
Home Location Register (Linux) V1.1 Support Guide
- 000001111122222
2
Chapter 11 SIM Commands
Authentication Information
203
To update authentication information for a subscriber who does not have subscriber key encryption, enter: UPDATE:SIM,000001111122222,AUTH,1,0000000000111111 1111222222222233; GSM PDS - SIM Updated Subscriber IMSI
- 000001111122222
To update authentication information for a subscriber who has subscriber key encryption, enter: UPDATE:SIM,000001111122222,AUTH,1,0000000000111111 1111222222222233,9999,99999999,AAAA; GSM PDS - SIM Updated Subscriber IMSI
- 000001111122222
The example below returns an error because the has only 3 digits: UPDATE:SIM,000001111122222,AUTH,1,0000000000111111 1111222222222233,9999,99999999,ABC; C1:00007,00007,Invalid parameter value;
2
Home Location Register (Linux) V1.1 Support Guide
204
Home Location Register (Linux) V1.1 Support Guide
Chapter 11 SIM Commands
2
205
Chapter 12
Subscriber Commands
Subscriber commands let you change subscriber information in the HLR database.
2
Command
Description
Page
AUCUPDATE:SUB
Updates the authentication data in the integrated HLR/AUC database
page 266
COPY:SUB
Creates a subscriber record using an existing subscriber as a template
page 208
CREATE:SUB
Creates a subscriber record
page 206
DELETE:SUB
Deletes a subscriber record and all associated records
page 211
LOCK:SUB
This command locks a subscriber record in the database. This command is for development and is not used in normal operation
page 213
SET:TRACE
Logs transaction or SS7 events to log files, to the screen (for real-time tracing), or makes event records available to off-platform tracing (for TIMON tracing)
page 269
UNLOCK:SUB
This command unlocks a subscriber record in the database. This command is for development and is not used in normal operation.
page 214
UPDATE:SUB
Updates subscriber attributes in the database
page 215
UPDATE:ZONELIST
Updates a zone code list for a subscriber
page 228
VIEW:SUB
Displays subscriber attributes in the database
page 231
Home Location Register (Linux) V1.1 Support Guide
206
Chapter 12 Subscriber Commands
CREATE:SUB The CREATE:SUB command creates a subscriber record in the database.
Syntax CREATE:SUB,,<msisdn>,;
Parameters Parameter
Meaning
Subscriber IMSI
<msisdn>
Main MSISDN
Text (up to 16 characters) containing the Bearer Capability title associated with the main MSISDN
Every MSISDN record must be associated with a . This name is used to locate a Bearer Capability Allocation in the BCA table. See Bearer Capabilities (bca) table for details of this table.
MultiSIM Subscriptions
When a new subscriber is created, the default SIM ID (used to distinguish SIMs in a MultiSIM subscription) is 0 (zero). See MultiSIM on page 46 for a description of MultiSIM subscriptions.
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
207
Errors <error_code>
<error_message>
00001
Subscriber IMSI already in use.
00004
Subscriber MSISDN already in use.
00038
Duplicate MSISDN specified.
00046
Incorrect number of MSISDNs specified.
00053
Cannot copy template with PNUM.
00055
Unable to access subscriber record.
00059
BC title not known.
00099
Internal software error.
00116
Unable to allocate resource.
Example To create a subscriber with a specified IMSI and MSISDN and associate the main MSISDN with the telephony service (TS11): CREATE:SUB,111112222233333,11111222223,TS11; GSM PDS - Subscriber Created Subscriber IMSI - 111112222233333 Main MSISDN- 11111222223
2
Home Location Register (Linux) V1.1 Support Guide
208
Chapter 12 Subscriber Commands
COPY:SUB The COPY:SUB command creates a subscriber record using an existing subscriber as a template. Using a template allows you to create a record without having to specify all the services for each subscriber.
Syntax COPY:SUB,,, <main_msisdn>,{<msisdn>};
Parameters Parameter
Meaning
IMSI of the subscriber to be used as a template
IMSI of the new subscriber record
<main_msisdn>
The subscriber’s main MSISDN
{<msisdn>}
Additional MSISDNs to be added to the record. As many MSISDNs must be specified as there are in the template subscriber record. A maximum of 4 additional MSISDNs can be specified. MSISDNs cannot be omitted in the middle of the MSISDN list. All MSISDNs must be different.
The COPY command must have the same number of MSISDNs as the template. Additional duplicates must not be specified. MSISDNs can be added as specified in ADD:MSISDN on page 280. The new subscriber’s secondary MSISDNs contain basic services assigned to the template’s secondary MSISDNs, in the same order as displayed by a VIEW:SUB command. The COPY command fails if the subscriber template has a bearer capability title that is not recognised. For example, if a bearer capability title for the template’s <main_msisdn> is removed from the BCA table. The COPY command also fails if the subscriber used as a template is a member of a linked subscription, indicated by the presence of a published number (PNUM). However, the template is allowed to contain values for LINKED_TYPE, OWNM_P and DNLD_P, which are attributes used by a linked subscription. All PDP contexts are copied, but static addresses in PDP contexts are not copied. Not all PDP contexts have a static address, but a static address can be specified using the UPDATE:PDP admin command.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
MultiSIM subscriptions
209
If the is any IMSI in a MultiSIM group, the command will succeed but only the subscription data will be copied, and a new single IMSI with SIM ID of 0 (zero) is created for the new subscription. See MultiSIM on page 46 for a description of MultiSIM subscriptions.
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Errors <error_code>
<error_message>
00001
Subscriber IMSI already in use.
00004
Subscriber MSISDN already in use.
00038
Duplicate MSISDN specified.
00046
Incorrect number of MSISDNs specified.
00053
Cannot copy template with PNUM.
00055
Unable to access subscriber record.
00059
BC title not known.
00099
Internal software error.
00116
Unable to allocate resource.
Example To create a subscriber record from an existing subscriber template: COPY:SUB,123456789012345,123456789012346, 44370123456; GSM PDS - Subscriber Created from Template Subscriber IMSI - 123456789012346 Main MSISDN - 44370123456 In this second example, repeating the command fails because the new IMSI for the subscriber is already in the database. COPY:SUB,123456789012345,123456789012346, 44370123457; C1:00002,00001,Subscriber IMSI already in use. Re-enter the command with the correct value for the IMSI.
2
Home Location Register (Linux) V1.1 Support Guide
210
Chapter 12 Subscriber Commands
COPY:SUB,123456789012345,123456789012344, 44370123457; GSM PDS - Subscriber Created from Template Subscriber IMSI - 123456789012344 Main MSISDN - 44370123456
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
211
DELETE:SUB The DELETE:SUB command deletes a subscriber record and all associated records (for example: MSISDN information) from the database. The IMSI used is either the actual one or the overlapping IMSI, and the MSISDN may be any allocated to the subscriber. The IMSI specifies the subscriber to be deleted, the MSISDN is optionally used as confirmation. The command is rejected if the MSISDN specified does not belong to the subscriber. To cancel the subscriber’s registration on a VLR, this command should be preceded by an UPDATE:SUB,...,ADMIN,DISABLED; command to initiate a registration cancellation. See UPDATE:SUB on page 215.
Syntax DELETE:SUB,(,);
Parameters Parameter
Meaning
Subscriber IMSI
Optional field containing one of the subscriber’s MSISDNs
If a MSISDN parameter is used, the subscriber is disconnected only if the MSISDN specified matches the IMSI. If there is no match, the command is rejected.
MultiSIM Subscriptions
If the is part of a MultiSIM subscription, DELETE:SUB deletes all SIMs that are part of that subscription. See MultiSIM on page 46 for a description of MultiSIM subscriptions.
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
2
Home Location Register (Linux) V1.1 Support Guide
212
Chapter 12 Subscriber Commands
Errors <error_code>
<error_message>
00002
Record not found.
00007
Subscriber MSISDN/IMSI mismatch.
00055
Unable to access subscriber record.
00099
Internal software error.
Example To delete a subscriber record: DELETE:SUB,123456789012346,44370123456; GSM PDS - Subscriber Deleted Subscriber IMSI - 123456789012346
DELETE:SUB,123456789012345; C1:00002,00002,Record not found; The specified IMSI is not in the database. Re-enter the command with the correct value for the IMSI.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
213
LOCK:SUB This command locks a subscriber record in the database. The subscriber record may be accessed by either IMSI or MSISDN. The IMSI used may be either the actual or the overlapping IMSI, and the MSISDN may be any of those allocated to the subscriber. This command is for development; it is not used in normal operation.
Syntax LOCK:SUB,IMSI|MSISDN,;
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Errors <error_code>
<error_message>
00002
Record not found.
00055
Unable to access subscriber record.
00099
Internal software error.
Example LOCK:SUB,MSISDN,123412341234; GSM PDS - Subscriber Locked
2
Home Location Register (Linux) V1.1 Support Guide
214
Chapter 12 Subscriber Commands
UNLOCK:SUB This command unlocks a subscriber record in the database. The subscriber record may be accessed by either IMSI or MSISDN. The IMSI used may be either the actual or the overlapping IMSI, and the MSISDN may be any of those allocated to the subscriber. This command is for development; it is not used in normal operation.
Syntax UNLOCK:SUB,IMSI|MSISDN,;
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Errors <error_code>
<error_message>
00002
Record not found.
00055
Unable to access subscriber record.
00099
Internal software error.
Example UNLOCK:SUB,MSISDN,123412341234; GSM PDS - Subscriber Unlocked
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
215
UPDATE:SUB The UPDATE:SUB command updates subscriber attributes in the database. Access to the record is by the IMSI (actual or overlapping) or any MSISDN allocated to the subscriber. If the subscriber is registered on a VLR or SGSN, the VLR and/or SGSN is also updated. Table 20 list the attributes.
Syntax To update a subscriber record, enter: UPDATE:SUB,IMSI|MSISDN,, ,; Enter a separate command for each attribute that you want to update.
Parameters Parameter
Meaning
IMSI|MSISDN
Indicates whether the number, which identifies the subscription, is an IMSI or MSISDN
IMSI or MSISDN of the subscription
Attribute to be changed (see Table 20)
New value for the attribute
Table 20. UPDATE:SUB Attribute Values
Default
Meaning
ADMIN
DISABLED/ENABLED
DISABLED
Administration status.
BADPWDCTR
0 to 3
0
Counts the number of times that a subscriber enters the wrong call barring password.
CATEGORY
PAYPHONE, NORMAL, PRIORITY, TEST or V0 to V255
NORMAL
Type of phone.
CFBCP
NOTIFY/NONOTIFY
NONOTIFY
Call forwarding busy calling party. Whether the calling party is notified that a call is being diverted.
CFBFP
NOTIFY/NONOTIFY
NONOTIFY
Call forwarding busy forwarding party. Whether the forwarding party is notified that a call is being diverted.
2
Home Location Register (Linux) V1.1 Support Guide
216
Chapter 12 Subscriber Commands
Table 20. UPDATE:SUB Attribute Values (Continued)
Default
Meaning
CFNRCCP
NOTIFY/NONOTIFY
NONOTIFY
Call forwarding not reachable calling party. Whether the calling party is notified that a call is being diverted.
CFNRYCP
NOTIFY/NONOTIFY
NONOTIFY
Call forwarding no reply calling party. Whether the calling party is notified that a call is being diverted.
CFNRYFP
NOTIFY/NONOTIFY
NONOTIFY
Call forwarding no reply forwarding party. Whether the forwarding party is notified that a call is being diverted.
CFUCP
NOTIFY/NONOTIFY
NONOTIFY
Call forwarding unconditional calling party. Whether the calling party is notified that a call is being diverted.
CNUM_BHVR
0 to 31
0
Number that selects a type of forward-to number translation or barring defined in the C Number Behaviour table. 0 (zero) indicates no C number conversion (see C Number Behaviour Table (CNUM_BHVR).
CTRL_SS
NO/YES
NO
Flag containing control supplementary service barring status which indicates whether the subscriber can control supplementary services barring, using a password procedure. See also BADPWDCTR.
DNLD_P
PNUM/OWN
EMLPP_PRIORITY
0 to 6
☞???
The call precedence value at which an eMLPP subscriber makes calls. See the description of EMLPP_DFLT_PRIORITY in the HLR_CONFIG table for a description of the values.
GPRS_SUB_RESTR
decimal 0 to 65535 or hexadecimal 0x0000 to 0xFFFF
0
Roaming restriction placed on the GPRS side of a subscription. Similar to the GSM_SUB_RESTR attribute
For a member of a linked subscription, specifies which number is downloaded to the VLR. PNUM - published number downloaded to the VLR OWN - subscriber’s own (routing/ member) MSISDN downloaded to the VLR .
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
217
Table 20. UPDATE:SUB Attribute Values (Continued)
Default
Meaning
GSM_SUB_RESTR
decimal 0 to 65535 or hexadecimal 0x0000 to 0xFFFF
0
Subscription restriction number, which restricts the use of subscriber roaming. GSM_SUB_RESTR accesses the same bitmask as the obsolete SUB_RESTR attribute.
GROUP
0 (zero)
0 (zero)
No longer used. Should be 0 (zero).
HOMETICK
0 (or NONE) to 999
0
Terminating IN Category Key when in Home network. This replaces TICK and the associated supplementary services. HOMETICK allows the GMSC to perform specific processing when a customer receives an incoming call. If provisioned, the HOMETICK value is returned in response to an SRI message.
IMEI
CLEAR and null
null
When set to CLEAR, removes the IMEI from the VLR.
LINKED_TYPE
ATS/MESS
MSRN_PFX_ID
0 to 16
0
Number for the MSRN prefix index. A value of 0 (zero) indicates NONE
MWD_RACE_TIMER
decimal 0 to (232-1)
0
Number of seconds since 01/01/ 1991.
NAM
GSM, GPRS, or GSM_GPRS
GSM
Network Access Mode. GSM - subscriber only has access to standard GSM network and hence must only register on a VLR/ MSC. GPRS - subscriber only has access to the GPRS network and hence must only register on a SGSN (or VLR with GPRS capability). GSM_GPRS - subscriber has access to both the GSM and GPRS networks.
2
Type of linked subscription. ATS - automotive twin SIM MESS - mutually exclusive secondary SIM.
Home Location Register (Linux) V1.1 Support Guide
218
Chapter 12 Subscriber Commands
Table 20. UPDATE:SUB Attribute Values (Continued)
NO_SVC_UNSUPP_ BH
+{...} -{...} {...} {} for example, {} bars both outgoing and incoming calls
Default
Home Location Register (Linux) V1.1 Support Guide
Meaning Behaviour if the subscriber has OICK but the VLR does not support OICK. This value is also used by the OCSI_2 CAMEL trigger detection point. See ADD:CAMEL on page 332 and UPDATE:CAMEL on page 375. is an operator determined bar (ODB). {} removes all bars. + adds one bar - removes one bar {... } replaces any existing list of bars The HLR invokes the ODBs if the subscriber registers on a VLR that does not support OICK. See Appendix I, Operator Determined Bars for descriptions of ODBs.
Nominated SIM in a MultiSIM subscription (see page 46) and the basic service groups (BSGs) handled by that SIM. <sim_id> - SIM identity. Integer from 0 to 9 If no SIM has the specified <sim_id>, an error is returned. <sim_id> is followed by a list of one or more basic service groups (BSGs) to be assigned to the SIM: SPEECH - voice calls SMS - short messages FAX - facsimile DCICA - data circuit (modem) DCICS - data circuit (synchronous) PADACC - dedicated PAD access DPACK - dedicated data packet UNREST - 12 kbits/s unrestricted digital AUXSPEECH - obsolescent If no basic service groups are specified, indicated by omitting the parameter altogether, the SIM is nominated for all BSGs. The SIM is nominated for all specified BSGs regardless of whether the subscription has those BSGs, provided the (<sim_id> is valid). If a BSG is added to a SIM later, the nomination is applied to an incoming message for that BSG.
NOTIFY_CB
TRUE or FALSE
FALSE
Flag to control whether the CAMEL Service Environment (CSE) is notified if call barring (CB) data is changed. The CSE is notified by a Notification of Subscriber Data Change message, which is sent if call barring data changes. The entities that receive the message are defined by the CB_NOTIFY parameter in the HLR_CONFIG Table
2
Home Location Register (Linux) V1.1 Support Guide
220
Chapter 12 Subscriber Commands
Table 20. UPDATE:SUB Attribute Values (Continued)
Default
Meaning
NOTIFY_CF
TRUE or FALSE
FALSE
Flag to control whether the CAMEL Service Environment (CSE) is notified if call forwarding (CF) data is changed. The CSE is notified by a Notification of Subscriber Data Change message, which is sent if call forwarding data changes. The entities that receive the message are defined by the CF_NOTIFY parameter in theHLR_CONFIG Table
NOTIFY_ODB
TRUE or FALSE
FALSE
Flag to control whether the CAMEL Service Environment (CSE) is notified if operator determined bar (ODB) data is changed. The CSE is notified by a Notification of Subscriber Data Change message, which is sent if operator determined bar data changes. The entities that receive the message are defined by the ODB_NOTIFY parameter in the HLR_CONFIG Table
OICK
0 to 999
0
Originating Intelligent Network Category Key. This value selects one IN service or a combination of IN services. 0 (zero) disables OICK.
OVERRIDE
TRUE/FALSE
FALSE
Controls Calling Line Identification presentation. Values are TRUE/ FALSE depending on whether the subscriber is allowed to override the CLI restriction of an incoming call. See CLIP Restriction Override on page 633.
OWNM_P
PNUM/ OWN
Home Location Register (Linux) V1.1 Support Guide
For a member of a linked subscription, specifies which number is returned in response to an OWN_MSISDN USSD. PNUM - published number is returned OWN - subscriber’s own (routing/ member) MSISDN is returned For a member of a mutually exclusive secondary SIM linked subscription, OWNM_P should always have the value PNUM.
2
Chapter 12 Subscriber Commands
221
Table 20. UPDATE:SUB Attribute Values (Continued)
Default
Meaning
PAI
OFF or ON
ON
Positioning Allowed Indicator. Shows whether a subscriber can use mobile positioning services. OFF - positioning services not allowed ON - positioning services allowed Both PAI and the Subscriber Location Privacy Profile (SLPP) must allow positioning services. PAI defaults to ON to allow the Location Enabling Server (LES) to control privacy. See page 36 for a description of location based services.
PAI_CTRL
OFF or ON
ON
Positioning Allowed Indicator Control Flag. Determines whether a subscriber can control PAI. OFF - subscriber not allowed to control PAI ON - subscriber allowed to control PAI
PNUM
MSISDN
PRES_MODE
DEF_ALLOW DEF_RESTR PERMANENT
2
The published number for a linked subscription. If NONE is specified, the published number is removed from the group member subscriber. (Can also be done using the REMOVE:PNUM command). If a published number value is supplied, but the subscriber has no PNUM to update, a PNUM with the specified value is added to the subscriber. (Can also be done using the ADD:PNUM command). PERMANENT
Presentation mode. This relates to the Calling Line Identification Restriction service. DEF_ALLOW - The subscriber’s directory number is displayed by the called party. DEF_RESTR - The subscriber’s directory number is not displayed by the called party. PERMANENT - The subscriber’s directory number is permanently not displayed by the called party. This status can be changed only using an administration command, not from the subscriber’s handset. (see Calling Line Identity Restriction on page 632)
Home Location Register (Linux) V1.1 Support Guide
222
Chapter 12 Subscriber Commands
Table 20. UPDATE:SUB Attribute Values (Continued)
Default
Meaning
PRIORITY
0 to 255 except for invalid values 0 to 3, 64 to 67, 128 to 131 and 192 to 195
0
Value for PRIORITY supplementary service. Bits 3 to 6 (4 bits in total) of the 8-bit PRIORITY indicate the priority (other bits are flags or spare bits) and must be non-zero. Some values of PRIORITY are therefore invalid.
PWD
0000 to 9999
0000
Number for the password.
ROAMTICK
0 (or NONE) to 999
0
Terminating IN Category Key when Roamed to another network. This replaces TICK and the associated supplementary services. ROAMTICK allows the GMSC to perform specific processing when a customer receives an incoming call. If provisioned, the ROAMTICK value is returned in response to an SRI message.
SPCODE
8 to 10 alphanumeric characters, usually two letters followed by six digits
(no default)
Service Provider code (if available), which identifies the subscriber’s service provider Service provider details are listed in the Service Provider (SP) Table. Services that depend on the service provider are described in Service Provider Services on page 56.
SUBTYPE
0 to 127
0
Value for SUBTYPE supplementary service.
SUB_RESTR
decimal 0 to 65535 or hexadecimal 0x0000 to 0xFFFF
0
The Subscription Restriction Status is a bitmask that indicates whether a subscriber can register in a geographical location, as a way to control roaming. Every VLR or PLMN has a corresponding bitmask which indicates its geographical location. SUB_RESTR has been superseded by the GSM_SUB_RESTR attribute, but it can still be specified.
TICK
0 (or NONE) to 999
0
Terminating IN Category Key supplementary service. This has been replaced by HOMETICK and ROAMTICK, but is retained for backward compatibility.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
223
Table 20. UPDATE:SUB Attribute Values (Continued)
TRACE
0 to 255 or + or -
TRANSFER_OF_SM
VIA_MSC or VIA_SGSN
2
Default
Meaning Trace flags are SUB_SS7 (for network which traces all SS7 events)/ SUB_TRAN (for transaction tracing)/TIMON (for TiMON tracing)/REALTIME (for real time tracing), B0, B1, B2 or B3. See also SET:TRACE on page 269.
VIA_SGSN
Some gateway MSCs connected to text messaging centres do not support GPRS. Therefore, a GMSC indicates whether it supports GPRS when requesting routing information for an SMS message. If the GMSC does not support GPRS, the HLR refers to TRANSFER_OF_SM to decide how to reroute the short message. This attribute is used to optimize speed, cost and reliability of delivering messages to subscribers. VIA_MSC - transfer of SM via MSC VIA_SGSN - transfer of SM via SGSN
Home Location Register (Linux) V1.1 Support Guide
224
Chapter 12 Subscriber Commands
Table 20. UPDATE:SUB Attribute Values (Continued)
Default
Meaning
VMTYPE
NONE, BTCVM, BTVM, RECALL, UM, NGVM, BTNOMI, or GREEN
(none)
The type of Voicemail service for subscribers. Currently the only supported values are BTCVM (BT Converged Voicemail), NGVM, and NONE (indicating that the subscriber doers not have voicemail). Setting it to any other value is similar to setting it to NONE (although it indicates that the subscriber does have voicemail, and so will affect the response of the HLR to certain messages). If the VMTYPE attribute is specified, the command can take the additional, optional, parameter, . This can take the following values: ALLDIVS Clears any existing diverts before enabling the diverts specified in the voicemail table for this vmtype. NODIVS No existing diverts are changed. RECALLDIVS Existing diverts that have RECALL behaviour, or GSM behaviour and match the mailbox number returned in an MLR Lookup request, are modified: they are cleared if a new divert format is defined in the voicemail table. Otherwise the divert is set to the new FTN. For example: UPDATE:SUB,MSISDN, 44375453264,VMTYPE,NGVM, ALLDIVS;
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
225
Errors <error_code>
<error_message>
00002
Record not found.
00024
Unexpected data value error.
00044
Unable to add P number.
00055
Unable to access subscriber record.
00061
HLR updated but Subscriber Data download failed.
00099
Internal software error.
00114
Configurable CAMEL GSMSCF GT unavailable.
00132
SIM ID not in use.
00155
Emlpp default priority greater than maximum allowed.
00172
MSISDN has no country code.
00173
ISDN cannot be formatted.
Example Migrating Linked Subscriptions
Migrate a subscriber from a mutually exclusive secondary SIM (MESS) linked subscription to an automotive twin SIM (ATS) linked subscription as follows: UPDATE:SUB,IMSI|MSISDN,,LINKED_TYPE,ATS;
The HLR removes the MESS subscription’s IN bar, if any, thereby allowing the subscriber to make outgoing calls. An ATS subscriber can be migrated to a MESS linked subscription in a similar way. However, because the HLR applies IN bars to members of a MESS linked subscription, disable ATS members before migrating as follows: UPDATE:SUB,IMSI|MSISDN,,ADMIN,DISABLED;
Providing and Withdrawing CAMEL
Provide CAMEL (Customized Applications for Mobile network Enhanced Logic) services using the ADD:CAMEL, REMOVE:CAMEL and UPDATE:CAMEL commands. For backward compatibility, CAMEL services can be provided and removed using a series of UPDATE:SUB commands, as described below. However, ADD:CAMEL, REMOVE:CAMEL and UPDATE:CAMEL commands should be used instead.
2
Home Location Register (Linux) V1.1 Support Guide
226
Provisioning OICK
Chapter 12 Subscriber Commands
This example provisions a subscriber with OICK. If CAMEL is not supported, the OICK service has an associated unsupported behaviour which invokes an operator determined bar to prevent the subscriber from originating calls (see Appendix I, Operator Determined Bars). UPDATE:SUB,IMSI,,OICK,3; UPDATE:SUB,IMSI,,NO_SVC_UNSUPP_BH,+ODBAOC;
Changing a MultiSIM Subscription
A MultiSIM subscription has up to 10 SIMs assigned to the same MSISDN, with the option of assigning particular basic service groups (BSGs) to each SIM. The general form of the command to assign BSGs to nominated SIMs is: UPDATE:SUB,IMSI|MSISDN,,NOMSIM, <sim_id>,{(SPEECH) (SMS) (FAX) (DCICA) (DCICS) (PADACC) (DPACK) (UNREST) (AUXSPEECH)}; If no basic service groups are specified, that is, the braces are empty, all basic service groups are assigned to the SIM. This example assigns speech calls and SMS messages to SIM 0 and all other BSGs to SIM1: UPDATE:SUB,IMSI|MSISDN,,NOMSIM,0, {SPEECH SMS}; UPDATE:SUB,IMSI|MSISDN,,NOMSIM,0, {FAX DCICA DCICS PADACC DPACK UNREST AUXSPEECH}; This example assigns all basic service groups to SIM 0: UPDATE:SUB,IMSI|MSISDN,,NOMSIM,0,{};
Tracing
This turns off the TRACE attribute for a subscriber: UPDATE:SUB,IMSI,123456789012345,TRACE,0; GSM PDS - Subscriber Updated Subscriber IMSI - 123456789012345 123456789012345
= Subscriber IMSI
In this example the specified IMSI is not in the database: UPDATE:SUB,IMSI,123456789012344,TRACE,0; C1:00002,00002,Record not found; 123456789012344
= Subscriber IMSI
Re-enter the command with the correct value for the IMSI.
Changing Voicemail configuration
The following are examples of commands used to change a subscriber’s voicemail configuration: UPDATE:SUB,MSISDN,44375453264,VMTYPE,NGVM;
UPDATE:ZONELIST The UPDATE:ZONELIST command updates a zone code list for a subscriber. A zone code list completely replaces any existing list for the specified CC-NDC combination. If no zone code is specified, the zone code list is removed.
Indicates whether used to locate subscriber record is an IMSI or an MSISDN.
Numeric field containing either the subscriber IMSI, overlapping IMSI or MSISDN.
Numeric field containing a country code (2 or 3 digits) and national destination number (usually 3 or 4 digits). VLRs and SGSNs with a CC and NDC that match contain the zones identified by zone codes.
Numeric field. Optional zone code of 0 to 65535. The zone code identifies a geographical area within the area covered by VLRs and SGSNs that have the CC and NDC combination defined by . Zone code values and how they are used are defined by the network operator.
Adding a Zone Code List
If at least one zone code is specified for a CC-NDC combination, and the subscriber does not already have a zone code list for that CC-NDC combination, then a zone code list is added. Provided that the subscriber does not already have the maximum number of zone code lists, the list is stored against the subscriber.
Removing a Zone Code List
If a CC-NDC combination is specified without any zone codes, the list for the CC-NDC combination is removed. Even if the subscriber does not have a list for the specified CC-NDC combination, the removal is considered successful and an error is not returned.
Replacing a Zone Code List
If at least one zone code is specified for a CC-NDC combination the subscriber already has, then that zone code list is completely replaced by the new zone codes.
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
229
Note: The result of adding, removing or updating a zone code list is compared with the data in the VLR/SGSN where the subscriber is registered. If the two differ, changes to the subscriber data are downloaded to the VLR/SGSN.
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>;
Errors <error_code>
<error_message>
00002
Record not found.
00022
Duplicate zone codes specified.
00029
Subscriber has maximum zone lists.
00055
Unable to access subscriber record.
00061
HLR updated but Subscriber Data download failed.
00099
Internal software error.
00116
Unable to allocate resource.
Example This is an example of adding zone code 100 for the 44 1635 country code plus area code combination. UPDATE:ZONELIST,IMSI,123451234512345,441635,100; GSM HLR - Zone list added/ updated/ removed MSISDN
- 123412341234
This example shows that one subscriber cannot be given a zone code list for more than one country code plus area code combination. UPDATE:ZONELIST,IMSI,123451234512345,441793,200; C1:00002,00029,Subscriber has maximum zone lists;
2
Home Location Register (Linux) V1.1 Support Guide
230
Chapter 12 Subscriber Commands
This example shows that the same zone code cannot be specified twice. UPDATE:ZONELIST,IMSI,123451234512345,441635,100, 100; C1:00002,00022,Duplicate zone codes specified;
Home Location Register (Linux) V1.1 Support Guide
2
Chapter 12 Subscriber Commands
231
VIEW:SUB The VIEW:SUB command displays subscriber attributes in the database. Access to the record is by the IMSI (actual or overlapping) or any MSISDN allocated to the subscriber.
Indicates whether the number, which identifies the subscription, is an IMSI or MSISDN
Number of the subscriber IMSI or MSISDN
ENQUIRE
Request subscriber data from the MLR (if the subscriber has RECALL SS), and VLR (if the subscriber has a circuit switched (CS) location).
NOENQUIRE
Do not request subscriber data from the MLR or VLR
Response C1:00000,00000; or C1:00002,<error_code>,<error_message>; C2 responses are grouped by the kind of data they contain and are listed in the table below. Code