Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-282 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Private User Mobility (PUM) - Registration supplementary service (QSIG-PUMR) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational exchange integrated inter mobility network pisn

ecma, standard, ecma international, specification, ecma-282, ecma 282, 282, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, user, mobility, pum, registration, supplementary, service, qsig-pumr

S tandard ECMA-282

3rd Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Private User Mobility (PUM) Registration Supplementary Service

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]

S tandard ECMA-282

3rd Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Private User Mobility (PUM) Registration Supplementary Service (QSIG-PUMR)

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW

Ecma-282.doc

14-01-02 10,29

Brief History

This Standard is one of a series of standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of standards for Open Systems Interconnection as defined by ISO/IEC. This Standard specifies the signalling protocol for use at the Q reference point in support of the Private User Mobility Registration supplementary service. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 1st Edition of Standard ECMA-282 (published by ECMA in December 1998), the 2nd Edition incorporated changes to achieve complete alignment with International Standard ISO/IEC 17876:2000(E) published by ISO/IEC in April 2000. Compared to the 2nd edition of Standard ECMA-282 (published by ECMA in June 2000), this 3rd Edition incorporates migration to ASN.1 Version 1997.

Adopted as 3rd Edition of Standard ECMA-282 by the General Assembly of December 2001.

- i -

Table of contents 1

Scope

Conformance

References (normative)

Definitions E x te r n a l d e f in itio n s R e mo t e P I N X Previous Visitor PINX Alternative identifier Activating user

2 2 3 3 3 3

List of acronyms

4 4.1 4.2 4.3 4.4 4.5 5 6

Signalling protocol for the support of SS-PUMR 6 . 1 S S - P U MR d e s c r ip tio n 6 . 2 S S - P U MR o p e r a tio n a l r e q u ir e me n ts 6.2.1 Re q u ir e me n ts o n th e V is ito r P I N X 6.2.2 Re q u ir e me n ts o n th e H o me P I N X 6.2.3 Re q u ir e me n ts o n th e P r e v io u s V is ito r P I N X 6.2.4 Re q u ir e me n ts o n a T r a n s it P I N X 6.2.5 Re q u ir e me n ts o n th e D ir e c to r y P I N X 6.2.6 Re q u ir e me n ts o n th e Re mo te P I N X 6 . 3 S S - P U MR c o d in g r e q u ir e me n ts 6.3.1 Operations 6.3.2 I n f o r ma t i o n e l e me n t s 6.3.3 Messages 6 . 4 S S - P U MR s ta te d e f in itio n s 6.4.1 States at the Visitor PINX 6.4.2 S t a t e s a t t h e H o me P I N X 6.4.3 States at the Directory PINX 6.4.4 States at the Previous Visitor PINX 6.4.5 S t a t e s a t t h e R e mo t e P I N X 6 . 5 S S - P U MR s ig n a llin g p r o c e d u r e s f o r r e g is tr a tio n 6.5.1 Actions at the Visitor PINX for registration 6.5.2 A d d i t i o n a l a c t i o n s a t t h e V i s i t o r P I N X i n c a s e o f r e mo t e r e g is t r a t i o n 6.5.3 A c tio n s a t th e H o me P I N X f o r r e g is tr a tio n 6.5.4 A c tio n s a t a T r a n s it P I N X f o r r e g is tr a tio n 6.5.5 A c tio n s a t th e p r e v io u s V is ito r P I N X f o r r e g is tr a tio n 6.5.6 A c tio n s a t th e Re mo te P I N X f o r r e g is tr a tio n 6 . 6 S S - P U MR s ig n a llin g p r o c e d u r e s f o r d e - r e g is tr a tio n 6.6.1 A c tio n s a t th e V is ito r P I N X f o r d e - r e g is tr a tio n

4 4 4 4 4 4 4 4 4 5 5 9 9 9 9 10 10 10 10 10 10 11 12 13 13 13 14 14

- ii -

6.6.2 A c tio n s a t th e H o me P I N X f o r d e - r e g is tr a tio n 6.6.3 A c tio n s a t a T r a n s it P I N X f o r d e - r e g is tr a tio n 6.6.4 A c tio n s a t th e Re mo te P I N X f o r d e - r e g is tr a tio n 6 . 7 S S - P U MR s ig n a llin g p r o c e d u r e s f o r in te r r o g a tio n 6.7.1 Actions at the Visitor PINX for interrogation 6.7.2 A c tio n s a t th e H o me P I N X f o r in te r r o g a tio n 6.7.3 A c t i o n s a t t h e R e mo t e P I N X f o r i n t e r r o g a t i o n 6 . 8 S ig n a llin g p r o c e d u r e s f o r e n q u ir y to a D ir e c to r y P I N X 6.8.1 A c tio n s a t a P I N X f o r e n q u ir y to a D ir e c to r y P I N X 6.8.2 A c tio n s a t th e D ir e c to r y P I N X f o r e n q u ir y 6 . 9 S S - P U MR imp a c t o f in te r w o r k in g w ith p u b lic I S D N s 6.10 S S - P U MR imp a c t o f in te r w o r k in g w ith n o n - I S D N s 6.11 P r o to c o l in te r a c tio n s b e tw e e n S S - P U MR a n d o th e r s u p p le me n ta r y s e r v ic e s a n d ANFs 6.11.1 I n t e r a c t i o n w i t h C a l l i n g N a me I d e n t i f i c a t i o n P r e s e n t a t i o n ( S S - C N I P ) 6.11.2 I n t e r a c t i o n w i t h C o n n e c t e d N a me I d e n t i f i c a t i o n P r e s e n t a t i o n ( S S - C O N P ) 6.11.3 I n te r a c tio n w ith Ca ll F o r w a r d in g U n c o n d itio n a l ( S S - CF U ) 6.11.4 I n t e r a c t i o n w i t h C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.11.5 I n te r a c tio n w ith Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.11.6 Interaction with Call Deflection (SS-CD) 6.11.7 I n t e r a c t i o n w i t h P a t h R e p l a c e me n t ( A N F - P R ) 6.11.8 Interaction with Call Transfer (SS-CT) 6.11.9 I n t e r a c t i o n w i t h C a l l C o mp l e t i o n t o B u s y S u b s c r i b e r ( S S - C C B S ) 6 . 1 1 . 1 0 I n t e r a c t i o n w i t h C a l l C o mp l e t i o n o n N o R e p ly ( S S - C C N R ) 6.11.11 Interaction with Call Offer (SS-CO) 6.11.12 Interaction with Do Not Disturb (SS-DND) 6 . 1 1 . 1 3 I n t e r a c t i o n w i t h D o N o t D is t u r b O v e r r i d e ( S S - D N D O ) 6.11.14 Interaction with Call Intrusion (SS-CI) 6.11.15 Interaction with Call Interception (ANF-CINT) 6 . 1 1 . 1 6 I n te r a c tio n w ith T r a n s it Co u n te r ( A N F - T C) 6.11.17 Interaction with Recall (SS-RE) 6 . 1 1 . 1 8 I n te r a c tio n w ith A d v ic e O f Ch a r g e ( S S - A O C) 6 . 1 1 . 1 9 I n t e r a c t i o n w i t h W ir e l e s s T e r mi n a l I n c o min g C a l l ( S S - W T M I ) 6 . 1 1 . 2 0 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l O u t g o in g c a l l ( S S - W T M O ) 6 . 1 1 . 2 1 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l L o c a t i o n R e g is t r a t i o n ( S S - W T L R ) 6 . 1 1 . 2 2 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l A u t h e n t i c a t i o n o f t h e W T M U s e r (SS-WTAT) 6 . 1 1 . 2 3 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l A u t h e n t i c a t i o n o f t h e P I S N ( S S - W T A N ) 6 . 1 1 . 2 4 I n te r a c tio n s w ith Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6 . 1 1 . 2 5 I n t e r a c t i o n s w i t h C o mmo n I n f o r ma t i o n ( A N F - C MN ) 6.11.26 Interactions with Call Priority Interruption (SS-CPI) 6 . 1 1 . 2 7 I n t e r a c t i o n s w i t h C a l l P r i o r i t y I n te r r u p tio n P r o te c tio n ( S S - CP I P ) 6.12 S S - P U M R p a r a me t e r v a l u e s ( t i me r s ) 6.12.1 T i me r T 1 6.12.2 T i me r T 2 6.12.3 T i me r T 3

15 17 17 17 17 18 19 20 20 21 21 21 21 21 21 21 21 21 21 21 22 22 22 22 22 22 22 22 22 22 22 22 22 22 23 23 23 23 24 24 24 24 24 24

- iii -

6.12.4 6.12.5

T i me r T 4 T i me r T 5

24 24

A n n e x A - P r o t o c o l I m p l e m e n t a t i o n C o n fo r m a n c e S t a t e m e n t ( P I C S ) p r o f o r m a

A n n e x B - Ex a m p le s o f M e s s a g e S e q u e n c e s

A n n e x C - S p e c i f i c a t i o n a n d D e s c r i p t i o n L a n gu a g e ( S D L ) r e p r e s e n t a t i o n o f p r o c e d u r e s

Annex D - Imported ASN.1 Definitions

A n n e x E - A S N . 1 d e f in it io n s a c c o r d in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9

- iv -

Scope This Standard specifies the signalling protocol for the support of the Private User Mobility Registration supplementary service (SS-PUMR) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). SS-PUMR is a supplementary service which enables a PUM user to register at, or de-register from, any wired or wireless terminal within the PISN. The ability to register at different locations in the PISN at different times enables the PUM user to maintain the provided services (including the ability to make and receive calls) at different access points. De-registration is used to inform the PISN that the PUM user is temporarily unable to make use of the provided services (including the receipt of calls). SS-PUMR may provide the PUM user with the ability to obtain information on the current registration sessions (interrogation). The Q reference point is defined in ECMA-133. Service specifications are produced in three stages and according to the method specified in ITU-T Rec. I.130. This Standard contains the stage 3 specification for the Q reference point and satisfies the requirements identified by the stage 1 and stage 2 specifications in ECMA-281. The signalling protocol for SS-PUMR uses certain aspects of the generic procedures for the control of supplementary services specified in ECMA-165. This Standard also specifies additional signalling protocol requirements for the support of interactions at the Q reference point between SS-PUMR and other supplementary services and ANFs. NOTE 1 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. This Standard is applicable to PINXs which can interconnect to form a PISN. This Standard applies to PUM only within a single PISN.

Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma in annex A. Conformance to this Standard includes conforming to those clauses that specify protocol interactions between SS-PUMR and other supplementary services and ANFs for which signalling protocols at the Q reference point are supported in accordance with the stage 3 standards concerned.

References (normative) The following standards contain provisions which, through reference in this text, constitute provision of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-133

Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)

ECMA-155

Private Integrated ISO/IEC 11571)

ECMA-165

Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)

Services

Networks

Addressing

(International

Standard

- 2 -

ECMA-242

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Message Waiting Indication Supplementary Service (International Standard ISO/IEC 15506)

ECMA-281

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Private User Mobility (PUM) - Registration Supplementary Service (International Standard ISO/IEC 17875)

ECMA-301

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Wireless Terminal Location Registration Supplementary Service and Wireless Terminal Information Exchange Additional Network Feature (International Standard ISO/IEC 15428)

ECMA-302

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Wireless Terminal Location Registration Supplementary Service and Wireless Terminal Information Exchange Additional Network Feature (International Standard ISO/IEC 15429)

ITU-T Rec. I.112

Vocabulary of terms for ISDN (1993)

ITU-T Rec. I.130

Method for the characterization of telecommunication services supported by an ISDN and network capabilities of an ISDN (Blue Book) (1988)

ITU-T Rec. I.210

Principles of telecommunication services supported by an ISDN and the means to describe them (1993)

ITU-T Rec. Q.950

Supplementary services protocols, structure and general principles (2000)

ITU-T Rec. Z.100

Specification and description language (1999)

Definitions For the purpose of this Standard the following definitions apply.

4.1

External definitions This Standard uses the following terms defined in other documents: − AllCall registration

(ECMA-281)

− Application Protocol Data Unit (APDU)

(ECMA-165)

− Basic Service

(ITU-T Rec. I.210)

− Call, Basic Call

(ECMA-165)

− Complete Number

(ECMA-155)

− Coordination Function

(ECMA-165)

− De-registration

(ECMA-281)

− Directory PINX

(ECMA-301)

− End PINX

(ECMA-165)

− Gateway PINX

(ECMA-165)

− Home data base (HDB)

(ECMA-281)

− Home PINX

(ECMA-281)

− Hosting address

(ECMA-281)

− InCall registration

(ECMA-281)

− Network Facility Extension (NFE)

(ECMA-165)

− PISN Number

(ECMA-155)

- 3 -

4.2

− Originating PINX

(ECMA-165)

− OutCall registration

(ECMA-281)

− Private Integrated Services Network (PISN)

(ECMA-133)

− Private Integrated services Network eXchange (PINX)

(ECMA-133)

− Private User Mobility (PUM)

(ECMA-281)

− PUM number

(ECMA-281)

− PUM user

(ECMA-281)

− Registration

(ECMA-281)

− Registration session

(ECMA-281)

− Signalling

(ITU-T Rec. I.112)

− Supplementary Service

(ITU-T Rec. I.210)

− Supplementary Service Control Entity

(ECMA-165)

− Terminating PINX

(ECMA-165)

− Transit PINX

(ECMA-165)

− Visitor data base (VDB)

(ECMA-281)

− Visitor PINX

(ECMA-281)

Remote PINX Any PINX in the private network not coincident with the Visitor PINX, from which a PUM user or another authorized user has access to the features (registration/de-registration and interrogation) of SS-PUMR.

4.3

Previous Visitor PINX A PINX in the private network, at which a PUM user is still registered and has to be de-registered from when he attempts to register at another Visitor PINX.

4.4

Alternative identifier An identifier, other than the PISN number, which identifies the PUM user uniquely.

4.5

Activating user Either the PUM user himself or an authorized user acting on behalf of the PUM user.

List of acronyms ANF

Additional Network Feature

APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation no.1

Call Transfer

HDB

Home Data Base

ISDN

Integrated Services Digital Network

MWI

Message Waiting Indication

NFE

Network Facility Extension

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

- 4 -

PUM

Private User Mobility

SDL

Specification and Description Language

Supplementary Service

SS-PUMR Private User Mobility Registration supplementary service

VDB

Visitor Data Base

Wireless Terminal

WTM

Wireless Terminal Mobility

Signalling protocol for the support of SS-PUMR

6.1

SS-PUMR description SS-PUMR is a supplementary service which enables a PUM user to register at, or de-register from, any wired or wireless terminal within the PISN. The ability to register for incoming calls (InCall registration) is mandatory, whereas the ability to register for outgoing calls (OutCall registration) or for both incoming and outgoing calls (AllCall registration) is optional. The ability to register at different locations in the PISN at different times enables the PUM user to maintain the provided services (including the ability to make and receive calls) at different access points. De-registration is used to inform the PISN that the PUM user is temporarily unable to make use of the provided services (including the receipt of calls). SS-PUMR may provide the PUM user with the ability to obtain information on the current registration sessions (interrogation).

6.2

SS-PUMR operational requirements

6.2.1

Requirements on the Visitor PINX Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating and Terminating PINX, shall apply.

6.2.2

Requirements on the Home PINX Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for a Terminating and an Originating PINX, shall apply.

6.2.3

Requirements on the Previous Visitor PINX Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for a Terminating PINX, shall apply.

6.2.4

Requirements on a Transit PINX Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.

6.2.5

Requirements on the Directory PINX Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for a Terminating PINX, shall apply.

6.2.6

Requirements on the Remote PINX Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply.

- 5 -

6.3 6.3.1

SS-PUMR coding requirements O p e r a t io n s The operations defined in Abstract Syntax Notation number 1 (ASN.1) in table 1 shall apply. The notation is in accordance with ITU-T Rec. X.680 and X.690. The ITU-T Rec. X.208 and X.209 superseded version is in annex E. Table 1 - Operations in Support of SS-PUMR PUM-Registration-Operations-asn1-97 { iso (1) standard (0) pss1-pum-registration (17876) pum-registration-operations-asn1-97 (1) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operations-Information-Objects { joint-iso-itu-t (2) remote-operations (4) informationObjects (5) version1(0)} EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 { iso (1) standard (0) pss1-generic-procedures (11582) msi-class-asn1-97 (11) } notAvailable, invalidServedUserNr, supplementaryServiceInteractionNotAllowed FROM General-Error-List { ccitt recommendation q 950 general-error-list (1) } PartyNumber FROM Addressing-Data-Elements-asn1-97 { iso (1) standard (0) pss1-generic-procedures (11582) addressing-data-elements-asn1-97 (20) } BasicService FROM Call-Diversion-Operations-asn1-97 { iso (1) standard (0) pss1-call-diversion (13873) call-diversion-operations-asn1-97 (1) } pisnEnquiry FROM WTM-Location-Registration-Operations-asn1-97 { iso (1) standard (0) pss1-location-registration (15429) wtmlr-operations-asn1-97 (1) };

PUM-Registration-Operations OPERATION ::= { pumRegistr | pumDelReg | pumDe-reg | pumInterrog | pisnEnquiry } pumRegistr

OPERATION ::= { -- Registration (sent from the Visitor PINX to the Home PINX or -from a Remote PINX to the Visitor PINX) ARGUMENT PumRegistrArg RESULT PumRegistrRes ERRORS { invalidServedUserNr | notAuthorized | unspecified | notAvailable | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | pumUserNotSubscribedToThisServiceOpt | pumUserFailedAuthentication | hostingAddrInvalid } CODE local: 89}

- 6 -

Table 1 - Operations in Support of SS-PUMR (continued) pumDelReg

OPERATION ::= { -- Delete Registration (sent from the Home PINX to the Previous Visitor PINX) ARGUMENT PumDelRegArg RESULT DummyRes ERRORS { notAvailable | temporarilyUnavailable | unspecified | supplementaryServiceInteractionNotAllowed } CODE local: 90}

pumDe-reg

OPERATION ::= { -- De-registration (sent from the Visitor PINX or Remote PINX to the Home PINX) ARGUMENT PumDe-regArg RESULT DummyRes ERRORS { invalidServedUserNr | notAuthorized | unspecified | supplementaryServiceInteractionNotAllowed | pumUserNotSubscribedToThisServiceOpt | pumUserFailedAuthentication | hostingAddrInvalid | pumUserNotRegistered } CODE local: 91}

pumInterrog

OPERATION ::= { -- Interrogation (sent from the Visitor PINX or Remote PINX to the Home PINX and -from the Home PINX to the Visitor PINX) ARGUMENT PumInterrogArg RESULT PumInterrogRes ERRORS { invalidServedUserNr | notAuthorized | unspecified | supplementaryServiceInteractionNotAllowed | pumUserFailedAuthentication | hostingAddrInvalid | pumUserNotRegistered } CODE local: 92}

PumRegistrArg ::= SEQUENCE

- 7 -

Table 1 - Operations in Support of SS-PUMR (continued) PumRegistrRes ::= SEQUENCE

{ pumNumber PartyNumber, serviceOption ServiceOption OPTIONAL, -- Type of registration (InCall, OutCall or AllCall) sessionParams SessionParams OPTIONAL, -- Duration of session, Number of outgoing calls argExtension PumrExtension OPTIONAL }

DummyRes ::=

{ null extension sequOfExtn

CHOICE

NULL, [ 1 ] IMPLICIT Extension{{PUMRExtSet}}, [ 2 ] IMPLICIT SEQUENCE OF Extension{{PUMRExtSet}} }

PumDelRegArg ::= SEQUENCE

PumDe-regArg ::= SEQUENCE

{ pumUserId CHOICE { pumNumber PartyNumber, -- The PISN number of the PUM user, -- always a Complete Number. alternativeId AlternativeId }, basicService BasicService, -- specific basic service or all basic services, hostingAddr [0] PartyNumber OPTIONAL, -- The PISN number of the hosting user, -- always a Complete Number. -- Not included if serviceOption indicates 'inCallRegistration', -- optional if serviceOption indicates 'outCallRegistration' -- or 'allCallRegistration'. activatingUserAddr [1] PartyNumber OPTIONAL, -- The PISN number of the activating user, -- always a Complete Number. -- Mandatory if sent from a Remote PINX, else not included. serviceOption ServiceOption DEFAULT inCallRegistration, -- Type of registration session (InCall, OutCall or AllCall) -- If serviceOption indicates 'outCallRegistration' and -- hostingAddr is omitted, the de-registration applies to -- all OutCall registrations of this PUM user. -- If serviceOption indicates 'allCallRegistration' and -- hostingAddr is omitted, the de-registration applies to the -- AllCall and all OutCall registrations of this PUM user. userPin CHOICE { pumUserPin [6] IMPLICIT UserPin, activatingUserPin [7] IMPLICIT UserPin } OPTIONAL, argExtension PumrExtension OPTIONAL }

- 8 -

Table 1 - Operations in Support of SS-PUMR (continued) PumInterrogArg ::= SEQUENCE

homeInfoOnly BOOLEAN DEFAULT TRUE, -- True = Only Home PINX information (default) -- False = Complete information userPin CHOICE { pumUserPin [6] IMPLICIT UserPin, activatingUserPin [7] IMPLICIT UserPin } OPTIONAL, argExtension PumrExtension OPTIONAL } PumInterrogRes ::= SET SIZE(1..8) OF SEQUENCE { basicService [0] IMPLICIT BasicService OPTIONAL, -- specific basic service or all basic services, -- (Home PINX information) hostingAddr [1] PartyNumber OPTIONAL, -- The PISN number of the hosting user, -- always a Complete Number. -- (Home PINX information) serviceOption [2] IMPLICIT ServiceOption OPTIONAL, -- Type of registration session -- (InCall, OutCall or AllCall) -- (Home PINX information) interrogParams SessionParams OPTIONAL, -- Time left in registration session, -- Number of outgoing calls left -- (Visitor PINX information) argExtension PumrExtension OPTIONAL } AlternativeId

::=

OCTET STRING (SIZE(1..20))

ServiceOption ::= ENUMERATED { inCallRegistration outCallRegistration allCallRegistration

(0), (1), (2) }

SessionParams ::= SEQUENCE { durationOfSession [ 1 ] IMPLICIT INTEGER OPTIONAL, -- Duration of session in seconds, -- default if omitted: duration of session unlimited. numberOfOutgCalls [ 2 ] IMPLICIT INTEGER OPTIONAL } -- Default if omitted: number of outgoing calls unlimited. UserPin

::=

OCTET STRING (SIZE(1..20))

- 9 -

Table 1 - Operations in Support of SS-PUMR (concluded) PumrExtension ::=

CHOICE extension sequOfExtn

{ [ 4 ] IMPLICIT Extension {{PUMRExtSet}}, [ 5 ] IMPLICIT SEQUENCE OF Extension{{PUMRExtSet}} }

PUMRExtSet EXTENSION ::= {...}unspecified Extension{{PUMRExtSet}}

ERROR

::= {

PARAMETER

CODE local: 1008} notAuthorized temporarilyUnavailable pumUserNotSubscribedToThisServiceOpt pumUserFailedAuthentication hostingAddrInvalid pumUserNotRegistered END

ERROR ERROR ERROR ERROR ERROR ERROR

::= { ::= { ::= { ::= { ::= { ::= {

CODE local: 1007} CODE local: 1000} CODE local: 1019} CODE local: 1020} CODE local: 1021} CODE local: 1022}

-- of PUM-Registration-Operations-asn1-97

6.3.2 Information elements 6.3.2.1 Facility information element The operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of operations defined in 6.3.1, the destinationEntity data element of the NFE shall contain value endPINX. When conveying the invoke APDU of operations defined in 6.3.1, the Interpretation APDU shall either be omitted or be included with value rejectAnyUnrecognisedInvokePdu. 6.3.2.2

6.3.3

6.4

Other information elements Any other information elements (e.g. Calling party number, Called party number) shall be coded in accordance with the rules of ECMA-165. Messages The Facility information element shall be conveyed in the messages as specified in clause 10 of ECMA-165.

SS-PUMR state definitions

6.4.1

S t a t e s a t t h e V is it o r P I N X The procedures for the Visitor PINX are written in terms of the following conceptual states existing within the SS-PUMR Supplementary Service Control entity in that PINX in association with a particular registration request.

6.4.1.1

S t a t e V is it I d le SS-PUMR is not operating.

6.4.1.2

S t a t e V is it R e g A pumRegistr invoke APDU has been sent.

6.4.1.3

State VisitEnquiry A pisnEnquiry invoke APDU has been sent.

6.4.1.4

S t a t e V is it I n t e r r o g a t io n A pumInterrog invoke APDU has been sent.

6.4.1.5

S t a t e V is it D e - r e g A pumDe-reg invoke APDU has been sent.

- 10 -

6.4.2

States at the Home PINX The procedures for the Home PINX are written in terms of the following conceptual states existing within the SS-PUMR Supplementary Service Control entity in that PINX in association with a particular registration request.

6.4.2.1

S t a t e H o m e I d le SS-PUMR is not operating. Ready for receipt of a pumRegistr or pumDe-reg invoke APDU.

6.4.2.2

State HomeDelete A pumDelReg invoke APDU has been sent.

6.4.2.3

S t a t e H o m e I n t e r r o g a t io n A pumInterrog invoke APDU has been sent.

6.4.3

States at the Directory PINX The procedures for the Directory PINX are written in terms of the following conceptual states existing within the SS-PUMR Supplementary Service Control entity in that PINX in association with a particular registration request.

6.4.3.1 6.4.4

State DirectoryIdle Ready for receipt of a pisnEnquiry invoke APDU. S t a t e s a t t h e P r e v io u s V is it o r P I N X The procedures for the Previous Visitor PINX are written in terms of the following conceptual states existing within the SS-PUMR Supplementary Service Control entity in that PINX in association with a particular registration request.

6.4.4.1 6.4.5

S t a t e P r e V is it o r I d le Ready for receipt of a pumDelReg invoke APDU. States at the Remote PINX The procedures for a Remote PINX are written in terms of the following conceptual states existing within the SS-PUMR Supplementary Service Control entity in that PINX in association with a particular registration request.

6.4.5.1

S t a t e R e m o t e I d le SS-PUMR is not operating.

6.4.5.2

State RemoteReg A pumRegistr invoke APDU has been sent.

6.4.5.3

State RemoteEnquiry A pisnEnquiry invoke APDU has been sent.

6.4.5.4

S t a t e R e m o t e I n t e r r o g a t io n A pumInterrog invoke APDU has been sent.

6.4.5.5

State RemoteDe-reg A pumDe-reg invoke APDU has been sent.

6.5

SS-PUMR signalling procedures for registration Examples of message sequences are shown in annex B.

6.5.1 6.5.1.1

A c t io n s a t t h e V is it o r P I N X f o r r e g is t r a t io n The SDL representation of procedures at the Visitor PINX is shown in C.1 of annex C. Normal procedures On receipt of a valid registration request from a PUM user and if the Visitor PINX possesses sufficient addressing information to make a registration request to the Home PINX, the Visitor PINX shall send a pumRegistr invoke APDU to the Home PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or

- 11 -

used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU, the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service for which the PUM user is to be registered shall be included in element basicService, and the PISN number of the hosting user shall be included in element hostingAddr. This PISN number shall be suitable for use in the Called party number information element of a call or call independent signalling connection that is to be routed to the hosting user. If provided by the registration request from the PUM user, the Visitor PINX shall additionally include in element serviceOption the type of registration (InCall, OutCall or AllCall). If provided by the registration request from the PUM user, the Visitor PINX shall further include the PUM user's PIN in element userPin. The Visitor PINX shall enter state VisitReg and start timer T1. The registration request from a PUM user may optionally contain session parameters (element sessionParams) specifying the maximum duration of the registration session or the maximum number of outgoing calls (in case of OutCall or AllCall registration). If the Visitor PINX supports these optional parameters, it shall set a duration timer and a counter for the number of outgoing calls to the values specified by these parameters. On expiry of the duration timer or when reaching the specified number of outgoing calls, the Visitor PINX shall terminate the registration session by means of a pumDe-reg invoke APDU to the Home PINX, as specified in 6.6.1.1 (conditional de-registration). NOTE 2 Validation of the registration request can involve authentication of the PUM user. NOTE 3 In the absence of sufficient addressing information, the Visitor PINX can, before sending a pumRegistr invoke APDU, use the procedures of 6.8.1 to make an enquiry to a Directory PINX in order to translate an identifier provided by the PUM user in the registration request into a PISN number. NOTE 4 The number to be used in the Called party number information element when establishing the call independent signalling connection to the Home PINX is outside the scope of this Standard. It can, for example, be a PISN number provided by the PUM user in the registration request or optionally the PISN number provided by the Directory PINX. On receipt of the pumRegistr return result APDU, the Visitor PINX shall stop timer T1, update the information in the VDB for the requested basic service and hosting address, revert to state VisitIdle and indicate acceptance to the PUM user. The Visitor PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.5.1.2

Ex c e p t io n a l p r o c e d u r e s If the Visitor PINX is unable to proceed with the registration request, it shall enter state VisitIdle and indicate failure to the PUM user. On receipt of a pumRegistr return error or reject APDU from the Home PINX, the Visitor PINX shall stop timer T1, revert to state VisitIdle and indicate rejection to the PUM user. If timer T1 expires (i.e. the pumRegistr invoke APDU is not answered by the Home PINX), the Visitor PINX shall indicate rejection to the PUM user and enter state VisitIdle. The Visitor PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T1. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.5.2 6.5.2.1

Additional actions at the Visitor PINX in case of remote registration The SDL representation of procedures at the Visitor PINX is shown in C.1 of annex C. Normal procedures On receipt of a pumRegistr invoke APDU from a Remote PINX using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the actions specified in 6.5.1.1

- 12 -

shall apply with the term "PUM user" replaced by "Remote PINX". On receipt of the pumRegistr return result APDU from the Home PINX, the Visitor PINX shall send a pumRegistr return result to the Remote PINX. The contents of this pumRegistr return result APDU shall be the same as the contents of the pumRegistr return result APDU from the Home PINX. 6.5.2.2

Ex c e p t io n a l p r o c e d u r e s If the Visitor PINX is unable to proceed with the registration request, it shall send a pumRegistr return error APDU containing an appropriate error to the Remote PINX and enter state VisitIdle. On receipt of a pumRegistr return error APDU from the Home PINX, the Visitor PINX shall send a pumRegistr return error APDU to the Remote PINX containing the same error as received in the pumRegistr return error APDU from the Home PINX, stop timer T1 and revert to state VisitIdle. On receipt of a pumRegistr reject APDU from the Home PINX, the Visitor PINX shall send a pumRegistr return error APDU to the Remote PINX containing an appropriate error corresponding to the reject problem received in the pumRegistr reject APDU from the Home PINX, stop timer T1 and revert to state VisitIdle. If timer T1 expires (i.e. the pumRegistr invoke APDU is not answered by the Home PINX), the Visitor PINX shall send a pumRegistr return error APDU containing the error temporarilyUnavailable to the Remote PINX and enter state VisitIdle.

6.5.3 6.5.3.1

A c t io n s a t t h e H o m e P I N X f o r r e g is t r a t io n The SDL representation of procedures at the Home PINX is shown in C.2 of annex C. Normal procedures On receipt of a pumRegistr invoke APDU using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the Home PINX shall check the received basic service (element basicService) and the PUM user’s PISN number or alternative identifier (element pumUserId), and verify that the PUM user is allowed to register. If the PUM user is allowed to register, the Home PINX shall update the information in the HDB and answer the pumRegistr invoke APDU with a return result APDU. If the received pumRegistr invoke APDU contained an InCall or AllCall registration (in element serviceOption), the Home PINX shall send a pumDelReg invoke APDU to the previous Visitor PINX using the call reference of a call independent signalling connection, in order to terminate the PUM user's previous InCall or AllCall registration session (if applicable). If the received pumRegistr invoke APDU contained an OutCall registration (in element serviceOption), the Home PINX may optionally send a pumDelReg invoke APDU to the previous Visitor PINX using the call reference of a call independent signalling connection, in order to terminate the PUM user's previous InCall or AllCall registration session (if applicable). The Home PINX may optionally leave the PUM user's existing OutCall registration session(s) unaffected (if applicable). If the received pumRegistr invoke APDU does not contain the optional element serviceOption, i.e. does not specify the type of registration, the Home PINX shall assume an InCall registration and shall take the actions according to that type. Termination of previous registration session(s) shall be performed by sending appropriate pumDelReg invoke APDU(s) to the previous Visitor PINX(s) using the call reference(s) of (a) call independent signalling connection(s). The call independent signalling connection(s) shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the pumDelReg invoke APDU(s), the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service for which the PUM user has registered shall be included in element basicService, a PISN number identifying the hosting user shall be included in element hostingAddr, and the type of registration (InCall, OutCall, or AllCall) shall be included in element serviceOption. The Home PINX shall enter state HomeDelete and start timer T4.

- 13 -

On receipt of all outstanding responses to the pumDelReg invoke APDUs, the Home PINX shall stop timer T4 and enter state HomeIdle. The Home PINX is responsible for clearing the call independent signalling connection(s) towards the previous Visitor PINX(s). This may occur on receipt of a return result APDU. Alternatively, the signalling connection(s) may be retained for other applications, if appropriate. 6.5.3.2

Ex c e p t io n a l p r o c e d u r e s If the Home PINX is unable to proceed with the registration request, it shall answer the pumRegistr invoke APDU with a return error APDU containing an appropriate error and enter state HomeIdle. If the PUM user is not found in the HDB, the Home PINX shall answer the pumRegistr invoke APDU with a return error APDU containing the error invalidServedUserNr. If the PUM user is not allowed to register, the Home PINX shall answer the pumRegistr invoke APDU with a return error APDU containing the error notAuthorized. On receipt of a pumDelReg return error or reject APDU from a previous Visitor PINX and if there are still responses to the pumDelReg invoke APDU(s) outstanding, no action shall be taken at the Home PINX. If timer T4 expires (e.g. a pumDelReg invoke APDU is not answered by a previous Visitor PINX), the Home PINX shall enter state HomeIdle. NOTE 5 Expiry of timer T4 or receipt of a pumDelReg return error or reject APDU may invoke management actions to correct the VDB data in the previous Visitor PINX(s).

6.5.4

A c t io n s a t a Tr a n s it P I N X f o r r e g is t r a t io n No special actions are required in support of registration.

6.5.5

Actions at the previous Visitor PINX for registration The SDL representation of procedures at the previous Visitor PINX is shown in C.3 of annex C.

6.5.5.1

Normal procedures On receipt of a pumDelReg invoke APDU using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the previous Visitor PINX shall check the received basic service (element basicService), the PUM user’s PISN number or alternative identifier (element pumUserId), the hosting address (element hostingAddr) and the type of registration (element serviceOption), delete the specified VDB entry for the PUM user and answer the pumDelReg invoke APDU with a return result APDU.

6.5.5.2

Ex c e p t io n a l p r o c e d u r e s If the specified VDB entry for the PUM user is not found in the VDB, the previous Visitor PINX shall answer the pumDelReg invoke APDU with a return result APDU. If the VDB is temporarily unavailable, the previous Visitor PINX shall answer the pumDelReg invoke APDU with a return error APDU containing the error temporarilyUnavailable.

6.5.6 6.5.6.1

A c t io n s a t t h e R e m o t e P I N X f o r r e g is t r a t io n The SDL representation of procedures at the Remote PINX is shown in C.5 of annex C. Normal procedures On receipt of a valid registration request from an activating user, the Remote PINX shall send a pumRegistr invoke APDU to the Visitor PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU, the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service for which the PUM user is to be registered shall be included in element basicService, a PISN number identifying the hosting user shall be included in element hostingAddr, and the PISN number of the activating user shall be included in element activatingUserAddr. The PISN number of the hosting user shall be suitable for use in the Called party number information element of a call or call independent signalling connection that is to

- 14 -

be routed to the hosting user. If provided by the registration request from the activating user, the Remote PINX shall additionally include the type of registration (InCall, OutCall, or AllCall) in element serviceOption and the session parameters (maximum duration of the registration session, maximum number of outgoing calls) in element sessionParams. If provided by the registration request from the activating user, the Remote PINX shall further include the activating user's PIN in element userPin. The Remote PINX shall enter state RemoteReg and start timer T1. NOTE 6 Validation of the registration request can involve authentication of the activating user. NOTE 7 The number to be used in the Called party number information element when establishing the call independent signalling connection to the Visitor PINX is outside the scope of this Standard. It can, for example, be a PISN number provided by the activating user in the registration request. On receipt of the pumRegistr return result APDU, the Remote PINX shall stop timer T1, revert to state RemoteIdle and indicate acceptance to the activating user. The Remote PINX is responsible for clearing the call independent signalling connection towards the Visitor PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.5.6.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a pumRegistr return error or reject APDU from the Visitor PINX, the Remote PINX shall stop timer T1, revert to state RemoteIdle and indicate rejection to the activating user. If timer T1 expires (i.e. the pumRegistr invoke APDU is not answered by the Visitor PINX), the Remote PINX shall indicate rejection to the activating user and enter state RemoteIdle. The Remote PINX is responsible for clearing the call independent signalling connection towards the Visitor PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T1. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.6

SS-PUMR signalling procedures for de-registration Examples of message sequences are shown in annex B.

6.6.1 6.6.1.1

A c t io n s a t t h e V is it o r P I N X f o r d e - r e g is t r a t io n The SDL representation of procedures at the Visitor PINX is shown in C.1 of annex C. Normal procedures On receipt of a valid de-registration request from a PUM user or an authorized user, the Visitor PINX shall: − If the de-registration request is for a particular registration session or all sessions of a PUM user, send a pumDe-reg invoke APDU to the Home PINX using the call reference of a call independent signalling connection. − If the de-registration request is for all PUM users being registered at a specific hosting address, send a pumDe-reg invoke APDU for each registered PUM user to the Home PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU(s), the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId and the basic service for which the PUM user is to be de-registered shall be included in element basicService. If provided by the de-registration request from the PUM user or authorized user, the Visitor PINX shall additionally indicate: − in element serviceOption which type of registration session is to be de-registered; − in element activatingUserAdress the PISN number of the user activating the request; − in element activating userPIN the PIN supplied by the activating user.

- 15 -

If only sessions at a specific hosting address are to be de-registered, a PISN number identifying the hosting user shall be included in element hostingAddr otherwise, element hostingAddr shall be omitted. The Visitor PINX shall enter state VisitDe-reg and start timer T3. NOTE 8 In the absence of sufficient addressing information, the Visitor PINX can, before sending a pumDereg invoke APDU, use the procedures of 6.8.1 to make an enquiry to a Directory PINX in order to translate an identifier provided by the PUM user in the registration request into a PISN number. NOTE 9 The same procedures apply if the duration timer for a session expires or if the maximum number of outgoing calls is reached (conditional de-registration). NOTE 10 Validation of the de-registration request can involve authentication of the PUM user or the authorized user. On receipt of a pumDe-reg return result APDU, the Visitor PINX shall delete the information in the VDB for the requested PUM user and basic service and, if applicable, indicate acceptance to the PUM user or authorized user. On receipt of all outstanding responses to the pumDe-reg invoke APDUs, the visitor PINX shall stop timer T3 and revert to state VisitIdle. The Visitor PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of all outstanding responses. Alternatively, the signalling connection may be retained for other applications, if appropriate. On receipt of a pumDelReg invoke APDU from the Home PINX using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the Visitor PINX shall check the received basic service (element basicService), the PUM user’s PISN number or alternative identifier (element pumUserId), the hosting address (element hostingAddr) and the type of registration (element serviceOption), delete the specified VDB entry for the PUM user, and answer the pumDelReg invoke APDU with a return result APDU. 6.6.1.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a pumDe-reg return error or reject APDU from the Home PINX and if there are still responses to the pumDe-reg invoke APDU(s) outstanding, no action shall be taken at the Visitor PINX, except, if applicable, indicate rejection to the PUM user or authorized user. If timer T3 expires (i.e. a pumDe-reg invoke APDU is not answered by the Home PINX), the Visitor PINX shall enter state VisitIdle and, if applicable, indicate rejection to the PUM user. The Visitor PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of all outstanding responses or on expiry of timer T3. Alternatively, the signalling connection may be retained for other applications, if appropriate. If, on receipt of a pumDelReg invoke APDU from the Home PINX, the specified VDB entry for the PUM user is not found in the VDB, the Visitor PINX shall answer with a pumDelReg return result APDU. If the VDB is temporarily unavailable, the previous Visitor PINX shall answer the pumDelReg invoke APDU with a return error APDU containing the error temporarilyUnavailable.

6.6.2

A c t io n s a t t h e H o m e P I N X f o r d e - r e g is t r a t io n The SDL representation of procedures at the Home PINX is shown in C.2 of annex C. The procedures specified in the following apply for de-registration initiated by a PUM user at a Visitor PINX and for remote de-registration.

6.6.2.1

Normal procedures On receipt of a pumDe-reg invoke APDU using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the Home PINX shall check the received basic service (element basicService) and the PUM user’s PISN number or alternative identifier (element

- 16 -

pumUserId) and the activating user's PISN number if provided and verify that de-registration is permitted. The pumDe-reg invoke APDU may contain either a request for de-registration of a specific type of registration session (InCall, OutCall, AllCall) at a specific hosting address or a request for deregistration of all registration sessions at all hosting addresses. If element serviceOption in the received pumDe-reg invoke APDU indicates 'outCallRegistration' and hostingAddr is omitted, the de-registration shall apply to all OutCall registrations of this PUM user. If serviceOption indicates 'allCallRegistration' and hostingAddr is omitted, the de-registration shall apply to the AllCall and all OutCall registrations of this PUM user. If a hosting address (in element hostingAddr) is contained in the received pumDe-reg invoke APDU, the de-registration shall apply only to the registration session indicated in element serviceOption of this PUM user at this hosting address. If the received pumDe-reg invoke APDU does not contain the optional element serviceOption, i.e. does not specify which type of registration session is to be de-registered, the Home PINX shall assume an InCall de-registration and shall take the actions according to that type. If the PUM user may de-register, the Home PINX shall update the location information in the HDB and answer the pumDe-reg invoke APDU with a return result APDU. If required according to the contents of the pumDe-reg invoke APDU, the Home PINX shall additionally send (a) pumDelReg invoke APDU(s) to the Visitor PINX(s) using the call reference(s) of (a) call independent signalling connection(s). The call independent signalling connection(s) shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the pumDelReg invoke APDU(s), the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service for which the PUM user is to be de-registered shall be included in element basicService, a PISN number identifying the hosting user shall be included in element hostingAddr, and the type of registration (InCall, OutCall, or AllCall) shall be included in element serviceOption. The Home PINX shall enter state HomeDelete and start timer T4. On receipt of all outstanding responses to the pumDelReg invoke APDUs, the Home PINX shall stop timer T4 and enter state HomeIdle. The Home PINX is responsible for clearing the call independent signalling connection(s) towards the Visitor PINX(s). This may occur on receipt of a return result APDU. Alternatively, the signalling connection(s) may be retained for other applications, if appropriate. 6.6.2.2

Ex c e p t io n a l p r o c e d u r e s If the Home PINX is unable to proceed with the de-registration request, it shall answer the pumDe-reg invoke APDU with a return error APDU containing an appropriate error and enter state HomeIdle. If the PUM user is not found in the HDB, the Home PINX shall answer the pumDe-reg invoke APDU with a return error APDU containing the error invalidServedUserNr. If the PUM user is not allowed to de-register, the Home PINX shall answer the pumDe-reg invoke APDU with a return error APDU containing the error notAuthorized. On receipt of a pumDelReg return error or reject APDU from a Visitor PINX and if there are still responses to the pumDelReg invoke APDU(s) outstanding, no action shall be taken at the Home PINX. If timer T4 expires (e.g. a pumDelReg invoke APDU is not answered by a Visitor PINX), the Home PINX shall enter state HomeIdle. NOTE 11 Expiry of timer T4 or receipt of a pumDelReg return error or reject APDU may invoke management actions to correct the VDB data in the previous Visitor PINX(s).

- 17 -

6.6.3

A c t io n s a t a Tr a n s it P I N X f o r d e - r e g is t r a t io n No special actions are required in support of SS-PUMR.

6.6.4

A c t io n s a t t h e R e m o t e P I N X f o r d e - r e g is t r a t io n The SDL representation of procedures at the Remote PINX is shown in C.5 of annex C.

6.6.4.1

Normal procedures On receipt of a valid de-registration request from an activating user, the Remote PINX shall send a pumDe-reg invoke APDU to the Home PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU, the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service for which the PUM user is to be deregistered shall be included in element basicService, the PISN number of the activating user shall be included in element activatingUserAddr and, if provided, the activatinfg user's PIN shall be included in element activatingUserPIN. The de-registration request from the activating user may contain a request for de-registration of either a specific type of session (InCall, OutCall, AllCall) at a specific hosting address or all sessions of a PUM user at all hosting addresses. If provided by the deregistration request from the activating user, the Remote PINX shall indicate in element serviceOption which type of registration session is to be de-registered. If only sessions at a specific hosting address are to be de-registered, a PISN number identifying the hosting user shall be included in element hostingAddr. The Remote PINX shall enter state RemoteDe-reg and start timer T3. NOTE 12 In the absence of sufficient addressing information, the Visitor PINX can, before sending a pumDereg invoke APDU, use the procedures of 6.8.1 to make an enquiry to a Directory PINX in order to translate an identifier provided by the PUM user in the registration request into a PISN number. NOTE 13 In the absence of sufficient addressing information, the Remote PINX can, before sending a pumDe-reg invoke APDU, use the procedures of 6.8.1 to make an enquiry to a Directory PINX in order to translate an identifier provided by the activating user in the de-registration request into a PISN number. NOTE 14 Validation of the de-registration request can involve authentication of the activating user. On receipt of the pumDe-reg return result APDU, the Remote PINX shall stop timer T3, revert to state RemoteIdle and, if applicable, indicate acceptance to the activating user. The Remote PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.6.4.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a pumDe-reg return error or reject APDU from the Home PINX, the Remote PINX shall stop timer T3, revert to state RemoteIdle and, if applicable, indicate rejection to the activating user. If timer T3 expires (i.e. the pumDe-reg invoke APDU is not answered by the Home PINX), the Remote PINX shall enter state RemoteIdle and, if applicable, indicate rejection to the activating user. The Remote PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T3. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.7

SS-PUMR signalling procedures for interrogation Examples of message sequences are shown in annex B.

6.7.1

A c t io n s a t t h e V is it o r P I N X f o r in t e r r o g a t io n The SDL representation of procedures at the Visitor PINX is shown in C.1 of annex C.

- 18 -

6.7.1.1

Normal procedures On receipt of a pumInterrog invoke APDU from the Home PINX using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the Visitor PINX shall check the received basic service (element basicService) and the PUM user’s PISN number or alternative identifier (element pumUserId) and answer the pumInterrog invoke APDU with a return result APDU containing the required information (interrogParams). On receipt of a valid interrogation request from a PUM user (interrogation of existing registration sessions / hosting addresses), the Visitor PINX shall send a pumInterrog invoke APDU to the Home PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU, the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service shall be included in element basicService and the type of registration session (InCall, OutCall or AllCall) to which the interrogation applies shall be included in element serviceOption. In accordance with the interrogation request from the PUM user, the invoke APDU may additionally include the element homeInfoOnly indicating whether only Home PINX information or complete information is required, and a PISN number identifying the hosting user in element hostingAddr. Omission of the element hostingAddr indicates that information about all hosting addresses of this PUM user and this basic service is required. The Visitor PINX shall enter state VisitInterrogation and start timer T5. NOTE 15 In the absence of sufficient addressing information, the Visitor PINX can, before sending a pumInterrog invoke APDU, use the procedures of 6.8.1 to make an enquiry to a Directory PINX in order to translate an identifier provided by the PUM user in the registration request into a PISN number. NOTE 16 Validation of the interrogation request can involve authentication of the PUM user. On receipt of the pumInterrog return result APDU, the Visitor PINX shall stop timer T5, revert to state VisitIdle and forward the received information to the PUM user.

6.7.1.2

Ex c e p t io n a l p r o c e d u r e s If the Visitor PINX is unable to proceed with the interrogation request, it shall answer the pumInterrog invoke APDU with a return error APDU containing an appropriate error and enter state VisitIdle. If the PUM user is not found in the VDB, the Visitor PINX shall answer the pumInterrog invoke APDU with a return error APDU containing the error pumUserNotRegistered. On receipt of a pumInterrog return error or reject APDU the Visitor PINX shall stop timer T5, revert to state VisitIdle and indicate rejection to the PUM user. If timer T5 expires (i.e. the pumInterrog invoke APDU is not answered), the Visitor PINX shall enter state VisitIdle and indicate rejection to the PUM user. The Visitor PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T5. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.7.2 6.7.2.1

A c t io n s a t t h e H o m e P I N X f o r in t e r r o g a t io n The SDL representation of procedures at the Visitor PINX is shown in C.2 of annex C. Normal procedures On receipt of a pumInterrog invoke APDU using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the Home PINX shall check the received basic service (element basicService), the PUM user’s PISN number or alternative identifier (element pumUserId) and, if provided, the activating user's PISN number (activatingUserAddr) and verify that the user may interrogate.

- 19 -

If the PUM user may interrogate, the Home PINX shall: − If the received pumInterrog invoke APDU contained an interrogation of Home PINX information for existing registration sessions, obtain the required information from the HDB and answer the pumInterrog invoke APDU with a return result APDU containing the required information (elements basicService, hostingAddr, serviceOption). − If the received pumInterrog invoke APDU (additionally) contained an interrogation of complete information (i.e. including session parameters), obtain this information from the HDB and from the corresponding Visitor PINX(s) by means of an interrogation at this (these) Visitor PINX(s) and then answer the pumInterrog invoke APDU with a return result APDU containing the required information (elements basicService, hostingAddr, serviceOption, and interrogParams). To interrogate the session parameters of a particular session at a Visitor PINX, the Home PINX shall send a pumInterrog invoke APDU to this Visitor PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU, the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service shall be included in element basicService, a PISN number identifying the hosting user shall be included in element hostingAddr. The Home PINX shall start timer T5 and enter state HomeInterrogation. The received pumInterrog invoke may require more than one interrogation to various other Visitor PINXs. In this case the Home PINX shall collect the information received in the pumInterrog return result APDUs. On receipt of the last response to the pumInterrog invoke APDU, the Home PINX shall stop timer T5, send the obtained information to the interrogating PINX using the pumInterrog return result APDU and enter state HomeIdle. The Home PINX is responsible for clearing the call independent signalling connection towards the interrogated Visitor PINX(s). This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.7.2.2

Ex c e p t io n a l p r o c e d u r e s If the Home PINX is unable to proceed with the interrogation request, it shall answer the pumInterrog invoke APDU with a return error APDU containing an appropriate error and enter state HomeIdle. If the PUM user may not interrogate, the Home PINX shall answer the pumInterrog invoke APDU with a return error APDU containing the error notAuthorized. If the PUM user is not found in the HDB, the Home PINX shall answer the pumInterrog invoke APDU with a return error APDU containing the error invalidServedUserNr. If timer T5 expires (i.e. the pumInterrog invoke APDU is not answered by all of the other Visitor PINXs), the Home PINX shall answer the pumInterrog invoke APDU with a return result APDU containing the available information and enter state HomeIdle.

6.7.3

A c t io n s a t t h e R e m o t e P I N X f o r in t e r r o g a t io n The SDL representation of procedures at the Visitor PINX is shown in C.5 of annex C. PUM user is either the PUM user or an authorized user acting on behalf of the PUM user.

6.7.3.1

Normal procedures On receipt of a valid interrogation request from a PUM user, the Remote PINX shall send a pumInterrog invoke APDU to the Home PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU, the PISN number or an alternative identifier of the PUM user shall be included in element pumUserId, the basic service shall be included in element basicService. In accordance with the interrogation request from the PUM user, the invoke APDU may

- 20 -

additionally include the element homeInfoOnly indicating whether only Home PINX information or complete information is required, and a PISN number identifying the hosting user in element hostingAddr. Omission of the element hostingAddr indicates that information about all hosting addresses of this PUM user and this basic service is required. The PISN number of the activating user shall be included in element activatingUserAddr. The Remote PINX shall enter state RemoteInterrogation and start timer T5. NOTE 17 In the absence of sufficient addressing information, the Remote PINX can, before sending a pumInterrog invoke APDU, use the procedures of 6.8.1 to make an enquiry to a Directory PINX in order to translate an identifier provided by the PUM user in the interrogation request into a PISN number. NOTE 18 Validation of the interrogation request can involve authentication of the PUM user. On receipt of the pumInterrog return result APDU, the Remote PINX shall stop timer T5, revert to state RemoteIdle and forward the received information to the PUM user. 6.7.3.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a pumInterrog return error or reject APDU the Remote PINX shall stop timer T5, revert to state RemoteIdle and indicate rejection to the PUM user. If timer T5 expires (i.e. the pumInterrog invoke APDU is not answered), the Remote PINX shall enter state RemoteIdle and indicate rejection to the PUM user. The Remote PINX is responsible for clearing the call independent signalling connection towards the Home PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T5. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.8

Signalling procedures for enquiry to a Directory PINX Examples of message sequences are shown in annex B.

6.8.1 6.8.1.1

Actions at a PINX for enquiry to a Directory PINX The SDL representation of these procedures is shown in C.4 of annex C. Normal procedures In order to make an enquiry to a Directory PINX to translate an identifier provided by the PUM user into a PISN number (the PUM number), the PINX may send a pisnEnquiry invoke APDU to the Directory PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in 7.3 of ECMA-165. Within the argument of the invoke APDU, element alternativeId shall contain the identifier provided by the PUM user. The PINX shall enter state Enquiry and start timer T2. NOTE 19 The number to be used in the Called party number information element when establishing the call independent signalling connection to the Directory PINX is outside the scope of this Standard. On receipt of the pisnEnquiry return result APDU, the PINX shall stop timer T2. The PISN number received in the pisnEnquiry return result APDU can be used e.g. for registration. The PINX is responsible for clearing the call independent signalling connection towards the Directory PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.8.1.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a pisnEnquiry return error or reject APDU from the Directory PINX, the PINX shall stop timer T2 and enter state Idle. If timer T2 expires, the PINX shall enter state Idle.

- 21 -

NOTE 20 If, in any of these situations the PINX is unable to proceed, it should indicate rejection to the PUM user or answer a received invoke APDU with an appropriate return error APDU, respectively, unless there is another means available for obtaining the PISN number of the PUM user. The PINX is responsible for clearing the call independent signalling connection towards the Directory PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T2. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.8.2

Actions at the Directory PINX for enquiry The SDL representation of procedures at the Directory PINX is shown in C.4 of annex C.

6.8.2.1

Normal procedures On receipt of a pisnEnquiry invoke APDU using the call reference of a call independent signalling connection (as specified in 7.3 of ECMA-165), the Directory PINX shall attempt to translate the PUM user’s identity received in the pisnEnquiry invoke APDU to a PISN number. The PUM user’s PISN number shall be returned in a pisnEnquiry return result APDU.

6.8.2.2

Ex c e p t io n a l p r o c e d u r e s If the Directory PINX is unable to translate the identity received in the pisnEnquiry invoke APDU, a pisnEnquiry return error APDU containing the error invalidServedUserNr shall be returned.

6.9

SS-PUMR impact of interworking with public ISDNs Not applicable.

6.10

SS-PUMR impact of interworking with non-ISDNs Not applicable.

6.11

Protocol interactions between SS-PUMR and other supplementary services and ANFs This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had been published at the time of publication of this Standard. For interactions with supplementary services and ANFs for which stage 3 standards are published subsequent to the publication of this Standard, see those other stage 3 standards. NOTE 21 Simultaneous conveyance of APDUs for SS-PUMR and other supplementary services or ANFs in the same message, each in accordance with the requirements of its respective stage 3 standard, does not, on its own, constitute a protocol interaction.

6.11.1

Interaction with Calling Name Identification Presentation (SS-CNIP) No interaction.

6.11.2

Interaction with Connected Name Identification Presentation (SS-CONP) No interaction.

6.11.3

I n t e r a c t io n wit h C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) No interaction.

6.11.4

I n t e r a c t io n wit h C a ll F o r wa r d in g Bu s y ( S S - C F B) No interaction.

6.11.5

I n t e r a c t io n wit h C a ll F o r wa r d in g N o R e p ly ( S S - C F N R ) No interaction.

6.11.6

Interaction with Call Deflection (SS-CD) No interaction.

6.11.7

Interaction with Path Replacement (ANF-PR) No interaction.

- 22 -

6.11.8

I n t e r a c t io n wit h C a ll Tr a n s f e r ( S S - C T) No interaction.

6.11.9

Interaction with Call Completion to Busy Subscriber (SS-CCBS) No interaction. NOTE 22 SS-CCBS may need to be cancelled if the PUM user (as either the calling user or called user) changes location or de-registers.

6 . 1 1 . 1 0 I n t e r a c t i o n wit h C a l l C o m p l e t i o n o n N o R e p l y ( S S - C C N R ) No interaction. NOTE 23 SS-CCNR may need to be cancelled if the PUM user (as either the calling user or called user) changes location or de-registers. 6 . 1 1 . 1 1 I n t e r a c t i o n wit h C a l l O f f e r ( S S - C O ) No interaction. 6 . 1 1 . 1 2 I n t e r a c t i o n wit h D o N o t D i s t u r b ( S S - D N D ) No interaction. 6.11.13 Interaction with Do Not Disturb Override (SS-DNDO) No interaction. 6 . 1 1 . 1 4 I n t e r a c t i o n wit h C a l l I n t r u s i o n ( S S - C I ) No interaction. 6.11.15 Interaction with Call Interception (ANF-CINT) No interaction. 6 . 1 1 . 1 6 I n t e r a c t io n wit h Tr a n s it C o u n t e r ( A N F - TC ) No interaction. 6 . 1 1 . 1 7 I n t e r a c t io n wit h R e c a ll ( S S - R E) No interaction. 6 . 1 1 . 1 8 I n t e r a c t io n wit h A d v ic e O f C h a r g e ( S S - A O C ) No interaction. 6.11.19 Interaction with Wireless Terminal Incoming Call (SS-WTMI) No interaction. 6.11.20 Interactions with Wireless Terminal Outgoing call (SS-WTMO) No interaction. 6 . 1 1 . 2 1 I n t e r a c t i o n s w i t h W i r e l e s s T e r m in a l L o c a t i o n R e g i s t r a t i o n ( S S - W T L R ) Interactions with WTLR occur when a PUM user is registered at a WT and the WT changes location as well as in case of an initial remote registration at a WT. An example message sequence is shown in annex B. 6 . 1 1 . 2 1 . 1 A c t io n s a t t h e p r e v io u s V is it o r P I N X On receipt of a locationDelete invoke APDU from a WTM Home PINX and if the previous Visitor PINX detects by checking its VDB that a PUM user is registered at the corresponding WT, it shall act as a Remote PINX and send a pumRegistr invoke APDU to the WTM Home PINX according to the procedures specified in 6.5.6. The pumRegistr invoke APDU may be sent together with the locationDelete return result APDU in one message. On receipt of a pumDelReg invoke APDU the previous Visitor PINX shall act as specified in 6.5.5.

- 23 -

6.11.21.2 Actions at the WTM Home PINX in case of location update On receipt of a pumRegistr invoke APDU from the previous Visitor PINX, the WTM Home PINX shall act as a Remote PINX and send a corresponding pumRegistr invoke APDU to the new Visitor PINX according to the procedures specified in 6.5.6. On receipt of the pumRegistr return result APDU from the new Visitor PINX, the WTM Home PINX shall act as a Remote PINX as specified in 6.5.6 and additionally send a corresponding pumRegistr return result APDU to the previous Visitor PINX. 6.11.21.3 Actions at the WTM Home PINX in case of initial remote registration On receipt of a pumRegistr invoke APDU from the initiating Remote PINX, the WTM Home PINX shall act as a Remote PINX and send a corresponding pumRegistr invoke APDU to the Visitor PINX according to the procedures specified in 6.5.6. On receipt of the pumRegistr return result APDU from the Visitor PINX, the WTM Home PINX shall act as a Remote PINX as specified in 6.5.6 and additionally send a corresponding pumRegistr return result APDU to the initiating Remote PINX. 6 . 1 1 . 2 1 . 4 A c t io n s a t t h e ( n e w) V is it o r P I N X On receipt of a pumRegistr invoke APDU from the WTM Home PINX, the (new) Visitor PINX shall act as a Visitor PINX in case of remote registration and send a corresponding pumRegistr invoke APDU to the (PUM) Home PINX according to the procedures specified in 6.5.2. 6 . 1 1 . 2 1 . 5 A c t io n s a t t h e ( P U M ) H o m e P I N X On receipt of a pumRegistr invoke APDU from the (new) Visitor PINX, the Home PINX shall send a pumRegistr return result APDU to the Visitor PINX and a pumDelReg invoke APDU to the previous Visitor PINX according to the procedures specified in 6.5.3 (if applicable). 6.11.22 Interactions with Wireless Terminal Authentication of the WTM User (SS-WTAT) No interaction. 6.11.23 Interactions with Wireless Terminal Authentication of the PISN (SS-WTAN) No interaction. 6 . 1 1 . 2 4 I n t e r a c t io n s wit h M e s s a g e W a it in g I n d ic a t io n ( S S - M W I ) 6 . 1 1 . 2 4 . 1 A c t io n s a t t h e H o m e P I N X f o r r e g is t r a t io n On receipt of a pumRegistr invoke APDU containing the request for an InCall or AllCall registration and if any stored mwiActivate invoke APDU for that PUM user is available, the Home PINX shall send a mwiActivate invoke APDU to the Visitor PINX, in addition to the pumRegistr return result APDU which is sent to the Visitor PINX or, in case of remote registration, to the Remote PINX, according to 6.5.3. On receipt of a mwiActivate invoke APDU together with the pumDelReg return result APDU from a previous Visitor PINX, the Home PINX shall forward the mwiActivate invoke APDU to the (new) Visitor PINX if available. If no PINX is identified as the PUM user's Visitor PINX (i.e., the PUM user is not currently registered), the Home PINX shell either store the mwiActivate invoke APDU until the start of the next registration session or ignore it. 6 . 1 1 . 2 4 . 2 A c t io n s a t t h e p r e v io u s V is it o r P I N X f o r r e g is t r a t io n On receipt of a pumDelReg invoke APDU and if any stored mwiActivate invoke APDU for that PUM user is available, the previous Visitor PINX shall send a mwiActivate invoke ADPU together with the pumDelReg return result APDU to the Home PINX according to 6.5.5. 6 . 1 1 . 2 4 . 3 A c t io n s a t t h e V is it o r P I N X f o r d e - r e g is t r a t io n On receipt of a pumDelReg invoke APDU and if any stored mwiActivate invoke APDU for that PUM user is available, the Visitor PINX shall send a mwiActivate invoke ADPU together with the pumDelReg return result APDU to the Home PINX according to 6.6.1. 6 . 1 1 . 2 5 I n t e r a c t i o n s wit h C o m m o n I n f o r m a t i o n ( A N F - C M N ) No interaction.

- 24 -

6 . 1 1 . 2 6 I n t e r a c t io n s wit h C a ll P r i o r i t y I n t e r r u p t i o n ( S S - C P I ) No interaction. 6 . 1 1 . 2 7 I n t e r a c t io n s wit h C a ll P r io r it y I n t e r r u p t i o n P r o t e c t i o n ( S S - C P I P ) No interaction.

6.12

SS-PUMR parameter values (timers) The following timers apply:

6.12.1

Timer T1 Timer T1 operates at the Visitor PINX during state VisitReg and at the Remote PINX during state RemoteReg. Its purpose is to protect against the absence of a response to the pumRegistr invoke APDU. Timer T1 shall have a value not less than 15 s.

6.12.2

Timer T2 Timer T2 operates at the PINX during state Enquiry. Its purpose is to protect against the absence of a response to the pisnEnquiry invoke APDU. Timer T2 shall have a value not less than 15 s.

6.12.3

Timer T3 Timer T3 operates at the Visitor PINX during state VisitDe-reg and at the Remote PINX during state RemoteDe-reg. Its purpose is to protect against the absence of a response to the pumDe-reg invoke APDU. Timer T3 shall have a value not less than 15 s.

6.12.4

Timer T4 Timer T4 operates at the Home PINX during state HomeDelete. Its purpose is to protect against the absence of a response to the pumDelReg invoke APDU. Timer T4 shall have a value not less than 15 s.

6.12.5

Timer T5 Timer T5 operates at the Visitor PINX during state VisitInterrogation, at the Remote PINX during state RemoteInterrogation, and at the Home PINX during state HomeInterrogation. Its purpose is to protect against the absence of a response to the pumInterrog invoke APDU. Timer T5 shall have a value not less than 15 s.

- 25 -

Annex A ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) proforma

A.1

Introduction The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use: − by the protocol implementor, as a check list to reduce the risk of failure to conform to the Standard through oversight; − by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard's PICS proforma; − by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICS's; − by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.

A.2

Instructions for completing the PICS proforma

A.2.1

General structure of the PICS proforma The PICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. Each item is identified by an item number, the name of the item (question to be answered), and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: m

mandatory (the capability is required for conformance to the protocol);

optional (the capability is not required for conformance to the protocol, but if the capability is implemented it is required to conform to the protocol specifications);

o.<n>

optional, but support of at least one of the group of options labelled by the same numeral <n> is required;

prohibited;

c.<cond>

conditional requirement, depending on support for the item or items listed in condition <cond>;

<item>:m

simple conditional requirement, the capability being mandatory if item number <item> is supported, otherwise not applicable;

<item>:o

simple conditional requirement, the capability being optional if item number <item> is supported, otherwise not applicable.

Answers to the questionnaire items are to be provided either in the "Support" column, by simply marking an answer to indicate a restricted choice (Yes or No), or in the "Not Applicable" column (N/A).

- 26 -

A.2.2

Additional Information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception information.

A.2.3

Exception Information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer will be found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.

- 27 -

A.3

PICS proforma for ECMA-282

A.3.1

Implementation Identification

Supplier Contact point for queries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification, e.g., name(s) and version(s) for machines and/or operating systems; system name(s) Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).

A.3.2

Protocol Summary

Protocol version

1.0

Addenda Implemented (if applicable) Amendments Implemented Have any exception items been required (see A.2.3)

Date of Statement

No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)

- 28 -

A.3.3

General

Item

Question/feature

References

Status

N/A

Support

Support of functionality of a Visitor PINX

o.1

Yes[ ] No[ ]

Support of functionality of a Home PINX

o.1

Yes[ ] No[ ]

Support of functionality of a Remote PINX

o.1

Yes[ ] No[ ]

Support of functionality of a Directory PINX

Yes[ ] No[ ]

Support of InCall registration

6.1

c.1

[]

m:Yes[ ]

Support of OutCall registration

6.1

c.2

[]

Yes[ ] No[ ]

Support of AllCall registration

6.1

c.2

[]

Yes[ ] No[ ]

c.1 = IF (A1 OR A2) THEN m, ELSE N/A c.2 = IF (A1 OR A2) THEN o, ELSE N/A

A.3.4

Procedures

Item

Question/feature

References

Status

N/A

Support

Support of generic procedures for the call independent control (connection oriented) of supplementary services as specified in ECMA-165 for an originating and terminating PINX in the Visitor PINX

6.2.1, 6.2.3

A1: m

[]

m:Yes[ ]

Support of generic procedures for the call independent control (connection oriented) of supplementary services as specified in ECMA-165 for an originating and terminating PINX in the Home PINX

6.2.2

A2: m

[]

m:Yes[ ]

Support of generic procedures for the call independent control (connection oriented) of supplementary services as specified in ECMA-165 for an originating PINX in the Remote PINX

6.2.6

A3: m

[]

m:Yes[ ]

Support of generic procedures for the call independent control (connection oriented) of supplementary services as specified in ECMA-165 for a terminating PINX in the Directory PINX

6.2.5

A4: m

[]

m:Yes[ ]

Support of generic procedures for the call independent control (connection oriented) of supplementary services as specified in ECMA-165 for a Transit PINX

6.2.4

Support of signalling procedures for Registration at the Visitor PINX

6.5.1

A1: m

[]

m:Yes[ ]

Support of additional signalling procedures for Remote registration at the Visitor PINX

6.5.2

A1: o

[]

Yes[ ] No[ ]

Yes[ ]

- 29 -

Item

Question/feature

References

Status

N/A

Support

Support of signalling procedures for Registration at the Home PINX

6.5.3

A2: m

[]

m:Yes[ ]

Support of signalling procedures for Delete registration in a Home PINX

6.5.3, 6.6.2

A2: m

[]

m:Yes[ ]

B10

Support of signalling procedures for Delete registration in a previous Visitor PINX

6.5.5

A1: m

[]

m:Yes[ ]

B11

Support of signalling procedures for Registration at the Remote PINX

6.5.6

A3: m

[]

m:Yes[ ]

B12

Support of signalling procedures for De-registration at the Visitor PINX

6.6.1

A1: m

[]

m:Yes[ ]

B13

Support of signalling procedures for De-registration at the Home PINX

6.6.2

A2: m

[]

m:Yes[ ]

B14

Support of signalling procedures for De-registration at the Remote PINX

6.6.4

A3: m

[]

m:Yes[ ]

B15

Support of signalling procedures for Interrogation at the Visitor PINX

6.7.1

A1: o

[]

Yes[ ] No[ ]

B16

Support of signalling procedures for Interrogation at the Home PINX

6.7.2

A2: o

[]

Yes[ ] No[ ]

B17

Support of signalling procedures for Interrogation at the Remote PINX

6.7.3

A3: o

[]

Yes[ ] No[ ]

B18

Support of signalling procedures for Enquiry to a Directory PINX

6.8.1

c.3

[]

Yes[ ] No[ ]

B19

Support of signalling procedures for Enquiry at a Directory PINX

6.8.2

A4: m

[]

m:Yes[ ]

B20

Support of timer for duration of session and counter for number of outgoing calls at a Visitor PINX

6.5.1

A1: o

[]

Yes[ ] No[ ]

B21

Support of the option to leave existing OutCall registrations unaffected at a Home PINX

6.5.3

A2: o

[]

Yes[ ] No[ ]

c.3 = IF (A1 OR A3) THEN o, ELSE N/A

A.3.5

Coding

Item

Question/feature

References

Status

N/A

Support

Sending of pumRegistr invoke and receipt of pumRegistr return result/error by a Visitor PINX

6.3.1

B6:m

[]

Yes[ ]

Sending of pumRegistr invoke and receipt of pumRegistr return result/error by a Remote PINX

6.3.1

B11: m

[]

m:Yes[ ]

Sending of pumDelReg invoke and receipt of pumDelReg return result/error by a Home PINX

6.3.1

B8:m

[]

Yes[ ]

- 30 -

Item

Question/feature

References

Status

N/A

Support

Sending of pumDe-reg invoke and receipt of pumDe-reg return result/error by a Visitor PINX

6.3.1

B12:m

[]

Yes[ ]

Sending of pumDe-reg invoke and receipt of pumDe-reg return result/error by a Remote PINX

6.3.1

B14: m

[]

m:Yes[ ]

Sending of pumInterrog invoke and receipt of pumInterrog return result/error by a Visitor PINX

6.3.1

B15: m

[]

m:Yes[ ]

Sending of pumInterrog invoke and receipt of pumInterrog return result/error by a Remote PINX

6.3.1

B17: m

[]

m:Yes[ ]

Sending of pumInterrog invoke and receipt of pumInterrog return result/error by a Home PINX

6.3.1

B16: m

[]

m:Yes[ ]

Receipt of pumRegistr invoke and sending of pumRegistr return result/error by a Visitor PINX

6.3.1

B7: m

[]

m:Yes[ ]

C10

Receipt of pumRegistr invoke and sending of pumRegistr return result/error by a Home PINX

6.3.1

B8:m

[]

Yes[ ]

C11

Receipt of pumDelReg invoke and sending of pumDelReg return result/error by a Visitor PINX

6.3.1

B10:m

[]

Yes[ ]

C12

Receipt of pumDe-reg invoke and sending of pumDe-reg return result/error by a Home PINX

6.3.1

B13:m

[]

Yes[ ]

C13

Receipt of pumInterrog invoke and sending of pumInterrog return result/error by a Visitor PINX

6.3.1

B15: m

[]

m:Yes[ ]

C14

Receipt of pumInterrog invoke and sending of pumInterrog return result/error by a Home PINX

6.3.1

B16: m

[]

m:Yes[ ]

C15

Sending of pisnEnquiry invoke and receipt of pisnEnquiry return result/error by a PINX

6.3.1

B18: m

[]

m:Yes[ ]

C16

Receipt of pisnEnquiry invoke and sending of pisnEnquiry return result/error by a Directory PINX

6.3.1

B19: m

[]

m:Yes[ ]

- 31 -

A.3.6

Timer

Item

Question/feature

References

Status

N/A

Support

Support of Timer T1 at a Visitor PINX

6.12.1

A1: m

[]

m:Yes[ ]

Support of Timer T1 at a Remote PINX

6.12.1

A3: m

[]

m:Yes[ ]

Support of Timer T2 at a PINX

6.12.2

B18: m

[]

m:Yes[ ]

Support of Timer T3 at a Visitor PINX

6.12.3

A1: m

[]

m:Yes[ ]

Support of Timer T3 at a Remote PINX

6.12.3

A3: m

[]

m:Yes[ ]

Support of Timer T4 at a Home PINX

6.12.4

A2: m

[]

m:Yes[ ]

Support of Timer T5 at a Visitor PINX

6.12.5

B15: m

[]

m:Yes[ ]

Support of Timer T5 at a Remote PINX

6.12.5

B17: m

[]

m:Yes[ ]

Support of Timer T5 at a Home PINX

6.12.5

B16: m

[]

m:Yes[ ]

N/A

Support

A.3.7

Interactions between SS-PUMR and SS-WTLR

Item

Question/feature

References

Status

Support of SS-WTLR

ECMA-302

Support of procedures at a Home PINX for interaction with SS-WTLR

6.11.21.5

E1: m

[]

m:Yes[ ]

Support of procedures at a previous Visitor PINX / Visitor PINX for interaction with SS-WTLR

6.11.21.1 6.11.21.4

E1: m

[]

m:Yes[ ]

N/A

Support

A.3.8

Yes[ ] No[ ]

Interactions between SS-PUMR and SS-MWI

Item

Question/feature

References

Status

Support of SS-MWI

ECMA-242

Support of procedures at a Home PINX for interaction with SS-MWI

6.11.24.1

F1: m

[]

Yes[ ] No[ ]

Support of procedures at a previous Visitor PINX / Visitor PINX for interaction with SS-MWI

6.11.24.2 6.11.24.3

F1: m

[]

m:Yes[ ]

Yes[ ] No[ ]

- 32 -

- 33 -

Annex B ( in f o r ma tiv e )

Examples of Message Sequences

This annex describes some typical message flows for SS-PUMR. The following conventions are used in the figures of this annex. 1.

The following notation is used: Call independent signalling connection message containing SS-PUMR information Call independent signalling connection message without SS-PUMR information Symbolic primitive carrying SS-PUMR information xxx.inv xxx.rr

Invoke APDU for operation xxx Return result APDU for operation xxx

The figures show messages exchanged via Protocol Control between PINXs involved in SS-PUMR. Only messages relevant to SS-PUMR are shown.

Only the relevant information content (e.g. remote operation APDUs, information elements) is listed below each message name. The Facility information elements containing remote operation APDUs are not explicitly shown. Information with no impact on SS-PUMR is not shown.

Some interactions with users are included in the form of symbolic primitives. The actual protocol at the terminal equipment interface is outside the scope of this Standard.

- 34 -

B.1 B.1.1

Successful registration Successful registration using the PUM number Figure B.1 shows an example message flow of successful registration in the case where the PUM number is provided for identification.

PUM user

Visitor PINX

Previous Visitor PINX

Home PINX

SETUP PumRegistr.inv

CALL PROC. CONNECT

SETUP

PumRegistr.rr

PumDelReg.inv

RELEASE REL. COMP.

CALL PROC. CONNECT PumDelReg.rr

RELEASE REL. COMP.

F ig u r e B. 1 - Ex a m p le m e s s a g e f lo w f o r r e g i s t r a t i o n u s i n g t h e P U M n u m b e r NOTE 24 It depends on the contents of the original registration request from Visitor to Home PINX whether the previous OutCall registration(s) shall be deleted. A previous InCall registration will in any case be deleted. Therefore, more than one message with pumDelReg invoke APDUs to more than one Previous Visitor PINX might be required.

- 35 -

B.1.2

Successful registration with additional enquiry to a Directory PINX Figure B.2 shows an example message flow of successful registration in the case where an alternative identifier (rather than the PUM number) is provided for identification, i.e. using an additional procedure with enquiry to the Directory PINX to obtain the PUM user’s PISN number.

PUM user

Visitor PINX

Directory PINX

SETUP PisnEnquiry.inv

CALL PROC. CONNECT PisnEnquiry.rr

RELEASE REL. COMP.

Previous Home PINX

Visitor PINX

SETUP PumRegistr.inv

CALL PROC. CONNECT

SETUP

PumRegistr.rr

PumDelReg.inv

RELEASE

CALL PROC.

REL. COMP.

CONNECT PumDelReg.rr

RELEASE REL. COMP.

F i g u r e B . 2 - E x a m p l e m e s s a g e f l o w f o r r e g i st r a t i o n w i t h e n q u i r y t o a D i r e c t o r y P I N X NOTE 25 It depends on the contents of the original registration request from Visitor to Home PINX whether the previous OutCall registration(s) shall be deleted. A previous InCall registration will in any case be deleted. Therefore, more than one message with pumDelReg invoke APDUs to more than one Previous Visitor PINX might be required.

- 36 -

B.1.3

Successful registration invoked by a Remote PINX Figure B.3 shows an example message flow of successful registration in the case where registration is invoked by a Remote PINX.

PUM user

Remote PINX

Visitor PINX

SETUP PumRegistr.inv

CALL PROC.

CONNECT PumRegistr.rr

RELEASE REL. COMP.

Previous Visitor PINX

Home PINX

SETUP PumRegistr.inv

CALL PROC. CONNECT

SETUP

PumRegistr.rr

PumDelReg.inv

RELEASE REL. COMP.

CALL PROC. CONNECT PumDelReg.rr

RELEASE REL. COMP.

F ig u r e B. 3 - Ex a m p le m e s s a g e f lo w f o r r e g is t r a t io n in v o k e d b y a R e m o t e P I N X NOTE 26 It depends on the contents of the original registration request whether the previous OutCall registration(s) shall be deleted. A previous InCall registration will in any case be deleted. Therefore, more than one message with pumDelReg invoke APDUs to more than one Previous Visitor PINX might be required.

- 37 -

B.2 B.2.1

Successful de-registration Successful local de-registration Figure B.4 shows an example message flow of successful de-registration invoked by (a local PUM user at) the Visitor PINX.

PUM user

Visitor PINX

Home PINX

SETUP PumDe-reg.inv

CALL PROC. CONNECT PumDe-reg.rr

RELEASE REL. COMP.

F ig u r e B. 4 - Ex a m p le m e s s a g e f lo w f o r l o c a l d e - r e g i s t r a t i o n

- 38 -

B.2.2

Successful forced de-registration Figure B.5 shows an example message flow of successful forced de-registration of a particular session requested by an authorized user at the Visitor PINX. authorized user

Visitor PINX

Home PINX

SETUP PumDe-reg.inv

CALL PROC. CONNECT PumDe-reg.rr

RELEASE REL. COMP.

Figure B.5 - Example message flow for forced local de-registration NOTE 27 In case of forced de-registration of all PUM users at a specific hosting address, more than one pumDe-reg invoke APDU to the Home PINX might be required.

- 39 -

B.2.3

Successful conditional de-registration Figure B.6 shows an example message flow of successful conditional de-registration of a particular session. Visitor PINX

Home PINX

SETUP PumDe-reg.inv

CALL PROC. CONNECT PumDe-reg.rr

RELEASE REL. COMP.

F ig u r e B. 6 - Ex a m p le m e s s a g e f lo w f o r c o n d it io n a l d e - r e g is t r a t io n

- 40 -

B.2.4

Successful remote de-registration Figure B.7 shows an example message flow of successful de-registration invoked by (a PUM user at) a Remote PINX. De-registration can be invoked for a single / multiple / all registration sessions of a PUMuser. PUM user

Remote PINX

Home PINX

Visitor PINX

SETUP PumDe-reg.inv

CALL PROC. CONNECT

SETUP

PumDe-reg.rr

PumDelReg.inv

RELEASE REL. COMP.

CALL PROC. CONNECT PumDelReg.rr

RELEASE REL. COMP.

F ig u r e B. 7 - Ex a m p le m e s s a g e f lo w f o r d e - r e g is t r a t io n in v o k e d b y a R e m o t e P I N X NOTE 28 More than one message with pumDelReg invoke APDUs to more than one Visitor PINX might be required. The Remote PINX can also be a Visitor PINX. An enquiry procedure to a Directory PINX may be invoked (if necessary) prior to sending the pumDe-reg invoke APDU to the Home PINX.

- 41 -

B.3

Successful interrogation

B.3.1

Successful local interrogation of registration sessions Figure B.8 shows an example message flow of successful interrogation of registration sessions at the Visitor PINX invoked by a local PUM user. PUM user

Visitor PINX

Home PINX

SETUP PumInterrog.inv

CALL PROC. CONNECT PumInterrog.rr

RELEASE REL. COMP.

F ig u r e B. 8 - Ex a m p le m e s s a g e f lo w f o r s u c c e s s f u l in t e r r o g a t io n o f r e g is t r a t io n s e s s io n s

- 42 -

B.3.2

Successful local interrogation of registration sessions including session parameters Figure B.9 shows an example message flow of successful interrogation of registration sessions including session parameters at the Visitor PINX invoked by a local PUM user. other PUM user

Visitor PINX

Home PINX

SETUP PumInterrog.inv

CALL PROC.

Visitor PINX

SETUP PumInterrog.inv

CALL PROC.

CONNECT CONNECT FACILITY

PumInterrog.rr

RELEASE RELEASE REL. COMP. REL. COMP.

F ig u r e B. 9 - Ex a m p le m e s s a g e f lo w f o r s u c c e s s f u l in t e r r o g a t io n o f r e g is t r a t io n s e s s io n s and session parameters NOTE 29 More than one message with pumInterrog invoke APDUs to more than one other Visitor PINX might be required.

- 43 -

B.3.3

Successful remote interrogation of registration sessions Figure B.10 shows an example message flow of successful interrogation of registration sessions at the Home PINX invoked by a remote PUM user. PUM user

Remote PINX

Home PINX

SETUP PumInterrog.inv

CALL PROC. CONNECT PumInterrog.rr

RELEASE REL. COMP.

F i g u r e B . 1 0 - E x a m p l e m e s s a g e f lo w f o r s u c c e s s f u l r e m o t e i n t e r ro g a t i o n o f r e g i s t r a t i o n s e s s i o n s NOTE 30 An enquiry procedure to a Directory PINX may be invoked (if necessary) prior to sending the pumInterrog invoke APDU to the Home PINX.

- 44 -

B.3.4

Successful remote interrogation of registration sessions and/or session parameters Figure B.11 shows an example message flow of successful interrogation of registration sessions and/or session parameters at the Home PINX invoked by a remote PUM user. PUM user

Remote PINX

Home PINX

SETUP PumInterrog.inv

CALL PROC.

Visitor PINX

SETUP PumInterrog.inv

CALL PROC.

CONNECT CONNECT FACILITY

PumInterrog.rr

RELEASE RELEASE REL. COMP. REL. COMP.

F ig u r e B. 1 1 - Ex a m p le m e s s a g e f lo w f o r s u c c e s s f u l in t e r r o g a t io n o f r e g is t r a t io n s e s s io n s and/or session parameters NOTE 31 More than one message with pumInterrog invoke APDUs to more than one other Visitor PINX might be required. The Remote PINX can also be a Visitor PINX. An enquiry procedure to a Directory PINX may be invoked (if necessary) prior to sending the pumInterrog invoke APDU to the Home PINX.

- 45 -

B.4

Interaction with SS-WTLR Figure B.12 shows an example message flow of interactions of SS-PUMR with SS-WTLR.

Visitor PINX

CTM

PUM

Home PINX

Visitor PINX

LocationUpdate.inv LocationUpdate.rr

LocationDelete.inv LocationDelete.rr PumRegistr.inv

PumRegistr.inv PumRegistr.inv PumDelReg.inv PumRegistr.rr PumRegistr.rr

PumDelReg.rr PumRegistr.rr

F ig u r e B. 1 2 - Ex a m p le m e s s a g e f lo w f o r i n t e r a c t i o n s w i t h W T L R NOTE 32 The locationDelete return result APDU and the pumRegistr invoke ADPU from the previous Visitor PINX may be sent within one message.

- 46 -

- 47 -

Annex C ( in f o r ma tiv e )

Specification and Description Language (SDL) representation of procedures

The diagrams in this annex use the Specification and Description Language defined in ITU-T Recommendation Z.100 (1999). Each diagram represents the behaviour of a SS-PUMR Supplementary Service Control entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Supplementary Service Control entity uses, via the Coordination Function, the services of Generic Functional Procedures Control and Basic Call Control. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a message being sent, the output symbol bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. Where an input symbol represents a primitive from the Coordination Function, and that primitive is the result of a message being received, the input symbol bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. The following abbreviations are used: inv.

invoke APDU

res.

return result APDU

err.

return error APDU

rej.

reject APDU

C.1

SDL representation of SS-PUMR at the Visitor PINX Figures C-1 show the behaviour of a SS-PUMR Supplementary Service Control entity within the Visitor PINX. The source of each input signal is identified in a comment attached to the input symbol and the destination of each output signal is identified in an SDL "TO" statement within the output symbol.

- 48 -

Proc es s VisitorPINX

1(4)

V isitIdle

Re gis tra tion _ R equ e st

/*The p ro ced ure, "Get Us erAd dress" is d ecla re d at t he SD L syste m le ve l so tha t it is a va ilab le t o th e Visito r PIN X a nd the R em ote P IN X */

A dd ition a l inp uts in t his s tat e a re sh ow n o n o th er pa g es

/* Ea ch tim er is s et to t he mi nim um va lue pe rmi tted in su b clause 6 .1 2 */ From PU M Us er

TIM E R T1 := 1 5* s; TIM E R T3 := 1 5* s; TIM E R T5 := 1 5* s;

'ad dress ing in fo availa ble '

Get_ User_ Add res s

No Ye s Ge tU sera ddres s (Alte rn a tive ID, P ISN nu m b er)

P ISN n um b er Fou nd

Set_ _Sess ion_ _Parameters

Be ha vio ur is b e yo nd th e sco pe of th is sta nd ard

Update_ _VDB

Be ha vio ur is b e yo nd th e sco pe of th is sta nd ard

Get_ Interrogation_ Information

Be ha vio ur is b e yo nd th e sco pe of th is sta nd ard

N ot_ Fou nd

Se t_S ess io n _ _P aram e ters

R e gist rat ion _ _ Failure TO P U M_ Us er

S tart_ Tim e r(T1 )

Visit Idle

Pu m Re g is tr.inv TO H om e PIN X

V isit_ R e gistra tion _1

Pu m Re g is tr.re s

S top _ Tim er(T1)

From H o m e PIN X

P um R e gistr.e rr, P um R e gistr.rej

Fro m H om e PIN X

T1 /*E xpiry* /

Sto p _Ti me r(T1 )

Up da te_ VD B

Re gis tra tion _ _S ucce ssf ul TO PU M_ U ser

R eg istratio n_ _ Failure TO PU M _U se r

Re g is tration _ _Fail ure TO PU M _U ser

V isitIdle

F ig u r e C - 1 . 1 a - S D L R e p r e s e n t a t io n o f S S - P U M R e g is t r a t io n a t t h e V is it o r P I N X

- 49 -

Proc es s VisitorPINX

2(4)

V isitIdle

Pu m Re g is tr.inv

A dd ition a l inp uts in t his s tat e a re sh ow n o n o th er pa g es

From Re m ot e P IN X

'ad d res sing in fo availa ble ' Ye s

No Ge tU sera ddre ss (Alte rn a tive ID, P ISN nu m b er)

Fou nd

P ISN n um b er N ot_ Fou nd

Se t_S ess ion _ _P aram ete rs

S tart_ Tim e r(T1 )

P um Re gist r. err TO R e mo te PIN X

Visit Idle

PU M Re gist r. in v TO H om e PIN X

V isit_ R e gistra tion _2

Pu m Re g is tr.re s

S top _ Tim er(T1)

From H o m e PIN X

P um R e gistr.e rr, P um R e gistr.rej

Fro m H om e P IN X

T1 /* Expiry */

Sto p _Ti me r(T1 )

Up da te _VD B

Pu m Re g is tr.re s TO Re m ote PIN X

P um R e gistr.e rr TO R em o te PIN X

Pu m R eg istr.err TO Re m ot ePIN X

V isitIdle

F ig u r e C - 1 . 1 b - S D L R e p r e s e n t a t io n o f S S - P U M R e g i s t r a t i o n a t t h e V i s i t o r P I N X ( c o n t . )

- 50 -

Proc es s VisitorPINX

3(4)

V isitIdle

D e-re gist ra tion re qu est

A dd itio na l inp uts in t his s tat e a re sh ow n o n o th er p ag es

Pu m D elR e g.in v

From PU M U ser

'dele te re g is tra tion po ssib le'

S tart_ Tim e r(T3 )

Fro m H om e PIN X

Yes

Pu m De R eg .in v TO H om e PIN X

U pd ate _ VD B

P um D el Re g.re s TO H om e PIN X

Pu m D elR eg .err TO H om e PIN X

VisitId le

V isit_D e _R eg

Pu mD e R eg. re s

S top _ Tim er(T3)

From H o m e PIN X

P um D e Re g. err, P um D e R eg. re j

Fro m H om e P IN X

T3 /* Expiry */

Sto p _Ti me r(T3 )

Up da te _VD B

De _R e gist rat ion _ _S ucce ssf ul TO PU M_ U ser

D e_ R eg istratio n_ _ Failure TO PU M_ Use r

D e_ Re gist ra tion _ Failure TO PU M _U se r

V isitIdle

F ig u r e C - 1 . 2 - S D L R e p r e s e n t a t io n o f S S - P U M D e - r e g i s t r a t i o n a t t h e V i s i t o r P I N X

- 51 -

Proc es s VisitorPINX

4(4)

V isitIdle

Inte rrog atio n_ R eq ue st

Add itio na l inp uts in t his sta te a re sh ow n o n oth er p ag es

P um In te rro g .inv

From PU M U ser

Fro m H om e PIN X

'i nte rro gat io n po ssib le'

'ad d res sing in fo availa ble ' Ye s

Ye s

Ge t_ In terro g ation _ In fo rm a tion

Ge tU sera ddre ss (Alte rna tive ID, P ISN nu m b er)

P um Int erro g.re s TO H om ePIN X

PISN n um b er

Pu m In terro g. err TO H om e PIN X

Foun d N ot _Fou nd

S ta rt_ Tim e r(T5 )

Pu m Int erro g.in v TO H om e PIN X

In terrog atio n_ Fa ilure TO P U M_ Us er

VisitId le

Vis it Idle

Visit_ Inte rro ga tion

Pu mI nte rro g.res

S to p_ Tim er(T5)

Inte rrog atio n_ R es pon se TO PU M_ U ser

From H o m e PIN X

P um In te rrog .e rr, P um Int errog. re j

fro m H om e PIN X

T5 / *Expiry */

St op _Ti me r(T5)

In terrog atio n_ Fail ure TO P U M_ Use r

Inte rro gat ion _ Failure TO PU M _U se r

V isitIdle

F ig u r e C - 1 . 3 - S D L R e p r e s e n t a t io n o f S S - P U M I n t e r r o g a t io n a t t h e V is it o r P I N X

- 52 -

Figure C-1.4 shows the behaviour of a SS-PUMR Supplementary Service Control entity within a Visitor PINX for the determination of the PUM user's PISN address from an alternative identifier. The source of each input signal is identified in a comment attached to the input symbol and the destination of each output signal is identified in an SDL "TO" statement within the output symbol. Proc edure GetUs erAddres s FP AR IN p um Id IN /OU T a dd re ss

1(1)

A lte rn at iveId , P artyN um b er;

TIME R T2 := 15 *s; /* Min im um va lue pe rm itt ed in s ub claus e 6 .1 2 */

S tart_ Tim e r(T2 )

Pisn Enq u ire y. inv (p um Id ) TO Di rec toryPIN X

PU M R_ En qu iry

Pisn En qu iry.res (a dd re ss)

Fro m D ire cto ry P IN X

S top _ Tim er(T2)

'Ad d res s fo un d'

P isn Enq u iry.e rr, P isnE nq uiry.re j

From D irect ory PIN X

TS / *Expiry*/

St op _Ti me r(T2 )

'Ad dress no t fo u nd '

'A dd re ss no t fo un d'

Figure C-1.4 - SDL Representation of conversion of alternative identifier to PISN number (also used by the Remote PINX)

- 53 -

C.2

SDL representation of SS-PUMR at the Home PINX Figures C-2 show the behaviour of a SS-PUMR Supplementary Service Control entity within the Home PINX. The source of each input signal is identified in a comment attached to the input symbol and the destination of each output signal is identified in an SDL "TO" statement within the output symbol.

Proces s HomePINX

1(5)

Update_ _HDB

Be ha vio ur is b eyo nd th e sco pe of th is sta nd ard

G etLocal_ I nterrogation_ Information

Be ha vio ur is b eyo nd th e sco pe of th is sta nd ard

Delete_ _Regis tration

/* Eac h t ime r is se t to t he m inim u m value p erm itte d in sub cla use 6.1 2 */ TIM E R T4 := 1 5*s ; TIM E R T5 := 1 5*s ;

H om e Id le

P um R e gistr.in v

A dd it ion al in pu ts in th is st ate are sh ow n on o the r pa ge s

Fro m V isitor P IN X

're gist rat ion po ssib le' Yes

U pd ate _H D B

Pu m R eg istr.err TO Visit orPIN X

P um R e gistr.res TO V is it orPIN X

Ho m eId le

H o me _1

F ig u r e C - 2 . 1 a - S D L R e p r e s e n t a t io n o f S S - P U M R e g is t r a t io n a t t h e H o m e P I N X

- 54 -

Proces s HomePINX

2(5)

H o me _ 1

N ew _ R eg istratio n_ Typ e

InC all OR A llC all

Ou tC all

In Ca ll

InC a ll No t_C u rren tly Re gist ered

C urre nt ly_ R eg istre d

A llCa ll C urre nt ly_ R eg istred

C urre nt ly_ R eg istre d

A llCa ll

At _In Ca ll_ R eg istratio n

Cu rren tly_ Re g is tre d

N o t_C u rren tly R e giste re d K ee p_ Cu rren t_ Ou tC all_ _ Re g is tra tion

N o t_C u rren tly R e gist ere d

D ele te _C urrent _ Ou tC all_ _ Re gist ra tion

N o t_C u rren tly R e giste re d

At_ A llC a ll_ Re g is tra tion De lete _ Cu rren t_ OutC a ll_ _R eg istra tio n

K ee p_ Cu rre nt_ Ou tC all_ _ R eg istra tio n

D elet e_ _R e gistrat io n (A llCa ll)

D e lete _ _ R eg istra tio n (InC a ll)

D el ete _ _ Re g is tra tion (InC a ll)

D elet e_ _R e gistrat io n (A llCa ll)

H om e _2

Ho m e_ 2

H om e _2

F ig u r e C - 2 . 1 b - S D L R e p r e s e n t a t io n o f S S - P U M R e g is t r a t io n a t t h e H o m e P I N X ( c o n t . )

- 55 -

Proces s HomePINX

3(5)

H o me _2

Ou tC all C u rre n tly_ R e gistred

N o t_C u rren tly R e gist ere d

At _Ou tC all_ R eg istra tio n

K ee p_ Cu rren t_ Ou tC all_ _ Re g is tra tion

De let e_ C urre nt_ Out Ca ll_ _R e gistrat io n

D ele te_ _R e gist rat ion (OutC a ll)

H o me Idle

H om e Id le

Ho m eId le

F ig u r e C - 2 . 1 c - S D L R e p r e s e n t a t io n o f S S - P U M R e g is t r a t io n a t t h e H o m e P I N X ( c o n t . )

- 56 -

Proces s HomePINX

4(5)

H om e Id le

P u mD e re g. inv

Ad dit ion al in pu ts in th is st ate are sh ow n on o the r pa ge s

Fro m V isitor P IN X

'de reg istra tio n p os sible

Yes

U pd ate _H D B

Pu m D eR e g.e rr TO Visit orPIN X

P um D eR e g.res TO Vis it orPIN X

Ho m eId le

te rm i nat e ot her se ssion s Yes

H o me Idle

H o me _2

Figure C-2.2 - SDL Representation of SS-PUM De-registration at the Home PINX

- 57 -

Proces s HomePINX

5(5)

H om e Id le

P um In te rrog .inv (Int errogP ars)

A dd it ion al in pu ts in th is st ate are sh ow n on o the r pa ge s

Fro m V isitor P IN X o r Re m ote P IN X

'i nte rro gat io n po ssib le' No

Yes

P um In terrog .err TO SE ND E R

Ge tLo ca l_ In terrog atio n_ In fo rm a tion

H om e Idle

H o m eOn ly! In te rrog Pars True

False

S tart_ Tim e rT5)

P um In te rrog .inv TO V is it orPIN X

Se n d t o a ll PIN X s w h ere PU M U se r is reg iste red

H o me _ I nte rrog atio n

P um In terrro g.res , P um In te rrog .err, P um Im te rro g.rej

Fro m V isitor P IN X

T5 / *Expiry */

'all V isito r P IN Xs re spon d ed ' No

Yes

H om e _ In tero gat ion

St op _Ti me r(T5 )

P um Int errog. re s TO S EN D ER

H om e Id le

F ig u r e C - 2 . 3 - S D L R e p r e s e n t a t io n o f S S - P U M I n t e r r o g a t io n a t t h e H o m e P I N X

- 58 -

Figure C-2.4 shows the behaviour of a SS-PUMR Supplementary Service Control entity within the Home PINX for deleting a PUM user's registrations at previous Visitor PINXs. Proc edure Delete_Regis tration

1(1)

FP AR IN R e gTy pe Servi ceO ption ;

St art_ Tim er(T4)

R e gTyp e Ou tC all

A llC all InC all

Co u nt : = Nu m b erOf_ Out Ca ll_R eg istratio ns

P U M De lRe g. inv (InC a ll) TO Old Visito rP IN X

P UM D elR eg .in v (A llCa ll) TO OldV isitorPIN X

PU M D elR eg .in v (Ou tC all) TO OldVisit orPIN X

H om e De let e

Ho m eD ele te

C o unt := C o un t - 1

Else

C o un t 0

H o me D ele te

PU M D elR eg .re s, PU M D elR eg .e rr, PU M De lR eg. re j

'all Old Visito rPIN Xs re spon d ed '

From Old Visito r PIN X

T4 / *Tim e ou t*/

Ye s

S top _ Tim er(T4)

H om e De let e

F ig u r e C - 2 . 4 - S D L R e p r e s e n t a t io n o f S S - P U M r e g i s t r a t i o n d e l e t i o n b y t h e H o m e P I N X

- 59 -

C.3

SDL representation of SS-PUMR at the previous Visitor PINX Figure C-3 shows the behaviour of a SS-PUMR Supplementary Service Control entity within the previous Visitor PINX. The source of each input signal is identified in a comment attached to the input symbol and the destination of each output signal is identified in an SDL "TO" statement within the output symbol.

Proc es s OldV isitorPINX

Delete_ _ Rec ord_ _f rom_VDB

Be ha vio ur is b eyo nd th e sco pe of th is sta nd ard

1(1)

PreV isito rId le

P um D e lR e g. in v

Fro m H om e P IN X

'D e lete reg istra tio n po ssib le' Yes

D ele te_ R eco rd _ _f ro m _V D B

P u mD e lR eg. re s TO H om ePIN X

Pu m D elR e g.e rr TO H om e PIN X

PreV isito rId le

Figure C-3 - SDL Representation of SS-PUMR at the previous Visitor PINX

- 60 -

C.4

SDL representation of the PISN Enquiry procedure Figure C-4 shows the behaviour of a SS-PUMR Supplementary Service Control entity within the Directory PINX. The source of each input signal is identified in a comment attached to the input symbol and the destination of each output signal is identified in an SDL "TO" statement within the output symbol.

Proc es s Direc toryPINX

L ook_Up_ _Addres s

1(1)

Be ha vio ur is b eyo nd th e sco pe of th is sta nd ard

D irecto ryId le

P isnE nq uiry.inv (alte rna tive ID)

Fro m Visit or PIN X

Lo ok_ U p_ Ad dres s (a ltern at iveID , PIS N Nu m b er)

PIS N Nu m be r Va lid

P isnE nq uiry.re s

Inva lid

P isnE nq uiry.err

D irecto ryId le

Figure C-4 - SDL Representation of PISN Enquiry at the Directory PINX

- 61 -

C.5

SDL representation of SS-PUMR at the Remote PINX Figures C-5 show the behaviour of a SS-PUMR Supplementary Service Control entity within the Remote PINX. The source of each input signal is identified in a comment attached to the input symbol and the destination of each output signal is identified in an SDL "TO" statement within the output symbol.

Proces s RemotePINX

G et_ Us er_ A ddres s

1(2)

Re m ote Idle

R e gist rat ion _ R equ es t

/* Eac h Tim er is set to the m inim u m value p erm itte d in sub cla use 6.1 2 */

A dd ition al in p uts in th is st at e a re sh ow n on o th er pa ge s

From PU M Use r

St art_ Tim e r(T1 )

Tim e r T1 := 1 5*s; Tim e r T3 := 1 5*s; P um Re gist r. inv TO V isitorPIN X

R em o te Re g

P um Re gist r.res

St op _Tim er(t1 )

R e gist rat ion _ S uc cess ful TO P U M_ Us er

From Visito r PIN X

P um R eg istr.e rr, Pu m R eg istr.rej

Fro m Vis it or PIN X

T1 /*E xp iry*/

Sto p_ Tim e r(T1 )

R eg istratio n_ Failu re TO PU M _U se r

Re g is tra tion _ Failure TO PU M_ U ser

Re m ote Idle

F ig u r e C - 5 . 1 - S D L R e p r e s e n t a t io n o f S S - P U M R e g is t r a t io n a t t h e R e m o t e P I N X

- 62 -

Process RemotePINX

2(2)

Re m ote Idle

In terrog atio n_ R equ es t

A dd ition al in p uts in th is st at e a re sh own on o th er pa ge s

f rom PUM User

'ad dressin g in fo availa ble ' Yes

No Get UserAd dress (a lte rn at ive ID, P ISNnu mb er)

PI SNnu mbe r Fo un d No t_ Foun d In te rro ga tion _ Failu re TO PUM _Use r

St art_ Tim e r(T5 )

P um In te rrog .in v TO Ho m eP INX

Rem ote Id le

Rem ote Inte rro gat ion

P umIn terrog. re s

St op _Tim er(T5)

In terrog atio n_ S uc cess TO P UM_ Us er

From Hom e P INX

Pu m In terro g. err, Pu m Int erro g.re j

Fro m Hom e PINX

T5 /*E xp iry*/

Sto p_ Tim e r(T5 )

In te rro ga tion _ Failu re TO PUM _Use r

Inte rrog tratio n_ Failure TO PUM_ User

Re m ote Idle

F ig u r e C - 5 . 2 - S D L R e p r e s e n t a t io n o f S S - P U M I n t e r r o g a t io n a t t h e R e m o t e P I N X

- 63 -

Annex D ( in f o r ma tiv e )

Imported ASN.1 Definitions

The content of this annex has been deleted to remove duplicate ASN.1 definitions defined elsewhere.

- 64 -

- 65 -

Annex E ( n o r ma tiv e )

ASN.1 definitions according to ITU-T Recs. X.208 / X.209

This annex lists all ASN.1 modules as they were defined in the second edition of ECMA-282, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the third edition the ASN.1 modules within ECMA-282 comply with ITU-T Recommendations X.680 / X.690. Please note that regardless of which version of these modules is used as a base of a QSIG implementation, the line encoding remains unchanged. Changes in future editions to modules based on X.680 / X.690 ASN.1 are not reflected in the modules in this annex. Ta b le E. 1 - P U M - R e g is t r a t io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 PUM-Registration-Operations { iso (1) standard (0) pss1-pum-registration (17876) pum-registration-operations (0) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operation-Notation { joint-iso-ccitt (2) remote-operations (4) notation (0) } Extension FROM Manufacturer-specific-extension-definition { iso (1) standard (0) pss1-generic-procedures (11582) msi-definition (0) } notAvailable, invalidServedUserNumber, supplementaryServiceInteractionNotAllowed FROM General-Error-List { ccitt recommendation q 950 general-error-list (1) } -- Note: The definition of these errors is reproduced in annex D PartyNumber FROM Addressing-Data-Elements { iso (1) standard (0) pss1-generic-procedures (11582) addressing-data-elements (9) } -- Note: The definition of PartyNumber is reproduced in annex D BasicService FROM Basic-Service-Elements { iso (1) standard (0) pss1-call-diversion (13873) call-diversion-operations (0) } -- Note: The definition of BasicService is reproduced in annex D pisnEnquiry FROM WTM-Location-Registration-Operations { iso (1) standard (0) pss1-location-registration (15429) wtlr-operations (0) }; -- Note: The definition of pisnEnquiry is reproduced in annex D

PumRegistr

::= OPERATION -- Registration (sent from the Visitor PINX to the Home PINX or -from a Remote PINX to the Visitor PINX) ARGUMENT PumRegistrArg RESULT PumRegistrRes ERRORS { invalidServedUserNumber, notAuthorized, unspecified, notAvailable, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, pumUserNotSubscribedToThisServiceOpt, pumUserFailedAuthentication, hostingAddrInvalid }

- 66 -

Ta b le E. 1 - P U M - R e g is t r a t io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) PumDelReg

::= OPERATION -- Delete Registration (sent from the Home PINX to the Previous Visitor PINX) ARGUMENT PumDelRegArg RESULT DummyRes ERRORS { notAvailable, temporarilyUnavailable, unspecified, supplementaryServiceInteractionNotAllowed }

PumDe-reg

::= OPERATION -- De-registration (sent from the Visitor PINX or Remote PINX to the Home PINX) ARGUMENT PumDe-regArg RESULT DummyRes ERRORS { invalidServedUserNumber, notAuthorized, unspecified, supplementaryServiceInteractionNotAllowed, pumUserNotSubscribedToThisServiceOpt, pumUserFailedAuthentication, hostingAddrInvalid, pumUserNotRegistered }

PumInterrog

::= OPERATION -- Interrogation (sent from the Visitor PINX or Remote PINX to the Home PINX and -from the Home PINX to the Visitor PINX) ARGUMENT PumInterrogArg RESULT PumInterrogRes ERRORS { invalidServedUserNumber, notAuthorized, unspecified, supplementaryServiceInteractionNotAllowed, pumUserFailedAuthentication, hostingAddrInvalid, pumUserNotRegistered }

PumRegistrArg ::=

SEQUENCE

PumRegistrRes ::=

SEQUENCE

DummyRes

::=

{ null extension sequOfExtn

CHOICE

NULL, [ 1 ] IMPLICIT Extension, [ 2 ] IMPLICIT SEQUENCE OF Extension }

- 67 -

Ta b le E. 1 - P U M - R e g is t r a t io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) PumDelRegArg ::=

SEQUENCE

PumDe-regArg ::=

SEQUENCE

PumInterrogArg ::= SEQUENCE

- 68 -

Ta b le E. 1 - P U M - R e g is t r a t io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n c lu d e d ) homeInfoOnly BOOLEAN DEFAULT TRUE, -- True = Only Home PINX information (default) -- False = Complete information userPin CHOICE { pumUserPin [6] IMPLICIT UserPin, activatingUserPin [7] IMPLICIT UserPin } OPTIONAL, argExtension PumrExtension OPTIONAL } PumInterrogRes ::= SET SIZE(1..8) OF SEQUENCE { basicService [0] IMPLICIT BasicService OPTIONAL, -- specific basic service or all basic services, -- (Home PINX information) hostingAddr [1] PartyNumber OPTIONAL, -- The PISN number of the hosting user, -- always a Complete Number. -- (Home PINX information) serviceOption [2] IMPLICIT ServiceOption OPTIONAL, -- Type of registration session -- (InCall, OutCall or AllCall) -- (Home PINX information) interrogParams SessionParams OPTIONAL, -- Time left in registration session, -- Number of outgoing calls left -- (Visitor PINX information) argExtension PumrExtension OPTIONAL } AlternativeId ::=

OCTET STRING (SIZE(1..20))

ServiceOption ::=

ENUMERATED

{ inCallRegistration outCallRegistration allCallRegistration

SessionParams ::=

SEQUENCE

{ durationOfSession [ 1 ] IMPLICIT INTEGER OPTIONAL, -- Duration of session in seconds, -- default if omitted: duration of session unlimited. numberOfOutgCalls [ 2 ] IMPLICIT INTEGER OPTIONAL } -- Default if omitted: number of outgoing calls unlimited.

UserPin

::=

OCTET STRING (SIZE(1..20))

PumrExtension

::=

CHOICE

(0), (1), (2) }

{ extension sequOfExtn

[ 4 ] IMPLICIT Extension, [ 5 ] IMPLICIT SEQUENCE OF Extension }

pumRegistr pumDelReg pumDe-reg pumInterrog

PumRegistr PumDelReg PumDe-reg PumInterrog

::= localValue 89 ::= localValue 90 ::= localValue 91 ::= localValue 92

notAuthorized temporarilyUnavailable unspecified Unspecified ::=

ERROR ERROR Unspecified ERROR

::= localValue 1007 ::= localValue 1000 ::= localValue 1008 PARAMETER Extension

pumUserNotSubscribedToThisServiceOpt pumUserFailedAuthentication hostingAddrInvalid pumUserNotRegistered

ERROR ERROR ERROR ERROR

::= localValue 1019 ::= localValue 1020 ::= localValue 1021 ::= localValue 1022

END

-- of PUM-Registration-Operations

Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:

+41 22 849.60.01 [email protected]

Files of this Standard can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.

ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.

ECMA-282 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Private User Mobility (PUM) - Registration supplementary service (QSIG-PUMR) (December 2001)

Related documents