Standard ECMA-250 2nd E dition - De c ember 1998
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Common Information Additional Network Feature
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-250 2nd E dition - De c ember 1998
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Common Information Additional Network Feature (ANF-CMNSD)
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-250.doc
06-01-99 10,46
.
Brief History
This Standard is one of a series of ECMA standards defining services and signalling protocols applicable to Private Integrated Services Networks. The series uses the ISDN concepts as developed by ITU-T (formerly CCITT) and is also within the framework of standards for open systems interconnection as defined by ISO. It has been produced under ETSI work item DE/ECMA-00070. This Standard specifies the Common Information additional network feature. The 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 feature specified by ITU-T or ETSI for public ISDNs. Compared to the 1st Edition of Standard ECMA-250 (published by ECMA in December 1996), this 2nd Edition incorporates changes to achieve complete alignment with International Standard ISO/IEC 15771:1998(E) published by ISO/IEC in November 1998.
Adopted as 2nd Edition of Standard ECMA-250 by the General Assembly of December 1998.
.
- i -
Table of contents 1 Scope
1
2 Conformance
1
3 References (normative)
1
4 Definitions
1
4.1 External definitions
1
4.2 Additional Network Feature
2
4.3 ANF-CMN User
2
4.4 Backward direction
2
4.5 Call, Basic Call
2
4.6 Common Information
2
4.7 Feature Identifier
2
4.8 Forward direction
2
4.9 Equipment Identity
2
4.10 Node Identity
3
4.11 Group Identity
3
4.12 Unit Identity
3
4.13 Party Category
3
5 List of acronyms
3
6 ANF-CMN stage 1 specification
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 Calling Line Identification Presentation (CLIP)
4
6.3.2 Connected Line Identification Presentation (COLP)
4
6.3.3 Calling/Connected Line Identification Restriction (CLIR)
4
6.3.4 Calling Name Identification Presentation (CNIP)
4
6.3.5 Connected Name Identification Presentation (CONP)
4
6.3.6 Calling/Connected Name Identification Restriction (CNIR)
4
6.3.7 Call Forwarding Unconditional (CFU)
5
6.3.8 Call Forwarding Busy (CFB)
5
6.3.9 Call Forwarding No Reply (CFNR)
5
6.3.10 Call Deflection (CD)
5
6.3.11 Call Transfer (CT)
5
- ii -
6.3.12 Completion of Calls to Busy Subscriber (CCBS)
5
6.3.13 Completion of Calls on No Reply (CCNR)
5
6.3.14 Call Intrusion (CI)
5
6.3.15 Call Offer (CO)
5
6.3.16 Do Not Disturb (DND)
5
6.3.17 Do Not Disturb Override (DNDO)
5
6.3.18 Call Interception (CINT)
5
6.3.19 Advice Of Charge (AOC)
5
6.3.20 Message Waiting Indication (MWI)
5
6.3.21 Path Replacement (PR)
5
6.3.22 Recall (RE)
5
6.3.23 Cordless Terminal Mobility, Outgoing call (CTMO)
6
6.3.24 Cordless Terminal Mobility, Incoming call (CTMI)
6
6.3.25 Cordless Terminal, Location Registration (CTLR)
6
6.3.26 Cordless Terminal, Authentication (CTAN, CTAT)
6
6.3.27 Transit Counter (TC)
6
6.4 Interworking considerations
6
6.5 Overall SDL
6
7 ANF-CMN stage 2 specification
8
7.1 Functional Model
8
7.1.1 Functional Model Description
8
7.1.2 Description of Functional Entities
8
7.1.3 Relationship of Functional Model to Basic Call Functional Model
8
7.2 Information Flows
9
7.2.1 Definition of Information Flows
9
7.2.2 Relationship of Information Flows to Basic Call Information Flows
12
7.2.3 Information Flow Sequences
12
7.3 Functional entity actions
14
7.3.1 Functional entity actions of FE1
14
7.3.2 Functional entity actions of FE2
14
7.4 Functional entity behaviour
14
7.4.1 Behaviour of FE1
15
7.4.2 Behaviour of FE2
16
7.5 Allocation of Functional Entities to Physical Equipment
16
7.6 Interworking considerations
16
Annex A - Party category and Equipment Identity
19
1
Scope This Standard specifies the additional network feature Common Information (ANF-CMN), which is applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. ANF-CMN is an additional network feature which enables the exchange of Common Information between entities acting on behalf of the two ends of a connection through a PISN. This Common Information is a collection of miscellaneous information that relates to the user or equipment at one end of a connection and includes one or more of the following: Feature Identifiers, Party Category, Equipment Identity. This information, when received by an entity, can be used for any purpose, e.g. as the basis for indications to the local user or to another network or in order to filter feature requests. Additional network feature specifications are produced in three stages, according to the method described in ETS 300 387. This Standard contains the stage 1 and stage 2 specifications of ANF-CMN. The stage 1 specification (clause 6) specifies the additional network feature as seen by users of the feature. The stage 2 specification (clause 7) identifies the functional entities involved in the additional network feature 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 additional network feature 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.
4
ECMA-133
Private Integrated Services Network - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)
ECMA-142
Private Integrated Services Network (PISN) - Circuit-mode 64 kbit/s bearer services - Service description, functional capabilities and information flows (International Standard ISO/IEC 11574)
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 purpose 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)
Connection
(ITU-T Rec. I.112)
- 2 -
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 (except in the context of ANF-CMN user)
(ECMA-142)
This Standard refers to the following basic call functional entities (FEs) 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/confirmation 4.2
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.3
ANF-CMN User An entity that acts on behalf of one end of a connection through a PISN by using ANF-CMN to exchange Common Information with a peer entity acting on behalf of the other end of the connection.
4.4
Backward direction Within the context of a call, the direction from the called user towards the calling user.
4.5
Call, Basic Call An instance of the use of a basic service.
4.6
Common Information Information relating to the user or equipment at one end of a connection through a PISN. This information includes one or more of the following: Feature Identifiers, Party Category, Equipment Identity.
4.7
Feature Identifier In the context of a particular call, an indication of the availability of a supplementary service or ANF or of a particular capability of a supplementary service or ANF.
4.8
Forward direction Within the context of a call, the direction from the calling user towards the called user.
4.9
Equipment Identity A unique identity, three-level structured consisting of Node identity, Group identity, Unit identity. NOTE The purpose of the Equipment Identity is to indicate, to another user or to another PINX, information about a calling or called party involved in a call. Assignment of network wide unique Equipment Id values is outside the scope of this Standard.
- 3 -
4.10
Node Identity The identity of the PINX at which a unit of equipment is located.
4.11
Group Identity Within the context of a PINX, the identity of the group of equipment to which a unit of equipment belongs.
4.12
Unit Identity Within the context of a PINX or a group of equipment within a PINX, the identity of a unit of equipment.
4.13
Party Category Indicates the category of a party involved in a call. NOTE The purpose of the Party Category is to indicate to the other end of a connection the category of a user involved in a call. A received Party Category information may be used for display at the user's terminal or for the PISNinternal call handling process, e.g. depending whether the calling party is an extension or PISN attendant, the call handling may invoke different options of a supplementary service related to that call.
5
List of acronyms
6
ANF
Additional Network Feature
ANF-CMN
Additional Network Feature Common Information
CC
Call Control (functional entity)
CCA
Call Control Agent (functional entity)
FE
Functional Entity
FI
Feature Identifier
ISDN
Integrated Services Digital Network
PINX
Private Integrated Services Network Exchange
PISN
Private Integrated Services Network
SDL
Specification and Description Language
SS
Supplementary Service
ANF-CMN stage 1 specification
6.1 6.1.1
Description General description ANF-CMN is an additional network feature which enables the exchange of Common Information between ANFCMN users acting on behalf of the two ends of a connection through a PISN. This Common Information is a collection of miscellaneous information that relates to the user or equipment at one end of a connection and includes one or more of the following: Feature Identifiers, Party Category, Equipment Identity. This information, when received by an ANF-CMN user, can be used for any purpose, e.g. as the basis for indications to the local user or to another network or in order to filter feature requests. A solicited and an unsolicited service can be offered to an ANF-CMN user (which may be located at either end of a connection). The solicited service enables the ANF-CMN user to request the Common Information from a peer ANF-CMN user. The unsolicited service enables an ANF-CMN user to supply Common Information to a peer ANF-CMN user. These services may be combined and are not mutually exclusive.
- 4 -
6.1.2
Qualifications on Applicability to Telecommunication Services ANF-CMN is applicable to all circuit-mode basic services defined in ECMA-142.
6.2
Procedures
6.2.1
Provision/Withdrawal ANF-CMN shall be PISN instigated.
6.2.2
Normal procedures
6.2.2.1
Activation/Deactivation/Registration/Interrogation Not applicable.
6.2.2.2
Invocation and operation The conditions under which ANF-CMN is invoked shall be an implementation matter. Also, Common Information offered by a PISN shall be an implementation matter. An ANF-CMN user may invoke ANF-CMN at any time during a call
to send its own Common Information to the peer ANF-CMN user (unsolicited service), or to request the Common Information of the peer ANF-CMN user (solicited service). Sending and requesting the Common Information may be combined. NOTE Typically the Common Information is exchanged during the establishment of a call. On receiving a request for Common Information the receiving ANF-CMN user shall respond with its Common Information. 6.2.3
Exceptional procedures
6.2.3.1
Activation/Deactivation/Registration/Interrogation Not applicable.
6.2.3.2
Invocation and Operation If no response is received on a request for Common Information (solicited service), the action to be taken shall be implementation dependent.
6.3
Interactions 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
Calling Line Identification Presentation (CLIP) No interaction.
6.3.2
Connected Line Identification Presentation (COLP) No interaction.
6.3.3
Calling/Connected Line Identification Restriction (CLIR) No interaction.
6.3.4
Calling Name Identification Presentation (CNIP) No interaction.
6.3.5
Connected Name Identification Presentation (CONP) No interaction.
6.3.6
Calling/Connected Name Identification Restriction (CNIR) No interaction.
- 5 -
6.3.7
Call Forwarding Unconditional (CFU) Common Information relating to the originating end of a call sent at the time of the call establishment request shall, if the call is diverted, be diverted to the ANF-CMN user at the terminating end of the diverted call.
6.3.8
Call Forwarding Busy (CFB) Clause 6.3.7 shall apply.
6.3.9
Call Forwarding No Reply (CFNR) Unsolicited Common Information relating to the originating end of a call sent at the time of the call establishment request shall, if the call is diverted, be diverted to the ANF-CMN user at the terminating end of the diverted call. A request for solicited Common Information relating to the originating end of a call sent at the time of the call establishment request shall not, if the call is diverted, be diverted to the ANF-CMN user at the terminating end of the diverted call.
6.3.10
Call Deflection (CD) In case of Call Deflection immediate, clause 6.3.7 shall apply. In case of Call Deflection on alerting, clause 6.3.9 shall apply.
6.3.11
Call Transfer (CT) No interaction. NOTE ANF-CMN users involved in a call resulting from Call Transfer may exchange Common Information subsequent to transfer.
6.3.12
Completion of Calls to Busy Subscriber (CCBS) No interaction.
6.3.13
Completion of Calls on No Reply (CCNR) No interaction.
6.3.14
Call Intrusion (CI) No interaction.
6.3.15
Call Offer (CO) No interaction.
6.3.16
Do Not Disturb (DND) No interaction.
6.3.17
Do Not Disturb Override (DNDO) No interaction.
6.3.18
Call Interception (CINT) In case of Call Interception immediate, clause 6.3.7 shall apply. In case of Call Interception delayed, clause 6.3.9 shall apply.
6.3.19
Advice Of Charge (AOC) No interaction.
6.3.20
Message Waiting Indication (MWI) No interaction.
6.3.21
Path Replacement (PR) No interaction.
6.3.22
Recall (RE) No interaction.
- 6 -
6.3.23
Cordless Terminal Mobility, Outgoing call (CTMO) No interaction.
6.3.24
Cordless Terminal Mobility, Incoming call (CTMI) Clause 6.3.7 shall apply.
6.3.25
Cordless Terminal, Location Registration (CTLR) No interaction.
6.3.26
Cordless Terminal, Authentication (CTAN, CTAT) No interaction. Difference from ISO/IEC 15771 In the International Standard, “Wireless Terminal” is used in place of “Cordless Terminal” in the titles of subclauses 6.3.23 – 6.3.26, and the corresponding acronyms are WTMO, WTMI, WTLR, WTAN, and WTAT, respectively. End of difference
6.3.27
Transit Counter (TC) No interaction.
6.4
Interworking considerations On a call to or from another network both ANF-CMN users will be located within the PISN, with one ANF-CMN user acting on behalf of the other network. That ANF-CMN user may use information from the other network in compiling its own Common Information and may send some or all of the peer ANF-CMN user's Common Information to the other network.
6.5
Overall SDL Figure 1 contains the dynamic description of ANF-CMN using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1993). The SDL process represents the behaviour of the network in providing ANFCMN. The relationship of this process to the basic call process is indicated in the annotations. Input signals from the left and output signals to the left represent primitives from and to the invoking ANF-CMN user. Input signals from the right represent primitives from the non-invoking ANF-CMN user or internal stimuli. Output signals to the right represent primitives to the non-invoking ANF-CMN user.
- 7 -
IDLE
CMN-Request for solicited service
Send CMN-Request
CMN-Request for solicited + unsolic. serv.
Request to send unsolicited CMN
Send CMNRequest and Common Info.
Send Common Information
IDLE
Await CMN
solicited Common Info received
no answer
basic call cleared, timeout etc.
Inform ANF-CMN user
IDLE
IDLE
Figure 1 - ANF-CMN, Overall SDL
- 8 -
7
ANF-CMN stage 2 specification
7.1
Functional Model
7.1.1
Functional Model Description The functional model shall comprise the following functional entities (FEs): FE1
ANF-CMN Invoke
FE2
ANF-CMN Remote
The following functional relationship shall exist between these FEs: ra
between FE1 and FE2
Figure 2 shows these FEs and this relationship.
ra FE1
FE2
Figure 2 - Functional Model for ANF-CMN 7.1.2 7.1.2.1
Description of Functional Entities ANF-CMN Invoke Functional Entity, FE1 This functional entity
receives requests from the local ANF-CMN user for the solicited service: sends a Common Information request to FE2 receives the response from FE2 and passes the received Common Information to the local ANF-CMN user.
for the unsolicited service: sends the Common Information to FE2. 7.1.2.2
ANF-CMN Remote Functional Entity, FE2 This functional entity
for the solicited service: receives the Common Information request obtains Common Information from the local ANF-CMN user and responds to FE1. for the unsolicited service: receives the Common Information and passes it to the local ANF-CMN user. 7.1.3
Relationship of Functional Model to Basic Call Functional Model Functional entity FE1 is collocated with invoking ANF-CMN user's CC. Functional entity FE2 is collocated with non-invoking ANF-CMN user's CC. An example of a relationship between FEs for ANF-CMN and FEs for the basic call is shown in figure 3.
- 9 -
CCA
r1
r2
CC
r2
CC ra
FE1
r3
CC
CCA
FE2
Figure 3 - Example Relationship between Model for ANF-CMN and Basic Call
7.2
Information Flows
7.2.1
Definition of Information Flows 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.
7.2.1.1
ra-CMN-REQUEST ra-CMN-REQUEST is a confirmed information flow across ra between FE1 and FE2 which is used to request the remote Common Information. The response contains the requested remote Common Information (solicited service). Table 1 lists the service elements within the ra-CMN-REQUEST information flow. The contents of the service elements in table 1 are defined in 7.2.1.3. Table 1 - Content of ra-CMN-REQUEST Service element
Request
Confirm
FI-list
-
O
(Note 1)
Equipment Id
-
O
(Note 1)
Party Category
-
O
(Note 1)
NOTE 1 At least one of these three service elements shall be present within the ra-CMN-REQUEST confirmation. 7.2.1.2
ra-CMN-INFORM ra-CMN-INFORM is an unconfirmed information flow across ra from FE1 to FE2 which is used to send unsolicited Common Information. Table 2 lists the service elements within the ra-CMN-INFORM information flow. The contents of the service elements in table 2 are defined in 7.2.1.3. Table 2 - Content of ra-CMN-INFORM Service element
Request
FI-list
O
(Note 1)
Equipment Id
O
(Note 1)
Party Category
O
(Note 1)
NOTE 1 At least one of these three service elements shall be present within the ra-CMN-INFORM request. 7.2.1.3
Contents of Service Elements of ANF-CMN The service elements of ANF-CMN are listed in tables 3 and 4.
- 10 -
NOTE Future supplementary services or additional network features will specify the appropriate Feature Identifiers in their service descriptions. The service element FI-list, when used in forward direction, shall include one or more of the Feature Identifiers listed in table 3. Table 3 - Feature Identifiers in Forward Direction Feature Identifiers
Values
Comments
SS-CF re-routeing available
Yes/No
Call Forwarding
SS-CT re-routeing available
Yes/No
Call Transfer
SS-CI protection level
0 1 2 3
Call Intrusion
ANF-PR available at a co-operating PINX
Yes/No
Path Replacement
ANF-CINT can intercept - interception immediate
Yes/No
Call Interception
ANF-CINT can intercept - interception delayed
Yes/No
ANF-CTMI re-routeing available
Yes/No
Cordless Terminal Incoming Call
The service element FI-list, when used in backward direction, shall include one or more of the Feature Identifiers listed in table 4.
- 11 -
Table 4 - Feature Identifiers in Backward Direction Feature Identifiers
Values
Comments
SS-CT re-routeing available
Yes/No
Call Transfer
SS-CCBS available
Yes/No
Call Completion on Busy Subscriber
SS-CCNR available
Yes/No
Call Completion on No Reply
SS-CO available
Yes/No
Call Offer
SS-DNDO available
Yes/No
Do Not Disturb Override
SS-DNDO protection level
0 1 2 3
SS-CI available
Yes/No
SS-CI protection level
0 1 2 3
options: SS-CI Forced Release available
Yes/No
SS-CI Isolation available
Yes/No
SS-CI Wait on Busy available
Yes/No
SS-AOC Support of charge rate provision at a gateway PINX
Yes/No
SS-AOC Support of interim charge provision at a gateway PINX
Yes/No
SS-AOC Support of final charge provision at a gateway PINX
Yes/No
ANF-PR available at a co-operating PINX
Yes/No
Call Intrusion
Advice Of Charge
Path Replacement
Table 5 - Equipment Identity Parameter
Indication
Values
Mandatory Comments / Optional Indication
Equipment Identity
Node Identity
alphanum. string
O
Group Identity
alphanum. string
O
Unit Identity
alphanum. string
O
- 12 -
Table 6 - Party Category Parameter
Values
Party Category
Unknown
Mandatory Comments / Optional Indication O
Extension PISN attendant Emergency extension
7.2.2
Relationship of Information Flows to Basic Call Information Flows When ra-CMN-REQUEST request/indication information flow is sent it shall be:
together with a basic call information flow if this is sent at the same time, otherwise independently of a basic call information flow. NOTE At call setup time ra-CMN-REQUEST is sent together with r2-SETUP request/indication. When ra-CMN-REQUEST response/confirmation information flow is sent it shall be:
together with a basic call information flow if this is sent at the same time, otherwise independently of a basic call information flow. When ra-CMN-INFORM request/indication information flow is sent it shall be:
together with a basic call information flow if this is sent at the same time, otherwise independently of a basic call information flow. 7.2.3
Information Flow Sequences A stage 3 standard for ANF-CMN 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 and ANFs, different topologies, etc. In the figures, ANF-CMN information flows are represented by solid arrows and basic call information flows are represented by broken arrows. An ellipse embracing two information flows indicates that the two information flows occur simultaneously. Within a column representing an ANF-CMN functional entity, the numbers refer to functional entity actions as listed in 7.3.
7.2.3.1
Normal Operation of ANF-CMN Figure 4 shows an example of the information flow sequence for normal operation of ANF-CMN for the solicited service at call setup time. Figure 5 shows an example of the information flow sequence for normal operation of ANF-CMN for the unsolicited service, independently of any basic call information flow. Figure 6 shows an example of the information flow sequence for normal operation of ANF-CMN for a combination of the solicited and unsolicited service at call setup time.
- 13 -
FE1 CCA
r1
CC 101
ra r2
ra-CMN-REQUEST req/ind
FE2 CC
r3
CCA
201
r2-SETUP req/ind
102
ra-CMN-REQUEST resp/conf r2-SETUP resp/conf
Figure 4 - Information Flow Sequence - Normal Operation of ANF-CMN solicited service at call setup time
ra
FE2
CC
r2
CC
103
ra-CMN-INFORM req/ind
202
FE1 CCA
r1
r3
CCA
Figure 5 - Information Flow Sequence - Normal Operation of ANF-CMN unsolicited service
- 14 -
FE1 CCA
r1
CC
101
ra r2
ra-CMN-REQUEST req/ind
FE2 CC
r3
CCA
201
r2-SETUP req/ind 103
ra-CMN-INFORM req/ind
102
ra-CMN-REQUEST resp/conf
202
r2-SETUP resp/conf
Figure 6 - Information Flow Sequence - Normal Operation of ANF-CMN combination of solicited and unsolicited service at call setup time
7.3
Functional entity actions The following FE actions shall occur at the points indicated in the figures of 7.2.3.
7.3.1
7.3.2
7.4
Functional entity actions of FE1 101
Send ra-CMN-REQUEST req/ind to FE2 in order to request Common Information from FE2.
102
Pass on the received Common Information to the requesting ANF-CMN user.
103
Obtain Common Information from the local ANF-CMN user and send ra-CMN-INFORM req/ind to FE2.
Functional entity actions of FE2 201
On receipt of the request for Common Information obtain the Common Information from the local ANF-CMN user and send ra-CMN-REQUEST resp/conf to FE1.
202
Pass on the received Common Information to the local ANF-CMN user.
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 (1993).
- 15 -
7.4.1
Behaviour of FE1 Figure 7 shows the normal behaviour of FE1. Input signals from the left and output signals to the left represent primitives from and to the ANF-CMN-user. Input signals from the right represent information flows from FE2 or internal stimuli (e.g. primitives from Basic Call). Output signals to the right represent information flows to FE2.
ANF-CMN Idle
request to send unsolicited CMN
ra-CMNINFORM request
CMN-Request for solicited service
ra-CMNREQUEST request
CMN-Request for solicited + unsol. serv.
ra-CMNINFORM request
ra-CMNREQUEST request
ANF-CMN Idle
Await ra-CMNAnswer
ra-CMNREQUEST confirmation
no answer
Inform ANF-CMN user
ANF-CMN Idle
ANF-CMN Idle
Figure 7 - ANF-CMN, SDL for Functional Entity FE1
basic call cleared, timeout etc.
- 16 -
7.4.2
Behaviour of FE2 Figure 8 shows the normal behaviour of FE2. Output signals to the right represent primitives from and to the ANF-CMN user. Input signals from the left and output signals to the left represent information flows to and from FE1.
ANF-CMN Idle
ra-CMNREQUEST indication
ra-CMNINFORM indication
Obtain Common Information
ra-CMNREQUEST response
Pass on Common Information
ANF-CMN Idle
Figure 8 - ANF-CMN, SDL for Functional Entity FE2
7.5
Allocation of Functional Entities to Physical Equipment The allocations of FEs to physical equipment shown in table 7 shall apply. Table 7 - Scenarios for the Allocation of FEs to Physical Equipment
7.6
FE1
FE2
Scenario 1
Originating PINX
Terminating PINX
Scenario 2
Terminating PINX
Originating PINX
Interworking considerations When interworking with another network, both FE1 and FE2 will be located within the PISN (table 8, scenarios 3 8). On an incoming call from another network: Scenario 3 applies if ANF-CMN is invoked in forward direction, Scenario 4 applies if ANF-CMN is invoked in backward direction. On an outgoing call to another network: Scenario 5 applies if ANF-CMN is invoked in forward direction, Scenario 6 applies if ANF-CMN is invoked in backward direction.
- 17 -
On a call that traverses the PISN: Scenario 7 applies if ANF-CMN is invoked in forward direction, Scenario 8 applies if ANF-CMN is invoked in backward direction.
Table 8 - Scenarios for the allocation of FEs to physical equipment for normal operation in the case of interworking with another network FE1
FE2
Scenario 3
Incoming Gateway PINX
Terminating PINX
Scenario 4
Terminating PINX
Incoming Gateway PINX
Scenario 5
Originating PINX
Outgoing Gateway PINX
Scenario 6
Outgoing Gateway PINX
Originating PINX
Scenario 7
Incoming Gateway PINX
Outgoing Gateway PINX
Scenario 8
Outgoing Gateway PINX
Incoming Gateway PINX
- 18 -
- 19 -
Annex A (informative)
Party category and Equipment Identity
A.1
General The purpose of the Party category is to indicate, to another user or to another PINX, the category of a user involved in a call. A received Party category information may be used for display at the user's terminal or for PINX internal call handling, e.g. depending on whether the calling or called party is an Extension or a PISN attendant, the PINX internal call handling may invoke different options of a supplementary service related to that call. The purpose of the Equipment Identity is to indicate, to another user or to another PINX, information about a calling or called party involved in a call. The information could either be sent in addition to Party category information or when the Party category information of a user is either unknown or not available (i.e. Party category value is "unknown" or Party category information is absent). The Equipment Identity can consist of up to three components, allowing e.g. a hierarchical structure of up to three levels. The number of components actually used and the meaning of each component is network dependent and therefore not specified in this International Standard.
A.2 A.2.1
Examples on use of Party Category information Use of value PISN attendant The receipt of a value PISN attendant could prevent the user from invoking services like Call Intrusion, Call Completion or Hold.
A.2.2
Use of value Emergency extension The value Emergency extension could be used on calls from “Emergency Telephones” located for instance at motor ways. This would allow the terminating side to treat the calls in the most suitable way, i.e. convey them to the proper answering position in case called number is a group number. Additional information relating to the physical location could also be conveyed in element Equipment Identity.
.
.
.
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]
A description of this Standard can be found on the ECMA Web site, www.ecma.ch. From there, files E250-DOC.EXE (MSWord, self-expanding) and E250-PDF.PDF (Acrobat PDF) can be freely downloaded. The ECMA web site 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-250 is available free of charge in printed form and as a file. See inside cover page for instructions