feature 1673 - nvs registration (standalone mode)

7/18/2019 Feature 1673 - NVS Registration (Standalone Mode)

http://slidepdf.com/reader/full/feature-1673-nvs-registration-standalone-mode 1/47

MSC Server, Rel. M16.2,

Feature Documentation,

version 2

Feature 1673: NVS Registration

(Standalone Mode)

DN0628538

Issue 8-0-0

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 DN0628538

Issue 8-0-0

Feature 1673: NVS Registration (Standalone Mode)

Id:0900d805809109f5

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 whichthe 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 respectiveowners, 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 ProduktsicherheitVon 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.



DN0628538

Issue 8-0-0

3


Id:0900d805809109f5

Table of ContentsThis document has 47 pages.

1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Benefits for the operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Requirements for using the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1 Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.3 Products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Subscriber data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.2 Serving Profile Database (SPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.3 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.3.1 General concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.3.2 Registration without authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.3.3 Registration with authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4.3.4 Re-registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.3.5 Deregistration, user-initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4.3.6 Deregistration, network initiated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4.4 NVS without LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.5 Simultaneous registration in NVS and MSS network elements through a

single IMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.4.5.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4.5.2 Registering as an NVS subscriber using an LTE terminal . . . . . . . . . . . 251.4.5.3 Registering as an NVS subscriber without an LTE terminal . . . . . . . . . 26

1.4.5.4 Registering as a visiting VoIP user with an LTE terminal, but no record in

the SDB LDAP directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.4.5.5 Registering as a visiting VoIP user without using an LTE terminal and no

record in the SDB LDAP directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.4.5.6 Subscription data modification notification. . . . . . . . . . . . . . . . . . . . . . . 31

1.4.6 NVS concurrent login prevention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.4.7 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.4.8 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.4.9 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.4.10 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.4.11 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

1.5 Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

1.6 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

1.7 Related and interworking features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1.8 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1.9 Operator interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1.9.1 MMLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1.9.2 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1.10 Subscriber interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1.11 External interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Main changes in Feature 1673: NVS Registration (Standalone Mode) . 45



4 DN0628538

Issue 8-0-0


Id:0900d805809109f5

Changes in the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Changes in the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45



DN0628538

Issue 8-0-0

5


Id:0900d805809109f5

List of FiguresFigure 1 NVS registration - protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 2 Interfaces toward subscriber information-related databases . . . . . . . . . . 9

Figure 3 Registration without authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 4 Registration with authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 5 Re-registration with authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 6 Deregistration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 7 Network-initiated deregistration, user is deleted . . . . . . . . . . . . . . . . . . 15

Figure 8 Network-initiated deregistration, user status is changed . . . . . . . . . . . . 15

Figure 9 Network-initiated deregistration, HLR initiates subscriber de-registration .

16

Figure 10 Unsuccessful registration - IMSI not found . . . . . . . . . . . . . . . . . . . . . . 17

Figure 11 Successful registration - LDAP query still possible despite NVS without

LDAP license activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 12 Successful registration in the absence of LDAP . . . . . . . . . . . . . . . . . . 20

Figure 13 Registering as an NVS subscriber using an LTE terminal. . . . . . . . . . . 26

Figure 14 Registering as an NVS subscriber without an LTE terminal . . . . . . . . . 27

Figure 15 Registering as a visiting VoIP user with an LTE terminal, but no record in

the SDB LDAP directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figure 16 Registering as a visiting VoIP user without using an LTE terminal and no

record in the SDB LDAP directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31



6 DN0628538

Issue 8-0-0


Id:0900d805809109f5

List of TablesTable 1 Subscriber values assigned during registration in the absence of LDAP .

19

Table 2 Subscriber registration status in VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . 21



DN0628538

Issue 8-0-0

7

Feature 1673: NVS Registration (Standalone Mode) Feature description

Id:0900d8058094d7c9

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 standalone Nokia Siemens

Networks Mobile VoIP Server (NVS) environments.

SIP clients register over the SIP access interface using the SIP protocol. The NVS

makes use of both the MAP Application Protocol (MAP) and Lightweight Directory

Access Protocol (LDAP) to communicate with the Home Location Register (HLR) and

the SIP Subscriber Database (SDB)—an LDAP directory that stores VoIP subscribers’

SIP-specific data—during the registration process.

Figure 1 NVS registration - protocols

During registration the NVS queries the SDB to obtain the subscriber’s IMSI so that it

[the NVS] can initiate a location update toward the HLR, authenticate the subscriber's

device, and identify the VoIP subscriber's SIP services.

Even though an LDAP solution is preferred alongside the NVS to store VoIP-specific

subscriber data, it is not mandatory: if NVS without LDAP functionality 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 func-

tionality, see section NVS without LDAP .

1.2 Benefits for the operator

The NVS in standalone mode provides services for both fixed and mobile networks.

These services are provided over the SIP Access interface through a converged archi-

tecture. The NVS provides VoIP 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 NVS comes with integrated support for emergency calls as well as other regulatory

requirements such as lawful interception and number portability, based on the same

conventions as GSM/UMTS mobile networks.

UE(SIP client) HLR

(LDAP directory)

SIP

LDAP

MAP

VoIP

MSS

NVS



8 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

The NVS provides functionality that enables VoIP operators to allow VoIP subscribers

without a SIP profile in the SDB LDAP directory to roam inside the operators’ VoIP net-

works. 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 NVS can do so with no extra

costs. For more information about this functionality, see section NVS without LDAP .

The NVS also provides functionality that limits revenue leakage for operators by pre-

venting 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.

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.

NVS without LDAP 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).

1.3.2 Hardware

This feature requires the following network element:

• MSC server (MSS) (MSS)

• Home Location Register (HLR)

• SIP Subscriber Database (SDB) Lightweight Directory Access Protocol (LDAP)

directory

You will also need a SIP Call Processing Unit (SCPU) to run the NVS.

The SCPU should be equipped with at least:

• 1 GB memory

• CP816-A or newer CPU

1.3.3 ProductsThe feature functions in Nokia Siemens Networks MSC Server (MSS) network ele-

ments.

1.4 Functionality

1.4.1 Subscriber data management

The NVS uses a combination of the HLR and LDAP directory to maintain SIP subscriber-

related information. The NVS accesses the HLR to retrieve supplementary service and

IN related information. It then uses the HLR enquiry procedure to find out the VLRaddress, or the MSRN (routing) address, to route terminating SIP or short messages



DN0628538

Issue 8-0-0

9


Id:0900d8058094d7c9

and terminating VoIP or normal voice calls. The NVS accesses the LDAP directory to

obtain the following additional information specific to SIP subscribers:

• IMSI of the subscriber

Used as the key to the HLR database to obtain circuit-switched-related data for thesubscription. It is also used during registration (through the location update proce-

dure) to handle routing within the network in much the same way as in a GSM/UMTS

network.

• SIP Uniform Resource Identifier (URI)

The SIP URI represents the logical name of the subscriber, which is used as the key

in obtaining the E.164 address related to the subscription.

• E.164 address of the subscriber

• Hypertext Transfer/Transport Protocol (HTTP) digest authentication parameters

(user name, password or nonce)

• SIP-specific service data

• Authentication profile ID • Presence server profile ID

• MWI server profile ID

Figure Interfaces toward subscriber information-related databases illustrates both the

MAP and LDAP interfaces of the NVS 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.For more information, see subsection Network elements.

1.4.2 Serving Profile Database (SPD)

The SPD in the MSS is a kind of VLR, with limited functionality, and is located in SCPU-

signaling units. The SPD stores all the SIP user-related data, like the URI, password,

and so on. The SPD is linked to the VLR and contains SIP-related data, while the VLR

stores the standard GSM-related data of the user. When a subscriber registers in the

MSS, the subscriber’s SIP data is downloaded from the LDAP directory and stored in

the SPD. The subscriber’s GSM-related data, which comes from the HLR, is stored in

the VLR. This relational data, though distributed to different units, is nevertheless har-

monized, thus, minimizing data inconsistencies between the SPD and the VLR.



10 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

1.4.3 Registration

1.4.3.1 General concept

SIP UAs register with the home NVS even when they are abroad. This means that SIP-

level roaming is not provided at a system level (when compared with the IMS P-CSCF).

However, IP-level roaming (the use of the same SIP UA over different IP networks) is

supported, making it possible to have, for example, the same E.164 address for mobile-

terminated calls, regardless of the physical IP network. From a functionality point of

view, this means that SIP UAs must have pre-configured AOR information containing

the address of the registrar server—that is, the address of the NVS being used as the

registrar server.

g Inter-SPD registration can only be made if the registrar address is first changed in the

UA.

The registrar address can be one of the following:

• A URI

• A Fully Qualified Domain Name (FQDN), which can be used by the UA to resolve

into a usable IP address through the Domain Name System (DNS)

g If the DNS is used to resolve the IP address for the signaling unit, access to the DNS

server from the SIP UA over the IP layer must be provided. If the DNS resolves the

SBC's address, then the SBC resolves the IP address of the signaling unit of the

MSS.

• An IP address, representing the address of the signaling unit in the MSS

• The address of the SBC, if an SBC is used

The NVS acts as a registrar toward the SIP UA.

g Registrar/Registration functionality is defined in RFC 3261 SIP: Session Initiation Proto-

col .

1.4.3.2 Registration without authentication

The SIP UA sends an initial REGISTER request to the MSS in order to become regis-

tered.

The following figure illustrates the call flows involved when no authentication is per-

formed during initial registration.



DN0628538

Issue 8-0-0

11


Id:0900d8058094d7c9

Figure 3 Registration without authentication

During registration without authentication the NVS performs the following tasks:

• Queries the SDB LDAP directory for the registering party’s VoIP subscription data

• Executes the appropriate MAP operation on the HLR to update the subscriber’s

location information or download the subscriber’s existing location information from

the HLR to the VLR

• Updates the VLR with the subscriber’s data retrieved from the HLR

• Updates the SPD with the subscriber’s SIP data retrieved from the SDB LDAP direc-

toryIf the registering party is a roaming VoIP subscriber from another operator network, the

NVS performs the following additional task:

• assigns the subscriber the basic SIP group profile—see section NVS without LDAP

If the registering party is an LTE subscriber, the NVS may also:

• retrieve the subscriber’s IMSI and CAMEL information from the HLR and execute an

IN attribute analysis to determine the appropriate MAP operation to perform on the

HLR: UpdateLocation or RestoreData—see section Simultaneous registration in

NVS and MSS network elements through a single IMSI

1.4.3.3 Registration with authentication

Subscribers are authenticated according to the HTTP digest scheme, which means that

a user is authenticated when a registration is initiated. To ensure smooth authentication,

the challenge (nonce) value is changed every time. Authenticated events include regis-

tration, re-registration, deregistration, and non-registration-related requests (for

example INVITE, MESSAGE, REFER, PUBLISH, SUBSCRIBE).

GSM-like authentication is not used for subscribers using SIP access if the SIM-based

authentication feature is not activated. For more information on SIM-based authentica-

tion and the supported schemes, see Feature 1863: SIM-based Authentication for NVS

Convergence, Feature Description.

The SIP UA sends an initial REGISTER request to the NVS to become registered. Thefollowing figure illustrates the call flows used for authentication during initial registration.

SIP-UA NVS/SPD NVS/VLR HLR

REGISTER LDAP_Search

(SIP URI)

LDAP_SearchResult

(SIP subscriber data)

LocationUpdate

(IMSI_Attach) MAP_Update-

Location

MAP_Update-

LocationAck

200 OK

LocationUpdateAck

SDB LDAPdirectory



12 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

Figure 4 Registration with authentication

During the registration with authentication process the NVS performs the following

tasks:

• Authenticates the subscriber

• Queries the SDB LDAP directory for the registering party’s VoIP subscription data

• Executes the appropriate MAP operation on the HLR to update the subscriber’s

location information or download the subscriber’s existing location information from

the HLR to the VLR

• Updates the VLR with the subscriber’s data retrieved from the HLR

• Updates the SPD with the subscriber’s SIP data retrieved from the SDB LDAP direc-

tory

If the registering party is a roaming VoIP subscriber from another operator network, the

NVS performs the following additional task: • assigns the subscriber the basic SIP group profile—see section NVS without LDAP

The following steps are also taken when registration is performed with authentication:

The SIP UA registers its AOR under the preconfigured address of the SIP registrar

or outbound proxy—for example, the address of the NVS or the SBC (if an SBC is

used). In the figure, the SIP UA forwards the REGISTER message toward the final

recipient—that is, to the NVS. The Contact address of the SIP UA is stored in the

SPD.

2 The NVS then searches for the received AOR from the SDB LDAP directory. If the

AOR is found, the NVS retrieves the SIP-related information from the subscriber’s

LDAP record. This information includes all of the identities used by the SIP subscrip-tion and HTTP digest authentication-related information. The NVS uses this infor-

SIP-UA NVS/SPD NVS/VLR HLR

REGISTER LDAP_Search

(SIP URI)

LDAP_SearchResult

(SIP subscriber data)

LocationUpdate

(IMSI_Attach)MAP_Update-

Location

MAP_Update-

LocationAck

200 OK

LocationUpdateAck

Authentication

401 Unauthorized

REGISTER

Authentication

SDB/LDAPdirectory



DN0628538

Issue 8-0-0

13


Id:0900d8058094d7c9

mation to authenticate the subscriber's data by sending the appropriate SIP

response to the SIP UA with the relevant authentication-related headers.

g If the NVS without LDAP license is activated in the NVS and the

SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter is set to FALSE , thisstep (step 2) and step 3 are skipped. Instead SIM-based authentication is per-

formed. For more information, see section NVS without LDAP .

3 The SIP UA responds by sending a REGISTER message with the correct HTTP

digest authentication response. This information is then compared with the

response calculated by the NVS based on the information retrieved from the LDAP

directory.

4 If successful, the NVS then initiates a location update. The HLR handles the location

update procedure as per normal—that is, as an event initiated through the location

update event of the GSM or UMTS terminal/subscription.

g If the registering party is an LTE subscriber, the NVS may instead:

• execute a RestoreData MAP operation on the HLR

• retrieve the subscriber’s IMSI and CAMEL information from the HLR and

execute an IN attribute analysis to determine the appropriate MAP operation to

perform on the HLR: UpdateLocation or RestoreData.

For more information, see section Simultaneous registration in NVS and MSS

network elements through a single IMSI .

5 A 200 OK response message is sent by the NVS to the SIP UA that initiated the reg-

istration process. This response indicates that registration has been successful.

1.4.3.4 Re-registration

The SIP UA can re-register to renew the registration’s lifetime or to change some

parameter—for example, the Contact address.

Re-registration means that the user is already registered with the NVS/SPD/VLR.

Figure 5 Re-registration with authentication



14 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

During re-registration, the user is challenged again based on the local policy.

g To eliminate a reply attack, each challenge is used just once.

If the subscriber is an LTE subscriber (see section Simultaneous registration in NVS andMSS network elements through a single IMSI ), the subscriber's existing data in the VLR

is not updated during the location update procedure; only the SPD in Use flag is set to

(T )RUE. The Radio Access Information of the subscriber remains as it was before the

location update.

1.4.3.5 Deregistration, user-initiated

A SIP UA can deregister by sending a SIP REGISTER request and setting the expiry

header to zero or by setting the expiry tag of the Contact tag to zero.

Figure 6 Deregistration

Based on local settings, the user is deleted from the SPD and from the VLR. However,

it is also possible that the user is only set to deregistered and the subscriber’s associ-

ated data only deleted during cleaning.

Deregistration behavior is controlled by the patience time SIP group profile configuration

parameter.

g If the SPD attempts to delete the subscriber's data and the subscriber's radio access

information is SIP, the subscriber's data is removed from the VLR. If the subscriber's

VLR data download type is set to RD, however, (that is, to RestoreData) the VLR does

not execute the PurgeMS MAP operation on the HLR to remove the subscriber's termi-

nal's address information.

If 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 FALSE.

If a 3rd party deregistration request is initiated by the CFX-based SBC (for example,

through the frequent expiry of the re-registration timer or through IP address blocking),

a parameter in the FROM header allows the NVS to differentiate between the different

deregistration requests (coming from the user agent or the SBC).

A request coming from the CFX-based SBC causes the NVS to skip authentication and

release ongoing calls.

NVS/VLR HLR

REGISTER

DeleteSubscriber

200 OK

MAP_PurgeMS

MAP_PurgeMSAck

DeleteSubscriberAck

deletesubscriber

deletesubscriber

SIP UA NVS/SPD



DN0628538

Issue 8-0-0

15


Id:0900d8058094d7c9

1.4.3.6 Deregistration, network initiated

There are two network initiated deregistration cases related to this feature:

1. 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 (see

figure Network-initiated deregistration, user is deleted ) or the subscriber’s registra-

tion state is changed (see figure Network-initiated deregistration, user status is

changed ). If the subscriber’s registration state is changed, the subscriber is

detached in the VLR. These deregistered subscribers are then deleted during the

next cleaning process.

g If the SPD attempts to delete the subscriber's data and the subscriber's radio access

information is SIP, the subscriber's data is removed from the VLR. If the subscriber's

VLR data download type is set to RD, however, (that is, to RestoreData) the VLR

does not execute the PurgeMS MAP operation on the HLR to remove the sub-scriber's terminal's address information.


from the VLR. Instead, the subscriber's User in SPD flag is set to (F )ALSE.

Figure 7 Network-initiated deregistration, user is deleted

Figure 8 Network-initiated deregistration, user status is changed

DeleteSubscriber

MAP_PurgeMSMAP_PurgeMSAck

DeleteSubscriberAck

deletesubscriber

deletesubscriber

timer expiration

NVS/SPD NVS/VLR HLR

DetachSubscriber

DetachSubscriberAck

status:=deregisterred

timer expiration

NVS/SPD NVS/VLR



16 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

2. 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.

Figure 9 Network-initiated deregistration, HLR initiates subscriber de-registra-

tion

g If the subscriber, however, is an LTE subscriber registered in both CS and PS (SIP)

access networks at the same time, the subscriber's data is not removed from the

VLR (nor from the SPD). Instead, the User in SPD flag is set to (T )RUE.

1.4.4 NVS without LDAPThis 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 NVS without investing in an LDAP solution

As such, the NVS supports VoIP subscribers both with and without SIP subscription 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 NVS can support both types of subscriber—thatis, those with and those without SIP data in the SDB. If the prfile parameter is set to

FALSE , then both types of subscriber are treated as though neither have SIP subscriber

data in the SDB.

g If your NVS configuration does not have this prfile parameter, the NVS interprets all VoIP

subscribers as having no SIP subscription data in the SDB LDAP directory. As such, the

NVS assigns all subscribers the default values described in table Subscriber values

assigned during registration in the absence of LDAP .

Both types of subscriber registration are described below:

DeleteSubscriber

MAP_CancelLocation

MAP_CancelLocationAck

DeleteSubscriberAck

deletesubscriber

deletesubscriber

NVS/SPD NVS/VLR HLR



DN0628538

Issue 8-0-0

17


Id:0900d8058094d7c9

Registration

During registration, the NVS first checks to see whether or not the NVS without LDAP

license is activated in the network element that runs the NVS. If it is not, registration

proceeds as per normal for a VoIP subscriber—that is, the NVS queries the SDB LDAPdirectory for the subscriber's IMSI using the SIP-URI value in the registration message,

downloads the SIP subscriber’s data, authenticates the subscriber using the appropriate

authentication mechanism—for example, HTTP Digest—and updates the subscriber's

location in the VLR and HLR. For more information about VoIP registration when this

license is not activated, see section Registration with authentication.

If, on the other hand, the license is activated, the NVS parses the IMSI from the user

part of the subscriber's SIP URI (see section NVS without LDAP restrictions concerning

the format of the SIP-URI), wrapped in the To header of the initial registration message.

If the subscriber's IMSI is not found, the NVS checks the setting of the

SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter. If the parameter is set

to FALSE , the NVS returns a 403 Forbidden message to the SIP user agent—that is,the subscriber's UE or a session border controller acting as a user agent. In this case,

the subscriber's registration is unsuccessful—see figure Unsuccessful registration -

IMSI not found .

Figure 10 Unsuccessful registration - IMSI not found

If, however, the prfile parameter is set to TRUE , the NVS queries the SDB LDAP direc-

tory for the subscriber's SIP data—that is, for the subscriber's IMSI, SIP group profile ID

and authentication ID—and executes the registration process for the VoIP subscriber as

though the NVS without LDAP license was not activated.

REGISTER

SBC NVS

NVS without LDAP license activated?

Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE

parameter set to ?TRUE

No

Derive IMSI fromoT

header

Unsuccessful

403 Forbidden



18 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

Figure 11 Successful registration - LDAP query still possible despite NVS without

LDAP license activation

g For more information about VoIP registration and authentication using the LDAP inter-

face, see section Registration with authentication.

If the subscriber's IMSI is successfully parsed from the To header, the NVS checks the

settings of the SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter. If the

prfile parameter is set to TRUE , the NVS queries the SDB LDAP directory for the sub-

scriber's SIP data and executes the registration process for the VoIP subscriber as

though the NVS without LDAP license was not activated. If, however, the prfile param-

eter is set to FALSE , the NVS uses the following default values to register the sub-

scriber:

REGISTER

200 OK(PAU)

Location update(IMSI)

LocationUpdateAck

SBC NVS VLR HLR


LocationUpdateAck


Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


Yes

Update SPD withCS and SM service

info

Derive IMSI fromoT

header

Unuccessful

SDB/LDAP

LDAP search(SIP-URI)LDAP result(SIP data)

Authentication based on subscriber'sLDAP authentication profile ID

401 Unauthorized

REGISTER

Authenticationsuccessful?

Yes



DN0628538

Issue 8-0-0

19


Id:0900d8058094d7c9

These values determine the available SIP services for the subscriber (determined by the

default SIP group profile ID), the available presence and message summary services

(determined by the default Presence server ID and the MWI server ID, respectively), and

the authorization procedure to use (determined by the default Authorization profile ID).

gEach of these default values can be assigned a particular configuration. To learn how todo this, see sections SIP group profile, SIP authentication profile, and Testing the MWI

server subscription when NVS without LDAP functionality is enabled in Feature 1673:

NVS Registration (Standalone mode), Feature Activation Manual . More information on

presence and message summary services can be found in Feature 1883: Presence and

Message Summary Services in NVS. The process and commands for creating configu-

rations for MWI servers and Presence servers is the same. However, the default values

for both servers are different. The default value for the MWI server ID is 1, whereas the

default value for the Presence server ID is 0 .

SIM-based authentication is always used as the means to authenticate VoIP subscriber

devices when it is not possible to query the SDB LDAP directory for the subscriber’s

authorization profile ID. For information on how to assign an authentication type to anauthentication profile ID, see section SIP authentication profile in both Feature 1673:

NVS Registration (Standalone Mode) and Feature 1863: SIM-based authentication for

NVS Convergence feature activation manuals. For a detailed description of SIM-based

authentication methods, see the Feature 1863: SIM-based authentication for NVS Con-

vergence feature description.

Figure Successful registration in the absence of LDAP illustrates this successful regis-

tration procedure.

Description Value

SIP group profile ID 0 or route category

Authentication profile ID 0

Presence server ID 0

MWI server ID 1 or route category

Table 1 Subscriber values assigned during registration in the absence of LDAP



20 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

Figure 12 Successful registration in the absence of LDAP

It is possible to provide the subscriber with a more flexible SIP group profile and/or MWI

server profile configuration. You can do this by instructing the NVS to use the value of

the subscriber's routing category (stored in the subscriber’s HLR record) as a SIP group

profile ID and/or MWI server ID, instead of using the default settings. To do this, set the

USE_RC_AS_PROFILE (052:0090) prfile parameter appropriately—see the

USE_RC_AS_PROFILE parameter description in section Parameters for information on

possible settings. However, if you choose to do this, you must make sure that a SIP

group profile and/or an MWI server profile already exists with these ID values in the

NVS.

At the end of each successful registration process, the NVS returns a200 OK message,

together with the subscriber's SIP URI, wrapped in the message's P-Associated-Uri

header.

1.4.5 Simultaneous registration in NVS and MSS network elements

through a single IMSI

Long Term Evolution (LTE) terminals can be simultaneously connected to CS and VoIP

networks. This is problematic, since each subscriber's record in the HLR can accept only

one MSS/VLR address. Therefore, care must be taken when registering with a VoIP

REGISTER

200 OK(PAU)


LocationUpdateAck

SBC NVS VLR HLR


LocationUpdateAck

includes MSISDNand routing

category

Execute SIM-based authentication, in accordance with the defaultauthentication profile configuration setting


Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


No


info

Derive IMSI fromoT

header

Successful



DN0628538

Issue 8-0-0

21


Id:0900d8058094d7c9

network so that the MSS/VLR address in the HLR, used by the CS network, is not over-

written.

As a solution to this problem, Nokia Siemens Networks has introduced an update to the

NVS Registration feature, controlled by a new license named Restore data for SIP reg-istration. The aim of this update 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 appro-

priate 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 SPD

The 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 access network, the NVS downloads his/her sub-

scription 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 updates

CS 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

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 notlisted in the VLR before the location update, the User in SPD flag is set to (T )RUE.

User in SPD Radio Access Information Registration status

T SIP SIP only

F GSM/UMTS CS only

T LTE SIP and CS

Table 2 Subscriber registration status in VLR



22 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

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.

• CancelLocation

If the subscriber is registered in either CS access or SIP access (but not both at thesame time), the subscriber's record is deleted from the VLR as per usual, or placed

in passive state if the Supercarger 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 deletion


from the VLR. Instead, the subscriber's User in SPD flag is set to (F )ALSE.

VLR Data Download Type

The 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 MSS/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 NVS then performs a service attribute analysis

on the subscriber’s T-CSI information to determine the appropriate 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:

NVS subscribers with LTE terminals capable of being registered in circuit

switched and packet switched networks at the same time.RD

NVS subscribers with terminals incapable of being registered in CS and PS-

based networks at the same timeUL

Visiting VoIP subscribers from other operator networks without access to

LDAP TCSI



DN0628538

Issue 8-0-0

23


Id:0900d8058094d7c9

This solution introduces a slight change to the NVS registration procedure. This change

will now be described, after which, four use cases will be given that demonstrate the reg-

istration procedure for:

• NVS subscribers with LTE terminals

• NVS subscribers without LTE terminals

• Visiting VoIP users with LTE terminals but no record in the SDB LDAP directory

• Visiting VoIP users without LTE terminals and no record in the SDB LDAP directory

All license activation and feature configure instructions can be found in section Activat-

ing Simultaneous registration functionality in NVS and MSS network elements through

a single IMSI in the Feature 1673: NVS Registration (Standalone Mode) feature activa-

tion manual.

1.4.5.1 Registration

Upon receipt of an initial SIP registration request—either directly, from the subscriber's

device, or indirectly, through a session border controller acting as a SIP user agent—the

NVS checks the status of the NVS without LDAP ON/OFF license. The NVS then

performs registration according to whether or not the license is ON or OFF as described

in the two subsections that follow.

g More information on NVS without LDAP functionality can be found in section NVS

without LDAP . Instructions on activating this license are given in the Feature 1673: NVS

Registration (Standalone Mode) feature activation manual.

NVS without LDAP license is ON

If the NVS without LDAP license is ON, the NVS tries to parse the IMSI from the userpart of the SIP-URI, wrapped in the To header of the registration request.

If successful:

The NVS queries the SPD for the subscriber's SIP group profile ID and authentica-

tion profile ID, using the IMSI—parsed from the To header—as a key. If the sub-

scriber's record is not found in the SPD, the NVS checks the setting of the

SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter. If the parameter is

set to TRUE , the NVS queries the SDB LDAP directory for the same information,

using either the SIP URI or the IMSI value, parsed from the To header.

g If the IMSI is used to query the SDB LDAP directory, the query looks for the IMSI in

both the SDB LDAP mssIMSI and mssCSIMSI fields since NVS subscribers withUSIM-based HSPA/LTE modem dongles or combined CS/VoIP handsets have both

a VoIP IMSI value, stored in mssIMSI, and a CS-IMSI (or SIM-IMSI) value, stored

in mssCSIMSI. Such devices require a different registration procedure. For more

information, see section Shared USIM support for cellular and SIP authentication in

the Feature 1863: SIM-based Authentication for NVS Convergence feature descrip-

tion.

If the prfile parameter is set to FALSE , the NVS assigns the subscriber the default

SIP group profile ID and authentication profile ID, listed in table Subscriber values

assigned during registration in the absence of LDAP .



24 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

The NVS uses the SIP group profile ID to determine the VLRDLTYPE parameter

value (that is, the appropriate MAP operation to perform on the HLR) and the

authentication profile ID to determine how to authenticate the subscriber's device.

2 The NVS then checks the status of the Restore data for SIP registration ON/OFFlicense.

If this license is ON, the NVS reads the VLRDLTYPE to determine the appropriate

MAP operation to perform on the HLR: UpdateLocation or RestoreData. See the full

list of possible values.

If the license is OFF, the NVS always performs the UpdateLocation MAP operation

on the HLR.

3 The NVS authenticates the device using the authentication method determined by

the Authentication profile ID. In the case of NVS subscribers, this is usually HTTP

digest but SIM-based authentication is also an alternative. In the case of visiting

VoIP users from other operator networks SIM-based authentication is used.

g SIM-based authentication is always used as the means to authenticate VoIP sub-

scriber devices when it is not possible to query the SDB LDAP directory for the sub-

scriber’s authorization profile ID. For information on how to assign an authentication

type to an authentication profile ID, see section SIP authentication profile in both

Feature 1673: NVS Registration (Standalone Mode) and Feature 1863: SIM-based

authentication for NVS Convergence feature activation manuals. For a detailed

description of SIM-based authentication methods, see the Feature 1863: SIM-based

authentication for NVS Convergence feature description.

4 After successful authentication the NVS performs the appropriate MAP procedure

on the HLR, as indicated by the value of the VLRDLTYPE parameter in the sub-

scriber’s assigned SIP group profile.

If unsuccessful:

The NVS queries the SPD for the subscriber's IMSI, SIP group profile ID, and authenti-

cation ID using the SIP-URI, passed in the To header of the request. If the subscriber's

record is not found in the SPD, the NVS checks the setting of the

SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter. If it is set to TRUE , the

NVS queries the SDB LDAP directory, again using the SIP-URI, to retrieve the sub-

scriber's IMSI, SIP group profile ID and authentication ID. If successful, the NVS contin-

ues to register the device in accordance with steps 2-4 above.

If, however, the prfile parameter is set to FALSE , the NVS returns a 403 Forbidden error

message to the subscriber's terminal. At this point, the registration request stops beingprocessed—registration is unsuccessful. See figure Unsuccessful registration - IMSI not

found .

NVS without LDAP license OFF

If the NVS without LDAP license is OFF, the NVS performs registration of the sub-

scriber’s device in accordance with the process described in section Registration with

authentication, with one important difference: the NVS also checks the status of the

Restore data for SIP registration ON/OFF license. If the license is ON, the NVS reads

the VLRDLTYPE to determine the appropriate MAP operation to perform on the HLR:

UpdateLocation or RestoreData (see the full list of possible values). However, if the

license is OFF, the NVS always performs the UpdateLocation MAP operation.

Once the appropriate MAP operation to perform is known, the NVS:



DN0628538

Issue 8-0-0

25


Id:0900d8058094d7c9

1. authenticates the device using the authentication method determined by the

Authentication profile ID;

g Since the NVS without LDAP license is OFF, the authentication method used is

HTTP digest.

2. performs the appropriate MAP procedure on the HLR (after the successful authen-

tication of the device), as indicated by the value of the VLRDLTYPE parameter in the

subscriber’s assigned SIP group profile.

3. updates the VLR as appropriate

1.4.5.2 Registering as an NVS subscriber using an LTE terminal

An NVS subscriber attempts to register with an NVS network.

The NVS checks the status of the NVS without LDAP license. In this case the license is

ON and the SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter is set to

TRUE . The NVS retrieves the subscriber's SIP group profile ID and Authentication

profile ID from the SDB LDAP directory (using the subscriber’s SIP URI) after an unsuc-

cessful search in the SPD.

Since the NVS subscriber has an LTE terminal, the VLRDLTYPE parameter, in the sub-

scriber's SIP group profile, is set to RD.

The NVS authenticates the subscriber's device using HTTP digest. The authentication

procedure is successful. The NVS then performs 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 VLR.



26 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

Figure 13 Registering as an NVS subscriber using an LTE terminal

1.4.5.3 Registering as an NVS subscriber without an LTE terminal

An NVS subscriber attempts to register with an NVS network.

The NVS checks the status of the NVS without LDAP license. In this case the license is

ON and the SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter is set to

TRUE . The NVS retrieves the subscriber's SIP group profile ID and Authentication

profile ID from the SDB LDAP directory (using the subscriber’s SIP URI) after an unsuc-

cessful search in the SPD.

REGISTER

200 OK(PAU)

SIP UA NVS VLR HLR

NVS without LDAP license ON?

Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


Yes

Update SPD withMSISDN#, CS and

SM service info

Derive IMSI fromoT header

Unsuccessful

SDB/LDAP

LDAP search(SIP-URI)

LDAP result(SIP data)

401 Unauthorized (challenge)

REGISTER(challenge resp.)


Yes

Subscriber data download type in VLR is RD Authentication type is HTTP digest

Restore data for SIP registrationlicense ON?

Yes

Yes

ISD(MSISDN# services)

RestoreData(IMSI)

RestoreDataAck

RestoreData(IMSI)

RestoreDataAck



DN0628538

Issue 8-0-0

27


Id:0900d8058094d7c9

Since the NVS subscriber does not have an LTE terminal, the VLRDLTYPE, in the sub-

scriber's SIP group profile, is set to UL.

The NVS authenticates the subscriber's device using HTTP digest. The authentication

procedure is successful. The NVS then performs an UpdateLocation MAP operationon the HLR to update the subscriber's record in the HLR with the new NVS/VLR

address.

Figure 14 Registering as an NVS subscriber without an LTE terminal

REGISTER

200 OK(PAU)

SIP UA NVS VLR HLR


Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


Yes


info

Derive IMSI from

oT header

Unsuccessful

SDB/LDAP

LDAP search(SIP-URI)

LDAP result(SIP data)

401 Unauthorized (challenge)

REGISTER(challenge resp.)


Yes

Subscriber data download type in VLR is UL Authentication type is H TTP digest


Yes

Yes

ISD(subscriber data)

UpdateLocation(IMSI)

UpdateLocationAck


UpdateLocationAck



28 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

1.4.5.4 Registering as a visiting VoIP user with an LTE terminal, but no

record in the SDB LDAP directory

A visiting VoIP subscriber attempts to register with an NVS network.

The NVS checks the status of the NVS without LDAP license. In this case, the license

is ON and the SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter is set to

FALSE . As a result, the NVS assigns the default SIP group profile ID and authentication

profile ID to the subscriber, listed in table Subscriber values assigned during registration

in the absence of LDAP .

The NVS then checks the status of the Restore data for SIP registration license. In this

case, this license is also ON.

The VLRDLTYPE parameter, in the subscriber's SIP group profile, is set to TCSI . The

NVS, therefore, analyses the subscriber's TCSI information, provisioned in the sub-

scriber's HLR record, to determine whether or not an UpdateLocation or RestoreData

MAP operation should be performed. Since the subscriber has an LTE terminal capable

of being simultaneously registered in PS and CS networks, a RestoreData MAP opera-

tion is performed. However, this MAP operation is only performed after the successful

authentication of the subscriber's device.

The NVS uses the default authentication profile to determine how to authenticate the

subscriber's device. As such, SIM-based authentication is used.

After successful authentication, the NVS performs 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 VLR.



DN0628538

Issue 8-0-0

29


Id:0900d8058094d7c9

Figure 15 Registering as a visiting VoIP user with an LTE terminal, but no record in

the SDB LDAP directory

1.4.5.5 Registering as a visiting VoIP user without using an LTE terminal

and no record in the SDB LDAP directory

A visiting VoIP subscriber attempts to register with an NVS network.

The NVS checks the status of the NVS without LDAP license. In this case, the license

is ON and the SIP_USE_LDAP_IF_LDAPLES (052:0095) prfile parameter is set to

FALSE . As a result, the NVS assigns the default SIP group profile ID and authentication

REGISTER

200 OK

RestoreData(IMSI)

ISD(MSISDN# services)

RestoredataAck

ATSI(IMSI/CSI)

ATSI Result (T-CSI)

SIP UA NVS/VLR HLR/AuC

SIM-based authentication


Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


No


Successful

Yes


Yes

Subscriber data download type in VLR is TCSI Authentication type is Sim-based

Analysis result shows that a RestoreDatais required

Perform IN/service attributeanalysis with T-CSI

Update VLR withMSISDN#, CS and

SM service info

Successful



30 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

profile ID to the subscriber, listed in table Subscriber values assigned during registration

in the absence of LDAP .

The NVS then checks the status of the Restore data for SIP registration license. In this

case, this license is also ON.The VLRDLTYPE parameter, in the subscriber's SIP group profile, is set to TCSI . The

NVS, therefore, analyses the subscriber's TCSI information, provisioned in the sub-

scriber's HLR record, to determine whether or not an UpdateLocation or RestoreData

MAP operation should be performed. Since the subscriber does not have an LTE

terminal capable of being simultaneously registered in PS and CS networks, an Update-

Location MAP operation is performed. However, this MAP operation is only performed

after the successful authentication of the subscriber's device.

The NVS uses the default authentication profile to determine how to authenticate the

subscriber's device. As such, SIM-based authentication is used.

After successful authentication, the NVS performs an UpdateLocation 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 VLR.



DN0628538

Issue 8-0-0

31


Id:0900d8058094d7c9

Figure 16 Registering as a visiting VoIP user without using an LTE terminal and no

record in the SDB LDAP directory

1.4.5.6 Subscription data modification notification

An LTE subscriber’s VLR record is updated whenever his/her supplementary service

data is modified in the HLR through MMI, facility codes or XCAP PUT and DELETE

requests.

g For more information on MMI, facility codes, or XCAP, see Feature 1741: Control of

Supplementary Services in NVS or Feature 1979: Ut/XCAP interface Support in NVS,

as appropriate.

REGISTER

200 OK


ISD(subscriber data)

UpdateLocationAck

ATSI(IMSI/CSI)

ATSI Result (T-CSI)

SIM-based authentication


Yes

SIP_USE_LDAP

_IF_LDAPLES PRFILE


No


Successful

Yes


Yes

Subscriber data download type in VLR is TCSI Authentication type is Sim-based

Analysis result shows that an UpdateLocationis required

Perform IN/service attributeanalysis with T-CSI

Update VLR withCS and

SM service info

SIP UA NVS/VLR HLR/AuC

Successful



32 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

The HLR sends a NoteSubscriberDataModified MAP message to the NVS. The NVS

searches for the subscriber in the VLR using the subscriber’s IMSI. If the subscriber is

found, and the SCP address configured in the HLR points to the serving (that is, homing)

NVS, then one of two things may occur:

• If the subscriber is only registered on the SIP access side, the subscriber’s VLR

record is updated.

• If the subscriber is not SIP registered, the VLR is not updated since an InsertSub-

scriberData message will be sent directly to the VLR from the HLR.

If the subscriber is found, but the configured NVS address differs from the serving NVS

address, the notification is forwarded to the appropriate NVS.

If, on the other hand, the subscriber is not found in the VLR, no update is performed.

1.4.6 NVS concurrent login prevention

The NVS provides the means to prevent concurrent logins from initial requests that aremade from different locations—for example, when a subscriber logged in to the VoIP

service from one PC tries to concurrently log in from another PC. The NVS prevents con-

current logins by storing the subscriber’s device’s IP address in the SPD during regis-

tration. The IP addresses contained in INVITE/MESSAGE/PUBLISH/SUBSCRIBE

requests are checked against this stored IP address. If the addresses match, the

requests are accepted; if not, the requests are rejected.

If a REGISTER request is made, however, and the IP address contained in the request

differs from the IP address contained in the SPD, the SPD is updated with the IP address

contained in the request.

gThe terminal’s IP address is taken from the Via header’s Sent by or Received field.

However, if the Via header contains an FQDN rather than an IP address, the terminal’s

IP address cannot be taken from the header.

1.4.7 Files

There are no files directly visible to the operator.

1.4.8 Statistics

Statistics functionality is included in Feature 1696: NVS Statistics, Feature Description.

1.4.9 Parameters

NVS-specific parameters

• MSC_VOIP_SUPPORT (002:1078)

This FIFILE parameter controls the NVS by activating and deactivating NVS stand-

alone mode. If this parameter is enabled, the NVS accepts SIP messages on its

Normal Access and Normal Network interfaces.

g The MSC_VOIP_SUPPORT and the MSC_AS_VOIP_SUPPORT (002:1089) FIFILE

parameters, and the functionalities related to them, 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.



DN0628538

Issue 8-0-0

33


Id:0900d8058094d7c9

• 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 NVS. If not, the User

Datagram Protocol (UDP) is used.

• NVS_TERMINAL_IP_CHECK (052:0097)

This prfile parameter controls whether or not the NVS should store the IP address

of the device that the subscriber uses to connect to the VoIP service during registra-

tion. 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.

• FALSE

The subscriber device’s IP address is not stored in the SPD and no checking is

performed on initial requests.

• SIP_ACCESS_SBC_TYPE (052:0088)

This prfile parameter is used to define the type of SBC on the normal access inter-

face. There are two values to choose from:

0 General SBC or no SBC is connected to the normal access inter-

face.

1 CFX-based SBC is connected to the normal access interface.

• SIP_ALLOWED_IMPREG_TYPE (052:0070)

This prfile parameter is used to select the SIP implicit registration type. There arefour 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



34 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

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_USE_LDAP_IF_LDAPLES (052:0095)

This prfile parameter is used to control whether or not NVS executes LDAP queries,even if NVS without LDAP functionality is active. If the parameter is set to TRUE , the

NVS reads the subscriber’s data from the LDAP directory. If there is no LDAP entry

for the subscriber, the NVS serves the subscriber in accordance with NVS without

LDAP functionality.

If the parameter is set to FALSE , the NVS serves the subscriber in accordance with

NVS without LDAP functionality.

• TCP_ACTIVATED_ON_ACC_IF (052:0047)

Using this parameter the operator can control whether or not to use TCP on the SIP

Access interface of NVS for SIP requests. This parameter is set only in case the

MSC_VOIP_TCP_SUPP FIFILE parameter is activated.



DN0628538

Issue 8-0-0

35


Id:0900d8058094d7c9

• USE_RC_AS_PROFILE (052:0090)

This prfile parameter instructs the NVS 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 NVS without LDAP functionality is active.Possible values:

000B The SIP group profi le 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 .


MWI server ID and the MP ID. The subscriber's SIP group profile ID

is set to its default value—that is, to 0 .


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.

Common SIP prfile parameters (commonly used with SIP-I and SIP-T trunk) • 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.



36 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

• 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 senta 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 Charging

See Feature 1703: NVS Charging, Feature Description.

1.4.11 Transport

TCP support

TCP is supported in the NVS and can be enabled or disabled with the

MSC_VOIP_TCP_SUPP (002:1219) FIFILE parameter. If activated, TCP can be switched

on or off using prfile parameters.

In standalone mode, TCP can be activated or deactivated separately for the Normal

Access (public) interface using the TCP_ACTIVATED_ON_ACC_IF (052:0047) prfile

parameter.

SCTP support



DN0628538

Issue 8-0-0

37


Id:0900d8058094d7c9

Support of SIP over SCTP in the context of NVS registration in standalone mode means

support for SCTP on the Normal Access interface if there is a network element between

the NVS and the SIP subscriber (for example, an SBC).

1.5 Capacity

One entry from the given VLR or SIP registrar (MSS) must be available for reservation

if the division of individual subscribers is planned during the provisioning phase. Other-

wise, it is not possible for a subscriber having a SIP UA to obtain any services from the

network.

In the case of provisioning subscribers to individual MSSs, the number of GSM and

UMTS subscribers must also be considered.

According to the M13 time frame, the maximum capacity of a single MSS is 1 million

subscribers (which is also the limit placed on VLR capacity), regardless of subscriber

type (SIP, UMTS or GSM only).When the same MSS network element is handling GSM, UMTS and SIP traffic, all sub-

scribers use the same VLR space. Therefore, the operator needs to estimate the

number of SIP subscribers that need to be served by a single MSS in order to calculate

the VLR space to be used for GSM and UMTS traffic. If the MSS is already in use, the

number of SIP subscribers needs to be measured together with the existing division of

GSM and UMTS traffic.

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 NVS 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.

• The maximum size of an accepted SIP messages is 8 kilobytes.

• 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.

• There can be no more than 50 authentication profiles.

• The NVS does not use the Sh interface.

• The Reg-Event package is not supported by the NVS.

NVS without LDAP restrictions

If 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.

• HTTP-Digest authentication is not supported.

• Un-solicited MWI notifications using sip:<number>@<domain> formatted URIs arenot supported.



38 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

1.7 Related and interworking features

This 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 the 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 MSC

Server (MSS) features and implements the Media Gateway Control Function

(MGCF) in the MSS. Between MSSs both SIPT [Internet Engineering Task Force(IETF)] and SIP-I [International Telecommunications Union (ITU-T)] can be used.

In the case of SIP-T, Integrated Services User Part (ISUP) tunneling can also be

switched off, but it is not advised since the ISUP feature’s transparency can be lost.

• 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 mobilestations 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 NVS.

Statistical functions for the NVS are provided through the extension of several mea-surements and observations that already exist in the MSS network elements, and by

introducing new measurements and observations that provide NVS-specific infor-

mation.

• 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 NVS Application Server (AS) and

other possible IP Multimedia Systems (IMSs) in cases where the user or usage is

related or interfaced with the CS network through SIP.

• Feature 1760: NVS Messaging

This feature provides Instant Messaging (IM) functionality to the MSS and enables

the handling of SIP User Agent (UA) originated and terminated messages as well as



DN0628538

Issue 8-0-0

39


Id:0900d8058094d7c9

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 NVS

without LDAP 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 Mobile VoIP Server (NVS) environ-

ments. This feature is relevant to the MSS and control plane signaling, since the

MGW already supports the concept of multiple isolated IP networks for the user

plane.

• Feature 1990: SCC AS in NVS (Standalone Mode)

This feature enables an ongoing session to be transferred across different access

networks. It also provides homing and Terminating Access Domain Selection (T-

ADS) functionality that enables the call to be homed to the appropriate NVS for

further processing and routing to the called party over the appropriate access

domain.

1.8 Compliance

This 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 SIP 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 Group

Using the commands of this command group it is possible to configure and interrogate

SDB client configurations.



40 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

• JDM - CREATE OR MODIFY DIRECTORY SERVER CONFIGURATION

• JDI - 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:0096) 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 NVS

related function that requires LDAP is enabled), these commands remain visible,

regardless of the activation status of the NVS without LDAP license.

For more information on configuring LDAP directories and LDAP servers, 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.

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 NVS 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 MSS/VLR

address. Nokia Siemens Networks recommends setting this parameter to UL for

all NVS subscribers who do not have LTE terminals capable of being simultane-ously registered in PS and CS networks.

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 NVS sub-

scribers who have LTE terminals capable of being simultaneously registered in

PS and CS networks.

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.



DN0628538

Issue 8-0-0

41


Id:0900d8058094d7c9

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.

gThe VLRDLTYPE parameter is visible in printouts as SUBSCRIBER DATA DL TYPEIN 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.

NVS Address Configuration Handling, JI Command Group

The following commands of this command group are used to configure the listening

points of each signaling unit, the server addresses used in the NVS, VLR address res-

olution, and the mapping of the locationID to CGI.

• JII - INTERROGATE SIP ADDRESSES

Use this command to interrogate SIP listening points.

• JIM - CREATE AND MODIFY SIP ADDRESS

Use this command to create and modify SIP listening points.

• JIO - REMOVE SIP ADDRESSES

Use this command to remove SIP listening points.

• JIS - ADD LOCATION ID MAPPING

Use this command to add a location ID entry.

• JIR - DELETE LOCATION ID MAPPING

Use this command to delete a location ID entry.

• JIT - QUERY LOCATION ID MAPPING

Use 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 NVS 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.



42 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

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.

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.

1.9.2 Alarms

2397 DATABASE FILE IS IN DANGER TO GET FULL

This alarm is set by the SPD. It is raised (only at 1:30 a.m.) when the upper alarm l imit

of the database file fill ratio (95%) has been exceeded.

Alarm class: two star alarm

1.10 Subscriber interfaces

The feature enables SIP users to register in the NVS through third-party registration.

Network elements

• MSS

The SIP registrar functionality is implemented in the MSS.

• HLR/HLRi

The HLR has the information that is dynamically updated every time the subscriber

registers in the MSS System. The 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 mes-

sages, as well as terminating VoIP or normal voice calls, when required. This

solution does not cause any new requirements for the HLR network element.



DN0628538

Issue 8-0-0

43


Id:0900d8058094d7c9

• SDB/LDAP server

External LDAP server is used to store and return static SIP specific data of the sub-

scribers using the new SIP Access interfaces of the NVS.

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 MSS/NVS. The client processes are located in the signalling units of

the MSS/NVS.

The MSS/NVS 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 isan 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.

1.11 External interfaces

• SIP

The SIP Normal Access and SIP Normal Network interfaces are used in the MSS.

The SIP Normal Access interface is a non-trusted interface, which typically resides

on the public network. This interface is used to communicate with access-type

devices, such as SIP Soft Phones, Access Gateways, Analog Telephone Adapters(ATA), and Intelligent Access Devices (IAD).

The SIP Normal Network interface is a trusted interface, which is used to communi-

cate with other network elements, such as soft switches, SIP Proxies, and SIP

Network Servers.

These interfaces are compliant with both RFC 3261, SIP: Session Initiation Protocol

and 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2 .

• MAP

This solution does not cause any new requirements for the MAP interface if no Nokia

Siemens Networks specific features, such as MultiSIM, are used.



44 DN0628538

Issue 8-0-0


Id:0900d8058094d7c9

Feature description

• LDAP

The LDAP interface is used toward the external SIP Subscriber Database (SDB)

(LDAP directory).

When the NVS without LDAP license is activated and theSIP_USE_LDAP_IF_LDAPLES (052:0096) prfile parameter is set to FALSE , the

NVS 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.



DN0628538

Issue 8-0-0

45

Feature 1673: NVS Registration (Standalone Mode) Main changes in Feature 1673: NVS Registration(Standalone Mode)

Id:0900d8058094a224

Main changes in Feature 1673: NVS Registra-

tion (Standalone Mode)

Changes in the feature

Changes in the feature between releases M16.1 and M15.1

Simultaneous 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.


Functionality 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.


A parameter is introduced to handle the deregistration requests from the CFX based

Session Border Controller (SBC).

The functionality of NVS operation without LDAP has been introduced.


Due to feature 1883, the Presence Server Profile ID and MWI Server Profile ID have

been introduced for subscriber data management.

In case of registration with authentication, authenticated events include also non-regis-

tration-related requests (such as INVITE, MESSAGE, REFER, PUBLISH, SUB-SCRIBE).


With the introduction of feature 1863, SIM-based authentication is also possible. This

affects registrations with authentication.


• 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.

Changes in the document

Changes made between issues 8-0-0 and 7-0-1

The following section has been added:

• Simultaneous registration in NVS and MSS network elements through a single IMSI

The following sections have been updated:

• Registration

• Requirements for using the feature

• Related and interworking features

• Compliance

• MMLs



46 DN0628538

Issue 8-0-0


Id:0900d8058094a224

Main changes in Feature 1673: NVS Registration(Standalone Mode)


Editorial updates have been made to section NVS without LDAP functionality.


The following sections have been updated:

• NVS-specific parameters

VOIP_SCTP_ON_SIP_ACCESS (052:0071) PRFILE parameter has been

removed.

• MMLs

• Subscriber interfaces

• External interfaces


A 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) PRFILEparameter in section Common SIP PRFILE parameters (commonly used with SIP-I and

SIP-T trunk).

Changes made between issues 6-0-0 and 5-1

The 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 section has been added to section Functionality :

• NVS concurrent login prevention

Changes made between issues 5-1 and 5-0

The following sections and subsections have been updated to incorporate information

on the functionality of NVS operation without LDAP.

• Introduction

• Benefits for the operator

• Registration without authentication and Registration with authentication

• SCTP suppor t 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.



Feature 1673: NVS Registration (Standalone Mode) Main changes in Feature 1673: NVS Registration(Standalone Mode)


The Registration and Parameters sections of the chapter Functionality have been

updated to incorporate the changes for 3rd party deregistration requests from the CFX

based SBC.Changes made between issues 4-1 and 4-0

Editorial changes have been made.


The following changes have been made:

• The company and product names have been changed according to the official Nokia

Siemens Networks portfolio naming.

• Presence Server Profile ID and MWI Server Profile ID have been added to section

Subscriber data management .

• Non-registration-related requests (for exampleINVITE, MESSAGE, REFER,

PUBLISH, SUBSCRIBE) have been added to section Registration with authentica-tion.

• Feature 1883 has been added to section Related and interworking features.


The following changes have been made:

• In Section Subscriber data management :

Authentication Profile ID has been added to the listed LDAP directory information

elements.

• In Section Registration with authentication:

Information about SIM-based authentication (feature 1863) has been added.

• In Section Related and interworking features:Feature 1863: SIM-based Authentication for NVS Convergence has been listed.

• In Section MMLs:

The description of the JO command group has been modified and the JOA command

has been deleted. The JHE, JHO, JHU, and JHT commands have been added.

feature 1673 - nvs registration (standalone mode)

Documents

feature documentation

software products

additional information

environmental services

product names

product packaging

mentioned hardware

power use