Standard ECMA-163 3rd E dition - Se ptember 1997
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Name Identification Supplementary Services
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h
.
Standard ECMA-163 3rd E dition - Se ptember 1997
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Name Identification Supplementary Services (NISD)
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h IW Ecma-163.doc
02-09-97 12,09
.
Brief History
This Standard is one of a series of ECMA 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 International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been produced under ETSI work item DE/ECMA-00005. This particular Standard specifies the Calling Name Identification Presentation (CNIP), the Connected Name Identification Presentation (CONP) and the Calling/Connected Name Identification Restriction (CNIR) supplementary services. 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 and 2nd Editions of Standard ECMA-163 (published by ECMA in March 1992 and December 1993 respectively), this 3rd Edition incorporates changes in order to achieve complete alignment with International Standard ISO/IEC 13864:1995(E) published by ISO/IEC in November 1995.
Adopted as 3rd Edition of Standard ECMA-163 by the General Assembly in September 1997.
.
- i -
Table of contents 1 Scope
1
2 Conformance
1
3 References (normative)
1
4 Definitions
2
4.1 External definitions
2
4.2 Other definitions
2
4.2.1 Additional network feature
2
4.2.2 Application identifier
2
4.2.3 Busy
3
4.2.4 Busy party name
3
4.2.5 Call, basic call
3
4.2.6 Calling party name
3
4.2.7 Connected party name
3
4.2.8 Called party name
3
4.2.9 Name
3
4.2.10 Terminal, terminal equipment
3
5 Acronyms
3
6 SS-CNIP Stage 1 Description
3
6.1 Description
3
6.1.1 General Description
3
6.1.2 Qualifications on Applicability to Telecommunication Services
4
6.2 Procedures
4
6.2.1 Provision/Withdrawal
4
6.2.2 Normal Procedures
4
6.2.3 Exceptional Procedures
4
6.3 Interactions with other Supplementary Services and ANFs
4
6.3.1 Connected Name Identification Presentation (CONP)
4
6.3.2 Calling/Connected Name Identification Restriction (CNIR)
4
6.3.3 Calling Line Identification Presentation (CLIP)
4
6.3.4 Connected Line Identification Presentation (COLP)
5
6.3.5 Calling/Connected Line Identification Restriction (CLIR)
5
6.3.6 Call Forwarding Unconditional (CFU)
5
6.3.7 Call Forwarding Busy (CFB)
5
6.3.8 Call Forwarding No Reply (CFNR)
5
6.3.9 Call Deflection (CD)
5
6.3.10 Call Transfer (CT)
5
6.3.11 Completion of Calls to Busy Subscribers (CCBS)
5
6.3.12 Completion of Calls on No Reply (CCNR)
5
- ii -
6.3.13 Path Replacement (ANF-PR)
5
6.4 Interworking Considerations
5
6.4.1 Incoming Calls
5
6.4.2 Outgoing Calls
5
6.5 Overall SDL
5
7 SS-CONP Stage 1 Description
7
7.1 Description
7
7.1.1 General Description
7
7.1.2 Qualifications on Applicability to Telecommunication Services
7
7.2 Procedures
7
7.2.1 Provision/Withdrawal
7
7.2.2 Normal Procedures
7
7.2.3 Exceptional Procedures
8
7.3 Interactions with other Supplementary Services and ANFs
8
7.3.1 Calling Name Identification Presentation (CNIP)
8
7.3.2 Calling/Connected Name Identification Restriction (CNIR)
8
7.3.3 Calling Line Identification Presentation (CLIP)
8
7.3.4 Connected Line Identification Presentation (COLP)
8
7.3.5 Calling/Connected Line Identification Restriction (CLIR)
8
7.3.6 Call Forwarding Unconditional (CFU)
8
7.3.7 Call Forwarding Busy (CFB)
8
7.3.8 Call Forwarding No Reply (CFNR)
8
7.3.9 Call Deflection (CD)
8
7.3.10 Call Transfer (CT)
8
7.3.11 Completion of Calls to Busy Subscribers (CCBS)
8
7.3.12 Completion of Calls on No Reply (CCNR)
9
7.3.13 Path Replacement (PR)
9
7.4 Interworking Considerations
9
7.4.1 Outgoing Calls
9
7.4.2 Incoming Calls
9
7.5 Overall SDL
9
8 SS-CNIR Stage 1 Description
11
8.1 Description
11
8.1.1 General Description
11
8.1.2 Qualifications on applicability to Telecommunication Services
11
8.2 Procedures
11
8.2.1 Provision/Withdrawal
11
8.2.2 Normal Procedures
11
8.2.3 Exceptional Procedures
12
8.3 Interactions with other Supplementary Services and ANFs
12
8.3.1 Calling Name Identification Presentation (CNIP)
12
8.3.2 Connected Name Identification Presentation (CONP)
12
- iii -
8.3.3 Calling Line Identification Presentation (CLIP)
12
8.3.4 Connected Line Identification Presentation (COLP)
12
8.3.5 Calling/Connected Line Identification Restriction (CLIR)
12
8.3.6 Call Forwarding Unconditional (CFU)
12
8.3.7 Call Forwarding Busy (CFB)
12
8.3.8 Call Forwarding No Reply (CFNR)
12
8.3.9 Call Deflection (CD)
12
8.3.10 Call Transfer (CT)
12
8.3.11 Completion of Calls to Busy Subscribers (CCBS)
12
8.3.12 Completion of Calls on No Reply (CCNR)
12
8.3.13 Path Replacement (PR)
12
8.4 Interworking Considerations
12
8.4.1 Incoming Calls
12
8.4.2 Outgoing Calls
13
8.5 Overall SDL
13
9 SS-CNIP Stage 2 Description
15
9.1 Functional Model
15
9.1.1 Functional Model Description
15
9.1.2 Description of the Functional Entities
15
9.1.3 Relationship of the Functional Model to the Basic Call Functional Model
15
9.2 Information Flows
15
9.2.1 Definition of Information Flows
15
9.2.2 Relationship of Information Flows to Basic Call Information Flows
16
9.2.3 Information Flow Sequences
16
9.3 The Functional Entity Actions
17
9.4 Functional Entity Behaviour
17
9.5 Allocation of Functional Entities to Physical Locations
20
10 SS-CONP Stage 2 Description
21
10.1 Functional Model
21
10.1.1 Functional Model Description
21
10.1.2 Description of the Functional Entities
21
10.1.3 Relationship of the Functional Model to the Basic Call Functional Model
21
10.2 Information Flows
21
10.2.1 Definition of Information Flows
21
10.2.2 Relationship of Information Flows to Basic Call Information Flows
24
10.2.3 Information Flow Sequences
25
10.3 Functional Entity Actions
26
10.4 Functional Entity Behaviour
27
10.5 Allocation of Functional Entities to Physical Locations
29
11 SS-CNIR Stage 2 Description
30
11.1 Functional Model
30
11.1.1 Functional Model Description
30
- iv -
11.1.2 Description of the Functional Entities
30
11.1.3 Relationship of the Functional Model to the Basic Call Functional Model
30
11.2 Information Flows
30
11.2.1 Definition of Information Flows
30
11.2.2 Relationship of Information Flows to Basic Call Information Flows
30
11.2.3 Information Flow Sequences
31
11.3 Functional Entity Actions
31
11.4 Functional Entity Behaviour
32
11.5 Allocation of Functional Entities to Physical Locations
34
Annex A - Structure and Content of a PISN Name
35
1
Scope This Standard specifies the supplementary services Calling Name Identification Presentation (SS-CNIP), Connected Name Identification Presentation (SS-CONP) and Calling/Connected Name Identification Restriction (SS-CNIR), which are applicable to various basic services supported by Private Integrated Services Networks (PISNs). Basic services are specified in ECMA-142. Calling Name Identification Presentation (CNIP) is a supplementary service which is offered to the called user and which provides the name of the calling user (calling party name) to the called user. Connected Name Identification Presentation (CONP) is a supplementary service which is offered to the calling user and which provides to the calling user the following: − the name of the user who answers the call (connected party name); − optionally the name of the alerting user (called party name); − optionally the name of the called user who cannot be reached (busy party name). Calling/Connected Name Identification Restriction (CNIR) is a supplementary service which is offered to a user to restrict presentation of that user's name to another user. Service specifications are produced in three stages, according to the method described in ETS 300 387. This Standard contains the stage 1 and 2 specifications of the Name Identification supplementary services. The stage 1 specifications (clauses 6, 7 and 8) specify the supplementary services as seen by users of PISNs. The stage 2 specifications (clauses 9, 10 and 11) identify the functional entities involved in the supplementary services 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 services 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 clauses 6, 7 and 8 (stage 1) and clauses 9, 10 and 11 (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 provisions 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-142
Private Integrated Services Network - Circuit-mode 64 kbit/s Bearer Services - Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
ECMA-173
Private Integrated Services Network - Specification, Functional Model and Information Flows Call Diversion Supplementary Services (International Standard ISO/IEC 13872)
ECMA-178
Private Integrated Services Network - Inter-Exchange Signalling Protocol - Call Transfer Supplementary Service (International Standard ISO/IEC 13869)
ISO/IEC 8859-1
Information processing - 8-bit single-byte coded graphic character sets - Part I: Latin alphabet No.1 (1987)
ISO/IEC 11579-1
Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Part 1: Reference configuration for PISN Exchanges (PINX)
- 2 -
4
ETS 300 387
Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)
ITU-T Rec. I.112
Vocabulary of terms for ISDNs (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 (1993)
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)
− Private Integrated Services Network (PISN)
(ISO/IEC 11579-1)
− Private Integrated Services Network Exchange (PINX)
(ISO/IEC 11579-1)
− 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 defined in ECMA-142: − Call Control (CC) − Call Control Agent (CCA) This Standard refers to the following basic call information flows defined in ECMA-142: − r1 − r2 − r3 This Standard refers to the following basic call information flows defined in ECMA-142: − DISCONNECT request/indication − REPORT request/indication − RELEASE request/indication − SETUP request/indication − SETUP response/confirmation − SETUP REJECT request/indication
4.2 4.2.1
Other definitions Additional network feature A capability, over and above that of a basic service, provided by a PISN, but not directly to a PISN user.
4.2.2
Application identifier Manufacturer specific information which can imply the structure of the name information.
- 3 -
4.2.3
Busy An ISDN destination is considered to be busy if either a "network determined user busy" or a "user determined user busy" conditions occurs.
4.2.4
Busy party name The name of the called user who cannot be reached because of a busy condition.
4.2.5
Call, basic call An instance of the use of a basic service.
4.2.6
Calling party name The name of the calling user.
4.2.7
Connected party name The name of the user who answers the call.
4.2.8
Called party name The name of the alerting user.
4.2.9
Name A string of maximum 50 characters which is used for the name identification of the PISN user of a call. NOTE 1 The structure and content of a name are defined in annex A.
4.2.10
Terminal, terminal equipment An item of equipment attached to a PISN to provide access for a user to one or more services.
5
Acronyms
6
CC
Call Control (functional entity)
CCA
Call Control Agent (functional entity)
CONP
Connected Name Identification Presentation
CNIP
Calling Name Identification Presentation
CNIR
Calling/Connected Name Identification Restriction
FE
Functional Entity
ISDN
Integrated Services Digital Network
PISN
Private Integrated Services Network
PINX
Private Integrated Services Network Exchange
SDL
Specification and Description Language
SS-CONP
Connected Name Identification Presentation supplementary service
SS-CNIP
Calling Name Identification Presentation supplementary service
SS-CNIR
Calling/Connected Name Identification Restriction supplementary service
TE
Terminal Equipment
SS-CNIP Stage 1 Description
6.1 6.1.1
Description General Description Calling Name Identification Presentation (SS-CNIP) is a supplementary service which is offered to the called user and which provides the name of the calling user (calling party name) to the called user.
- 4 -
The PISN provides the calling party name to the called user if available and allowed (according to the restrictions defined in 6.2.3.1) whenever an incoming call is presented. The possible provision of the calling party name by the calling user to the PISN is outside the scope of this Standard. 6.1.2
Qualifications on Applicability to Telecommunication Services This supplementary service is applicable to all basic services defined in ECMA-142.
6.2
Procedures
6.2.1
Provision/Withdrawal This Supplementary service shall be generally available. Some users may have a service profile which permits the override of calling name identification restriction.
6.2.2
Normal Procedures
6.2.2.1
Activation/Deactivation/Registration/Interrogation SS-CNIP shall be permanently activated. No information needs to be registered with the PISN for this supplementary service and therefore interrogation is not applicable.
6.2.2.2
Invocation and Operation The PISN shall provide the called user with the calling party name at the same time as indicating an incoming call. The PISN may truncate the calling party name in accordance with what the user can receive. The method by which the PISN obtains the name information is implementation dependent and outside the scope of this Standard. The management of the PISN name directory system is also outside the scope of this Standard. In some cases where calling name identification restriction has been invoked, there may be certain categories of called user that have the service profile to override this restriction and have the calling party name presented, e.g. emergency stations, PISN operators. In these circumstances, presentation shall include an indication that restriction has been invoked.
6.2.3
Exceptional Procedures
6.2.3.1
Invocation and Operation There are two exceptions when the calling party name shall not be presented to the called user: − when the calling name identification restriction has been invoked (see definition of Calling/Connected Name Identification Restriction), and − when the calling party name is not available, e.g. due to interworking with another network or when no name is registered against the calling PISN user. In such cases the called user shall receive an indication of the situation.
6.3
Interactions with other Supplementary Services and ANFs This clause specifies interactions with other supplementary services and ANFs for which PISN Standards were available at the time of publication of this Standard.
6.3.1
Connected Name Identification Presentation (CONP) No interactions.
6.3.2
Calling/Connected Name Identification Restriction (CNIR) The calling party name shall not be presented if calling name identification restriction has been invoked at the calling user, unless the called user has the service profile to override this restriction.
6.3.3
Calling Line Identification Presentation (CLIP) No interactions.
- 5 -
6.3.4
Connected Line Identification Presentation (COLP) No interactions.
6.3.5
Calling/Connected Line Identification Restriction (CLIR) No interactions.
6.3.6
Call Forwarding Unconditional (CFU) Interaction specified in ECMA-173 shall apply.
6.3.7
Call Forwarding Busy (CFB) Interactions specified in ECMA-173 shall apply.
6.3.8
Call Forwarding No Reply (CFNR) Interactions specified in ECMA-173 shall apply.
6.3.9
Call Deflection (CD) Interactions specified in ECMA-173 shall apply.
6.3.10
Call Transfer (CT) No interactions. NOTE 2 When Call Transfer has been performed, the names of the connected users are provided to each other, unless restriction applies, as part of the Call Transfer supplementary service.
6.3.11
Completion of Calls to Busy Subscribers (CCBS) No interactions. NOTE 3 Unless restriction applies, SS-CNIP applies to the called user when the call is eventually offered to that user.
6.3.12
Completion of Calls on No Reply (CCNR) No interactions. NOTE 4 Unless restriction applies, SS-CNIP applies to the called user when the call is eventually offered to that user.
6.3.13
Path Replacement (ANF-PR) No interactions.
6.4 6.4.1
Interworking Considerations Incoming Calls On calls incoming from another network, the calling party name shall be obtained from the other network if available. Where no name is provided by the other network, the called PISN user shall be given an indication "name unavailable" or "presentation restricted", as appropriate. If the number of characters in the calling party name exceeds 50, the PISN shall truncate the excess characters.
6.4.2
Outgoing Calls On outgoing calls to another network, the PISN shall provide the calling party name to the other network if this network supports an equivalent supplementary service and if the name is available and presentation not restricted. If the number of characters in a name exceeds the maximum number of characters that can be transmitted to the other network, the trailing characters shall be truncated.
6.5
Overall SDL Figure 1 contains the dynamic description of SS-CNIP using the SDL defined in ITU-T Rec. Z.100. The SDL process represents the behaviour of the network in providing SS-CNIP. The relationship to the basic call process is indicated in the annotations.
- 6 -
Output signals to the right represent primitives to the called PISN user. Input signals from the left represent internal stimuli. Idle
CNIP is invoked at the same time as basic call SETUP_indication is sent to the called user
CNIP required
include indication whether presentation restriction applies
No
presentation restricted ?
Yes
override ?
No
Yes include name, if available, in CNIP indication
CNIP indication
Idle
Figure 1 - SS-CNIP Overall SDL
- 7 -
7
SS-CONP Stage 1 Description
7.1
Description
7.1.1
General Description Connected Name Identification Presentation (SS-CONP) is a supplementary service which is offered to the calling user and which provides to the calling user the following: − the name of the user who answers the call (connected party name), − optionally the name of the alerting user (called party name), − optionally the name of the called user who cannot be reached (busy party name). The PISN provides the connected party name to the calling user when the called user connects to the incoming call. The PISN optionally provides the busy party name to the calling user when the called user is busy. The PISN optionally provides the called party name to the calling user when the called user is alerting. NOTE 5 Interactions with certain supplementary services may cause the connected party name to differ from the called party name. The possible provision of the connected party name by the connected user to the PISN is outside the scope of this Standard.
7.1.2
Qualifications on Applicability to Telecommunication Services This supplementary service is applicable to all basic services defined in ECMA-142.
7.2
Procedures
7.2.1
Provision/Withdrawal This Supplementary service shall be generally available. Some users may have a service profile which permits the override of connected/called/busy name identification restriction.
7.2.2 7.2.2.1
Normal Procedures Activation/Deactivation/Registration/Interrogation SS-CONP shall be permanently activated. No information needs to be registered with the PISN for this supplementary service and therefore interrogation is not applicable.
7.2.2.2
Invocation and Operation The PISN shall provide the calling user with the connected party name at the same time as indicating that call establishment is complete. The PISN may provide the calling user with the busy party name at the same time as indicating that call establishment is unsuccessful. The PISN may provide the calling user with the called party name at the same time as indicating that the call is alerting. The PISN may truncate the connected/called/busy party name in accordance with what the user can receive. The method by which the PISN obtains the name information is implementation dependent and outside the scope of this Standard. The management of the PISN name directory system is also outside the scope of this Standard. In some cases where Connected Name Identification Restriction has been invoked, there may be certain categories of calling user that have the service profile to override this restriction and have the connected/called/busy party name presented, e.g. emergency stations, PISN operators. In these circumstances, presentation shall include an indication that restriction has been invoked.
- 8 -
7.2.3
Exceptional Procedures
7.2.3.1
Invocation and Operation There are two exceptions when the connected/called/busy party name shall not be presented to the calling user: − when the connected/called/busy/ name identification restriction has been invoked (see definition of Calling/Connected Name Identification Restriction), and − when the connected/called/busy party name is not available, e.g. due to interworking with another network or when no name is registered against the destination PISN user. In such cases the calling user shall receive an indication of the situation.
7.3
Interactions with other Supplementary Services and ANFs This clause specifies interactions with other supplementary services for which PISN Standards were available at the same time of publication of this Standard.
7.3.1
Calling Name Identification Presentation (CNIP) No interactions.
7.3.2
Calling/Connected Name Identification Restriction (CNIR) The connected/called/busy party name shall not be presented if Connected Name Identification Restriction has been invoked at the destination user, unless the calling user has the service profile to override this restriction.
7.3.3
Calling Line Identification Presentation (CLIP) No interactions
7.3.4
Connected Line Identification Presentation (COLP) No interactions.
7.3.5
Calling/Connected Line Identification Restriction (CLIR) No interactions.
7.3.6
Call Forwarding Unconditional (CFU) Interactions specified in ECMA-173 shall apply.
7.3.7
Call Forwarding Busy (CFB) Interactions specified in ECMA-173 shall apply.
7.3.8
Call Forwarding No Reply (CFNR) Interactions specified in ECMA-173 shall apply.
7.3.9
Call Deflection (CD) Interactions specified in ECMA-173 shall apply.
7.3.10
Call Transfer (CT) No interactions. NOTE 6 When Call Transfer has been performed, the names of the connected users (and optionally of the alerting user) are provided to each other, unless restriction applies, as part of the Call Transfer supplementary service.
7.3.11
Completion of Calls to Busy Subscribers (CCBS) No protocol interactions. NOTE 7 Unless restriction applies, SS-CONP applies to the calling user when the call is established as a result of Completion of Calls to Busy Subscriber.
- 9 -
7.3.12
Completion of Calls on No Reply (CCNR) No protocol interactions. NOTE 8 Unless restriction applies, SS-CONP applies to the calling user when the call is established as a result of Completion of Calls on No Reply.
7.3.13
Path Replacement (PR) No protocol interactions.
7.4 7.4.1
Interworking Considerations Outgoing Calls On calls outgoing to another network, the connected/called/busy party name shall be obtained from the other network if available. Where no name is provided by the other network, the calling PISN user shall be given an indication "name unavailable" or "presentation restricted", as appropriate. If the number of characters in the connected/called/busy party name exceeds 50, the PISN shall truncate the excess characters.
7.4.2
Incoming Calls On incoming calls from another network, the PISN shall provide the connected/called/busy party name to the other network if this network supports an equivalent supplementary service and if the name is available and presentation not restricted. If the number of characters in a name exceeds the maximum number of characters that can be transmitted to the other network, the trailing characters shall be truncated.
7.5
Overall SDL Figure 2 contains the dynamic description of SS-CONP using the SDL defined in ITU-T Rec. Z.100. The SDL process represents the behaviour of the network in providing SS-CONP. The relationship to the basic call process is indicated in the annotations. Output signals to the left represent primitives to the calling PISN user. Input signals from the right represent internal stimuli.
- 10 -
Idle
CONP is invoked at the same time as basic call SETUP_confirmation, REPORT_indication or RELEASE_indication is sent to the calling user
CONP required
include indication whether presentation restriction applies
No
presentation restricted ?
Yes
override ?
No
Yes include name, if available, in CONP indication
CONP indication
Idle
Figure 2 - SS-CONP Overall SDL
- 11 -
8
SS-CNIR Stage 1 Description
8.1
Description
8.1.1
General Description Calling/connected Name Identification Restriction (SS-CNIR) is a supplementary service which is offered to a user to restrict presentation of that user's name to another user. When SS-CNIR applies to a user, the user's name is normally not presented to any other user.
8.1.2
Qualifications on applicability to Telecommunication Services The supplementary service is applicable to all basic services defined in ECMA-142.
8.2
Procedures
8.2.1
Provision/Withdrawal SS-CNIR shall be provided on a service profile basis. A PISN may provide one or more of several service options. The options shall apply separately to each name. The following service profile options are available. − SS-CNIR mode: permanent (invoked for all calls) temporary (specified by user per call) − Default for temporary mode: presentation restricted presentation not restricted
8.2.2 8.2.2.1
Normal Procedures Activation/Deactivation/Registration/Interrogation SS-CNIR shall be activated on provision and deactivated on withdrawal. This supplementary service requires no registration and admits no interrogation.
8.2.2.2
Invocation and Operation If permanent mode is provided, then calling party name restriction shall be invoked automatically for all calls originating from the PISN user concerned, and connected/called/busy identification restriction shall be invoked automatically for all calls that terminate at the PISN user concerned. If temporary mode is provided, the called party name and busy name shall not be presented. If temporary mode with default "presentation restricted" is provided, identification restriction of the calling party name and connected party name shall be invoked automatically for all calls originating or terminating at the PISN user concerned, unless requested otherwise by the PISN user at call establishment time. If temporary mode with default "presentation not restricted" is provided, identification restriction of the calling party name and connected party name shall not be invoked automatically for calls originating or terminating at the PISN user concerned, unless requested otherwise by the PISN user at call establishment time. To override the default for an outgoing call when temporary mode is provided, the calling user makes a request for restriction or no restriction at the same time as requesting call establishment. To override the default for an incoming call when temporary mode is provided, the called user makes a request for restriction or no restriction at the same time as responding to the incoming call indication. If identification restriction is invoked for an outgoing call, the calling party name shall be marked by the PISN as "presentation restricted". This prevents presentation to the called user (unless the called user has an override service profile). If identification restriction is invoked for an incoming call, the connected/called/busy party name shall be marked by the PISN as "presentation restricted". This prevents presentation to the calling user (unless the calling user has an override service profile).
- 12 -
8.2.3
Exceptional Procedures
8.2.3.1
Invocation and Operation A request from the PISN user for the override of a default shall be ignored if the PISN user is not provided with the temporary mode.
8.3
Interactions with other Supplementary Services and ANFs This clause specifies interactions with other supplementary services for which PISN Standards were available at the time of publication of this Standard.
8.3.1
Calling Name Identification Presentation (CNIP) See SS-CNIP clause 6.3.2.
8.3.2
Connected Name Identification Presentation (CONP) See SS-CONP clause 7.3.2.
8.3.3
Calling Line Identification Presentation (CLIP) No interactions.
8.3.4
Connected Line Identification Presentation (COLP) No interactions.
8.3.5
Calling/Connected Line Identification Restriction (CLIR) No interactions.
8.3.6
Call Forwarding Unconditional (CFU) Interactions specified in ECMA-173 shall apply.
8.3.7
Call Forwarding Busy (CFB) Interactions specified in ECMA-173 shall apply.
8.3.8
Call Forwarding No Reply (CFNR) Interactions specified in ECMA-173 shall apply.
8.3.9
Call Deflection (CD) Interactions specified in ECMA-173 shall apply.
8.3.10
Call Transfer (CT) Interactions specified in ECMA-178 shall apply.
8.3.11
Completion of Calls to Busy Subscribers (CCBS) No interactions.
8.3.12
Completion of Calls on No Reply (CCNR) No interactions.
8.3.13
Path Replacement (PR) No interactions.
8.4 8.4.1
Interworking Considerations Incoming Calls This PISN supplementary service does not apply to the calling user of an incoming call. The other network may provide the equivalent service, in which case the PISN may receive an indication that presentation of the calling party name is restricted. In such a situation the other network may or may not supply the calling party name to the PISN. If not provided, even a called PISN user with an override service profile will be given only an indication that presentation is restricted. If the called user has invoked name identification restriction, only the indication that presentation is restricted shall be passed on to the other network, and no connected/called/busy party name shall be passed.
- 13 -
8.4.2
Outgoing Calls This PISN supplementary service does not apply to the connected user of an outgoing call. The other network may provide the equivalent service, in which case the PISN may receive an indication that presentation of the connected/called/busy party name is restricted. In such a situation the other network may or may not supply the connected/called/busy party name to the PISN. If not provided, even a calling PISN user with an override service profile will be given only an indication that presentation is restricted. If the calling user has invoked Name Identification restriction, the calling party name shall be marked as "presentation restricted". Only this indication shall be passed on to the other network.
8.5
Overall SDL Figure 3 contains the dynamic description of SS-CNIR using the SDL defined in ITU-T Rec. Z.100. The SDL process represents the behaviour of the network in providing SS-CNIR. The relationship to the basic call process is indicated in the annotations. Input signals from the left represent primitives from the served PISN user. Input signals from the right represent internal stimuli.
- 14 -
Figure 3 - SS-CNIR Overall SDL
- 15 -
9
SS-CNIP Stage 2 Description
9.1
Functional Model
9.1.1
Functional Model Description The functional model for SS-CNIP shall comprise the FEs "CNIP Provision" (FE1), "CNIP Presentation" (FE2) and "CNIP Reception" (FE3). A relationship ra shall exist between FE1 and FE2 and relationship rb shall exist between FE2 and FE3. Figure 4 shows these FEs and relationships.
ra
FE1 r1
CCA
CC
r2
CC
rb
FE2 r2
r3
CC
Calling User
FE3
CCA
Called User
Figure 4 - Functional model and relationship to basic call for SS-CNIP
9.1.2
Description of the Functional Entities The functional entities required by SS-CNIP shall be as follows: -
FE1
CNIP Provision: responsible for provision of the calling party name information and associated indicators to FE2.
-
FE2
CNIP Presentation: responsible for reporting the calling party name information and associated indicators to FE3.
-
FE3
CNIP Reception: responsible for delivery of the calling party name information and associated indicators to the PISN user.
NOTE 9 The structure of the name information is described in annex A of this Standard. NOTE 10 The possibility, that the name information is stored in another FE (data base) and provided to FE1 on request for delivery to FE2 is outside the scope of this Standard. 9.1.3
Relationship of the Functional Model to the Basic Call Functional Model Figure 4 shows also the relationship with a basic service for SS-CNIP.
9.2
Information Flows
9.2.1
Definition of Information Flows The information flows INFORM 1 and INFORM 2 shall apply for SS-CNIP. In the tables below, the column headed "Request" indicates which of the service elements are mandatory (M) and which are optional (O) in an request/indication information flow. The column headed "Confirm" indicates which of the service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow.
9.2.1.1
INFORM 1 This unconfirmed information flow, which conveys the calling party name, shall be sent over relationship ra (optional in case of name not available otherwise mandatory). It shall contain the service elements listed in table 1.
- 16 -
Table 1 - Content of INFORM 1 Service Elements
Allowed Value
Presentation Indicator
presentation not restricted presentation restricted calling party name not available
Request M
Name
O (Note 11)
Type of Character Set
O (Note 11)
Application Identifier
O
NOTE 11 The service element shall be present if and only if the name is available.
9.2.1.2
INFORM 2 This unconfirmed information flow, which conveys the calling party name, shall be sent over relationship rb (optional in case of name not available, otherwise mandatory). It shall contain the service elements listed in table 2. Table 2 - Content of INFORM 2 Service Elements
Allowed Value
Presentation Indicator
presentation not restricted presentation restricted calling party name not available
Request M
Name
O (Note 12)
Type of Character Set
O (Note 12)
Application Identifier
O
NOTE 12 The service element shall be present as indicated if the name is available and not restricted or if restricted and the called user has an override service profile. Otherwise the service element shall be omitted.
9.2.2
Relationship of Information Flows to Basic Call Information Flows The SS-CNIP information flows shall be sent at the same time as the basic call information flow SETUP req/ind (r2/r3).
9.2.3
Information Flow Sequences Signalling procedures shall be provided in support of the information flow sequences specified below. In addition, signalling procedures shall be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc.. In the figure, SS-CNIP information flows are represented by solid arrows and basic call information flows are represented by shaded arrows. An ellipse embracing two information flows indicates that the two information flows occur together. Within a column representing an SS-CNIP functional entity, the numbers refer to functional entity actions listed in 9.3. Figure 5 shows the information flow sequence for normal operation of SS-CNIP. (Note that not all basic call information flows are shown in this figure; only those which have related name identification information flows.)
- 17 -
ra
FE1
CCA
r1
r2
CC
FE2 r2
CC
CC
rb
r3
FE3
CCA
SETUP req/ind SETUP req/ind SETUP req/ind SETUP req/ind 101
INFORM 1 req/ind 201
INFORM 2 req/ind
301
Figure 5 - Information Flow Sequence for SS-CNIP
9.3
The Functional Entity Actions The following FE actions shall occur at the points indicated in the figure of 9.2.3:
9.4
-
FE1 action 101: Generate INFORM 1 request/indication (if available) and send it at the same time as the basic call SETUP request/indication to the subsequent functional entity FE2.
-
FE2 action 201: Receive INFORM 1 request/indication, remove the name information according to element presentation indicator and the override service profile of the called user and send INFORM 2 at the same time as the basic call SETUP request/indication to the functional entity FE3.
-
FE3 action 301: Receive INFORM 2 request/indication and provide the received information to the called PISN user.
Functional Entity Behaviour Figures 6, 7 and 8 are intended to illustrate typical FE behaviour in terms of information flows sent and received. The figures show the behaviour of the functional entities FE1, FE2 and FE3 in providing SS-CNIP using the SDL defined in ITU-T Rec. Z.100. Output signals to the right represent information flows to other functional entities or primitives to the called PISN user. Input signals from the left represent information flows from other functional entities or internal stimuli. The relationship to the basic call process is indicated in the annotations.
- 18 -
Idle
CNIP required
CNIP is invoked at the same time as the basic call SETUP req/ind is sent
include indication whether presentation restriction applies in INFORM 1 req/ind
include name, if available, in INFORM 1 req/ind
INFORM 1 req/ind
Idle
Figure 6 - SDL for Functional Entity FE1
- 19 -
Idle
CNIP is invoked at the same time as the basic call SETUP req/ind is sent
INFORM 1
include indication whether presentation restriction applies in INFORM 2 req/ind
No
presentation restricted ?
Yes
override ?
No
Yes include name, if available, in INFORM 2 req/ind
INFORM 2 req/ind
Idle
Figure 7 - SDL for Functional Entity FE2
- 20 -
Idle
INFORM 2 req/ind
CNIP indication
Idle
Figure 8 - SDL for functional Entity FE3
9.5
Allocation of Functional Entities to Physical Locations The allocation of FEs to physical equipment for SS-CNIP as shown in table 3 shall apply. If the served user's TE is stimulus with respect to SS-CNIP, FE3 shall be allocated in the Destination PINX. Table 3 - Allocation of functional entities to physical location for SS-CNIP Calling User
Called User
Scenario
FE1
FE2
FE3
Scenario 1
Originating PINX
Destination PINX
TE
Scenario 2
Originating PINX
Gateway PINX
other network
Scenario 3
other network
Destination PINX
TE
- 21 -
10
SS-CONP Stage 2 Description
10.1 10.1.1
Functional Model Functional Model Description The functional model for SS-CONP shall comprise the FEs "CONP Provision" (FE4), "CONP Presentation" (FE5) and "CONP Reception" (FE6). A relationship rc shall exist between FE4 and FE5 and a relationship rd shall exist between FE5 and FE6. Figure 9 shows these FEs and relationships.
rd
FE6
r1
CCA
rc
FE5
CC
r2
CC
FE4 r2
r3
CC
Calling User
CCA
Called User
Figure 9 - Functional model and relationship to basic call for SS-CONP
10.1.2
Description of the Functional Entities The functional entities required by SS-CONP shall be as follows: -
FE4
CONP Provision: responsible for provision of the connected/called/busy party name information and associated indicators to FE5.
-
FE5
CONP Presentation: responsible for reporting the connected/called/busy party name information and associated indicators to FE6.
-
FE6
CONP Reception: responsible for delivery of the connected/called/busy party name information and associated indicators to the PISN user.
NOTE 13 The structure of the name information is described in annex A of this Standard. NOTE 14 The possibility, that the name information is stored in another FE (data base) and provided to FE4 on request for delivery to FE5 is outside the scope of this Standard. NOTE 15 Interactions with certain supplementary services may cause the connected/busy party name to differ from the called party name. 10.1.3
Relationship of the Functional Model to the Basic Call Functional Model Figure 9 shows also the relationship with a basic service for SS-CONP.
10.2 10.2.1
Information Flows Definition of Information Flows The information flows INFORM 3, INFORM 4, INFORM 5, INFORM 6, INFORM 7 and INFORM 8 shall apply for SS-CONP. In the tables below, the column headed "Request" indicates which of the service elements are mandatory (M) and which are optional (O) in an request/indication flow. The column headed "Confirm" indicates which of the service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow.
- 22 -
10.2.1.1
INFORM 3 This unconfirmed information flow, which conveys the connected party name, shall be sent over relationship rc (optional in case of name not available, otherwise mandatory). It shall contain the service elements listed in table 4. Table 4 - Content of INFORM 3 Service Elements Presentation Indicator
Allowed Value presentation not restricted presentation restricted connected party name not available
Request M
Name
O (Note 16)
Type of Character Set
O (Note 16)
Application Identifier
O
NOTE 16 The service element shall be present if and only if the name is available. 10.2.1.2
INFORM 4 This unconfirmed information flow, which conveys the connected party name, shall be sent over relationship rd (optional in case of name not available, otherwise mandatory). It shall contain the service elements listed in table 5. Table 5 - Content of INFORM 4 Service Elements Presentation Indicator
Allowed Value presentation not restricted presentation restricted connected party name not available
Request M
Name
O (Note 17)
Type of Character Set
O (Note 17)
Application Identifier
O
NOTE 17 The service element shall be present as indicated if the name is available and not restricted or if restricted and the calling user has an override service profile. Otherwise the service element shall be omitted.
- 23 -
10.2.1.3
INFORM 5 This unconfirmed information flow, which conveys the called party name, may be sent over relationship rc. It shall contain the service elements listed in table 6. Table 6 - Content of INFORM 5 Service Elements
Allowed Value
Presentation Indicator
presentation not restricted presentation restricted called party name not available
Request M
Name
O (Note 18)
Type of Character Set
O (Note 18)
Application Identifier
O
NOTE 18 The service element shall be present if and only if the name is available. 10.2.1.4
INFORM 6 This unconfirmed information flow, which conveys the called party name, may be sent over relationship rd. It shall contain the service elements listed in table 7. Table 7 - Content of INFORM 6 Service Elements
Allowed Value
Presentation Indicator
presentation not restricted presentation restricted called party name not available
Request M
Name
O (Note 19)
Type of Character Set
O (Note 19)
Application Identifier
O
NOTE 19 The service element shall be present as indicated if the name is available and not restricted or if restricted and the calling user has an override service profile. Otherwise the service element shall be omitted.
- 24 -
10.2.1.5
INFORM 7 This unconfirmed information flow, which conveys the busy party name, may be sent over relationship rc. It shall contain the service elements listed in table 8. Table 8 - Content of INFORM 7 Service Elements
Allowed Value
Presentation Indicator
presentation not restricted presentation restricted busy party name not available
Request M
Name
O (Note 20)
Type of Character Set
O (Note 20)
Application Identifier
O
NOTE 20 The service element shall be present if and only if the name is available.
10.2.1.6
INFORM 8 This unconfirmed information flow, which conveys the busy party name, may be sent over relationship rd. It shall contain the service elements listed in table 9. Table 9 - Content of INFORM 8 Service Elements
Allowed Value
Presentation Indicator
presentation not restricted presentation restricted busy party name not available
Request M
Name
O (Note 21)
Type of Character Set
O (Note 21)
Application Identifier
O
NOTE 21 The service element shall be present as indicated if the name is available and not restricted or if restricted and the calling user has an override service profile. Otherwise the service element shall be omitted.
10.2.2
Relationship of Information Flows to Basic Call Information Flows The SS-CONP information flows INFORM 3 request/indication and INFORM 4 request/indication shall be sent at the same time as the basic call information flow SETUP response/confirmation (r2/r1) for the connected party name. The SS-CONP information flows INFORM 5 request/indication and INFORM 6 request/indication shall be sent at the same time as the basic call information flow REPORT request/indication (r2/r1) for the called party name. The SS-CONP information flows INFORM 7 request/indication and INFORM 8 request/indication shall be sent at the same time as the basic call information flow RELEASE request/indication (r2) and DISCONNECT request/indication (r1) for the busy party name.
- 25 -
10.2.3
Information Flow Sequences Signalling procedures shall be provided in support of the information flow sequences specified below. In addition, signalling procedures shall 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-CONP information flows are represented by solid arrows and basic call information flows are represented by shaded arrows. An ellipse embracing two information flows indicates that the information flows occur together. Within a column representing an SS-CONP functional entity, the numbers refer to functional entity actions listed in 10.3. Figures 10 and 11 show the information flow sequences for normal operation of SS-CONP. (Note that not all basic call information flows are shown in these figures; only those which have related name identification information flows.)
FE6
CCA
rd
r1
rc
FE5
CC
r2
REPORT req/ind
CC
FE4 r2
r3 CC
CCA
REPORT req/ind
REPORT req/ind 401
REPORT req/ind
INFORM 5 req/ind 501
601
INFORM 6 req/ind SETUP resp/conf
SETUP resp/conf
SETUP resp/conf 401
SETUP resp/conf
INFORM 3 req/ind 501
601
INFORM 4 req/ind
Figure 10 - Information Flow Sequence for SS-CONP when the called user is free
- 26 -
FE6
CCA
rd
r1
rc
FE5 r2
CC
RELEASE req/ind
CC
FE4 r2
r3 CC
CCA
SETUP REJECT req/ind
RELEASE req/ind 401
DISCONNECT req/ind
INFORM 7 req/ind 501
601
INFORM 8 req/ind
Figure 11 - Information Flow Sequence for SS-CONP when the called user is busy
10.3
Functional Entity Actions The following FE actions shall occur at the points indicated in the figures of 10.2.3: -
FE4 action 401: Generate INFORM 3 request/indication (if available) and send it at the same time as the basic call SETUP response/confirmation to the subsequent functional entity FE5. Generate optionally INFORM 5 request/indication (if available) and send it at the same time as the basic call REPORT request/indication to the subsequent functional entity FE5. Generate optionally INFORM 7 request /indication (if available) and send it at the same time as the basic call RELEASE request/indication to the subsequent functional entity FE5.
-
FE5 action 501: Receive INFORM 3 request/indication, remove the name according to service element Presentation Indicator and the override service profile of the calling user and send this information in INFORM 4 request/indication at the same time as the basic call SETUP response/confirmation to the functional entity FE6. Receive optionally INFORM 5 request/indication, remove the name according to service element Presentation Indicator and the override service profile of the calling user and send this information in INFORM 6 request/indication at the same time as the basic call REPORT request/indication to the functional entity FE6. Receive optionally INFORM 7 request/indication, remove the name according to service element Presentation Indicator and the override service profile of the calling user and send this information in INFORM 8 request/indication at the same time as the basic call DISCONNECT request/indication to the entity FE6.
-
FE6 action 601: Receive INFORM 4 request/indication, receive optionally INFORM 6 request/indication and INFORM 8 request/indication and provide the received information to the calling PISN user.
- 27 -
10.4
Functional Entity Behaviour Figures 12, 13, and 14 are intended to illustrate typical FE behaviour in terms of information flows sent and received. The figures show the behaviour of the functional entities FE4, FE5 and FE6 in providing SS-CONP using the SDL defined in ITU-T Rec. Z.100. Output signals to the left represent information flows to other functional entities or primitives to the calling PISN user. Input signals from the right represent information flows from other functional entities or internal stimuli. The relationship to the basic call process is indicated in the annotations.
Figure 12 - SDL for Functional Entity FE4
- 28 -
Figure 13 - SDL for Functional Entity FE5
- 29 -
Figure 14 - SDL for Functional Entity FE6
10.5
Allocation of Functional Entities to Physical Locations The allocation of FEs to physical equipment for SS-CONP as shown in table 10 shall apply. If the served user's TE is stimulus with respect to SS-CONP, FE6 shall be located in the Originating PINX. Table 10 - Allocation of functional entities to physical location for SS-CONP Calling User
Called User
Scenario
FE6
FE5
FE4
Scenario 1
TE
Originating PINX
Destination PINX
Scenario 2
TE
Originating PINX
other network
Scenario 3
other network
Gateway PINX
Destination PINX
- 30 -
11
SS-CNIR Stage 2 Description
11.1
Functional Model
11.1.1
Functional Model Description The functional model for SS-CNIR shall comprise the FEs "Restriction Request" (FE7) and "Restriction Control" (FE8). A relationship re shall exist between FE7 and FE8. Figure 15 shows these FEs and relationships. re
FE7
FE8
r1
CCA
CC
re
FE8 r2
CC
r2
r3
CC
Calling User
FE7
CCA
Called User
Figure 15 - Functional model and relationship to basic call for SS-CNIR
11.1.2
Description of the Functional Entities The functional entities required by SS-CNIR shall be as follows:
11.1.3
-
FE7
Restriction Request: responsible for receiving PISN user requests for override of the temporary mode default and passing them on to FE8.
-
FE8
Restriction Control: responsible for determining whether to invoke restriction on behalf of a user in a call, based on the user's service profile and any requests from FE7 for the override of the temporary mode default.
Relationship of the Functional Model to the Basic Call Functional Model Figure 15 shows also the relationship with a basic service for SS-CNIR.
11.2
Information Flows
11.2.1
Definition of Information Flows The information flow RESTRICT shall apply for SS-CNIR. In the table below, the column headed "Request" indicates which of the service elements are mandatory (M) and which are optional (O) in an request/indication information flow. The column headed "Confirm" indicates which of the service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow. This unconfirmed information flow, which conveys to a PISN user a request to override the SS-CNIR temporary mode default, shall be sent over relationship re. It shall contain the service element listed in table 11. Table 11 - Content of RESTRICT Service Elements
Restriction Indicator
11.2.2
Allowed Value presentation not restricted presentation restricted
Request
Confirm
M
Relationship of Information Flows to Basic Call Information Flows When the calling PISN user wishes to override the SS-CNIR temporary mode default, the Restrict request/indication information flow shall be sent at the same time as the basic call information flow SETUP request/indication (r1).
- 31 -
When the called PISN user wishes to override the SS-CNIR temporary mode default, the Restrict request/indication information flow shall be sent at the same time as the basic call information flow SETUP response/confirmation (r3). NOTE 22 If FE8 invokes SS-CNIR on behalf of the calling or called user (automatically or on request from the PISN user), an indication that restriction applies is included in the INFORM 1 request/indication, INFORM 3 request/indication, INFORM 5 request/indication or INFORM 7 request/indication information flow respectively. It is then the responsibility of the FEs of SS-CNIP or SS-CONP to ensure that identification information is not presented to the other user. 11.2.3
Information Flow Sequences Signalling procedures shall be provided in support of the information flow sequences specified below. In addition, signalling procedures shall be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc.. In the figure, SS-CNIR information flows are represented by solid arrows and basic call information flows are represented by shaded arrows. An ellipse embracing two information flows indicates that the two information flows occur together. Within a column representing an SS-CNIR functional entity, the numbers refer to functional entity actions listed in 11.3 Figure 16 shows the information flow sequences for normal operation of SS-CNIR.
FE7
CCA
701
re
r1
FE8
CC
FE8 r2
CC
r2
CC
RESTRICT req/ind
re
r3
RESTRICT req/ind 801
FE7
CCA
701
801
Figure 16 - Information Flow Sequence for SS-CNIR
11.3
Functional Entity Actions The following FE actions shall occur at the points indicated in the figure of 11.2.3: -
FE7 action 701: If served user wishes to override the CNIR temporary mode restriction default, generate a RESTRICT request/indication and send to FE8.
-
FE8 action 801: Assign the appropriate presentation restriction indicator to the served user's Name Identification, based on whether CNIR permanent mode or temporary mode applies and, in the case of temporary mode, whether a request to override the default has been received from FE7.
- 32 -
11.4
Functional Entity Behaviour Figures 17 and 18 are intended to illustrate typical FE behaviour in terms of information flows sent and received. The figures show the behaviour of the functional entities FE7 and FE8 in providing SS-CNIR using the SDL defined in ITU-T Rec. Z.100. Output signals to the right represent information flows to other functional entities. Input signals from the left represent internal stimuli or input from other functional entities. The relationship to the basic call process is indicated in the annotations.
Idle
CNIR request
RESTRICT req/ind
Idle
Figure 17 - SDL for Functional Entity FE7
- 33 -
Figure 18 - SDL for Functional Entity FE8
- 34 -
11.5
Allocation of Functional Entities to Physical Locations The allocation of FEs to physical equipment for SS-CNIR as shown in table 12 shall apply. If the served user's TE is stimulus with respect to SS-CNIR, FE7 shall be located in the served user's PINX. Table 12 - Allocation of functional entities to physical location for SS-CNIR Calling User
Called User
Scenario
FE7
FE8
Scenario 1
TE
Originating PINX
Scenario 2
FE8
FE7
Destination PINX
TE
- 35 -
Annex A (normative)
Structure and Content of a PISN Name
The string of characters, which constitutes a name, shall be accompanied by the indication of the type of used character set and optionally by an application identifier. The application identifier is defined as manufacturer specific information which can imply the structure of the name information. Various character sets may be used including an application specific character set which is qualified by manufacturer specific information. At least one of the specified standard character sets shall be supported by a manufacturer. The list of possible character set shall include: -
The 8-bit single byte character set defined in ISO8859-1, Part 1: Latin alphabet No.1.
Not all of the specified characters in a set have to be implemented by a PINX or TE.
.
.
.
Printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:
+41 22 849.60.01 [email protected]
Files can be downloaded from our FTP site, ftp.ecma.ch, logging in as anonymous and giving your E-mail address as password. This Standard is available from library ECMA-ST as a compacted, self-expanding file in MSWord 6.0 format (file E163-DOC.EXE) and as an Acrobat PDF file (file E163-PDF.PDF). File E163-EXP.TXT gives a short presentation of the Standard. Our web site, http://www.ecma.ch, gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland This Standard ECMA-163 is available free of charge in printed form and as a file. See inside cover page for instructions