IPWorks 3GPP AAA Server-HLR D' Interface

Contents

1Introduction
1.1Prerequisites
1.2Related Information

2
Interface Overview
2.1Interface Role
2.2Services
2.3Encapsulation and Addressing

3
Procedures
3.1MAP_SEND_AUTHENTICATION_INFO

4
Information Model
4.1MAP_SEND_AUTHENTICATION_INFO

5
Formal Syntax or Schema

6
Related Standards

Reference List

1   Introduction

This document describes the D' interface between the IPWorks AAA server node and the Home Location Register (HLR) node.

1.1   Prerequisites

Not Applicable.

1.2   Related Information

Definition and explanation of acronyms and terminology, trademark information, and typographic conventions can be found in the following documents:

The standard, related to the HLR D' interface, can be found in the section References.

2   Interface Overview

This section describes the D' interface between the IPWorks AAA server node and HLR node as shown in Figure 1.

The main purpose of D’ reference is to communicate between AAA and HLR. Support of the D’ reference points requires no modifications to the MAP protocol at the HLR.

In IPWorks AAA, the following functionality can be enabled if they are available in HLR:

Figure 1   D' Interface

The functions provided on the D' reference points are a subset of the functions provided on the D' reference points described in TS 23.002:

When IPWorks AAA server supports the D' reference point, it appears to the HLR as a VLR and behaves according to the description of the behavior of a VLR supporting the D' reference point as described in TS 23.002.

2.1   Interface Role

D' interface uses the Mobile Application Part (MAP) protocol to get the authentication vector and other information from HLR.

MAP is an SS7 protocol, which provides an application layer for various nodes in GSM and UMTS mobile core networks and GPRS core networks. With the application layer, the various nodes can communicate with each other to provide services to the mobile phone users.

For D' interface, IPWorks AAA simulates the part of behaviors of VLR in interaction with HLR.

2.2   Services

This section describes the services used within the D' as shown in Table 1.

Table 1    Offered Services

Service

Description

MAP_SEND_AUTHENTICATION_INFO

This service is used between the IPWorks AAA and the HLR to retrieve authentication information from the HLR in D’ interface.

2.3   Encapsulation and Addressing

This section describes the lower-level protocols on the D'.

IPWorks AAA supports MAP standard protocol for accessing HLR data. Using the MAP protocol for the communication between entities in the PLMN implies the use of Transaction Capabilities (TC) and the Signalling Connection Control Part (SCCP) of SS7.

The services offered by the Transaction Capabilities Application Part (TCAP) are used as specified in ITU-T Recommendation (07/96) Q.711 to Q.714.

The services offered by the SCCP are used according to the ITU Recommendation (06/97) Q.771 to Q.775 or ANSI T1.112-20001.

2.3.1   Application Context Supported

Table 2 lists the version of the Application Contexts used in IPWorks AAA, with the operations used by them and, where applicable, whether the operation description is the same as for previous versions.

Table 2    Application Context Supported

AC Name

AC Version

Operations Used

Comments

infoRetrievalContext

v3

sendAuthenticationInfo

  

IPWorks AAA does not support AC negotiation for the moment, which means when receiving a TC-U-ABORT indication primitive (the response to the TC-BEGIN message) with the abort-reason set to "AC-not-supported", IPWorks will take the dialog as failed and no further action.

2.3.2   Application Context Syntax

locationInfoRetrievalContext-v3  OBJECT IDENTIFIER ::= 
{map-ac locInfoRetrieval(5) version3(3)}

2.3.3   SCCP Addressing (ITU-T Standard)

The SCCP addressing consists of the following elements:

2.3.3.1   Calling Party Address

2.3.3.1.1   Without GT

IPWorks AAA uses SPC and SSN in the calling party address. It includes:

The following subsystem numbers are used by IPWorks AAA depending on the configuration:

2.3.3.1.2   With GT

IPWorks AAA uses GT and SSN in the calling party address. The Global Title follows the structure of a Global Title defined in ITU-T Recommendation Q.713 section B4.6 as Figure 2, include:

The following subsystem numbers are used by IPWorks AAA depending on the configuration:

2.3.3.2   Called Party Address

2.3.3.2.1   Numbering Plan is E212

IPWorks AAA uses GT and SSN in the called party address. The Global Title follows the structure of a Global Title defined in ITU-T Recommendation Q.713 section B4.6 as Figure 2, including:

Figure 2   ITU-T SCCP Address Format for TT=40, NP=6, NAI=4

3   Procedures

This section describes the procedures used in connection with the offered and used interfaces of IPWorks.

3.1   MAP_SEND_AUTHENTICATION_INFO

The service is invoked When IPWorks AAA sends a request to HLR to retrieve Authentication Vectors (AV), HLR returns one triplet vectors (RAND, SRES, KC) for a 2G user and one quintuplet vectors (RAND, XRES, CK, IK, AUTN) for 3G users as described in Figure 3.

See Section 4.1 MAP_SEND_AUTHENTICATION_INFO for the service primitives.

Figure 3   MAP_SEND_AUTHENTICATION_INFO Procedure, No Segmentation

4   Information Model

This section describes the information model, including mandatory and optional parameters of each service operation.

The following conventions are used for categorizing parameters, refer to Reference [5].

Table 3    Conventions for Categorizing Parameters

M

The inclusion of the parameter is mandatory. The M category can be used for any primitive type and specifies the corresponding parameters that must be presented in the indicated primitive type.

O

The inclusion of the parameter is a service-provider option. The O category can be used in indication and confirm type primitives and is used for parameters that is optionally included by the service-provider.

U

The inclusion of the parameter is a service-user option. The U category can be used in request and response type primitives. The inclusion of the corresponding parameter is the choice of the service-user.

C

The inclusion of the parameter is conditional. The C category can be used for the following purposes:


  • To indicate that if the parameter is received from another entity, it must be included for the service being considered.

  • To indicate that the service user must decide whether to include the parameter, based on the context on which the service is used.

  • To indicate that one of a number of mutually exclusive parameters must be included (for example, parameters indicating a positive result versus parameters indicating a negative result).

  • To indicate that a service user optional parameter (marked with "U") or a conditional parameter (marked with "C") presented by the service user in a request or response type primitive is to be presented to the service user in the corresponding indication or confirm type primitive.

(=)

When the parameter is appended to one of the above, this symbol means that the parameter gets the same value as the parameter shown at the left.

Blank

The parameter is not presented.

4.1   MAP_SEND_AUTHENTICATION_INFO

4.1.1   Service Primitives

The service primitives are shown in Table 4.

Table 4    MAP_SEND_AUTHENTICATION_INFO

Parameter Name

Request

Indication

Response

Confirm

Invoke ID

M

M(=)

M(=)

M(=)

IMSI

C

C(=)

    

Number of requested vectors

C

C(=)

    

Requesting node type

C

C(=)

    

Re-synchronization Info

C

C(=)

    

Segmentation prohibited indicator

C

C(=)

    

Immediate response preferred indicator

U

C(=)

    

Requesting PLMN ID

C

C(=)

    

AuthenticationSetList

    

C

C(=)

User error

    

C

C(=)

Provider error

      

O

4.1.2   Parameter Use

The parameters used by IPWorks AAA are listed as follows:

Invoke ID: This parameter identifies corresponding service primitives. The parameter is supplied by the MAP service-user and must be unique over each service-user/service-provider interface.

IMSI: This parameter is the International Mobile Subscriber Identity defined in 3GPP Numbering, addressing and identification, TS 23.003 V9.4.0, refer to Reference [4].

Number of requested vectors: A number that indicates how many authentication vectors the VLR will receive. The HLR shall not return more vectors than the number indicated by this parameter. IPWorks AAA server always requires one authentication vectors.

Requesting node type: The type of the requesting node. This parameter shall be presented in the first (or only) request of the dialogue. If multiple service requests are presented in a dialogue then this parameter shall not be presented in any service request other than the first one. In IPWorks AAA server we use 0 as VLR node type.

Re-synchronisation Info: This parameter will be used in resynchronization case. If multiple service requests are presented in a dialogue, then this parameter shall not be presented in any service request other than the first one.

AuthenticationSetList: This parameter is a set of one to five authentication vectors that are transferred from the HLR to the VLR.

5   Formal Syntax or Schema

IPWorks AAA supports the constants and data types for above operations as specified in Mobile Application Part (MAP) specification 3GPP TS 29.002 version 8.13.0, Section 17 Abstract syntax of the MAP protocol, refer to Reference [5].

6   Related Standards


Reference List

Ericsson Documents
[1] Glossary of Terms and Acronyms.
[2] Trademark Information.
[3] Typographic Conventions.
Standards
[4] 3GPP Numbering, addressing and identification, TS 23.003 V9.4.0.
[5] Mobile Application Part (MAP) specification 3GPP TS 29.002 version 8.13.0.


Copyright

© Ericsson AB 2016. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    IPWorks 3GPP AAA Server-HLR D' Interface