feature 1673 - nvs registration (application server mode)

MSC Server, Rel. M16.2, Feature Documentation, version 2

Feature 1673: NVS Registration (Application Server Mode)

DN0628541

Issue 8-0-1

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their compo-nents.

If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Siemens Networks for any additional information.

2 DN0628541Issue 8-0-1

Feature 1673: NVS Registration (Application ServerMode)

Id:0900d80580a3848c

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2013/12/21. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal, Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-satzes.

DN0628541Issue 8-0-1

3


Id:0900d80580a3848c

Table of ContentsThis document has 74 pages.

1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Benefits for the operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Requirements for using the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.1 Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.3 Products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.1 Subscriber data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.1.1 Subscriber data in HSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4.1.2 Subscriber data in HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.1.3 Subscriber data in LDAP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.2 Serving Profile Database (SPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.3 Repository solutions in different deployment scenarios. . . . . . . . . . . . . 161.4.3.1 Multifunction VoLTE AS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.3.2 MMTel AS/IM-SSF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4.4 Registration in Multifunction VoLTE AS . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.4.1 Subscriber data storage in HSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.4.2 Subscriber data storage in HSS and HLR . . . . . . . . . . . . . . . . . . . . . . . 221.4.4.3 Subscriber data storage in LDAP Server and HLR . . . . . . . . . . . . . . . . 231.4.5 Registration in MMTel AS/IM-SSF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.4.5.1 Subscriber data storage in HSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.4.5.2 Subscriber data storage in HSS and HLR . . . . . . . . . . . . . . . . . . . . . . . 311.4.5.3 Subscriber data storage in LDAP Server and HLR . . . . . . . . . . . . . . . . 311.4.5.4 Subscriber data storage in HLR only . . . . . . . . . . . . . . . . . . . . . . . . . . . 381.4.5.5 Simultaneous registration in Open TAS and MSS network elements

through a single IMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421.4.6 Subscriber data modification notifications and georedundancy for Open

TAS based VoLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441.4.7 Location and visited network information handling during registration . 551.4.8 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561.4.9 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571.4.9.1 Open TAS specific parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571.4.9.2 SIP-I PRFILE parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611.4.10 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611.4.11 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621.4.12 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621.4.12.1 TCP support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621.4.12.2 SCTP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621.5 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621.6 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621.7 Related and interworking features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631.8 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651.9 Operator interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 DN0628541Issue 8-0-1


Id:0900d80580a3848c

1.9.1 MMLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651.9.2 Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681.10 Subscriber interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681.11 Network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681.12 External interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Main changes in Feature 1673: NVS Registration (Application Server Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Changes in the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Changes in the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

DN0628541Issue 8-0-1

5


Id:0900d80580a3848c

List of FiguresFigure 1 Open TAS registration - protocols and elements . . . . . . . . . . . . . . . . . . . 7Figure 2 Interfaces toward subscriber information-related databases . . . . . . . . . 10Figure 3 Subscriber data storage in HSS—High-level view. . . . . . . . . . . . . . . . . 17Figure 4 Subscriber data storage in HSS and HLR—High-level view . . . . . . . . . 18Figure 5 Subscriber data storage in LDAP Server and HLR—High-level view . . 19Figure 6 Subscriber data storage in HSS—High-level view. . . . . . . . . . . . . . . . . 20Figure 7 Subscriber data storage in HSS and HLR—High-level view . . . . . . . . . 20Figure 8 Subscriber data storage in LDAP Server and HLR—High-level view . . 21Figure 9 Subscriber data storage in HLR only—High-level view . . . . . . . . . . . . . 22Figure 10 Initial registration—Retrieving VoIP subscriber data from LDAP and sup-

plementary service data from HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 11 Re-registration—Retrieving VoIP subscriber data from LDAP and supple-

mentary service data from HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 12 User-initiated deregistration—Retrieving VoIP subscriber data from LDAP

and supplementary service data from HLR . . . . . . . . . . . . . . . . . . . . . . 26Figure 13 Network-initiated deregistration—Retrieving VoIP subscriber data from

LDAP and supplementary service data from HLR . . . . . . . . . . . . . . . . . 26Figure 14 Implicit registration on the originating side—Retrieving VoIP subscriber

data from LDAP and supplementary service data from HLR. . . . . . . . . 28Figure 15 Terminating implicit registration—Retrieving VoIP subscriber data from

LDAP and supplementary service data from HLR . . . . . . . . . . . . . . . . . 30Figure 16 Initial registration—Retrieving VoIP subscriber data from LDAP and sup-

plementary service data from HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figure 17 Re-registration—Retrieving VoIP subscriber data from LDAP and supple-

mentary service data from HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 18 User-initiated deregistration—Retrieving VoIP subscriber data from LDAP

and supplementary service data from HLR . . . . . . . . . . . . . . . . . . . . . . 34Figure 19 Network-initiated deregistration—Retrieving VoIP subscriber data from

LDAP and supplementary service data from HLR . . . . . . . . . . . . . . . . . 34Figure 20 Implicit registration on the originating side—Retrieving VoIP subscriber

data from LDAP and supplementary service data from HLR. . . . . . . . . 36Figure 21 Implicit registration on the terminating side—Retrieving VoIP subscriber

data from LDAP and supplementary service data from HLR. . . . . . . . . 37Figure 22 Unsuccessful registration - IMSI not found . . . . . . . . . . . . . . . . . . . . . . 39Figure 23 Successful registration - LDAP query still possible despite NVS without

LDAP license activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figure 24 Successful registration in the absence of LDAP . . . . . . . . . . . . . . . . . . 41Figure 25 VLR update for a SIP registered subscriber on receipt of a NoteSubscrib-

erDataModified MAP message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 26 Subscriber previously registered in Homing SCC AS has become unregis-

tered. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figure 27 VLR update in Open TAS (MMTel AS/IP-SM-GW) . . . . . . . . . . . . . . . . 49Figure 28 Subscriber registered in Open TAS (MMTel AS/IP-SM-GW) as SIP and CS

50Figure 29 NVS-Data repository data management during registration . . . . . . . . . 52Figure 30 Invalid or no GT address returned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Figure 31 Matching GT address returned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figure 32 Non-matching GT address returned . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 DN0628541Issue 8-0-1


Id:0900d80580a3848c

List of TablesTable 1 Subscriber registration status in VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Table 2 Content of the SRIforSM sent from the Homing SCC AS to the HLR . . 46

DN0628541Issue 8-0-1

7


Feature description

Id:0900d80580a37f33

1 Feature description

1.1 IntroductionThis feature provides functionality related to the registration of Session Initiation Protocol (SIP) clients—that is, user equipment (UE)—in IMS environments when the Nokia Siemens Networks Open Telecom Application Server (Open TAS) / Nokia Siemens Networks Mobile VoIP Server (NVS) is used as a telephony application server.

g For stylistic reasons, the term Open TAS, rather than Open TAS/NVS, is used through-out the rest of this document. There is no difference in functionality between the Open TAS and the NVS operating in IMS environments. For more information on the naming conventions used in this document, see the document entitled Impact of the Nokia Siemens Networks Open Telecom Application Server (Open TAS) on Documentation.

When a SIP client registers in the IMS, the S-CSCF triggers third-party registration toward the Open TAS over the IP Multimedia Service Control (ISC) interface using the SIP protocol. The Open TAS then makes use of the Home Subscriber Server (HSS), or the Home Location Register (HLR), to retrieve the necessary subscriber service profile.

Figure 1 Open TAS registration - protocols and elements

In the case of an HSS centric approach, both VoIP subscriber data and supplementary service data are retrieved from the Home Subscriber Server (HSS) over the Sh inter-face. This approach is license based and configurable using the PRI_REPO_SOURCE (002:2056) PRFILE parameter. For more information, see Feature 2027: Sh for NVS Subscriber Repository, Feature Description.

In the case of an HLR centric approach, the Open TAS makes use of the Mobile Appli-cation Part (MAP) protocol to download supplementary service data (MMTEL data). The VoIP subscriber’s SIP specific basic data can be downloaded from the HSS over the Sh interface or from the SIP Subscriber Database (SDB) using Lightweight Directory Access Protocol (LDAP). During registration the Open TAS queries the HSS or the SDB (that is, the LDAP directory) to retrieve the VoIP subscriber’s data and retrieve the VoIP subscriber’s IMSI so that it [the Open TAS] can initiate MAP operations toward the HLR to download the subscriber’s supplementary service data. This approach is also license

UE P-CSCFS-CSCF

HLR

LDAP

MAP

LDAP

ISC (SIP)

SIPSIP HSS

Dx, Cx,(DIAMETER)

Sh

Open TAS

Open TAS

VoLTE/IMSSubscriber

8 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

based and configurable using the PRI_REPO_SOURCE (002:2056) PRFILE parame-ter.

Even though an HSS or SDB is preferred alongside the Open TAS to store VoIP-specific subscriber data, it is not mandatory: if the Open TAS without LDAP connection function-ality is active in the network, then VoIP users without a VoIP subscription requiring access to the SDB LDAP directory can also register and access the network. For more information about this functionality, see section Subscriber data storage in HLR only.

The choice between the use of the HSS and the HLR can be defined on user level.

1.2 Benefits for the operatorThe Open TAS provides services for both fixed and mobile networks. These services are provided over the SIP ISC interface through a single converged architecture. The Open TAS provides voice and multimedia call functionality, message interworking between SMs and SIP messages, as well as end-to-end SIP services—for example, direct instant messaging between terminals.

The Open TAS provides inbuilt service consistency and scalable resiliency in VoLTE networks where more than one Open TAS is deployed. This is achieved by the ability of the Open TAS to understand and handle VoLTE subscriber data changes in the respec-tive registers (HSS/HLR/LDAP) and to restore services without preceding registration. This enables VoLTE operators to sustain end user service even during planned software upgrades, to minimize recovery time in the case of a disaster, and to avoid the total loss of service for a large number of subscribers and the loss of revenue in the case of a major disaster.

The Open TAS also provides the possibility of using the same Intelligent Network (IN) services, such as CAMEL pre-paid and Virtual Private Numbering (VPN) services for VoIP subscribers registered in the IMS, in much the same way as for GSM/UMTS sub-scribers. In such cases the Open TAS provides flexible routing schemes to enable the use of the same national numbering plans when both GSM/UMTS and VoIP subscribers make calls.

The Open TAS comes with integrated support for emergency calls as well as other reg-ulatory requirements such as lawful interception and number portability, based on the same conventions as GSM/UMTS mobile networks. However, in VoLTE deployments, the emergency solution is recommended to be based on the Emergency Call Session Control Function (E-CSCF).

The Open TAS provides functionality that enables VoIP operators to allow VoIP sub-scribers without a SIP profile in the SDB LDAP directory to roam inside the operators’ VoIP networks. This provides VoIP operators with the opportunity to increase network traffic, gain greater market share, and increase revenue. Since this functionality removes the need for an LDAP solution, operators wishing to try out the Open TAS can do so with no extra costs. For more information about this functionality, see section Sub-scriber data storage in HLR only.

The Open TAS also provides functionality that limits revenue leakage for operators by preventing their subscribers from being simultaneously logged into the VoIP service. This same functionality also helps to minimize subscriber complaints concerning the dispute of simultaneous calls on their billing statements.

DN0628541Issue 8-0-1

9


Feature description

Id:0900d80580a37f33

1.3 Requirements for using the feature

1.3.1 SoftwareThis feature requires Feature 906: MSRN Allocation Enhancements to be active in order to function.

The Open TAS without LDAP connection functionality is controlled by the ON/OFF license NVS without LDAP (feature code: 1556).

Simultaneous registration functionality is controlled by the ON/OFF license Restore data for SIP registration (feature code: 3177).

Subscriber data modification notifications and georedundancy functionality requires the following license to be activated:

• Internal SCP LK (feature code 3216)

1.3.2 HardwareThis feature requires the following hardware to execute NVS/Open TAS functionality:

• SIP Call Processing Unit (SCPU)

The SCPU should be equipped with at least:– 1 GB memory– CP816-A or newer CPU

For more information on hardware effects and network elements involved, see section Configuration requirements in the feature activation manual of Feature 1673: NVS Reg-istration (Application Server Mode).

1.3.3 ProductsThis feature functions in the following products:

• Nokia Siemens Networks MSC Server (MSS) running NVS software

1.4 Functionality

1.4.1 Subscriber data managementThe Open TAS accesses the following central databases to download subscriber-specific data:

• HSS • HLR • LDAP server (SIP Subscriber Database (SDB))

The Open TAS can use the Sh interface and the HSS to retrieve supplementary service data (MMTEL data) and IN related information. Supplementary service data in the HLR is not used by the Open TAS in this case. This approach is license based and configu-rable using the PRI_REPO_SOURCE (002:2056) PRFILE parameter. For more infor-mation, see Feature 2027: Sh for NVS Subscriber Repository, Feature Description.

Alternatively, the Open TAS can use a combination of the HLR and the HSS to maintain IMS subscriber-related information. The Open TAS accesses the HLR to retrieve the

10 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

standard supplementary service and IN related information and it accesses the HSS over the Sh interface to obtain the basic VoIP subscription information of SIP subscrib-ers, that is, the IMSI, MSISDN, Group Profile ID, XCAP password, and so on.

As a third alternative, the Open TAS can use a combination of the HLR and LDAP direc-tory to maintain IMS subscriber-related information. The Open TAS accesses the HLR to retrieve the standard supplementary service and IN related information and it accesses the LDAP directory to obtain the basic VoIP subscription information of SIP subscribers, that is, the IMSI, MSISDN, Group Profile ID, XCAP password, and so on.

Overall service brokering is performed in the S-CSCF, based on the initial Filter Criteria (iFC) stored in the Home Subscriber Server (HSS). If these filter criteria have been con-figured to use Open TAS for REGISTER, INVITE and MESSAGE requests, the S-CSCF routes the requests to the Open TAS over the IP multimedia service control (ISC) inter-face.

Figure Interfaces toward subscriber information-related databases illustrates the MAP, LDAP and Sh interfaces of the Open TAS toward the required subscriber information-related databases and directories.

Figure 2 Interfaces toward subscriber information-related databases

Each SIP subscription requires an individual International Mobile Subscriber Identity (IMSI) as well as the E.164 address within the Public Land Mobile Network (PLMN). In terminating transactions (Mobile Terminating SMs, Mobile Terminating Calls, and so on), it is possible to use either the specific allocated E.164 address directly or to use the group address of the MultiSIM hunting group, if the feature is active in the system, to complete the call or SMS.

1.4.1.1 Subscriber data in HSSThe HSS is configured with the basic IMS subscription required for identitly handling, authentication, registration, call routing, and so on.

Related to the actual service execution, the initial Filter Criteria (iFC) are also configured to route the REGISTER, INVITE, and MESSAGE SIP requests to the Open TAS to provide value added services for basic calls and messaging. In addition, when the HSS is used as the source of service data for Open TAS subscribers, the respository data are also configured. These repository data contain subscriber-specific service configura-tions in XML format.

The HSS can contain the data of several repositories, which are provisioned depending on which repository model and which functionalities of the Open TAS are used. The fol-

Open TAS HLR

CS subscriptionsMAPVoIP

LDAP HSS

SSIP subscriptions

hLDAPSIP subscriptions

DN0628541Issue 8-0-1

11


Feature description

Id:0900d80580a37f33

lowing sections provide information about the different HSS repository models used by the Open TAS.

g If multiple IP Multimedia Public Identities (IMPUs) are configured for the subscriber, then they must be configured as a part of the Alias Group since repository data are attached to Alias Groups.

VoIP subscriber dataVoIP subscriber data is retrieved from a repository in the HSS, named SIP-Basic-Data. The data consists of the following information:

• IMSI

This number represents the subscriber’s International Mobile Subscriber Identifica-tion (IMSI).

g In the case of fixed users and soft clients (that is, non-VoLTE clients), it is not man-datory to configure the IMSI in the SIP-Basic-Data repository if MMTEL data is pro-visioned in the HSS.

When the IMSI is not available in the retrieved SIP-Basic-Data repository, the Open TAS generates the IMSI based on the following rules:

• The Mobile Country Code (MCC) is set to 999.

• The Mobile Network Code (MNC) is set to 99.

• The remaining 10 digits are filled with the MSISDN received in the SIP-Basic-Data repository.

If the MSISDN is less than 10 digits, then the remaining digits are filled with zeroes.

For example: MSISDN=66881234 -> IMSI=999990066881234

If the MSISDN is longer than 10 digits, then the last 10 digits of the MSISDN are used.

For example: MSISDN=66881234567 -> IMSI=999996881234567

• MSISDN

This number represents the Mobile Station International ISDN Number (MSISDN) of the subscriber.

• Auth-Info

This field is used by the Ut/XCAP functionality when authenticating PUT, GET and DELETE HTTP requests. It represents the user’s XCAP Authentication Secret.

• Group Profile ID

This field represents the subscriber’s VoIP (SIP) group profile identification.

• Common URI/Used

The value of this field can override the Calling Party identity of the subscriber (if the Common URI is used) and can be applied when one alphanumeric SIP URI (for example, bob@domain) should be replaced by another logical SIP URI (for example, cleaningservice@domain).

• Location ID

This field is used to set a subscriber-specific location in the Open TAS.

12 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

• Common CLI

This field defines an MSISDN to be used as a CLI for the subscriber and is used when a numeric SIP URI (for example, 12344@domain) needs to be replaced by another numeric SIP URI.

• Messaging Profile ID

This field represents the Messaging Profile identifier as used by the subscriber.

Supplementary service dataSupplementary service data is retrieved from two repositories in the HSS, named MMTEL-Services and MMTEL-Services-Extra.

MMTEL-ServicesThe MMTEL-Services repository contains standard MMTEL data in XML format. The data consists of the following information:

• OIP

Originating Identity Presentation (OIP) information controls whether the called party can see the identity of the calling party.

The corresponding supplementary service in the HLR is called Calling Line Identity Presentation (CLIP).

• OIP override

This field controls whether OIP can be overwritten.

The corresponding supplementary service in the HLR is called CLIP override.

• OIR

Original Identity Restriction (OIR) information controls whether the calling party can hide his/her identity from the called party.

The corresponding supplementary service in the HLR is called Calling Line Identity Presentation Restriction (CLIR).

• TIP

Terminating Identification Presentation (TIP) information controls whether the calling party can see the connected line identity on the terminal display when CLI presentation has not been restricted by the called subscriber or by the operator.

The corresponding supplementary service in the HLR is called Connected Line Iden-tification Presentation (COLP).

• TIP override

This field controls whether TIP can be overwritten.

The corresponding supplementary service in the HLR is called COLP override.

• TIR

Terminating Identity Restriction (TIR) information controls whether the calling party can hide his/her identity from the called party.

The corresponding supplementary service in the HLR is called Connected Line Identity Presentation Restriction (COLR).

DN0628541Issue 8-0-1

13


Feature description

Id:0900d80580a37f33

• Malicious call identification (MCID)

This field is used to activate the logging of terminated calls using trace reports. Mali-cious Call Identification (MCID) is implemented only for SIP terminated cases.

• Explicit Call Transfer (ECT)

This field controls whether the user is allowed to transfer two ongoing calls (attended) or to transfer a call to a third user and leave the call.

• Conference (CONF)

This field controls whether the user is allowed to invite others to an existing call.

• Call Hold (HOLD)

This field controls whether the subscriber is allowed to put a call on hold.

• User-controlled Call Forwarding

This field is used when defining the conditions of Call Forwarding controlled by the user.

• Call Diversion Notification services

This field controls whether the calling and called party are notified about call diver-sion, and it also controls who can see the identities of the parties involved in call diversion.

• Call Diversion Operator options

This field is used to control call diversion options set by the operator.

• User-controlled Barring services

This field is used when defining the conditions of Call Barring controlled by the user.

• Call Waiting

This field is used to control whether the calling party can receive a notification about the call waiting situation.

g This parameter is not used by the Open TAS currently.

This information is stored in XML format in the HSS. For more information on each of these fields and the structure of the XML file passed in Sh and Dh messages from the HSS to the Open TAS, see the Sh Interface Description document.

g When XML data is sent from the HSS to the Open TAS, the Open TAS must parse the XML data from the relevant answer message (for example, User-Data-Answer), before it can store the information in the SPD and/or VLR.

MMTEL-Services-ExtraThe MMTEL-Services-Extra repository contains Open TAS specific, advanced service data in XML format, which includes the provisioned basic services (for example, audio, video, and so on) as well as non-standardized supplementary service data that is nec-essary for proper subscriber and service handling—such as Operator Determined Bar-rings, IN triggers, Routing Category, and so on—and to allow operators to provide a seamless service experience between 2G/3G and 4G domains. The data consists of the following information:

• Provisioned services

This field contains the list of allowed basic services for the given subscriber.

14 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

• CNAP

The Calling Name Presentation (CNAP) field controls whether a custom text is sent as calling party identity.

• Call Deflection (CD)

This field controls whether to start the Call Forwarding service when the client sends 302/301 responses with a valid Forwarded To URI in the Contact header.

• Carrier identification code/picLock

This field is used to identify the Preferred Interexchange Carrier (PIC).

• Routing Category/Additional Routing Category

This field is used when performing different analyses, for example, Routing Attribute analysis.

• Zone codes

This field is used to define the zone codes of the subscriber.


• National Specific SS code

This field is used to activate certain non-standard services.

• PNP Index

This field is used to identify the subscriber’s Private Numbering Plan (PNP).

• Redirection Destination Index

This field is used to identify the redirection destination.

• Subscriber category

This field is used to identify the subscriber category as defined by Q.763, the ITU-T specification that defines the formats and codes of the ISDN User Part (ISUP) of Sig-nalling System No. 7 (SS7).

• enhanced Multi-Level Precedence and Pre-emption service (eMLPP)

This field is used to define the levels of precedence for call setup and for call conti-nuity in case of a handover.


• Operator Determined Barring

This field is used to set barring services.

• Operator-controlled Call Forwarding

This field is used to set specific call forwarding for a user when the user does not define a Forwarded-To-Number (FTN) for a given forwarding type.

• O-CSI

This element contains Originating CAMEL Subscription Information (CSI) specific settings.

• T-CSI

This element contains Terminating CAMEL Subscription Information specific set-tings.

DN0628541Issue 8-0-1

15


Feature description

Id:0900d80580a37f33

• VT-CSI

This element contains Visited Mobile Switching Center (VMSC) Terminating CAMEL Subscription Information specific settings.

• D-CSI

This element contains Dialled Service CAMEL Subscription Information specific set-tings.

• M-CSI

This element contains Mobility Management CAMEL Subscription Information specific settings.

• MO-SMS-CSI

This element contains Mobile Originated SMS CAMEL Subscription Information set-tings.

• MT-SMS-CSI

This element contains Mobile Terminated SMS CAMEL Subscription Information settings.

• Call-related IN triggers

This field is used to define the service triggers used in activating call-related intelli-gent network services.

• SMS-related IN triggers

This field is used to define the service triggers used in activating SMS-related intel-ligent network services.

• MM-related IN triggers

This field is used to define the service triggers used in activating MM-related intelli-gent network services.

• CAMEL Translation Information Flag

This field is used to indicate whether or not the HLR attempts to perform any trans-lation or other checks when the subscriber registers an FTN.

• Fraud data

This field is used to set indicators for fraud information.

This information is stored in XML format in the HSS. For more information on each of these fields and the structure of the XML file passed in Sh and Dh messages from the HSS to the Open TAS, see the Sh Interface Description document.

g When XML data is sent from the HSS to the Open TAS, the Open TAS must parse the XML data from the relevant answer message (for example, User-Data-Answer), before it can store the information in the SPD and/or VLR.

1.4.1.2 Subscriber data in HLRThe HLR stores supplementary service data used for 2G/3G subscribers. These supple-mentary services are:

• Calling Line Identity Presentation (CLIP) • Connected Line Identity Presentation (CLOP)

16 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

• Calling Line Identity Restriction (CLIR) • Connected Line Identity Restriction (COLR) • Call Forwarding Unconditional (CFU) • Call Forwarding not Reachable (CFNRc) • Call Forwarding Busy (CFB) • Call Forwarding no Reply (CFNR) • Barring of all Incoming Calls (BAIC) • Barring of all Outgoing Calls (BAOC) • Barring of Outgoing International Calls (BOIC) • Call Hold (CH) • Call Waiting (CW) • Conference (MPTY)

g The Open TAS uses the standard MAP-D interface toward the HLR and does not require any proprietary functionality from the HLR allowing for multi-vendor configurations.

1.4.1.3 Subscriber data in LDAP serverThe LDAP server can contain the same VoIP subscriber data that is stored in the HSS in the Basic-SIP-Data repository, that is, the IMSI, MSISDN, XCAP password, and so on as it provides an alternative to HSS repository data.

g It is mandatory to configure the IMSI in the LDAP server. If the IMSI is missing, registra-tion and implicit registration requests are rejected.

g MMTEL data cannot be stored in the LDAP server.

1.4.2 Serving Profile Database (SPD)Internally, the Open TAS makes use of the VLR in a similar way as the MSS but in addi-tion, it also requires a Serving Profile Database (SPD) located in the SCPU signaling units. The SPD contains a registered subscriber’s SIP-related data and is linked to the VLR, while the VLR stores the subscriber’s standard GSM-related data. When a sub-scriber registers in the Open TAS, the subscriber’s SIP data is downloaded from the SDB LDAP directory and stored in the SPD. The subscriber’s GSM-related data, stored in the HLR, is downloaded to the VLR.

g When the Sh based approach is used to download supplementary service data—that is, supplementary service data is retrieved from the HSS—gateway terminating services related data is stored in the SPD. For more information, see Feature 2027: Sh for NVS Subscriber Repository, Feature Description.

1.4.3 Repository solutions in different deployment scenariosDifferent deployment scenarios and different subscriber types may require different repositories to be used. Thus, based on the planned subscriber types, operators can decide where (HSS, HLR, LDAP) subscriber data (basic VoIP data, MMTEL data, and so on) is stored.

g The Open TAS supports the different data models in parallel so the used model can be provisioned on a subscriber basis.

DN0628541Issue 8-0-1

17


Feature description

Id:0900d80580a37f33

The main deployment scenarios are:

• Multifunction VoLTE Application Server (MMTel AS/IM-SSF/IP-SM-GW/SCC AS)

This combination is typically used for VoLTE subscribers when one subscriber is provided with the following Open TAS functionalities:

– MMTel Application Server (MMTel AS): multimedia supplementary services

– IP Multimedia Subsystem Switching Service Function (IM-SSF): IN services using CAMEL/INAP/SINAP

– Service Centralization & Continuity Application Server (SCC AS): Single Radio Voice Call Continuity (SRVCC), Terminating Access Domain Selection (T-ADS), Homing

– IP Short Message Gateway (IP-SM-GW): SMS

g IP-SM-GW is optional as SMS can be provided by using CS fallback (CSFB).

• MMTel AS/IM-SSF

The Open TAS can also provide supplementary services and IN services for the fol-lowing types of subscribers:

– Fixed users (Analog Telephone Adapter (ATA), Access Gateway Control Function (AGCF))

– Soft clients on portable devices connected over broadband access (WiFi, xDSL, Mobile Broadband)

1.4.3.1 Multifunction VoLTE AS

Subscriber data storage in HSSIn this model, the Open TAS uses the HSS to retrieve all types of subscriber data so both basic SIP data and MMTEL supplementary service related data are stored in the HSS. This is the standard 3GPP defined model of subscriber data storage in the IP mul-timedia subsystem (IMS).

Figure 3 Subscriber data storage in HSS—High-level view

During registration, the Open TAS retrieves the SIP-Basic-Data, MMTEL-Services, and MMTEL-Services-Extra repositories from the HSS over the Diameter Sh interface and stores them in its internal database. If the IP-SM-GW is activated for the UE, then the

S-CSCF Open TAS HSS

Registration

HLR

Successful

Retrieve basic SIP data from HSS

Retrieve MMTEL data from HSS

Update IP-SM-GW address in HLR

Retrieve SRVCC data from HSS

Update SRVCC data in HSS if needed

18 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

IP-SM-GW subrole of the Open TAS updates the IP-SM-GW address attribute in the HLR with its own address over the MAP interface. At the end of the procedure, the Open TAS executes the SRVCC related processes, that is, it retrieves and updates SRVCC data from/in the HSS over the Sh interface.

g HLR provisioning is still needed to handle the cases when the UE is camping in the 2G/3G network but the provisioned HLR data is not used by the Open TAS.

For more information on this model, see Feature 2027: Sh for NVS Subscriber Reposi-tory, Feature Description.

Subscriber data storage in HSS and HLRIn this model, the Open TAS uses the HSS to retrieve basic SIP data and MMTEL sup-plementary service related data is stored in the HLR.

This deployment is for operators who want to reuse the existing (already provisioned) subscriber records in the HLR currently used for 2G/3G access and use the same sub-scriber data in LTE access with seamless service synchronization between the CS and LTE domains.

Figure 4 Subscriber data storage in HSS and HLR—High-level view

During registration, the Open TAS retrieves the SIP-Basic-Data repository from the HSS over the Diameter Sh interface and then MMTEL supplementary service data from the HLR over the standard MAP interface. The Open TAS then stores both types of data in its internal database. If the IP-SM-GW is activated for the UE, then the IP-SM-GW role of the Open TAS updates the IP-SM-GW address attribute in the HLR with its own address over the MAP interface. At the end of the procedure, the Open TAS executes the SRVCC related processes, that is, it retrieves and updates SRVCC data from/in the HSS over the Sh interface.

When the Open TAS retrieves MMTEL data using MAP RestoreData, the subscriber data (that is, the VLR address) is not modified during this procedure. In this solution, the subscriber record in the HLR is used by the MSS and the Open TAS.

For more information on this model, see Feature 2027: Sh for NVS Subscriber Reposi-tory, Feature Description.

Subscriber data storage in LDAP Server and HLRIn this model, the Open TAS uses an LDAP server to retrieve basic SIP data and the MMTEL supplementary service related data is stored in the HLR.

S-CSCF Open TAS HSS

Registration

HLR

Successful


Retrieve MMTEL data from HLR




DN0628541Issue 8-0-1

19


Feature description

Id:0900d80580a37f33

This deployment is for operators who want to reuse the existing (already provisioned) subscriber records in the HLR currently used for 2G/3G access and use the same sub-scriber data in LTE access with seamless service synchronization between the CS and LTE domains. In this case, the HSS is not provisioned with Open TAS related data, the external LDAP server and the HLR are used instead. The HSS, however, can still be used for other operations over the Sh interface, such as IMPU retrieval or T-ADS infor-mation retrieval by the SCC AS role of the Open TAS, or to download/modify SRVCC related information in the HSS.

In the NSN portfolio, the One-NDS product can serve as the LDAP server since the Open TAS supports the redundancy model of One-NDS.

Figure 5 Subscriber data storage in LDAP Server and HLR—High-level view

During registration, the Open TAS retrieves the SIP-Basic-Data repository from the LDAP server and then retrieves MMTEL supplementary service data from the HLR over the standard MAP interface. The Open TAS stores both of these in its internal database. If the IP-SM-GW is activated for the UE, then the IP-SM-GW role of the Open TAS updates the IP-SM-GW address attribute in the HLR with its own address over the MAP interface. At the end of the procedure, the Open TAS executes the SRVCC related pro-cesses, that is, it retrieves and updates SRVCC data from/in the HSS over the Sh inter-face.

When the Open TAS retrieves MMTEL data using MAP RestoreData, the subscriber data (that is, the VLR address) is not modified during this procedure. In this solution, the subscriber record of the HLR is used by the MSS and the Open TAS.

1.4.3.2 MMTel AS/IM-SSF

Subscriber data storage in HSSIn this model, the Open TAS uses the HSS to retrieve all types of subscriber data so both basic SIP data and MMTEL supplementary service related data are stored in the HSS. This is the standard 3GPP defined model of subscriber data storage in the IMS.

S-CSCF Open TAS HSS

Registration

HLR

Successful

LDAP Server

Retrieve basic SIP data from LDAP Server





20 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 6 Subscriber data storage in HSS—High-level view

During registration, the Open TAS retrieves the SIP-Basic-Data, MMTEL-Services and MMTEL-Services-Extra repositories from the HSS over the Diameter Sh interface and stores them in its internal database.

g HLR provisioning is not needed for this type of subscribers.

Subscriber data storage in HSS and HLRIn this model, the Open TAS uses the HSS to retrieve basic SIP data and MMTEL sup-plementary service related data is stored in the HLR.

This deployment is for operators who want to reuse the existing HLR for storing supple-mentary services for fixed and broadband users and optionally want to provide the pos-sibility to send and receive SMS.

Figure 7 Subscriber data storage in HSS and HLR—High-level view

During registration, the Open TAS retrieves the SIP-Basic-Data repository from the HSS over the Diameter Sh interface and retrieves MMTEL supplementary service data from the HLR over the standard MAP interface. The Open TAS then stores these data in its internal database.

For fixed and broadband users, the Open TAS retrieves MMTEL data using the MAP Update Location operation, which means that the subscriber record in the HLR is exclu-sively used by the Open TAS (that is, not used for 2G/3G subscription) since during the Update Location procedure, the HLR sets the VLR address to the address of the Open TAS.

Since the VLR address in the HLR contains the address of the Open TAS, fixed and broadband users can send and receive SMS—for more information, see Feature 1760: NVS Messaging (Application Server Mode), Feature Description.

g The IP-SM-GW functionality is not required since the IP-SM-GW can be used when the UE can be located in both the CS and PS domains, but in this case, the UE is always in the PS domain.

S-CSCF Open TAS HSS

Registration

Successful


Retrieve MMTEL data from HSS

S-CSCF Open TAS HSS

Registration

HLR

Successful



DN0628541Issue 8-0-1

21


Feature description

Id:0900d80580a37f33

Subscriber data storage in LDAP Server and HLRIn this model, the Open TAS uses an LDAP directory to retrieve basic SIP data, and MMTEL supplementary service related data is stored in the HLR.

This deployment is for operators who want to reuse the existing HLR for storing supple-mentary services data for fixed and broadband users and optionally want to provide the possibility to send and receive SMS. In this case, the HSS is not provisioned with Open TAS related data, the external LDAP server and the HLR are used. The HSS, however, can still be used over the Sh interface for other purposes, such as IMPU retrival.

In the NSN portfolio, the One-NDS product can be used as the LDAP server since the Open TAS supports the redundancy model One-NDS.

Figure 8 Subscriber data storage in LDAP Server and HLR—High-level view

During registration, the Open TAS retrieves the SIP-Basic-Data repository from the LDAP server and then retrieves the MMTEL supplementary service data from the HLR over the standard MAP interface. The Open TAS stores these data in its internal data-base.

For fixed and broadband users, the Open TAS retrieves MMTEL data using the MAP Update Location operation, which means that subscriber record in the HLR is exclu-sively used by the Open TAS (that is, not used for 2G/3G subscription) since during the Update Location procedure, the HLR sets the VLR address to the address of the Open TAS.


g The IP-SM-GW functionality is not required since the IP-SM-GW can be used when the UE can be located in both the CS and PS domains, but in this case, the UE is always in the PS domain.

Subscriber data storage in HLR onlyMMTEL supplementary service data is stored in the HLR, while SIP Basic Data is gen-erated from the registration request.

This data model can be used in the cases when:

• The operator does not wish to deploy an LDAP server. • The operator wants to allow other networks’ users to register in the Open TAS.

g This use case works only with NSN IMS since in LDAPless scenarios, the Open TAS uses proprietary functionalities of the NSN IMS.

S-CSCF Open TAS HLR

Registration

LDAP Server

Successful

Retrieve basic SIP data from LDAP Server


22 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 9 Subscriber data storage in HLR only—High-level view

During registration, the Open TAS generates SIP Basic Data from the received REGISTER message, retrieves the MMTEL supplementary service data from the HLR over the standard MAP interface and then stores these in its internal database.

For fixed and broadband users, the Open TAS retrieves MMTEL data using the MAP Update Location operation, which means that the subscriber record in the HLR (which can be a foreign HLR) is exclusively used by the Open TAS (that is, not used for 2G/3G subscription) since during the Update Location procedure, the HLR sets the VLR address to the address of the Open TAS.


1.4.4 Registration in Multifunction VoLTE AS

1.4.4.1 Subscriber data storage in HSSFor detailed descriptions of the various registration use cases when all subscriber data is stored in the HSS, see the following sections in Feature 2027: Sh for NVS Subscriber Repository, Feature Description:

• Initial registration—Retrieving VoIP subscriber data and supplementary service data from HSS

• Reregistration—Retrieving VoIP subscriber data and supplementary service data from HSS

• User-initiated deregistration • Network-initiated deregistration • Implicit registration on the originating side • Implicit registration on the terminating side

1.4.4.2 Subscriber data storage in HSS and HLRFor detailed descriptions of the various registration use cases when basic SIP sub-scriber data is stored in the HSS and MMTEL supplementary service data is stored in the HLR, see the following sections in Feature 2027: Sh for NVS Subscriber Repository, Feature Description:

• Initial registration—Retrieving VoIP subscriber data from HSS and supplementary service data from HLR

S-CSCF Open TAS HLR

Registration

Successful

Create basic SIP datafrom registration message


DN0628541Issue 8-0-1

23


Feature description

Id:0900d80580a37f33

• Reregistration—Retrieving VoIP subscriber data from HSS and supplementary service data from the HLR


1.4.4.3 Subscriber data storage in LDAP Server and HLR

Initial registration—Retrieving VoIP subscriber data from LDAP and supplemen-tary service data from HLR The Open TAS receives a registration request from the S-CSCF. The REGISTER message contains the registering subscriber’s SIP URI in the To header, optionally the DataRepository parameter in the Route header, and an Expires header containing a value that states how long the registering subscriber would like the registration to remain valid.

Either the DataRepository Application Server SIP URI parameter, configurable in the HSS as iFC criteria, or the PRI_REPO_SOURCE (002:2056) PRFILE parameter, con-figurable in the Open TAS, is set so that the LDAP server and the HLR are used as data respositories.

When the REGISTER request is received, the Open TAS checks the Serving Profile Database (SPD) to ascertain whether or not the subscriber is already registered. Since the subscriber—in this use case—is not registered, the Open TAS determines which repository source to use when retrieving the subscriber’s VoIP data. It does this by first checking for the existence of the DataRepository parameter in the Route header of the REGISTER request. If the parameter is not present, the Open TAS reads the value of the PRI_REPO_SOURCE (002:2056) PRFILE parameter to determine the reposi-tory source for retrieving VoIP subscriber data. In this use case, VoIP subscriber data (SIP Basic Data) is retrieved from the LDAP server.

The Open TAS then sends an LDAP Search Request to the LDAP server to obtain the subscriber’s VoIP data, identified by the user identity submitted in the request. If the LDAP cannot find the subscriber, it returns the LDAP Result with empty results to the Open TAS. The Open TAS then sends a 404 Not Found response. A generic 500 Internal Server Error may also be returned if there is a problem with the server, unrelated to the request. In this use case, however, the LDAP server finds the record and returns the subscriber’s VoIP related data. The Open TAS performs a RestoreData MAP operation on the HLR to download the subscriber's voice and short message service data, that is, the subscriber's MMTEL service data, which it then stores in its internal database.

g The choice of which MAP operation to perform (in this case, to send MAP RestoreData) depends on the VLRDLTYPE parameter of the subscriber’s Group Profile. For more information about the VLRDLTYPE parameter, see section VLR Data Download Type.

If IP-SM-GW functionality is activated for the given user, then the IP-SM-GW role of the Open TAS updates the IP-SM-GW address in the HLR using the MAP AnyTimeModifi-cation operation. For a detailed description, see Feature 2001: IP-SM-GW Support in NVS (Application Server Mode), Feature Description.

24 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Once all necessary data has been retrieved from the HLR, the Open TAS updates the SPD and/or VLR with the subscriber’s data (including repository source information), then returns a 200 OK message to the S-CSCF, signifying that the registration of the subscriber was completed successfully.

At this point, the SCC AS role of the Open TAS may perform SRVCC related procedures toward the HSS over Sh. For more information, see Feature 2045: SCC AS for Session Continuity, Feature Description.

Figure 10 Initial registration—Retrieving VoIP subscriber data from LDAP and sup-plementary service data from HLR

g When the Open TAS retrieves MMTEL data using MAP RestoreData, the subscriber data (that is, the VLR address) is not modified during the procedure.

Re-registration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRThe S-CSCF can re-register a subscriber to renew the registration lifetime or change some parameters. Re-registration means that the subscriber is already registered in the Open TAS.

The Open TAS receives the registration request from the S-CSCF. Upon receipt, the Open TAS first checks whether or not the subscriber identified in the REGISTER message exists in the SPD. Since in this use case the subscriber does exist in the SPD, the HLR is not contacted. The Open TAS, however, may optionally re-download SIP Basic Data from the LDAP server if the ADDITIONAL LDAP QUERY Group Profile parameter is set.

If IP-SM-GW functionality is activated for the given user, then the IP-SM-GW role of the Open TAS may update the IP-SM-GW address in the HLR using the MAP AnyTimeMod-ification operation. For a detailed description, see Feature 2001: IP-SM-GW Support in NVS (Application Server Mode), Feature Description.

Open TASLDAPServer

HLRS-CSCF

REGISTER

VoIP registrationcheck

VoIP repositorycheck

MAP RestoreData Res

Optional IP-SM-GWprocedures toward HLR

200 OK

LDAP Search (SIP URI)

LDAP Result (SIP Basic Data)

MAP RestoreData

Not registered

LDAP+HLR

ISD(MMTEL Services)

Optional SRVCC relatedprocedures toward HSS

DN0628541Issue 8-0-1

25


Feature description

Id:0900d80580a37f33

Once all these procedures are completed, the Open TAS returns a 200 OK message to the S-CSCF, indicating that the re-registra¬tion of the subscriber was successful.

At this point, the SCC AS role of the Open TAS may perform SRVCC related procedures toward the HSS over Sh. For more information, see Feature 2045: SCC AS for Session Continuity, Feature Description.

Figure 11 Re-registration—Retrieving VoIP subscriber data from LDAP and supple-mentary service data from HLR

User-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRThe S-CSCF can deregister a subscriber by sending a SIP REGISTER request and setting the Expires header to 0. The reason for the deregistration toward the Open TAS can be that the UE explicitly deregisters from the IMS, or the S-CSCF administratively deregisters the UE.

A REGISTER message with an Expires header value of 0 is sent to the Open TAS. The Open TAS checks to make sure that the subscriber exists in the SPD, then—assuming the subscriber is found—proceeds to deregister the subscriber.

Based on local settings, the UE is deleted from the internal database (that is, the SPD and the VLR) or the UE can also be kept in the internal database with a “deregistered” IMS registration status. If the user is kept in the database, then the user’s data is only deleted during the next cleaning process.

Deregistration behavior is controlled by the patience time and DELETE ONLY AT CLEANING SIP group profile configuration parameters.

Open TASS-CSCF

REGISTER


Optional SIP Basic Dataretrieval from LDAP server

200 OK

Registered


Optional SRVCCprocedures toward HSS

26 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 12 User-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

Network-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRWhen the registration timer expires, the subscriber is deregistered. Based on the local configuration, the subscriber is either deleted from the VLR and SPD or the subscriber’s registration state is changed.

These deregistered subscribers are then deleted during the next cleaning process. Deregistration behavior is controlled by the patience time and DELETE ONLY AT CLEANING SIP group profile configuration parameters.

Figure 13 Network-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

Subscriber deletion from Open TAS—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRDeleting a subscriber from the Open TAS means deleting the subscriber from the SPD and VLR. Deletion from the SPD and VLR can occur for several reasons—for example:

• The S-CSCF sends deregistration information to the Open TAS, and configuration parameters trigger immediate deletion from the SPD/VLR.

• The operator deletes the subscriber from the SPD or VLR via MML. • The cleaning procedure deletes the subscriber.

During the deletion process, no external message communication occurs.

Open TASS-CSCF

REGISTER(Expires=0)


200 OK


Registered


Depending on configuration:- Delete subscriber from internal database

OR- Set IMS registration status to "deregistered"

Open TAS




Registration timer expires

DN0628541Issue 8-0-1

27


Feature description

Id:0900d80580a37f33

Implicit registration on the originating side—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLROriginating implicit registration occurs when a VoIP subscriber initiates a SIP transac-tion—that is, sends a SIP:INVITE or a SIP:MESSAGE to another subscriber—but the Open TAS handling the request on the originating side is unable to find the subscriber in its Serving Profile Database (SPD). When this occurs, the Open TAS initiates an implicit registration on behalf of the subscriber, so that the SIP transaction can be pro-cessed and the subscriber’s originating services executed.

Possible reasons why the subscriber record is missing from the OpenTAS internal database are as follows:

• A subscriber with a VoLTE terminal, registered in the CS access network only, makes a call which is redirected/homed to the IMS for originating centralized service execution—for more information, see Feature 1990: SCC AS for Service Centraliza-tion and T-ADS, Feature Description. In this use case, the subscriber is restored to the OpenTAS with a “deregistered” IMS state.

• Due to Open TAS failover, upon receiving the INVITE or MESSAGE request, the S-CSCF selects a new Open TAS for serving the subscriber for originating services. In this use case, the subscriber is restored to the OpenTAS with a “registered” IMS state.

Either the DataRepository Application Server SIP URI parameter, configurable in the HSS as iFC criteria for INVITE and MESSAGE requests, or the PRI_REPO_SOURCE (002:2056) PRFILE parameter, configurable in the Open TAS, indicates that the LDAP server and the HLR are to be used as data repositories. The VLRDLTYPE param-eter of the subscriber’s Group Profile indicates that MAP RestoreData operation is to be used toward the HLR.

g To enable originating implicit registration, the SIP_IMPLICIT_REG_SUPP (003:1363) FIFILE parameter must be set to ON, and the SIP_ALLOWED_IMPREG_TYPE (052:0070) PRFILE parameter must be set to 1 or 3.

28 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 14 Implicit registration on the originating side—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

Implicit registration on the terminating side—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRTerminating implicit registration occurs when the terminating VoIP subscriber receives a SIP transaction—that is, receives a SIP:INVITE or a SIP:MESSAGE from another sub-scriber—but the Open TAS handling the request for terminating service execution is unable to find the subscriber in its Serving Profile Database (SPD). When this occurs, the Open TAS initiates an implicit registration on behalf of the subscriber, so that the SIP transaction can be processed and the subscriber’s terminating services executed.

Possible reasons why the subscriber record is missing from the Open TAS internal database are as follows:

• A subscriber with a VoLTE terminal, registered in the CS access network only, is called and the call is re-routed/homed to the IMS for terminating centralized service execution—for more information, see Feature 1990: SCC AS for Service Centraliza-tion and T-ADS, Feature Description. In this use case, the subscriber is restored to the Open TAS with a “deregistered” IMS state.

• Due to Open TAS failover, upon receiving the INVITE or MESSAGE request, the S-CSCF selects a new Open TAS for serving the subscriber for terminating services.

Open TASLDAPServer

HLRS-CSCF

INVITE/MESSAGE

Retrieval of subscriber datafrom internal database fails:

UE not registered


MAP RestoreData Res


INVITE/MESSAGE

LDAP Search(SIP URI)

LDAP Result(SIP Basic Data)

MAP RestoreData

LDAP+HLR

ISD(MMTEL Services)


Originating implicitregistration is initiated

Originating implicitregistration is finished

Continue originatingservice execution

DN0628541Issue 8-0-1

29


Feature description

Id:0900d80580a37f33

In this use case, the subscriber is restored to the Open TAS with a “registered” IMS state.

The registration status is controlled by the ServiceInfo iFC parameter.

Either the DataRepository Application Server SIP URI parameter, configurable in the HSS as iFC criteria for INVITE and MESSAGE requests, or the PRI_REPO_SOURCE (002:2056) PRFILE parameter, configurable in the Open TAS, indicates that the LDAP server and the HLR are to be used as data repositories. The VLRDLTYPE param-eter of the subscriber’s Group Profile indicates that MAP RestoreData operation is to be used toward the HLR. For more information about the VLRDLTYPE parameter, see VLR Data Download Type.

g To enable terminating implicit registration, the SIP_IMPLICIT_REG_SUPP (003:1363) FIFILE parameter must be set to ON, and the SIP_ALLOWED_IMPREG_TYPE (052:0070) PRFILE parameter must be set to 2 or 3.

30 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 15 Terminating implicit registration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

1.4.5 Registration in MMTel AS/IM-SSF

1.4.5.1 Subscriber data storage in HSSFor detailed descriptions of the various registration use cases when all subscriber data is stored in the HSS, see the following sections in Feature 2027: Sh for NVS Subscriber Repository, Feature Description:

• Initial registration—Retrieving VoIP subscriber data and supplementary service data from HSS

• Reregistration—Retrieving VoIP subscriber data and supplementary service data from HSS

• User-initiated deregistration

Open TASLDAPServer

HLRS-CSCF

INVITE/MESSAGE


UE not registered


MAP RestoreData Res


INVITE/MESSAGE



MAP RestoreData

LDAP+HLR

ISD(MMTEL Services)


Terminating implicitregistration is initiated

Terminating implicitregistration is finished

Continue terminatingservice execution

MAP SendRoutingInfo

MAP SendRoutingInfo Res (IMSI, T-CSI)

DN0628541Issue 8-0-1

31


Feature description

Id:0900d80580a37f33

• Network-initiated deregistration • Implicit registration on the originating side • Implicit registration on the terminating side

1.4.5.2 Subscriber data storage in HSS and HLRFor detailed descriptions of the various registration use cases when basic SIP sub-scriber data is stored in the HSS and MMTEL supplementary service data is stored in the HLR, see the following sections in Feature 2027: Sh for NVS Subscriber Repository, Feature Description:

• Initial registration—Retrieving VoIP subscriber data from HSS and supplementary service data from HLR

• Reregistration—Retrieving VoIP subscriber data from HSS and supplementary service data from the HLR


1.4.5.3 Subscriber data storage in LDAP Server and HLR

Initial registration—Retrieving VoIP subscriber data from LDAP and supplemen-tary service data from HLRThe Open TAS receives the registration request from the S-CSCF. The REGISTER message contains the registering subscriber’s SIP URI in the To header, optionally the DataRepository parameter in the Route header, and an Expires header containing a value that states how long the registering subscriber would like the registration to remain valid.

Either the DataRepository Application Server SIP URI parameter, configurable in the HSS as iFC criteria, or the PRI_REPO_SOURCE (002:2056) PRFILE parameter, con-figurable in the Open TAS, is set to indicate that the LDAP server and the HLR are to be used as data respositories.

When the REGISTER request is received, the Open TAS checks the Serving Profile Database (SPD) to ascertain whether or not the subscriber is already registered. Since the subscriber—in this use case—is not registered, the Open TAS determines which repository source to use when retrieving the subscriber’s VoIP data. It does this by first checking for the existence of the DataRepository parameter in the Route header of the REGISTER request. If the parameter is not present, the Open TAS reads the value of the PRI_REPO_SOURCE (002:2056) PRFILE parameter to determine the reposi-tory source for retrieving VoIP subscriber data. In this use case, VoIP subscriber data (SIP Basic Data) is retrieved from the LDAP server.

The Open TAS then sends an LDAP Search Request to the LDAP server to obtain the subscriber’s VoIP data, identified by the user identity submitted in the request. If the LDAP cannot find the subscriber, it returns the LDAP Result with empty results to the Open TAS. The Open TAS then sends a 404 Not Found response. A generic 500 Internal Server Error may also be returned if there is a problem with the server, unrelated to the request. In this use case, however, the LDAP server finds the record and returns the subscriber’s VoIP related data.

32 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

The Open TAS performs an Update Location MAP operation on the HLR to download the subscriber's voice and short message service data—that is, the subscriber's MMTEL service data, which it then stores in its internal database. At this point, the HLR updates the VLR address to the address of the Open TAS.

g The choice of which MAP operation to perform (in this case, MAP Update Location) depends on the VLRDLTYPE parameter of the subscriber’s Group Profile. For more information about the VLRDLTYPE parameter, see section VLR Data Download Type.

Once all necessary data has been retrieved from the HLR, the Open TAS updates the SPD and/or VLR with the subscriber’s data (including repository source information), then returns a 200 OK message to the S-CSCF, signifying that the registration of the subscriber was completed successfully.

Figure 16 Initial registration—Retrieving VoIP subscriber data from LDAP and sup-plementary service data from HLR

g The Open TAS retrieves MMTEL data using the MAP Update Location operation, which means that the subscriber record in the HLR (which can be a foreign HLR) is exclusively used by the Open TAS (that is, not used for 2G/3G subscription) since during the Update Location procedure, the HLR sets the VLR address to the address of the Open TAS.

Re-registration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRThe S-CSCF can re-register a subscriber to renew the registration lifetime or change some parameters. Re-registration means that the subscriber is already registered in the Open TAS.

The Open TAS receives the registration request from the S-CSCF. Upon receipt, the Open TAS first checks whether or not the subscriber identified in the REGISTER message exists in the SPD. Since in this use case the subscriber does exist in the SPD, the HLR is not contacted. The Open TAS, however, may optionally re-download SIP

Open TASLDAPServer

HLRS-CSCF

REGISTER



VLR download type:Update Location

200 OK

Not registered

LDAP+HLR

MAP Update Location Res



MAP Update Location

ISD(MMTEL Services)

DN0628541Issue 8-0-1

33


Feature description

Id:0900d80580a37f33

Basic Data from the LDAP server if the ADDITIONAL LDAP QUERY Group Profile parameter is set.

Once all these procedure are completed, the Open TAS returns a 200 OK message to the S-CSCF, indicating that the re-registration of the subscriber was successful.

Figure 17 Re-registration—Retrieving VoIP subscriber data from LDAP and supple-mentary service data from HLR

User-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRThe S-CSCF can deregister a subscriber by sending a SIP:REGISTER request and setting the Expires header to zero. The reason for the deregistration toward the Open TAS can be that the UE explicitly deregisters from the IMS, or the S-CSCF administra-tively deregisters the UE.

When the deregistration request is received, the Open TAS checks to make sure that the subscriber exists in the SPD, then—assuming the subscriber is found—proceeds to deregister the subscriber.

Based on local settings, the UE is deleted from the internal database (that is, the SPD and the VLR), or the UE can also be kept in the internal database with a “deregistered” IMS registration status. If the user is kept in the database, then the user’s data is only deleted during the next cleaning process.

Deregistration behavior is controlled by the patience time and DELETE ONLY AT CLEANING SIP group profile configuration parameters.

When the user is deleted from the internal database, then MAP Purge MS is sent to the HLR, indicating that the UE is not available any more in this particular Open TAS.

Open TASS-CSCF

REGISTER


Optional SIP Basic Dataretrieval from LDAP server

200 OK

Registered

34 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 18 User-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

Network-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRThere are two network-initiated deregistration cases related to this feature:

• Deregistration, network-initiated, registration timeout

When the registration timer expires, the subscriber is deregistered. Based on the local configuration, the subscriber is either deleted from the VLR and SPD, or the subscriber’s registration state is changed.

The deregistered subscriber is then deleted during the next cleaning process. Deregistration behavior is controlled by the patience time and DELETE ONLY AT CLEANING SIP group profile configuration parameters.

Figure 19 Network-initiated deregistration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

Open TASS-CSCF

REGISTER(Expires=0)


200 OK


Registered




HLR

MAP Purge MS

MAP Purge MS Res

If user is deletedfrom internaldatabase

Open TAS




Registration timer expires

HLR

MAP Purge MS

MAP Purge MS Res

If user is deletedfrom internaldatabase

DN0628541Issue 8-0-1

35


Feature description

Id:0900d80580a37f33

• Deregistration, network-initiated, the HLR initiates subscriber deregistration

When a subscriber is deactivated in the HLR, the HLR sends a CancelLocation MAP message to the VLR to delete the subscriber’s record in its database. In such a case, the user is also deleted from the SPD.

Subscriber deletion from Open TAS—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRDeleting a subscriber from the Open TAS means deleting the subscriber from the SPD and the VLR. Deletion from the SPD and VLR can occur for several reasons—for example:

• The S-CSCF sends deregistration informatiob to the Open TAS and configuration parameters trigger immediate deletion from the SPD/VLR.

• The operator deletes the subscriber from the SPD or VLR via MML. • The cleaning procedure deletes the subscriber.

During the deletion process, the Open TAS sends a MAP Purge MS to the HLR.

Implicit registration on the originating side—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLROriginating implicit registration occurs when a VoIP subscriber initiates a SIP transac-tion—that is, sends a SIP:INVITE or a SIP:MESSAGE to another subscriber—but the Open TAS handling the request on the originating side is unable to find the subscriber in its Serving Profile Database (SPD). When this occurs, the Open TAS initiates an implicit registration on behalf of the subscriber, so that the SIP transaction can be pro-cessed and the subscriber’s originating services executed.


• Due to Open TAS failover, upon receiving the INVITE or MESSAGE request, the S-CSCF selects a new Open TAS for serving the subscriber for originating services. In this use case, the subscriber is restored to the Open TAS with the “registered” IMS state.

Either the DataRepository Application Server SIP URI parameter, configurable in the HSS as iFC criteria for INVITE and MESSAGE requests, or the PRI_REPO_SOURCE (002:2056) PRFILE parameter, configurable in the Open TAS, indicates that the LDAP server and the HLR are to be used as data repositories. The VLRDLTYPE param-eter of the subscriber’s Group Profile indicates that MAP UpdateLocation operation is to be used toward the HLR. For more information about the VLRDLTYPE parameter, see section VLR Data Download Type.

g To enable originating implicit registration, the SIP_IMPLICIT_REG_SUPP (003:1363) FIFILE parameter must be set to ON, and the SIP_ALLOWED_IMPREG_TYPE (052:0070) PRFILE parameter must be set to 1 or 3.

36 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 20 Implicit registration on the originating side—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

Implicit registration on the terminating side—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLRTerminating implicit registration occurs when the terminating VoIP subscriber receives a SIP transaction—that is, receives a SIP:INVITE or a SIP:MESSAGE from another sub-scriber—but the subscriber is not registered in the Serving Profile Database (SPD). On receiving a MAP Provide Roaming Number, the subscriber check in the VLR fails, which triggers the Open TAS to initiate an implicit registration on behalf of the subscriber, so that the MAP Provide Roaming Number can be processed and the subscriber’s termi-nating services executed.


• Due to Open TAS failover, upon receiving the INVITE or MESSAGE request, the S-CSCF selects a new Open TAS for serving the subscriber for terminating services. In this use case, the subscriber is restored to the Open TAS with a “registered” IMS state.

Either the DataRepository Application Server SIP URI parameter, configurable in the HSS as iFC criteria for INVITE and MESSAGE requests, or the PRI_REPO_SOURCE

Open TASLDAPServer

HLRS-CSCF

INVITE/MESSAGE


UE not registered



INVITE/MESSAGE



MAP Update Location

LDAP+HLR

ISD(MMTEL Services)

Originating implicitregistration is initiated

Originating implicitregistration is finished

Continue originatingservice execution

VLR download type:Update Location

DN0628541Issue 8-0-1

37


Feature description

Id:0900d80580a37f33

(002:2056) PRFILE parameter, configurable in the Open TAS, indicates that the LDAP server and HLR are to be used as data repositories. The VLRDLTYPE parameter of the subscriber’s Group Profile indicates that MAP UpdateLocation operation is to be used toward the HLR. For more information about the VLRDLTYPE parameter, see section VLR Data Download Type.

g To enable terminating implicit registration, the SIP_IMPLICIT_REG_SUPP (003:1363) FIFILE parameter should be set to ON, and the SIP_ALLOWED_IMPREG_TYPE (052:0070) PRFILE parameter should be set to 2 or 3.

Figure 21 Implicit registration on the terminating side—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR

g In this case, the user is searched with the IMSI in the LDAP server, which requires that the subscriber data be indexed with the IMSI in the LDAP server.

Open TASLDAPServer

HLRS-CSCF

INVITE/MESSAGE

Allocation of MSRB fails:UE not registered



Allocate MSRN

INVITE/MESSAGE



MAP Update Location

LDAP+HLR

ISD(MMTEL Services)

Terminating implicitregistration is initiated

Terminating implicitregistration is finished

Continue terminatingservice execution

MAP SendRoutingInfo

MAP SendRoutingInfo Res (IMSI, T-CSI)

MAP Provide Roaming Number

MAP Provide Roaming Number Res

38 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

1.4.5.4 Subscriber data storage in HLR onlyThis functionality aims to support operators who, as well as continuing to provide support for their home VoIP subscribers, wish to:

• support roaming VoIP subscribers from other operator networks (and so increase traffic and, hence, revenue)

• use the Open TAS without investing in an LDAP and HSS (Sh) solution

As such, the Open TAS supports VoIP subscribers both with and without SIP subscrip-tion data in the SDB LDAP directory. It provides this support through the activation of the license NVS without LDAP and the setting of the PRFILE parameter SIP_USE_LDAP_IF_LDAPLES (052:0095). If the PRFILE is set to TRUE and the NVS without LDAP license is activated, the Open TAS can support both types of sub-scribers—that is, those with and those without SIP data in the SDB. If the PRFILE parameter is set to FALSE, then both types of subscribers are treated as though neither have SIP subscriber data in the SDB.

g If this PRFILE parameter is not available in your configuration, the Open TAS assigns all subscribers the default SIP group profile ID of 0.

g Instructions on activating the NVS without LDAP license are given in the feature activa-tion manual of Feature 1673: NVS Registration (Application Server Mode).

Both types of subscriber registration are described below:

RegistrationDuring registration, the Open TAS first checks to see whether or not the NVS without LDAP license is activated in the network element that runs the Open TAS. If it is not, registration proceeds as per normal for a VoIP subscriber—that is, the Open TAS queries the SDB LDAP directory for the subscriber's IMSI using the SIP-URI value in the registration message, downloads the SIP subscriber’s data, and updates the sub-scriber's location in the VLR and HLR.

For more information about registration when this license is not activated, see section Initial registration—Retrieving VoIP subscriber data from LDAP and supplementary service data from HLR.

If, on the other hand, the license is activated, the Open TAS parses the IMSI from the P-com.Siemens.IMSI-ID header. If the Open TAS cannot find the IMSI in this header, it checks the user part of the subscriber's SIP URI (see section Open TAS without LDAP connection restrictions concerning the format of the SIP-URI), wrapped in the To header. If the Open TAS still cannot find the IMSI of the subscriber, it checks the SIP_USE_LDAP_IF_LDAPLES (052:0095) PRFILE parameter to see if it can obtain the information from the SDB LDAP directory. If this PRFILE parameter is set to FALSE, the Open TAS sends a 403 Forbidden error message to the S-CSCF to indicate that the subscriber's registration was unsuccessful.

DN0628541Issue 8-0-1

39


Feature description

Id:0900d80580a37f33

Figure 22 Unsuccessful registration - IMSI not found

If, however, the PRFILE parameter is set to TRUE, the Open TAS queries the SDB LDAP directory for the subscriber's SIP data—that is, for the subscriber's IMSI, SIP group profile ID and other relevant SIP data—and executes the registration process for the VoIP subscriber as though the NVS without LDAP license was not activated.

REGISTER

S-CSCF Open TAS

NVS without LDAPlicense activated?

Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE

parameterset to ?TRUE

No

Derive IMSI fromoT

header

Unsuccessful

403 Forbidden

Derive IMSI fromP-com.Siemens.IMSI-ID

header

Unsuccessful

40 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 23 Successful registration - LDAP query still possible despite NVS without LDAP license activation

g For more information about registration and authentication using the LDAP interface, see section Initial registration—Retrieving VoIP subscriber data from LDAP and supple-mentary service data from HLR.

If the subscriber's IMSI is successfully parsed from the P-com.Siemens.IMSI-ID, or the To header, the Open TAS queries the SPD for the subscriber’s SIP group profile ID and authentication profile ID using the IMSI as a key. If the subscriber’s record is not found in the SPD, the Open TAS checks the settings of the SIP_USE_LDAP_IF_LDAPLES (052:0095) PRFILE parameter. If the PRFILE parameter is set to TRUE, the Open TAS queries the SDB LDAP directory for the subscriber's SIP data using either the SIP URI or the IMSI as the key and executes the registration process for the VoIP subscriber as though the NVS without LDAP license was not activated. If, however, the PRFILE parameter is set to FALSE, the Open TAS initiates a location update and assigns the default SIP group profile ID 0 to the subscriber. This profile provides a limited set of services for the subscriber.

REGISTER

S-CSCF Open TAS HLR


Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


Yes

Derive IMSI fromoT

header

Un uccessfuls

SDB/LDAP

LDAP search(SIP-URI)

LDAP result(SIP data)

200 OK(PAU)

Location pdate(IMSI)U

LocationUpdateAck

Update SPD withCS and SM service

info


headerUnsuccessful

DN0628541Issue 8-0-1

41


Feature description

Id:0900d80580a37f33

g To provide a more flexible SIP group profile for subscribers, you can instruct the Open TAS network element to use the value of each subscriber's routing category (stored in their HLR record) as a SIP group profile ID instead of using the default setting 0. You can do this by setting the USE_RC_AS_PROFILE (052:0090) PRFILE parameter—see the USE_RC_AS_PROFILE parameter description in section Open TAS specific parameters for more information. However, if you choose to do this, you must make sure that a SIP group profile with this ID already exists in the Open TAS.

The location update returns the MSISDN of the subscriber. This is used by the Open TAS to route calls and text messages to the subscriber.

At the end of each successful registration process, the Open TAS returns a 200 OK message, together with the subscriber's SIP URI, wrapped in the message's P-Associ-ated-Uri header.

Figure 24 Successful registration in the absence of LDAP

REGISTER

200 OK(PAU)

Location pdate(IMSI)U

LocationUpdateAck

S-CSCF Open TAS HLR

includes MSISDNand routing

category


Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


No

Update SPD withCS and SM service

info

Derive IMSI fromoT

header

Successful


headerUnsuccessful

42 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

1.4.5.5 Simultaneous registration in Open TAS and MSS network elements through a single IMSIIn the current release one MSS network element may also work as an Open TAS. This means that VoLTE terminals can be simultaneously registered from CS and PS networks in the same network element.

g This solution will not be available in upcoming releases.

In order to allow the same VLR record to be used for CS and PS access, the HLR should be used as the MMTEL repository source and the VLRDLTYPE parameter in the sub-scriber's SIP group profile should be set to “Restore Data” or “T-CSI”.

The aim of this feature is to control how the subscriber's record, located in both the HLR and VLR, is updated. This is achieved in two parts: firstly, through the appropriate setting of the User in SPD flag in the subscriber’s VLR record; and secondly, by configuring the VLRDLTYPE parameter in the subscriber's SIP group profile.

These two parts will now be described.

User in SPDThe User in SPD flag, together with the Radio Access Information (RAI) field—which provides the radio access type used by the subscriber (for example, gsm, umts, sip or lte)—is used to determine the registration status of the subscriber. See table Subscriber registration status in VLR.

The User in SPD flag is set to (T)RUE if the subscriber’s data is found in the Serving Profile Database (SPD) and set to (F)ALSE if it is not.

g When a subscriber registers in the PS (VoIP) access network, the Open TAS downloads his/her subscription data from the SIP Subscriber Database (SDB) LDAP directory to the SPD. For more information, see section Serving Profile Database (SPD).

As can be seen, if the User in SPD flag is set to (T)RUE and the subscriber’s radio access type is SIP, the subscriber's registration status is SIP only. If the User in SPD flag, however, is set to (F)ALSE and the radio access type of the subscriber is something other than SIP, the subscriber's registration status is CS only. On the other hand, if the User in SPD flag is set to (T)RUE and the radio access type is not SIP, the subscriber's registration status is SIP and CS.

This parameter is set/updated during the following processes:

• CS and SIP location updatesCS registration through a CS location update: If the subscriber’s IMSI is not listed in the VLR, the User in SPD flag is set to (F)ALSE. If the IMSI is listed in the VLR and

User in SPD Radio Access Information Registration status

T SIP SIP only

F GSM/UMTS CS only

T LTE SIP and CS

Table 1 Subscriber registration status in VLR

DN0628541Issue 8-0-1

43


Feature description

Id:0900d80580a37f33

the registration status of the subscriber is CS only, the User in SPD flag remains unchanged—that is, the User in SPD flag remains set to (F)ALSE.

SIP and CS [combined] registration through a CS location update: If the subscriber's IMSI is already listed in the VLR before the location update for the combined regis-tration takes place, the User in SPD flag remains unchanged—that is, the User in SPD flag remains set to (T)RUE.

SIP registration/re-registration through a SIP location update: If the subscriber is not listed in the VLR before the location update, the User in SPD flag is set to (T)RUE. If the subscriber is listed in the VLR, the subscriber’s data is not updated, only the User in SPD flag is set to (T)RUE.

• CancelLocationIf the subscriber is registered in either CS access or SIP access (but not both at the same time), the subscriber's record is deleted from the VLR as per usual, or placed in passive state if the Supercharger feature is active (for deletion during the next cleanup process). If, on the other hand, the subscriber is registered in both CS and PS (SIP) access networks at the same time, the subscriber's data is not removed from the VLR. Instead, the User in SPD flag is set to (T)RUE.

• SPD initiated subscriber deletionIf the subscriber's Radio Access Information is not SIP, the subscriber is not deleted from the VLR. Instead, the subscriber's User in SPD flag is set to (F)ALSE.

VLR Data Download TypeThe VLRDLTYPE parameter determines the appropriate MAP operation to perform on the HLR during the registration procedure and is configured in the subscriber’s SIP group profile using the JHA MML command.

The parameter takes three possible values:

UL meaning perform an UpdateLocation MAP operation on the HLR to update the subscriber's record with the address of the visited Open TAS/VLR and update the VLR with the subscriber’s data, downloaded from the HLR.

RD meaning perform a RestoreData MAP operation on the HLR to download the subscriber's voice and short message service data—that is, the subscriber's CS service data—to the SPD and/or VLR.

TCSI meaning analyze the Terminating CAMEL Subscription Information (TCSI) of the subscriber, provisioned in the HLR, to determine the appropriate MAP operation to perform on the HLR: UpdateLocation or RestoreData.

If the VLRDLTYPE parameter is set to TCSI, an AnyTimeSubscriptionIn-terrogation (ATSI) MAP operation is used to retrieve the subscriber’s T-CSI from the HLR. The Open TAS then performs a service attribute analysis on the subscriber’s T-CSI information to determine the appro-priate MAP operation to perform.

For more information on configuring this parameter, see section JHA - ADD SIP GROUP PROFILE in the SIP Address Configuration Handling (JH Command Group) command reference manual.

When configuring VLRDLTYPE, Nokia Siemens Networks recommends the following values for the following types of VoIP subscriber:

44 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

1.4.6 Subscriber data modification notifications and georedundancy for Open TAS based VoLTEA VoLTE subscriber’s supplementary service data when stored in the HLR can be modified using several methods in different access domains:

CS domain • by entering commands in the Man Machine Interface (MMI) of the subscriber’s user

equipment (UE) • by entering facility codes, like **21*+491774190099#

PS domain • by submitting XCAP HTTP PUT and DELETE requests over the Ut interface, which

are then routed to the HLR over the MAP interface • by entering facility codes, like *31#12345567

For more information, see Feature 1741: Control of Supplementary Services in NVS, Feature Description.

g Facility codes can be used to manage services in HLR-based deployments only.

A VoLTE subscriber’s supplementary service data when stored in the HSS can be mod-ified:

• by submitting XCAP HTTP PUT and DELETE requests over the Ut interface, which are then routed to the HSS over the Sh interface

The Ut/XCAP approach is license based and configurable using the XCAP_PRI_REPO_SOURCE (002:2092) PRFILE parameter. For more information, see Feature 1979: Ut/XCAP Interface Support in NVS, Feature Description.

The Open TAS responsible for the VoLTE subscriber's service execution in the network needs to be kept up-to-date with any changes to the subscriber's supplementary service data, so that it can handle calls and sessions for the subscriber in the same manner irre-spective of the subscriber's current access domain.

To this end, the HLR can be configured to send MAP NoteSubscriberDataModified (NSDM) messages to the Open TAS where the VoLTE subscriber is registered whenever a change to the subscriber's supplementary service data takes place. The NSDM is thus used to keep the subscriber's VLR record in the Open TAS up-to-date.

The challenge occurs when there is more than one Open TAS deployed in the network: the HLR does not know under which Open TAS the subscriber is registered. As such, it does not know which specific Open TAS to send the NSDM to. For the HLR to know this, the address of every Open TAS would need to be configured and stored in the HLR. However, to minimize the number of addresses that the HLR would need to store, Nokia

Open TAS subscribers with LTE terminals capable of being registered in circuit switched and packet switched networks at the same time. RD

Open TAS subscribers with terminals incapable of being registered in CS and PS-based networks at the same time UL

Visiting VoIP subscribers from other operator networks without access to LDAP TCSI

DN0628541Issue 8-0-1

45


Feature description

Id:0900d80580a37f33

Siemens Networks has devised a Homing SCC AS* solution. This Homing SCC AS is used to select an appropriate Open TAS to route the NSDM to.

* The Homing SCC AS is an Open TAS that acts as a Service Centralization & Continuity Application Server (SCC AS). Such an Open TAS is responsible for the rerouting of ter-minating calls to subscribers with LTE terminals from a CS network to an IMS network for service execution. The Homing SCC AS is also responsible for rerouting the NSDM to the Open TAS where the subscriber is registered.

With this solution, VoLTE subscribers’ HLR records are preconfigured with a virtual Homing SCC AS address. This virtual address is contained in the SCP address field—a field that usually points toward a Service Control Point (SCP) for the execution of intel-ligent network (IN) services on behalf of the subscriber, but in this case is used to point to an available Homing SCC AS.

Before the HLR sends the NSDM, it first performs a signaling connection control part (SCCP) layer Global Title (GT) analysis on the virtual Homing SCC AS address (the SCP address). The aim of this analysis is to select an available Homing SCC AS to send the NSDM to so that the NSDM can then be routed to its correct destination.

g The GT analysis result created for the virtual Homing SCC AS must include the destina-tion point code of every Homing SCC AS in the network, since it is possible for the operator to deploy more than one Homing SCC AS. SCCP level load sharing must also be applied across all destination point codes. The analysis uses a round robin approach to select an available Homing SCC AS. If one particular Homing SCC AS goes down, its destination point code becomes unavailable. While unavailable, that particular Homing SCC AS cannot be selected for NSDM delivery.

For more information on the configuration of the GT analysis, see section Activating noti-fications for subscriber data modification and georedundancy for Open TAS based VoLTE in Feature 1673: NVS Registration, Feature Activation Manual.

The HLR then sends the NSDM MAP message to the selected Homing SCC AS address. Upon receipt of the MAP message, the Homing SCC AS's VLR application first checks whether the subscriber is present within its repository. Depending on the result of this check, one of the following scenarios is executed:

• VoLTE subscriber is present in the Homing SCC AS’s VLR

• VoLTE subscriber is not present in the Homing SCC AS’s VLR

Both of these scenarios will now be described in the subsections that follow.

VoLTE subscriber is present in the Homing SCC AS’s VLRIf the Homing SCC AS's VLR application finds the subscriber in its repository, it checks the registration status of the subscriber. If the subscriber’s registration status is set to SIP only (see table Subscriber registration status in VLR), the subscriber's VLR record is updated based on the content of the NSDM. If it is set to a different value, for example, CS only or SIP and CS, no update to the subscriber's VLR record, based on the NSDM, takes place. Instead, the HLR updates the VLR record in accordance with the usual update procedure used in CS networks—that is, through MAP InsertSubscriberData.

46 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 25 VLR update for a SIP registered subscriber on receipt of a NoteSubscrib-erDataModified MAP message

g In this example, the Homing SCC AS is also the Open TAS where the subscriber is reg-istered.

VoLTE subscriber is not present in the Homing SCC AS’s VLRIf the Homing SCC AS’s VLR application cannot find the subscriber’s IMSI in its repos-itory, the subscriber is either not registered in the network or registered in a different Open TAS. To determine what to do next, the Homing SCC AS checks the value (0, 1 or 2) of the NSDM_RELAY_MODE (052:0114) PRFILE parameter.

NSDM_RELAY_MODE (052:0114) value is 0

If the parameter’s value is set to its default value (0), the VLR of the Homing SCC AS simply acknowledges the receipt of the NSDM MAP message, and no further action takes place.


If the parameter’s value is set to 1, the IP-SM-GW based solution is used. The Homing SCC AS uses the IP-SM-GW specific SRIforSM relay function to discover where the subscriber is registered. For more information, see section IP-SM-GW homing in Feature 2001: IP-SM-GW Support in NVS (Application Server Mode).

The SMS application in the MSS on which the Open TAS is running begins to simulate the role of an SMS-GMSC so that the Homing SCC AS can send the SRIforSM MAP message. The MAP message contains the following information:

HLR Homing SCC AS

MAP NoteSubscriberDataModified

Accessregistration

check

Registration status =SIP only

MAP NoteSubscriberDataModifiedRes

NSDM:

IMSIMSISDNModified data

CdPa GT = virtual Homing SCgPa GT = HLR

SCC A

Update VLR

VLR checkIMSI found in VLR

VLR record:

imsi = IMSImsisdn= MSISDNmodified subscriber data...

MAP SRIforSM contents Value

Called party (CdPa) GT address

Set to the value of the MSISDN delivered in the NSDM message

Calling party (CgPa) GT address

Set to the value of the MSC address of the Homing SCC AS

msisdn Set to the value of the MSISDN delivered in the NSDM

Table 2 Content of the SRIforSM sent from the Homing SCC AS to the HLR

DN0628541Issue 8-0-1

47


Feature description

Id:0900d80580a37f33

Since the MAP SRIforSM message is not sent from an IP-SM-GW, the HLR reads the registered IP-SM-GW address in the subscriber’s HLR record and changes the value of the CdPa GT address from the CdPa’s MSISDN to the subscriber’s IP-SM-GW address. Once this is done, the HLR relays the modified MAP SRIforSM to the IP-SM-GW address (now set as the CdPa GT address).

g The Open TAS in which the VoLTE subscriber is registered and the subscriber’s IP-SM-GW must be located in the same network element. For more information, see note entitled Prerequisites for using the IP-SM-GW specific SRIforSM relay function.

Once the IP-SM-GW receives the SRIforSM, it starts mobile terminating short message (MT-SM) homing logic. Since the SMSC address received in the NSDM message equals SMSC address for VoLTE NSDM (as read from the HRNFIL record of the Homing SCC AS), the IP-SM-GW executes homing logic specific to the MAP NoteSub-scriberDataModified message. This involves the assignment of a fake correlation ID and the copying of the MSC address running the IP-SM-GW to the Network Node Number (NNN). This information is then returned to the Homing SCC AS as routing information in the SRIforSMRes response to the original MAP SRIforSM message.

On receipt of the response from the IP-SM-GW, the Homing SCC AS sets the sub-scriber’s Open TAS address to the value contained in the NNN parameter of the SRIforSM response. The VLR application in the Homing SCC AS then determines whether the subscriber is located in a different Open TAS or is simply not registered by comparing the subscriber’s Open TAS address with its [the Homing SCC AS’] own MSC address.

If the addresses match, that is, if the Homing SCC AS and the subscriber’s Open TAS address are the same, but the subscriber is not listed in the VLR, no update to the VLR takes place. If this is the case, the VLR of the Homing SCC AS simply acknowledges the NSDM MAP message. When the subscriber next registers in the SIP access network, his/her VLR data is updated automatically by the MAP RestoreData operation. See figure Subscriber previously registered in Homing SCC AS has become unregis-tered.

SMSC address Set to the value of SMSC for VoLTE NSDM as read from HRNFIL

SM-RI-PRI Set to True, meaning force the SRIforSM to be sent to the IP-SM-GW

MAP SRIforSM contents Value

Table 2 Content of the SRIforSM sent from the Homing SCC AS to the HLR (Cont.)

48 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 26 Subscriber previously registered in Homing SCC AS has become unregis-tered

If the Open TAS address for the subscriber is different from the Homing SCC AS address, the subscriber is served by a different Open TAS. If this is the case, the VLR forwards the NSDM MAP message to the subscriber’s Open TAS address. Once the Open TAS (MMTel AS/IP-SM-GW) receives the NSDM MAP message, its VLR applica-tion checks the subscriber’s registration status. If the subscriber is registered as SIP only, the subscriber’s VLR record is updated with the new supplementary service data, passed in the NSDM. See figure VLR update in Open TAS (MMTel AS/IP-SM-GW).

Homing SCC AS/ VLR


HLR

VLR checkIMSI not found in VLR

MAP SRIforSM(MSISDN)

IP-SM-GW addresscheck


Execute IP-SM-GWhoming logic

MAP SRIforSMRes(Routinginfo)


NSDM_RELAY_MODE(052:0114) = 1

successful

PRFILEcheck

SimulateSMSC-GMSC

SRIforSM:

CdPa GT=MSISDNCgPa GT=msisdn=MSISDNSMSC address = SMSC for VoLTE NSDMSM-RP-PRI = T

MSC address of Homing SSCC A

SRIforSM:

CdPa GT=IP-SM-GWCgPa GT=msisdn=MSISDNSMSC address = SMSC for VoLTE NSDM


SRIforSMRes:

imsi=fake correlation IDNNN=MSC address of S (TAS/IP-SM-GW)ANNN=N/A

TA

Compare Homing Saddress with NNN

SCC A addresses match

NSDM:



SCC A

IP-SM-GW/ VLR

DN0628541Issue 8-0-1

49


Feature description

Id:0900d80580a37f33

Figure 27 VLR update in Open TAS (MMTel AS/IP-SM-GW)

If the subscriber’s registration status is something other than SIP only, or the subscriber is not listed in the Open TAS (MMTel AS/IP-SM-GW) / VLR, the VLR acknowledges the NSDM sent from the Homing SCC AS. Once the Homing SCC AS receives the acknowl-edgement from the Open TAS (MMTel AS/IP-SM-GW), the Homing SCC AS acknowl-edges the original NSDM, sent from the HLR. See figure Subscriber registered in Open TAS (MMTel AS/IP-SM-GW) as SIP and CS.

Homing SCC AS/ VLR

IP-SM-GW/ VLR


HLR



IP-SM-GW addresscheck


Execute IP-SM-GWhoming logic

MAP SRIforSMRes(Routinginfo)




NSDM_RELAY_MODE(052:0114) = 1

successful

PRFILEcheck

SimulateSMSC-GMSC

NSDM:



SCC A

SRIforSM:

CdPa GT=MSISDNCgPa GT= MSC address of Homing Smsisdn=MSISDNSMSC address = SMSC for VoLTE NSDMSM-RP-PRI = T

SCC A

SRIforSM:

CdPa GT=IP-SM-GWCgPa GT=msisdn=MSISDNSMSC address = SMSC for VoLTE NSDM


NSDM:

CdPa GT = MSC address o S (TAS/IP-SM-GW)CgPa GT =msisdn=MSISDNimsi=IMSIModified subscriber data

f TASCC AMSC address of Homing S

SRIforSMRes:

imsi=fake correlation IDNNN=ANNN=N/A

MSC address of S (TAS/IP-SM-GW)TA

VLR check

IMSI found in VLRRegistration status =

SIP only

Update VLR

Compare Homing Saddress with NNN

SCC A addresses don't match

50 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 28 Subscriber registered in Open TAS (MMTel AS/IP-SM-GW) as SIP and CS

g Prerequisites for using the IP-SM-GW specific SRIforSM relay function

This solution requires IP-SM-GW functionality to be activated in every Open TAS in the network. The HLR must provide standards-based IP-SM-GW support and VoLTE sub-scribers must be IP-SM-GW users. Furthermore, each Homing SCC AS and Open TAS (MMTel AS/IP-SM-GW) should be configured with an SMSC address for VoLTE NSDM MAP messages (configurable using the WV MML Command group). For more informa-tion on how IP-SM-GW specific SRIforSM relay functionality works, see section IP-SM-GW homing in Feature 2001: IP-SM-GW Support in NVS (Application Server Mode), Feature Description.


If the parameter’s value is set to 2, the Sh based approach is used. The VLR of the Homing SCC AS asks the GT address of the Open TAS currently serving the subscriber from the HSS. The HSS stores Open TAS addresses (including the GT address) in a repository called NVS-Data.

NVS-Data is created by the Open TAS and stored in the HSS. During registration, the Open TAS retrieves NVS-Data repository data from the HSS. The Open TAS sends a User-Data-Request (UDR) to the HSS, which returns the requested data in a User-Data-Answer (UDA) message. If there is any other Sh query prior to sending the 200 OK message at the end of a successful registration (for example, when VoIP subscription data or supplementary service data is downloaded from the HSS), NVS-Data repository data is downloaded as part of that Sh query.

If there is no Sh interaction involved in the registration process (for example, when VoIP subscription data is retrieved from the LDAP directory and supplementary service data from the HLR), then NVS-Data is downloaded after the 200 OK is sent.

The Open TAS compares the data returned by the HSS to data configured in the Open TAS. If the Open TAS finds that the retrieved data differs from the configured data, it sends the HSS a Profile-Update-Request (PUR) message over the Sh interface to

Homing SCC AS/ VLR


HLR




NSDM:

CdPa GT = MSC address of S (TAS/IP-SM-GW)CgPa GT =msisdn=MSISDNimsi=IMSIModified subscriber data

TASCC AMSC address of Homing S

VLR check


SIP and CS

NSDM is routed to the S (TAS/IP-SM-GW) since the Homing S's VLR application cannot find the subscriberTA SCC A

NSDM:



SCC A

IP-SM-GW/ VLR

DN0628541Issue 8-0-1

51


Feature description

Id:0900d80580a37f33

update its address in the NVS-Data repository. If the HSS does not return any data at the initial NVS-Data repository data retrieval—that is, the repository is not yet created—the Open TAS sends the PUR message with the SequenceNumber set to 0 to indicate repository data creation. In any other case—that is, when the HSS does return reposi-tory data in the UDA message—when sending the PUR, the Open TAS will increase the SequenceNumber sent by the HSS in the UDA by 1.

g NVS-Data repository data does not require any extra provisioning on subscriber level. NVS-Data is provisioned to the HSS on network element level to allow the creation of this data from the Open TAS over Sh.

g The figure illustrates a multiple repository support scenario where data related to all repositories is downloaded using one Diameter request message (that is, notif-eff-support is on). In a single repository support scenario, there are as many Diameter message pairs between the Open TAS and the HSS as many repositories are enquired.

52 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 29 NVS-Data repository data management during registration

Following initial registration, the NVS-Data may be requested by the Open TAS from the HSS during reregistration, restoration, and implicit registration. Whether NVS-Data is downloaded from and updated in the HSS by the Open TAS is controlled by the USE_NVS_DATA_REP (052:0119) PRFILE.

For more information about the NVS-Data repository, see the Sh Interface Description document.

In a georedundancy scenario, when the VoLTE subscriber is not present in the Homing SCC AS’s VLR and the NSDM_RELAY_MODE (052:0114) PRFILE parameter’s value is set to 2, the Homing SCC AS sends a User-Data-Request (UDR) message to the HSS to retrieve NVS-Data repository data and thus discover where the subscriber is regis-tered. The search key used by the Open TAS is the MSISDN received in the NSDM, it is encoded to the MSISDN AVP. The HSS returns NVS-Data information in a User-Data-Answer (UDA) message to the Open TAS. The VLR checks the returned GT address.

S-CSCF Open TAS

REGISTER

(a@domain)

200 OK

Continue

registration

HSS

Sh:UDR(RepositoryData, ServiceIndication=SIP-Basic-Data, NVS-Data

optional: MMTEL-Services, MMTEL-Services-Extra)

Sh:UDA(Open TAS addresses)

Sh:SNR(RepositoryData, ServiceIndication=SIP-Basic-Data

optional: MMTEL-Services, MMTEL-Services-Extra)

Sh:SNA

Check if Open TAS addresses

are up-to-date in HSSNo

Sh:PUR(RepositoryData, ServiceIndication=NVS-Data)

Sh:PUA

Continue SCC AS

functionality if needed

Sh interactionis involved in theregistration process

Sh:UDR(RepositoryData, ServiceIndication=NVS-Data

Sh:UDA(Open TAS addresses)

Other


Other


No other

DN0628541Issue 8-0-1

53


Feature description

Id:0900d80580a37f33

If the GT address is not received or an invalid value is received, the NSDM is not relayed but its receipt is acknowledged.

Figure 30 Invalid or no GT address returned

If the GT address is received and is the same as that of the Homing SCC AS, the NSDM is not relayed but its receipt is acknowledged. NSDM processing stops with a successful response.

g When the subscriber is not listed in the VLR and the addresses of the Homing SCC AS and the subscriber’s Open TAS still match, it means that the subscriber is deregistered from the Open TAS and the HSS has not yet been updated. Deregistration does not trigger an HSS update (that is, Open TAS address removal). This is why the HSS points to the Open TAS in which the subscriber is missing from the VLR. When the subscriber next registers in the SIP access network, his/her VLR data is updated automatically by the MAP RestoreData operation.

Homing SCC AS/ VLR


HLR



NSDM_RELAY_MODE(052:0114) = 2PRFILEcheck

Compare Homing Saddress with

SCC AGT address

invalid or no address

NSDM:



SCC A

HSS

Sh:UDR(RepositoryData, ServiceIndication=NVS-Data, UserIdentity=MSISDN)

Sh:UDA(Open TAS GT address)

invalid or no address

54 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

Figure 31 Matching GT address returned

If the GT address is received and is different from that of the Homing SCC AS, the VLR constructs and relays the NSDM to the hosting Open TAS in the same way as it is done in the IP-SM-GW cases.

Homing SCC AS/ VLR


HLR





SCC AGT address

addresses match

NSDM:



SCC A

HSS



DN0628541Issue 8-0-1

55


Feature description

Id:0900d80580a37f33

Figure 32 Non-matching GT address returned

1.4.7 Location and visited network information handling during registra-tionThe Open TAS manages LTE location information and visited network specific location information for service execution purposes, and, respectively, for barring purposes, during call handling and messaging in the IMS. With this optional feature in the Open

Homing SCC AS/ VLR


HLR


MAP NoteSubscriberDataModified(IMSI, MSISDN, Data)



SCC AGT address

addresses matchdon't

NSDM:



SCC A

Hosting Open TASHSS



NSDM:

Modified dataimsi=IMSI

subscriber

CdPa GT = Ho SCgPa GT =

MSC address of sting Open TAMSC address of Homing SCC AS

msisdn=MSISDN

VLR check


SIP only

Update VLR



VLR check


SIP and CS

User found in VLR



addresses match


User not found in VLR


Compare H ing Saddress with

ost Open TAGT address

56 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

TAS, E-UTRAN location and visited network specific identifiers are correlated to 2G/3G identifiers so that the existing service logic can utilize these in the existing configuration over the existing interfaces.

The E-UTRAN location and visited network specific identifiers are obtained by the Open TAS during registration. The Open TAS registration logic is extended with the capability to retrieve and store location information from the following headers of the REGISTER request:

• P-Access-Network-Info (PANI) • P-Visited-Network-ID (PVNI)

E-UTRAN location informationDuring initial third-party registration, the Open TAS selects a P-Access-Network-Info (PANI) header as the source of the E-UTRAN location information, parses the header, and correlates the retrieved information (ECGI) against the LTE to 2G/3G location mapping configuration of the E-UTRAN cell configuration. As a result of a successful registration, the Open TAS stores the E-UTRAN location, and the location specific con-figuration record in the SPD.

The same logic applies during re-registration, and both originating and terminating implicit registration.

Visited network specific location informationDuring initial third-party registration, if the REGISTER request includes a P-Visited-Network-ID (PVNI) header, the Open TAS parses the header content and stores the PVNI header string in the SPD. During registration, the PVNI header is only stored in the internal database but, at this point, the information is not validated against the Visited NW configuration.

The same logic applies during re-registration, and both originating and terminating implicit registration.

For more information, see Feature 2037: LTE/MBB Location Support, Feature Descrip-tion.

1.4.8 Files

HRNFILFunctionality related to Georedundancy for Open TAS based VoLTE extends HRNFIL through the addition of the following parameters:

• OIPSMGW

This parameter represents the address of a VoLTE subscriber’s IP short message gateway. This parameter must be configured for the subscriber in the HRNFIL file, in the network element running the IP-SM-GW.

• VOLNSDM

This parameter represents a special case scenario. If this parameter is set to SMSC address for VoLTE NSDM, the IP-SM-GW does not execute its usual homing logic on receipt of a MAP SRIforSM relay message. It instead executes the logic described in section Subscriber data modification notifications and georedundancy for Open TAS based VoLTE.

DN0628541Issue 8-0-1

57


Feature description

Id:0900d80580a37f33

g This parameter must be configured for the subscriber in the HRNFIL file of each Open TAS—that is, of each network element running MMTel AS and IP-SM-GW functionality.

Instructions for setting OIPSMGW and VOLNSDM using the WV MML command group are given in section Activating georedundancy for NVS based VoLTE in Feature 1673: NVS Registration (Application Server Mode), Feature Activation Manual.

1.4.9 Parameters

1.4.9.1 Open TAS specific parameters • MSC_AS_VOIP_SUPPORT (002:1089)

This FIFILE parameter controls the Open TAS by activating and deactivating appli-cation server mode. If this parameter is enabled, the Open TAS accepts SIP messages on its ISC Access and ISC Network interfaces.

g The MSC_VOIP_SUPPORT (002:1078) and MSC_AS_VOIP_SUPPORT (002:1089) FIFILE parameters, and the functionalities they are based on, are independent from each other; it is possible, therefore, to enable both parameters and so have both sets of functionalities operating at the same time.

• MSC_VOIP_TCP_SUPP (002:1219)

This FIFILE parameter controls whether the Transmission Control Protocol (TCP) can be used for outgoing SIP requests and responses in the Open TAS. If not, the User Datagram Protocol (UDP) is used.

• NSDM_RELAY_MODE (052:0114)

This PRFILE parameter defines which relay method to use when the Open TAS receives a NoteSubscriberDataModified MAP message from the HLR and the sub-scriber is not listed in the VLR.

Possible values:

– 0D

The NoteSubscriberDataModified MAP message is not relayed. (Default)

– 1D

IP-SM-GW based functionality is used to relay the NoteSubscriberDataModified MAP message to the subscriber’s Open TAS.

– 2D

HSS data over the Sh interface is used to relay the MAP NSDM to the sub-scriber’s Open TAS.

• USE_NVS_DATA_REP (052:0119)

This PRFILE parameter controls whether the NVS-Data repository is downloaded from and updated in the HSS.

Possible values:

– TRUE

NVS-Data repository is downloaded from and updated in the HSS.

58 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

– FALSE

NVS-Data repository is not downloaded from and not updated in the HSS.

• NVS_TERMINAL_IP_CHECK (052:0097)

This PRFILE parameter controls whether or not the Open TAS should store the IP address of the device that the subscriber uses to connect to the VoIP service during registration. It also determines whether or not initial requests are accepted from that IP address. There are two values to choose from:– TRUE

The subscriber device’s IP address is stored in the SPD during registration. Initial INVITE/MESSAGE/PUBLISH/SUBSCRIBE requests are only accepted if they originate from this IP address. Otherwise, the requests are rejected.

– FALSEThe subscriber device’s IP address is not stored in the SPD and no checking is performed on initial requests.

• PRI_REPO_SOURCE (002:2056)

This parameter determines where the Open TAS should retrieve VoIP subscriber data and supplementary service data from.

Possible values:

0 Retrieve the subscriber’s VoIP data from the SDB LDAP directory. (Default)

1 Retrieve the subscriber’s VoIP data from the HSS and the sub-scriber’s MMTEL data from the HLR.

2 Retrieve both the subscriber’s VoIP data and MMTEL data from the HSS.

• SIP_ALLOWED_IMPREG_TYPE (052:0070)

This PRFILE parameter is used to select the SIP implicit registration type. There are four types to choose from:– 0D (default)

SIP implicit registration is not allowed.– 1D

SIP implicit registration is only allowed with SIP originating transactions.– 2D

SIP implicit registration is only allowed with SIP terminating transactions.– 3D

SIP implicit registration is allowed with both SIP originating and SIP terminating transactions.

• SIP_CONN_SETUP (052:0031)

This parameter determines the maximum length of time that can be used for TCP connection setup. If the connection cannot be established during this time, SIP falls back to UDP. A fallback to UDP may occur even earlier if the transport connection indicates an error—for example, when the remote end does not listen for a connec-tion.

The timeout is determined in tens of milliseconds. The possible values are the fol-lowing:

20 (200 ms) minimum value

DN0628541Issue 8-0-1

59


Feature description

Id:0900d80580a37f33

2000 (20 seconds) maximum value

500 (5 seconds) default value

The value 0 means that SIP waits until the transport connection gives up the con-nection setup.

• SIP_CONN_TCP_USED (052:0043)

This parameter defines whether outgoing requests are sent using the TCP connec-tion if the local policy, such as the transport protocol of the registered contact, allows it.

• SIP_CONN_TIMEOUT (052:0025)

This parameter determines the maximum length of time that the TCP connection can be kept open without any activity. If a message is neither sent nor received during this time period, the connection is closed.

The timeout is determined in seconds. The possible values are the following:

10 seconds minimum value

28800 seconds (8 hours) maximum value

1800 seconds (1/2 hours) default value

The value 0 means that the connection is never closed. The value 1 indicates that the connection can only be closed after all call handling hands have terminated.

• SIP_CONN_TIMEOUT_ACCESS (052:0042)

This parameter determines the maximum length of time that the TCP connection can be kept open without any activity toward users on the SIP access interface. If SIP messages are neither sent nor received during this time period, the connection is closed.

The timeout is determined in seconds. The possible values are:

10 seconds minimum value

28800 seconds (8 hours) maximum value

60 seconds default value

The value 1 indicates that the connection can only be closed after all call handling hands have terminated. On ISC interfaces, the SIP_CONN_TIMEOUT (052:0025) parameter is used.

• SIP_IMPLICIT_REG_SUPP (002:1363)

This FIFILE parameter makes SIP implicit registration functionality available to oper-ators.

• SIP_USE_LDAP_IF_LDAPLES (052:0095)

This PRFILE parameter is used to control whether or not Open TAS executes LDAP queries, even if the Open TAS without LDAP connection functionality is active. If the parameter is set to TRUE, the Open TAS reads the subscriber’s data from the LDAP directory. If there is no LDAP entry for the subscriber, the Open TAS serves the sub-scriber in accordance with the Open TAS without LDAP connection functionality.

If the parameter is set to FALSE, the Open TAS serves the subscriber in accordance with the Open TAS without LDAP connection functionality.

60 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

• TCP_ACTIVATED_ON_ISC_IF(052:0048)

Using this parameter, the operator can control whether or not TCP can be used on the SIP ISC interfaces of the Open TAS for SIP requests and responses. This parameter can be set only if the MSC_VOIP_TCP_SUPP FIFILE parameter has been activated.

• USE_RC_AS_PROFILE (052:0090)

This PRFILE parameter instructs the Open TAS to use the value of the subscriber’s routing category as a SIP group profile ID, MWI server ID and/or Message profile (MP) ID when the Open TAS without LDAP connection functionality is active.

g Setting the subscriber’s routing category value as the MWI server ID has no effect. This is because a separate application server handles MWI requests.

Possible values:

000B The SIP group profile ID, MWI server ID and Message Profile (MP) ID are set to their default values—that is, to 0, 1 and 0 respectively.

001B The value of the subscriber’s routing category is used as the SIP group profile ID. The subscriber's MWI server ID and Message Profile (MP) ID are set to their default values—that is, to 1 and 0.

010B The value of the subscriber’s routing category is used as the MWI server ID. The subscriber's SIP group profile ID and MP ID are set to their default values—that is, to 0.

100B The value of the subscriber’s routing category is used as the MP ID. The subscriber's SIP group profile ID and MWI server ID are set to their default values—that is, to 0 and 1 respectively.

011B The value of the subscriber’s routing category is used as both the SIP group profile ID and the MWI server ID. The subscriber's MP ID is set to its default value—that is, to 0.

110B The value of the subscriber’s routing category is used as both the MWI server ID and the MP ID. The subscriber's SIP group profile ID is set to its default value—that is, to 0.

101B The value of the subscriber’s routing category is used as both the SIP group profile ID and the MP ID. The subscriber's MWI server ID is set to its default value—that is, to 1.

111B The value of the subscriber’s routing category is used as the SIP group profile ID, MWI server ID and MP ID.

• VOIP_SIP_RESTORATION (052:0056)

With this PRFILE parameter, the operator can control whether or not SIP subscriber data should be restored after an SCPU unit restart—for example, in the case of a failed switchover. The operator can also define whether SIP restoration should be performed in the case of SIP originating transactions only, in the case of SIP termi-nating transactions only, or in both cases.

DN0628541Issue 8-0-1

61


Feature description

Id:0900d80580a37f33

1.4.9.2 SIP-I PRFILE parameters • DSCP_FOR_SIGNALLING (053:0009)

Signaling applications, such as Bearer Independent Call Control (BICC), SIP, H.248, M3UA, and the interworking function (IWF) control protocol use this param-eter to set the differentiated services codepoint carried in the Type of Service or Traffic Class field in IPv4 and IPv6 headers, respectively. The parameter can be set to any value between 0H and 03FH. For definitions of the DiffServ codepoints and their respective values, see IETF RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Dec 1998, IETF RFC 2597 Assured Forwarding PHB Group, June 1999, and IETF RFC 2598 An Expedited Forwarding PHB, June 1999.

• SIP_TIMER_T1 (052:0001)This parameter determines SIP timer T1 for the retransmission of exponential backoff expressed in milliseconds. A SIP client using UDP must retransmit a BYE, CANCEL, OPTIONS, REGISTER or MESSAGE request with an exponential retreat, starting at a T1 second interval, doubling the interval for each packet, and capping off at a T2 second interval. This means that when the first packet is sent, the second packet is sent T1 seconds later, the next 2*T1 seconds after that, the next 4*T1 seconds after that, and so on, until the interval reaches T2. Subsequent retransmissions are spaced by T2 seconds. If the client receives a provisional response, it continues to retransmit the request, but with an interval of T2 seconds. Retransmissions cease after the client has sent a total of eleven packets, or when the client receives a definitive response. Default values for T1 and T2 are 500 ms and 4s, respectively. Clients can use larger values, but must not use smaller ones.

• SIP_TIMER_T2 (052:0002)This parameter determines the SIP timer T2 for the retransmission of requests other than INVITEs expressed in milliseconds, when unreliable transport is used. A SIP client using UDP must retransmit a BYE, CANCEL, OPTIONS, REGISTER or MESSAGE request with an exponential retreat, starting at a T1 second interval, doubling the interval for each packet and capping off at a T2 second interval. This means that after the first packet is sent, the second packet is sent T1 seconds later, the next 2*T1 seconds after that, the next 4*T1 seconds after that, and so on, until the interval reaches T2. Subsequent retransmissions are spaced by T2 seconds. If the client receives a provisional response, it continues to retransmit the request, but with an interval of T2 seconds. Retransmissions cease after the client has sent a total of eleven packets or when the client receives a definitive response. Default values for T1 and T2 are 500 ms and 4 s, respectively. Clients can use larger values, but must not use smaller ones.

• SIP_TIMER_T4 (052:0035)This parameter defines the SIP timer T4 which, in the case of non-INVITE client transactions, represents the amount of time the network needs to clear messages between client and server transactions as described in IETF RFC3261 SIP: Session Initiation Protocol, June 2002.

1.4.10 StatisticsSee Feature 1696: NVS Statistics, Feature Description.

62 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

1.4.11 ChargingSee Feature 1703: NVS Charging, Feature Description.

1.4.12 Transport

1.4.12.1 TCP supportTCP is supported in the Open TAS and can be enabled or disabled using the MSC_VOIP_TCP_SUPP (002:1219) FIFILE parameter. If activated, TCP can be switched on or off using PRFILE parameters. TCP can be activated and deactivated using the TCP_ACTIVATED_ON_ISC_IF (052:0048) PRFILE parameter on ISC interfaces. TCP is supported only if both the MSC_VOIP_TCP_SUPP (002:1219) and the TCP_ACTIVATED_ON_ISC_IF (052:0048) PRFILE parameters are active. If either of them is deactivated, TCP is not supported on ISC interfaces.

1.4.12.2 SCTP supportSupport for SIP over SCTP in the context of Open TAS registration (application server mode) means support for SCTP on the ISC Access interface.

1.5 CapacityThere are no capacity considerations related to this feature.

1.6 Restrictions • The user part of the SIP URI is a maximum of 35 characters; the domain part of the

SIP URI is a maximum of 65 characters. • Registration with TEL URL (for example, tel: +1234) is not supported.

g However, sip: [email protected] is supported.

• The Open TAS can receive more contact addresses in the SIP REGISTER request coming from an S-CSCF; however, only the one with the highest preference can be stored in the SPD.

• There can be no more than 300 SIP group profiles. • There can be no more than 255 FQDNs on the domain list. • The maximum size of an accepted SIP messages is 8 Kilobytes. • The Reg-Event package is not supported by the Open TAS.

Open TAS without LDAP connection restrictionsIf the NVS without LDAP license is activated and the SIP_USE_LDAP_IF_LDAPLES (052:0095) PRFILE parameter is set to FALSE, the following restrictions apply:

• Only sip:<number>@<domain>formatted SIP URIs are supported. Alphanumeric SIP URIs are not supported.

• Implicit registration for terminating transactions is not supported.

DN0628541Issue 8-0-1

63


Feature description

Id:0900d80580a37f33

1.7 Related and interworking featuresThis feature interworks with the following features:

• Feature 906: MSRN Allocation Enhancements

The feature provides the possibility to allocate MSRNs based on the called sub-scriber’s registered Location Area (LA). LA-based functionality provides the ability to assign an MSRN group to one or several location areas. A location area is selected for the subscriber during registration. This location area is used later when terminat-ing calls.

• Feature 1331: Session Initiation Protocol in MSS

The Session Initiation Protocol (SIP) is used to create and manage multimedia sessions between two or more participants over the Internet in third generation net-works. A general aim of SIP is to support Voice over IP and to ensure that future Voice over IP services are fully Internet-based. The feature works with other Open TAS features and implements the Media Gateway Control Function (MGCF). The SIP-I interface [International Telecommunications Union (ITU-T)] can be used between Open TASs.

• Feature 1451: IMS-CS Interworking

This feature extends BICC and SIP interworking in the interface serving node (ISN), which provides the interworking between IMS and CS networks, in accordance with 3GPP/ITU-T standards.

• Feature 1541: Same CLI for Multiple Subscribers

This feature makes it possible for several International Mobile Subscriber Identities (IMSIs) to use a common Mobile Station International ISDN Number (MSISDN) when establishing calls (voice or data) or sending short messages. The mobile stations can belong to one or more users.

• Feature 1670: SIP Subscriber Database

This feature enables the storage of additional SIP subscriber attributes in a separate database (LDAP directory) in much the same way that the DX HLR stores GSM sub-scription related data.

• Feature 1671: NVS Call Handling

This feature provides functionality related to SIP call scenarios on SIP access and trunk interfaces.

• Feature 1696: NVS Statistics

The feature offers statistical support for the Open TAS.

Statistical functions for the Open TAS are provided through the extension of several measurements and observations that already exist in the MSS network elements, and by introducing new measurements and observations that provide Open TAS specific information.

• Feature 1703: NVS Charging

This feature offers customers the basic ability to charge using CDRs on the Circuit Switched (CS) network side for the usage of the Open TAS and other possible IP Multimedia Systems (IMSs) in cases where the user or usage is related or interfaced with the CS network through SIP.

64 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

• Feature 1760: NVS Messaging

This feature provides Instant Messaging (IM) functionality to the Open TAS and enables the handling of SIP User Agent (UA) originated and terminated messages as well as IM-SMS interworking. With this feature, VoIP subscribers can have similar services to GSM and UMTS subscribers.

• Feature 1863: SIM-based Authentication for NVS Convergence

This feature enhances authentication with the implementation of Digest AKAv1 and AKAv2 (according to RFC3310, Hypertext Transfer Protocol (HTTP) Digest Authen-tication Using Authentication and Key Agreement (AKA) and RFC4169, Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2).

This feature provides the means to authenticate VoIP subscribers when the Open TAS without LDAP connection functionality is in operation and the SIP_USE_LDAP_IF_LDAPLES (052:0095) PRFILE parameter is set to FALSE.

• Feature 1903: MSS - IP Realm

The feature provides support for multiple isolated IP networks, referred to as IP realms, in MSS and Nokia Siemens Networks Open Telecom Application Server (Open TAS) environments. This feature is relevant to the MSS and control plane sig-naling, since the MGW already supports the concept of multiple isolated IP networks for the user plane.

• Feature 1990: SCC AS in NVS (Application Server Mode)

This feature provides homing and Terminating Access Domain Selection (T-ADS) functionality that enables a CS call to be homed to the appropriate Open TAS for further processing and terminating access domain selection before routing it [the call] to the called party over the appropriate access domain.

• Feature 2001: IP-SM-GW Support in NVS (Application Server Mode)

This feature provides the IP-SM-GW specific homing logic that enables the Open TAS to relay MAP NoteSubscriberDataModified messages from the Homing SCC AS to the VoLTE subscriber’s serving Open TAS when located in separate network elements, or when unregistered in the Homing SCC AS’s VLR.

• Feature 2027: Sh for NVS Subscriber Repository

This feature provides an alternative approach to retrieving VoIP subscriber data and supplementary service data for registration purposes: instead of obtaining the sub-scriber’s VoIP data from the SDB LDAP directory and the supplementary service data from the HLR, it is possible to obtain both from the HSS over the Sh interface. This is achieved by configuring the PRI_REPO_SOURCE (002:2056) PRFILE parameter appropriately.

• Feature 2037: LTE/MBB Location Support

This feature provides E-UTRAN location information and visited network specific location information management in the Open TAS. With this feature, E-UTRAN location information and visited network specific location information can be used in the existing service execution logic. This information is retrieved from the access network during registration.

DN0628541Issue 8-0-1

65


Feature description

Id:0900d80580a37f33

• Feature 2045: SCC AS for Session Continuity

This feature enables an ongoing session to be transferred across different access networks, including the transfer of several ongoing active and inactive calls.

1.8 ComplianceThis feature is compliant with the following relevant Internet Engineering task Force (IETF) Requests for Comments (RFCs):

• RFC 3261, SIP: Session Initiation Protocol (IETF SIP) • RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted

Identity within Trusted Networks • RFC 3455, Private Header (P-Header) Extensions to the Session Initiation Protocol

(SIP) for the 3rd-Generation Partnership Project (3GPP) • 3GPP TS 23.228, IP Multimedia Subsystem (3GPP SIP) • 3GPP TS 23.003, Numbering, addressing and identification

Detailed compliancy information is described in the Nokia Siemens Networks Mobile VoIP Server ISC Interface Description.

This feature is supported in 2G, 3G, and 4G environments.

1.9 Operator interfaces

1.9.1 MMLs

Subscriber Profile Database Configuration Administration Handling, JD Command GroupUsing the commands of this command group it is possible to configure and interrogate SDB client configurations.

• JDM - CREATE OR MODIFY DIRECTORY SERVER CONFIGURATION • JDC - INTERROGATE DIRECTORY SERVER CONFIGURATION • JDD - DELETE DIRECTORY SERVER CONFIGURATION • JDS - CHANGE THE STATE OF DIRECTORY SERVER CONFIGURATION • JDT - DISPLAY THE LDAP CONNECTION TABLE OF A UNIT • JDY - COPY DIRECTORY SERVER CONFIGURATION

g If the NVS without LDAP license is activated and the SIP_USE_LDAP_IF_LDAPLES (052:0095) PRFILE parameter is set to FALSE, the commands of the JD command group are hidden and their execution is disabled (regardless of the status of the MSC_VOIP_SUPPORT and MSC_AS_VOIP_SUPPORT FIFILE parameters). If, however, MultiSIM without HLR dependency functionality is enabled (or some other non-Open-TAS related function that requires LDAP to be enabled), these commands remain visible, regardless of the activation status of the NVS without LDAP license.

For more information on LDAP database and LDAP server configuration, see LDAP Interface for Nokia Siemens Networks MSC Server (MSS) and Mobile VoIP Server (NVS), User Guide.

For more information on the configuration of LDAP client processes, see Subscriber Profile Database Configuration Administration Handling, JD Command Group.

66 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

SIP Parameters Configuration Handling (JH Command Group)The command group helps you configure SIP group profiles for your end users. Func-tionality related to Simultaneous registration in Open TAS and MSS network elements through a single IMSI requires the use of the following commands:

• JHA - Add SIP group profile

This command is used to add a new profile to the configuration. The command has been extended to include the following information:

– VLRDLTYPE

g This parameter is only configurable and visible when the Restore data for SIP registration license is active.

This parameter can be set to UL, RD or TCSI.

If this parameter is set to UL—the default value—an UpdateLocation MAP oper-ation is used to update the subscriber’s HLR record with the visited Open TAS/VLR address. Nokia Siemens Networks recommends setting this parame-ter to UL for all Open TAS subscribers who do not have an LTE terminal.

If this parameter is set to RD, a RestoreData MAP operation is used to download the subscriber’s CS subscription information from the HLR to the VLR. Nokia Siemens Networks recommends setting this parameter to RD for all Open TAS subscribers who have LTE terminals.

If this parameter is set to TCSI, the subscriber’s Terminating CAMEL Subscrip-tion Information (T-CSI), provisioned in the HLR, is analyzed to determine the appropriate MAP operation to perform on the HLR: an UpdateLocation or a RestoreData. Nokia Siemens Networks recommends setting this parameter to TCSI for all VoIP users without a record in the SDB LDAP directory.

g Nokia Siemens Networks also recommends assigning this value to the default SIP group profile (ID=0), since all VoIP users without a record in the SDB LDAP directory are assigned the default SIP group profile.

• JHM - Modify SIP group profile

This command is used to modify the parameters in a VoIP subscriber’s SIP group profile.

g The VLRDLTYPE parameter is only configurable and visible when the Restore data for SIP registration license is active.

• JHI - Interrogate SIP group profile

Using this command you can interrogate the parameters of a VoIP subscriber’s SIP group profile.

g The VLRDLTYPE parameter is visible in printouts as SUBSCRIBER DATA DL TYPE IN VLR, but only when the Restore data for SIP registration license is active.

More information on these commands and the commands of the whole command group can be found in the SIP Parameters configuration handling (JH Command Group) command reference manual.

DN0628541Issue 8-0-1

67


Feature description

Id:0900d80580a37f33

SIP Address Configuration Handling, JI Command GroupThe following commands of this command group are used for configuring the listening points of each SCPU/CCSU/SIGU, the server addresses used in the Open TAS, VLR address resolution, and the mapping of the locationID to CGI.

• JII - INTERROGATE SIP ADDRESSESUse this command to interrogate SIP listening points.

• JIM - CREATE AND MODIFY SIP ADDRESSUse this command to create and modify SIP listening points.

• JIO - REMOVE SIP ADDRESSESUse this command to remove SIP listening points.

• JIS - ADD LOCATION ID MAPPINGUse this command to add a location ID entry.

• JIR - DELETE LOCATION ID MAPPINGUse this command to delete a location ID entry.

• JIT - QUERY LOCATION ID MAPPINGUse this command to query a location ID entry.

For more information on these commands and their parameters, see NVS Address Con-figuration Handling, JI Command Group.

Serving Profile Database Subscriber Handling (JO Command Group)This command group helps you see the configuration of the Serving Profile Database (SPD). Functionality related to Simultaneous registration in Open TAS and MSS network elements through a single IMSI makes use of the following commands:

• JOU - Update subscriber data in SPD and/or VLR

This command is used to trigger an update to a subscriber’s record in the SPD and/or VLR.

g The subscriber’s record in the VLR is only updated if the VLRDLTYPE parameter, stored in the subscriber’s SIP group profile, is set to RL—that is, to RestoreData. See the JHA MML command for more information on the possible values of this parameter.

This command takes the following parameters:

– IMSI

The IMSI of the subscriber’s device.

– Target database

This parameter can be set to Both, VLR, or SPD and indicates which database to update.

g Both and VLR values are only available when the Restore data for SIP registra-tion license is active.

• JOI - Interrogate SIP subscriber in SPD

This command is used to interrogate a subscriber in the Serving Profile Database (SPD).

g The VLRDLTYPE parameter is visible in printouts as SUBSCRIBER DATA DL TYPE IN VLR, but only when the Restore data for SIP registration license is active.

68 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

More information on these commands and the commands of the whole command group can be found in the Serving Profile Database Subscriber Handling (JO Command Group) command reference manual.

GSM Network and Network Element Specific Number (WV Command Group)This command group provides operations for creating, removing, modifying and interro-gating network and network element specific numbers, such as routing numbers for home and foreign users, IP-SM-GW addresses for specific subscribers, and so on.

Only the commands relevant to this feature, most notably to Georedundancy for Open TAS based VoLTE functionality, are listed below.

• WVS - CREATE NETWORK AND NETWORK ELEMENT SPECIFIC NUMBER

Use this command to create new routing parameters in the HRNFIL file.

• WVR - DELETE NETWORK AND NETWORK ELEMENT SPECIFIC NUMBER

Use this command to delete routing parameters from the HRNFIL file.

• WVF - MODIFY NETWORK AND NETWORK ELEMENT SPECIFIC NUMBER

Use this command to modify routing parameters in the HRNFIL file.

• WVI - INTERROGATE NETWORK AND NETWORK ELEMENT SPECIFIC NUMBER

Use this command to interrogate routing parameters in the HRNFIL file.

g For more information on each of these commands, with examples, see the relevant sections in the GSM Network and Network Element Specific Number (WV Command Group) command reference manual.

1.9.2 Alarms

2397 DATABASE FILE IS IN DANGER TO GET FULLThis alarm is set by the SPD. It is raised (only at 1:30 a.m.) when the upper alarm limit of the database file fill ratio (95%) has been exceeded.

Alarm class: two star alarm

1.10 Subscriber interfacesThere are no subscriber interfaces related to this feature.

1.11 Network elementsThe feature enables SIP users to register in the Open TAS through third-party registra-tion. The following network elements are involved in the process:

• Open TASThe SIP registrar functionality is implemented in the Open TAS.

• HLR/HLRiThe HLR is used to retrieve supplementary service and IN-related information. The HLR enquiry procedure is used to find out the VLR address or the MSRN address to be used to route terminating SIP or short messages, as well as terminating VoIP or normal voice calls, when required. This solution does not cause any new require-ments for the HLR network element.

DN0628541Issue 8-0-1

69


Feature description

Id:0900d80580a37f33

• SDB/LDAP serverExternal LDAP server is used to store and return static SIP specific data of the sub-scribers using the new SIP Access interfaces of the Open TAS.SDB data can be managed and maintained by LDAP solutions, such as, NPS, One-NDS or OpenLDAP. The SDB database is an LDAP directory. The SDB data, residing in the LDAP directory, is accessed and queried by the LDAP client pro-cesses of the Open TAS. The client processes are located in the signalling units of the Open TAS.The Open TAS supports both the two-site and the three-site LDAP client-server model, that is, LDAP server deployment on two or three sites. The optional high availability model offers a more flexible management of the LDAP databases in primary, secondary and tertiary servers. The high availability three-site model is an optional functionality and is controlled by license.If both the primary and secondary servers fail, the tertiary server can continue serving LDAP requests. Read failure measurement functionality provides an opti-mized solution to manage client-side high availability. Read failure measurement is an optional functionality and is controlled by license.For more information, see Feature 1670: SIP Subscriber Database, Feature Description.For more information on LDAP database and LDAP server configuration, see LDAP Interface for Nokia Siemens Networks MSC Server (MSS) and Mobile VoIP Server (NVS), User Guide.For more information on the configuration of LDAP client processes, see Subscriber Profile Database Configuration Administration Handling, JD Command Group.For more information on the high availability three-site model and Read failure mea-surement functionality, see the respective sections of the LDAP Interface for Nokia Siemens Networks MSC Server (MSS) and Mobile VoIP Server (NVS), User Guide.For more information on option control, see sections LDAP model and LDAP client applications of the LDAP Interface for Nokia Siemens Networks MSC Server (MSS) and Mobile VoIP Server (NVS), User Guide.

• HSSThe HSS can hold VoIP subscriber data in a repository called SIP-Basic-Data as well as supplementary service data in the MMTEL-Services and MMTEL-Services-Extra repositories. The Open TAS retrieves the contents of these repositories from the HSS during registration via the Sh interface.The HSS can also hold the addresses of the Open TAS currently serving the sub-scriber in a repository called NVS-Data. Repository data is created by the Open TAS and stored in the HSS for georedundancy purposes. A Homing SCC AS may retrieve Open TAS addresses from the HSS to discover where the subscriber is reg-istered so it can relay the MAP NSDM message to the correct Open TAS. This solution uses the Sh interface as a standardized interface toward the HSS network element.

1.12 External interfaces • SIP

ISC Access and ISC Network SIP interfaces are used in the Open TAS. The inter-faces are trusted and typically reside in the private network. They are used by the S-CSCF to communicate with the Open TAS for originating and terminating service execution. The interfaces are also compliant with both RFC 3261 (IETF SIP) and

70 DN0628541Issue 8-0-1


Id:0900d80580a37f33

Feature description

3GPP TS 23.228, IP Multimedia Subsystem (3GPP SIP). A description of the inter-faces can be found in Nokia Siemens Networks Mobile VoIP Server ISC Interface Description, Application Server Solution.

• MAPThis solution does not cause any new requirements for the MAP interface if no Nokia Siemens Networks specific features, such as MultiSIM, are used.

• LDAPThe LDAP interface is used toward the external SIP Subscriber Database (SDB) (LDAP directory).When the NVS without LDAP license is activated and the SIP_USE_LDAP_IF_LDAPLES (052:0095) PRFILE parameter is set to FALSE, the Open TAS does not use the LDAP interface to query SIP subscriber information.For more information about the LDAP interface and schema files, see Nokia Siemens Networks MSC Server and Mobile VoIP Server LDAP Interface Descrip-tion.

• ShThe Sh interface is used toward the HSS when the HSS is used to obtain: – VoIP subscriber data and/or supplementary service data– the addresses of the Open TAS serving the subscriberFor more information about the Sh interface, see the Sh Interface Description doc-ument.

DN0628541Issue 8-0-1

71


Main changes in Feature 1673: NVS Registration (Ap-plication Server Mode)

Id:0900d80580a3b07b

Main changes in Feature 1673: NVS Registra-tion (Application Server Mode)

Changes in the featureChanges in the feature between releases M16.2 and M16.1 EP1The Phase 2 implementation of Feature 2027: Sh for NVS Subscriber Repository intro-duces:

• the possibility to retrieve supplementary service data from the HSS over the Sh inter-face rather than from the HLR over the MAP interface

• support for XCAP operations over the Sh interface

The Georedundancy for Open TAS-based VoLTE functionality has been extended with the possibility to relay the MAP NSDM message to the Open TAS currently serving the subscriber using data stored in the HSS.

The Open TAS registration logic has been extended with LTE location and visited network specific location information management.

Due to support for the automatic generation of the IMSI when not received over the Sh interface, it is not mandatory for operators to configure the IMSI.

Changes in the feature between releases M16.1 EP1 and M16.1Georedundancy for NVS-based VoLTE functionality has been added to this feature. This functionality allows MAP NoteSubscriberDataModified messages to be routed to the appropriate NVS (TAS/IP-SM-GW) so that the NVS’ VLR application can update the subscriber’s record with changes already made to the subscriber’s supplementary service data in the HLR.

Changes in the feature between releases M16.1 and M15.1Simultaneous registration functionality has been added. This allows subscribers with LTE terminals to be registered in both PS and CS networks at the same time, under the same IMSI.

Changes in the feature between releases M15.0 and M14.5Functionality that enables the NVS to query LDAP when the NVS without LDAP license is activated and to detect and prohibit concurrent login to the NVS from multiple termi-nals has been added.

Changes in the feature between releases M14.5 and M14.0Functionality to support NVS without LDAP has been introduced.

Changes in the feature between releases M14.0 and M13.3This feature was implemented in M14.0 with the following changes to M13.3:

• TCP support in the NVS has been introduced. • Support of the SIP over SCTP transport has also been introduced. The optional

SCTP transport can be used with multi-homing and can be selected per FQDN.

72 DN0628541Issue 8-0-1


Id:0900d80580a3b07b


Changes in the documentChanges made between issues 8-0-1 and 8-0-0The following sections have been added:

• Subscriber data in HSS • Subscriber data in HLR • Subscriber data in LDAP server • Repository solutions in different deployment scenarios

Information on registration types has been revised and new use cases have been added:

• Registration in Multifunction VoLTE AS • Registration in MMTel AS/IM-SSF

Added a note about the support for the automatic generation of the IMSI when it is not received over the Sh interface in section Subscriber data in HSS.

Changes made between issues 8-0-0 and 7-1-1The following sections have been updated:

• Subscriber data managementA note about the possibility to retrieve supplementary service data from the HSS has been added.

• Serving Profile Database (SPD)A note about the Sh based approach has been added.

• Subscriber data modification notifications and georedundancy for Open TAS based VoLTE.A note about XCAP operations over the Sh interface has been added.

• Subscriber data modification notifications and georedundancy for Open TAS based VoLTEInformation has been added about the possibility to relay the MAP NSDM message to the subscriber’s Open TAS using HSS data retrieved over the Sh interface.

• Parameters– The description of NSDM_RELAY_MODE (052:0114) has been updated with a

new value (2D).– PFRFILE parameter USE_NVS_DATA_REP (052:0119) has been added.– The description of PRI_REPO_SOURCE (002:2056) has been updated with a

new value (2). • Restrictions

The restriction about the Open TAS not using the Sh interface has been removed. • Related and interworking features

– The entry about Feature 2027: Sh for NVS Subscriber Repository has been updated with information about the possibility to retrieve supplementary service data from the HSS over the Sh interface.

– Feature 2037: LTE/MBB Location Support has been added. • Subscriber interfaces

Information about the HSS network element has been added. • External interfaces

Information about the Sh interface has been added.

The following section has been added:

DN0628541Issue 8-0-1

73



Id:0900d80580a3b07b

• Location and visited network information handling during registration

To reflect the addition of a new product to the Nokia Siemens Networks portfolio and the resulting change in naming conventions, instances of Nokia Siemens Networks Mobile VoIP Server (NVS) and NVS have been replaced, where appropriate, with Nokia Siemens Networks Open Telecom Application Server (Open TAS) and Open TAS or the appropriate role of the Open TAS product. Feature names and license names, however, retain the term NVS. For further information, see the document entitled Impact of the Nokia Siemens Networks Open Telecom Application Server (Open TAS) on Documen-tation.

Internal SCP LK license has been added to section Software.

Changes made between issues 7-1-1 and 7-1-0Incorrect occurrences of the SIP_USE_LDAP_IF_LDAPLES (052:0095) PRFILE parameter have been fixed throughout the document. The parameter number has been corrected from 052:0096 to 052:0095.


• Subscriber data modification notifications and georedundancy for Open TAS based VoLTEThis section, previously entitled Subscriber data modification notifications, has been updated to include details about NSDM relaying, using IP-SM-GW specific SRIforSM functionality.

• FilesParameter extensions to the HRNFIL have been added.

• ParametersThe NSDM_RELAY_MODE (052:0114) PRFILE parameter has been added.

Changes made between issues 7-0-0 and 6-0-1The following section has been added:

• Registration in Multifunction VoLTE AS

The following sections have been updated:

• Registration in MMTel AS/IM-SSF • Requirements for using the feature • Related and interworking features • Compliance • MMLs

Changes made between issues 6-0-1 and 6-0-0Editorial updates have been made to section NVS without LDAP functionality.


• NVS-specific parametersVOIP_SCTP_ON_SIP_ACCESS (052:0071) PRFILE parameter has been removed.

• MMLs • Subscriber interfaces

74 DN0628541Issue 8-0-1


Id:0900d80580a3b07b


• External interfaces

Changes made between issues 5-0-1 and 5-0-0A note concerning lack of SIP support for DSCP when Feature 1828: SIP Load Balancer is activated has been added to the DSCP_FOR_SIGNALLING (053:0009) PRFILE parameter in section Common SIP PRFILE parameters (commonly used with SIP-I and SIP-T trunk).

Changes made between issues 5-0-0 and 4-0The document as a whole has been edited to ensure easier reading.

The functionality NVS operation without LDAP has been renamed to NVS without LDAP.

Several sections have been updated with subsections of their own—for example:

• NVS without LDAP • Querying LDAP when the NVS without LDAP license is activated

The following sections have been added to section Functionality:

• NVS concurrent login prevention

Changes made between issues 4-0 and 3-1The following sections and subsections have been updated to incorporate information on the functionality of NVS operation without LDAP.

• Introduction • Benefits for the operator • SCTP support in subsection Transport • Restrictions • Related and interworking features • Compliance • External interfaces

Subsection NVS operation without LDAP has been added to the Functionality section.

PRFILE parameter USE_RC_AS_PROFILE has been added to the NVS-specific param-eters subsection.

In subsection MMLs, JI and JH command groups have been updated, and JD command group has been added.

Changes made between issue 3-1 and 3-0Editorial changes have been made.

Changes made between issues 3-0 and 2-0The company and product names have been changed according to the official Nokia Siemens Networks portfolio naming.

feature 1673 - nvs registration (application server mode)

Documents

feature documentation

software products

additional information

environmental services

product names

product packaging

mentioned hardware

power use