S tandard ECMA-281
3rd Edition - December 2001
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows 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-281
3rd Edition -December 2001
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Private User Mobility (PUM) Registration Supplementary Service (PUMRSD)
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
Ecma-281.doc
14-01-02 10,27
.
Brief History
This Standard is one of a series of standards defining services and signalling procedures 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 Private User Mobility Registration (PUMR) 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. There is currently no equivalent service specified by ITU-T or ETSI for public ISDN. Compared to the 1st Edition of Standard ECMA-281 (published by ECMA in December 1998), the 2nd Edition (published by ECMA in June 2000) incorporated changes to achieve complete alignment with International Standard ISO/IEC 17875:2000(E) published by ISO/IEC in April 2000.
Adopted as 3rd Edition of Standard ECMA-281 by the General Assembly of December 2001.
.
- i -
Table of contents 1
Scope
1
2
Conformance
1
3
References (normative)
1
Definitions E x te r n a l d e f in itio n s A l l C a l l r e g is t r a t i o n A d d itio n a l n e tw o r k f e a tu r e ( A N F ) Alternative identifier D e s tin a tio n n u mb e r H o me D a t a B a s e ( H D B ) H o me P I N X H o s tin g a d d r e s s InCall registration I n c o min g P U M c a l l O r ig in a tin g n u mb e r O u t C a l l r e g is t r a t i o n O u tg o in g P U M c a ll PUM user identity Private User Mobility (PUM) ( P U M) d e - r e g i s t r a t i o n P U M r e g is tr a tio n P U M n u mb e r PUM user Re g is tr a tio n s e s s io n Visitor area Visitor Data Base (VDB) Visitor PINX
2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4
List of acronyms
4
4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 5 6
S S - P U M R s t a g e 1 s p e c if ic a t io n 6 . 1 D e s c r ip tio n 6.1.1 G e n e r a l d e s c r ip tio n 6.1.2 Q u a l i f i c a t i o n s o n a p p l i c a b i l i t y t o t e l e c o mmu n ic a t i o n s e r v i c e s 6.2 Procedure 6.2.1 P r o v is io n /w ith d r a w a l 6.2.2 N o r ma l p r o c e d u r e s 6.2.3 E x c e p tio n a l p r o c e d u r e s 6 . 3 I n te r a c tio n w ith o th e r s u p p le me n ta r y s e r v ic e s a n d A N F s 6.3.1 N u mb e r i d e n t i f i c a t i o n s e r v i c e s ( S S - C L I P , S S - C O L P , S S - C L I R )
5 5 5 5 6 6 6 8 8 8
- ii -
7
6.3.2 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.3.3 C o n n e c t e d N a me I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO N P ) 6.3.4 Ca llin g /Co n n e c te d N a me I d e n tif ic a tio n Re s tr ic tio n ( S S - CN I R) 6.3.5 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.3.6 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.3.7 Call Transfer (SS-CT) 6.3.8 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.3.9 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.3.10 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.3.11 Call Deflection (SS-CD) 6.3.12 P a t h R e p l a c e me n t ( A N F - P R ) 6.3.13 Call Offer (SS-CO) 6.3.14 Call Intrusion (SS-CI) 6.3.15 Do not Disturb (SS-DND) 6.3.16 Do not Disturb Override (SS-DNDO) 6.3.17 A d v ic e o f Ch a r g e ( S S - A O C) 6.3.18 Recall (SS-RE) 6.3.19 Call Interception (ANF-CINT) 6.3.20 T r a n s it Co u n te r ( A N F - T C) 6.3.21 R o u te R e s t r i c t i o n C l a s s ( A N F - R R C ) 6.3.22 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6.3.23 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 i s t r a t i o n ( S S - W T L R ) 6.3.24 W ir e l e s s T e r mi n a l I n c o min g C a l l ( A N F - W T MI ) 6.3.25 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 ( A N F - W T M O ) 6.3.26 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 a W T M U s e r ( S S - W T A T ) 6.3.27 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.3.28 P r i v a t e U s e r M o b i l i t y I n c o min g C a l l ( A N F - P U M I ) 6.3.29 P r i v a t e U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) 6.3.30 C o mmo n I n f o r ma t i o n ( A N F - C MN ) 6.3.31 Call Priority Interruption (Protection) (SS-CPI(P)) 6 . 4 I n te r w o r k in g c o n s id e r a tio n s 6.5 Overall SDL
8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 10 11
S S - P U M R s t a g e 2 s p e c if ic a t io n 7 . 1 F u n c tio n a l mo d e l 7.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 7.1.2 Description of Functional Entities 7.1.3 Re la tio n s h ip o f f u n c tio n a l mo d e l to b a s ic c a ll f u n c tio n a l mo d e l 7 . 2 I n f o r ma t i o n f l o w s 7.2.1 D e f in itio n o f in f o r ma tio n f lo w s 7.2.2 Re la tio n s h ip o f in f o r ma tio n f lo w s to b a s ic c a ll in f o r ma tio n f lo w s 7.2.3 I n f o r ma tio n f lo w s e q u e n c e s 7.3 Functional Entity actions 7.3.1 A c tio n s o f F E 1 7.3.2 A c tio n s o f F E 2 7.3.3 A c tio n s o f F E 3
11 11 11 12 13 13 13 21 21 28 28 28 29
- iii -
7.3.4 A c tio n s o f F E 4 7.3.5 A c tio n s o f F E 5 7.3.6 A c tio n s o f F E 6 7.3.7 A c tio n s o f F E 7 7.3.8 A c tio n s o f F E 8 7 . 4 F u n c t i o n a l e n t i t y b e h a v io u r 7.4.1 Be h a v io u r o f F E 1 7.4.2 Be h a v io u r o f F E 2 7.4.3 Be h a v io u r o f F E 3 7.4.4 Be h a v io u r o f F E 4 7.4.5 Be h a v io u r o f F E 5 7.4.6 Be h a v io u r o f F E 6 7.4.7 Be h a v io u r o f F E 7 7.4.8 Be h a v io u r o f F E 8 7 . 5 A l l o c a t i o n o f F u n c t i o n a l E n t i t i e s t o p h ys i c a l e q u ip me n t 7 . 6 I n te r w o r k in g c o n s id e r a tio n s
29 29 30 30 30 31 31 33 36 37 41 44 45 46 47 47
- iv -
.
1
Scope This Standard specifies the Supplementary Service (SS) Private User Mobility Registration (PUMR), which is applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. SS-PUMR is a supplementary service that 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 wired and wireless terminals 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. Supplementary service specifications are produced in three stages, according to the method described in ITU-T Rec. I.130. This Standard contains the stage 1 and stage 2 specifications of SS-PUMR. The stage 1 specification (clause 6) specifies the general feature principles and capabilities. The stage 2 specification (clause 7) identifies the Functional Entities involved in the supplementary service and the information flows between them.
2
Conformance In order to conform to this Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the supplementary service specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clause 6 (stage 1) and clause 7 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.
3
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-142
Private Integrated Services Network (PISN) - Circuit Mode 64kbit/s Bearer Services Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
ECMA-155
Private Integrated ISO/IEC 11571)
ECMA-185
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Call Completion Supplementary Services (International Standard ISO/IEC 13866)
ECMA-283
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Private User Mobility (PUM) - Call Handling Additional Network Features (International Standard ISO/IEC 17877)
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-303
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Wireless Terminal Call Handling Additional Network Features (International Standard ISO/IEC 15430)
Services
Networks
-
Addressing
(International
Standard
- 2 -
4
ECMA-305
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Wireless Terminal Authentication Supplementary Services (International Standard ISO/IEC 15432)
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.112
Vocabulary of terms for ISDN (1993)
ITU-T Rec. I.210
Principles of telecommunication services supported by an ISDN and the means to describe them (1993)
ITU-T Rec. Z.100
Specification and description language (1999)
Definitions For the purposes of this Standard the following definitions apply.
4.1
External definitions This Standard uses the following terms defined in other documents: − Basic service
(ITU-T Rec. I.210)
− Call (Basic call)
(ECMA-142)
− PISN Number
(ECMA-155)
− Private Integrated Services Network (PISN)
(ECMA-133)
− Private Integrated services Network eXchange (PINX)
(ECMA-133)
− Service
(ITU-T Rec. I.112)
− Signalling
(ITU-T Rec. I.112)
− Supplementary Service
(ITU-T Rec. I.210)
− User
(ECMA-142)
This Standard refers to the following basic call Functional Entities (FE) defined in ECMA-142: − Call Control (CC) − Call Control Agent (CCA) This Standard refers to the following basic call inter-FE relationships defined in ECMA-142: − r1 − r2 − r3 This Standard refers to the following basic call information flows defined in ECMA-142: − SETUP request/indication − SETUP response/confirm − RELEASE request/indication This Standard refers to the following service elements defined for basic call control in ECMA-142: − Call History − Connection Type − Destination Number − Destination Subaddress
- 3 -
− Originating Number − Originating Subaddress
4.2
AllCall registration PUM registration for both incoming and outgoing calls. These two components are combined into a single service option, and cannot be separated.
4.3
Additional network feature (ANF) A capability provided by a PISN, not generally directly to a User, over and above that of the Basic call.
4.4
Alternative identifier An identifier, other than the PISN number, which identifies the PUM user uniquely.
4.5
Destination number The PISN number of the original called user.
4.6
Home Data Base (HDB) The database in which the data on the current location and associated parameters of a wireless terminal or a mobile user are stored.
4.7
Home PINX The PINX that has direct access to the HDB entry for a particular PUM user.
4.8
Hosting address The complete PISN number of the entity within the network to which incoming calls for the PUM user are directed by the Home PINX (i.e., the address where a PUM user is currently registered).
4.9
InCall registration PUM registration for incoming calls.
4.10
Incoming PUM call A call where the called user is a PUM user.
4.11
Originating number The PISN number of the user initiating a call.
4.12
OutCall registration PUM registration for outgoing calls.
4.13
Outgoing PUM call A call originated by a PUM user.
4.14
PUM user identity A PUM number or alternative identifier used to uniquely identify the PUM user.
4.15
Private User Mobility (PUM) The capability of a PISN user to register at any PISN terminal, and so receive the PISN services at the hosting terminal.
4.16
(PUM) de-registration The process whereby a PUM registration is cancelled.
4.17
PUM registration The operation performed by a PUM user to inform the PISN of the PISN address that should be used for locating the user.
4.18
PUM number A number which uniquely identifies a PUM user. This is the number used by the caller to reach the PUM user.
- 4 -
4.19
PUM user For the purpose of this Standard, a PUM user is defined as the user of the SS-PUMR supplementary service.
4.20
Registration session The period following registration at a hosting address that the PUM user is registered to make calls, receive calls, or make and receive calls.
4.21
Visitor area The coverage area of a visitor data base.
4.22
Visitor Data Base (VDB) The database in which location information concerning a wireless terminal or a mobile user is stored, as long as the wireless terminal or the mobile user are localized in the corresponding visitor area.
4.23
Visitor PINX The PINX that has direct access to the VDB currently associated with a particular PUM user.
5
List of acronyms ANF
Additional Network Feature
AOC
Advice Of Charge
CC
Call Control (Functional Entity)
CCA
Call Control Agent (Functional Entity)
CCBS
Call Completion to Busy Subscriber
CCNR
Call Completion on No Reply
CD
Call Deflection
CFB
Call Forwarding Busy
CFNR
Call Forwarding No Reply
CFU
Call Forwarding Unconditional
CI
Call Intrusion
CICL
Call Intrusion Capability Level
CINT
Call INTerception
CLIP
Calling Line Identification Presentation
CLIR
Calling/Connected Line Identification Restriction
CMN
CoMmoN Information
CNIP
Calling Name Identification Presentation
CNIR
Calling/Connected Name Identification Restriction
CO
Call Offer
COLP
Connected Line Identification Presentation
CONP
Connected Name Identification Presentation
CPI
Call Priority Interruption
CPICL
Call Priority Interruption Capability Level
CPIP
Call Priority Interruption Protection
CPIPL
Call Priority Interruption Protection Level
- 5 -
6
CT
Call Transfer
DND
Do Not Disturb
DNDO
Do Not Disturb Override
FE
Functional Entity
FEA
Functional Entity Action
HDB
Home Data Base
ISDN
Integrated Services Digital Network
MWI
Message Waiting Indication
PIN
Personal Identification Number
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
PR
Path Replacement
PUM
Private User Mobility
PUMI
PUM Incoming Call Handling
PUMO
PUM Outgoing Call Handling
PUMR
Private User Mobility Registration
RE
REcall
SDL
Specification and Description Language
SS
Supplementary Service
TC
Transit Counter
TE
Terminal Equipment
VDB
Visitor Data Base
WT
Wireless Terminal
WTAU
Wireless Terminal AUthentication
WTLR
Wireless Terminal Location Registration
WTM
Wireless Terminal Mobility
WTM
Wireless Terminal Mobility
WTMI
Wireless Terminal Mobility Incoming call
WTMO
Wireless Terminal Mobility Outgoing call
SS-PUMR stage 1 specification
6.1 6.1.1
Description General description PUM Registration (PUMR) identifies to the PISN the address at which a PUM user will subsequently make calls, receive calls or make and receive calls. A request to register a PUM user at an address can be rejected. SS-PUMR also allows a PUM user to indicate to the PISN that the existing registration at the hosting address is to be terminated (de-registration).
6.1.2
Qualifications on applicability to telecommunication services SS-PUMR is applicable to all basic services defined in ECMA-142.
- 6 -
6.2
Procedure
6.2.1
P r o v is io n /wit h d r a wa l SS-PUMR shall be provided and withdrawn by arrangement with the PISN authority on a per PISN number basis. This service may be provided separately for each basic service subscribed to. The mandatory and optional PUMR service options in a PISN are specified in table 1. Table 1 - Service options for PUM registration Service option
Status
Registration for incoming calls (InCall registration)
Mandatory
Registration for outgoing calls (OutCall registration)
Optional
Registration for both incoming and outgoing calls (AllCall registration)
Optional
For each of the service options listed in table 1, at least the parameter(s) specified in table 2 shall be supported. Table 2 - Parameters for the service options Service option
Parameter(s)
InCall registration
Maximum duration of each InCall registration session
OutCall registration
Maximum duration of each OutCall registration session, or maximum number of outgoing calls per OutCall registration session
AllCall registration
Maximum duration of each AllCall registration session
In a PISN where the PUM user is not required to specify a service option parameter, the session may continue indefinitely until it is either terminated by the PISN or a PISN user. 6.2.2 Normal procedures 6.2.2.1 A c t iv a t io n , d e a c t iv a t io n a n d in t e r r o g a t io n SS-PUMR shall be activated on provision and deactivated on withdrawal on a per PISN number basis. The PUMR service may provide the PUM user with the ability to obtain information on the current registration sessions (interrogation). If interrogation is supported, it shall be possible to obtain the addresses of all current registration sessions, optionally requested on a per service option basis. Furthermore, the PUM user may be provided with the ability to request the following items of information for a specified registration session: − Type of the registration session (InCall, OutCall, or AllCall); − Time left in the registration session (if applicable); − Number of outgoing calls left in the registration session (if applicable). 6.2.2.2
I n v o c a t io n a n d o p e r a t io n SS-PUMR shall be invoked to register the PUM user at a specified address. If, at the time of invocation, more than one of the options listed in table 1 are available, the PUM user shall indicate which option to select. Upon successful completion of SS-PUMR, an indication of successful completion shall be sent to the PUM user.
- 7 -
6.2.2.2.1
R e g is t r a t io n f o r in c o m in g c a lls ( I n C a ll r e g is t r a t io n ) The PUM user may specify the duration of the InCall registration session. A PISN may support InCall registration sessions for one or more PUM users concurrently at the same hosting address. Upon successful completion of an InCall registration, the PISN shall terminate the PUM user's previous InCall registration session (if applicable). Similarly, upon successful completion of an InCall registration, the PISN shall terminate the PUM user's previous AllCall registration session (if applicable). The invocation of an InCall registration may leave the PUM user's existing OutCall registration session (if applicable) unaffected.
6.2.2.2.2
R e g is t r a t io n f o r o u t g o in g c a lls ( O u t C a ll r e g is t r a t io n ) The PUM user may specify the number of outgoing calls or the duration of the OutCall registration session. A PISN may support OutCall registration sessions for one or more PUM users concurrently at the same hosting address. Upon successful completion of an OutCall registration, the PISN may leave the PUM user's existing OutCall, InCall, and AllCall registration sessions (if applicable) unaffected.
6.2.2.2.3
R e g is t r a t io n f o r b o t h in c o m in g a n d o u t g o in g c a lls ( A llC a ll r e g is t r a t io n ) The PUM user may specify the duration of the AllCall session. A PISN may support AllCall registration sessions for one or more PUM users concurrently at the same hosting address. Upon successful completion of an AllCall registration, the PISN shall terminate the PUM user's previous AllCall registration session (if applicable). Similarly, upon successful completion of an AllCall registration, the PISN shall terminate the PUM user's previous InCall registration session (if applicable). The invocation of an AllCall registration may leave the PUM user's existing OutCall registration session (if applicable) unaffected.
6.2.2.2.4
Local and remote registration It shall be possible to invoke SS-PUMR from the hosting address (local registration). Additionally, as an implementation option, a PISN may allow SS-PUMR to be invoked from a PISN address other than the hosting address (remote registration).
6.2.2.2.5
P U M d e - r e g is t r a t io n SS-PUMR may be invoked to de-register a PUM user from the current hosting address. The following PUM de-registration mechanisms are specified: a) Explicit de-registration: The PUM user shall be able to de-register from the hosting address by means of a manual operation carried out on the hosting address. As an implementation option, the PUM user may be permitted to specify that the de-registration is to apply to: − a specified remote hosting address; − a specified type of registration session; or − all registration sessions regardless of hosting address or type. b) Conditional de-registration: If finite values for the parameters listed in table 2 are supported, the PISN shall de-register the PUM user when a specified criterion is met. c) Forced de-registration: As an implementation option, an authorized user may be permitted to deregister a visiting PUM user by means of a manual operation carried out on the hosting address. Upon successful completion of the de-registration process, the PUM de-registration may be confirmed to the PUM user.
- 8 -
NOTE 1 During a period when a PUM user is not registered at any address, the PISN can assign a default address for incoming and / or outgoing calls. Alternatively, incoming PUM calls can receive implementation-specific processing (e.g., a voice announcement). 6.2.2.2.6
I d e n t if ic a t io n As part of the registration and explicit de-registration procedures, the PUM user shall provide identification which may be either the PUM number or an alternative unique identifier.
6.2.2.2.7
A u t h e n t ic a t io n As part of the registration and explicit de-registration procedures, the PUM user may be required to provide a PIN for authentication. NOTE 2 More complex authentication procedures can be used, but such procedures are outside the scope of this Standard.
6.2.3 Ex c e p t io n a l p r o c e d u r e s 6.2.3.1 A c t iv a t io n , d e a c t iv a t io n , a n d in t e r r o g a t io n Not applicable. 6.2.3.2
I n v o c a t io n a n d o p e r a t io n The invocation of SS-PUMR shall be rejected under at least the following circumstances: − PUM user identity not known; − PUM user not permitted to register on the specified address; − PUM user not subscribed to the specified option or parameter; − PUM user failed authentication; − PUM registration temporarily not possible. An indication of the reason for rejection shall be sent to the PUM user. PUM de-registration shall be rejected if the PUM user is not registered at the specified address.
6.3
Interaction with other supplementary services and ANFs Interactions with other supplementary services and ANFs for which PISN standards were available at the time of publication of this Standard are specified below.
6.3.1
Number identification services (SS-CLIP, SS-COLP, SS-CLIR) No interaction.
6.3.2
Calling Name Identification Presentation (SS-CNIP) No Interaction.
6.3.3
Connected Name Identification Presentation (SS-CONP) No interaction.
6.3.4
C a l l i n g /C o n n e c t e d N a m e I d e n t i f i c a t i o n R e s t r i c t i o n ( S S - C N I R ) No interaction.
6.3.5
Call Completion to Busy Subscriber (SS-CCBS) If the PUM user is either the served (calling) user or the called user in a call completion attempt, the invocation of SS-PUMR may cause call completion to be cancelled.
6.3.6
Call Completion on No Reply (SS-CCNR) If the PUM user is either the served (calling) user or the called user in a call completion attempt, the invocation of SS-PUMR may cause call completion to be cancelled.
6.3.7
C a ll Tr a n s f e r ( S S - C T) No interaction.
- 9 -
6.3.8
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.3.9
C a ll F o r wa r d in g Bu s y ( S S - C F B) No interaction.
6.3.10
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.3.11
C a ll D e f le c t io n ( S S - C D ) No interaction.
6.3.12
Path Replacement (ANF-PR) No interaction.
6.3.13
C a ll O f f e r ( S S - C O ) No interaction.
6.3.14
C a ll I n t r u s io n ( S S - C I ) No interaction.
6.3.15
Do not Disturb (SS-DND) No interaction.
6.3.16
Do not Disturb Override (SS-DNDO) No interaction.
6.3.17
A d v ic e o f C h a r g e ( S S - A O C ) No interaction.
6.3.18
R e c a ll ( S S - R E) No interaction.
6.3.19
Call Interception (ANF-CINT) No interaction.
6.3.20
Tr a n s it C o u n t e r ( A N F - TC ) No interaction.
6.3.21
Route Restriction Class (ANF-RRC) No interaction.
6.3.22
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 ) No interaction.
6.3.23
W i r e l e s s T e r m i n a l L o c a t io n R e g i s t r a t i o n ( S S - W T L R ) The invocation of SS-PUMR may be rejected if attempted between the invocation and completion of the SS-WTLR procedures. The invocation of SS-WTLR shall not cause a PUM registration which may exist on the relevant WT to be cancelled.
6.3.24
Wireless Terminal Incoming Call (ANF-WTMI) An incoming call to a wireless terminal may be rejected if it occurs between the invocation and completion of the SS-PUMR procedures on that terminal.
6.3.25
Wireless Terminal Outgoing Call (ANF-WTMO) No interaction.
6.3.26
Wireless Terminal Authentication of a WTM User (SS-WTAT) The invocation of SS-PUMR may be rejected if attempted between the invocation and completion of the SS-WTAT procedures.
- 10 -
6.3.27
Wireless Terminal Authentication of the PISN (SS-WTAN) The invocation of SS-PUMR may be rejected if attempted between the invocation and completion of the SS-WTAN procedures.
6.3.28
Private User Mobility Incoming Call (ANF-PUMI) An incoming call to a PUM user may be rejected if it occurs between the invocation and completion of the SS-PUMR procedures or if the incoming call occurs during a period of de-registration.
6.3.29
P r i v a t e U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) No interaction.
6.3.30
Common Information (ANF-CMN) No interaction.
6.3.31
C a ll P r io r it y I n t e r r u p t io n ( P r o t e c t i o n ) ( S S - C P I ( P ) ) No interaction.
6.4
Interworking considerations Not applicable.
- 11 -
6.5
Overall SDL Figure 1 contains the dynamic description of SS-PUMR using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1999). The SDL process represents the behaviour of the PISN in providing SS-PUMR.
Process Stage_1
1(1)
SS-PUMR Idle
PUM Registration Request
No
PUM Deregistration Request
From PUM User
Request Acceptable
Request Acceptable
Yes
No
Yes Deregister User From Specified Address
Register User At Specified Address
PUM Registration Indication
From User or Network
PUM Deregistration Indication
To PUM User
To PUM User
SS-PUMR Idle
F ig u r e 1 - S S - P U M R , o v e r a ll S D L
7
SS-PUMR stage 2 specification
7.1 7.1.1
Functional model Functional model description The functional model shall comprise the following Functional Entities (FE): FE1
Service initiating control entity;
FE2
Service control entity;
FE3
PUM user's local service agent entity;
FE4
VDB function control entity;
FE5
HDB function control entity;
FE6
Old VDB function control entity;
FE7
PUM user's old local service agent entity;
- 12 -
FE8
Identification mapping entity.
The following functional relationships shall exist between these FEs: ra between FE1 and FE2; rb between FE2 and FE4; rc between FE3 and FE4; rd between FE4 and FE5; re between FE5 and FE6; rf between FE6 and FE7; rg between FE2 and FE8, and between FE4 and FE8; rh between FE2 and FE5. Figure 2 shows these FEs and relationships.
re
FE5
ra
rb
FE2
rf
FE7
rd
rh FE1
FE6
rg
FE4
rc
FE3
rg FE8
Figure 2 - Functional model for the registration procedures of a PUM user 7.1.2 D e s c r ip t io n o f F u n c t io n a l En t it ie s 7.1.2.1 Service initiating control entity, FE1 This FE initiates and forwards requests for PUM registration, de-registration and interrogation. A request can be initiated by a user or the PISN. 7.1.2.2
Service control entity, FE2 This FE forwards PUM registration, de-registration and interrogation requests and responses between FE1 and FE4, and between FE1 and FE5. FE2 also communicates with FE8 to have alternative identifiers translated into PUM numbers.
7.1.2.3
PUM user's local service agent entity, FE3 This FE serves the PUM user at the hosting address.
7.1.2.4
V D B f u n c t io n c o n t r o l e n t it y , F E4 This FE is responsible for the maintenance of PUM location information while the PUM user is registered in the visitor area. It inserts an entry in the VDB when the PUM user registers in the visitor area, and deletes the entry when the PUM user's registration in the visitor area is cancelled. FE4 also communicates with FE8 to have alternative identifiers translated into PUM numbers. FE4 communicates with FE5 to supply the interrogated registration session information.
7.1.2.5
H D B f u n c t io n c o n t r o l e n t it y , F E5 This FE stores the new visitor area of the PUM user and requests the deletion of location information in the old visitor area (if applicable). FE5 communicates with all FE4s to collect information about the registration sessions when interrogated by FE2.
- 13 -
7.1.2.6
O ld V D B f u n c t io n c o n t r o l e n t it y , F E6 This FE is the VDB function control in the previous visitor area and is responsible for the deletion of location information that is no longer required.
7.1.2.7
P U M u s e r 's o ld lo c a l s e r v ic e a g e n t e n t it y , F E7 This FE is the PUM user's service agent in the previous visitor area.
7.1.2.8
I d e n t if ic a t io n m a p p in g e n t it y , F E8 This FE converts an identity (alternative identifier) supplied by the PUM user to the PUM number.
7.1.3
7.2
R e la t io n s h ip o f f u n c t io n a l m o d e l t o b a s ic c a ll f u n c t io n a l m o d e l The functional model for SS-PUMR is independent of the basic call functional model.
Information flows
7.2.1
7.2.1.1
D e f in it io n o f in f o r m a t io n f lo ws In the tables listing the service elements in information flows, the column headed "Request" indicates which of these elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed "Confirm" (confirmed information flows only) indicates which of these elements are mandatory (M) and which are optional (O) in a response/confirmation information flow. PUM-R PUM-R is a confirmed information flow that is used to perform a PUM registration. PUM-R Requests are sent across relationship ra from FE1 to FE2, relayed by FE2 across relationship rb towards FE4 and then sent across relationship rd towards FE5. Table 3 lists the elements within the PUM-R information flow.
- 14 -
Table 3 - Contents of PUM-R Service element PUM user's identity
Allowed value
Request
- PUM number - alternative identifier
M
Hosting address Basic service indicator
M - a specific basic service - all basic services
Activating user's address Service option
M O (NOTE 3)
- InCall registration - OutCall registration - AllCall registration
Parameter(s) for service option - Duration of the registration session (for InCall, OutCall and AllCall registration) - Number of outgoing calls (for OutCall registration) PUM user's PIN Result
O
O (NOTE 4)
O
O (NOTE 4)
O (NOTE 5) - accepted - rejected
PUM number Cause of rejection
Confirm
M O (NOTE 6)
- PUM user's identity not known; - PUM user not permitted to register at this address; - PUM user not subscribed to this service option or parameter; - PUM user failed authentication; - hosting address invalid.
O (NOTE 7)
NOTE 3 This service element shall be included over relationship rb, and shall not be included over relationship ra. NOTE 4 This service element shall be included if it is present in the corresponding received PUM-R information flow. NOTE 5 This service element is used for authentication purposes, see clause 6.2.2.2. NOTE 6 This service element is mandatory if the result is "accepted". NOTE 7 This service element shall only be included if the result is "rejected".
- 15 -
7.2.1.2
R - D EL This confirmed information flow is used to request the deletion of a PUM user's location information in FE4 or FE6. It is sent across relationship rd from FE5 to FE4 and across relationship re from FE5 to FE6. Table 4 lists the elements within the R-DEL information flow. Table 4 - Contents of R-DEL Service elements
Allowed value
Request
PUM number
M
Hosting address
M
Basic service indicator
- a specific basic service - all basic services
M
Service option
- InCall registration - OutCall registration - AllCall registration - all registrations for this PUM number at this hosting address
M
Result
- accepted - rejected
Cause of rejection
- de-registration not possible - PUM user not registered
NOTE 8 This service element shall only be included if the result is "rejected".
Confirm
M O (NOTE 8)
- 16 -
7.2.1.3
PUM-DR1 This confirmed information flow is used to perform an explicit PUM de-registration at a specific hosting address. PUM-DR1 Requests are sent across relationship ra from FE1 to FE2, and relayed by FE2 across relationship rh towards FE5. Table 5 lists the elements within the PUM-DR1 information flow. Table 5 - Contents of PUM-DR1 Service elements PUM user's identity
Allowed value
Request
- PUM number - alternative identifier
M
Hosting address Basic service indicator
O (NOTE 9) - a specific basic service - all basic services
Activating user's address Service option
Confirm
M O (NOTE 10)
- InCall registration - OutCall registration - AllCall registration - all registrations for this PUM user at specified hosting address(es)
PUM user's PIN
O (NOTE 11)
O (NOTE 12)
Result
- accepted - rejected
Cause of rejection
- PUM user's identity not known; - PUM user not registered; - PUM user failed authentication; - de-registration not possible; - hosting address invalid.
M O (NOTE 13)
NOTE 9 If this service element is omitted, it shall be interpreted as a request to de-register the PUM user at all hosting addresses. NOTE 10 This service element shall be included over relationship rb, and shall not be included over relationship ra. NOTE 11 If this service element is omitted, it shall be interpreted as "all registrations for this PUM user at specified hosting address(es)". NOTE 12 This service element is used for authentication purposes, see clause 6.2.2.2. NOTE 13 This service element shall only be included if the result is "rejected".
- 17 -
7.2.1.4
PUM-DR2 This confirmed information flow is used to perform a conditional PUM de-registration at a specific hosting address. PUM-DR2 Requests are sent across relationship rd from FE4 to FE5. Table 6 lists the elements within the PUM-DR1 information flow. Table 6 - Contents of PUM-DR2 Service elements PUM user's identity
Allowed value - PUM number
Hosting address
Request M M
Basic service indicator
- a specific basic service - all basic services
M
Service option
- InCall registration - OutCall registration - AllCall registration - accepted - rejected
M
Result Cause of rejection
Confirm
- PUM user not registered; - de-registration not possible; - hosting address invalid.
NOTE 14 This service element shall only be included if the result is "rejected".
M O (NOTE 14)
- 18 -
7.2.1.5
PUM-I1 This confirmed information flow is used to perform a PUM service interrogation. PUM-I1 Requests are sent across relationship ra from FE1 to FE2, and (possibly after an inquiry to FE8) relayed by FE2 across relationship rh towards FE5. Table 7 lists the elements within the PUM-I1 information flow. Table 7 - Contents of PUM-I1 Service elements PUM user's identity
Allowed value
Request
- PUM number - alternative identifier
M (NOTE 15)
Hosting address Basic service indicator Interrogation Type
M - a specific basic service - all basic services - basic information - complete information
Activating user's address Service option
M
O
M O (NOTE 16)
- InCall registration - all OutCall registrations - AllCall registration - all registrations
O (NOTE 17)
O (NOTE 18)
O (NOTE 19)
PUM user's PIN Result
Confirm
- accepted - rejected
Basic Interrogation parameter(s) - hosting address(es) - time remaining in Complete Interrogation limited period parameter(s) registration - number of calls remaining in limited call count registration Cause of rejection - PUM user's identity not known; - PUM user not registered; - PUM user failed authentication; - interrogation not allowed.
M O (NOTE 18) O (NOTE 20)
O (NOTE 21)
NOTE 15 Across relationship rh, this value shall be the PUM number. NOTE 16 This service element shall be included over relationship rh, and shall not be included over relationship ra. NOTE 17 If this service element is omitted, it shall be interpreted as "all registrations". NOTE 18 This service element shall only be included if the result is "accepted". NOTE 19 This service element is used for authentication purposes, see clause 6.2.2.2.
- 19 -
NOTE 20 This service element shall only be included in the Confirm information flow if the result is "accepted" and service element "Interrogation type" was set to "complete information" in the corresponding Request information flow. NOTE 21 This service element shall only be included if the result is "rejected". 7.2.1.6
PUM-I2 This confirmed information flow is used to request PUM service information from the Visitor PINX in the case where an interrogation with complete information is specified. PUM-I2 Requests are sent across relationship rd from FE5 to FE4. Table 8 lists the elements within the PUM-I2 information flow. Table 8 - Contents of PUM-I2 Service elements
Allowed value
Request
Confirm
PUM user's identity
- PUM number
M
Basic service indicator
- a specific basic service - all basic services - InCall registration - all OutCall registrations - AllCall registration - all registrations
M
O
O (NOTE 22)
O (NOTE 23)
Service option
Result
- accepted - rejected Basic Interrogation parameter(s) - hosting address(es)
M O (NOTE 24)
Complete Interrogation parameter(s)
- time remaining in limited period registration - number of calls remaining in limited call count registration
O (NOTE 25)
Cause of rejection
- PUM user not registered;
O (NOTE 26)
NOTE 22 If this service element is omitted, it shall be interpreted as "all registrations". NOTE 23 This service element shall only be included in the Confirm information flow if the result is "accepted" and service element "Service option" was set to "all registrations" in the corresponding request information flow. NOTE 24 This service element shall only be included in the Confirm information flow if the result is "accepted" and service element "Service option" was set to "all OutCall registrations" or "all registrations" in the corresponding request information flow. NOTE 25 This service element shall only be included if the result is "accepted". NOTE 26 This service element shall only be included if the result is "rejected".
- 20 -
7.2.1.7
P I S N - EN Q This confirmed information flow is used to request the PUM number for a PUM user identified by an alternative identifier. It shall be sent across relationship rg. Table 9 lists the elements within the PISN-ENQ information flow. Table 9 - Contents of PISN-ENQ Service elements PUM user's identity
Allowed value
Request
alternative identifier
M
PUM number Result
Confirm O (NOTE 27)
- accepted - rejected
M
NOTE 27 This service element is mandatory if the result is "accepted". 7.2.1.8
R-INFO This unconfirmed information flow is used to inform FE3 of a PUM registration. It shall be sent across relationship rc from FE4 to FE3. Table 10 lists the elements within the R-INFO information flow. Ta b le 1 0 - C o n t e n t s o f R - I N F O Service elements
Allowed value
Request
PUM number
M
Basic service indicator
- a specific basic service - all basic services
M
Service option
- InCall registration - OutCall registration - AllCall registration
O (NOTE 28)
Parameter(s) for service option - Duration of the registration session (for InCall, OutCall and AllCall registration) - Number of outgoing calls (for OutCall registration)
O (NOTE 28)
NOTE 28 This service element shall be included if it is available to FE4.
Confirm
- 21 -
7.2.1.9
DR-INFO This unconfirmed information flow is used to inform FE3 or FE7 of a PUM de-registration. It shall be sent across relationship rc from FE4 to FE3 and across relationship rf from FE6 to FE7. Table 11 lists the elements within the DR-INFO information flow. Ta b le 1 1 - C o n t e n t s o f D R - I N F O Service elements
Allowed value
PUM number
Request
Confirm
M
Basic service indicator
- a specific basic service - all basic services
M
Service option
- InCall registration O (NOTE 29) - OutCall registration - AllCall registration - all registrations for this PUM number
NOTE 29 This service element shall be included if it is available to the sending FE. 7.2.2
R e la t io n s h ip o f in f o r m a t io n f lo ws t o b a s ic c a ll in f o r m a t io n f lo ws All SS-PUMR information flows are independent of basic call information flows.
7.2.3
I n f o r m a t io n f lo w s e q u e n c e s A stage 3 standard for SS-PUMR shall provide signalling procedures in support of the information flow sequences specified below. In addition, signalling procedures should be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc. In the figures, SS-PUMR information flows are represented by solid arrows. Within a column representing a SS-PUMR functional entity, the numbers refer to functional entity actions listed in 7.3. The following abbreviations are used: req
request;
ind
indication;
resp
response;
conf
confirm.
- 22 -
7.2.3.1
P U M r e g is t r a t io n d ia g r a m s Figure 3 shows the information flow sequence for PUM registration in the case where the PUM number is provided for identification. User Functions
Visitor Functions
Home Function
Previous Visitor Functions
rh rb FE1 101
FE2
ra PUM-R req/ind
FE3
201
FE4
rc
PUM-R req/ind
401
FE5
rd
202 102
PUM-R resp/conf
301
rf
FE7
PUM-R req/ind PUM-R resp/conf
PUM-R resp/conf
FE6
re
501 R-DEL req/ind
402
R-INFO req/ind
R-DEL resp/conf
502
601 DR-INFO req/ind
701
Figure 3 - PUM registration using the PUM number Figure 4 shows the information flow sequence for PUM registration in the case where an alternative identifier (rather than the PUM number) is provided for identification. U s e r F u n c tio n s
V is ito r F u n c tio n s
H o m e F u n c tio n
P re v io u s V is ito r F u n c tio n s
Id e n tific a tio n F u n c tio n
rg rg
rh rb
FE1 101
ra P U M -R re q /in d
FE2
201
FE3
P U M -R re q /in d
P U M -R re s p /c o n f
202 102
P U M -R re s p /c o n f
rc
301
R -IN F O re q /in d
FE4
rd
401
P IS N -E N Q re q /in d
403
P U M -R re q /in d
402
P U M -R re s p /c o n f
FE5
re
FE6
rf
FE7
FE8
P IS N -E N Q re s p /c o n f 501 R -D E L re q /in d
502
R -D E L re s p /c o n f
601 D R -IN F O re q /in d
701
Figure 4 - PUM registration using an alternative identifier
801
- 23 -
7.2.3.2
P U M d e - r e g is t r a t io n d ia g r a m s Figure 5 shows the information flow sequence for explicit PUM de-registration when a PUM number is provided. User Functions
Visitor Functions
Home Function
rh rb FE1 103
ra PUM-DR1 req/ind
FE2
203
FE3
rc
FE4
rd
PUM-DR1 req/ind R-DEL req/ind DR-INFO resp/conf 302
104
PUM-DR1 resp/conf
204
FE5
503
404 R-DEL resp/conf PUM-DR1 resp/conf
504
Figure 5 - PUM de-registration when the PUM number is provided
- 24 -
Figure 6 shows the information flow sequence for explicit PUM de-registration when an alternative identifier is provided. User Functions
Visitor Functions
Home Function
Identification Function
rg
rh rg
rb
FE1 103
FE2
ra PUM-DR1 req/ind
FE3
203
FE4
rc
FE5
rd
PISN-ENQ req/ind PISN-ENQ resp/conf
205
PUM-DR1 req/ind
503
R-DEL req/ind DR-INFO resp/conf
104
404 R-DEL resp/conf
302
PUM-DR1 resp/conf
FE8
PUM-DR1 resp/conf
204
504
F ig u r e 6 - P U M d e - r e g is t r a t io n a t a n u n s p e c if ie d h o s t in g a d d r e s s when an alternative identifier is provided Figure 7 shows the information flow sequence for conditional PUM de-registration. U ser Functions
Visitor Functions
H om e Function
rh rb
FE1
ra
FE2
FE3
rc
FE 4 405
302
D R -IN FO req/ind
406
rd PU M -D R 2 req/ind PU M -D R 2 resp/conf
F ig u r e 7 - C o n d it io n a l P U M d e - r e g is t r a t io n
FE 5
505
802
- 25 -
7.2.3.3
P U M s e r v ic e in t e r r o g a t io n d ia g r a m s Figures 8 and 9 shows the information flow sequence for a PUM interrogation service. It is assumed that the PUM number is provided. User Functions
Visitor Functions
Hom e Function
rh rb
FE1 105
106
ra PUM -I1 req/ind
PUM -I1 resp/conf
FE2
206
FE3
rc
FE4
FE5
rd
PUM -I1 req/ind PUM -I1 resp/conf
207
506
F ig u r e 8 - P U M in t e r r o g a t io n wh e n b a s ic in f o r m a t io n is r e q u e s t e d
User Functions
Visitor Functions
Home Function
rh rb FE1 105
ra PUM-I1 req/ind
FE2
206
FE3
rc
FE4
rd
PUM-I1 req/ind
410
PUM-I2 req/ind PUM-I2 resp/conf
106
PUM-I1 resp/conf
207
PUM-I1 resp/conf
FE5
506
510
F ig u r e 9 - P U M in t e r r o g a t io n wh e n c o m p le t e in f o r m a t io n is r e q u e s t e d
- 26 -
7.2.3.4
D ia g r a m s f o r c a s e s o f u n s u c c e s s f u l o p e r a t io n Figure 10 shows the information flow sequence for the case where the PUM registration request is rejected by FE4. User Functions
Visitor Functions
Home Function
rh rb
FE1 101
102
ra PUM-R req/ind
PUM-R resp/conf (rejected)
FE2
201
FE3
rc
PUM-R req/ind PUM-R resp/conf (rejected)
202
FE4
FE5
rd
407
Figure 10 - PUM registration rejected by FE4 Figure 11 shows the information flow sequence for the case where the PUM registration request is rejected by FE5. User Functions
Visitor Functions
Home Function
rh rb
FE1 101
ra PUM-R req/ind
FE2
201
202 102
PUM-R resp/conf (rejected)
FE3
rc
PUM-R req/ind
FE4
401
PUM-R resp/conf (rejected)
408
rd
PUM-R req/ind PUM-R resp/conf (rejected)
Figure 11 - PUM registration rejected by FE5
FE5
507
- 27 -
Figure 12 shows the information flow sequence for the case where an explicit PUM de-registration request specifying the PUM number is rejected by FE5. User Functions
Visitor Functions
Hom e Function
rh rb FE1
103
PUM -DR1 req/ind
203
FE4
rc
rd
PUM -DR1 req/ind PUM -DR1 resp/conf (rejected)
204
PUM -DR1 resp/conf (rejected)
104
FE3
FE2
ra
FE5
508
Figure 12 - Explicit PUM de-registration rejected by FE5 Figure 13 shows the information flow sequence for the case where the PUM registration request is rejected by FE2. FE1
ra
101
102
PUM-R req/ind PUM-R resp/conf (rejected)
FE2
208
Figure 13 - PUM registration rejected by FE2 Figure 14 shows the information flow sequence for the case where, following the acceptance of the registration request by FE4 and FE5, the corresponding registration deletion request is rejected by FE6. User Functions
Visitor Functions
Hom e Function
Previous Visitor Functions
rh rb
FE1 101
FE2
ra PUM -R req/ind
201
FE3
rc
PUM -R req/ind
FE4
401
rd
202 102
PUM -R resp/conf
301
R-INFO req/ind
re
FE6
PUM-R req/ind PUM-R resp/conf
PUM -R resp/conf
FE5
501 R-DEL req/ind
402
509
R-DEL resp/conf (rejected)
602
Figure 14 - PUM registration deletion rejected by FE6
rf
FE7
- 28 -
Figure 15 shows the information flow sequence for the case where the PISN enquiry request is rejected by FE8. U s e r F u n c tio n s
V is ito r F u n c t io n s
H o m e F u n c tio n
P r e v io u s V is ito r F u n c tio n s
Id e n tific a tio n F u n c tio n
rg rg
rh rb FE1
101
ra
P U M -R r e q /in d
201
202
102
P U M -R r e s p /c o n f (re je c te d )
FE3
FE2
rc
P U M -R r e q /in d
FE4
401
P U M -R re s p /c o n f ( re je c te d )
rd
FE5
re
FE6
rf
FE8
FE7
P I S N -E N Q r e q /in d
409
P IS N -E N Q r e s p /c o n f ( re je c te d )
803
Figure 15 - PISN enquiry request rejected by FE8
7.3
Functional Entity actions The following FE actions shall occur at the points indicated in the figures of Information flow sequences.
7.3.1
7.3.2
A c t io n s o f F E1 101: The FE shall detect the initiation of PUM registration, and send a PUM-R req/ind information flow to FE2. PUM registration may be initiated by the PUM user or the PISN. 102:
The FE shall receive a PUM-R resp/conf information flow from FE2, and deliver a corresponding indication to the requesting entity.
103:
The FE shall detect the initiation of an explicit PUM de-registration and send a PUM-DR1 req/ind information flow to FE2.
104:
The FE shall receive a PUM-DR1 resp/conf information flow from FE2 and deliver a corresponding indication to the requesting user.
105:
The FE shall detect the initiation of a PUM interrogation and send a PUM-I1 req/ind information flow to FE2.
106:
The FE shall receive a PUM-I1 resp/conf information flow from FE2 and deliver the corresponding information to the requesting user.
A c t io n s o f F E2 201: The FE shall receive a PUM-R req/ind information flow from FE1 and relay it to FE4. 202:
The FE shall receive a PUM-R resp/conf information flow from FE4 and relay it to FE1.
203:
The FE shall receive a PUM-DR1 req/ind information flow from FE1. If the PUM number is provided, the FE shall relay the PUM-DR1 req/ind information flow to FE5. If an alternative identifier is provided, the FE shall send a PISN-ENQ req/ind information flow to FE8.
204:
The FE shall receive a PUM-DR1 resp/conf information flow from FE5 and relay it to FE1.
205:
The FE shall receive a PISN-ENQ resp/conf information flow (accepted) from FE8 and send a PUM-DR1 req/ind information flow including the PUM number to FE5.
206:
The FE shall receive a PUM-I1 req/ind information flow from FE1 and relay it to FE5.
207:
The FE shall receive a PUM-I1 resp/conf information flow from FE5 and relay it to FE1.
208:
The FE shall receive a PUM-R req/ind information flow from FE1 and send a PUM-R resp/conf information flow (rejected) back to FE1.
- 29 -
7.3.3
A c t io n s o f F E3 301: The FE shall receive a R-INFO req/ind information flow from FE4 and deliver a corresponding indication to the user. 302:
7.3.4
7.3.5
The FE shall receive a DR-INFO req/ind information flow from FE4 and deliver a corresponding indication to the user.
A c t io n s o f F E4 401: The FE shall receive a PUM-R req/ind information flow from FE2. If the PUM number is provided, the FE shall pass on the PUM-R req/ind information flow to FE5. If an alternative identifier is provided, the FE shall send a PISN-ENQ req/ind information flow to FE8. 402:
The FE shall receive a PUM-R resp/conf information flow (accepted) from FE5 and shall register the PUM user by adding a corresponding entry in the VDB. The FE shall pass on the PUM-R resp/conf information flow (accepted) to FE2 and send a R-INFO req/ind information flow to FE3.
403:
The FE shall receive a PISN-ENQ resp/conf information flow (accepted) from FE8 and send a PUM-R req/ind information flow to FE5.
404:
The FE shall receive a R-DEL req/ind information flow from FE5 and shall de-register the PUM user by deleting the corresponding entry in the VDB. The FE shall send a R-DEL resp/conf information flow (accepted) to FE5 and a DR-INFO req/ind information flow to FE3.
405:
The FE shall detect a reason for de-registering the PUM user (conditional de-registration) and send a PUM-DR2 req/ind information flow to FE5.
406:
The FE shall receive a PUM-DR2 resp/conf information flow (accepted) from FE5 and shall de-register the PUM user by deleting the corresponding entry in the VDB. The FE shall send a DR-INFO req/ind information flow to FE3.
407:
The FE shall receive a PUM-R req/ind information flow from FE2 and send a PUM-R resp/conf information flow (rejected) containing the cause of rejection to FE2.
408:
The FE shall receive a PUM-R resp/conf information flow (rejected) from FE5 and send a PUM-R resp/conf information flow (rejected) containing the cause of rejection to FE2.
409:
The FE shall receive a PISN-ENQ resp/conf information flow (rejected) from FE8 and send a PUM-R resp/conf information flow (rejected) containing the cause of rejection to FE2.
410:
The FE shall receive a PUM-I2 req/ind information flow from FE5 and shall construct and send a PUM-I2 resp/conf information flow back to FE5.
A c t io n s o f F E5 501: The FE shall receive a PUM-R req/ind information flow from FE4, update the PUM user's entry in the HDB, and send a PUM-R resp/conf information flow (accepted) to FE4. The FE shall send a R-DEL req/ind information flow to FE6. 502:
The FE shall receive a R-DEL resp/conf information flow (accepted) from FE6.
503:
The FE shall receive a PUM-DR1 req/ind information flow from FE2 and send a R-DEL req/ind information flow to FE4.
504:
The FE shall receive a R-DEL resp/conf information flow (accepted) from FE4 and de-register the PUM user by updating the corresponding entry in the HDB. The FE shall send a PUM-DR resp/conf information flow (accepted) to FE2.
505:
The FE shall receive a PUM-DR2 req/ind information flow from FE4 and de-register the PUM user by updating the corresponding entry in the HDB. The FE shall send a PUM-DR2 resp/conf information flow (accepted) to FE4.
506:
The FE shall receive a PUM-I1 req/ind information flow from FE2. If this information flow indicates that only basic information is requested, the FE shall send a PUM-I1 resp/conf information flow (accepted) containing the requested interrogation information back to FE2. If, however, complete information is requested, the FE shall send a PUM-I2 req/ind to FE4.
- 30 -
7.3.6
507:
The FE shall receive a PUM-R req/ind information flow from FE4 and send a PUM-R resp/conf information flow (rejected) containing the cause of rejection to FE4.
508:
The FE shall receive a PUM-DR1 req/ind information flow from FE2 and send a PUM-DR1 resp/conf information flow (rejected) containing the cause of rejection to FE4.
509:
The FE shall receive a R-DEL resp/conf information flow (rejected) from FE6 and take an implementation-specific action.
510:
The FE shall receive a PUM-I2 resp/conf (accepted) PUM-I1 resp/conf (accepted) to FE2.
from
FE4
and
send
a
A c t io n s o f F E6 601: The FE shall receive a R-DEL req/ind information flow from FE5 and de-register the PUM user by deleting the corresponding entry in the VDB. The FE shall send a R-DEL resp/conf information flow (accepted) to FE5 and a DR-INFO req/ind information flow to FE7. 602:
The FE shall receive a R-DEL req/ind information flow from FE5 and send a R-DEL resp/conf information flow (rejected) containing the cause of rejection to FE5.
7.3.7
A c t io n s o f F E7 701: The FE shall receive a DR-INFO req/ind information flow from FE6 and deliver a corresponding indication to the user (if applicable).
7.3.8
A c t io n s o f F E8 801: The FE shall receive a PISN-ENQ req/ind information flow from FE4 and send a PISN-ENQ resp/conf information flow containing the PUM number back to FE4. 802:
The FE shall receive a PISN-ENQ req/ind information flow from FE2 and send a PISN-ENQ resp/conf information flow (accepted) containing the PUM number back to FE2.
803:
The FE shall receive a PISN-ENQ req/ind information flow from FE4 and send a PISN-ENQ resp/conf information flow (rejected) back to FE2.
- 31 -
7.4
Functional entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1999). Each input and output symbol is labelled to show the source FE of input signals or the destination FE of output signals.
7.4.1
Be h a v io u r o f F E1 Figure 16 shows the behaviour of FE1.
Process F E1
1(2)
PU MR_ Idle
'R egistration Reques t'
From u ser
'Deregistration R eques t'
F rom u ser
PUM -R req.ind
To F E2
P UM-D R1 req.ind
To F E2
W ait_ PUM-R
W ait_ PU M-DR
PUM -R resp.c onf (ac c epted)
PUM-R resp.conf (rejected)
F rom FE2
P UM-D R1 res p.c onf (acc epted)
PU M-DR 1 resp.c onf (rejec ted)
From F E2
'indicate reg ist ration ac c eptance'
'ind icate reg is tration rejec tion'
T o us er
'indic ate deregistration acc eptanc e'
'indicate dereg istration rejec tion'
To u ser
PUMR _Idle
PUMR _Idle
F ig u r e 1 6 - S S - P U M R , S D L f o r F E1 - P a r t 1 o f 2
- 32 -
Process F E1
2(2)
PU MR_ Idle
'Interrogation r eques t'
F rom us er
P UM-I1 r eq.ind
T o FE2
W ait_ PUM -I
P UM-I1 r es p.conf ( ac cepted)
F rom FE2
PU M-I1 res p.c onf (rejected)
from FE2
'ind ic ate interrogation r es ult'
To Us er
'indic ate interrogat ion rejecti on'
To U ser
PU MR_ Idle
F ig u r e 1 6 - S S - P U M R , S D L f o r F E1 - P a r t 2 o f 2
- 33 -
7.4.2
Be h a v io u r o f F E2 Figure 17 shows the behaviour of FE2.
Process F E2
1(3)
PUM R_Idle
PU M-R req. ind
F rom FE1
Analys e_ Regis tration_ Parameters
Unac ceptable Regis tration_ status A cc eptable PUM-R resp.conf (rejected)
T o FE1
PU M-R req. ind
To FE4
W ait _ PUM -R
PU MR _Idle
PU M-R res p.c onf (acc epted)
from F E4
PUM -R resp.c onf (rejec ted)
From F E4
PU M-R res p.c onf (acc epted)
To FE1
PUM -R resp.c onf (rejec ted)
To F E1
PUM R_Idle
F ig u r e 1 7 - S S - P U M R , S D L f o r F E2 - P a r t 1 o f 3
- 34 -
Process F E2
2(3) PU MR_ Idle
P UM -DR1 r eq.ind
F rom FE1
A naly se_ DeR egis tration_ Parameters
Un ac cept able Deregis trat ion_ Status Ac ceptable PU M-DR 1 resp.c onf (rejec ted)
To F E1
Not Provided
PUM_ Num ber Provided
PISN-EN Q req.ind
To FE8
W ait_ PISN-ENQ_1
PISN-EN Q res p.c onf (acc epted)
P UM -DR1 r eq.ind
PUMR _Idle
T o FE4
W ait _ PUM -D R
PISN-ENQ res p. c onf (rejec ted)
From F E8
PU M-DR res p. c onf (rejec ted)
To F E1
PUMR _Idle
P UM -DR1 r es p.conf ( ac cepted)
f rom F E4
PU M-D R1 res p. c onf (rejec ted)
From F E4
P UM -DR1 r es p.conf ( ac cepted)
T o FE1
PU M-D R1 res p. c onf (rejec ted)
To F E1
PU MR_ Idle
F ig u r e 1 7 - S S - P U M R , S D L f o r F E2 - P a r t 2 o f 3
- 35 -
Process F E2
3(3) PU MR_ Idle
P UM-I1 r eq.ind
F rom FE1
A naly se_ DeR egis tration_ Parameters
U nacc eptable
Interrog_ Status Ac ceptable
PUM -I1 resp.c onf (rejec ted)
To F E1
Not Provid ed
PUM_ Num ber Provided
PISN-EN Q req.ind
To FE8
W ait_ PISN-ENQ_2
PISN-EN Q res p.c onf (acc epted)
P UM-I1 r eq.ind
PUMR _Idle
T o FE4
W ait _ PUM -I
PISN-ENQ res p. c onf (rejec ted)
From F E8
PU M-I res p. c onf (rejec ted)
To F E1
PUMR _Idle
P UM-I1 r es p.conf ( ac cepted)
f rom F E4
PU M-I1 res p. c onf (rejec ted)
From F E4
P UM-I1 r es p.conf ( ac cepted)
T o FE1
PU M-I1 res p. c onf (rejec ted)
To F E1
PU MR_ Idle
F ig u r e 1 7 - S S - P U M R , S D L f o r F E2 - P a r t 3 o f 3
- 36 -
7.4.3
Be h a v io u r o f F E3 Figure 18 shows the behaviour of FE3.
Process F E3
1(1)
PU MR_ Idle
R-INFO req.ind
DR -IN FO req.ind
From FE 4
Store_Us er_ _Regis tration_ _In formation
Rem ove_Us er_ _Registration_ _In form ation
PU MR_ Idle
F ig u r e 1 8 - S S - P U M R , S D L f o r F E3
F rom F E4
- 37 -
7.4.4
Be h a v io u r o f F E4 Figure 19 shows the behaviour of FE4.
Pro ce ss F E4
1 (4 )
PU MR_ Idle
P UM-R req.ind
F rom FE2
A nalyse_ _R egistration_ _ Param eters
P UM_ N um ber Provided
N ot_Provided
PISN-EN Q req.ind
To FE8
W ait_ PISN-ENQ
PISN-EN Q res p.c onf (acc epted)
PISN-ENQ res p. c onf (rejec ted)
From F E8
PU M-R res p. c onf (rejec ted)
To F E2
Un ac ceptable R egis tration_ Status Acc eptable PUM -R resp.c onf (rejec ted)
PUMR _Idle
To FE 2
P UM-R req.ind
W ait_ PU M-R
T o FE5
PUMR _Idle
F ig u r e 1 9 - S S - P U M R , S D L f o r F E4 - P a r t 1 o f 4
- 38 -
Process F E4
2(4)
W ait_ PU M-R
PUM -R resp.conf (reject ed)
from FE5
PUM -R resp.conf (reject ed)
To FE 2
PU M-R res p. conf (ac cepted)
from F E5
C reate_ _PU M_Us ers_ _VD B En try
PU M-R res p. conf (ac cepted)
T o FE2
R -IN FO req. ind
T o FE3
P eriod of R eg istration
Lim ited
Start_Tim er(T 1)
Unl imited Tim er T1 is set to the p erm itt ed regis tration p eriod for t he PU M user
PU MR_ Idle
F ig u r e 1 9 - S S - P U M R , S D L f o r F E4 - P a r t 2 o f 4
- 39 -
Process F E4
3(4)
PU MR_ Idle
R-DEL req.ind
F rom FE5
Analys e_ _Deletion_ _Parameters
T1 /* Expiry* /
P UM-D R2 req.ind
U nacc eptable
To FE5
W ait_ PU M-DR
D elet ion_ Status Acc eptable
P UM-D R2 res p.c onf (acc ep ted
Stop_Tim er(T1)
R-DEL resp.conf (reject ed)
R-DEL resp.conf (ac cepted)
T o FE5
DR -INF O req.ind
T o FE3
Delet e_ PUM_ _u sers_VD B_ _entry
PU M-D R2 res p.c onf (rejec ted)
'Tak e im pl em ent ations pecific ac tion'
PU MR_ Idle
F ig u r e 1 9 - S S - P U M R , S D L f o r F E4 - P a r t 3 o f 4
F rom F E5
- 40 -
Pro ce ss F E4
4 (4 )
PU MR_ Idle
P UM-I2 req.ind
F rom FE5
A nalys e_ _Interrogation_ _Param eters
No
U ser_ registered Yes
P UM-I2 res p.conf (ac cepted)
T o FE5
PU M-I2 res p.c onf (rejected)
PU MR_ Idle
F ig u r e 1 9 - S S - P U M R , S D L f o r F E4 - P a r t 4 o f 4
To F E5
- 41 -
7.4.5
Be h a v io u r o f F E5 Figure 20 shows the behaviour of FE5.
Process F E5
1(3)
PU MR_ Idle
PUM -R req.ind
P UM-D R2 req. ind
From F E4
Analys e_ _Regis tration_ _Parameters
F rom F E4
A naly se_ _ DeRegistration_ _ Param eters
U nac c eptable Regist ration_ Status
D eregis tration_ Status
Ac c eptable
Acc eptable Up date_ _PUM _Us ers_ _HD B_Entry
Update_ _P UM _Users _ _H DB_ Entry
PUM -R resp.c onf (ac c epted)
R-DE L req.ind
W ait_ R-DEL
R-DE L resp.c onf (ac c epted)
Unacc eptable
PUM-R resp.conf (rejected)
T o FE4
P UM-D R2 res p.c onf (acc epted)
PU M-D R2 resp.c onf (rejec ted)
To F E6
PU MR_ Idle
R-D ELresp.conf (rejected)
PUM R_Idle
F rom FE6
'Tak e im plem en tationspec ific action '
PUM R-Idle
F ig u r e 2 0 - S S - P U M R , S D L f o r F E5 - P a r t 1 o f 3
To F E4
- 42 -
Process F E5
2(3)
PU MR_ Idle
PUM -DR1 req.ind
F rom FE2
A naly se_ Deregis tration_ _ Param eters
U nacc eptable Deregis tration_ Stat us Ac ceptable R-DEL req.ind
T o FE4
W ait_ R -D EL_2
R-DEL resp.conf (ac cepted)
P UM-D R1 res p.c onf (rejected)
To FE2
PUM R_Idle
F rom FE4
R -D EL res p.c onf (rejected)
F rom F E4
T o FE2
P UM-D R1 res p.c onf (rejected)
To FE2
U pdate_ _P UM_ Users_ _H DB_En try
PUM -DR1 resp.conf (ac cepted)
PU MR_ Idle
F ig u r e 2 0 - S S - P U M R , S D L f o r F E5 - P a r t 2 o f 3
- 43 -
Process F E5
3(3)
PUMR _Idle
PU M-I1 req.ind
F rom F E2
Analys e_ _Interogation_ _Parameters
Interogation_ Status
U nacc eptable
Acc eptable
Interrogation_ Ty pe
Com plete
Basic P UM-I2 r eq.ind
T o FE4
PU M-I1 res p.c onf (acc epted)
PUM -I1 resp.c onf (rejec ted)
W ait_ PU M-I2
PUM -I2 resp.c onf (rejec ted
From F E4
P UM-I2 r es p.conf ( ac cepted)
F rom FE4
PUM -I1 resp.c onf (rejec ted)
To F E2
P UM-I1 r es p.conf ( ac cepted)
T o FE2
PU MR_ Idle
PUMR _Idle
F ig u r e 2 0 - S S - P U M R , S D L f o r F E5 - P a r t 3 o f 3
To F E2
- 44 -
7.4.6
Be h a v io u r o f F E6 Figure 21 shows the behaviour of FE6.
Process F E6
1(1)
PU MR_ Idle
R -DEL req.ind
F rom FE5
A nalyse_ _ Deletion_ _ Param eters
Unac ceptable D eletion_ Status Ac cept able D R-INFO req.ind
T o FE7
R -DEL res p.conf (ac cepted)
T o FE5
R -D EL res p.c onf (rejected)
D elete_ _PU M_U sers_ _VD B_Ent ry
PU MR_ Idle
F ig u r e 2 1 - S S - P U M R , S D L f o r F E6
To F E5
- 45 -
7.4.7
Be h a v io u r o f F E7 Figure 22 shows the behaviour of FE7.
Pro ce ss F E7
1 (1 )
PU MR_Idle
D R-INFO req.ind
F rom FE6
Rem ove_ _PUM _Us ers_ _R eg ist ration
PU MR_Idle
F ig u r e 2 2 - S S - P U M R , S D L f o r F E7
- 46 -
7.4.8
Be h a v io u r o f F E8 Figure 23 shows the behaviour of FE8.
Process F E8
1(1)
PU MR_ Idle
PISN -E NQ req.ind
F rom FE 2 or F E4
Loc ate_U ser
No
Us er_ Found Yes Get_Us ers_ _PUM _Num ber
PISN -E NQ resp.conf (ac cepted)
To Sender (F E2 orF E4)
PISN-EN Q res p.c onf (rejected)
PU MR_ Idle
F ig u r e 2 3 - S S - P U M R , S D L f o r F E8
To Send er (FE2 or F E4)
- 47 -
7.5
Allocation of Functional Entities to physical equipment Table 12 shows the allocation of Functional Entities to physical equipment. For the purposes of this table, a Remote PINX denotes a PINX where a remote SS-PUMR invocation is performed. T a b l e 1 2 - S c e n a r i o s f o r t h e a l l o c a t io n o f F E s t o p h y s i c a l e q u i p m e n t
Scenario
FE1 (NOTE 30)
FE2
FE3 (NOTE 31)
FE4
FE5
FE6
FE7
FE8
1
Visitor PINX
Visitor PINX
Visitor PINX
Visitor PINX
Home PINX
Old Visitor PINX
Old Visitor PINX
Directory PINX
2
Remote PINX
Visitor PINX
Visitor PINX
Visitor PINX
Home PINX
Old Visitor PINX
Old Visitor PINX
Directory PINX
3
Visitor PINX
Home PINX
Visitor PINX
Visitor PINX
Home PINX
Old Visitor PINX
Old Visitor PINX
Directory PINX
4
Remote PINX
Home PINX
Visitor PINX
Visitor PINX
Home PINX
Old Visitor PINX
Old Visitor PINX
Directory PINX
5 (NOTE 32)
Old Visitor PINX
any PINX
Visitor PINX
Visitor PINX
Home PINX
Old Visitor PINX
Old Visitor PINX
Directory PINX
6 (NOTE 33)
Remote PINX
any PINX
Visitor PINX
Visitor PINX
Home PINX
Old Visitor PINX
Old Visitor PINX
Directory PINX
NOTE 30 As specified, FE1 cannot reside in a TE. This does not prevent an implementation from putting a proprietary "service initiating function" into a TE, if appropriate. Since such a terminal-specific function communicates with FE1 exclusively via a terminal interface, it is however outside the scope of this Standard. NOTE 31 If the corresponding user's TE is functional with respect to PUMR, this FE may reside in the TE. NOTE 32 This scenario arises only in PISNs which support WTM. It relates to the case of an automatic PUM reregistration when the hosting terminal is a roaming WT. NOTE 33 This scenario arises only in PISNs which support WTM. It relates to the case of a remote PUM registration when the hosting terminal is a WT.
7.6
Interworking considerations Not applicable.
.
.
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.