Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-347 — Private Integrated Services Network (PISN) – Inter-exchange signalling protocol – Message Centre Monitoring and Mailbox Identification supplementary services (QSIG-MCM / QSIG-MID) (June 2003)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

centre ecma ecmainternational exchange identification integrated inter message

ecma, standard, ecma international, specification, ecma-347, ecma 347, 347, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, message, centre, monitoring, and, mailbox, identification, supplementary, qsig-mcm, qsig-mid

Standard ECMA-347 June 2003

International

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) – Inter-Exchange Signalling Protocol – Message Centre Monitoring and Mailbox Identification Supplementary Services

Phone/Fax: +41 22 849.60.00/01

http://www.ecma-international.org

mailto: h e l p d e s k @ e c m a . c h

Standard ECMA-347 June 2003

International

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) – Inter-Exchange Signalling Protocol – Message Centre Monitoring and Mailbox Identification Supplementary Services (QSIG-MCM / QSIG-MID)

Phone/Fax: +41 22 849.60.00/01 IW

Ecma-347.doc

10-07-03 14,52

http://www.ecma-international.org

mailto: h e l p d e s k @ e c m a . c h

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-00230. This particular Standard specifies the signalling protocol for use at the Q reference point in support of the Message Centre Monitoring supplementary service as well as the Mailbox Identification supplementary service. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). 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 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.

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)

5 6

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 Me s s a g e Ce n tr e P I N X 4.2.2 Served User PINX List of acronyms Signalling protocol for the support of SS-MCM 6 . 1 S S - MCM d e s c r ip tio n 6 . 2 S S - MCM o p e r a tio n a l r e q u ir e me n ts 6.2.1 Re q u ir e me n ts o n a Me s s a g e Ce n tr e P I N X 6.2.2 Re q u ir e me n ts o n a S e r v e d U s e r P I N X 6.2.3 Re q u ir e me n ts o n a T r a n s it P I N X 6 . 3 S S - MCM c o d in g r e q u ir e me n ts 6.3.1 Operations 6.3.2 I n f o r ma t i o n e l e me n t s 6.3.3 Messages 6 . 4 S S - MCM s ta te d e f in itio n s 6.4.1 States at the Message Centre PINX 6.4.2 States at the Served User PINX 6 . 5 S S - MCM s ig n a llin g p r o c e d u r e s 6.5.1 A c tio n s a t th e Me s s a g e Ce n tr e P I N X 6.5.2 Actions at the Served User PINX 6.5.3 Actions at a Transit PINX 6 . 6 S S - MCM imp a c t o f in te r w o r k in g w ith p u b lic I S D N s 6 . 7 S S - MCM imp a c t o f in te r w o r k in g w ith n o n - I S D N s 6 . 8 P r o to c o l in te r a c tio n s b e tw e e n S S - MCM a n d o th e r s u p p le me n ta r y s e r v ic e s a n d A N F s 6.8.1 Calling Line Identification Presentation (SS-CLIP) 6.8.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.8.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.8.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.8.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.8.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.8.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.8.8 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.8.9 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R)

2 2 3 3 3 3 3 3 3 3 4 4 4 4 11 11 11 11 12 12 12 16 18 18 18 18 19 19 19 19 19 19 19 19 19

- ii -

6.8.10 P a t h R e p l a c e me n t ( A N F - P R ) 6.8.11 Call Transfer (SS-CT) 6.8.12 Call Deflection (SS-CD) 6.8.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.8.14 Co mp le tio n o f Ca lls o n N o Re p ly ( S S - CCN R) 6.8.15 Call Offer (SS-CO) 6.8.16 Do Not Disturb (SS-DND) 6.8.17 Do Not Disturb Override (SS-DNDO) 6.8.18 Ca ll I n tr u s io n ( S S - CI ) 6.8.19 A d v ic e o f Ch a r g e ( S S - A O C) 6.8.20 Recall (SS-RE) 6.8.21 Call Interception (SS-CINT) 6.8.22 T r a n s it Co u n te r ( A N F - T C) 6.8.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.8.24 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6.8.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) 6.8.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.8.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.8.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.8.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.8.30 Co mmo n I n f o r ma tio n ( S S - CMN ) 6.8.31 Call Priority Interruption (Protection) (SS-CPI(P)) 6.8.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.8.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.8.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.8.35 Single Step Call Transfer (SS-SSCT) 6.8.36 S i mp l e D i a l o g ( S S - S D ) 6.8.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 ) 6.8.38 Short Message Service (SS-SMS) 6.8.39 Make Call Request (SS-MCR) 6.8.40 Ma ilb o x I d e n tif ic a tio n ( S S - MI D ) 6 . 9 S S - M C M p a r a me t e r v a l u e s ( t i me r s ) 6.9.1 T i me r T 1 6.9.2 T i me r T 2 6.9.3 T i me r T 3

19 19 19 19 19 19 19 19 19 19 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 21 21 21 21 21 21 21

Signalling protocol for the support of SS-MID 7 . 1 S S - MI D d e s c r ip tio n 7 . 2 S S - MI D o p e r a tio n a l r e q u ir e me n ts 7.2.1 Re q u ir e me n ts o n a Me s s a g e Ce n tr e P I N X 7.2.2 Re q u ir e me n ts o n a S e r v e d U s e r P I N X 7.2.3 Re q u ir e me n ts o n a T r a n s it P I N X 7 . 3 S S - MI D c o d in g r e q u ir e me n ts 7.3.1 Operations 7.3.2 I n f o r ma t i o n e l e me n t s 7.3.3 Messages

22 22 22 22 22 22 23 23 25 25

- iii -

7 . 4 S S - MI D s ta te d e f in itio n s 7.4.1 States at the Message Centre PINX 7.4.2 States at the Served User PINX 7 . 5 S S - MI D s ig n a llin g p r o c e d u r e s 7.5.1 A c tio n s a t th e Me s s a g e Ce n tr e P I N X 7.5.2 Actions at the Served User PINX 7.5.3 Actions at a Transit PINX 7 . 6 S S - MI D imp a c t o f in te r w o r k in g w ith p u b lic I S D N s 7 . 7 S S - MI D imp a c t o f in te r w o r k in g w ith n o n - I S D N s 7 . 8 P r o to c o l in te r a c tio n s b e tw e e n S S - MI D a n d o th e r s u p p le me n ta r y s e r v ic e s a n d A N F s 7.8.1 Calling Line Identification Presentation (SS-CLIP) 7.8.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 ) 7.8.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.8.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.8.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.8.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.8.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.8.8 C a l l F o r w a r d in g B u s y ( S S - C F B ) 7.8.9 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 7.8.10 P a t h R e p l a c e me n t ( A N F - P R ) 7.8.11 Call Transfer (SS-CT) 7.8.12 Call Deflection (SS-CD) 7.8.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.8.14 Co mp le tio n o f Ca lls o n N o Re p ly ( S S - CCN R) 7.8.15 Call Offer (SS-CO) 7.8.16 Do Not Disturb (SS-DND) 7.8.17 Do Not Disturb Override (SS-DNDO) 7.8.18 Ca ll I n tr u s io n ( S S - CI ) 7.8.19 A d v ic e o f Ch a r g e ( S S - A O C) 7.8.20 Recall (SS-RE) 7.8.21 Call Interception (SS-CINT) 7.8.22 T r a n s it Co u n te r ( A N F - T C) 7.8.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.8.24 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 7.8.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.8.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.8.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.8.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.8.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.8.30 Co mmo n I n f o r ma tio n ( S S - CMN ) 7.8.31 Call Priority Interruption (Protection) (SS-CPI(P)) 7.8.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.8.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.8.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.8.35 Single Step Call Transfer (SS-SSCT) 7.8.36 S i mp l e D i a l o g ( S S - S D )

25 25 25 25 25 26 27 27 27 27 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29

- iv -

7.8.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.8.38 Short Message Service (SS-SMS) 7.8.39 Make Call Request (SS-MCR) 7.8.40 Me s s a g e Ce n tr e Mo n ito r in g ( S S - MCM) 7 . 9 S S - M I D p a r a me t e r v a l u e s ( t i me r s ) 7.9.1 T i me r T 1 7.9.2 T i me r T 2

29 29 29 30 30 30 30

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

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

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

A n n e x D - Lis t o f M e s s a g e Ty p e s

Scope This Standard specifies the signalling protocol for the support of the Message Centre Monitoring supplementary service (SS-MCM) as well as the Mailbox Identification supplementary service (SS-MID) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). 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 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 Messages Centre. The Q reference point is defined in ECMA-133. Service specifications are produced in three stages and according to the method specified in ETS 300 387. This Standard contains the stage 3 specification for the Q reference point and satisfies the requirements identified by the stage 1 and stage 2 specifications in ECMA-346. The signalling protocol for SS-MCM and SS-MID uses certain aspects of the generic procedures for the control of supplementary services specified in ECMA-165. This Standard also specifies additional signalling protocol requirements for the support of interactions at the Q reference point between SS-MCM as well as SS-MID and other supplementary services and ANFs. NOTE Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications.

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

References (normative) The following standards contain provisions which, through reference in this text, constitute 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 64kbit/s Bearer Services – Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)

ECMA-143

Private Integrated Services Network (PISN) – Circuit Mode Bearer Services – InterExchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)

ECMA-165

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

- 2 -

ECMA-174

Private Integrated Services Network (PISN) – Inter-Exchange Signalling Protocol – Call Diversion Supplementary Services (International Standard ISO/IEC 13873)

ECMA-241

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

ECMA-242

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

ECMA-346

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

ETS 300 387

Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)

ISO 8601

Data elements and interchange formats - Information interchange – Representation of dates and times (2000)

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. Q.950 Digital Subscriber Signalling System No. 1 (DSS 1) – Supplementary services protocols, structure and general principles (2000) ITU-T Rec. Z.100 Specification and Description Language (1999)

Definitions For the purposes of this Standard, the following definitions apply:

4.1

External definitions This Standard uses the following terms defined in other documents: − Address Header

(ECMA-346)

− Application Protocol Data Unit (APDU)

(ECMA-165)

− Call-Independent

(ECMA-165)

− Complete Information

(ECMA-346)

− Compressed Information

(ECMA-346)

− Gateway PINX

(ECMA-165)

− Mailbox

(ECMA-346)

− Message Centre (MC)

(ECMA-346)

− Message Status

(ECMA-346)

− Message Type

(ECMA-346)

− Message Waiting Signal

(ECMA-346)

− New Message

(ECMA-346)

− Originating PINX

(ECMA-165)

− Private Integrated services Network eXchange (PINX)

(ECMA-133)

− Private Integrated Services Network (PISN)

(ECMA-133)

− Retrieved Message

(ECMA-346)

- 3 -

− Served User

(ECMA-346)

− Signalling

(ITU-T Rec. I.112)

− Supplementary Service

(ITU-T Rec. I.210)

− Supplementary Service Control Entity

(ECMA-165)

− Terminating PINX

(ECMA-165)

− Transit PINX

(ECMA-165)

4.2

Other definitions

4.2.1

Message Centre PINX The PINX where the Message Centre is located.

4.2.2

Served User PINX The PINX where the Served User is located.

List of acronyms

ANF

Additional Network Feature

APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation One

ISDN

Integrated Services Digital Network

MCM

Message Centre Monitoring

MID

Mailbox Identification

NFE

Network Facility Extension

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

Supplementary Service

Signalling protocol for the support of SS-MCM

6.1

SS-MCM 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 the Served User’s Mailbox. This can be due to the arrival of New Messages or due to 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.

6.2 6.2.1

SS-MCM operational requirements Requirements on a Message Centre PINX Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply.

- 4 -

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

Requirements on a Served User PINX Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for call-independent control (connection-oriented) of supplementary services, as specified in ECMA-165 for a Terminating PINX and for an Originating PINX, shall apply.

6.2.3

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

6.3 6.3.1

SS-MCM coding requirements O p e r a t io n s The operations defined in Abstract Syntax Notation One (ASN.1) in table 1 shall apply. NOTE The coding includes the operations as defined in SS-MWI (ECMA-242) but with the new operations names of SS-MCM. The following operations are identical in SS-MCM and SS-MWI: SS-MCM operations

SS-MWI operations

mCMNewMsg

ÅÆ

mWIActivate

mCMNoNewMsg

ÅÆ

mWIDeactivate

mCMUpdateReq

ÅÆ

mWIInterrogate

Table 1 – Operations in support of SS-MCM SS-MCM-Operations-asn1-97 {iso (1) identified-organization (3) icd-ecma (0012) standard (0) qsig-message-centre-monitoring (347) message-centre-monitoring-operations-asn1-97 (1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

- 5 -

Table 1 – Operations in support of SS-MCM (continued) Name FROM Name-Operations-asn1-97 {iso standard pss1-name (13868) name-operations-asn1-97 (1)} ; MCM-Operations

OPERATION ::= { mCMNewMsg | mCMNoNewMsg | mCMUpdate | mCMUpdateReq | mCMService | mCMInterrogate | mCMailboxFull }

mCMNewMsg

OPERATION ::= { ARGUMENT MCMNewMsgArg RESULT MCMDummyRes ERRORS {userNotSubscribed | invalidServedUserNr | basicServiceNotProvided | unspecified} CODE local: 80} -- same code as for mWIActivate in SS-MWI

mCMNoNewMsg

OPERATION ::= { ARGUMENT MCMNoNewMsgArg RESULT MCMDummyRes ERRORS {userNotSubscribed | invalidServedUserNr | basicServiceNotProvided | unspecified} CODE local: 81} -- same code as for mWIDeactivate in SS-MWI

mCMUpdate

OPERATION ::= { ARGUMENT MCMUpdateArg RESULT MCMDummyRes ERRORS {userNotSubscribed | invalidServedUserNr | unspecified} CODE local: 115}

mCMUpdateReq

OPERATION ::= { ARGUMENT MCMUpdateReqArg RESULT MCMUpdateReqRes ERRORS {userNotSubscribed | invalidServedUserNr | basicServiceNotProvided | unspecified} CODE local: 82} -- same code as for mWIInterrogate in SS-MWI

- 6 -

Table 1 – Operations in support of SS-MCM (continued) mCMService

OPERATION ARGUMENT RESULT ERRORS

CODE mCMInterrogate

OPERATION ARGUMENT RESULT ERRORS

CODE mCMailboxFull

MCMailboxFullArg

::= { MCMServiceArg MCMDummyRes {userNotSubscribed | invalidServedUserNr | basicServiceNotProvided | mCMModeNotProvided | unspecified} local: 116} ::= { MCMInterrogateArg MCMInterrogateRes {userNotSubscribed | invalidServedUserNr | basicServiceNotProvided | mCMModeNotProvided | unspecified} local: 117}

OPERATION ::= { ARGUMENT MCMailboxFullArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 118} ::= SEQUENCE { partyInfo mailboxFullFor extensions ... }

PartyInfo, MailboxFullFor, MCMExtensions

OPTIONAL,

MailboxFullFor

::= SEQUENCE OF MailboxFullPar

MailboxFullPar

::= SEQUENCE { messageType MessageType, capacityReached INTEGER (0..100) OPTIONAL -- percentage of storage capacity already used }

MCMServiceArg

::= SEQUENCE { partyInfo mCMChange extensions ... }

PartyInfo, MCMChange, MCMExtensions

OPTIONAL,

- 7 -

Table 1 – Operations in support of SS-MCM (continued) MCMChange

MCMServiceInfo

MCMInterrogateArg

MCMInterrogateRes

::= CHOICE { activateMCM deactivateMCM setToDefaultValues } ::= SEQUENCE { messageType mCMModeNew mCMModeRetrieved }

[1] IMPLICIT SEQUENCE OF MCMServiceInfo, [2] IMPLICIT SEQUENCE OF MessageType, NULL

MessageType, [1] IMPLICIT MCMMode [2] IMPLICIT MCMMode

OPTIONAL, OPTIONAL

::= SEQUENCE { partyInfo interrogateInfo extensions ... }

PartyInfo, SEQUENCE OF MessageType, MCMExtensions OPTIONAL,

::= SEQUENCE { interrogateResult extensions ... }

SEQUENCE OF MCMServiceInfo, MCMExtensions OPTIONAL,

MCMNewMsgArg

::= SEQUENCE { servedUserNr PartyNumber, specificMessageType MessageType, msgCentreId MsgCentreId OPTIONAL, nrOfMessages [3] IMPLICIT NrOfMessages OPTIONAL, originatingNr [4] PartyNumber OPTIONAL, timestamp TimeStamp OPTIONAL, priority [5] IMPLICIT INTEGER (0..9) OPTIONAL, argumentExt CHOICE { extension [6] IMPLICIT Extension{{MCMExtSet}}, multipleExtension [7] IMPLICIT SEQUENCE OF Extension{{MCMExtSet}} } OPTIONAL }

MCMNoNewMsgArg

::= SEQUENCE { servedUserNr PartyNumber, specificMessageType MessageType, msgCentreId MsgCentreId OPTIONAL, argumentExt CHOICE { extension [3] IMPLICIT Extension{{MCMExtSet}}, multipleExtension [4] IMPLICIT SEQUENCE OF Extension{{MCMExtSet}} } OPTIONAL }

- 8 -

Table 1 – Operations in support of SS-MCM (continued) MCMUpdateArg

::= SEQUENCE { partyInfo messageType updateInfo moreInfoFollows extensions ... }

MCMUpdateReqArg

::= SEQUENCE { servedUserNr specificMessageType msgCentreId argumentExt extension multipleExtension }

MCMUpdateReqRes

} OPTIONAL

::= SEQUENCE { specificMessageType msgCentreId nrOfMessages originatingNr timestamp priority argumentExt extension multipleExtension }

PartyInfo

} OPTIONAL

::= INTEGER { compressed complete }

MCMDummyRes

PartyNumber, MessageType, MsgCentreId OPTIONAL, CHOICE { [3] IMPLICIT Extension{{MCMExtSet}}, [4] IMPLICIT SEQUENCE OF Extension{{MCMExtSet}}

::= SEQUENCE SIZE (1..10) OF MCMUpdateReqResElt

MCMUpdateReqResElt

MCMMode

PartyInfo, MessageType, UpdateInfo, BOOLEAN DEFAULT FALSE, MCMExtensions OPTIONAL,

MessageType, MsgCentreId OPTIONAL, [3] IMPLICIT NrOfMessages OPTIONAL, [4] PartyNumber OPTIONAL, TimeStamp OPTIONAL, [5] IMPLICIT INTEGER (0..9) OPTIONAL, CHOICE { [6] IMPLICIT Extension{{MCMExtSet}}, [7] IMPLICIT SEQUENCE OF Extension{{MCMExtSet}}

(0), (1)

::= MCMExtensions

::= SEQUENCE { servedUserNr messageCentreID }

PartyNumber, MsgCentreId

- 9 -

Table 1 – Operations in support of SS-MCM (continued) UpdateInfo

AllMsgInfo

MessageInfo

::= CHOICE { newMsgInfoOnly retrievedMsgInfoOnly allMsgInfo } ::= SEQUENCE { newMsgInfo retrievedMsgInfo } ::= CHOICE { completeInfo compressedInfo noMsgsOfMsgType }

[1] MessageInfo, [2] MessageInfo, AllMsgInfo

MessageInfo, MessageInfo

[1] IMPLICIT CompleteInfo, [2] IMPLICIT CompressedInfo, NULL

CompleteInfo

::= SEQUENCE OF AddressHeader

AddressHeader

::= SEQUENCE { originatorNr timeStamp priority }

CompressedInfo

PartyNumber, [1] IMPLICIT TimeStamp [2] IMPLICIT Priority

::= SEQUENCE { nrOfMessages lastTimeStamp highestPriority }

NrOfMessages, TimeStamp Priority

NrOfMessages

::= INTEGER (0..65535)

Priority

::= INTEGER (0..9)

MsgCentreId

::= CHOICE { integer partyNumber numericString }

OPTIONAL, OPTIONAL

-- the value 0 means the highest priority -- and 9 the lowest

[0] IMPLICIT INTEGER (0..65535), [1] PartyNumber, [2] IMPLICIT NumericString (SIZE(1..10))

- 10 -

Table 1 – Operations in support of SS-MCM (continued) TimeStamp

MessageType

-----------

::= GeneralizedTime (SIZE (12..19)) a VisibleString containing: - the (local) date in 8 digits (YYYYMMDD), - followed by (local) time of day in 4 or 6 digits (HHMM[SS]), - optionally followed by the letter "Z" or by a local time differential in 5 digits ("+"HHMM or "-"HHMM); this date and time representation follows ISO 8601 Examples: 1) 19970621194530, meaning 21 June 1997, 19:45:30; 2) 19970621194530Z, meaning the same as 1); 3) 19970621194530-0500, meaning the same as 1), 5 hours retarded in relation to UTC time ::= ENUMERATED { -- Note: for the following message type see also Annex D.4 allServices (0), -- Note: for the following message types see also Annex D.1 -- For compatibility among vendors, speech is recommended for -- voice mail indications speech (1), unrestrictedDigitalInformation (2), audio3100Hz (3), telephony (32), teletex (33), telefaxGroup4Class1 (34), videotextSyntaxBased (35), videotelephony (36), telefaxGroup2-3 (37), reservedNotUsed1 (38), reservedNotUsed2 (39), reservedNotUsed3 (40), reservedNotUsed4 (41), reservedNotUsed5 (42), -- Note: for the following message types see also annex D.2 email (51), video (52), fileTransfer (53), shortMessageService (54), -- Note: for the following message types see also annex D.3 speechAndVideo (55), speechAndFax (56), speechAndEmail (57), videoAndFax (58), videoAndEmail (59), faxAndEmail (60), speechVideoAndFax (61), speechVideoAndEmail (62), speechFaxAndEmail (63), videoFaxAndEmail (64), speechVideoFaxAndEmail (65), -- Note: for the following message types see also annex D.4 multimediaUnknown (66), serviceUnknown (67),

- 11 -

Table 1 – Operations in support of SS-MCM (concluded) futureReserve1 futureReserve2 futureReserve3 futureReserve4 futureReserve5 futureReserve6 futureReserve7 futureReserve8 } MCMExtensions

::= CHOICE { none extension multipleExtension }

(68), (69), (70), (71), (72), (73), (74), (75)

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

mCMModeNotProvided

ERROR CODE

unspecified

ERROR ::= { PARAMETER Extension{{MCMExtSet}} CODE local 1008}

MCMExtSet END

::= { local 1037}

EXTENSION ::= {...} -- of SS-MCM-Operations-asn1-97

6.3.2 Information elements 6.3.2.1 Facility information element The operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of operations defined in 6.3.1, the destination Entity data element of the NFE shall contain the value endPINX. When conveying the mCMailboxFull invoke APDU defined in 6.3.1, the interpretation APDU shall be set to discardAnyUnrecognisedInvokePDU. When conveying any other invoke APDU of operations defined in 6.3.1, the interpretation APDU shall either be omitted or have the value rejectAnyUnrecognisedInvokePdu. 6.3.2.2 6.3.3

6.4

Other information elements Any other information element shall be coded in accordance with ECMA-165. Messages The Facility information element shall be conveyed in messages as specified in clause 10 of ECMA-165.

SS-MCM state definitions

6.4.1

6.4.1.1

States at the Message Centre PINX The procedures for the Message Centre PINX are written in terms of the following conceptual states existing within the SS-MCM Supplementary Service Control entity in that PINX. State MCM-MC-idle SS-MCM is not operating.

- 12 -

6.4.1.2

6.4.2

S t a t e M C M - M C - wa i t The invoke APDU of one of the following operations has been sent: mCMNewMsg, mCMNoNewMsg and mCMUpdate operation. The Message Centre PINX is waiting for the corresponding response. States at the Served User PINX The procedures for the Served User PINX are written in terms of the following conceptual states existing within the SS-MCM Supplementary Service Control entity in that PINX.

6.4.2.1

S t a t e M C M - S U - id le SS-MCM is not operating.

6.4.2.2

S t a t e M C M - S U - wa it The invoke APDU of one of the following operations has been sent: mCMService, mCMInterrogate or mCMUpdateReq operation. The Served User PINX is waiting for the corresponding response.

6.4.2.3

State MCM-SU-update The invoke APDU of the operation mCMUpdate has been received with value “moreInfoFollows” set to TRUE. The Served User PINX is waiting for the consecutive mCMUpdate invoke APDU.

6.5

SS-MCM signalling procedures For the exchange of the SS-MCM APDUs a call independent signalling connection shall be used between the Message Centre PINX and the Served User PINX. If no such connection exists the sender of the invoke APDU of the operations defined in 6.3.1 (either the Message Centre PINX or the Served User PINX) shall establish a call independent signalling connection as specified in 7.3 of ECMA-165. The corresponding return result or return error APDU shall use the same Call Reference as the invoke APDU. Call clearing is the responsibility of the sender who has established the call independent signalling connection. This may occur on receipt of a return result, return error or reject APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate. Examples of message sequences are shown in clause B.1 of annex B.

6.5.1

A c t io n s a t t h e M e s s a g e C e n t r e P I N X The SDL representation of procedures at the Message Centre PINX is shown in clause C.1 of annex C.

6.5.1.1 Normal procedures 6 . 5 . 1 . 1 . 1 A c t iv a t io n , d e a c t iv a t io n a n d in t e r r o g a t io n SS-MCM shall be available in a default configuration as arranged by the service provider. Within the default configuration an activation (i.e. re-activation after a previous deactivation or change of actual parameters) and/or deactivation of the monitoring of messages of specific Message Types can be done. Therefore, in general, upon receipt of a mCMService invoke APDU the Message Centre PINX shall check if the request (i.e. activation or deactivation of Message Types) is allowed due to the service provider's default configuration. Upon receipt of a mCMService invoke APDU with an activation request for the monitoring of messages of one or more Message Types, the Message Centre PINX shall remain in state MCM-MC-idle and shall •

inform the Message Centre with an appropriate indication about the activation request, (i.e. activation of monitoring for new and/or retrieved messages either in compressed or complete information style of one or more specific Message Types);

•

send a mCMService return result APDU towards the Served User PINX to confirm the activation request and

•

start the update procedure for the activated Message Types as described in 6.5.1.1.4.

Upon receipt of a mCMService invoke APDU containing a deactivation request for the monitoring of messages of one or more Message Types, the Message Centre PINX shall remain in state MCM-MC-idle and shall •

inform the Message Centre with an appropriate indication about the deactivated Message Types and

- 13 -

•

send a mCMService return result APDU towards the Served User PINX to confirm the deactivation request.

NOTE After the deactivation of one or more Message Types no update procedure shall be started by the Message Centre PINX. Upon receipt of a mCMService invoke APDU with the argument set to the value "set to default", the Message Centre PINX shall remain in state MCM-MC-idle and shall •

inform the Message Centre with an appropriate indication about the resetting to the default configuration as provided by the service provider;

•

send a mCMService return result APDU towards the Served User PINX to confirm the request and

•

start the update procedure as described in 6.5.1.1.4 for those Message Types which have been influenced by the request.

Upon receipt of a mCMInterrogate invoke APDU with one or more Message Types, the Message Centre PINX shall send a mCMInterrogate return result APDU to the Served User PINX and remain in MCM-MC-idle. The mCMInterrogate return result APDU indicates whether complete or compressed information is provided for new and/or retrieved messages of every Message Type mentioned in the mCMInterrogate invoke APDU. 6.5.1.1.2

I n c o m in g N e w M e s s a g e Upon receipt of an appropriate indication for the arrival of a new message from the Message Centre, the Message Centre PINX shall send a mCMNewMsg invoke APDU towards the Served User PINX, start timer T1 and enter state MCM-MC-wait. The mCMNewMsg invoke APDU shall contain the following elements: •

optionally, the identity of the Message Centre;

•

the address of the Served User;

•

the Message Type of the specific New Message.

In addition, 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 mCMNewMsg invoke APDU shall contain the following elements: a) Compressed Mode: •

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

•

optionally, the priority of the latest highest priority New Message waiting for the 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: •

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

•

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

•

optionally, the priority of the last incoming message;

•

optionally, the time of the last incoming message.

NOTE This structure is the same as the mWIActivate.invoke APDU in SS-MWI. In state MCM-MC-wait, upon receipt of mCMNewMsg return result APDU, the Message Centre PINX shall stop timer T1 and re-enter state MCM-MC-idle.

- 14 -

6.5.1.1.3

N o N e w M e s s a g e s o f a M e s s a g e Ty p e a v a ila b le a t t h e S e r v e d U s e r 's m a ilb o x Upon receipt of an appropriate indication from the Message Centre, that there are no New Messages in the Served User’s mailbox anymore, the Message Centre PINX shall send a mCMNoNewMsg invoke APDU towards the Served User PINX, start timer T1 and enter state MCM-MC-wait. The mCMNoNewMsg invoke APDU shall contain the following elements: •

optionally, the identity of the Message Centre;

•

the address of the Served User;

•

the Message Type(s) for which New Messages are not available anymore.

NOTE This structure is the same as the mWIDeactivate invoke APDU in SS-MWI. In state MCM-MC-wait, upon receipt of mCMNoNewMsg return result APDU the Message Centre PINX shall stop timer T1 and re-enter state MCM-MC-idle. 6.5.1.1.4

Update of Message Centre Information (update procedure) The update of Message Centre information is performed on the basis of the different Message Types. That means that the update procedure is done separately and sequentially for every Message Type whose number of New and Retrieved Messages has been changed due to a Served User action. In state MCM-MC-idle, upon receipt of an appropriate update indication for a specific Message Type from the Message Centre the Message Centre PINX shall start the update procedure by sending a mCMUpdate invoke APDU to the Served User PINX. The mCMUpdate invoke APDU shall contain the following elements: •

the address of the Served User;

•

the identity of the Message Centre PINX;

•

an indication about the Message Type and

•

update-information for the Served User.

The update-information includes •

either complete information;

•

or compressed information

and shall be for •

either the new messages only;

•

or the retrieved messages only;

•

or for both kind of messages (new and retrieved)

of a specific Message Type stored in the Served User's mailbox. The information related to a specific Message Type may have to be split over several consecutive mCMUpdate invoke APDUs, due to its length. In this case, parameter “moreInfoFollows” shall be included with value TRUE in all APDUs except the last one. After sending the mCMUpdate invoke APDU, the Message Centre PINX shall start timer T1 and enter state MCM-MC-wait. In state MCM-MC-wait, upon receipt of the corresponding mCMUpdate return result APDU, the Message Centre PINX shall act as follows: If further update information is to be sent, the Message Centre PINX shall send the consecutive mCMUpdate invoke APDU, restart Timer T1 and remain in state MCM-MC-wait. Otherwise the Message Centre PINX shall stop Timer T1 and enter state MCM-MC-idle.

- 15 -

6.5.1.1.5

Update request from the Served User In state MCM-MC-idle, upon receipt of a mCMUpdateReq invoke APDU the Message Centre PINX shall transmit the Served User request in an appropriate manner to the Message Centre and remain in state MCM-MC-idle. After the receipt of the requested updated information about the New Messages of a specific Message Type from the Message Centre the Message Centre PINX shall send a mCMUpdateReq return result APDU containing the following elements, depending on the mode (i.e. compressed or complete information) which is adopted in the current configuration for the New Messages: a) Compressed Mode: •

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

•

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

•

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

•

optionally, the identity of the Message Centre;

•

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

•

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

b) Complete Mode: •

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

•

optionally, the identity of the Message Centre;

•

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

NOTE This structure is the same as the mWIInterrogate invoke APDU in SS-MWI. After having sent mCMUpdateReq return result APDU, the Message Centre PINX shall start the update procedure as described in 6.5.1.1.4. 6.5.1.1.6

M a ilb o x - f u ll in d ic a t io n In state MCM-MC-idle, upon an incoming indication from the Message Centre, indicating that the Served User's mailbox for one or more Message Types is full (i.e. no more messages of those Message Types can be stored) or has reached a certain threshold (e.g. 80% of storage capacity for the Message Type), the Message Centre PINX shall send a mCMailboxFull invoke APDU towards the Served User PINX and remain in state MCM-MC-idle. The mCMailboxFull invoke APDU shall contain the Message Types for which the Served User's mailbox has reached its threshold and, optionally, the percentage of storage capacity currently used for that Message Type.

6.5.1.2 Ex c e p t io n a l p r o c e d u r e s 6 . 5 . 1 . 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 Upon receipt of an invalid mCMService invoke APDU (e.g. activation request for monitoring of a Message Type which is not provided by the service provider) the Message Centre PINX shall respond with a mCMService return error APDU and remain in state MCM-MC-idle. Upon receipt of an invalid mCMInterrogate invoke APDU (e.g. interrogation request for a Message Type which is not provided by the service provider) the Message Centre PINX shall respond with a mCMInterrogate return error APDU and remain in state MCM-MC-idle. 6.5.1.2.2

I n c o m in g N e w M e s s a g e In state MCM-MC-wait, upon receipt of mCMNewMsg return error APDU the Message Centre PINX shall stop timer T1, re-enter state MCM-MC-idle and inform the Message Centre with an appropriate error indication. Any further action is the responsibility of the Message Centre. In state MCM-MC-wait, on expiry of timer T1, the Message Centre PINX shall release the call independent signalling connection with the Served User PINX unless the connection is still

- 16 -

required for other purposes, enter MCM-MC-idle and send an appropriate error indication to the Message Centre, which may take further action. 6.5.1.2.3

N o N e w M e s s a g e s o f a M e s s a g e Ty p e a v a ila b le a t t h e S e r v e d U s e r 's m a ilb o x In state MCM-MC-wait, upon receipt of mCMNoNewMsg return error APDU, the Message Centre PINX shall stop timer T1, re-enter state MCM-MC-idle and inform the Message Centre with an appropriate error indication. Any further action is the responsibility of the Message Centre. In state MCM-MC-wait, on expiry of timer T1, the Message Centre PINX shall release the call independent signalling connection with the Served User PINX unless the connection is still required for other purposes, enter MCM-MC-idle and send an appropriate error indication to the Message Centre, which may take further action.

6.5.1.2.4

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 In state MCM-MC-wait, upon receipt of a mCMUpdate return error APDU, the Message Centre PINX shall stop timer T1, re-enter state MCM-MC-idle and inform the Message Centre with an appropriate error indication. Any further action is the responsibility of the Message Centre. In state MCM-MC-wait, on expiry of timer T1, the Message Centre PINX shall release the call independent signalling connection with the Served User PINX unless the connection is still required for other purposes, enter MCM-MC-idle and send an appropriate error indication to the Message Centre, which may take further action. In state MCM-MC-wait, upon receipt of a mCMUpdate reject APDU, the Message Centre PINX shall stop timer T1, re-enter state MCM-MC-idle and inform the Message Centre with an appropriate error indication. Any further action is the responsibility of the Message Centre. However, additional update information should not be sent.

6.5.1.2.5

6.5.2

Update request from the Served User Upon receipt of an invalid mCMUpdateReq invoke APDU (e.g. update information request for New Messages of a Message Type which is not provided by the service provider), the Message Centre PINX shall respond with a mCMUpdateReq return error APDU containing an appropriate error value and remain in state MCM-MC-idle.

A c t io n s a t t h e S e r v e d U s e r P I N X The SDL representation of procedures at the Served User PINX is shown in clause C.2 of annex C.

6.5.2.1 Normal procedures 6 . 5 . 2 . 1 . 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 state MCM-SU-idle, upon receipt of an appropriate indication from the Served User to activate, deactivate or reset SS-MCM parameters, the Served User PINX shall send a mCMService invoke APDU, start timer T2 and enter state MCM-SU-wait. The mCMService invoke APDU shall contain the following elements: •

the address of the Served User;

•

the identity of the Message Centre PINX;

•

one of the following requests: •

either an activation request for new and/or retrieved messages of one or more Message Types together with an optional indication whether complete or compressed information is requested while monitoring is active for messages of these Message Types;

•

or a deactivation request for the monitoring of messages of one or more Message Types;

•

or a reset of monitoring parameters to the default configuration as arranged by the service provider.

In state MCM-SU-wait, upon receipt of mCMService return result APDU, the Served User PINX shall stop timer T2, re-enter state MCM-SU-idle and inform the Served User in an appropriate manner.

- 17 -

In state MCM-SU-idle, upon request of the Served User, the Served User PINX shall send a mCMInterrogate invoke APDU, enter MCM-SU-wait and start timer T2. The mCMInterrogate invoke APDU shall contain the Message Types for which the Served User requests information. In state MCM-SU-wait, upon receipt of mCMInterrogate return result APDU, the Served User PINX shall stop timer T2, re-enter state MCM-SU-idle and deliver the received information in an appropriate manner to the Served User. 6.5.2.1.2

I n c o m in g N e w M e s s a g e In state MCM-SU-idle, upon receipt of a mCMNewMsg invoke APDU, the Served User PINX shall respond with a mCMNewMsg return result APDU, may give an appropriate indication to the Served User and shall remain in state MCM-SU-idle. NOTE A Message Waiting Signal can be set for that specific Message Type at the Served User's terminal.

6.5.2.1.3

N o N e w M e s s a g e s o f a M e s s a g e Ty p e a v a ila b le a t t h e S e r v e d U s e r 's m a ilb o x In state MCM-SU-idle, upon receipt of a mCMNoNewMsg invoke APDU, the Served User PINX shall respond with a mCMNoNewMsg return result APDU, may give an appropriate indication to the Served User and shall remain in state MCM-SU-idle. NOTE If a Message Waiting Signal was set for that specific Message Type, the Message Waiting Signal is cancelled at the Served User's terminal.

6.5.2.1.4

Update of Message Centre Information (update procedure) In state MCM-SU-idle or MCM-SU-update, upon receipt of a mCMUpdate invoke APDU, the Served User PINX shall respond with a mCMUpdate return result APDU and may give an appropriate indication to the Served User. In addition,

6.5.2.1.5

•

in state MCM-SU-idle, when parameter “moreInfoFollows” is set to TRUE, the Served User PINX shall start Timer T3 and enter state MCM-SU-update;

•

in state MCM-SU-update, when parameter “moreInfoFollows” is set to TRUE, the Served User PINX shall restart Timer T3 and remain in state MCM-SU-update;

•

in all other cases, the Served User PINX shall stop Timer T3, if running, and enter state MCMSU-idle.

Update request from the Served User In state MCM-SU-idle, upon the arrival of an appropriate Served User request for updated information, the Served User PINX shall send a mCMUpdateReq invoke APDU and enter state MCM-SU-wait. The mCMUpdateReq invoke APDU shall contain the following elements: •

the address of the Served User;

•

Message Type for which the Served User requests an update;

•

optionally, the identity of the Message Centre PINX.

In state MCM-SU-wait, upon receipt of mCMUpdateReq return result APDU, the Served User PINX shall stop timer T2, re-enter state MCM-SU-idle and shall inform the Served User in an appropriate manner. 6.5.2.1.6

M a ilb o x - f u ll in d ic a t io n In state MCM-SU-idle, upon receipt of a mCMailboxFull invoke APDU, the Served User PINX may inform the Served User in an appropriate manner that the Served User's mailbox has reached a certain threshold for messages of all indicated Message Types and shall remain in state MCM-SUidle.

- 18 -

6.5.2.2 Ex c e p t io n a l p r o c e d u r e s 6 . 5 . 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 state MCM-SU-wait, on receipt of a mCMService return error APDU, the Served User PINX shall stop timer T2, enter MCM-SU-idle, release the call independent signalling connection with the Message Centre PINX unless the connection is still required for other purposes, and send an appropriate error indication to the Served User. In state MCM-SU-wait, on receipt of a mCMInterrogate return error APDU, the Served User PINX shall stop timer T2, enter MCM-SU-idle, release the call independent signalling connection with the Message Centre PINX unless the connection is still required for other purposes, and send an appropriate error indication to the Served User. In state MCM-SU-wait, on expiry of timer T2, the Served User PINX shall release the call independent signalling connection with the Message Centre PINX unless the connection is still required for other purposes, enter MCM-SU-idle and send an appropriate error indication to the Served User. 6.5.2.2.2

I n c o m in g N e w M e s s a g e In state MCM-SU-idle, upon receipt of an invalid mCMNewMsg invoke APDU (e.g. Message Type not supported, user not subscribed), the Served User PINX shall respond with the mCMNewMsg return error APDU containing an appropriate error value and remain in state MCM-SU-idle.

6.5.2.2.3

N o N e w M e s s a g e s o f a M e s s a g e Ty p e a v a ila b le a t t h e S e r v e d U s e r 's m a ilb o x In state MCM-SU-idle, upon receipt of an invalid mCMNoNewMsg invoke APDU (e.g. Message Type not supported, user not subscribed) the Served User PINX shall respond with the mCMNoNewMsg return error APDU containing an appropriate error value and remain in state MCM-SU-idle.

6.5.2.2.4

Update of Message Centre Information (update procedure) In state MCM-SU-idle or in state MCM-SU-update, upon receipt of an invalid mCMUpdate invoke APDU (e.g. Message Type not supported, user not subscribed), the Served User PINX shall stop Timer T3, if running, respond with the mCMUpdate return error APDU containing an appropriate error value and enter or remain in state MCM-SU-idle. In state MCM-SU-update, on expiry of Timer T3, the Served User PINX shall enter state MCMSU-idle. In addition, the Served User PINX may send a mCMUpdateReq invoke APDU in order to restart the update procedure and may send an indication to the Served User.

6.5.2.2.5

6.5.3

6.6

Update request from the Served User In state MCM-SU-idle, upon receipt of a mCMUpdateReq return error APDU, the Served User PINX shall re-enter state MCM-SU-idle, release the call independent signalling connection with the Message Centre PINX unless the connection is still required for other purposes, and send an appropriate error indication to the Served User.

A c t io n s a t a Tr a n s it P I N X Not applicable.

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

6.7

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

6.8

Protocol interactions between SS-MCM and other supplementary services and ANFs This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had been published at the time of publication of this Standard. For interactions with supplementary services and ANFs for which stage 3 standards are published subsequent to the publication of this Standard, see those other stage 3 standards.

- 19 -

NOTE Simultaneous conveyance of APDUs for SS-MCM and another supplementary service or ANF in the same message, each in accordance with the requirements of its respective stage 3 standard, does not, on its own, constitute a protocol interaction. 6.8.1

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

6.8.2

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

6.8.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 protocol interaction.

6.8.4

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

6.8.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 protocol interaction.

6.8.6

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

6.8.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 protocol interaction.

6.8.8

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

6.8.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 protocol interaction.

6.8.10

Path Replacement (ANF-PR) No protocol interaction.

6.8.11

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

6.8.12

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

6.8.13

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

6.8.14

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

6.8.15

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

6.8.16

Do Not Disturb (SS-DND) No protocol interaction.

6.8.17

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

6.8.18

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

6.8.19

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

- 20 -

6.8.20

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

6.8.21

Call Interception (SS-CINT) No protocol interaction.

6.8.22

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

6.8.23

Route Restriction Class (ANF-RRC) No protocol interaction.

6.8.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 protocol interaction. NOTE SS-MCM is based on SS-MWI and includes its entire functionality. The operations of SS-MWI are included in SS-MCM, therefore backward compatibility with SS-MWI is guaranteed. However, the use and meaning of the optional elements within the mWIActivate.inv APDU are not described in SS-MWI as strictly as in SS-MCM. Therefore, the complete benefit of SS-MCM may not be achieved when interworking with SS-MWI.

6.8.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 protocol interaction.

6.8.26

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

6.8.27

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

6.8.28

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

6.8.29

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

6.8.30

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

6.8.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 protocol interaction.

6.8.32

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

6.8.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 protocol interaction.

6.8.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 protocol interaction.

6.8.35

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

6.8.36

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

6.8.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 protocol interaction.

- 21 -

6.8.38

Short Message Service (SS-SMS) No protocol interaction.

6.8.39

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

6.8.40

M a ilb o x I d e n t if ic a t io n ( S S - M I D ) If the identification and authentication procedures of SS-MID are used in conjunction with SS-MCM operations the following interworking shall occur upon receipt of a SS-MID operation return error or reject APDU: Upon receipt of a mIDMailboxID return error or reject APDU an invoke APDU of the SS-MCM operations mCMNewMsg, mCMNoNewMsg, mCMUpdate and mCMailboxFull may be sent. Upon receipt of a mIDMailboxAuth return error or reject APDU an invoke APDU of the SS-MCM operations mCMUpdateReq, mCMService and mCMInterrogate shall not be sent.

6.9 6.9.1

SS-MCM parameter values (timers) Timer T1 Timer T1 shall operate at the Message Centre PINX during state MCM-MC-wait. Its purpose is to protect against an absence of a response to an invoke APDU sent by the Message Centre PINX. Timer T1 shall have a value between 15 and 30 seconds.

6.9.2

Timer T2 Timer T2 shall operate at the Served User PINX during state MCM-SU-Wait. Its purpose is to protect against an absence of a response to an invoke APDU sent by the Served User PINX. Timer T2 shall have a value not less than 10 seconds.

6.9.3

Timer T3 Timer T3 shall operate at the Served User PINX during state MCM-SU-update. Its purpose is to protect against an incomplete update procedure. Timer T3 shall have a value not less than 35 seconds.

- 22 -

Signalling protocol for the support of SS-MID

7.1

SS-MID description The supplementary service MID enables a Message Centre to identify a specific Mailbox of a Served User in case 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.

7.2 7.2.1

SS-MID operational requirements Requirements on a Message Centre PINX Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for call-independent control (connection-oriented) of supplementary services, as specified in ECMA-165 for an Originating PINX and for a Terminating PINX, shall apply.

7.2.2

7.2.3

- 23 -

7.3 7.3.1

SS-MID coding requirements O p e r a t io n s The operations defined in Abstract Syntax Notation One (ASN.1) in table 2 shall apply. Table 2 – Operations in support of SS-MID

SS-MID-Operations-asn1-97 {iso (1) identified-organization (3) icd-ecma (0012) standard (0) qsig-mailbox-identification (347) mailbox-identification-operations-asn1-97 (2)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations (4) informationObjects (5) version1 (0)} EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 {iso standard pss1-generic-procedures (11582) msi-class-asn1-97 (11)} basicServiceNotProvided, userNotSubscribed, invalidServedUserNr FROM General-Error-List {itu-t (0) recommendation (0) q (17) 950 (950) general-error-list (1)} PresentedAddressUnscreened FROM Addressing-Data-Elements-asn1-97 {iso standard pss1-generic-procedures (11582) addressing-dataelements-asn1-97 (20)} Name FROM Name-Operations-asn1-97 {iso standard pss1-name (13868) name-operations-asn1-97 (1)} MessageType, MsgCentreId FROM SS-MCM-Operations-asn1-97 {iso (1) identified-organization (3) icd-ecma (0012) standard (0) qsig-message-centre-monitoring (347) message-centre-monitoring-operations-asn1-97 (1)} ;

MID-Operations

OPERATION ::= {mIDMailboxAuth | mIDMailboxID}

mIDMailboxAuth

OPERATION ::= { ARGUMENT MIDMailboxAuthArg RESULT MIDDummyRes ERRORS {userNotSubscribed | invalidServedUserNr | invalidMailbox | authorizationFailed | unspecified} CODE local 119}

- 24 -

Table 2 – Operations in support of SS-MID (continued) mIDMailboxID

OPERATION ::= { ARGUMENT MIDMailboxIDArg RESULT MIDDummyRes ERRORS {userNotSubscribed | invalidServedUserNr | invalidMailbox | unspecified} CODE local 120}

MIDMailboxAuthArg

::= SEQUENCE { partyInfo servedUserName mailBox password extensions ... }

MIDMailboxIDArg

MIDDummyRes

::= MIDExtensions

PartyInfo

::= SEQUENCE { servedUserNr messageType messageCentreID }

MIDExtensions

OPTIONAL, OPTIONAL, OPTIONAL,

::= SEQUENCE { partyInfo servedUserName mailBox extensions ... }

String

PartyInfo, Name [8]String String, MIDExtensions

::= CHOICE { stringBmp stringUtf8 } ::= CHOICE { none extension multipleExtension }

PartyInfo, Name String, MIDExtensions

OPTIONAL, OPTIONAL,

PresentedAddressUnscreened, MessageType OPTIONAL, MsgCentreId

BMPString, UTF8String

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

- 25 -

Table 2 – Operations in support of SS-MID (concluded) invalidMailbox

ERROR ::= { CODE local 1039}

authorizationFailed

ERROR ::= { CODE local 1040}

unspecified

ERROR ::= { PARAMETER Extension{{MIDExtSet}} CODE local 1008}

MIDExtSet

EXTENSION ::= {...}

END

-- of SS-MID-Operations-asn1-97

7.3.2 Information elements 7.3.2.1 Facility information element The operations defined in 7.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of operations defined in 7.3.1, the destination Entity data element of the NFE shall contain the value endPINX. When conveying the invoke APDU of operations defined in 7.3.1, the interpretation APDU shall either be omitted or have the value rejectAnyUnrecognizedInvokePdu. 7.3.2.2 7.3.3

7.4

SS-MID state definitions

7.4.1

States at the Message Centre PINX The procedures for the Message Centre PINX are written in terms of the following conceptual states existing within the SS-MID Supplementary Service Control entity in that PINX.

7.4.1.1

S t a t e M I D - M C - id le SS-MID is not operating.

7.4.1.2

S t a t e M I D - M C - wa it A mIDMailboxID invoke APDU has been sent. The Message Centre PINX is waiting for the response.

7.4.2

States at the Served User PINX The procedures for the Served User PINX are written in terms of the following conceptual states existing within the SS-MID Supplementary Service Control entity in that PINX.

7.4.2.1

S t a t e M I D - S U - id le SS-MID is not operating.

7.4.2.2

S t a t e M I D - S U - wa it A mIDMailboxAuth invoke APDU has been sent. The Served User PINX is waiting for the response.

7.5

SS-MID signalling procedures Examples of message sequences are shown in clause B.3 of annex B.

7.5.1

A c t io n s a t t h e M e s s a g e C e n t r e P I N X The SDL representation of procedures at the Message Centre PINX is shown in clause C.3 of annex C.

- 26 -

7.5.1.1 Normal procedures 7 . 5 . 1 . 1 . 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.5.1.1.2

I n v o c a t io n a n d o p e r a t io n In state MID-MC-idle, upon receipt of an appropriate indication from the Message Centre (e.g. that the following information belongs to a specific Mailbox of the Server User), the Message Centre PINX shall send a mIDMailboxID invoke APDU towards the Served User PINX, start timer T1 and enter state MID-MC-wait. The mIDMailboxID invoke shall contain the following elements: •

the address of the Served User;

•

optionally, the Message Type of the messages which are stored in that specific Mailbox;

•

the identity of the Message Centre;

•

optionally, the name of the Served User;

•

the identifier (e.g. name) of the specific Served User Mailbox.

In state MID-MC-wait, upon receipt of mIDMailboxID return result APDU, the Message Centre PINX shall stop timer T1 and re-enter state MID-MC-idle. In state MID-MC-idle, upon receipt of a mIDMailboxAuth invoke APDU from the Served User PINX, the Message Centre PINX shall perform the following consecutive actions: •

verification of the Served User's authentication request; NOTE It is an implementation option if this is done by the Message Centre PINX itself or in conjunction with the Message Centre.

•

send a mIDMailboxAuth return result APDU towards the Served User PINX, if the verification is valid, and remain in state MID-MC-idle.

7.5.1.2 Ex c e p t io n a l p r o c e d u r e s 7 . 5 . 1 . 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.5.1.2.2

I n v o c a t io n a n d o p e r a t io n In state MID-MC-wait, upon receipt of a mIDMailboxID return error APDU, the Message Centre PINX shall stop timer T1, re-enter state MID-MC-idle and inform the Message Centre with an appropriate error indication. Any further action is the responsibility of the Message Centre. In state MID-MC-wait, on expiry of timer T1, the Message Centre PINX shall release the call independent signalling connection with the Served User PINX unless the connection is still required for other purposes, send an appropriate error indication to the Message Centre and enter state MID-MC-idle. In state MID-MC-idle, on receipt of an invalid mIDMailboxAuth invoke APDU (e.g. invalid Served User password), the Message Centre PINX shall respond with a mIDMailboxAuth return error APDU with an appropriate error value towards the Served User PINX and remain in state MIDMC-Idle.

7.5.2

A c t io n s a t t h e S e r v e d U s e r P I N X The SDL representation of procedures at the Served User PINX is shown in clause C.4 of annex C.

7.5.2.1 Normal procedures 7 . 5 . 2 . 1 . 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.

- 27 -

7.5.2.1.2

I n v o c a t io n a n d o p e r a t io n In state MID-SU-idle, upon receipt of a mIDMailboxID invoke APDU, the Served User PINX shall respond with a mIDMailboxID return result APDU, may give an appropriate indication to the Served User and shall remain in state MID-SU-idle. In state MID-SU-idle, upon receipt of an appropriate indication from the Served User, the Served User PINX shall send a mIDMailboxAuth invoke APDU, start timer T2 and enter state MID-SUwait. The mIDMailboxAuth invoke APDU shall contain the following elements: •

the address of the Served User;

•

optionally, the Message Type of the messages which are stored in that specific Mailbox;

•

the identity of the Message Centre;

•

optionally, the name of the Served User;

•

optionally, the identifier (e.g. name) of the specific Served User Mailbox;

•

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

In state MID-SU-wait, upon receipt of the corresponding mIDMailboxAuth return result APDU, the Served User PINX may indicate the valid authentication at the Message Centre by sending an appropriate indication to the Served User. Any further action is the responsibility of the Served User PINX. NOTE These further actions can be triggered by Served User actions or timer expiry. 7.5.2.2 Ex c e p t io n a l p r o c e d u r e s 7 . 5 . 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.5.2.2.2

I n v o c a t io n a n d o p e r a t io n In state MID-SU-idle, on receipt of an invalid mIDMailboxID invoke APDU (e.g. invalid Mailbox identifier), the Served User PINX shall send a mIDMailboxID return error APDU with an appropriate error value towards the Message Centre PINX and remain in state MID-SU-idle. In state MID-SU-wait, upon receipt of a mIDMailboxAuth return error APDU, the Served User PINX shall stop timer T2, re-enter state MID-SU-idle and may inform the Served User with an appropriate error indication. Any further action is the responsibility of the Served User. In state MID-SU-wait, on expiry of timer T2, the Served User PINX shall release the call independent signalling connection with the Message Centre PINX unless the connection is still required for other purposes, may send an appropriate error indication to the Served User and shall enter state MID-SU-idle.

7.5.3

7.6

A c t io n s a t a Tr a n s it P I N X Not applicable.

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

7.7

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

7.8

Protocol interactions between SS-MID and other supplementary services and ANFs This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had been published at the time of publication of this Standard. For interactions with supplementary services and ANFs for which stage 3 standards are published subsequent to the publication of this Standard, see those other stage 3 standards.

- 28 -

NOTE Simultaneous conveyance of APDUs for SS-MID and another supplementary service or ANF in the same message, each in accordance with the requirements of its respective stage 3 standard, does not, on its own, constitute a protocol interaction. 7.8.1

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

7.8.2

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

7.8.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 protocol interaction.

7.8.4

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

7.8.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 protocol interaction.

7.8.6

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

7.8.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 protocol interaction.

7.8.8

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

7.8.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 protocol interaction.

7.8.10

Path Replacement (ANF-PR) No protocol interaction.

7.8.11

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

7.8.12

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

7.8.13

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

7.8.14

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

7.8.15

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

7.8.16

Do Not Disturb (SS-DND) No protocol interaction.

7.8.17

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

7.8.18

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

7.8.19

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

- 29 -

7.8.20

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

7.8.21

Call Interception (SS-CINT) No protocol interaction.

7.8.22

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

7.8.23

Route Restriction Class (ANF-RRC) No protocol interaction.

7.8.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 protocol interaction.

7.8.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 protocol interaction.

7.8.26

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

7.8.27

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

7.8.28

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

7.8.29

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

7.8.30

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

7.8.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 protocol interaction.

7.8.32

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

7.8.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 protocol interaction.

7.8.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 protocol interaction.

7.8.35

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

7.8.36

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

7.8.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 protocol interaction.

7.8.38

Short Message Service (SS-SMS) No protocol interaction.

7.8.39

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

- 30 -

7.8.40

Message Centre Monitoring (SS-MCM) If the identification and authentication procedures of SS-MID are used in conjunction with SS-MCM operations the following interworking shall occur upon receipt of a SS-MID operation return error or reject APDU: Upon receipt of a mIDMailboxID return error or reject APDU an invoke APDU of the SS-MCM operations mCMNewMsg, mCMNoNewMsg, mCMUpdate and mCMailboxFull may be sent. Upon receipt of a mIDMailboxAuth return error or reject APDU the invoke APDU of the SS-MCM operations mCMUpdateReq, mCMService and mCInterrogate shall not be sent.

7.9 7.9.1

SS-MID parameter values (timers) Timer T1 Timer T1 shall operate at the Message Centre PINX during state MID-MC-wait. Its purpose is to protect against an absence of response to the mIDMailboxID invoke APDU. Timer T1 shall have a value not less than 15 seconds.

7.9.2

Timer T2 Timer T2 shall operate at the Served User PINX during state MID-SU-wait. Its purpose is to protect against an absence of response to the mIDMailboxAuth invoke APDU. Timer T2 shall have a value not less than 15 seconds.

- 31 -

Annex A ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) Proforma

A.1

Introduction The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use:

A.2

−

by the protocol implementor, as a check-list to reduce the risk of failure to conform to the standard through oversight;

−

by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the standard's PICS proforma;

−

by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICSs;

−

by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.

Instructions for completing the PICS proforma

A.2.1

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

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

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

o.<n>

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

prohibited;

<c.cond>

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

<item>:m

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

<item>:o

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

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

- 32 -

A.2.2

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

A.2.3

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

- 33 -

A.3

PICS proforma for SS-MCM

A.3.1

Implementation identification

Supplier Contact point for queries about the PICS Implementation name(s) and version(s) Other information necessary for full identification, e.g., name(s) and version(s) for machines and/or operating systems; system name(s)

Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. The terms name and version should be interpreted appropriately to correspond with a supplier’s terminology (e.g. type, series, model).

A.3.2

Protocol summary

Protocol version

1.0

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

Date of Statement

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

- 34 -

A.3.3

General

Item

Question/feature

A1 A2

References

Status

N/A

Support

Behaviour as a Message Centre PINX for SS-MCM

o.1

[]

Yes [ ] No[ ]

Behaviour as a Served User PINX for SS-MCM

o.1

[]

Yes [ ] No[ ]

References

Status

N/A

Support

o.1: at least one of the items

A.3.4

Procedures

Item

Question/feature

Support of relevant ECMA-165 procedures at the Message Centre PINX

6.2.1

A1:m

[]

m:Yes [ ]

Support of relevant ECMA-165 procedures at the Served User PINX

6.2.2

A2:m

[]

m:Yes [ ]

Procedures at the Message Centre PINX for activation and deactivation of monitoring messages for specific Message Types

6.5.1

A1:o

[]

Yes [ ] No[ ]

Procedures at the Message Centre PINX for interrogation of current monitoring configuration

6.5.1

A1:o

[]

Yes [ ] No[ ]

Procedures at the Message Centre PINX for the arrival of new messages

6.5.1

A1:m

[]

m:Yes [ ]

Procedures at the Message Centre PINX for indicating no New Messages of a specific Message Type are available

6.5.1

A1:m

[]

m:Yes [ ]

Procedures at the Message Centre PINX for an update of Message Centre information

6.5.1

A1:m

[]

m:Yes [ ]

Procedures at the Message Centre PINX for an update request of Message Centre information

6.5.1

A1:m

[]

m:Yes [ ]

Procedures at the Message Centre PINX for a mailbox-full indication

6.5.1

A1:o

[]

Yes [ ] No[ ]

B10

Procedures at the Served User PINX for activation and deactivation of monitoring messages for specific Message Types

6.5.2

A2:o

[]

Yes [ ] No[ ]

B11

Procedures at the Served User PINX for interrogation of current monitoring configuration

6.5.2

A2:o

[]

Yes [ ] No[ ]

B12

Procedures at the Served User PINX for the arrival of new messages

6.5.2

A2:m

[]

m:Yes [ ]

B13

Procedures at the Served User PINX for indicating no New Messages of a specific Message Type are available

6.5.2

A2:m

[]

m:Yes [ ]

- 35 -

Item

Question/feature

References

Status

N/A

Support

B14

Procedures at the Served User PINX for an update of Message Centre information

6.5.2

A2:m

[]

m:Yes [ ]

B15

Procedures at the Served User PINX for an update request of Message Centre information

6.5.2

A2:m

[]

m:Yes [ ]

B16

Procedures at the Served User PINX for a mailbox-full indication

6.5.2

A2:o

[]

Yes [ ] No[ ]

References

Status

N/A

Support

A.3.5

Coding

Item

Question/feature

sending of mCMNewMessage invoke APDU and receiving of mCMNewMessage return result or return error APDU

6.3.1

A1:m

[]

m:Yes [ ]

receipt of mCMNewMessage invoke APDU and sending of mCMNewMessage return result or return error APDU

6.3.1

A2:m

[]

m:Yes [ ]

sending of mCMNoNewMessage invoke APDU and receiving of mCMNoNewMessage return result or return error APDU

6.3.1

A1:m

[]

m:Yes [ ]

receipt of mCMNoNewMessage invoke APDU and sending of mCMNoNewMessage return result or return error APDU

6.3.1

A2:m

[]

m:Yes [ ]

sending of mCMUpdate invoke APDU and receiving of mCMUpdate return result or return error APDU

6.3.1

A1:m

[]

m:Yes [ ]

receipt of mCMUpdate invoke APDU and sending of mCMUpdate return result or return error APDU

6.3.1

A2:m

[]

m:Yes [ ]

receipt of mCMUpdateReq invoke APDU and sending of mCMUpdateReq return result or return error APDU

6.3.1

A1:m

[]

m:Yes [ ]

sending of mCMUpdateReq invoke APDU and receiving of mCMUpdateReq return result or return error APDU

6.3.1

A2:m

[]

m:Yes [ ]

receipt of mCMService invoke APDU and sending of mCMService return result or return error APDU

6.3.1

B3:m

[]

m:Yes [ ]

C10

sending of mCMService invoke APDU and receiving of mCMService return result or return error APDU

6.3.1

B10:m

[]

m:Yes [ ]

C11

receipt of mCMInterrogate invoke APDU and sending of mCMInterrogate return result or return error APDU

6.3.1

B4:m

[]

m:Yes [ ]

- 36 -

Item

Question/feature

References

Status

N/A

Support

C12

sending of mCMInterrogate invoke APDU and receiving of mCMInterrogate return result or return error APDU

6.3.1

B11:m

[]

m:Yes [ ]

C13

sending of mCMailboxFull invoke APDU

6.3.1

B9:m

[]

m:Yes [ ]

C14

receipt of mCMailboxFull invoke APDU

6.3.1

B16:m

[]

m:Yes [ ]

A.3.6

Timers

Item

Question/feature

References

Status

N/A

Support

Support of Timer T1

6.9.1

A1:m

[]

m:Yes [ ] value: ...

Support of Timer T2

6.9.2

A2:m

[]

m:Yes [ ] value: ...

Support of Timer T3

6.9.3

A2:m

[]

m:Yes [ ] value: ...

- 37 -

A.4

PICS proforma for SS-MID

A.4.1

Implementation identification

A.4.2

Protocol summary

Protocol version

1.0

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

Date of Statement

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

- 38 -

A.4.3

General

Item

Question/feature

A1 A2

References

Status

N/A

Support

Behaviour as Message Centre PINX for SS-MID

o.1

[]

Yes [ ] No[ ]

Behaviour as Served User PINX for SS-MID

o.1

[]

Yes [ ] No[ ]

References

Status

N/A

Support

o.1: at least one of the items

A.4.4

Procedures

Item

Question/feature

Support of relevant ECMA-165 procedures at the Message Centre PINX

7.2.1

A1:m

[]

m:Yes [ ]

Support of relevant ECMA-165 procedures at the Served User PINX

7.2.2

A2:m

[]

m:Yes [ ]

Procedures at the Message Centre PINX for identification of Served User mailboxes

7.5.1

A1:o2

[]

Yes [ ] No[ ]

Procedures at the Message Centre PINX for authentication of a Served User at his/her mailbox

7.5.1

A1:o2

[]

Yes [ ] No[ ]

Procedures at the Served User PINX for identification of Served User mailboxes

7.5.2

A2:o3

[]

Yes [ ] No[ ]

Procedures at the Served User PINX for authentication of a Served User at his/her mailbox

7.5.2

A2:o3

[]

Yes [ ] No[ ]

References

Status

N/A

Support

o.2: at least one of the items o.3: at least one of the items

A.4.5

Coding

Item

Question/feature

sending of mIDMailboxID invoke APDU and receiving of mIDMailboxID return result or return error APDU

7.3.1

B3:m

[]

m:Yes [ ]

receipt of mIDMailboxID invoke APDU and sending of mIDMailboxID return result or return error APDU

7.3.1

B5:m

[]

m:Yes [ ]

receipt of mIDMailboxAuth invoke APDU and sending of mIDMailboxAuth return result or return error APDU

7.3.1

B4:m

[]

m:Yes [ ]

sending of mIDMailboxAuth invoke APDU and receiving of mIDMailboxAuth return result or return error APDU

7.3.1

B6:m

[]

m:Yes [ ]

- 39 -

A.4.6

Timers

Item

Question/feature

References

Status

N/A

Support

Support of Timer T1

7.9.1

B3:m

[]

m:Yes [ ] value: ...

Support of Timer T2

7.9.2

B6:m

[]

m:Yes [ ] value: ...

- 40 -

- 41 -

Annex B ( in f o r ma tiv e )

Examples of Message Sequences

This annex describes some typical message flows for SS-MCM as well as SS-MID. The following conventions are used in the figures of this annex. 1. The following notation is used: Call Independent Signalling Connection messages containing SS-MCM or SS-MID information Call Independent Signalling Connection messages without SS-MCM or SS-MID information SS-MCM or SS-MID information for the Served User or the Message Centre

2. The figures show messages exchanged via Protocol Control between PINXs involved in SS-MCM and SS-MID. Only messages relevant to SS-MCM as well as SS-MID are shown. 3. Only the relevant information content (e.g. remote operation APDUs, notifications, information elements) is listed below each message name. The Facility and Notification indicator information elements containing remote operation APDUs and notifications are not explicitly shown. Information with no impact on SS-MCM and SS-MID is not shown.

- 42 -

B.1 B.1.1

Example message sequence for SS-MCM Example message sequence for activation, deactivation and interrogation The figures B.1.1 – B.1.3 show an example for activation, deactivation and interrogation of monitoring of messages.

Message Centre

Message Centre PINX

Served User PINX

Served User

indication activate monitoring of messages of a Message Type(s) SETUP mCMService.inv (activateMCM) indication

CALL PROC

activate monitoring of messages of Message Type(s)

CONNECT mCMService.rr

indication monitoring activated

indication

FACILITY

Message Centre information for the activated Message Type(s)

mCMUpdate.inv NOTE Start of the Update procedure. For detailed information see figure B.1.6.

F ig u r e B. 1 . 1 – Ex a m p le o f a c t iv a t io n o f m o n it o r in g o f m e s s a g e s o f a s p e c if ic M e s s a g e Ty p e

- 43 -

Message Centre

Message Centre PINX

Served User PINX

Served User

indication deactivate monitoring of messages of a Message Type(s) SETUP mCMService.inv (deactivateMCM) indication

CALL PROC

deactivate monitoring of messages of Message Type(s)

RELEASE mCMService.rr indication REL COMP

monitoring of Message Type(s) deactivated

F ig u r e B. 1 . 2 – Ex a m p le o f d e a c t iv a t io n o f m o n it o r in g o f m e s s a g e s o f a s p e c if ic M e s s a g e Ty p e

- 44 -

Message Centre

Message Centre PINX

Served User PINX

Served User

indication interrogation about monitoring of messages of Message Type(s) SETUP mCMInterrogate.inv (MessageType(s)) CALL PROC

CONNECT mCMInterrogate.rr (activated Message Types(s))

RELEASE

indication about the activated monitoring of messages of Message Types

REL COMP

F ig u r e B. 1 . 3 – Ex a m p le f o r in t e r r o g a t io n o f m o n it o r in g o f m e s s a g e s

- 45 -

B.1.2

Example message sequence for the arrival of a New Message Figure B.1.4 shows an example for the Incoming New Message procedure.

Message Centre

Message Centre PINX

Served User PINX

Served User

indication New Message of an activated Message Type SETUP mCMNewMsg.inv (Message Type)

CALL PROC

RELEASE mCMNewMsg.rr

indication

REL COMP

New Message of a specific Message Type

F ig u r e B. 1 . 4 – Ex a m p le f o r t h e S S - M C M I n c o m i n g N e w M e s s a g e p r o c e d u r e

- 46 -

B.1.3

Example message sequence for the sending of the NoNewMessage indication Figure B.1.5 shows an example for the sending of the NoNewMessage indication.

Message Centre

Message Centre PINX

Served User PINX

Served User

NOTE Internal update within the Message Centre due to Served User actions (e.g. deletion of messages). indication No New Message of an activated Message Type in the mailbox

SETUP mCMNoNewMsg.inv (Message Type)

CALL PROC T1

CONNECT

indication

mCMNoNewMsg.rr

No New Message of a specific Message Type available in the mailbox

update indication New and/or Retrieved Messages for all of the requested Message Types T1

FACILITY mCMUpdate.inv (1st Message Type, UpdateInfo) NOTE Start of the Update procedure. For detailed information see figure B.1.6.

F ig u r e B. 1 . 5 – Ex a m p le f o r t h e S S - M C M in d ic a t io n t h a t N o N e w M e s s a g e s a r e in t h e m a ilb o x

- 47 -

B.1.4

Example message sequence for the Update of Message Centre Information (update procedure) Figure B.1.6 shows an example for the update procedure for various (n) Message Types, whereby the information on each Message Type does not exceed the limited length of a mCMUpdate invoke APDU. Therefore, parameter"moreInfoFollows" is set to FALSE in each APDU.

Message Centre

Message Centre PINX

Served User PINX

Served User

NOTE Internal update within the Message Centre due to Served User actions (e.g. deletion of messages). update indication

SETUP

New and/or Retrieved Messages for the 1st of the activated Message Types

mCMUpdate.inv (1st Message Type, UpdateInfo)

...

CALL PROC CONNECT

indication

mCMUpdate.rr

actual update information for the 1st activated Message Type

...

update indication New and/or Retrieved Messages for the nth of the activated Message Types T1

FACILITY mCMUpdate.inv (nth Message Type, UpdateInfo)

indication actual update information for the nth activated Message Type

FACILITY mCMUpdate.rr RELEASE REL COMP

Figure B.1.6 – Example for the SS-MCM Update procedure

- 48 -

B.1.5

Example message sequence for the SS-MCM Update request from the Served user Figure B.1.7 shows an example for an update request from the Served User.

Message Centre

Message Centre PINX

Served User PINX

Served User

indication

indication information about messages of a specific Message Type

SETUP mCMUpdateReq.inv (specific Message Type) CALL PROC

indication updated information about the New Messages of the requested Message Type

information about messages of a specific Message Type

CONNECT mCMUpdateReq.rr

indication information about the New Messages of the requested Message Type

update indication New and/or Retrieved Messages for all of the requested Message Types T1

FACILITY mCMUpdate.inv (1st Message Type, UpdateInfo) NOTE Start of the Update procedure. For detailed information see figure B.1.6.

Figure B.1.7 – Example for the SS-MCM Update Request procedure

- 49 -

B.1.6

Example message sequence for the SS-MCM Mailbox-Full indication Figure B.1.8 shows an example for a MailboxFull indication procedure.

Message Centre

Message Centre PINX

Served User PINX

Served User

indication Mailbox-full indication for an activated Message Type

SETUP mCMailboxFull.inv (Message Type) CALL PROC

indication

RELEASE

Mailbox-full indication for an activated Message Type

REL COMP

Figure B.1.8 – Example for the SS-MCM Mailbox-full indication

- 50 -

B.2 B.2.1

Example message sequences for interworking between for SS-MCM and SS-MWI SS-MCM is implemented at the Message Centre PINX Interworking scenarios between SS-MCM and SS-MWI if SS-MCM is implemented at the Message Centre PINX whereas SS-MWI is implemented at the Served User PINX. For simplification reasons the messages are conveyed within a FACILITY message.

Message Centre

Message Centre PINX (SS-MCM implemented)

Served User PINX (SS-MWI implemented)

Served User

indication New Message of an activated Message Type

FACILITY mCMNewMsg.inv = mWIActivate.inv

FACILITY mWIActivate.rr/.re = mCMNewMsg.rr/.re

indication New Message of a specific Message Type

F ig u r e B. 2 . 1 . 1 – Ex a m p le f o r in t e r wo r k in g wit h t h e S S - M C M I n c o m i n g N e w M e s s a g e p r o c e d u r e

- 51 -

Message Centre

Message Centre PINX (SS-MCM implemented)

Served User PINX (SS-MWI implemented)

Served User

indication No New Message of an activated Message Type

FACILITY mCMNoNewMsg.inv = mWIDeactivate.inv

FACILITY mWIDeactivate.rr/.re = mCMNoNewMsg.rr/.re

indication No New Message of a specific Message Type

FACILITY mCMUpdate.inv FACILITY mCMUpdate.rej

F ig u r e B. 2 . 1 . 2 – Ex a m p le f o r in t e r wo r k in g wit h t h e S S - M C M in d ic a t io n t h a t N o N e w M e s s a g e s are in the mailbox

- 52 -

Message Centre

Message Centre PINX (SS-MCM implemented)

Served User PINX (SS-MWI implemented)

Served User

indication with update-information FACILITY mCMUpdate.inv (1st Message Type) FACILITY NOTE Implementation dependent if all mCMUpdate.inv APDUs for all Message Types are sent.

mCMUpdate.rej (1st Message Type)

... FACILITY mCMUpdate.inv (n th Message Type) FACILITY mCMUpdate.rej (n th Message Type)

F ig u r e B. 2 . 1 . 3 – Ex a m p le f o r t h e in t e r wo r k i n g w i t h t h e S S - M C M U p d a t e p r o c e d u r e

- 53 -

Message Centre

Message Centre PINX (SS-MCM implemented)

Served User PINX (SS-MWI implemented)

FACILITY indication indication

Served User

indication

mWIInterrogate.inv = mCMUpdateReq.inv FACILITY mCMUpdateReq.rr/.re = mWIInterrogate.rr/.re

indication

FACILITY mCMUpdate.inv (1st Message Type) NOTE Implementation dependent if all mCMUpdate.inv APDUs for all Message Types are sent.

FACILITY mCMUpdate.rej (1st Message Type)

...

F ig u r e B. 2 . 1 . 4 – Ex a m p le f o r in t e r wo r k in g f o r t h e S S - M C M U p d a t e R e q u e s t p r o c e d u r e

- 54 -

B.2.2

SS-MCM is implemented at the Served User PINX Interworking scenarios between SS-MCM and SS-MWI, if SS-MCM is implemented at the Served User PINX whereas SS-MWI is implemented at the Message Centre PINX. For simplification reasons the messages are conveyed within a FACILITY message.

Message Centre

Message Centre PINX (SS-MWI implemented)

Served User PINX (SS-MCM implemented)

FACILITY

Served User

indication

mCMService.inv

FACILITY mCMService.rej

indication

F ig u r e B. 2 . 2 . 1 – Ex a m p le f o r in t e r wo r k in g f o r t h e S S - M C M a c t iv a t io n a n d d e a c t iv a t io n procedure

- 55 -

Message Centre

Message Centre PINX (SS-MWI implemented)

Served User PINX (SS-MCM implemented)

FACILITY

Served User

indication

mCMInterrogate.inv

FACILITY mCMInterrogate.rej

indication

F ig u r e B. 2 . 2 . 2 – Ex a m p le f o r in t e r wo r k in g f o r t h e S S - M C M in t e r r o g a t io n p r o c e d u r e

- 56 -

Message Centre

Message Centre PINX (SS-MWI implemented)

Served User PINX (SS-MCM implemented)

Served User

indication arrival of a New Message of an activated Message Type

FACILITY mWIActivate.inv = mCMNewMsg.inv

FACILITY mCMNewMsg.rr/.re = mWIActivate.rr/.re

indication New Message of a specific Message Type

F ig u r e B. 2 . 2 . 3 – Ex a m p le f o r in t e r wo r k in g wit h t h e S S - M C M I n c o m i n g N e w M e s s a g e p r o c e d u r e

- 57 -

Message Centre

Message Centre PINX (SS-MWI implemented)

Served User PINX (SS-MCM implemented)

Served User

indication No New Message of an activated Message Type

FACILITY mWIDeactivate.inv = mCMNoNewMsg.inv

FACILITY mCMNoNewMsg.rr/.re = mWIDeactivate.rr/.re

indication No New Message of a specific Message Type

F ig u r e B. 2 . 2 . 4 – Ex a m p le f o r in t e r wo r k in g wit h t h e S S - M C M in d ic a t io n t h a t N o N e w M e s s a g e s a r e in t h e m a ilb o x

- 58 -

Message Centre

Message Centre PINX (SS-MWI implemented)

Served User PINX (SS-MCM implemented)

FACILITY indication

Served User

indication

mCMUpdateReq.inv = mWIInterrogate.inv

indication FACILITY mWIInterrogate.rr/.re = mCMUpdateReq.rr/.re

indication

F ig u r e B. 2 . 2 . 5 – Ex a m p le f o r in t e r wo r k in g f o r t h e S S - M C M U p d a t e R e q u e s t p r o c e d u r e

- 59 -

B.3 B.3.1

Example message sequence for SS-MID Example message sequence for identification of a specific Served User Mailbox Figure B.3.1 shows an example for Mailbox identification within SS-MID.

Message Centre

Message Centre PINX

Served User PINX

Served User

indication identification of a specific Mailbox of the Served User

SETUP mIDMailboxID.inv

CALL PROC T2

CONNECT mIDMailboxID.rr

RELEASE

indication identification of a specific Mailbox of the Served User

REL COMP

F ig u r e B. 3 . 1 – Ex a m p le f o r M a ilb o x id e n t if ic a t io n wit h in S S - M I D

- 60 -

B.3.2

Example message sequence for authentication of a Served User at a specific Mailbox Figure B.3.2 shows an example for the authentication within SS-MID.

Message Centre

Message Centre PINX

Served User PINX

Served User

indication

SETUP

Mailbox authentication request from the Served User

mIDMailboxAuth.inv

indication

CALL PROC

Mailbox authentication request from the Served User indication Message authentication valid

CONNECT mIDMailboxAuth.rr

indication Message authentication valid

RELEASE REL COMP

F ig u r e B. 3 . 2 – Ex a m p le f o r a u t h e n t ic a t io n wit h in S S - M I D

- 61 -

Annex C ( in f o r ma tiv e )

Specification and Description Language (SDL) Representation of Procedures

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

invoke APDU

.res

return result APDU

.err

return error APDU

- 62 -

C.1

SDL representation of SS-MCM at the Message Centre PINX Figures C.1.1, C.1.2, C.1.3, C.1.4, C.1.5, C.1.6 and C.1.7 show the behaviour of an SS-MCM Supplementary Service Control entity within the Message Centre PINX. Input signals from the left and output signals to the left represent primitives from and to the Message Centre or internal events (e.g. timer expiry events). Input signals from the right and output signals to the right represent primitives from and to the Served User PINX.

MCM-MC- idle

activation request in mCMService.inv

evaluation of the activation request

YES

mCMService.res

activation request allowed ?

mCMService.err

activation request to the MC

MCM-MC- idle

F ig u r e C . 1 . 1 – S D L r e p r e s e n t a t io n o f S S - M C M a c t iv a t io n a t t h e M e s s a g e C e n t r e P I N X

- 63 -

MCM-MC- idle

deactivation request in mCMService.inv

evaluation of the deactivation request

YES

deactivation request allowed ?

mCMService.res

mCMService.err

deactivation request to MC

MCM-MC- idle

F ig u r e C . 1 . 2 – S D L r e p r e s e n t a t io n o f S S - M C M d e a c t iv a t io n a t t h e M e s s a g e C e n t r e P I N X

- 64 -

MCM-MC- idle

mCMInterrogate.inv

evaluation of the interrogation request

YES

interogation request allowed ?

mCMInterrogate.res

mCMInterrogate.err

MCM-MC- idle

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

- 65 -

MCM-MC- idle

new message indication from MC

mCMNewMsg.inv

start Timer T1

MCM-MC-wait

expiry of Timer T1

mCMNewMsg.res

mCMNewMsg.err

stop Timer T1

Timer 1 expiry indication to MC

error indication to MC

MCM-MC- idle

Figure C.1.4 – SDL representation of SS-MCM incoming New Message at the Message Centre PINX

- 66 -

MCM-MC- idle

update information from the MC

mCMUpdate.inv

start Timer T1

MCM-MC-wait

mCMUpdate.res

stop Timer T1

YES

further update information available ?

mCMUpdate.err

expiry of Timer T1

stop Timer T1

error indication to MC

Timer 1 expiry indication to MC

MCM-MC- idle

Figure C.1.5 – SDL representation of SS-MCM update of Message Centre information at the Message Centre PINX

- 67 -

MCM-MC- idle

mCMUpdateReq.inv

YES

NO mCMUpdateReq.inv valid ?

get SS-MCM update request information

mCMUpdateReq.res

mCMUpdateReq.err

MCM-MC- idle

Figure C.1.6 – SDL representation of SS-MCM update request at the Message Centre PINX

- 68 -

MCM-MC- idle

Mailbox full indication from MC

mCMailboxFull.inv

MCM-MC- idle

Figure C.1.7 – SDL representation of SS-MCM Mailbox-full indication at the Message Centre PINX

- 69 -

C.2

SDL representation of SS-MCM at the Served User PINX Figures C.2.1, C.2.2, C.2.3, C.2.4, C.2.5, and C.2.6 show the behaviour of an SS-MCM Supplementary Service Control entity within the Served User PINX. Input signals from the right and output signals to the right represent primitives from and to the Served User or internal events (e.g. timer expiry events). Input signals from the left and output signals to the left represent primitives from and to the Message Centre PINX.

- 70 -

MCM-SU- idle

activation / deactivation request from the Served User

YES

activation / deactivation allowed ?

activation / deactivation request in mCMService.inv

error indication to the Served User

start Timer T2

MCM-SU- wait

expiry of Timer T2

mCMService.res

stop Timer T2

error indication to the Served User

confirmation of activation / deactivation

mCMService.err

stop Timer T2

error indication to the Served User

MCM-SU- idle

F ig u r e C . 2 . 1 – S D L r e p r e s e n t a t io n o f S S - M C M a c t iv a t io n / d e a c t iv a t io n at the Served User PINX

- 71 -

MCM-SU- idle

interrogation request from the Served User

YES

interrogation request allowed ?

error indication to the Served User

mCMInterrogate.inv

start Timer T2

MCM-SU- wait

expiry of Timer T2

error indication to the Served User

mCMInterrogate.res

mCMInterrogate.err

stop Timer T2

confirmation to the Served User

error indication to the Served User

MCM-SU- idle

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

- 72 -

MCM-SU- idle

mCMNewMsg.inv

YES

content of mCMNewMsg.inv valid ?

indication to the Served User about the arrival of a New Message

mCMNewMsg.res

mCMNewMsg.err

MCM-SU- idle

Figure C.2.3 – SDL representation of SS-MCM incoming New Message at the Served User PINX

- 73 -

MCM-SU-update

MCM-SU- idle

mCMUpdate.inv

MCM-SU-update

mCMUpdate.inv

expiry of Timer T3

stop Timer T3 error indication to the Served User

YES

content of mCMUpdate.inv valid ?

indication to the Served User with the update information

error indication to the Served User

mCMUpdate.res

further mCMUpdate.inv will arrive ?

mCMUpdate.err

YES

start Timer T3

MCM-SU-update

MCM-SU- idle

Figure C.2.4 – SDL representation of SS-MCM update of Message Centre information at the Served User PINX

- 74 -

MCM-SU-idle

ServedUser request for update information

mCMUpdateReq.inv

start Timer T2

MCM-SU-wait

expiry of Timer T2

error indication to the Served User

mCMUpdateReq.err

mCMUpdateReq.res

stop Timer T2

error indication to the Served User

MCM-SU-idle

Update Request information to the Served User

MCM-SU-update

Figure C.2.5 – SDL representation of SS-MCM update request at the Served User PINX

- 75 -

MCM-SU- idle

mCMailboxFull.inv

Mailbox full indication to the Served User

MCM-SU- idle

Figure C.2.6 – SDL representation of SS-MCM Mailbox-full indication at the Served User PINX

- 76 -

C.3

SDL representation of SS-MID at the Message Centre PINX Figure C.3.1 and C.3.2 show the behaviour of an SS-MID Supplementary Service Control entity within the Message Centre PINX. Input signals from the left and output signals to the left represent primitives from and to the Message Centre or internal events (e.g. timer expiry events). Input signals from the right and output signals to the right represent primitives from and to Served User PINX.

- 77 -

MID-MC- idle

identification request from the Message Centre

mIDMailboxID.inv

start Timer T1

MID-MC-wait

expiry of Timer T1

error indication to the Message Centre

mIDMailboxID.res

mIDMailboxID.err

stop Timer T1

confirmation to the Message Centre

error indication to the Message Centre

MID-MC-idle

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

- 78 -

MID-MC- idle

mIDMailboxAuth.inv

YES

content of mIDMailboxAuth.inv valid ?

mIDMailboxAuth.res

mIDMailboxAuth.err

MID-MC-idle

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

- 79 -

C.4

SDL representation of SS-MID at the Served User PINX Figure C.4.1 and C.4.2 show the behaviour of an SS-MID Supplementary Service Control entity within the Served User PINX. Input signals from the right and output signals to the right represent primitives from and to the Served User or internal events (e.g. timer expiry events). Input signals from the left and output signals to the left represent primitives from and to the Message Centre PINX.

MID-SU- idle

mIDMailboxID.inv

YES

content of mIDMailboxID.inv valid ?

mIDMailboxID.res

mIDMailboxID.err

MID-SU-idle

Figure C.4.1 – SDL representation of SS-MID at the Served User PINX

- 80 -

MID-SU- idle

authentication request from the Served User

mIDMailboxAuth.inv

start Timer T2

MID-SU-wait

expiry of Timer T2

error indication to the Served User

mIDMailboxAuth.res

mIDMailboxAuth.err

stop Timer T2

authentication confirmation to the Served User

error indication to the Served User

MID-SU-idle

Figure C.4.2 – SDL representation of SS-MID at the Served User PINX

- 81 -

Annex D ( in f o r ma tiv e )

List of Message Types

The following types of messages may be supported by a Message Centre:

D.1

Telephony Type Messages

D.1.1

speech Messages for which the incoming call indicated a Bearer Capability / Information Transfer Capability set to „Speech“, as defined in ECMA-142.

D.1.2

unrestrictedDigitalInformation Messages for which the incoming call indicated a Bearer Capability / Information Transfer Capability set to „Unrestricted Digital Information“, as defined in ECMA-142.

D.1.3

audio3100Hz Message for which the incoming call indicated a Bearer Capability / Information Transfer Capability set to „3,1kHz audio (encoded)“, as defined in ECMA-142. No further indication about the type of message was available.

D.1.4

telephony Message for which the incoming call did not indicate any specific telephony Bearer Capability.

D.1.5 D.1.6

teletex telefaxGroup4Class1 Message for which the incoming call indicated Teleservice “Telefax Group 4”, as defined in ECMA-142.

D.1.7

videotextSyntaxBased Message for which the incoming call indicated Teleservice “Circuit-mode syntax-based videotext teleservice”, as defined in ECMA-142.

D.1.8 D.1.9

videotelephony telefaxGroup2-3 Message which was determined as a Telefax Group 2 or Telefax Group 3.

D.2

Data Type Messages The following message types are data network specific and require specific applications or equipment for retrieval, (e.g. email client or text to voice converter).

D.2.1 D.2.2 D.2.3 D.2.4

D.3

email video fileTransfer shortMessageService

Combination of Messages The following combination of messages shall be used for Message Centre Monitoring, to indicate that several messages of different Message Types are waiting. The item “speech” refers to Message Type “speech” as described in D.1.1.

- 82 -

The item “Video” refers to Message Type “videotelephony” as described in D.1.8. The item “Fax” refers to Message Type “telefaxGroup4Class1” as described in D.1.6. The item “Email” refers to Message Type “email” as described in D.2.1. ⇒ speechAndVideo ⇒ speechAndFax ⇒ speechAndEmail ⇒ videoAndFax ⇒ videoAndEmail ⇒ faxAndEmail ⇒ speechVideoAndFax ⇒ speechVideoAndEmail ⇒ speechFaxAndEmail ⇒ videoFaxAndEmail ⇒ speechVideoFaxAndEmail

D.4

Additional Message Types It is recommended, that the Message Types in this section are not used.

D.4.1

allServices This Message Type indicates, that messages of different types are waiting at the Message Centre.

D.4.2

multimediaUnknown A Data Type Message, which does not conform to one of the Message Types listed in D.2.

D.4.3

serviceUnknown No information about the type of message is available.

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-347 — Private Integrated Services Network (PISN) – Inter-exchange signalling protocol – Message Centre Monitoring and Mailbox Identification supplementary services (QSIG-MCM / QSIG-MID) (June 2003)

Related documents