Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-346 — Private Integrated Services Network (PISN) – Specification, functional model and information flows – Message Centre Monitoring and Mailbox Identification supplementary services (MCM-SD / MID-SD) (June 2003)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

centre ecma ecmainternational flows identification information integrated message

ecma, standard, ecma international, specification, ecma-346, ecma 346, 346, private, integrated, services, network, pisn, functional, model, and, information, flows, message, centre, monitoring, mailbox, identification, supplementary, mcm-sd, mid-sd

Standard ECMA-346 June 2003

International

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – Message Centre Monitoring and Mailbox Identification Supplementary Services

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

Standard ECMA-346 June 2003

International

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – Message Centre Monitoring and Mailbox Identification Supplementary Services (MCM-SD / MID-SD)

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

Ecma-346.doc

05-04-04 14,54

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 DTS/ECMA-00229. This particular Standard specifies the Message Centre Monitoring and Mailbox Identification supplementary service. SS-MCM is based on SS-MWI and includes its entire functionality. The interoperability with SS-MWI is guaranteed. Compared to SS-MWI, SS-MCM offers an enhanced functionality for monitoring status changes of messages stored in the Served User's Mailbox as follows: •

individual activation and deactivation for the monitoring of messages of different Message Type(s) within the Mailbox as well as interrogation of the actual SS-MCM configuration;

•

retrieval of information about all messages (i.e. new and retrieved messages) in the mailbox independent of the Message Status;

•

request of detailed updated information about messages stored in the mailbox at every time.

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.

This ECMA Standard has been adopted by the General Assembly of June 2003.

- i -

Table of contents 1

Scope

Conformance

References (normative)

Definitions 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 Address Header 4.2.2 C o mp l e t e I n f o r ma t i o n 4.2.3 C o mp r e s s e d I n f o r ma t i o n 4.2.4 Deleted Messages 4.2.5 Ma ilb o x 4.2.6 Me s s a g e Ce n tr e ( MC) 4.2.7 Me s s a g e S ta tu s 4.2.8 Me s s a g e T yp e 4.2.9 Me s s a g e W a itin g S ig n a l 4.2.10 N e w Me s s a g e 4.2.11 Originator 4.2.12 O r ig in a to r a d d r e s s 4.2.13 Re tr ie v e d Me s s a g e 4.2.14 Served User

2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3

5 6

List of acronyms SS-MCM stage 1 specification 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 Procedures 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 t e r a c t i o n s w i t h o t h e r S u p p l e me n t a r y S er v i c e s / A d d i t i o n a l N e t w o r k F e a t u r e s 6.3.1 Calling Line Identification Presentation (SS-CLIP) 6.3.2 C o n n e c t e d L i n e 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 L P ) 6.3.3 Ca llin g /Co n n e c te d L in e I d e n tif ic a tio n Re s tr ic tio n ( S S - CL I R) 6.3.4 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.5 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.6 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.7 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.8 C a l l F o r w a r d in g B u s y ( S S - C F B )

3 3 3 3 4 4 4 4 7 8 8 8 8 8 8 8 8 8

- ii -

6.3.9 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.3.10 P a t h R e p l a c e me n t ( A N F - P R ) 6.3.11 Call Transfer (SS-CT) 6.3.12 Call Deflection (SS-CD) 6.3.13 C o mp l e t i o n o f C a l l s t o B u s y S u b s c r i b e r s ( S S - C C B S ) 6.3.14 C o mp l e t i o n o f C a l l s o n N o R e p ly ( S S - C C N R ) 6.3.15 Call Offer (SS-CO) 6.3.16 Do Not Disturb (SS-DND) 6.3.17 Do Not Disturb Override (SS-DNDO) 6.3.18 Call Intrusion (SS-CI) 6.3.19 A d v ic e o f Ch a r g e ( S S - A O C) 6.3.20 Recall (SS-RE) 6.3.21 Call Interception (SS-CINT) 6.3.22 T r a n s it Co u n te r ( A N F - T C) 6.3.23 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.24 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6.3.25 W ir e l e s s T e r mi n a l L o c a t i o n Re g is tr a tio n ( S S - W T L R) 6.3.26 W ir e l e s s T e r mi n a l I n c o min g C a l l ( S S - W T MI ) 6.3.27 W ir e l e s s T e r mi n a l O u t g o in g C a l l ( S S - W T M O ) 6.3.28 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.29 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.30 C o mmo n I n f o r ma t i o n ( S S - C MN ) 6.3.31 Call Priority Interruption (Protection) (SS-CPI(P)) 6.3.32 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.33 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.34 P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) 6.3.35 Single Step Call Transfer (SS-SSCT) 6.3.36 S i mp l e D i a l o g ( S S - S D ) 6.3.37 Call Identification and Call Linkage (ANF-CIDL) 6.3.38 Short Message Service (SS-SMS) 6.3.39 Make Call Request (SS-MCR) 6.3.40 Ma ilb o x I d e n tif ic a tio n ( S S - MI D ) 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 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

S S - M I D s t a g e 1 s p e c if ic a t io n 7 . 1 D e s c r ip tio n 7.1.1 G e n e r a l d e s c r ip tio n 7.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 7.2 Procedures 7.2.1 P r o v is io n / w ith d r a w a l 7.2.2 N o r ma l p r o c e d u r e s 7.2.3 E x c e p tio n a l p r o c e d u r e s 7 . 3 I n t e r a c t i o n s w i t h o t h e r S u p p l e me n t a r y S er v i c e s / A d d i t i o n a l N e t w o r k F e a t u r e s 7.3.1 Calling Line Identification Presentation (SS-CLIP) 7.3.2 C o n n e c t e d L i n e 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 L P )

13 13 13 13 13 13 13 13 14 14 14

- iii -

7.3.3 Ca llin g /Co n n e c te d L in e I d e n tif ic a tio n Re s tr ic tio n ( S S - CL I R) 7.3.4 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 ) 7.3.5 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) 7.3.6 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 ) 7.3.7 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 ) 7.3.8 C a l l F o r w a r d in g B u s y ( S S - C F B ) 7.3.9 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 7.3.10 P a t h R e p l a c e me n t ( A N F - P R ) 7.3.11 Call Transfer (SS-CT) 7.3.12 Call Deflection (SS-CD) 7.3.13 C o mp l e t i o n o f C a l l s t o B u s y S u b s c r i b e r s ( S S - C C B S ) 7.3.14 Co mp le tio n o f Ca lls o n N o Re p ly ( S S - CCN R) 7.3.15 Call Offer (SS-CO) 7.3.16 Do Not Disturb (SS-DND) 7.3.17 Do Not Disturb Override (SS-DNDO) 7.3.18 Ca ll I n tr u s io n ( S S - CI ) 7.3.19 A d v ic e o f Ch a r g e ( S S - A O C) 7.3.20 Recall (SS-RE) 7.3.21 Call Interception (SS-CINT) 7.3.22 T r a n s it Co u n te r ( A N F - T C) 7.3.23 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 ) 7.3.24 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 7.3.25 W ir e le s s T e r min a l L o c a tio n Re g is tr a tio n ( S S - W T L R) 7.3.26 W ir e l e s s T e r mi n a l I n c o min g C a l l ( S S - W T MI ) 7.3.27 W ir e l e s s T e r mi n a l O u t g o in g C a l l ( S S - W T M O ) 7.3.28 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 ) 7.3.29 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 ) 7.3.30 Co mmo n I n f o r ma tio n ( S S - CMN ) 7.3.31 Call Priority Interruption (Protection) (SS-CPI(P)) 7.3.32 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 ) 7.3.33 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 ) 7.3.34 P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) 7.3.35 Single Step Call Transfer (SS-SSCT) 7.3.36 S i mp l e D i a l o g ( S S - S D ) 7.3.37 Ca ll I d e n tif ic a tio n a n d Ca ll L in k a g e ( A N F - CI D L ) 7.3.38 Short Message Service (SS-SMS) 7.3.39 Make Call Request (SS-MCR) 7.3.40 Me s s a g e Ce n tr e Mo n ito r in g ( S S - MCM) 7 . 4 I n te r w o r k in g c o n s id e r a tio n s 7.5 Overall SDL

14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 16 16 16 16

SS-MCM stage 2 specification 8 . 1 F u n c tio n a l mo d e l 8.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 8.1.2 Description of Functional Entities

18 18 18 18

- iv -

8 . 2 I n f o r ma t i o n f l o w s 8.2.1 D e f in itio n o f in f o r ma tio n f lo w s 8.2.2 I n f o r ma tio n f lo w s e q u e n c e s 8.3 Functional Entity actions 8.3.1 Functional Entity actions of FE1 8.3.2 Functional Entity actions of FE2 8.3.3 Functional Entity actions of FE3 8 . 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 8.4.1 Be h a v io u r o f F E 1 8.4.2 Be h a v io u r o f F E 2 8.4.3 Be h a v io u r o f F E 3 8 . 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 8 . 6 I n te r w o r k in g c o n s id e r a tio n s

19 19 25 28 28 29 29 30 30 37 44 50 50

S S - M I D s t a g e 2 s p e c if ic a t io n 9 . 1 F u n c tio n a l mo d e l 9.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 9.1.2 Description of Functional Entities 9 . 2 I n f o r ma t i o n f l o w s 9.2.1 D e f in itio n o f in f o r ma tio n f lo w s 9.2.2 I n f o r ma tio n f lo w s e q u e n c e s 9.3 Functional Entity actions 9.3.1 Functional Entity actions of FE1 9.3.2 Functional Entity actions of FE2 9.3.3 Functional Entity actions of FE3 9 . 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 9.4.1 Be h a v io u r o f F E 1 9.4.2 Be h a v io u r o f F E 2 9.4.3 Be h a v io u r o f F E 3 9 . 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 9 . 6 I n te r w o r k in g c o n s id e r a tio n s

51 51 51 51 51 51 53 54 54 54 54 55 55 57 59 60 60

Scope This Standard specifies supplementary service Message Centre Monitoring/Mailbox Identification (SSMCM/MID), which is related, but not limited, to various basic services supported by Private Integrated Services Networks (PISNs). Basic services are specified in ECMA-142. The supplementary service MCM enables a Served User to get informed by a Message Centre about the status and status changes of messages stored in that Served Users Mailbox. The supplementary service MID enables a Message Centre to identify a specific mailbox of a Served User in case that the Served User has more than one Mailbox within the Message Centre. In addition SS-MID enables a Served User to authenticate himself/herself at a specific Mailbox located within the Message Centre. Service 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 SS-MCM/MID. The stage 1 specification (clause 6 and 7) specifies the supplementary service as seen by users of PISNs. The stage 2 specification (clause 8 and 9) specifies the functional entities involved in the supplementary service and the information flows between them.

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 and 7 (stage 1) and clause 8 and 9 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.

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-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 64 kbit/s Bearer Services – Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)

ECMA-241

Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – Message Waiting Indication Supplementary Service (International Standard ISO/IEC 15505)

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 (1999)

- 2 -

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:

4.2

− Private Integrated services Network eXchange (PINX)

(ECMA-133)

− Private Integrated Services Network (PISN)

(ECMA-133)

− Service

(ITU-T Rec. I.112)

− Signalling

(ITU-T Rec. I.112)

− Supplementary Service

(ITU-T Rec. I.210)

− Telecommunication Service

(ECMA-142)

− User

(ECMA-142)

Other definitions

4.2.1

Address Header The Address Header includes Originator address information and, optionally, the receiving time stamp and the priority of one specific message.

4.2.2

C o m p le t e I n f o r m a t io n A complete list of Address Headers of either all New or all Retrieved Messages of one specific Message Type in a Mailbox.

4.2.3

C o m p r e s s e d I n f o r m a t io n Includes the number of either all New or all Retrieved Messages of one specific Message Type. Optionally, in the compressed information the Originator address, the priority level and the time stamp of the highest priority message can be included. If there is more than one message of the highest priority the optional information shall be related to the latest received highest priority message.

4.2.4

D e le t e d M e s s a g e s A message of any Message Type which was previously stored in the Mailbox but which is not available anymore due to deletion by the Served User.

4.2.5

M a ilb o x A logical entity within a Message Centre which stores all messages (New Messages and Retrieved Messages) of one or more Message Types for one specific Served User who is registered at the Message Centre.

4.2.6

Message Centre (MC) The entity within the network which administrates Mailboxes for Served Users. The MC provides the Served User with information •

about each incoming New Message in the Served User's Mailbox and

•

about Message Status changes (e.g. due to retrieval or deletion) in the Served User's Mailbox

by means of Complete or Compressed Information for New and Retrieved Messages. This information is provided by update procedures. 4.2.7

Message Status Describes whether a stored message at the Served User’s Mailbox is a New Message or a Retrieved Message.

4.2.8

M e s s a g e Ty p e The type of a message stored at the MC. A Message Type indicates either the telecommunication service (e.g. speech, 3.1kHz audio, etc.) that is needed to retrieve a specific message via a PISN or the general type of a message that might not be directly retrieved by means of a PISN (e.g. email or video).

- 3 -

4.2.9

M e s s a g e W a it in g S ig n a l Any type of signal presented to a Served User's terminal that is useful to draw a Served User’s attention to the arrival of a New Message in the Served User's Mailbox. NOTE The indication may be a lamp, special tone, display string etc. The technical realisation of the Message Waiting Signal is outside the scope of this Standard.

4.2.10

New Message A message of any Message Type, which is stored in a Mailbox. The Served User has not yet retrieved the message.

4.2.11

O r ig in a t o r The user who has left a message at the Served User's Mailbox.

4.2.12

O r ig in a t o r a d d r e s s Address information (i.e. Party Number) of the originator.

4.2.13

R e t r ie v e d M e s s a g e A message of any type, which is stored in a Mailbox. The Served User has already retrieved but not deleted the message (i.e. the message is no longer a New Message).

4.2.14

Served User The owner of a specific Mailbox at a Message Centre. The Served User receives an indication about status changes of the messages in the Served User’s Mailbox from the Message Centre.

List of acronyms

Functional Entity

ISDN

Integrated Services Digital Network

MCM

Message Centre Monitoring

MID

Mailbox Identification

MWI

Message Waiting Indication

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

Supplementary Service

SS-MCM stage 1 specification

6.1 6.1.1

Description General description The supplementary service MCM enables a Message Centre to inform a registered Served User about the status and status changes of messages stored in this Served Users Mailbox. This can be due to the arrival of New Messages or the change of the Message Status of stored messages (e.g. retrieval or deletion of messages). Additionally the Served User can request the current status of the messages in the Mailbox from the Message Centre. If there are New Messages for the Served User stored in the Mailbox a Message Waiting Signal may be set at the Served User’s terminal. Additionally a Served User might activate, deactivate or interrogate Message Centre Monitoring individually for the different Message Types.

- 4 -

NOTE 1 The procedures for how the Served User accesses the messages stored in the MC is outside the scope of this Standard. NOTE 2 The procedures for how a message can be left in a Served User’s Mailbox is outside the scope of this Standard. SS-MCM is based on SS-MWI (ECMA-241) and includes its entire functionality. Therefore the interoperability with SS-MWI is guaranteed. Compared to SS-MWI, SS-MCM offers an enhanced functionality for monitoring status changes of messages stored in the Served User's Mailbox as follows: • individual activation and deactivation for the monitoring of messages of different Message Type(s) within the Mailbox as well as interrogation of the actual SS-MCM configuration; • retrieval of information about all messages (i.e. New and Retrieved Messages) in the mailbox independent of the Message Status; • 6.1.2

6.2 6.2.1

request of detailed updated information about messages stored in the Mailbox.

Qualifications on applicability to telecommunication services This supplementary service does not apply directly to any basic telecommunication service. However, MCM relates to a basic service for which there are messages stored in the Served User's Mailbox.

Procedures P r o v is io n / wit h d r a wa l SS-MCM may be provided or withdrawn after pre-arrangement with the service provider or may be generally available to all users.

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 In general, SS-MCM shall be available for all Served Users in a default configuration as arranged by the service provider. The default configuration defines the messages (i.e. a set of Message Types) which can be stored in principle in a Served User's Mailbox. The default configuration also defines whether complete information or compressed information about the messages of each specific Message Type is sent to the Served User. By sending an appropriate indication to the MC the Served User can individually modify the configuration in the following manner: •

activation of either one or more of the predefined Message Types so that changes in the Mailbox of that activated Message Types will be presented to the Served User. After that the MC shall perform the Update procedure as described in 6.2.2.2.2;

•

deactivation of either one or more of predefined Message Types so that changes in the Mailbox of that deactivated Message Types will not be presented to the Served User anymore. After that the MC shall perform the Update procedure as described in 6.2.2.2.2. In addition, an indication shall be given to the Served User stating that no information about New Messages or Retrieved Messages of this Message Type will be presented to the Served User while monitoring is deactivated;

•

changing of the presentation style of SS-MCM information from complete information to compressed information or from compressed information to complete information for a specific Message Type. NOTE The change from compressed information to complete information (and vice versa) for a specific Message Type is only possible if the MC supports this option.

•

Re-setting of all the changed SS-MCM parameters to the default configuration.

In addition, the Served User can interrogate at the MC to get information about the actual configuration of SS-MCM. This means, that the Served User receives an actual list of all different

- 5 -

Message Types (i.e. the kind of messages) from the MC, which can be presented to the Served User together with an indication whether the Served User gets the complete information or only the compressed information about the stored messages of the specific Message Type(s). All described changes of the default configuration shall be initiated from the Served User (and confirmed with an appropriate indication by the MC) by using an already existing connection or by setting up a new call independent connection. Release of the call independent connection is the responsibility of the Served User. 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-MCM enables a MC to send status information to a Served User about messages stored in the Mailbox of the Served User. All information shall be delivered between the MC and the Served User by using an already existing connection or by setting up a new call independent connection. Release of the call independent connection is the responsibility of its initiator. The sections below describe this behavior in detail.

6.2.2.2.1

I n c o m in g N e w M e s s a g e Upon receipt of a new message in the Mailbox, the MC shall send an indication through the PISN towards the Served User with the following information: •

the address of the Served User;

•

the Message Type of the specific New Message;

•

optionally, the address of the Message Centre.

In addition to that, and depending on the presentation style that was selected in the configuration for New Messages of that specific Message Type (i.e. compressed or complete information), the following information shall be delivered through the PISN towards the Served User by the MC: a) Compressed Mode: •

the number of New Messages waiting for that specific Message Type;

•

optionally, the priority of the latest highest priority message waiting for that specific Message Type;

•

optionally, the address of the user that left the latest highest priority message;

•

optionally, the time when the latest highest priority message was left.

b) Complete Mode: •

optionally, the number of New Messages waiting for that specific Message Type;

•

the address of the user that left the last incoming message;

•

optionally, the priority of the last incoming message;

•

optionally, the time of the last incoming message.

NOTE 1 This structure is the same as the corresponding information specified in SS-MWI. If the Complete Mode was selected for a specific Message Type each arrival of a New Message shall be reported to the Served User. If the Compressed Mode was selected the new message arrival shall be reported by the MC using one of the following methods: •

each new message is reported individually;

•

more than one message is reported by using a single indication.

The support of compressed information is mandatory, whereas the support of complete information is optional. Storing of the delivered information at the Served User is optional. In the case that the

- 6 -

originator address is NOT a PISN number (e.g. Message Type is "email"), only the compressed mode shall be used. Each receipt of New Message information from the MC shall be confirmed with an appropriate indication. In addition, a Message Waiting Signal shall be set (if applicable) for that specific Message Type at the Served User’s terminal. If there are no more New Messages of a specific Message Type available in the mailbox (i.e. the Served User has retrieved all messages of a specific Message Type), the MC shall send an indication through the PISN towards the Served User. This indication shall contain the following information: •

the address of the Served User;

•

the Message Type(s) for which New Message(s) are no longer available;

•

optionally, the address of the Message Centre.

NOTE 2 This structure is the same as the corresponding information specified in SS-MWI. This indication shall be confirmed and the Message Waiting Signal at the Served User’s terminal, if any, shall be cancelled for that specific Message Type(s). 6.2.2.2.2

U p d a t e o f M e s s a g e C e n t r e I n f o r m a t io n Whenever the number of new and/or retrieved messages in a Mailbox changes, excluding the arrival of a New Message (e.g. the Served User has retrieved one or more of the new messages or has deleted one or more messages), the Message Centre shall inform the Served User by sending an updated list of all new and/or retrieved messages (i.e. update procedure). The update information shall include •

the address of the Message Centre;

•

the address of the Served User;

•

the Message Type of the messages for that specific update procedure;

•

either Complete Information about New and/or Retrieved Messages;

•

or Compressed Information about New and/or Retrieved Messages;

•

or a mixture of both, e.g. Complete Information for New Messages and Compressed Information for Retrieved Messages as defined in the actual configuration of SS-MCM.

NOTE 1 The procedures for how the Served User retrieves the content of messages and how the Served User can delete messages in the Mailbox is out of the scope of this Standard. The update procedure shall be based on the Message Type. The information for the next Message Type shall only be transmitted after the update information for all new and/or retrieved messages of one specific Message Type has been completely transmitted to the Served User. Each update procedure shall be confirmed with an appropriate indication. NOTE 2 The default style (Compressed or Complete Information), which is used for the update procedure of the various Message Type(s), is implementation dependent and will be pre-defined by the service provider. At the end of the update procedure the Message Waiting Signal at the Served User’s terminal, if available, shall be refreshed for the various Message Types.

- 7 -

6.2.2.2.3

Update request from the Served User At any time the Served User can request the Message Centre to send update information for either all available message types or only for one specific Message Type. To request an update for a Mailbox at the MC the following information from the Served User shall be sent towards the MC: •

address of the Served User (i.e. Party Number);

•

the Message Type(s) for which the Served User requests an update;

•

optionally, the address of the Message Centre (e.g. Party Number).

After this request the Message Centre shall answer the Served User request with information about the status of the New Messages in the Served User's Mailbox of the requested Message Type(s). Depending on the presentation style (i.e. compressed or complete information), which is adopted in the current configuration for the New Messages, the MC shall provide the Served User with the following information: a) Compressed Mode: •

Message Type for which the Served User has requested an update;

•

optionally, the address of the Message Centre;

•

optionally, the number of New Messages waiting for that specific Message Type;

•

optionally, the priority of the latest highest priority New Message waiting for that specific Message Type;

•

optionally, the address of the user that left the latest highest priority New Message;

•

optionally, the time when the latest highest priority New Message was left.

b) Complete Mode: •

Message Type for which the Served User has requested an update;

•

optionally, the number of New Messages waiting for that specific Message Type.

NOTE This structure is the same as the corresponding information specified in SS-MWI. After sending this information the MC shall start the update procedure as described in 6.2.2.2.2. 6.2.2.2.4

M a ilb o x – f u ll in d ic a t io n Whenever the Served User's Mailbox reaches its storing capacity (or a specific threshold value) for one or more Message Types, the MC may send a Mailbox-full indication for specific Message Types towards the Served User. The Mailbox-full indication shall be sent independently of all other monitoring procedures.

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 The Served User shall get an appropriate error indication if

6.2.3.2

•

the Served User wants to communicate with the MC but has no access from the service provider;

•

a specific Message Type is requested by the Served User but not provided by the MC;

•

a specific presentation style (i.e. compressed and/or complete information) for messages of a specific Message Type requested from the Served User is not provided by the MC.

I n v o c a t io n a n d o p e r a t io n The Served User shall get an appropriate error indication if •

the Served User wants to communicate with the MC but has no access from the service provider;

•

a specific Message Type is requested by the Served User but not provided by the MC;

- 8 -

•

6.3

a specific presentation style (i.e. compressed and/or complete information) for messages of a specific Message Type requested from the Served User is not provided by the MC.

Interactions with other Supplementary Services / Additional Network Features 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 (SS-CLIP) No interaction.

6.3.2

Connected Line Identification Presentation (SS-COLP) No interaction.

6.3.3

C a l l i n g /C o n n e c t e d L i n 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 L I R ) No interaction.

6.3.4

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

6.3.5

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

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

6.3.7

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

C a ll F o r wa r d in g Bu s y ( S S - C F B) No interaction.

6.3.9

C a l l F o r wa r d i n g N o R e p l y ( S S - C F N R ) No interaction.

6.3.10

Path Replacement (ANF-PR) No interaction.

6.3.11

C a ll Tr a n s f e r ( S S - C T) No interaction.

6.3.12

C a ll D e f le c t io n ( S S - C D ) No interaction.

6.3.13

Completion of Calls to Busy Subscribers (SS-CCBS) No interaction.

6.3.14

Completion of Calls on No Reply (SS-CCNR) No interaction.

6.3.15

C a ll O f f e r ( S S - C O ) No interaction.

6.3.16

Do Not Disturb (SS-DND) No interaction.

6.3.17

Do Not Disturb Override (SS-DNDO) No interaction.

6.3.18

C a ll I n t r u s io n ( S S - C I ) No interaction.

- 9 -

6.3.19

A d v ic e o f C h a r g e ( S S - A O C ) No interaction.

6.3.20

R e c a ll ( S S - R E) No interaction.

6.3.21

Call Interception (SS-CINT) No interaction.

6.3.22

Tr a n s it C o u n t e r ( A N F - TC ) No interaction.

6.3.23

Route Restriction Class (ANF-RRC) No interaction.

6.3.24

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. NOTE SS-MCM is based on SS-MWI and includes its entire functionality. The interoperability with SS-MWI is therefore guaranteed. Compared to SS-MWI, SS-MCM offers an enhanced functionality for monitoring status changes of messages stored in the Served User's Mailbox.

6.3.25

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 ) No interaction.

6.3.26

Wireless Terminal Incoming Call (SS-WTMI) No interaction.

6.3.27

Wireless Terminal Outgoing Call (SS-WTMO) No interaction.

6.3.28

Wireless Terminal Authentication of a WTM User (SS-WTAT) No interaction.

6.3.29

Wireless Terminal Authentication of the PISN (SS-WTAN) No interaction.

6.3.30

C o m m o n I n f o r m a t io n ( S S - C M N ) 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.3.32

Private User Mobility Incoming Call (ANF-PUMI) No interaction.

6.3.33

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

P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) No interaction.

6.3.35

Single Step Call Transfer (SS-SSCT) No interaction.

6.3.36

S im p le D ia lo g ( S S - S D ) No interaction.

6.3.37

C a ll I d e n t if ic a t io n a n d C a ll Lin k a g e ( A N F - C I D L) No interaction.

- 10 -

6.3.38

Short Message Service (SS-SMS) No interaction.

6.3.39

M a k e C a ll R e q u e s t ( S S - M C R ) No interaction.

6.3.40

M a ilb o x I d e n t if ic a t io n ( S S - M I D ) If SS-MID is used in conjunction with SS-MCM and if mailbox identification services offered by SSMID fail, it is implementation dependent if the services of SS-MCM are executed. If authentication services offered by SS-MID fail, the activation, deactivation, interrogation and update request services of SS-MCM shall not be executed.

6.4

Interworking considerations Interworking with other networks is optional, if the other network provides similar services.

6.5

Overall SDL The figure 1 contains the dynamic description of the SS-MCM activation, deactivation and interrogation procedures and figure 2 contains the dynamic description of SS-MCM normal operation procedure using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1999). Input signals from the left and output signals to the left represent primitives from and to the Message Centre. Input signals from the right and output signals to the right represent primitives from and to the Served User.

- 11 -

MCM idle

activation of specific Message Type(s) in complete or compressed style

deactivation of specific Message Type(s)

deactivation allowed from the MC

YES

deactivation of the requested Message Types from the MC

appropriate confirmation

Interrogation of characteristics of specific Message Type(s)

activation allowed from the MC

interogation allowed from the MC ?

YES activation of Message Type and/or complete or compressed style from the MC

YES

indication of MCM characteristics for the Served User

appropriate confirmation

appropriate error indication

MCM idle

F ig u r e 1 – S S - M C M O v e r a ll S D L: 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 r e q u e s t

- 12 -

MCM idle

incoming New Message for Served User

internal indication for a full Mailbox (e.g.treshold value reached)

updated information from the Message Centre

Mailbox full indication

update request by the Served User

Update Request allowed ?

YES

B MCM idle

Update/update request for the New AND Retrieved Messages with complete/ compressed information?

YES

only reduced update information about New Messages

appropriate error indication

Update/update request for the Retrieved Messages with compressed / complete information?

YES

New Message indication with complete or compressed information

appropriate confirmation

indication with the updated list of New AND Retrieved Message

appropriate confirmation

indication with the updated list for the Retrieved Messages

appropriate confirmation

indication with the updated list for the New Messages

appropriate confirmation

MCM idle

F ig u r e 2 – S S - M C M O v e r a ll S D L: A r r iv a l o f a N e w M e s s a g e a t t h e M C , U p d a t e a n d U p d a t e Request procedure, Mailbox-full indication

- 13 -

SS-MID stage 1 specification

7.1

Description

7.1.1

General description The supplementary service MID enables a Message Centre to identify a specific mailbox of a Served User in case that the Served User has more than one Mailbox within the Message Centre. In addition SSMID enables a Served User to authenticate himself/herself at a specific Mailbox located within the Message Centre.

7.1.2

Qualifications on applicability to telecommunication services This supplementary service does not apply directly to any basic telecommunication service.

7.2

Procedures

7.2.1

P r o v is io n / wit h d r a wa l SS-MID may be provided or withdrawn after pre-arrangement with the service provider or may be generally available to all users.

7.2.2 Normal procedures 7.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 Not applicable. 7.2.2.2 I n v o c a t io n a n d o p e r a t io n 7 . 2 . 2 . 2 . 1 I d e n t if ic a t io n In case the Served User has more than one mailbox at the MC, the MC shall identify a specific mailbox by sending the following mailbox identification data to the Served User: •

the address of the Message Centre where the Mailbox of the Served User is located;

•

the address of the Served User;

•

optionally, the Name of the Served User;

•

the Served User’s Mailbox identity (e.g. alphanumeric string).

The receipt of this information shall be confirmed with an appropriate indication to the MC. 7.2.2.2.2

A u t h e n t ic a t io n SS-MID enables a Served User to authenticate himself/herself at a specific Mailbox by sending the following address and authentication data to the MC: •

the address of the Message Centre where the Mailbox of the Served User is located;

•

the address of the Served User;

•

optionally, the Name of the Served User;

•

optionally, a Served User’s Mailbox identity (e.g. alphanumeric string);

•

an authentication string (i.e. password) from the Served User to identify himself/herself at the Mailbox.

After a successful verification of the Served User's password the MC shall confirm this to the Served User with an appropriate indication. All information shall be delivered between the Served User and the MC by using an already existing connection or by setting up a new call independent connection. Release of the call independent connection is the responsibility of its initiator. 7.2.3 Ex c e p t io n a l p r o c e d u r e s 7.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.

- 14 -

7.2.3.2

I n v o c a t io n a n d o p e r a t io n If an invalid mailbox identity is received from the MC an appropriate error indication shall be sent towards the Message Centre. If an invalid Served User password is received at the MC, the MC shall indicate the authentication failure by sending an appropriate error indication towards the Served User.

7.3

7.3.1

Calling Line Identification Presentation (SS-CLIP) No interaction.

7.3.2

Connected Line Identification Presentation (SS-COLP) No interaction.

7.3.3

C a l l i n g /C o n n e c t e d L i n 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 L I R ) No interaction.

7.3.4

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

7.3.5

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.

7.3.6

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

7.3.7

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.

7.3.8

C a ll F o r wa r d in g Bu s y ( S S - C F B) No interaction.

7.3.9

C a l l F o r wa r d i n g N o R e p l y ( S S - C F N R ) No interaction.

7.3.10

Path Replacement (ANF-PR) No interaction.

7.3.11

C a ll Tr a n s f e r ( S S - C T) No interaction.

7.3.12

C a ll D e f le c t io n ( S S - C D ) No interaction.

7.3.13

Completion of Calls to Busy Subscribers (SS-CCBS) No interaction.

7.3.14

Completion of Calls on No Reply (SS-CCNR) No interaction.

7.3.15

C a ll O f f e r ( S S - C O ) No interaction.

7.3.16

Do Not Disturb (SS-DND) No interaction.

7.3.17

Do Not Disturb Override (SS-DNDO) No interaction.

- 15 -

7.3.18

C a ll I n t r u s io n ( S S - C I ) No interaction.

7.3.19

A d v ic e o f C h a r g e ( S S - A O C ) No interaction.

7.3.20

R e c a ll ( S S - R E) No interaction.

7.3.21

Call Interception (SS-CINT) No interaction.

7.3.22

Tr a n s it C o u n t e r ( A N F - TC ) No interaction.

7.3.23

Route Restriction Class (ANF-RRC) No interaction.

7.3.24

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.

7.3.25

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 ) No interaction.

7.3.26

Wireless Terminal Incoming Call (SS-WTMI) No interaction.

7.3.27

Wireless Terminal Outgoing Call (SS-WTMO) No interaction.

7.3.28

Wireless Terminal Authentication of a WTM User (SS-WTAT) No interaction.

7.3.29

Wireless Terminal Authentication of the PISN (SS-WTAN) No interaction.

7.3.30

C o m m o n I n f o r m a t io n ( S S - C M N ) No interaction.

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

7.3.32

Private User Mobility Incoming Call (ANF-PUMI) No interaction.

7.3.33

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.

7.3.34

P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) No interaction.

7.3.35

Single Step Call Transfer (SS-SSCT) No interaction.

7.3.36

S im p le D ia lo g ( S S - S D ) No interaction.

7.3.37

C a ll I d e n t if ic a t io n a n d C a ll Lin k a g e ( A N F - C I D L) No interaction.

7.3.38

Short Message Service (SS-SMS) No interaction.

- 16 -

7.3.39

M a k e C a ll R e q u e s t ( S S - M C R ) No interaction.

7.3.40

Message Centre Monitoring (SS-MCM) If SS-MID is used in conjunction with SS-MCM and if mailbox identification services offered by SSMID fail, it is implementation dependent if the services of SS-MCM are executed. If authentication services offered by SS-MID fail, the activation, deactivation, interrogation and update request services of SS-MCM shall not be executed.

7.4

Interworking considerations Interworking with other networks is optional, if the other network provides similar services.

7.5

Overall SDL Figure 3 contains the dynamic description of SS-MID using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1999). The SDL process represents the behaviour of the network in providing SS-MID. Input signals from the left and output signals to the left represent primitives from and to the Message Centre. Input signals from the right and output signals to the right represent primitives from and to the Served User.

- 17 -

MID idle

Mailbox Authentication data from the Served User to the MC

Mailbox identifcation data from the MC to the Served User

evaluation of the authentication data from the Served User

right mailbox ?

YES evaluation of Served User successful ?

YES

indication for successful authentication of the Served User

indication for successful mailbox identification

appropriate error indication

MID idle

F ig u r e 3 – S S - M I D O v e r a ll S D L

appropriate error indication

- 18 -

SS-MCM stage 2 specification

8.1

Functional model

8.1.1

Functional model description The functional model shall comprise the following Functional Entities (FEs): FE1

Message Centre's control entity;

FE2

Served User's control entity;

FE3

Served User Agent.

The following relationship shall exist between these FEs: ra

between FE1 and FE2;

between FE2 and FE3.

Figure 4 shows these FEs and this relationship.

FE1

FE2

FE3

F ig u r e 4 – F u n c t io n a l m o d e l f o r S S - M C M 8.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 8.1.2.1 M e s s a g e C e n t r e 's c o n t r o l e n t it y , F E1 This Functional Entity:

8.1.2.2

8.1.2.3

receives an activation, deactivation and / or interrogation request from FE2;

sends a New Message indication to FE2;

sends updated information about New Messages and/or Retrieved Messages to FE2;

receives a Served User request for updated Mailbox information from FE2;

sends the Mailbox-full indication to FE2.

Served User's control entity, FE2 This Functional Entity: -

receives an activation, deactivation and / or interrogation request from FE3 and sends this request to FE1;

receives an indication about the arrival of a New Message from FE1 and sends this New Message indication to FE3;

receives updated information about New Message and / or Retrieved Messages stored at the Served User's Mailbox from FE1 and sends this updated information to FE3;

receives a request for updated Mailbox information from FE3 and sends this request to FE1;

receives a Mailbox-full indication from FE1 and send this Mailbox-full indication to FE3.

Served User Agent, FE3 This Functional Entity: -

sends an activation, deactivation and / or interrogation request to FE2;

receives an indication about the arrival of a New Message in the Served User's Mailbox from FE2;

- 19 -

8.2

receives updated information about New Message and/or Retrieved Messages stored at the Served User's Mailbox from the FE2;

sends a request for updated Mailbox information to FE2;

receives a Mailbox-full indication from FE2.

Information flows

8.2.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 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. The information flows across rb represent information flows between two functional entities FE2 and FE3. If FE3 is controlled by or resides in FE2 (e.g. stimulus terminal), the information flows across rb are outside the scope of this Standard.

8.2.1.1

M C M _ S e r v ic e C h a n g e MCM_ServiceChange is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FE1 used by the Served User to activate or deactivate monitoring of one or more predefined Message Types. Table 1 lists the elements within the MCM_ServiceChange information flow. Table 1 – Content of MCM_ServiceChange Element

Request

Confirm

NOTE

activation

deactivation

Served User identity

Message Centre identity

List of Message Types

Presentation style of the New Message information

Presentation style of the Retrieved Message information

Result

NOTE 1 This is the Served User's Party Number (e.g. PISN number). NOTE 2 This element identifies the Message Centre (e.g. PISN number). NOTE 3 This indicates one or more Message Types (e.g. speech, email, fax) which shall be activated or deactivated. NOTE 4 This is an indication whether compressed information or complete information shall be presented to the Served User for the New Messages. If this element is not present the presentation style shall be used as defined in the default configuration. NOTE 5 This is an indication whether compressed information or complete information shall be presented to

- 20 -

the Served User for the Retrieved Messages. If this element is not present the presentation style shall be used as defined in the default configuration. NOTE 6 This indicates acceptance or the reason for rejection. 8.2.1.2

MCM_Interrogate MCM_Interrogate is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FE1 used by the Served User to interrogate the properties and configuration parameters for a specific Message Type . Table 2 lists the elements within the MCM_Interrogate information flow. Ta b le 2 – C o n t e n t o f M C M _ I n t e r r o g a t e Element

Request

Confirm

NOTE

Served User identity

Message Centre identity

Message Type or List of Message Types

Information about the Message Type or List of Message Types

Result

NOTE 1 This is the Served User's identity (e.g. PISN number). NOTE 2 This element identifies the Message Centre (e.g. PISN number). NOTE 3 This is a specific Message Type (e.g. speech, email, fax) or a List of Message Types for which the Served User requests information about the predefined configuration. NOTE 4 This element gives information to the Served User whether the interrogated Message Type is supported with compressed information and/or complete information for New and/or Retrieved Messages. NOTE 5 This indicates acceptance or the reason for rejection. 8.2.1.3

M C M _ N e wM e s s a g e MCM_NewMessage is a confirmed information flow across ra from FE1 to FE2 and across rb from FE2 to FE3 used to indicate the arrival of a New Message in the Mailbox of the Served User. The information flow request has different elements depending whether complete information or compressed information is provided. NOTE This information flow includes the same elements as the information flow ra_MWI_Activate in SS-MWI. Table 3 lists the elements within the MCM_NewMessage information flow.

- 21 -

Ta b le 3 – C o n t e n t o f M C M _ N e wM e s s a g e Element

Request

Confirm

NOTE compressed information

Complete information

Served User identity

Message Type

Number of Messages

Priority

Message Centre identity

Originating number

Timestamp

Result

NOTE 1 This is the Served User's Party Number (e.g. PISN number). NOTE 2 This indicates the specific Message Type of the New Message (e.g. speech, email, fax). NOTE 3 This indicates the total number of New Messages of a particular Message Type which are stored in the Mailbox of the Served User. NOTE 4a This indicates the priority value for the highest priority among all New Messages stored in the Mailbox of a particular Message Type. NOTE 4b This indicates the priority value of a specific message which was left at the Message Centre. NOTE 5 This element identifies the Message Centre (e.g. PISN number). NOTE 6a This indicates the Party Number of the Originator that left the New Message with the highest priority value. NOTE 6b This indicates the Party Number of the Originator that left the New Message. NOTE 7a This is the time stamp for the incoming of the highest priority New Message of a particular Message Type within the Mailbox. NOTE 7b This indicates the time when a message was left. NOTE 8 This indicates acceptance or the reason for rejection. 8.2.1.4

M C M _ N o N e wM e s s a g e MCM_NoNewMessage is a confirmed information flow across ra from FE1 to FE2 and across rb from FE2 to FE3 used to indicate that there is no more New Message of a specific Message Type in the Mailbox of the Served User.

- 22 -

NOTE This information flow includes the same elements as the information flow ra_MWI_Deactivate in SS-MWI. Table 4 lists the elements within the MCM_NoNewMessage information flow. Ta b le 4 – C o n t e n t o f M C M _ N o N e wM e s s a g e Request

Element

Confirm

NOTE

Served User identity

Message Type

Message Centre identity

Result

NOTE 1 This is the Served User's Party Number (e.g. PISN number). NOTE 2 This is the specific Message Type of the New Message (e.g. speech, email, fax). NOTE 3 This element identifies the Message Centre (e.g. PISN number). NOTE 4 This indicates acceptance or reason for rejection. 8.2.1.5

MCM_UpdateInfo MCM_UpdateInfo is a confirmed information flow across ra from FE1 to FE2 and across rb from FE2 to FE3 used to update the information about New Messages and/or Retrieved Messages. Table 5 lists the elements within the MCM_UpdateInfo information flow. Table 5 – Content of MCM_UpdateInfo Element

Request

Confirm

NOTE

compressed information

Complete information

Served User identity

Message Centre identity

Message Type

List of Originator addresses of all New and/or Retrieved Messages of that Message Type

Number of all New and/or Retrieved Messages of that Message Type

Priority

Timestamp

Result

- 23 -

NOTE 1 This is the Served User's Party Number (e.g. PISN number). NOTE 2 This element identifies the Message Centre (e.g. PISN number). NOTE 3 This indicates a particular Message Type (e.g. speech, email, fax). NOTE 4 This indicates the Party Number of the Originator that left a message. Not applicable in the case that the Originator address is an email address. The information element is mandatory for complete information but shall not be used in the compressed information scenario. NOTE 5 This indicates the total number of New Messages of a specific Message Type, which are stored in the Mailbox of the Served User. NOTE 6 This indicates a list of the priority of all New and/or Retrieved Messages which were left at the Message Centre. When the compressed information style is used, this is the value for the highest priority among all New and/or Retrieved Messages stored in the Mailbox of that particular Message Type. NOTE 7 This indicates a list of the time stamp when the New and/or Retrieved Messages were left. When the compressed information style is used, this is the timestamp for incoming New and/or Retrieved Message with the highest priority of that particular Message Type within the Mailbox. NOTE 8 This indicates acceptance or the reason for rejection. 8.2.1.6

MCM_UpdateReq MCM_UpdateReq is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FE1 used by the Served User to request updated information about New Messages and/or Retrieved Messages. NOTE This information flow includes the same elements as the information flow ra_MWI_Interrogate in SS-MWI. Table 6 lists the elements within the MCM_UpdateReq information flow.

- 24 -

Table 6 – Content of MCM_UpdateReq Element

Request

Confirm compressed information

NOTE

complete information

Served User identity

Message Type

Number of messages

Priority

Message Centre identity

Originating Number

Timestamp

Result

NOTE 1 This is the Served User's Party Number (e.g. PISN number). NOTE 2 This indicates the specific Message Type of the New Message (e.g. speech, email, fax). NOTE 3 This indicates the total number of New Messages of a particular Message Type which are stored in the Mailbox of the Served User. NOTE 4 This indicates the priority value for the highest priority among all New Messages stored in the Mailbox of a particular Message Type. NOTE 5 This element identifies the Message Centre (e.g. PISN number). NOTE 6 This indicates the Party Number of the Originator that left the New Message with the highest priority value. NOTE 7 This is the time stamp for the incoming of the highest priority New Message of a particular Message Type within the Mailbox. NOTE 8 This indicates acceptance or the reason for rejection. 8.2.1.7

M C M _ M a ilb o x _ f u ll MCM_Mailbox_full is an unconfirmed information flow across ra from FE1 to FE2 and across rb from FE3 to FE2 used by the Message Centre to give an indication to the Served User that his/her Mailbox has reached the maximum storage capacity for messages of a specific Message Type. Table 7 lists the elements within the MCM_Mailbox_full information flow.

- 25 -

Ta b le 7 – C o n t e n t o f M C M _ M a ilb o x _ f u ll Element

Request

NOTE

Served User identity

Message Centre identity

Message Type

NOTE 1 This is the Served User's number (e.g. PISN number). NOTE 2 This element identifies the Message Centre (e.g. PISN number). NOTE 3 This indicates a particular Message Type (e.g. speech, email, fax). 8.2.2

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-MCM 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. The following abbreviations are used:

8.2.2.1

req

request;

ind

indication;

resp

response;

conf

confirm.

S e r v ic e C h a n g e p r o c e d u r e s o f S S - M C M Figure 5 shows in generic form the information flow sequence for activation and/or deactivation of SS-MCM.

FE1

FE2 ra_MCM_ServiceChange req/ind

201

FE3 rb_MCM_ServiceChange req/ind

301

101 ra_MCM_ServiceChange con/res

202

rb_MCM_ServiceChange con/res

302

F ig u r e 5 – I n f o r m a t io n f lo w s e q u e n c e f o r a c t iv a t io n a n d d e a c t iv a t io n o f S S - M C M

- 26 -

8.2.2.2

I n t e r r o g a t io n p r o c e d u r e o f S S - M C M Figure 6 shows in generic form the information flow sequence for interrogation of SS-MCM.

FE1

FE2 ra_MCM_Interrogate req/ind

203

FE3 rb_MCM_Interrogate req/ind

303

102 ra_MCM_Interrogate con/res

204

rb_MCM_Interrogate con/res

304

F ig u r e 6 – I n f o r m a t io n f lo w s e q u e n c e f o r in t e r r o g a t io n o f S S - M C M 8.2.2.3

Tr a n s m is s io n o f a N e wM e s s a g e I n d ic a t io n Figure 7 shows in generic form the information flow sequence for transmission of a NewMessage indication within SS-MCM.

FE1

103

FE2 ra_MCM_NewMessage req/ind

205

FE3 rb_MCM_NewMessage req/ind 305

104

ra_MCM_NewMessage con/res

206

rb_MCM_NewMessage con/res

F ig u r e 7 – I n f o r m a t io n f lo w s e q u e n c e f o r t r a n s m is s io n o f a N e wM e s s a g e in d ic a t io n 8.2.2.4

Tr a n s m is s io n o f a N o N e wM e s s a g e I n d ic a t io n Figure 8 shows in generic form the information flow sequence for transmission of a NoNewMessage indication within SS-MCM.

- 27 -

FE1

105

FE2 ra_MCM_NoNewMessage req/ind

207

FE3 rb_MCM_NoNewMessage req/ind 306

106

ra_MCM_NoNewMessage con/res

208

rb_MCM_NoNewMessage con/res

F ig u r e 8 – I n f o r m a t io n f lo w s e q u e n c e f o r t r a n s m is s io n o f a N o N e wM e s s a g e in d ic a t io n 8.2.2.5

Tr a n s m is s io n o f U p d a t e I n f o r m a t io n Figure 9 shows in generic form the information flow sequence for transmission of Update Information.

FE1

107

FE2 ra_MCM_UpdateInfo req/ind

209

FE3 rb_MCM_UpdateInfo req/ind 307

108

ra_MCM_UpdateInfo con/res

210

rb_MCM_UpdateInfo con/res

Figure 9 – Information flow sequence for transmission of update information 8.2.2.6

Tr a n s m is s io n o f a n U p d a t e R e q u e s t Figure 10 shows in generic form the information flow sequence for transmission of an Update Request.

- 28 -

FE1

FE2 ra_MCM_UpdateReq req/ind

109

ra_MCM_UpdateReq con/res

107

ra_MCM_UpdateInfo req/ind

211

212

209

FE3 rb_MCM_UpdateReq req/ind rb_MCM_UpdateReq con/res

308

309

rb_MCM_UpdateInfo req/ind 307

108

ra_MCM_UpdateInfo con/res

210

rb_MCM_UpdateInfo con/res

F i g u r e 1 0 – I n f o r m a t i o n f l o w s e q u e n c e f or t r a n s m i s s i o n o f a n u p d a t e r e q u e s t 8.2.2.7

Tr a n s m is s io n o f a M a ilb o x - f u ll in d ic a t io n Figure 11 shows in generic form the information flow sequence for transmission of a Mailbox-full indication.

FE1

110

FE2 ra_MCM_Mailbox_full req/ind

213

FE3 rb_MCM_Mailbox_full

310

req/ind

F ig u r e 1 1 – I n f o r m a t io n f lo w s e q u e n c e f o r t r a n s m is s io n o f a M a ilb o x - f u ll in d ic a t io n

8.3 8.3.1

Functional Entity actions F u n c t io n a l En t it y a c t io n s o f F E1 101 receives ra_MCM_ServiceChange req/ind from FE2 indicating the Message Type(s) which shall be activated or deactivated and sends ra_MCM_ServiceChange con/res after processing the request; 102

receives ra_MCM_Interrogate req/ind from FE2 with an interrogation request and sends ra_MCM_Interrogate con/res including the information requested by the interrogation;

103

sends ra_MCM_NewMessage req/ind to FE2 in order to indicate the arrival of a New Message;

104

receives ra_MCM_NewMessage con/res from FE2;

- 29 -

8.3.2

8.3.3

105

sends ra_MCM_NoNewMessage req/ind to FE2 in order to indicate that no more New Messages of a specific Message Type are in the Served User's mailbox;

106

receives ra_MCM_NoNewMessage con/res from FE2;

107

sends ra_MCM_UpdateInfo req/ind to FE2 with updated Mailbox information due to changes in the Served user's Mailbox or due to an update request from the Served User;

108

receives ra_MCM_UpdateInfo con/res from FE2;

109

receives ra_MCM_UpdateReq req/ind from FE2 conveying the Served User request for updated information and sends ra_MCM_UpdateReq con/res with updated information about New Messages to FE2;

110

sends ra_MCM_Mailbox_full req/ind to FE2 in order to indicate that the Mailbox reached its storage capacity.

F u n c t io n a l En t it y a c t io n s o f F E2 201 receives rb_MCM_ServiceChange req/ind from FE3 and sends ra_MCM_ServiceChange req/ind to FE1 in order to activate or deactivate specific Message Type(s); 202

receives ra_MCM_ServiceChange con/res from FE1 and sends rb_MCM_ServiceChange con/res to FE3;

203

receives rb_MCM_Interrogate req/ind from FE3 and sends ra_MCM_Interrogate req/ind with the interrogation request to FE1;

204

receives ra_MCM_Interrogate con/res from FE1 and sends rb_MCM_Interrogate con/res with the information requested by the interrogation to FE3;

205

receives ra_MCM_NewMessage req/ind from FE1 and sends rb_MCM_NewMessage req/ind to FE3 indicating the arrival of a New Message in the Mailbox;

206

receives rb_MCM_NewMessage con/res from FE3 and sends ra_MCM_NewMessage con/res to FE1;

207

receives ra_MCM_NoNewMessage req/ind from FE1 and sends rb_MCM_NoNewMessage req/ind to FE3 indicating that are no more New Messages of a specific Message Type in the Mailbox;

208

receives rb_MCM_NoNewMessage con/res from FE3 and sends ra_MCM_NoNewMessage con/res to FE1;

209

receives ra_MCM_UpdateInfo req/ind from FE1 and sends rb_MCM_UpdateInfo req/ind to FE3 with updated Mailbox information due to changes in the Served User's Mailbox or due to an update request from the Served User;

210

receives rb_MCM_UpdateInfo con/res from FE3 and sends ra_MCM_UpdateInfo con/res to FE1;

211

receives rb_MCM_UpdateReq req/ind from FE3 and sends ra_MCM_UpdateReq req/ind to FE1;

212

receives ra_MCM_UpdateReq con/res from FE1 and sends rb_MCM_UpdateReq con/res to FE3;

213

receives ra_MCM_Mailbox_full req/ind from FE1 and sends rb_MCM_Mailbox_full req/ind to FE3 indicating that the Mailbox reached its storage capacity.

F u n c t io n a l En t it y a c t io n s o f F E3 301 sends rb_MCM_ServiceChange req/ind to FE2 in order to activate or deactivate specific Message Type(s); 302

receives rb_MCM_ServiceChange con/res from FE2;

303

sends rb_MCM_Interrogate req/ind with an interrogation request to FE2;

- 30 -

8.4

304

receives rb_MCM_Interrogate con/res from FE2 with the information requested by the interrogation;

305

receives rb_MCM_NewMessage req/ind from FE2 indicating the arrival of a New Message in the Mailbox and sends rb_MCM_NewMessage con/res to FE2;

306

receives rb_MCM_NoNewMessage req/ind from FE2 indicating that there are no more New Message of a specific Message Type in the Mailbox and sends rb_MCM_NoNewMessage con/res to FE2;

307

receives rb_MCM_UpdateInfo req/ind from FE2 with updated Mailbox information due to changes in the Served User's Mailbox or due to an update request from the Served User and sends rb_MCM_UpdateInfo con/res to FE2;

308

sends rb_MCM_UpdateReq req/ind to FE2 conveying Served User's request for updated mailbox information;

309

receives rb_MCM_UpdateReq con/res from FE2 conveying updated mailbox information about New Messages;

310

receives rb_MCM_Mailbox_full req/ind from FE2 indicating that the Mailbox reached its storage capacity.

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 IUT-T Rec. Z.100 (1999).

8.4.1

Be h a v io u r o f F E1 Figure 12 shows the normal behaviour of FE1. Output signals to the right and input signals from the right represent information flows to and from FE2. Input signals from the left represent indications from the Message Centre.

- 31 -

MCM idle

ra_MCM_ServiceChange req/ind

YES

activation or deactivation request allowed ?

101 from FE2

activate/deactivate monitoring of indicated Message Types

101 to FE2

ra_MCM_ServiceChange con/res (accepted)

101 to FE2

ra_MCM_ServiceChange con/res (rejected)

MCM idle

F ig u r e 1 2 a – S D L f o r M C M S e r v ic e C h a n g e P r o c e d u r e s f o r F E1 , M e s s a g e C e n t r e 's c o n t r o l e n t it y

- 32 -

MCM idle

ra_MCM_Interrogation req/ind

YES

102 to FE2

interrogation request allowed ?

ra_MCM_Interrogation con/res (accepted)

102 from FE2

102 to FE2

ra_MCM_Interrogation con/res (rejected)

MCM idle

F ig u r e 1 2 b – S D L f o r M C M I n t e r r o g a t io n R e q u e s t f o r F E1 , M e s s a g e C e n t r e 's c o n t r o l e n t it y

- 33 -

MCM idle

Internal indication for the income of a New Message

103 to FE2

ra_MCM_NewMessage req/ind

MCM_wait

ra_MCM_NewMessage con/res (accepted)

104 from FE2

ra_MCM_NewMessage con/res (rejected)

104 from FE2

MCM idle

F ig u r e 1 2 c – S D L f o r M C M N e wM e s s a g e I n d ic a t io n f o r F E 1 , M e s s a g e C e n t r e ' s c o n t r o l e n t i t y

- 34 -

MCM idle

Internal indication that no New Messages for specific Message Types are in the mailbox

105 to FE2

ra_MCM_NoNewMessage req/ind

MCM_wait

ra_MCM_NoNewMessage con/res (accepted)

106 from FE2

ra_MCM_NoNewMessage con/res (rejected)

106 from FE2

MCM idle

F ig u r e 1 2 d – S D L f o r M C M N o N e wM e s s a g e I n d ic a t i o n f o r F E 1 , M e s s a g e C e n t r e ' s c o n t r o l e n t i t y

- 35 -

MCM idle

Internal indication to send updated information

107 to FE2

ra_MCM_UpdateInfo req/ind

MCM_wait

ra_MCM_UpdateInfo con/res (accepted)

further updated information available ?

ra_MCM_UpdateInfo con/res (rejected)

108 from FE2

YES

108 from FE2

MCM idle

Figure 12e – SDL for MCM Update Information for FE1, Message Centre's control entity

- 36 -

MCM idle

ra_MCM_UpdateReq req/ind

YES

109 to FE2

ra_MCM_UpdateReq con/res (accepted)

109 from FE2

Update Request allowed ?

109 to FE2

ra_MCM_UpdateReq con/res (rejected)

MCM idle

Figure 12f – SDL for MCM Update Request for FE1, Message Centre's control entity

MCM idle

Internal indication for a full Mailbox

110 to FE2

ra_MCM_Mailbox_full req/ind

MCM idle

F ig u r e 1 2 g – S D L f o r M C M M a ilb o x - f u ll I n d ic a t io n f o r F E1 , M e s s a g e C e n t r e 's c o n t r o l e n t it y

- 37 -

8.4.2

Be h a v io u r o f F E2 Figure 13 shows the normal behaviour of FE2. Output signals to the left and input signals from the left represent primitives to and from the FE1. Output signals to the right and input signals from the right represent information flows from and to FE3.

MCM idle

rb_MCM_ServiceChange req/ind

201 from FE3

Served User request allowed ?

YES

ra_MCM_ServiceChange req/ind

201 to FE1

MCM wait

202 from FE1

202 to FE3

ra_MCM_ServiceChange con/res (accepted)

rb_MCM_ServiceChange con/res (accepted)

202 from FE1

202 to FE3

ra_MCM_ServiceChange con/res (rejected)

rb_MCM_ServiceChange con/res (rejected)

MCM idle

F ig u r e 1 3 a – S D L f o r M C M S e r v ic e C h a n g e P r o c e d u r e s f o r F E2 , S e r v e d U s e r 's c o n t r o l e n t it y

- 38 -

MCM idle

rb_MCM_Interrogate req/ind

Served User request allowed ?

203 from FE3

YES

ra_MCM_Interrogate req/ind

203 to FE1

MCM wait

204 from FE1

204 to FE3

ra_MCM_Interrogate con/res (accepted)

rb_MCM_Interrogate con/res (accepted)

204 from FE1

204 to FE3

ra_MCM_Interrogate con/res (rejected)

rb_MCM_Interrogate con/res (rejected)

MCM idle

F ig u r e 1 3 b – S D L f o r M C M I n t e r r o g a t io n R e q u e s t f o r F E2 , S e r v e d U s e r 's c o n t r o l e n t it y

- 39 -

MCM idle

205 from FE1

205 to FE3

ra_MCM_NewMessage req/ind

rb_MCM_NewMessage req/ind

MCM wait

rb_MCM_NewMessage con/res (accepted)

ra_MCM_NewMessage con/res (accepted)

206 from FE3

206 to FE1

rb_MCM_NewMessage con/res (rejected)

ra_MCM_NewMessage con/res (rejected)

206 from FE3

206 to FE1

MCM idle

F ig u r e 1 3 c – S D L f o r M C M N e wM e s s a g e I n d ic a t io n f o r F E 2 , S e r v e d U s e r ' s c o n t r o l e n t i t y

- 40 -

MCM idle

207 from FE1

207 to FE3

ra_MCM_NoNewMessage req/ind

rb_MCM_NoNewMessage req/ind

MCM wait

rb_MCM_NoNewMessage con/res (accepted)

ra_MCM_NoNewMessage con/res (accepted)

208 from FE3

208 to FE1

rb_MCM_NoNewMessage con/res (rejected)

ra_MCM_NoNewMessage con/res (rejected)

208 from FE3

208 to FE1

MCM idle

F ig u r e 1 3 d – S D L f o r M C M N o N e wM e s s a g e I n d ic a t i o n f o r F E 2 , S e r v e d U s e r ' s c o n t r o l e n t i t y

- 41 -

MCM update wait

MCM idle

209 from FE1

209 to FE3

ra_MCM_UpdateInfo req/ind

209 from FE1

ra_MCM_UpdateInfo req/ind

rb_MCM_UpdateInfo con/res (rejected)

210 from FE3

rb_MCM_UpdateInfo req/ind

MCM wait

rb_MCM_UpdateInfo con/res (accepted)

ra_MCM_UpdateInfo con/res (accepted)

210 from FE3

210 to FE1

ra_MCM_UpdateInfo con/res (rejected)

210 to FE1

MCM idle

Figure 13e – SDL for MCM Update Information for FE2, Served User's control entity

- 42 -

MCM idle

rb_MCM_UpdateReq req/ind

ra_MCM_UpdateReq req/ind

211 from FE3

211 to FE1

MCM wait

212 from FE1

212 to FE3

ra_MCM_UpdateReq con/res (accepted)

rb_MCM_UpdateReq con/res (accepted)

MCM update wait

212 from FE1

212 to FE3

ra_MCM_UpdateReq con/res (rejected)

rb_MCM_UpdateReq con/res (rejected)

MCM idle

Figure 13f – SDL for MCM Update Request for FE2, Served User's control entity

- 43 -

MCM idle

213 from FE1

213 to FE3

ra_MCM_Mailbox_full req/ind

rb_MCM_Mailbox_full req/ind

MCM idle

F ig u r e 1 3 g – S D L f o r M C M M a ilb o x - f u ll I n d ic a t io n f o r F E2 , S e r v e d U s e r 's c o n t r o l e n t it y

- 44 -

8.4.3

Be h a v io u r o f F E3 Figure 14 shows the normal behaviour of FE3. Output signals to the left and input signals from the left represent information flows to and from the FE2. Input signals from the right represent Served User actions.

MCM idle

user indication for MCM Service Change

rb_MCM_ServiceChange req/ind

301 to FE2

MCM wait

302 from FE2

rb_MCM_ServiceChange con/res (accepted)

302 from FE2

rb_MCM_ServiceChange con/res (rejected)

MCM idle

F ig u r e 1 4 a – S D L f o r M C M S e r v ic e C h a n g e P r o c e d u r e s f o r F E3 , S e r v e d U s e r A g e n t

- 45 -

MCM idle

user indication for MCM Intrerrogate

rb_MCM_Interrogate req/ind

303 to FE2

MCM wait

304 from FE2

rb_MCM_Interrogate con/res (accepted)

304 from FE2

rb_MCM_Interrogate con/res (rejected)

MCM idle

F ig u r e 1 4 b – S D L f o r M C M I n t e r r o g a t io n R e q u e s t f o r F E3 , S e r v e d U s e r A g e n t

- 46 -

MCM idle

305 from FE2

rb_MCM_NewMessage req/ind

YES

rb_MCM_NewMessage con/res (accepted)

Information accepted?

rb_MCM_NewMessage con/res (rejected)

305 to FE2

MCM idle

F ig u r e 1 4 c – S D L f o r M C M N e wM e s s a g e I n d i c a t i o n f o r F E 3 , S e r v e d U s e r A g e n t

- 47 -

MCM idle

306 from FE2

rb_MCM_NoNewMessage req/ind

YES

rb_MCM_NoNewMessage con/res (accepted)

Information accepted?

rb_MCM_NoNewMessage con/res (rejected)

306 to FE2

MCM idle

F ig u r e 1 4 d – S D L f o r M C M N o N e wM e s s a g e I n d i c a t i o n f o r F E 3 , S e r v e d U s e r A g e n t

- 48 MCM update wait

MCM idle

307 from FE2

rb_MCM_UpdateInfo req/ind

YES

rb_MCM_UpdateInfo con/res (accepted)

Updated Information accepted?

307 from FE2

rb_MCM_UpdateInfo con/res (rejected)

307 to FE2

rb_MCM_UpdateInfo req/ind

307 to FE2

MCM idle

Figure 14e – SDL for MCM Update Information for FE3, Served User Agent

- 49 -

MCM idle

user indication for MCM Update Request

rb_MCM_UpdateReq req/ind

308 to FE2

MCM wait

309 from FE2

rb_MCM_UpdateReq con/res (accepted)

309 from FE2

MCM update wait

rb_MCM_UpdateReq con/res (rejected)

MCM idle

Figure 14f – SDL for MCM Update Request for FE3, Served User Agent

MCM idle

310 from FE2

rb_MCM_Mailbox_full req/ind

MCM idle

F ig u r e 1 4 g – S D L f o r M C M M a ilb o x - f u ll I n d ic a t io n f o r F E3 , S e r v e d U s e r A g e n t

- 50 -

8.5

Allocation of Functional Entities to physical equipment The allocation of FEs to physical locations shall apply as shown in table 8. Table 8 – Scenarios for the allocation of FEs to physical equipment for SS-MCM

Scenario 1

FE1

FE2

FE3

Message Centre PINX

Served User PINX

Terminal

If FE3 is controlled by or resides in FE2 (e.g. stimulus terminal), the information flows between FE2 and FE3 are outside the scope of this Standard.

8.6

Interworking considerations The allocation of FEs to physical locations in the case of interworking with other networks that support a compatible service shall apply as shown in table 9. Table 9 – Scenarios for the allocation of FEs to physical equipment for SS-MCM in the case of interworking with other networks FE1

FE2

FE3

Scenario 2

Message Centre PINX

Other network

Scenario 3

Other network

Served User PINX

Terminal

- 51 -

SS-MID stage 2 specification

9.1

Functional model

9.1.1

Functional model description The functional model shall comprise the following Functional Entities (FEs): FE1

Message Centre's control entity;

FE2

Served User's control entity;

FE3

Served User Agent.

The following relationship shall exist between these FEs: ra

between FE1 and FE2;

between FE2 and FE3.

Figure 15 shows these FEs and this relationship.

FE1

FE2

FE3

F ig u r e 1 5 – F u n c t io n a l m o d e l f o r S S - M I D 9.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 9.1.2.1 M e s s a g e C e n t r e 's c o n t r o l e n t it y , F E1 This Functional Entity:

9.1.2.2

9.1.2.3

9.2 9.2.1

sends Mailbox identification data to FE2;

receives Mailbox authentication data from FE2.

Served User's control entity, FE2 This Functional Entity: -

receives Mailbox identification data from FE1 and sends the Mailbox identification data to FE3;

receives Mailbox authentication data from FE3 and sends the Mailbox authentication data to FE1.

Served User Agent, FE3 This Functional Entity: -

receives Mailbox identification data from FE2.

sends Mailbox authentication data to FE2.

Information flows 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 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. The information flows across rb represent information flows between two functional entities FE2 and FE3. If FE3 is controlled by or resides in FE2 (e.g. stimulus terminal), the information flows across rb are outside the scope of this Standard.

- 52 -

9.2.1.1

M I D _ M a ilb o x I D MID_MailboxID is a confirmed information flow across ra from FE1 to FE2 and across rb from FE2 to FE3 used by the MC to indicate a specific Mailbox of the Served User. Table 10 lists the elements within the MID_MailboxID information flow. Ta b le 1 0 – C o n t e n t o f M I D _ M a ilb o x I D Element

Request

Confirm

NOTE

Served User identity

Mailbox identity

Message Centre number

Served User name

Result

NOTE 1 This is the Served User's Party Number (e.g. PISN number). NOTE 2 This identifies a particular Served User Mailbox when the Served User has different Mailboxes for different Message Types. NOTE 3 This element identifies the Message Centre (e.g. PISN number). NOTE 4 This is the name of the Served User. NOTE 5 This indicates acceptance or the reason for rejection. 9.2.1.2

M I D _ M a ilb o x A u t h MID_MailboxAuth is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FE1 used by the Served User to authenticate himself/herself at the Mailbox. Table 11 lists the elements within the MID_MailboxAuth information flow. Ta b le 1 1 – C o n t e n t o f M I D _ M a ilb o x A u t h Element

Request

Confirm

NOTE

Served User identity

Mailbox identity

Message Centre number

Served User name

Authentication data

Result

NOTE 1 This is the Served User's Party Number (e.g. PISN number). NOTE 2 This identifies a particular Served User Mailbox when the Served User has different Mailboxes (e.g. for different Message Types).

- 53 -

NOTE 3 This element identifies the Message Centre (e.g. PISN number). NOTE 4 This is the name of the Served User. NOTE 5 This is the data used from the Served User to authenticate himself/herself at his/her Mailbox (e.g. password). NOTE 6 This indicates acceptance or the reason for rejection. 9.2.2

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-MID 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. The following abbreviations are used:

9.2.2.1

req

request;

ind

indication;

resp

response;

conf

confirm.

M a ilb o x id e n t if ic a t io n Figure 16 shows in generic form the information flow sequence for Mailbox identification.

FE1

101

FE2 ra_MID_MailboxID req/ind

201

FE3 rb_MID_MailboxID req/ind 301

102

ra_MID_MailboxID con/res

202

rb_MID_MailboxID con/res

F ig u r e 1 6 – I n f o r m a t io n f lo w s e q u e n c e f o r t r a n s m is s io n o f m a ilb o x id e n t if ic a t io n d a t a

- 54 -

9.2.2.2

M a ilb o x a u t h e n t ic a t io n Figure 17 shows in generic form the information flow sequence for Mailbox authentication.

FE1

FE2 ra_MID_MailboxAuth req/ind

203

FE3 rb_MID_MailboxAuth req/ind

302

103 ra_MID_MailboxAuth con/res

204

rb_MID_MailboxAuth con/res

303

F ig u r e 1 7 – I n f o r m a t io n f lo w s e q u e n c e f o r t r a n s m is s io n o f a u t h e n t ic a t io n d a t a

9.3 9.3.1

9.3.2

9.3.3

Functional Entity actions F u n c t io n a l En t it y a c t io n s o f F E1 101 sends ra_MID_MailboxID req/ind with mailbox identification data to FE2; 102

receives ra_MID_MailboxID con/res from FE2;

103

receives ra_MID_MailboxAuth req/ind with authentication data from FE2 and sends ra_MID_MailboxAuth con/res to FE2.

F u n c t io n a l En t it y a c t io n s o f F E2 201 receives ra_MID_MailboxID req/ind from FE1 and sends rb_MID_MailboxID req/ind to FE3; 202

sends ra_MID_MailboxID con/res to FE1;

203

receives rb_MID_MailboxAuth req/ind from FE3 and sends ra_MID_MailboxAuth req/ind to FE1;

204

receives ra_MID_MailboxAuth con/res from FE1 and sends rb_MID_MailboxAuth con/res to FE3.

F u n c t io n a l En t it y a c t io n s o f F E3 301 receives rb_MID_MailboxID req/ind with mailbox identification data from FE2; 302

sends rb_MID_MailboxAuth req/ind with Served User's authentication data to FE2;

303

receives rb_MID_MailboxAuth con/res from FE2.

- 55 -

9.4

9.4.1

Be h a v io u r o f F E1 Figure 18 shows the normal behaviour of FE1. Output signals to the right and input signals from the right represent information flows from and to FE2. Input signals from the left represent indications from the Message Centre.

MID idle

Indication from the Message Centre

101 to FE2

ra_MID_MailboxID req/ind

MID wait

ra_MID_MailboxID con/res (accepted)

ra_MID_MailboxID con/res (rejected)

102 from FE2

MID idle

F ig u r e 1 8 a – S D L f o r t r a n s m is s io n o f id e n t if ic a t io n d a t a f o r F u n c t io n a l En t it y F E1 , Message Centre's control entity

- 56 -

MID idle

ra_MID_MailboxAuth req/ind

YES

103 to FE2

ra_MID_MailboxAuth con/res (accepted)

authentification data valid ?

103 to FE2

103 from FE2

ra_MID_MailboxAuth con/res (rejected)

MID idle

Figure 18b – SDL for receiving authentication data for Functional Entity FE1, Message Centre's control entity

- 57 -

9.4.2

Be h a v io u r o f F E2 Figure 19 shows the normal behaviour of FE2. Output signals to the left and input signals from the left represent primitives to and from the FE1. Output signals to the right and input signals from the right represent information flows to and from FE3.

MID idle

201 from FE1

201 to FE3

ra_MID_MailboxID req/ind

rb_MID_MailboxID req/ind

MID wait

rb_MID_MailboxID con/res (accepted)

ra_MID_MailboxID con/res (accepted)

rb_MID_MailboxID con/res (rejected)

202 from FE3

ra_MID_MailboxID con/res (rejected)

202 to FE1

202 from FE3

202 to FE1

MID idle

F ig u r e 1 9 a – S D L f o r t r a n s m is s io n o f id e n t if ic a t io n d a t a f o r F u n c t io n a l En t it y F E2 , Served User's control entity

- 58 -

MID idle

rb_MID_MailboxAuth req/ind

203 from FE3

ra_MID_MailboxAuth req/ind

203 to FE1

MID wait

204 from FE1

204 to FE3

ra_MID_MailboxAuth con/res (accepted)

204 from FE1

rb_MID_MailboxAuth con/res (accepted)

204 to FE3

ra_MID_MailboxAuth con/res (rejected)

rb_MID_MailboxAuth con/res (rejected)

MID idle

F ig u r e 1 9 b – S D L f o r t r a n s m is s io n o f a u t h e n t ic a t io n d a t a f o r F u n c t io n a l En t it y F E2 , Served User's control entity

- 59 -

9.4.3

Be h a v io u r o f F E3 Figure 20 shows the normal behaviour of FE3. Output signals to the right and input signals from the right represent information flows to and from FE2. Input signals from the left represent Served User actions.

MID idle

301 from FE2

rb_MID_MailboxID req/ind

YES

rb_MID_MailboxID con/res (accepted)

Mailbox identification data valid ?

301 to FE2

rb_MID_MailboxID con/res (rejected)

301 to FE2

MID idle

Figure 20a – SDL for receiving identification data for Functional Entity FE3, Served User Agent

- 60 -

MID idle

MID Authentication request

rb_MID_MailboxAuth req/ind

302 to FE2

MID wait

rb_MID_MailboxAuth con/res (accepted)

303 from FE2

rb_MID_MailboxAuth con/res (rejected)

MID idle

F ig u r e 2 0 b – S D L f o r t r a n s m is s io n o f a u t h e n t ic a t io n d a t a f o r F u n c t io n a l En t it y F E3 , Served User Agent

9.5

Allocation of Functional Entities to physical equipment The allocation of FEs to physical locations shall apply as shown in table 12. Table 12 – Scenarios for the allocation of FEs to physical equipment for SS-MID

Scenario 1

FE1

FE2

FE3

Message Centre PINX

Served User PINX

Terminal

If FE3 is controlled by or resides in FE2 (e.g. stimulus terminal), the information flows between FE2 and FE3 are outside the scope of this Standard.

9.6

Interworking considerations The allocation of FEs to physical locations in the case of interworking with other networks that support a compatible service shall apply as shown in table 13.

- 61 -

Ta b le 1 3 – S c e n a r io s f o r t h e a llo 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 f o r S S - M I D in the case of interworking with other networks FE1

FE2

FE3

Scenario 2

Message Centre PINX

Other network

Scenario 3

Other network

Served User PINX

Terminal

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

+41 22 849.60.01 [email protected]

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

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

ECMA-346 — Private Integrated Services Network (PISN) – Specification, functional model and information flows – Message Centre Monitoring and Mailbox Identification supplementary services (MCM-SD / MID-SD) (June 2003)

Related documents