Interface between the IP-SM-GW (SMSC) and the HLR/HSS

The interface(s) between the IP-SM-GW and the HLR/HSS is used for:

 Supporting the registration and de-registration from the IP-SM-GW to the

HLR/HSS for SMS delivery.
 Forwarding of the Send Routeing Information for Short Message requests
from HLR/HSS to IP-SM-GW in order to return the address where the SM
should be forwarded.
- Interrogating the HLR/HSS using Send Routing Information for Short
Message to retrieve the IMSI and the current MSC, SGSN, MME, and/or SMSF
addresses.
- Informing the HLR/HSS when a memory capacity exceeded condition
ceases.
- Retrieving SMS-related data from the HLR/HSS: subscriber data of
the short message service similar to the data for the current CS/PS domain and
additional service data on the service authorisation of the encapsulated short

message delivery via IMS, SC address for service-level interworking from Instant Message
to Short Message if the SC address is stored in the HLR/HSS.

Both a Sh interface and either a J or S6c interface can be deployed between the IP-SM-GW
and the HLR/HSS. During the functional allocation the change on existing MAP functions,
when used, should be minimized. The deployment of the J or S6c interface is mandatory,
since it is used for forwarding the SRI for SM message.
1.)MS sends an Attach request with IMSI and attach type.

2.)SGSN updates the HLR with the new location of the MS by sending Update GPRS location request.
3.)HLR sends thesubscriber information of the MS to SGSN through Insert subscriber request.
4.)SGSN acknowledges the reception of insert subscriber data request.

5.)HLR acknowledges completion of update location to the SGSN.

6.)SGSN accepts the Attach request and sends Attach request with a P_TMSI to the MS.

Required information for integration with MSC/HLR

(1) 1. SMSC information (for each site)

ITEM Sample value Description

SMSC DPC 002A60 (HEX) Point code for SMSC Mumbai
SMSC DPC type NI NI2 (national) or NI3 (national
resverse)

SMSC SSN OB (HEX) SSN=11 (SMSC)

SMSC GT 809989 GT Code

SMSC M3UA IP/Port X.X.X.X.X.X.X.X (XXXX) IP/Port for SCTP Connection

Gateway IP X.X.X.X.X.X.X.X Gateway address fo M3UA IP
Routing
This information is mandatory for SMSC configuration

ITEM Sample value Description

MSC DPC 002A61 (HEX) Point code for MSC
MSC DPC Type NI2 NI2(national) and NI3(national reverse)
MSC SSN 08 (HEX) SSN=8(MSC)

MSC GT 80XXXXXX GT Code

HLR DPC 002A62(HEX) Point Code for HLR
HLR DPC Type NI2 NI2(national) and NI3(national reverse)
HLR SSN 06 (HEX) SSN=6(MSC)
HLR GT 80XXXXXX GT Code
STP DPC 002A61 (HEX) Point Code for MSC
STP DPC Type NI2 NI2(national) and NI3(national reverse)
STP M3UA IP/Port XXX.XXX.XXX(XXXX) IP Port for SCTP Connection

1. TS29.002 - 3GPP MAP Specifications (making use of SCCP) in HLR

The Home Location Register (HLR)

There are several cases where the HLR has to be addressed.

6.1.3.3.1 During call set-up

When a call is initiated the HLR of the called mobile subscriber will be interrogated to discover the
whereabouts of the MS. The addressing required by the SCCP will be derived from the MSISDN
dialled by the calling subscriber. The dialled number will be translated into either an SPC, in the
case of communications within a PLMN, or a Global Title if other networks are involved (i.e. if the
communication is across a PLMN boundary).

If the calling subscriber is a fixed network subscriber, the interrogation can be initiated from the
Gateway MSC of the home PLMN in the general case. If the topology of the network allows it, the
interrogation could be initiated from any Signalling Point that has MAP capabilities, e.g. local
exchange, outgoing International Switching Centre (ISC), etc.

6.1.3.3.2 Before location updating completion

When an MS registers for the first time in a VLR, the VLR has to initiate the update location
dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if
the authentication information must be retrieved from the HLR. When initiating either of these
dialogues, the only data for addressing the HLR that the VLR has available is contained in the IMSI,
and addressing information for SCCP must be derived from it. When continuing the established
update location dialogue (as with any other dialogue), the VLR must derive the routeing
information towards the HLR from the Calling Party Address received with the first responding
CONTINUE message until the dialogue terminating message is received. This means that the VLR
must be able to address the HLR based on:

- an E.214 Mobile Global Title originally derived by the VLR from the IMSI (when CCITT or
ITU-T SCCP is used), or an E.212 number originally derived from IMSI (when ANSI SCCP is used, an
IMSI); or

- an E.164 HLR address; or

- in the case of intra-PLMN signalling, an SPC.

When answering with Global Title to the VLR, the HLR shall insert its E.164 address in the Calling
Party Address of the SCCP message containing the first responding CONTINUE message.

If the HLR is in the same PLMN as the VLR, local translation tables may exist to derive an SPC. For
authentication information retrieval and location updating via the international PSTN/ISDN
signalling network that requires the use of CCITT or ITU-T SCCP, the Global Title must be derived
from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering
Plan Indicator (NPI) value referenced by the SCCP Specifications. In World Zone 1 where the ANSI
SCCP is used, IMSI (E.212 number) is used as Global Title. A summary of the translation from the
IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation
E.214) is shown below:

- E.212 Mobile Country Code translates to E.164 Country Code;

- E.212 Mobile Network Code translates to E.164 National Destination Code;

- E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the
E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the
number is truncated to 15 by deleting the least significant digits.

This translation will be done either at the application or at SCCP level in the VLR. The Mobile
Global Title thus derived will be used to address the HLR.

If location updating is triggered by an MS that roams from one MSC Area into a different MSC Area
served by the same VLR, the VLR shall address the HLR in the same way as if the MS registers for
the first time in the VLR.

6.1.3.3.3 After location updating completion

In this case, the subscriber's basic MSISDN has been received from the HLR during the subscriber
data retrieval procedure as well as the HLR number constituting a parameter of the MAP message
indicating successful completion of the update location dialogue. From either of these E.164
numbers the address information for initiating dialogues with the roaming subscriber's HLR can be
derived. Also the subscriber's IMSI may be used for establishing the routeing information towards
the HLR. This may apply in particular if the dialogue with the HLR is triggered by subscriber
controlled input.

Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title
consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or either the E.214
Mobile Global Title derived from the IMSI if CCITT or ITU-T SCCP is used, or the IMSI if ANSI SCCP is
used (ANSI SCCP is used in World Zone 1).

6.1.3.3.4 VLR restoration

If a roaming number is requested by the HLR for an IMSI that has no data record in the
interrogated VLR, the VLR provides the roaming number in the dialogue terminating message.
Subsequently the VLR must retrieve the authentication data from the MS's HLR, if required, and
must then trigger the restore data procedure. For this purpose, the VLR has to initiate in
succession two independent dialogues with the MS's HLR. The MTP and SCCP address information
needed for routeing towards the HLR can be derived from the IMSI received as a parameter of the
MAP message requesting the roaming number. In this case, the IMSI received from the HLR in the
roaming number request shall be processed in the same way as the IMSI that is received from an
MS that registers for the first time within a VLR. Alternatively to the IMSI, the Calling Party
Address associated with the roaming number request may be used to obtain the routeing
information towards the HLR.

6.1.3.3.5 During Network-Requested PDP Context Activation

When receiving a PDP PDU the GGSN may interrogate the HLR of the MS for information retrieval.
When initiating such a dialogue, the only data for addressing the HLR that the GGSN has available
is contained in the IMSI, and addressing information must be derived from it. The IMSI is obtained
from the IP address or the X.25 address in the incoming IP message by means of a translation
table. This means that the GGSN shall be able to address the HLR based on an E.214, (if CCITT or
ITU-T SCCP is used), or E.212 (if ANSI SCCP is used), Mobile Global Title originally derived by the
GGSN from the IMSI in the case of inter-PLMN signalling. In the case of intra-PLMN signalling, an
SPC may also be used.

If the HLR is in the same PLMN as the GGSN, local translation tables may exist to derive an SPC. For
information retrieval via the international PSTN/ISDN signalling network, the Global title must be
derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the
Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. A summary of the
translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in
CCITT Recommendation E.214) is shown below:

- E.212 Mobile Country Code translates to E.164 Country Code;

- E.212 Mobile Network Code translates to E.164 National Destination Code;

- E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the
E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the
number is truncated to 15 by deleting the least significant digits.

This translation will be done either at the application or at SCCP level in the GGSN. The Mobile
Global Title thus derived will be used to address the HLR.

6.1.3.3.6 Before GPRS location updating completion

When an MS registers for the first time in an SGSN, the SGSN has to initiate the update location
dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if
the authentication information must be retrieved from the HLR. When initiating either of these
dialogues, the only data for addressing the HLR that the SGSN has available is contained in the
IMSI, and addressing information for SCCP must be derived from it. When continuing the
established update location dialogue (as with any other dialogue), the SGSN must derive the
routeing information towards the HLR from the Calling Party Address received with the first
responding CONTINUE message until the dialogue terminating message is received. This means
that the SGSN must be able to address the HLR based on:

- an E.214 (if CCITT or ITU-T SCCP is used) or E.212 (if ANSI SCCP is used) Mobile Global Title
originally derived by the SGSN from the IMSI; or

- an E.164 HLR address; or

- in the case of intra-PLMN signalling, an SPC.

If the HLR is in the same PLMN as the SGSN, local translation tables may exist to derive an SPC. For
authentication information retrieval and location updating via the international PSTN/ISDN
signalling network, the Global title must be derived from the IMSI, using the principles contained
in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the
SCCP Specifications. A summary of the translation from the IMSI (CCITT Recommendation E.212) to
Mobile Global Title (described in CCITT Recommendation E.214) is shown below:

- E.212 Mobile Country Code translates to E.164 Country Code;

- E.212 Mobile Network Code translates to E.164 National Destination Code;

- E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the
E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the
number is truncated to 15 by deleting the least significant digits.

This translation will be done either at the application or at SCCP level in the SGSN. The Mobile
Global Title thus derived will be used to address the HLR.

6.1.3.3.7 After GPRS location updating completion

In this case, the subscriber's Basic MSISDN has been received from the HLR during the subscriber
data retrieval procedure as well as the HLR number constituting a parameter of the MAP message
indicating successful completion of the update location dialogue. From either of these E.164
numbers the address information for initiating dialogues with the roaming subscriber's HLR can be
derived. Also the subscriber's IMSI may be used for establishing the routeing information towards
the HLR.

Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title
consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or the E.214 Mobile
Global Title derived from the IMSI.

6.1.3.3.8 Query for a Location Request

For a location request from an external client, the GMLC needs to address the home HLR of the
target MS to obtain the address of the target MS's serving MSC. The GMLC uses either the
international E.164 MSISDN, the international E.214 number (if CCITT or ITU-T SCCP is used) or the
international E.212 number (if ANSI SCCP is used) of the MS as means to route a query to the HLR.
Test Item Basic Service Function
Test Sub Item Common call
 Test Purpose The purpose of this test is to perform a common call when the Gateway MSC
to perform the interrogation of the HLR in order to route a call towards the
called MS.
Reference: 3GPP TS 29.002 section 10.1

Pre-requisites 1.Subscriber A and B have been allocated in HLR and registered for telephone
service;
2. Network Configuration: A
Test Procedure 1. Subscriber A calls subscriber B.

Test Verification 1. Subscriber A calls subscriber B successfully.

Message Flow
1 GMSC→HL MAP Send Routing Information Request
R

2 VLR←HLR MAP Provide Roaming Number Request

3 VLR→HLR MAP Provide Roaming Number

Response

4 GMSC←HL MAP Send Routing Information ACK

R

Test Result □ Pass □ Fail

Remarks

Signature Test date

Test Item Basic Service Function

Test Sub Common SMS
Item
Test The purpose of this test is used between the gateway MSC and the HLR to retrieve
Purpose the routing information needed for routing the short message to the servicing MSC.
Reference: 3GPP TS 29.002 section 12.1
Pre- 1. Subscriber A and B have been allocated in HLR;
requisites 2. Subscriber A and B subscribe SMS service;
3. Subscriber A and B log on network successfully;
3. Network Configuration: A
Test . Subscriber A sends SMS message to subscriber B.
Procedure

Test Subscriber A sends SMS successfully.

Verification Subscriber B get SMS successfully

Message
Flow 1 GMSC→HLR MA Send Routing Info For SM Request
P

2 GMSC←HLR MA Send Routing Info For SM Response

P

Test Result □ Pass □ Fail

 Test Item Basic Service Function
Remarks Verify the response incoming SMS from other operators.

Signature Test date

Test Item GPRS Services

Test Sub Item Update GPRS location triggered by a GPRS attach to a new SGSN

Test Purpose The purpose of the test is to verify that the update GPRS location procedure
can be successfully triggered by a GPRS attach when the MS has been
previously attached to a different SGSN.
Reference: 3GPP 29.002 section 19.1.1 & 3GPP 23.060 section 6.5
Pre-requisites Configurations: B
MS is GPRS attached in the ‘old’ SGSN.

Test Procedure Perform a GPRS attach in the new SGSN.

Test Verification Verify that the monitored message sequence is correct.

Verify that the GPRS attach is completed successfully.

Message Flow
NSGSN → HLR Send authentication information
NSGSN ← HLR Send authentication information acknowledge

NSGSN → HLR Update GPRS location

OSGSN ← HLR Cancel GPRS location
OSGSN → HLR Cancel GPRS location acknowledge

NSGSN ← HLR Insert subscriber data

NSGSN → HLR Insert subscriber data acknowledge

NSGSN ← HLR Update GPRS location acknowledge

Test Result □ Pass □ Fail

Remarks Also check for manual location cancel from HLR… kindly ensure that in
selected RPs GPRS-CSI data would not be inserted in roaming SGSN which
depend on the configuration.
Prepaid subscribers not allowed to do PS LU while on roaming.

Signature Test date

Test Item USSD Services

Test Sub Item Unstructured SS data request by MS

Test Purpose The purpose of this test is to verify the USSD functionality initiated by the UE
through MMI command.
Reference: 3GPP TS 24.090 section 6.1 & 3GPP TS 29.002 section 11.9, 11.10
Pre-requisites 1. Network configuration : A
2. MS_A has been performed a successful Location Update.
3. No other USSD flow is ongoing with this UE (MS_A).
Test 1. MS_A enters a MMI string in the UE.
Procedure
Test 1. Verify that the monitored message sequence is correct.
Verification
Message Flow
VL → HLR Process Unstructured SS Request
R
VL ← HLR Unstructured SS Notify
R
: ‘USSD Data Coding Scheme’ and ‘USSD String’ IEs are
included

VL → HLR Unstructured SS Notify Ack

R
VL ← HLR Process Unstructured SS Response
R
Test Result □ Pass □ Fail □ N/A

Remarks *444#
Signature Test date

Test Item USSD Services

Test Sub Item USSD interactive with network(MMI)

Test Purpose The purpose of this test is to verify the USSD request and notify functionalities
initiated by the Network in MMI mode.
Reference: 3GPP TS 23.090 section 5.2.5, 3GPP TS 24.090 section 5 & 3GPP TS
29.002 section 11.10, 11.11.

Pre-requisites 1. Network configuration: A

2. MS_A has been performed a successful Location Update.
3. No other USSD flow is ongoing with this UE (MS_A).
4. Notification is sent from USSD site.

Test 1. Use MMI to send a request followed by a notification from the HLR.
Procedure

Test 1. Verify that the monitored message sequence is correct.

Verification
 Message Flow
VL → HL Process Unstructured SS Request
R R
VL ← HL Unstructured SS Request
R R
: ‘USSD Data Coding Scheme’ and ‘USSD String’ IEs are
included

: MS displays the text provided and await user input

: Once response is entered by the user, it is sent to the

network

VL → HL Unstructured SS Response
R R
:
VL ← HL Unstructured SS Notify
R R
: ‘USSD Data Coding Scheme’ and ‘USSD String’ IEs are
included

VL → HL Unstructured SS Notify Ack

R R
VL ç HL Process Unstructured SS Response
R R

Test Result □ Pass

Remarks *786# ,*787#,*555#

Signature

Some Additional HLR Test Cases to be performed

 1.1.1 HLR provides 3-vector authentication set
Test Item Authentication Management
Test Sub HLR provides 3-vector authentication set
Item
Test The purpose of this test is to verify the correct behavior of the Authentication
Purpose procedure on the MAP interface for a 3G subscriber. If the user is a GSM subscriber,
the HLR shall return authentication triplets.
Reference: 3GPP TS 29.002 section 8.5.2
Pre- 1. Subscriber A has been created in HLR. It is a 2G subscriber and the authentication
requisites algorithm is COMP128-1/2/3;
2. Subscriber A has not performed LU.
3. Network Configuration: A
Test 1. Subscriber A switches on its handset and sends LU request;
Procedure 2. Open signaling tracking to check if the 3-vector authentication set returned from HLR
is correct.
Test 1. HLR returns Send_Authentication_Info REPONSE once it receives
Verification Send_Authentication_Info REQUEST from VLR;
2. The authentication and LU of subscriber A is successfully.

Message
Flow 1 VLR→HL MAP Send Authentication Info
R

2 VLR←HL MAP Send Authentication Info Ack

R

Test Result □ Pass □ Fail

Remarks
Signature Test date

1.1.1 OCSI service of CAMEL subscriber

Test Item CAMEL Services
Test Sub OCSI service of CAMEL subscriber
Item
Test The purpose of this test is If this Camel is activated, HLR send the CAMEL related
Purpose subscriber data to the visited PLMN.
Reference: 3GPP TS 23.078 section 4.3.1
Pre- 1. Home SCP of local CAMEL subscribers and all network elements are working
requisites well;
2. CAMEL subscriber A has registered in test MSC and HLR.
3. Network Configuration: A

Test 1. Register O_CSI service for subscriber A at HLR agent;

Procedure
Test 1. HLR send InsertSubScriber Request to VLR include OCSI data
Verification Case 1:
For prepaid will insert “release call” to VLR.
Case 2:
For postpaid will insert “continue call” to VLR.
 Message
Flow 1 VLR←HLR MAP InsertSubScriber Data Request

2 VLR→HLR MAP InsertSubScriber Data Response

Test Result □ Pass □ Fail

Remarks MML Command is like the following:

Set OCSI : IMSI={IMSI}, Phase=3, Active=1 ,TDP=2, SrvKey=123,
SCFAddr=862511223344, DftCall=1;

Signature Test date

1.1.2 TCSI service of CAMEL subscriber

Test Item CAMEL Services

Test Sub Item TCSI service of CAMEL subscriber
Test Purpose The purpose of this test is If this Camel is activated, The HLR may return TCSI
data in SRI Ack to GMSC.
Reference: 3GPP TS 23.078 section 4.4.3
Pre-requisites 1. Home SCP of local CAMEL subscribers & all NEs are working well;
2. CAMEL subscriber A has registered in test MSC and HLR.
3. Network Configuration: A
Test 1. Register T_CSI service for subscriber A at HLR agent;
Procedure 2. Someone calls subscriber A
Test 1. HLR return TCSI data in SRI Ack
Verification
Message
Flow 1 GMSC→HLR MA Send Routing Information
P

2 GMSC←HLR MA Send Routing Information ACK

P

Test Result □ Pass □ Fail

Remarks MML Command is like the following:
Set TCSI : IMSI={IMSI}, Phase=3, NotiCSE=1, Active=1 , TDP=12,
SrvKey=443, SCFAddr=862511223344, DftCall=1
Signature Test date
Spec/section Reg Eras Ac Deact Inv Int
t

22.067 eMLPP a/s w/r - - n dr

22.072, Call Deflection SS

CD p w u

22.081. Number Identif. SS

CLIP p w n s

CLIR p w n dr

CoLP p w n s

CoLR p w n s

22.082. Call Offering SS

CFU a/s w/r/s r/s e/s n dr

CFB a/s w/r/s r/s e/s n dr

CFNRy a/s w/r/s r/s e/s n dr

CFNRc a/s w/r/s r/s e/s n dr

22.083. Call Completion SS

CW a/s a/s n s

HOLD p w u

22.084. Multi Party SS

MPTY u

22.085. Comm. of Interest SS

CUG p w u/n
22.087. UsertoUser SS

UUS s c u/n

22.086. Charging SS

AoCI p w n

AoCC p w n

22.088. Call Restriction SS

BAOC a/s w/r a/s s/a n dr

BOIC a/s w/r a/s s/a n dr

BOICexHC a/s w/r a/s s/a n dr

BAIC a/s w/r a/s s/a n dr

BAICRoam a/s w/r a/s s/a n dr

ACR - - a/s s/a n s

22.067 eMLPP a/s w/r/s u/n s/dr

22.091. Call Transfer SS

ECT p w u

22.093. Completion of Calls to Busy Subscribers

CCBS SS - - p w n

CCBS Requests s s/a/w dr

22.096 Name Identification SS

 CNAP p w n s

22.135 Multicall

MC a/s w p w U/n dr

Ericsson ENM CLI commands are used to manage Ericsson ENM (Ericsson
Network Manager) devices. ENM is a network management system that is
used to manage Ericsson telecommunications equipment. ENM CLI
commands can be used to perform a variety of tasks, such as:
 Configuring ENM devices
 Monitoring ENM devices
 Troubleshooting ENM devices
ENM CLI commands are typically entered at the ENM CLI prompt. The ENM
CLI prompt is a text-based interface that is used to interact with ENM
devices.

Here are some examples of ENM CLI commands:

 cmedit get <node> <MO> - This command will get the value of the
specified MO for the specified node.
 cmedit set <node> <MO> <value> - This command will set the value of
the specified MO for the specified node.
 cmedit delete <node> <MO> - This command will delete the specified MO
from the specified node.
 cmedit import <file> - This command will import the specified file into
ENM.
 cmedit export <file> - This command will export the specified MO from
ENM to a file