Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-325 — Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Short message service (QSIG-SMS) (June 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational exchange integrated inter message network pisn

ecma, standard, ecma international, specification, ecma-325, ecma 325, 325, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, short, message, service, qsig-sms

S tandard ECMA-325

June 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) – Inter-Exchange Signalling Protocol – Short Message Service

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

S tandard ECMA-325

June 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) – Inter-Exchange Signalling Protocol – Short Message Service (QSIG-SMS)

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

ECMA-325.doc

04-09-02 09,38

Brief History

This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Digital Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as defined by ISO/ IEC. It has been produced under ETSI work item DTS/ECMA-00228. This particular Standard specifies the signalling protocol for use at the Q reference point in support of the Short Message Service. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). 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 is contributed to ISO/IEC JTC1 under terms of the fast-track procedure, for adoption as an ISO/IEC International Standard.

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

List of corrected errata for ECMA-325 25 Sep tember 2001

Summary Following is a summary of errors detected and corrected in Standard ECMA-325, Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Short Message Service.

Clause 6.3.1 Operations, table 1 •

Replace ambiguous tags (SmsExtension uses tags [1] and [2]). Original

SmsSubmitRes ::= SEQUENCE { serviceCentreTimeStamp ServiceCentreTimeStamp, protocolIdentifier [2] IMPLICIT ProtocolIdentifier userData [3] IMPLICIT UserData smsExtension SmsExtension

OPTIONAL, OPTIONAL, OPTIONAL}

Corrected SmsSubmitRes ::= SEQUENCE { serviceCentreTimeStamp ServiceCentreTimeStamp, protocolIdentifier [3] IMPLICIT ProtocolIdentifier userData [4] IMPLICIT UserData smsExtension SmsExtension

OPTIONAL, OPTIONAL, OPTIONAL}

Reason for change: SmsExtension is a CHOICE-structure which is implicitly tagged using already tags [1] and [2]. SmsExtension ::= CHOICE { single

[1] IMPLICIT Extension { { SmsExtSet } } ,

multiple

[2] IMPLICIT SEQUENCE OF Extension { { SmsExtSet } } }

Thus the context-specific tag [2] is used twice for optional elements. That introduces ambiguity for the types "ProtocolIdentifier" and "SEQUENCE OF Extension". The correction makes all types distinguishable.

•

Insert tags to remove ambiguity for the BOOLEANs.

•

NAME and PartyNumber use partly the same tags, due to Name OPTIONAL elements are not distinguishable prior to decoding of element status.

Original SmsStatusReportArg ::= SEQUENCE { messageReference MessageReference, serviceCentreTimeStamp ServiceCentreTimeStamp, dischargeTime DischargeTime, recipientAddress PartyNumber, recipientName Name destinationAddress PartyNumber, status Status, priority BOOLEAN DEFAULT FALSE, moreMessagesToSend BOOLEAN DEFAULT FALSE, statusReportQualifier BOOLEAN DEFAULT FALSE, protocolIdentifier ProtocolIdentifier userData UserData smsExtension SmsExtension

OPTIONAL,

OPTIONAL, OPTIONAL, OPTIONAL}

Corrected SmsStatusReportArg ::= SEQUENCE { messageReference MessageReference, serviceCentreTimeStamp ServiceCentreTimeStamp, dischargeTime DischargeTime, recipientAddress PartyNumber, recipientName [10] Name OPTIONAL, destinationAddress PartyNumber, status Status, priority [11] IMPLICIT BOOLEAN DEFAULT FALSE, moreMessagesToSend [12] IMPLICIT BOOLEAN DEFAULT FALSE, statusReportQualifier [13] IMPLICIT BOOLEAN DEFAULT FALSE, protocolIdentifier ProtocolIdentifier OPTIONAL, userData UserData OPTIONAL, smsExtension SmsExtension OPTIONAL} Reason for change: PartyNumber and Name are both implicitly tagged CHOICE-structures as shown in the table below. It shows that the contextspecific tags [0], [1] and [3] are used in both structures. Thus, if correspondingly tagged data is received at the decoder, it is not clear which of these elements is received prior to receipt of either a second context-specific tagged element, which then indicates "PartyNumber", or the tag for element "Status". Although no ambiguity is introduced, explicit tagging of the optional Name element helps in decoding of the received data. The three optional BOOLEAN elements need implicit tagging. If only one or two of them were received by the decoder, it is not clear which of the three elements is received.

PartyNumber ::= CHOICE {

Name ::= CHOICE {

unknownPartyNumber

[0] IMPLICIT NumberDigits,

namePresentationAllowed

NamePresentationAllowed,

publicPartyNumber

[1] IMPLICIT PublicPartyNumber,

namePresentationrestricted

NamePresentationRestricted,

dataPartyNumber

[3] IMPLICIT NumberDigits,

nameNotAvailable

NameNotAvailable}

telexPartyNumber

[4] IMPLICIT NumberDigits,

privatePartyNumber

[5] IMPLICIT PrivatePartyNumber,

nationalStandardPartyNumber [8] IMPLICIT NumberDigits}

NamePresentationAllowed ::= CHOICE { namePresentationAllowedSimple

[0] IMPLICIT NameData,

namePresentationAllowedExtended

[1] IMPLICIT NameSet}

NamePresentationRestricted ::= CHOICE {

•

namePresentationRestrictedSimple

[2] IMPLICIT NameData,

namePresentationRestrictedExtended

[3] IMPLICIT NameSet,

namePresentationRestrictedNull

[7] IMPLICIT NULL}

Insert tags to remove ambiguity (optional elements indistinguishable). Original

SmSubmitParameter ::= SEQUENCE protocolIdentifier validityPeriod statusReportRequest replyPath rejectDuplicates

{ ProtocolIdentifier, ValidityPeriod BOOLEAN DEFAULT FALSE, BOOLEAN DEFAULT FALSE, BOOLEAN DEFAULT FALSE}

OPTIONAL,

Corrected SmSubmitParameter ::= SEQUENCE protocolIdentifier validityPeriod statusReportRequest replyPath rejectDuplicates

{ ProtocolIdentifier, ValidityPeriod OPTIONAL, [11] IMPLICIT BOOLEAN DEFAULT FALSE, [12] IMPLICIT BOOLEAN DEFAULT FALSE, [13] IMPLICIT BOOLEAN DEFAULT FALSE}

Reason for change: see above.

•

Insert tags to remove ambiguity (optional elements indistinguishable). Original

SmDeliverParameter ::= SEQUENCE { protocolIdentifier serviceCentreTimeStamp priority moreMessagesToSend statusReportIndication replyPath

ProtocolIdentifier, ServiceCentreTimeStamp, BOOLEAN DEFAULT FALSE, BOOLEAN DEFAULT FALSE, BOOLEAN DEFAULT FALSE, BOOLEAN DEFAULT FALSE}

Corrected SmDeliverParameter ::= SEQUENCE { protocolIdentifier serviceCentreTimeStamp priority moreMessagesToSend statusReportIndication replyPath

ProtocolIdentifier, ServiceCentreTimeStamp, [11] IMPLICIT BOOLEAN DEFAULT FALSE, [12] IMPLICIT BOOLEAN DEFAULT FALSE, [13] IMPLICIT BOOLEAN DEFAULT FALSE, [14] IMPLICIT BOOLEAN DEFAULT FALSE}

Reason for change: see above.

•

Insert tags to remove ambiguity. Original

SmsDeliverResChoice ::= CHOICE{ null protocolIdentifier userData resChoiceSeq

NULL, ProtocolIdentifier, UserData, ResChoiceSeq}

ResChoiceSeq ::= SEQUENCE { protocolIdentifier userData

ProtocolIdentifier, UserData}

SmsStatusReportResponseChoice ::= CHOICE { null NULL, protocolIdentifier ProtocolIdentifier, userData UserData, resChoiceSeq ResChoiceSeq} Corrected SmsDeliverResChoice ::= CHOICE{ null protocolIdentifier userData resChoiceSeq

NULL, ProtocolIdentifier, [0] IMPLICIT UserData, [1] IMPLICIT ResChoiceSeq}

ResChoiceSeq ::= SEQUENCE { protocolIdentifier userData

ProtocolIdentifier, UserData}

SmsStatusReportResponseChoice ::= CHOICE { null NULL, protocolIdentifier ProtocolIdentifier, userData [0] IMPLICIT UserData, resChoiceSeq [1] IMPLICIT ResChoiceSeq} Reason for change: Elements UserData and ResChoiceSeq are both SEQUENCE-types. Thus implicit tagging of these types is required in order to make them distinguishable for a decoder.

List of corrected errata for ECMA-325 10 Ju ly 2002

Summary Following is a summary of errors detected and corrected in Standard ECMA-325, Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Short Message Service.

Clause 1 To clarify the scope of this Standard, a paragraph and the note are being added in clause 1. Corrected This service is based on GSM 03.40. The Service Centre functionality described in this Standard is equal to the functionality of a Service Centre in GSM 03.40. Thus, for interoperability with a GSM network, it is only necessary to implement a QSIG interface. NOTE 1 The interworking with other air interfaces is not precluded, but is outside the scope of this Standard.

Clause 6.3, table 1 In the Object Identifier associated to the module: Short-Message-Service-Operations-asn1-97, replace : ”icd-ecma(0012)” by “icd-ecma(12)”. Original {iso(1) identified-organization(3) icd-ecma(0012) standard(0) qsig-short-message-service(325) shortmessageservice-operations-asn1-97(1)} Corrected {iso(1) identified-organization(3) icd-ecma(12) standard(0) qsig-short-message-service(325) shortmessageservice-operations-asn1-97(1)}

- i -

Table of contents 1

Scope

Conformance

R eferences ( normat ive)

5 6

D ef in it io ns 4.1 Ex tern al d efin itions 4.2 O th er d ef in itions 4.2.1 R e c e iv in g U s er C a se 4.2.2 R e c e iv in g U s er P I N X 4.2 .3 Send ing U ser PINX 4.2 .4 Send ing U ser Messag e Cen tre 4.2 .5 Sho rt Me ssag e En tity 4.2.6 R e c e iv in g U s er Me ss age C en tr e A cro nym s S ig na lling P roto co l for th e su ppor t of SMS 6.1 SMS d escr ip tion 6.2 SMS op eration a l r equ iremen ts 6.2 .1 Provision /W ithdr awal 6.2 .2 Requ irements on a Sending U ser PINX 6.2 .3 Requ irements on a Sending U ser Message Cen tre 6.2 .4 Requ irements on a Service Cen tr e 6.2 .5 Requ irements on a Receiv ing U ser PINX 6.2 .6 Requ irements on a Receiv ing U ser Messag e Cen tr e 6.3 SMS coding r equ ir ements 6.3 .1 Op eration s 6.3 .2 Infor mation Elemen ts 6.3 .3 Messag es 6.4 SMS State def in itions 6.4 .1 States at th e Send ing User PINX and at th e Send ing U ser Messag e Cen tr e 6.4 .2 States at a Serv ice Centr e 6.4.3 S t a t es a t a R e c e iv in g U s er P I N X 6.4.4 S t a t es a t a R e c e iv in g U s er Me ss age C en tr e 6.5 SMS sign alling pro c edur es 6.5 .1 A c tions at a Send ing User PINX / Send ing U ser Messag e Cen tr e 6.5 .2 A c tions at a Send ing User Messag e Cen tre 6.5 .3 A c tions at a Serv ice Cen tr e 6.5 .4 A c tions at a Receiv ing U ser PINX 6.5 .5 A c tions at a Receiv ing U ser Me ssag e Cen tre 6.6 SMS imp act on in terwo rk ing w ith pub lic ISDN s 6.7 SMS imp act on in terwo rk ing w ith non-I SDNs

2 2 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5 5 11 11 11 11 12 12 12 13 13 15 15 19 21 22 22

- ii -

6.8 Proto co l In te raction s betw een SMS and supp leme n tar y serv ices and ANFs 6.8 .1 Calling Line Id en tif ication Presen tation ( SS- CLI P) 6.8 .2 Connected Lin e Iden tification Pr esen ta tion (SS- COLP) 6.8 .3 Calling / Conn ected Line Id en tif ication Restr iction ( SS- CLIR) 6.8 .4 Calling Name Id en tif ication Pr esentation (SS-CNIP) 6.8 .5 Calling / Conn ected N ame Id en tif ication Re str iction (SS- CNI R) 6.8 .6 Connected N a me Id en tif ication Pr esen tation ( SS-CON P) 6.8 .7 Co mp letion of Calls to Busy Sub scrib er ( SS- CCBS) 6.8 .8 Co mp letion of Calls on No Rep ly ( SS-CCN R) 6.8 .9 Call Tr an sfer ( CT) 6.8 .10 Call Forw ard ing Un cond ition al (SS- CFU ) 6.8 .11 Call Forw ard ing Bu sy (SS- CF B) 6.8 .12 Call Forw ard ing No Rep ly ( SS- CFN R) 6.8 .13 Call Def lection ( SS- CD) 6.8 .14 Path Rep lacemen t (ANF- PR) 6.8 .15 Call Off er (SS- CO) 6.8 .16 Call In tru s ion ( SS- CI ) 6.8 .17 Do No t D isturb (SS-DND) 6.8 .18 Do No t D isturb Overr ide (SS-DNDO) 6.8 .19 Adv ice of ch arge (SS-AO C) 6.8.20 Recall (SS-RE) 6.8 .21 Call In tercep tion (AN F-CINT) 6.8 .22 Tran sit Coun ter (AN F-TC) 6.8 .23 Rou te Re striction Class ( ANF- RRC) 6.8 .24 Messag e W aiting Ind ication ( SS- MW I) 6.8 .25 W ir e le ss Ter min al Location Reg istration (SS-WTLR) 6.8 .26 Wirele ss Termin al Mob ility In co ming Call (SS-WTMI ) 6.8 .27 Wirele ss Termin al Mob ility Ou tgo ing Call (SS-WTMO) 6.8 .28 Au th en tication of a W TM u ser (SS-W TAT) 6.8 .29 Au th en tication of the PI SN (SS-WTA N) 6.8 .30 Priv ate User Mob ility In co ming Call (ANF-PUMI) 6.8 .31 Priv ate User Mob ility Ou tgo ing Ca ll (ANF-PUMO) 6.8 .32 Priv ate User Mob ility Reg istration (SS-PUMR) 6.8 .33 Co mmo n Infor mation (ANF-CMN) 6.8 .34 Call Pr ior ity In terrup tion ( Pro tection) (SS-CPI( P)) 6.8 .35 Sing le Step Call Tr an sfer ( SS- SSCT ) 6.8 .36 Simp le D ialog ( SS- SD) 6.8 .37 Call Id entification and Call Link age (AN F- CIDL) 6.9 SS-SMS Parame ter values (Timer s) 6.9 .1 Time r T1 6.9 .2 Time r T2 6.9 .3 Time r T3 6.9 .4 Time r T4 6.9 .5 Time r T5 6.9 .6 Time r T6 6.9 .7 Time r T7

22 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 25 25 25 25 25 25 25 25

- iii -

An nex A - P roto co l Imp lementation Confo rma nce Statement (P ICS ) P rofo rma

Annex B - Examples of message sequences

An nex C - S pecif icat ion and Descript ion Lang ua g e ( S D L ) r ep re se n t a t io n o f p ro ce d u re s

Annex D - Mapping of QSIG-PDUs on GSM-PD Us

An nex E - D es cript ion of APDU element s

- iv -

Scope This Standard specifies the signalling protocol for the support of the Short Message Service (SMS) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). This service is based on GSM 03.40. The Service Centre functionality described in this Standard is equal to the functionality of a Service Centre in GSM 03.40. Thus, for interoperability with a GSM network, it is only necessary to implement a QSIG interface. NOTE 1 The interworking with other air interfaces is not precluded, but is outside the scope of this Standard. NOTE 2 The Short Message Service is a special type of basic service but is described in the present document as a supplementary service. The Short Message Service is a service which permits a served user to send a message of limited size to another user in the same PISN or another network. 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-324. The signalling protocol for SMS operates on top of the signalling protocol for the connection oriented call independent APDU transport mechanism and uses certain further 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 SMS and supplementary services and ANFs. This Standard is applicable to PINXs which can be interconnected to form a PISN.

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.

References (normative) The following standards contain provisions which, through references 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-143

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

ECMA-164

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Name Identification Supplementary Services (International Standard ISO/IEC 13868)

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

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

ECMA-324

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Short Message Service

ISO/IEC 10646-1

Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane

ISO 8601

Data elements and interchange formats - Information interchange - Representation of dates and times

GSM 03.38

Digital cellular telecommunications systems (Phase 2+); Alphabets and languagespecific information

ETSI TS 100 901

Digital cellular telecommunications systems (Phase 2+); Technical realisation of the Short Message Service (SMS) (GSM 03.40)

GSM 03.42

Digital cellular telecommunications systems (Phase 2+); Compression algorithm for text messaging services

GSM 04.11

Digital cellular telecommunications systems (Phase 2+); Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface

GSM 09.02

Digital cellular telecommunications systems (Phase 2+); Mobile Application Part (MAP) specification

ETS 300 387

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

ITU-T Rec. I.112

Vocabulary of terms for ISDNs (1993)

ITU-T Rec. I.210

Principles of telecommunication services supported by an ISDN and the means to describe them (1993)

ITU-T Rec. Z.100

Specification and description language (1999)

Definitions For the purpose of this Standard the following definitions apply.

4.1

External definitions This Standard uses the following terms defined in other documents: –

Application Protocol Data Unit (APDU)

(ECMA-165)

–

Call, Basic Call

(ECMA-165)

–

Call Independent Signalling Connection

(ECMA-165)

–

Command

(ECMA-324)

–

End PINX

(ECMA-165)

–

Message Centre

(ECMA-324)

–

Message Centre Case

(ECMA-324)

–

Private Integrated services Network eXchange (PINX)

(ECMA-133)

–

Private Integrated Services Network (PISN)

(ECMA-133)

–

Receiving User

(ECMA-324)

–

Sending User

(ECMA-324)

–

Service Centre

(ECMA-324)

–

Short Message

(ECMA-324)

- 3 -

4.2

–

Short Message Waiting Data

(ECMA-324)

–

Status Report

(ECMA-324)

–

Signalling

(ITU-T Rec. I.112)

–

Supplementary Service

(ITU-T Rec. I.210)

–

Terminal Case

(ECMA-324)

Other definitions

4.2.1

R ec e iv in g U se r C a se The configuration when the Terminal Case is provided for the Receiving User, i.e. no Receiving User Message Centre is involved in the SMS procedures.

4.2.2

R ec e iv in g U se r PINX The Receiving User PINX is the PINX serving the Receiving User.

4 .2 .3

S en d ing U se r P INX The Sending User PINX is the PINX serving the Sending User.

4 .2 .4

S en d ing U se r M e ssag e C ent re The Message Centre serving the Sending User.

4.2 .5

Short Messag e Ent ity A generic term for an entity that is capable of handling one or more SMS specific procedures. This can be either the Sending Users terminal, the Sending User PINX, the Sending User Message Centre, the Service Centre, the Receiving User Message Centre, the Receiving User PINX or the Receiving Users terminal.

4.2 .6

R eceiv ing U ser M essag e C ent re The Message Centre serving the Receiving User.

Acronyms APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation One

GSM

Global System for Mobile communication

ISDN

Integrated Services Digital Network

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

SIM

Subscriber Identity Module

Short Message

SMS

Short Message Service

SMSC

Short Message Service Centre

SMWD

Short Message Waiting Data

Supplementary Service

Terminal Equipment

UDH

User Data Header

- 4 -

Signalling Protocol for the support of SMS

6.1

SMS description Short Message Service is a service which is offered to a user in a PISN and which enables the user to send and receive Short Messages to and from another user in a PISN or in another (e.g. GSM) network. The PISN transfers the Short Message from the Sending User to an SC and from the SC to the Receiving User.

6.2

SMS operational requirements

6.2 .1

Prov ision/Wit hdra wal Provision and withdrawal shall be in accordance with 6.2.1 of ECMA-324.

6.2 .2

R equirements o n a Sending U s er PINX Generic procedures for the 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 .3

R equirements o n a Sending U s er M essage Centre Generic procedures for the 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 .4

R equ ir em en ts o n a Ser v ic e C ent re Generic procedures for the 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 .5

R equirements o n a R eceiv ing User PINX Generic procedures for the 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 .6

R equirements o n a R eceiv ing Us er M es sage C ent re Generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating-PINX and for a Terminating-PINX, shall apply.

- 5 -

6.3 6.3 .1

SMS coding requirements Operat ions The following operations defined in Abstract Syntax Notation One (ASN.1) in table 1 shall apply. Table 1 - Operations in Support of SMS

Short-Message-Service-Operations-asn1-97 {iso(1) identified-organization(3) icd-ecma(12) standard(0) qsig-short-message-service(325) short-message-serviceoperations-asn1-97(1)} DEFINITIONS::= BEGIN IMPORTS OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t (2) remote-operations(4) informationObjects(5) version1(0)} EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 {iso(1) standard(0) pss1-generic-procedures(11582) msi-class-asn1-97(11)} Name FROM Name-Operations-asn1-97 {iso(1) standard(0) pss1-name(13868) name-operations-asn1-97(1)} supplementaryServiceInteractionNotAllowed FROM General-Error-List {ccitt recommendation q 950 general-error-list(1)} PartyNumber FROM Addressing-Data-Elements-asn1-97 {iso(1) standard(0) pss1-generic-procedures(11582) addressing-data-elements-asn1-97(20)}; --TYPE DEFINITIONS FOR SMS OPERATIONS FOLLOW Sms-Operations OPERATION ::={ smsSubmit | smsDeliver | smsStatusReport | smsCommand | scAlert} smsSubmit

OPERATION ::= { -- sent from the Sending User PINX/ Sending User Message Centre to the Service Centre ARGUMENT SmsSubmitArg RESULT SmsSubmitRes ERRORS {smsSubmitError | unspecified} CODE local:107}

smsDeliver

OPERATION ::= { -- sent from the Service Centre to the Receiving User PINX or to the Receiving User Message Centre ARGUMENT SmsDeliverArg RESULT SmsDeliverRes ERRORS {smsDeliverError | unspecified} CODE local:108}

- 6 -

Table 1 - Operations in Support of SMS (continued) smsStatusReport OPERATION ::= { -- sent from the Service Centre to the Sending User PINX or to the Sending User Message Centre ARGUMENT SmsStatusReportArg RESULT SmsStatusReportRes ERRORS {smsStatusReportError | unspecified} CODE local:109} smsCommand OPERATION ::= { -- sent from the Sending User PINX or the Sending User Message Centre to the Service Centre ARGUMENT SmsCommandArg RESULT SmsCommandRes ERRORS {smsCommandError | unspecified} CODE local:110} scAlert

OPERATION ::= { -- sent from the Receiving User PINX or the Receiving User Message Centre to the Service Centre ARGUMENT ScAlertArg RESULT DummyRes ERRORS {unspecified} CODE local:111}

--TYPE DEFINITIONS FOR SMS DATA TYPES FOLLOW SmsSubmitArg ::= SEQUENCE destinationAddress originatingAddress messageReference smSubmitParameter userData smsExtension

{ PartyNumber, PartyNumber, MessageReference, SmSubmitParameter, UserData, SmsExtension

SmsSubmitRes ::= SEQUENCE { serviceCentreTimeStamp ServiceCentreTimeStamp, protocolIdentifier [3] IMPLICIT ProtocolIdentifier userData [4] IMPLICIT UserData smsExtension SmsExtension SmsDeliverArg ::= SEQUENCE originatingAddress destinationAddress originatingName smDeliverParameter userData smsExtension

{ PartyNumber, PartyNumber, Name SmDeliverParameter, UserData, SmsExtension

SmsDeliverRes ::= SEQUENCE { smsDeliverResponseChoice smsExtension

SmsDeliverResChoice, SmsExtension

OPTIONAL}

OPTIONAL, OPTIONAL, OPTIONAL}

OPTIONAL, OPTIONAL}

OPTIONAL}

- 7 -

Table 1 - Operations in Support of SMS (continued) SmsStatusReportArg ::= SEQUENCE { messageReference MessageReference, serviceCentreTimeStamp ServiceCentreTimeStamp, dischargeTime DischargeTime, recipientAddress PartyNumber, recipientName [10] Name destinationAddress PartyNumber, status Status, priority [11] IMPLICIT BOOLEAN DEFAULT FALSE, moreMessagesToSend [12] IMPLICIT BOOLEAN DEFAULT FALSE, statusReportQualifier [13] IMPLICIT BOOLEAN DEFAULT FALSE, protocolIdentifier ProtocolIdentifier userData UserData smsExtension SmsExtension

OPTIONAL, OPTIONAL, OPTIONAL}

SmsStatusReportRes ::= SEQUENCE { smsStatusReportResponseChoice smsExtension

SmsStatusReportResponseChoice, SmsExtension

OPTIONAL}

SmsCommandArg ::= SEQUENCE destinationAddress messageReference messageNumber protocolIdentifier commandType commandData statusReportRequest smsExtension

PartyNumber, MessageReference, MessageReference, ProtocolIdentifier, CommandType, CommandData BOOLEAN SmsExtension

OPTIONAL, OPTIONAL, OPTIONAL}

SmsCommandRes ::= SEQUENCE { serviceCentreTimeStamp protocolIdentifier userData smsExtension

ServiceCentreTimeStamp, ProtocolIdentifier UserData SmsExtension

OPTIONAL, OPTIONAL, OPTIONAL}

ScAlertArg ::= SEQUENCE originatingAddress smsExtension

PartyNumber, SmsExtension

OPTIONAL}

OPTIONAL,

{

DummyRes ::= CHOICE{ null smsExtension

NULL, SmsExtension}

SmSubmitParameter ::= SEQUENCE protocolIdentifier validityPeriod statusReportRequest replyPath rejectDuplicates

{ ProtocolIdentifier, ValidityPeriod [11] IMPLICIT BOOLEAN DEFAULT FALSE, [12] IMPLICIT BOOLEAN DEFAULT FALSE, [13] IMPLICIT BOOLEAN DEFAULT FALSE}

OPTIONAL,

- 8 -

Table 1 - Operations in Support of SMS (continued) SmDeliverParameter ::= SEQUENCE { protocolIdentifier ProtocolIdentifier, serviceCentreTimeStamp ServiceCentreTimeStamp, priority [11] IMPLICIT BOOLEAN DEFAULT FALSE, moreMessagesToSend [12] IMPLICIT BOOLEAN DEFAULT FALSE, statusReportIndication [13] IMPLICIT BOOLEAN DEFAULT FALSE, replyPath [14] IMPLICIT BOOLEAN DEFAULT FALSE} SmsDeliverResChoice ::= CHOICE null protocolIdentifier userData resChoiceSeq

{ NULL, ProtocolIdentifier, [0] IMPLICIT UserData, [1] IMPLICIT ResChoiceSeq}

ResChoiceSeq ::= SEQUENCE { protocolIdentifier userData

ProtocolIdentifier, UserData}

SmsStatusReportResponseChoice ::= CHOICE { null NULL, protocolIdentifier ProtocolIdentifier, userData [0] IMPLICIT UserData, resChoiceSeq [1] IMPLICIT ResChoiceSeq} MessageReference ::= INTEGER(0..255) SmsExtension ::= CHOICE{ single multiple

[1]IMPLICIT Extension{{SmsExtSet}}, [2]IMPLICIT SEQUENCE OF Extension{{SmsExtSet}}

} SmsExtSet EXTENSION ::= {...} ProtocolIdentifier ::= INTEGER (0..127) -- definition of the ProtocolIdentifier values and default value can be found in annex E section -- E.1.2.1 ServiceCentreTimeStamp

::= GeneralizedTime(SIZE(12..19)) -- this date and time representation follows ISO 8601

DischargeTime

::= GeneralizedTime(SIZE(12..19)) -- this date and time representation follows ISO 8601

ValidityPeriod ::= CHOICE{ validityPeriodRel [0] IMPLICIT ValidityPeriodRel, validityPeriodAbs [1] IMPLICIT ValidityPeriodAbs, validityPeriodEnh [2] IMPLICIT ValidityPeriodEnh} ValidityPeriodAbs

::= GeneralizedTime(SIZE(12..19)) -- this date and time representation follows ISO 8601

ValidityPeriodRel ::= INTEGER(0..255) -- the rules for the encoding of ValidityPeriodRel are shown in annex E section E.1.2.2

- 9 -

Table 1 - Operations in Support of SMS (continued) ValidityPeriodEnh ::= SEQUENCE{ singleShotSM enhancedVP

BOOLEAN DEFAULT FALSE, EnhancedVP

EnhancedVP ::= CHOICE{ validityPeriodRel validityPeriodSec validityPeriodSemi

[0] IMPLICIT ValidityPeriodRel, [1] IMPLICIT INTEGER(0..255), [2] IMPLICIT ValidityPeriodSemi}

OPTIONAL}

ValidityPeriodSemi ::= OCTET STRING (SIZE(3)) -- Validity Period is relative in semi-octet representation, see ETSI TS 100 901, section 9.1.2.3 -- and section 9.2.3.12.3 UserData ::= SEQUENCE{ userDataHeader class compressed shortMessageText

[0] IMPLICIT UserDataHeader [1] IMPLICIT INTEGER (0..3) [2] IMPLICIT BOOLEAN DEFAULT FALSE, ShortMessageText}

OPTIONAL, OPTIONAL,

ShortMessageText ::= shortMessageTextType shortMessageTextData

SEQUENCE{ ShortMessageTextType, ShortMessageTextData}

ShortMessageTextType ::=

INTEGER{ iA5Coded (0), -- ShortMessageTextData shall contain data according to octetCoded (1), -- the type given in ShortMessageTextType, for further uniCoded (2), -- details see annex E. 1.3.4. compressedCoded (3)} (0..8)

ShortMessageTextData ::= OCTET STRING (SIZE(0..140)) Status ::=

INTEGER (0..255) -- definition of status values can be found in section E.7.6 in annex E

CommandType ::= INTEGER{ enquiry cancelSRR deletePreviouslySubmittedSM enableSRRrelatingToPreviouslySubmittedSM

(0), (1), (2), (3)} (0..255)

CommandData ::= OCTET STRING (SIZE(0..157)) FailureCause ::= INTEGER (0..255) -- definition for failureCause values can be found in section E.3.1 in annex E UserDataHeader ::=

SEQUENCE OF UserDataHeaderChoice

UserDataHeaderChoice ::= CHOICE{ smscControlParameterHeader concatenated8BitSMHeader concatenated16BitSMHeader applicationPort8BitHeader applicationPort16BitHeader dataHeaderSourceIndicator wirelessControlHeader genericUserValue

[0] IMPLICIT SmscControlParameterHeader, [1] IMPLICIT Concatenated8BitSMHeader, [2] IMPLICIT Concatenated16BitSMHeader, [3] IMPLICIT ApplicationPort8BitHeader, [4] IMPLICIT ApplicationPort16BitHeader, [5] IMPLICIT DataHeaderSourceIndicator, [6] IMPLICIT WirelessControlHeader, [99] IMPLICIT GenericUserValue}

- 10 -

Table 1 - Operations in Support of SMS (continued) SmscControlParameterHeader ::= BIT STRING { sRforTransactionCompleted (0), sRforPermanentError (1), sRforTempErrorSCnotTrying (2), sRforTempErrorSCstillTrying (3), cancelSRRforConcatenatedSM (6), includeOrigUDHintoSR (7)} (SIZE(8)) Concatenated8BitSMHeader ::= SEQUENCE{ concatenated8BitSMReferenceNumber maximumNumberOf8BitSMInConcatenatedSM sequenceNumberOf8BitSM

INTEGER(0..255), INTEGER(0..255), INTEGER(0..255)}

Concatenated16BitSMHeader ::= SEQUENCE{ concatenated16BitSMReferenceNumber maximumNumberOf16BitSMInConcatenatedSM sequenceNumberOf16BitSM

INTEGER(0..65536), INTEGER(0..255), INTEGER(0..255)}

ApplicationPort8BitHeader ::= destination8BitPort originator8BitPort

SEQUENCE{ INTEGER(0..255), INTEGER(0..255)}

ApplicationPort16BitHeader ::= destination16BitPort originator16BitPort

SEQUENCE{ INTEGER(0..65536), INTEGER(0..65536)}

DataHeaderSourceIndicator ::= INTEGER{ originalSender (1), originalReceiver (2), sMSC (3)}(0..255) WirelessControlHeader ::=

-- valid in case of Status Report -- valid in case of Status Report -- can occur in any message or report

OCTET STRING

GenericUserValue ::= SEQUENCE{ parameterValue INTEGER(0..255), genericUserData OCTET STRING} smsDeliverError

smsSubmitError

ERROR ::= { PARAMETER SEQUENCE{ failureCause protocolIdentifier userData scAddressSaved CODE local:1026} ERROR ::= { PARAMETER SEQUENCE{ failureCause serviceCentreTimeStamp protocolIdentifier userData CODE local:1027}

FailureCause, [0] IMPLICIT ProtocolIdentifier OPTIONAL, [1] IMPLICIT UserData OPTIONAL, [2] IMPLICIT BOOLEAN DEFAULT FALSE}

FailureCause, ServiceCentreTimeStamp, [0] IMPLICIT ProtocolIdentifier [1] IMPLICIT UserData

OPTIONAL, OPTIONAL}

- 11 -

Table 1 - Operations in Support of SMS (concluded) smsStatusReportError ERROR ::= { PARAMETER SEQUENCE{ failureCause protocolIdentifier userData scAddressSaved CODE local: 1028} smsCommandError

unspecified

FailureCause, [0] IMPLICIT ProtocolIdentifier OPTIONAL, [1] IMPLICIT UserData OPTIONAL, [2] IMPLICIT BOOLEAN DEFAULT FALSE}

ERROR ::= { PARAMETER SEQUENCE{ failureCause FailureCause, serviceCentreTimeStamp ServiceCentreTimeStamp, protocolIdentifier [0] IMPLICIT ProtocolIdentifier userData [1] IMPLICIT UserData CODE local:1029} ERROR ::= { PARAMETER CODE

OPTIONAL, OPTIONAL}

SmsExtension local: 1008}

END -- of Short-Message-Service-Operations-asn1-97 6.3 .2 Info rmat ion Elements 6.3 .2.1 Fa cility info rmat io n element The operations defined in 6.3.1 for the support of SMS shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of the operations defined in 6.3.1 the destinationEntity data element of the NFE shall contain value endPINX. The Interpretation APDU in the Facility information element shall be omitted or have the value “rejectAnyUnrecognizedInvokeAPDU (0)”. 6.3 .2.2 6.3 .3

6.4

Ot he r info rma t ion e lem en ts Any other information elements shall be coded in accordance with ECMA-143. M essages The Facility information element shall be conveyed in messages as specified in clause 10 of ECMA-165.

SMS State definitions

6.4 .1

States at the Sending U ser PINX and at the Sending U ser Messag e C ent re The procedures at the Sending User PINX/ Sending User Message Centre are written in terms of the following conceptual states existing within the SMS control entity in that Sending User PINX/ Sending User Message Centre in association with a particular request from the Sending User.

6.4 .1.1

SM S-Send-Idle SMS is not operating.

6.4 .1.2

SM S-Send-Submit-Wait An smsSubmit invoke APDU has been sent to the Service Centre. The Sending User PINX/Sending User Message Centre is waiting for a response.

6.4 .1.3

SM S-Send-Co mmand-Wa it The Sending User-PINX/Sending User Message Centre has received a command request from the Sending User, has sent an smsCommand invoke APDU to the Service Centre and is waiting for receipt of an smsCommand return result, return error or reject APDU.

- 12 -

6.4 .2

States at a Serv ic e C entre The procedures at the Service Centre are written in terms of the following conceptual states existing within the SMS control entity in that Service Centre.

6.4 .2.1 States fo r Sho rt M e ssag e Tra nsf er 6.4 .2.1.1 SM S-SC- Idle SMS is not operating. 6.4 .2.1.2

SM S-SC-D eliv er- Wa it The Service Centre has sent an smsDeliver invoke APDU to the Receiving User PINX and is waiting for receipt of an smsDeliver return result, return error or reject APDU.

6.4 .2.1.3

SM S-SC-Awa it-A lert The Service Centre has received an smsDeliver return error APDU with failureCause “memoryCapacityExceeded” or “simSmsStorageFull” or with an additional Cause Information Element and is now waiting for receipt of an scAlert invoke APDU from the Receiving User PINX.

6.4 .2.2

States fo r Stat us Report Transf er The following states exist in parallel and independently of other states in the Service Centre, if the procedures for Status Report are supported.

6.4 .2.2.1

SM S-SC- SR- Wait The Service Centre has sent an smsStatusReport invoke APDU to the Sending User PINX/Sending User Message Centre and is waiting for receipt of an smsStatusReport return result, return error or reject APDU.

6.4 .2.2.2

SM S-SC- SR- Idle The Service Centre is waiting for an internal request to send a Status Report.

6.4 .3

States at a R eceiv ing U ser PINX The procedures at the Receiving User PINX are written in terms of the following conceptual states existing within the SMS control entity in that PINX.

6.4 .3.1

SM S-R ec-User- case-Idle SMS is not operating.

6.4 .3.2

SM S-R ec-User- case-A lert Wa it The Receiving User PINX unsuccessfully attempted to deliver a Short Message to a terminal and is waiting for an internal indication that the Receiving User is available again for further smsDeliver invoke APDUs.

6.4 .3.3

SM S-R ec-User- case-A lertR esp The Receiving User PINX has sent an scAlert invoke APDU to the Service Centre and is now waiting for receipt of an scAlert return result, return error or reject APDU from the Service Centre.

6.4 .3.4

SM S-R ec-MC- case- Idle The Receiving User PINX is waiting to forward received APDUs from the Service to the Receiving User Message Centre and vice versa. This state is maintained as long as SMS is provided in the Message Centre Case to the Receiving User.

6.4 .4

States at a R eceiv ing U ser M essag e C ent re The procedures at the Sending User Message Centre are written in terms of the following conceptual states existing within the SMS control entity in that Message Centre.

6.4 .4.1

SM S-R ec-MC- Idle SMS is not operating.

6.4 .4.2

SM S-R ec-MC-A lertWa it The Message Centre has unsuccessfully attempted to save a Short Message, has sent an smsDeliver return error APDU to the Receiving User PINX and is waiting for an internal indication that memory is available again.

- 13 -

6.4 .4.3

6.5

SM S-R ec-MC-A lertResp The Message Centre has sent an scAlert invoke APDU to the Receiving User PINX and is waiting for receipt of an scAlert return result, return error or reject APDU from the Receiving User PINX.

SMS signalling procedures References in this clause to protocol states refer to protocol states defined in section 7.3 of ECMA-165. The APDU elements refered to in the following subclauses are described in annex E.

6.5 .1

A ct ions at a Sending U ser PINX / Send ing Us er M es sage C ent re All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call Independent Signalling Connections (CISC). Therefore the Sending User PINX/Sending User Message Centre shall set up a call independent signalling connection in accordance with the procedures described in 7.3 in ECMA-165. The Sending User PINX/Sending User Message Centre is responsible for the clearing of this call independent signalling connection.

6.5 .1.1 No rma l procedures 6.5 .1.1.1 Short Messag e In state SMS-Send-Idle upon request of the Sending User to send a Short Message the Sending User PINX/ Sending User Message Centre shall 1) check if the Sending User is permitted to use the SMS; if so 2) generate an smsSubmit invoke APDU, based on the Short Message elements received from the Sending User, which shall include the following mandatory elements: -

the PartyNumber of the Receiving User in element destinationAddress,

the PartyNumber of the Sending User in element originating Address,

a Message Reference in element messageReference which is allocated by the Sending User PINX/Sending User Message Centre for each new Short Message or Command that is sent (see annex E for further details),

Short Message specific parameters in element smsSubmitParameters (see annex E for further details),

the Short Message Text and related information in element userData (see annex E for further details),

3) send the smsSubmit invoke APDU to the Service Centre; 4) start timer T1 and enter state SMS-Send-Submit-Wait. On receipt in state SMS-Send-Submit-Wait of an smsSubmit return result APDU the Sending User PINX shall 1) stop timer T1; 2) send an indication to the Sending User that the submission of the Short Message was successful and 3) enter state SMS-Send-Idle. 6.5 .1.1.2

Co mmand On request in state SMS-Send-Idle of the Sending User to send a Command the Sending User PINX/ Sending User Message Centre shall 1) check if the Sending User is permitted to use the SMS, if so 2) generate an smsCommand invoke APDU based on the Command information received from the Sending User, which shall include the following elements: -

the PartyNumber of the Receiving User of the Short Message to which the Command refers in element destinationAddress,

- 14 -

the Message Reference of the Short Message to which the Command refers in element messageNumber,

the Protocol Identifier identifying the higher layer protocol in element protocolIdentifier (see annex E for further details),

the Command Type in element commandType (see annex E for further details),

optional elements as described in annex E;

3) send the smsCommand invoke APDU to the Service Centre; 4) start timer T2 and enter state SMS-Send-Command-Wait. On receipt in state SMS-Send-Command-Wait of an smsCommand return result APDU the Sending User PINX/ Sending User Message Centre shall 1) stop timer T2; 2) send an indication to the Sending User that the submission of the Command was successful and 3) enter state SMS-Send-Idle. 6.5 .1.1.3

Status R epo rt On receipt in state SMS-Send-Idle of an smsStatusReport invoke APDU the Sending User PINX/ Sending User Message Centre shall 1) indicate the content of the received smsStatusReport invoke APDU to the Sending User; 2) send an smsStatusReport return result APDU (see annex E) to the Service Centre and 3) enter state SMS-Send-Idle.

6.5 .1.2

Except ional pro c edures In state SMS-Send-Idle upon a request from the Sending User to submit a Short Message or a Command, the Sending User PINX/Sending User Message Centre shall return an error indication to the Sending User if 1) the Sending User is not permitted to use the SMS; 2) the smsSubmit/smsCommand elements are incorrect or if mandatory elements are missing.

6.5 .1.2.1

Short Messag e On receipt in state SMS-Send-Submit-Wait of an smsSubmit reject or return error APDU the Sending User PINX/ Sending User Message Centre shall 1) stop timer T1; 2) send an indication including the error reason to the Sending User and 3) enter state SMS-Send-Idle. On expiry of timer T1 in state SMS-Send-Submit-Wait the Sending User PINX/ Sending User Message Centre shall either -

re-send the smsSubmit invoke ADPU, start timer T1 and re-enter state SMS-Send-Submit-Wait or

send an indication including the error reason to the Sending User and enter state SMS-SendIdle.

NOTE 3 The number of times the Sending User PINX may repeat the smsSubmit is an implementation matter.

- 15 -

6.5 .1.2.2

Co mmand On receipt in state SMS-Send-Command-Wait of an smsCommand reject or return error APDU the Sending User PINX/ Sending User Message Centre shall 1) stop timer T2; 2) send an indication including the error reason to the Sending User and 3) enter state SMS-Send-Idle. On expiry of timer T2 in state SMS-Send-Command-Wait the Sending User PINX/ Sending User Message Centre shall either -

re-send the smsCommand invoke APDU, start timer T2 and re-enter state SMS-SendCommand-Wait or

send an indication including the error reason to the Sending User and enter state SMS-SendIdle.

NOTE 4 The number of times the Sending User PINX may repeat the smsCommand is an implementation matter. 6.5 .1.2.3

Status R epo rt On receipt in state SMS-Send-Idle of an smsStatusReport invoke APDU the Sending User PINX/ Sending User Message Centre shall in case of an error send an smsStatusReport return error APDU with an appropriate error indication in element failureCause, to the Service Centre and enter state SMS-Send-Idle. Elements of the smsStatusReport error APDU and specific error reasons and related failureCause values are described in annex E.

6.5 .2

A ct ions at a Sending U ser M essag e C ent re The procedures for the Sending User Message Centre are as described in 6.5.1.

6.5 .3

A ct ions at a Serv ice Cent re All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call Independent Signalling Connections (CISC).Therefore the Service Centre shall set up a call independent signalling connection in accordance with the procedures described in 7.3 in ECMA-165. The Service Centre is responsible for the clearing of this call independent signalling connection.

6.5 .3.1 No rma l procedures 6.5 .3.1.1 Short Messag e On receipt in state SMS-SC-Idle of an smsSubmit invoke APDU from the Sending User PINX/Sending User Message Centre the Service Centre shall check if the received smsSubmit invoke APDU contains a Short Message with the same messageReference and destinationAddress as a previously received Short Message from the same originatingAddress. In case such a Short Message exists and the rejectDuplicates APDU element is set to FALSE or in case that the messageReference is different to the messageReference of the previously received Short Message the Service Centre shall 1) check the APDU element protocolIdentifier and -

if it is set to “replaceShortMessage” check the originatingAddress and replace any existing stored Short Message having the same Protocol Identifier Code and originatingAddress with the new Short Message and other parameter values. If there is no message to be replaced the Service Centre shall store the Short Message in the normal way;

if no “replaceShortMessage” code is present the Service Centre shall store the Short Message locally;

2) analyse and store the smsSubmit invoke APDU; 3) set the internal value StatusReportRequest according to the statusReportRequest element and the smscControlParameterHeader as received in the smsSubmit invoke APDU; if the smscControlParameterHeader was not received it shall be assumed that all values of this element are set to TRUE (i.e. a Status Report is requested for all conditions);

- 16 -

4) assign and store a serviceCentreTimeStamp and the priority (see annex E) for the Short Message; 5) send an smsSubmit return result APDU to the Sending User PINX/Sending User Message Centre with the following elements (see annex E for further details): -

serviceCentreTimeStamp,

further optional elements as described in annex E;

6) send an smsDeliver invoke APDU to the Receiving User PINX containing the received elements from the smsSubmit invoke ADPU and the following additional elements (see annex E for further details): -

optionally, the originatingName of the Sending User if available and not restricted,

serviceCentreTimeStamp as designed by the Service Centre,

priority as assigned by the Service Centre,

moreMessagesToSend: set to TRUE if there are more Short Messages waiting in that Service Centre for that particular destinationAddress,

statusReportIndication: set to TRUE if the statusReportRequest information element was set to TRUE in the original smsSubmit invoke APDU,

replyPath: set to TRUE if the Service Centre supports the Reply Path functionality;

7) start timer T3 and enter state SMS-SC-Deliver-Wait. On receipt in state SMS-SC-Deliver-Wait of an smsDeliver return result APDU the Service Centre shall 1) stop timer T3; 2) generate an internal request to send a Status Report with value “smReceivedBySME” if the internal StatusReportRequest field is set for this condition and 3) enter state SMS-SC-Idle. 6.5 .3.1.2

Co mmand On receipt in any state except SMS-SC-Idle of an smsCommand invoke APDU the Service Centre shall 1) identify a specific locally stored Short Message by the received smsCommand invoke APDU elements -

originatingAddress,

messageNumber, containing the messageReference of the stored Short Message;

2) execute the requested commandType on this message, i.e. for commandType -

“Enquiry” generate an internal request to send a Status Report, regardless of the setting of the internal StatusReportRequest field;

“CancelSRR” set the internal field StatusReportRequest to FALSE for all conditions;

“EnableSRRrelatingToPreviouslySubmittedSM” set the internal field StatusReportRequest to TRUE for all conditions;

“DeletePreviouslySubmittedSM” delete the identified Short Message and generate an internal request to send a Status Report with value “smDeletedByOriginatingSME” if the internal StatusReportRequest field is set for this condition;

3) afterwards, send an smsCommand return result APDU to the Sending User PINX/Sending User Message Centre and re-enter the current state.

- 17 -

6.5 .3.1.3

Status-Repo rt NOTE 5 The Status Report-related procedures within the Service Centre are independent of those for the normal Short Message. In state SMS-SC-SR-Idle on an internal request to send a Status Report for a specific Short Message the Service Centre shall send an smsStatusReport invoke APDU to the Sending User PINX/Sending User Message Centre using the following smsStatusReport APDU elements: -

messageReference: value contained in the previously received smsSubmit or smsCommand invoke APDU. If the Status Report is the result of an smsCommand where commandType was “Enquiry” the messageReference used in the Status Report shall be the messageNumber contained in the smsCommand invoke APDU (i.e. the messageReference of the previously submitted Short Message to which the “Enquiry” refers).

dischargeTime: time at which a previously submitted smsSubmit invoke APDU was successfully delivered to or attempted to deliver to the Receiving User or disposed of by the SC,

serviceCentreTimeStamp: the serviceCentreTimeStamp assigned to the original smsSubmit invoke APDU,

and other elements as described in 6.3.1, start timer T5 and enter state SMS-SC-SR-Wait. On receipt in state SMS-SC-SR-Wait of an smsStatusReport return result APDU from the Sending User PINX/Sending User Message Centre the Service Centre shall stop timer T5 and enter state SMS-SC-SR-Idle. 6.5 .3.2 Except ional pro c edures 6.5 .3.2.1 Short Messag e For a general description of all possible error values and their usage refer to annex E. On receipt in state SMS-SC-Idle of an smsSubmit invoke APDU from the Sending User PINX/Sending User Message Centre and this APDU contains -

either element rejectDuplicates set to TRUE and messageReference and destinationAddress of a previously received Short Message from the same originatingAddress;

or element messageReference that is identical to the messageReference of a previously received Short Message from the same Sending User, but indicates a different destinationAddress;

the Service Centre shall send an smsSubmit return error APDU to the Sending User PINX/Sending User Message Centre with failureCause “smRejectedDuplicateSM”, discard the smsSubmit invoke APDU and enter state SMS-SC-Idle. If element protocolIdentifier of the received smsSubmit invoke APDU indicates a specific interworking and if interworking is not supported by the Service Centre it shall return an smsSubmit return error APDU with failureCause “telematicInterworkingNotSupported” and enter state SMS-SC-Idle. On receipt in state SMS-SC-Deliver-Wait of an smsDeliver return error APDU from the Receiving User PINX the Service Centre shall check the APDU element failureCause. If it contains the value “memoryCapacityExceeded” or “simSmsStorageFull” or if an additional Cause Information Element has been received, the Service Centre shall 1) stop timer T3; 2) generate an internal request to send a Status Report with value “errorInSme” if the internal StatusReportRequest field is set for this condition; 3) start timer T4 if the smsDeliver return error APDU element scAddressSaved is set to FALSE (i.e. the Receiving User PINX will not send an scAlert invoke APDU if the smsDeliver invoke APDU can be re-sent) and 4) enter state SMS-SC-Await-Alert.

- 18 -

If a different failureCause was received, the Service Centre shall 1) stop timer T3; 2) delete the Short Message; 3) generate an internal request to send a Status Report with an appropriate value if the internal StatusReportRequest field is set for this condition and 4) enter state SMS-SC-Idle. On receipt in state SMS-SC-Deliver-Wait of an smsDeliver reject APDU the Service Centre shall 1) stop timer T3; 2) delete the Short Message; 3) generate an internal request to send a Status Report with value “connectionRejectedBySME” if the internal StatusReportRequest field is set for this condition and 4) enter state SMS-SC-Idle. On expiry of timer T3 in state SMS-SC-Deliver-Wait the Service Centre may -

either re-send the smsDeliver invoke APDU to the Receiving User PINX, start timer T3, generate an internal request to send a Status Report with value “noResponseFromSME” if the internal StatusReportRequest field is set for this condition and re-enter state SMS-SC-DeliverWait or

delete the Short Message, generate an internal request to send a Status Report with value “smDeletedByScAdministration” if the internal StatusReportRequest field is set for this condition and enter state SMS-SC-Idle.

On receipt in state SMS-SC-Await-Alert of an scAlert invoke APDU from the Receiving User PINX the Service Centre shall stop timer T4 if running, check the scAlert invoke APDU and depending on the outcome send an scAlert return result or return error APDU to the Receiving User PINX. If the scAlert is valid the SC shall 1) send the smsDeliver invoke APDU to the Receiving User PINX of the user whose number was contained in the scAlert invoke APDU; 2) start timer T3 and 3) enter state SMS-SC-Deliver-Wait. On expiry of timer T4 in state SMS-SC-Await-Alert the Service Centre shall 1) send the smsDeliver invoke APDU to the Receiving User PINX; 2) start timer T3 and 3) enter state SMS-SC-Deliver-Wait. NOTE 6 The number of times the Service Centre may repeat the delivery attempt for a Short Message depends on the duration of timer T4 and the Validity Period for this Short Message. If no Validity Period was indicated by the Sending User, an SC-specific default value will be assumed. On receipt in state SMS-SC-Await-Alert of an internal indication that the Validity Period for a Short Message expired the Service Centre shall stop timer T4 if running and shall either -

once again re-send the smsDeliver invoke APDU to the Receiving User PINX with priority set to TRUE, start Timer T3 and enter state SMS-SC-Deliver-Wait or

delete the Short Message, generate an internal request to send a Status Report with value “smValidityPeriodExpired” if the internal StatusReportRequest field is set for this condition and enter state SMS-SC-Idle.

On receipt in state SMS-SC-Deliver-Wait of an smsDeliver return error or return reject APDU for a Short Message for which the Validity Period has already expired, the Service Centre shall stop Timer T3 and generate an internal request to send a Status Report with value

- 19 -

“smValidityPeriodExpired” if the internal StatusReportRequest field is set for this condition and enter state SMS-SC-Idle. 6.5 .3.2.2

Co mmand On receipt in any state of an smsCommand invoke APDU, if no Short Message can be identified, the Service Centre shall 1) return an smsCommand return error APDU to the Sending User PINX/Sending User Message Centre with failureCause “commandCannotBeActioned”; 2) generate an internal request to send a Status Report with value “smDoesNotExist” if the internal StatusReportRequest field is set for this condition and 3) re-enter the current state.

6.5 .3.2.3

6.5 .4

Status R epo rt On receipt in state SMS-SC-SR-Wait of an smsStatusReport return error APDU or an smsStatusReport reject APDU or on expiry of timer T5 the Service Centre shall stop timer T5 (if running) and enter the SMS-SC-SR-Idle and may afterwards re-send the smsStatusReport invoke APDU according to the procedures described in section 6.5.3.1.1.

A ct ions at a R e ceiv ing U s er PINX All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call Independent Signalling Connections (CISC). Therefore the Receiving User PINX shall set up a call independent signalling connection in accordance with the procedures described in 7.3 in ECMA-165. The Receiving User PINX is responsible for the clearing of this call independent signalling connection. Due to internal administration, the Receiving User PINX shall, upon starting operation for a specific user, either

6.5 .4.1

enter state SM-Rec-MC-case-Idle if the Short Messages are stored and managed at the Receiving User Message Centre or

enter state SM-Rec-User-case-Idle if the Short Messages are stored and managed locally, either by the Receiving Users terminal equipment or by the Receiving User PINX. No rma l procedures In state SM-Rec-MC-case-Idle upon receipt of an smsDeliver return result, reject, return error APDU or an scAlert invoke APDU from the Receiving User Message Centre the Receiving User PINX shall send these APDUs to the Service Centre. In state SM-Rec-MC-case Idle upon receipt of an smsDeliver invoke APDU, an scAlert return result, return error or reject APDU the Receiving User PINX shall send these APDUs to the Receiving User Message Centre. On receipt in state SMS-Rec-User-case-Idle of an smsDeliver invoke APDU from the Service Centre the Receiving User PINX shall attempt to deliver the SM to the Receiving User. If the SM can successfully be delivered the Receiving User PINX shall send an smsDeliver return result APDU to the Service Centre and enter state SMS-Rec-User-case-Idle.

6.5 .4.2

Except ional pro c edures In state SMS-Rec-User-case-Idle, if element protocolIdentifier of the received smsDeliver invoke APDU is set to “shortMessageType0” the Receiving User PINX shall send an smsDeliver return result APDU to the Service Centre but may discard its contents due to internal configuration or restrictions of the Receiving Users terminal equipment. If the attempt by the Receiving User PINX to deliver a Short Message received from the Service Centre to the Receiving User is not successful, the Receiving User PINX shall -

if SMWD is not implemented, 1) send to the Service Centre an smsDeliver return error APDU with the following elements -

failureCause set to “memoryCapacityExceeded” or “simSmsStorageFull”,

optionally protocolIdentifier as received in the original smsDeliver invoke APDU,

- 20 -

optionally userData as received in the original smsDeliver invoke APDU,

scAddressSaved set to FALSE and

2) enter state SMS-Rec-User-case-Idle. -

if SMWD is implemented 1) save the Service Centre Address as indicated in the CallingPartyNumber Information Element of the call-independent-signalling-connection on which the smsDeliver invoke APDU was received, if not saved already; 2) send to the Service Centre an smsDeliver return error APDU with the following elements -

failureCause set to “memoryCapacityExceeded” or “simSmsStorageFull”,

optionally protocolIdentifier as received in the smsDeliver invoke APDU,

optionally userData as received in the smsDeliver invoke APDU,

scAddressSaved set to TRUE and

3) enter state SMS-Rec-User-case-AlertWait. On receipt in state SMS-Rec-User-case-AlertWait of an internal indication that the user is reachable or that the user has memory available again the Receiving User PINX shall send an scAlert invoke APDU to all Service Centres which are stored in the SMWD, start timer T6 and enter state SMS-RecUser-case-AlertResp for each of the sent scAlert invoke APDUs. On receipt in state SMS-Rec-User-case-AlertWait of an smsDeliver invoke APDU with element priority set to TRUE the Receiving User PINX shall attempt to deliver the SM to the Receiving User. If the SM can be delivered the Receiving User PINX shall 1) return an smsDeliver return result APDU to the Service Centre as described in section 6.5.4.1; 2) send an scAlert invoke APDU with element originatingAddress set to the Party Number of the Receiving User for all Service Centres that are contained in the SMWD to the Service Centres; 3) start timer T6 and enter state SMS-Rec-User-case-Alert-Resp. If the SM can not be delivered then, if the SC Address is not yet stored in SMWD, the SC Address as indicated in the CallingPartyNumber Information element of the call-independent-signallingconnection shall be saved in SMWD and the Receiving User PINX shall send an smsDeliver return error APDU to the Service Centre with scAddressSaved set to TRUE (see above). On receipt in state SMS-Rec-User-case-AlertWait of an smsDeliver invoke APDU the Receiving User PINX shall, 1) if the SC Address is not saved already in SMWD, save it there; 2) return an smsDeliver return error APDU to the Service Centre with scAddressSaved set to TRUE (see above) and 3) re-enter state SMS-Rec-User-case-AlertWait. On receipt in state SMS-Rec-User-case-AlertResp of an scAlert return result APDU the Receiving User PINX shall delete the address of the SC from the SMWD, stop timer T6 and enter state SMSRec-User-case-Idle. On receipt in state SMS-Rec-User-case-AlertResp of an scAlert return error or reject APDU or upon expiry of timer T6, the Receiving User PINX shall stop timer T6 (if running) and shall -

either delete the address of the SC from the SMWD and enter state SMS-Rec-User-case-Idle

or re-send the scAlert invoke APDU to the Service Centre, start timer T6 and re-enter state SMSRec-User-case-AlertResp.

On receipt in state SMS-Rec-User-case-AlertResp of an smsDeliver invoke APDU from the SC, the Receiving User PINX shall treat this APDU as described in section 6.5.4.1 but shall not enter state

- 21 -

SMS-Rec-User-case-Idle but re-enter SMS-Rec-User-case-AlertResp instead. Timer T6 shall not be stopped in this case. NOTE 7 The number of times the Receiving User PINX may repeat the scAlert is an implementation matter. 6.5 .5

6.5 .5.1

A ct ions at a R e ceiv ing U s er M e ssag e C ent re All invoke, return error, return result and reject APDUs shall be transported using the Call Reference of Call Independent Signalling Connections (CISC). Therefore the Receiving User Message Centre shall set up a call independent signalling connection in accordance with the procedures described in 7.3 in ECMA-165. The Receiving User Message Centre is responsible for the clearing of this call independent signalling connection. No rma l procedures On receipt in state SMS-Rec-MC-Idle of an smsDeliver invoke APDU from the Receiving User PINX the Receiving User Message Centre shall check the APDU element protocolIdentifier. If it is set to -

“shortMessageType0” the Receiving User Message Centre shall perform the procedures as described for this case in section 6.5.4.2.

“replaceShortMessage” the Receiving User Message Centre shall perform the procedures as described for the “replaceShortMessage” value in the protocolIdentifier in section 6.5.3.2.

If the Short Message is saved the Receiving User Message Centre shall send an smsDeliver return result APDU to the Sending User PINX, indicate the reception of a new Short Message to the Receiving User using SS-MWI and enter state SMS-Rec-MC-Idle. 6.5 .5.2

Except ional pro c edures In state SMS-Rec-MC-Idle, if element protocolIdentifier of the received smsDeliver invoke APDU is set to “shortMessageType0” the Receiving User Message Centre shall send an smsDeliver return result APDU to the Receiving User PINX but may discard its contents due to internal configuration or restrictions of the Receiving User Message Centre. On receipt in state SMS-Rec-MC-Idle of an smsDeliver invoke APDU from the Receiving User PINX if it is not possible for the Receiving User Message Centre to save the SM it shall, -

if SMWD is implemented, 1) save the Service Centre address as indicated in the CallingPartyNumber Information element of the call-independent-signalling-connection on which the smsDeliver invoke APDU was received, if not saved already; 2) send an smsDeliver return error APDU to the Service Centre with the following elements -

failureCause “memoryCapacityExceeded”,

optionally protocolIdentifier as received in the original smsDeliver invoke APDU,

optionally userData as received in the original smsDeliver invoke APDU,

scAddressStored set to TRUE and

3) enter state SMS-Rec-MC-AlertWait. -

if SMWD is not implemented 1) send an smsDeliver return error APDU to the Receiving User PINX with the following elements -

failureCause set to “memoryCapacityExceeded”,

optionally protocolIdentifier as received in the original smsDeliver invoke APDU,

optionally userData as received in the original smsDeliver invoke APDU,

scAddressStored set to FALSE and

2) enter state SMS-Rec-MC-Idle.

- 22 -

On receipt in state SMS-Rec-MC-AlertWait of an internal indication that the user is reachable or that the user has memory available again the Receiving User Message Centre shall send an scAlert invoke APDU to all Service Centres which are stored in the SMWD, start timer T7 and enter state SMS-RecMC-AlertResp for each of the sent scAlert invoke APDUs. On receipt in state SMS-Rec-MC-AlertWait of an smsDeliver invoke APDU with element priority set to TRUE the Receiving User Message Centre shall attempt to save the SM, following the procedures described in 6.5.5.1. If the SM can be saved the Receiving User Message Centre shall 1) return an smsDeliver return result APDU to the Receiving User PINX as described in section 6.5.5.1; 2) send an scAlert invoke APDU to the Receiving User PINX with element originatingAddress set to the Party Number of the Receiving User for all Service Centres which are stored in the SMWD; 3) start timer T7 and enter state SMS-Rec-MC-AlertResp. If the SM can not be saved then, if the SC Address is not yet stored in SMWD, the SC address as indicated in the CallingPartyNumber Information element of the call-independent-signallingconnection shall be saved in SMWD, the Receiving User Message Centre shall send an smsDeliver return error APDU to the Receiving User PINX with scAddressStored set to TRUE and enter state SMS-Rec-MC-AlertWait. On receipt in state SMS-Rec-MC-AlertWait of an smsDeliver invoke APDU the Receiving User Message Centre shall 1) if the SC Address is not saved already in SMWD save it there; 2) return an smsDeliver return error APDU with failureCause “memoryCapacityExceeded” and with scAddressStored set to TRUE to the Receiving User PINX and 3) re-enter state SMS-Rec-MC-AlertWait. On receipt in state SMS-Rec-MC-AlertResp of an scAlert return result APDU or upon expiry of timer T7 the Receiving User Message Centre shall stop timer T7 (if running), delete the SC Address from the SMWD field and enter state SMS-Rec-MC-Idle. On receipt in state SMS-Rec-MC-AlertResp of an scAlert return error or reject APDU the Receiving User Message Centre shall stop timer T7 (if running) and shall -

either delete the address of the SC from the SMWD and enter state SMS-Rec-MC-Idle

or re-send the scAlert invoke APDU to the Service Centre, start timer T7 and re-enter state SMSRec-MC-AlertResp.

On receipt in state SMS-Rec-MC-AlertResp of an smsDeliver invoke APDU from the Receiving User PINX the Receiving User Message Centre shall treat this APDU as described in section 6.5.5.1 but shall not enter state SMS-Rec-MC-Idle but re-enter SMS-Rec-MC-AlertResp instead. Timer T7 shall not be stopped in this case. NOTE 8 The number of times the Receiving User Message Centre may repeat the scAlert is an implementation matter.

6.6

SMS impact on interworking with public ISDNs NOTE 9 The interworking with the GSM network is described in annex D.

6.7

SMS impact on interworking with non-ISDNs Not applicable.

6.8

Protocol Interactions between SMS and supplementary services and ANFs This clause specifies protocol interactions with 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.

- 23 -

NOTE 10 Simultaneous conveyance of APDUs for SMS and 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. NOTE 11 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specification. 6.8 .1

Ca l l ing L i ne I de nt if i cat ion P r es entat io n (S S-C LI P) No protocol interaction.

6.8 .2

Con ne ct ed L i n e Id ent if i cat ion P re s entat io n (S S-CO LP ) No protocol interaction.

6.8 .3

Ca l l ing / Con ne ct ed L in e Id ent if i cat ion Re st ric t ion (SS-C LIR ) No protocol interaction.

6.8 .4

Ca lling Name Ident if icat io n P re se n t a t io n ( S S - C N I P) No protocol interaction.

6.8 .5

Ca l l ing / Con ne ct ed Nam e Id ent i f ic at ion R e str i ct io n ( SS-CN IR) No protocol interaction.

6.8 .6

Con ne ct ed Na me Id en tif i cat ion P re s entat io n (S S-CON P) No protocol interaction.

6.8 .7

Co mple t ion of Ca lls to Busy Subscriber (SS-CC BS) No protocol interaction.

6.8 .8

Co mplet ion of Ca lls on No Reply (SS-CCNR) No protocol interaction.

6.8 .9

Ca ll Transfer (C T) No protocol interaction.

6.8 .10

Ca ll Forwarding Uncondit iona l (SS-CFU ) No protocol interaction.

6.8 .11

Ca ll Forwarding Busy ( SS-C FB) No protocol interaction.

6.8 .12

Ca ll Forwarding No Reply ( SS-CFN R) No protocol interaction.

6.8 .13

Ca ll D ef lect ion (SS-CD) No protocol interaction.

6.8 .14

Pa th R eplacement (ANF-PR) No protocol interaction.

6.8 .15

Ca ll Off er ( SS-CO) No protocol interaction.

6.8 .16

Ca ll Int rusion (SS-CI) No protocol interaction.

6.8 .17

Do No t D isturb (SS-DND) No protocol interaction.

6.8 .18

Do No t D isturb Ov erride ( SS-DNDO) No protocol interaction.

- 24 -

6.8 .19

Adv ic e of cha rg e (S S-AOC ) No protocol interaction.

6.8 .20

R eca ll (SS-R E) No protocol interaction.

6.8 .21

Ca ll Int e rcept ion (ANF-CIN T) No protocol interaction.

6.8 .22

Tra nsit Count er (ANF- TC) No protocol interaction.

6.8 .23

Route Restrict io n C lass (ANF-RRC) No protocol interaction.

6.8 .24

M essage Wa it ing Indicat ion (SS-MWI) The Receiving User Message Centre shall, upon receipt and storage of an smsDeliver invoke APDU, send an mwiActivate invoke APDU with element basicService set to “shortMessageService” to the Receiving User PINX.

6.8 .25

Wireless Termina l Locat ion Reg ist rat ion (SS-WTLR) No protocol interaction.

6.8 .26

Wireless Termina l Mobility Incoming Ca ll (SS-WTMI) No protocol interaction.

6.8 .27

Wireless Termina l Mobility Outgo ing Ca ll (SS-WTMO) No protocol interaction.

6.8 .28

Authent icat ion of a WTM user (SS-WTA T) No protocol interaction.

6.8 .29

Authent icat ion of t he PISN (SS-WTAN) No protocol interaction.

6.8 .30

Privat e U ser Mobility Incoming Ca ll (AN F- PUM I) No protocol interaction.

6.8 .31

Privat e U ser Mobility Outgo ing Ca ll (AN F- PUMO) No protocol interaction.

6.8 .32

Privat e U ser Mobility R eg ist rat ion (SS-PUMR) No protocol interaction.

6.8 .33

Co mmon Info rmat io n (AN F-CMN) No protocol interaction.

6.8 .34

Ca ll Pr io r ity Int e rr uption (P rot ect ion ) ( SS-CP I( P)) No protocol interaction.

6.8 .35

Sing le St ep Ca ll Transf er (SS-SSC T) No protocol interaction.

6.8 .36

Simple D ia log ( SS- SD) No protocol interaction.

6.8 .37

Ca ll Ident ificat ion a nd Ca ll Linkag e (AN F-CID L) No protocol interaction.

- 25 -

6.9 6.9 .1

SS-SMS Parameter values (Timers) Timer T1 Timer T1 shall operate at the Sending User PINX during state SMS-Send-Submit-Wait. Its purpose is to protect against an absence of response to smsSubmit invoke APDU. Timer T1 shall have a value in the range of 4 to 6 seconds.

6.9 .2

Timer T2 Timer T2 shall operate at the Sending User PINX during state SMS-Send-Command-Wait. Its purpose is to protect against an absence of response to smsCommand invoke APDU. Timer T2 shall have a value in the range of 4 to 6 seconds.

6.9 .3

Timer T3 Timer T3 shall operate at the Service Centre during state SMS-SC-Deliver-Wait. Its purpose is to protect against absence of response to smsDeliver invoke APDU. Timer T3 shall have a value in the range of 4 to 6 seconds.

6.9 .4

Timer T4 Timer T4 may operate optionally at the Service Centre, if Short Message Waiting Data is not implemented, during state SMS-SC-Await-Alert. Its purpose is to ensure the automatic repetition of the delivery attempt of a Short Message. Timer T4 shall have an implementation dependent value.

6.9 .5

Timer T5 Timer T5 shall operate at the Service Centre during state SMS-SC-SR-Wait. Its purpose is to protect against absence of response to smsStatusReport invoke APDU. Timer T5 shall have a value in the range of 4 to 6 seconds.

6.9 .6

Timer T6 Timer T6 shall operate at the Receiving User PINX during state SMS-Rec-User-case-AlertResp. Its purpose is to protect against an absence of response to scAlert invoke APDU. Timer T6 shall have a value in the range of 4 to 6 seconds.

6.9 .7

Timer T7 Timer T7 shall operate at the Receiving User Message Centre during state SMS-Rec-MC-AlertResp. Its purpose is to protect against absence of response to scAlert invoke APDU. Timer T7 shall have a value in the range of 4 to 6 seconds.

- 26 -

- 27 -

Annex A (nor 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 Protocol Implementation Conformance Statement (PICS) proforma in A.3. 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 a 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 PICS proforma;

by user (or potential user) of the implementation, as a basis for initially checking the possibility of interworking with another implementation (note that, while interworking cannot be guaranteed, failure to interwork can often be predicted from incompatible PICS);

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

- 28 -

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

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

- 29 -

A.3

PICS Proforma for ECMA-325

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

- 30 -

A.3.3

Short Message Service

Item

Name of Item

Reference

Status

N/A

Support

Support of SMS in Sending User PINX

o.1

Yes [ ] No [ ]

Support of SMS in Sending Message Centre

o.1

Yes [ ] No [ ]

Support of SMS in Service Centre

o.1

Yes [ ] No [ ]

Support of SMS in Receiving User PINX

o.1

Yes [ ] No [ ]

Support of SMS in Receiving Message Centre

o.1

Yes [ ] No [ ]

A.3.4

Procedures for SMS

Item

Name of Item

Reference

Status

N/A

Support

Procedures at the Sending User PINX

6.5.1

A1:m

[]

Yes [ ]

Procedures at the Sending Message Centre

6.5.1

A2:m

[]

Yes [ ]

Procedures at the Service Centre

6.5.3

A3:m

[]

Yes [ ]

Procedures at the Receiving User PINX

6.5.4

A4:m

[]

Yes [ ]

Procedures at the Receiving Message Centre

6.5.5

A5:m

[]

Yes [ ]

Procedures for Status Report

6.5

c.1

[]

Yes[ ] No[ ]

Procedures for Reply Path

6.5

c.2

[]

Yes[ ] No[ ]

Procedures for Short Message Waiting Data

6.5

c.2

[]

Yes[ ] No[ ]

Procedures for Concatenated Short Message

6.5

[]

Yes[ ] No[ ]

B.10

Procedures for Validity Period

6.5

c.1

[]

Yes[ ] No[ ]

c.1:

If B1 or B2 or B3 then o else N/A

c.2:

If B3 or B4 or B5 then o else N/A

- 31 -

A.3.5

Coding

Item

Name of Item

Reference

Status

N/A

Sending of smsSubmit invoke APDU and receipt of return result and return error APDUs

6.5.1

c.3

[]

Yes [ ]

Sending of smsCommand invoke APDU and receipt of return result and return error APDUs

6.5.1

c.3

[]

Yes [ ]

Receipt of smsStatusReport invoke APDU and sending of return result and return error APDUs

6.5.1

B.6:m

[]

Yes [ ]

Sending of smsStatusReport invoke APDU and receipt of return result and return error APDUs

6.5.3

B.6:m

[]

Yes [ ]

Receipt of smsSubmit invoke APDU and sending of return result and return error APDUs

6.5.3

B.3:m

[]

Yes [ ]

Receipt of smsCommand invoke APDU and sending of return result and return error APDUs

6.5.3

B.3:m

[]

Yes [ ]

Sending of smsDeliver invoke APDU and receipt of return result and return error APDUs

6.5.3

B.3:m

[]

Yes [ ]

Receipt of scAlert invoke APDU and sending of return result and return error APDUs

6.5.3

B.8:m

[]

Yes [ ]

Sending of scAlert invoke APDU and receipt of return result and return error APDUs

6.5.4, 6.5.5

B.8:m

[]

Yes [ ]

C10

Receipt of smsDeliver invoke APDU and sending of return result and return error APDUs

6.5.4, 6.5.5

c.4

[]

Yes [ ]

C11

Coding of Short Message Text as an IA5String

Annex E

Yes [ ]

C12

Coding of Short Message Text as an Octet String

Annex E

Yes [ ] No [ ]

C13

Coding of Short Message Text as an BMPString

Annex E

Yes [ ] No [ ]

C14

Coding of Short Message Text as Compressed Coded

Annex E

Yes [ ] No [ ]

C15

Coding of Validity Period in relative format

Annex E

B10: o.2

[]

Yes [ ] No [ ]

C16

Coding of Validity Period in absolute format

Annex E

B10: o.2

[]

Yes [ ] No [ ]

C17

Coding of Validity Period in enhanced format

Annex E

B10: o.2

[]

Yes [ ] No [ ]

c.3:

If B1 or B2 then m else N/A

c.4

If B4 or B5 then m else N/A

Support

- 32 -

A.3.6 Item

Timers Name of Item

Reference

Status

N/A

Support

Support of Timer T1

6.9.1

Yes [ ]

Support of Timer T2

6.9.2

Yes [ ]

Support of Timer T3

6.9.3

Yes [ ]

Support of Timer T4

6.9.4

Yes [ ]

Support of Timer T5

6.9.5

Yes [ ]

Support of Timer T6

6.9.6

B.8:m

Yes [ ]

Support of Timer T7

6.9.7

Yes [ ]

- 33 -

Annex B (informative)

Examples of message sequences

This annex describes some typical message flows for SMS. the following conventions are used in the figures of this annex: 1

Protocol message (call-independent) Service primitive to/ from user xxx.inv

Invoke APDU for operation xxx

xxx.rr

Return result APDU for operation xxx

xxx.re

Return error APDU for operation xxx

The figures show messages exchanged via Protocol Control between PINXs involved in SMS. Only messages relevant to SMS are show.

Only the relevant information content (i.e. remote operation APDUs) is listed below each message name. The Facility information elements containing remote operation APDUs are not explicitly shown. Information with no impact on SMS is not shown.

- 34 -

B.1

Example message sequence for submission of a Short Message Sending User PINX

Sending User

Receiving User

Service Centre

Receiving User

PINX

smsSubmit request

SETUP smsSubmit.inv Call Proceeding

CONNECT smsSubmit

smsSubmit.rr

result

RELEASE RELEASE

SETUP smsDeliver.inv Call Proceeding

COMPLETE CONNECT smsDeliver.rr

smsDeliver indication

RELEASE RELEASE COMPLETE

Figure B.1 – Message sequence for submission of a Short Message

- 35 -

Sending User

Service Centre

Receiving User

PINX

Message Centre

smsSubmit request from User A

SETUP smsSubmit.inv Call Proceeding

CONNECT smsSubmit

smsSubmit.rr

result to User A

RELEASE

SETUP SETUP

smsDeliver.inv

smsDeliver.inv RELEASE COMPLETE

Call Proceeding Call Proceeding CONNECT CONNECT

smsDeliver.rr

smsDeliver.rr RELEASE

RELEASE RELEASE

RELEASE

COMPLETE

Figure B.2 – Message sequence for submission of a Short Message

- 36 -

B.2

Example message sequence for the submission of a Command Sending User PINX

Sending User

Service Centre

Receiving User PINX

smsCommand request

SETUP smsCommand.inv Call Proceeding

CONNECT smsCommand

smsCommand.rr

result

RELEASE RELEASE COMPLETE

Figure B.3 – Message sequence for submission of a Command

Receiving User

- 37 -

Sending User

Service Centre

Message Centre

smsCommand request from User A

Receiving User

PINX

Message Centre

SETUP smsCommand.inv Call Proceeding

CONNECT smsCommand

smsCommand.r

result to User A

RELEASE RELEASE COMPLETE

Figure B.4 – Message sequence for submission of a Command

- 38 -

B.3

Message sequence for submission of a Status Report Sending User PINX

Sending User

Service Centre

Receiving User PINX

SETUP smsStatusReport.inv Call Proceeding

CONNECT smsStatusReport

smsStatusReport.rr

result

RELEASE RELEASE COMPLETE

Figure B.5 – Message sequence for submission of a Status Report

Receiving User

- 39 -

Sending User

Service Centre

Message Centre

Receiving User

PINX

Message Centre

SETUP smsStatusReport.inv Call Proceeding

CONNECT smsStatusReport

smsStatusReport.rr

result to User A

RELEASE RELEASE COMPLETE

Figure B.6 – Message sequence for submission of a Status Report

- 40 -

B.4

Message sequence for submission of ScAlert

Sending User

Sending User PINX

Receiving User

Service Centre

PINX

SETUP scAlert.inv Call Proceeding CONNECT scAlert.rr RELEASE RELEASE COMPLETE

Figure B.7 – Message sequence for submission of ScAlert

Receiving User

- 41 -

Sending User

Service Centre

Receiving User

PINX

Message Centre

SETUP scAlert.inv SETUP scAlert.inv Call Proceeding Call Proceeding CONNECT scAlert.rr

CONNECT scAlert.rr RELEASE

RELEASE RELEASE COMPLETE

RELEASE COMPLETE

Figure B.8 – Message sequence for submission of an ScAlert

- 42 -

- 43 -

Annex C ( infor ma tive)

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. Each diagram represents the behaviour of an SMS 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 Transport Control and Basic Call Protocol. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a PSS1 message being sent, the output symbol bears the name of the message and any remote operation APDU(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the sending of that message are deemed to occur. Where an input symbol represents a primitive from the Coordination Function and that primitive results from a PSS1 message being received, the input symbol bears the name of the message and any remote operation APDU(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the receiving of that message are deemed to occur. The following abbreviations are used: .re

return error APDU

.ind

indication

.inv

invoke APDU

opt.

optional

.rej

reject APDU

.rr

return result APDU

- 44 -

C.1

SDL Representation of SS-SMS at the Sending User PINX Figure C.1 shows the behaviour of an SMS Supplementary Service Control entity within the Sending User PINX, -

Input signals from the left represent messages received from the Sending User.

Output signals to the right represent primitives to the Service Centre. SMS-SendIdle

Short Message from User

Sending User permitted? Yes

SmsSubmit.inv

Command from User

Error Indication to Sending User

Start Timer T1

SMS-SendSubmit-wait

Sending User permitted? Yes

SmsCommand.inv

Start Timer T2

SMS-SendIdle

SMS-SendCommand-wait

SmsStatusReport inv

Status Report o.k.? Yes

pos. Result to User

neg. Result to User

SmsStatusReport.rr

SmsStatusReport.re

SMS-SendIdle

Figure C.1 - Sending User PINX SDL (sheet 1 of 3)

- 45 -

SMS-SendCommand-wait

SmsCommand.rr

SmsCommand.re

Stop Timer T2

SmsCommand.rej

Timer T2 expiry

re-send?

pos. Result to User

Yes

neg. Result to User

SMS-SendIdle

Figure C.1 - Sending User PINX SDL (sheet 2 of 3) SMS-SendSubmit-wait

SmsSubmit.rr

SmsSubmit.re

Stop Timer T1

SmsSubmit.rej

Timer T1 expiry

re-send?

pos. Result to User

neg. Result to User

SMS-SendIdle

Figure C.1 - Sending User PINX SDL (sheet 3 of 3)

- 46 -

C.2

SDL Representation of SS-SMS at the Sending Message Centre The SDL diagrams representing the behaviour of the Sending Message Centre are equal to those for the Sending User PINX, see section C.1 in annex C.

C.3

SDL Representation of SS-SMS at the Service Centre Figure C.2 shows the behaviour of an SMS Supplementary Service Control entity within the Service Centre, -

Input signals from the left represent primitives received from the Sending User PINX or Sending Message Centre,

Output signals to the right represent primitives sent to the Receiving User PINX.

SMS-SCidle

SmsSubmit.inv

Yes

reject duplicates? No

SmsSubmit.re

replace Short Message?

Yes

SMS-SCidle

save Short Message, assign SCTS and priority

replace existing Short Message

SmsSubmit.rr D

SmsDeliver.inv

Start Timer T3

SMS-SC Del-Wait

Figure C.2 - Service Centre SDL (sheet 1 of 7)

- 47 -

SMS-SC Del-Wait

SmsDeliver.rr

Stop Timer T3

Status Report?

Yes

internal Status Report Request

SMS-SCidle

Figure C.2 - Service Centre SDL (sheet 2 of 7)

- 48 -

SMS-SC Del-Wait

SmsDeliver.re User not available

SmsDeliver.re memory capacity

Validity Period expired?

Yes

Stop Timer T3 C

Status Report?

Yes

Start Timer T4

SMWD?

Yes

SMS-SCAwait-Alert

Figure C.2 - Service Centre SDL (sheet 3 of 7)

internal Status Report request

- 49 -

SMS-SC Del-Wait

SmsDeliver.re other error

Timer T3 expired

SmsDeliver.rej

Yes

Stop Timer T3

resend?

delete SM

Status Report?

delete SM

Yes

Status Report? Yes

internal Status Report request

SMS-SCidle

Figure C.2 - Service Centre SDL (sheet 4 of 7)

- 50 -

SMS-SCAwait-Alert

Timer T4 expired

ScAlert.inv

VP expired

Stop Timer T4 if running

Stop Timer T4 if running Yes

ScAlert possible?

resend?

No No D

Yes

delete SM ScAlert.rr

ScAlert.re

Figure C.2 - Service Centre SDL (sheet 5 of 7)

SMS-SCidle

- 51 -

any State except SMS-SC-Idle

SmsCommand.inv

execute

successful?

Yes

SmsCommand.rr

Status Report?

SmsCommand.re

Yes internal Status Report request

previous state

Figure C.2 - Service Centre SDL (sheet 6 of 7)

- 52 -

SMS-SCSR-Idle

internal Status Report request

Start T5

SmsStatusReport.inv

SMS-SCSR-Wait

Timer T5 expired

SmsStatusReport.rej

SmsStatusReport.re

Stop Timer T5

resend?

SmsStatusReport.rr

Stop Timer T5

Yes

SMS-SCSR-Idle B

Figure C.2 - Service Centre SDL (sheet 7 of 7)

- 53 -

C.4

SDL Representation of SS-SMS at the Receiving User PINX

C.4.1

Receiving User PINX – Message Centre-case Figure C.3 shows the behaviour of an SMS Supplementary Service Control entity within the Receiving User PINX, -

Input messages from the left represent primitives received from the Service Centre,

Output messages to the right represent primitives sent to the Receiving Message Centre. SMS-RecMC-case-Idle

Deliver.inv

Deliver.rr

Deliver.rej

Deliver.rr

Deliver.rej

ScAlert.inv

SMS-RecMC-case-Idle

Figure C.3 - Receiving User PINX SDL (sheet 1 of 2) SMS-RecMC-case-Idle

ScAlert.rr

Deliver.re

ScAlert.re

Deliver.re

ScAlert.re

SMS-RecMC-case-Idle

Figure C.3 - Receiving User PINX SDL (sheet 2 of 2)

ScAlert.rej

- 54 -

C.4.2

Receiving User PINX – User Terminal-case Figure C.4 shows the behaviour of an SMS Supplementary Service Control entity within the Receiving User PINX, -

Input messages from the left represent primitives received from the Service Centre,

Output messages to the right represent primitives sent to the Receiving User Terminal. SMS-RecUser-case-Idle

SmsDeliver.inv from SC

SmsDeliver.inv to User

can SM be delivered?

Yes No SmsDeliver.rr

SMWD possible? Yes SmsDeliver.re with SCA saved indication

SmsDeliver.re without SCA saved indication

SMS-RecUser-case-Idle

save SC Address

SMS-RecUser-caseAlertWait

Figure C.4 - Receiving User PINX SDL (sheet 1 of 3)

- 55 -

SMS-RecUser-caseAlertWait

Indication User reachable

SmsDeliver.inv with Priority

SmsDeliver.inv without Priority

ScAlert.inv to SC

SmsDeliver.inv to User

SC Address stored already?

Yes can SM be delivered?

save SC Address

Yes SmsDeliver.rr

SC Address stored already?

SmsDeliver.re with SCA saved indication

Yes save SC Address ScAlert.inv to SC

Start Timer T6

SMS-RecUser-caseAlertResp

SMS-RecUser-caseAlertWait SmsDeliver.re with SCA saved indication

SMS-RecUser-caseAlertWait

Figure C.4 - Receiving User PINX SDL (sheet 2 of 3)

- 56 -

SMS-RecUser-caseAlertResp

ScAlert.rr

ScAlert.re

Stop Timer T6

smsDeliver.inv

Stop Timer T6

delete SC Address from SMWD

Timer T6 expired

ScAlert.rej

SmsDeliver.inv to User

No resend?

can SM be delivered? Yes

Yes SMWD possible?

SmsDeliver.rr

A Yes SMS-RecUser-case-Idle

SmsDeliver.re with SCA saved indication

SmsDeliver.re without SCA saved indication

save SC Address

SMS-RecUser-caseAlertResp

Figure C.4 - Receiving User PINX SDL (sheet 3 of 3)

C.5

SDL Representation of SMS at the Receiving Message Centre Figure C.5 shows the behaviour of an SMS Supplementary Service Control entity within the Receiving Message Centre, -

Input messages from the left represent primitives received from Receiving User PINX,

Output messages to the right represent primitives sent to the Receiving User Terminal.

- 57 -

SMS-RecMC-Idle

Deliver.inv

save SM

can SMs be saved?

Yes

SmsDeliver.rr

SMWD possible? Yes

SmsDeliver.re without SCA saved indication

save SC Address

MWI to user

SmsDeliver.re with SCA saved indication

SMS-RecMC-Idle

SMS-RecMC-AlertWait

Figure C.5 - Receiving Message Centre SDL (sheet 1 of 3)

- 58 -

SMS-RecMC-AlertWait

Indication User reachable

SmsDeliver.inv with Priority

SmsDeliver.inv without Priority

save SM ScAlert.inv to SC can SM be saved?

Yes SmsDeliver.rr

SC Address already stored?

Yes save SC address ScAlert.inv to SC

Start Timer T7

SMS-RecMC-AlertResp

Figure C.5 - Receiving Message Centre SDL (sheet 2 of 3)

SmsDeliver.re

SMS-RecMC-AlertWait

- 59 -

SMS-RecMC-AlertResp

ScAlert.rr

ScAlert.re

Stop Timer T7

ScAlert.rej

Stop Timer T7

resend?

Yes SMS-RecMC-Idle

Figure C.5 - Receiving Message Centre SDL (sheet 3 of 3)

Timer T7 expired

- 60 -

- 61 -

Annex D ( infor ma tive)

Mapping of QSIG-PDUs on GSM-PDUs

D.1

smsSubmit invoke APDU

smsSubmit invoke APDU (QSIG) Calling Party Number Information Element

Called Party Number Information Element SmsSubmitArg of smsSubmit invoke APDU DestinationAddress OriginatingAddress MessageReference SmsSubmitParameter ProtocolIdentifier ValidityPeriod ValidityPeriodRel ValidityPeriodAbs ValidityPeriodEnh singleShotSM enhanceVP validityPeriodRel validityPeriodSec validityPeriodSemi StatusReportRequest ReplyPath RejectDuplicates UserData UserDataHeader UserDataHeaderChoice smscControlParameterHeader concatenated8BitSMHeader concatenated8BitSMReferenceNumber

SmsSubmit (GSM) RP-Originating-Address (RP-OA) 1 Octet Address-Length 1 Octet Type-of-Address 1-n Octet Address-Value RP-Destination-Address (RP-DA) –SCA see RP-OA TP-Destination-Address (TP-DA) see RP-OA RP-Originating-Address (RP-OA) see RP-OA TP-Message-Reference (TP-MR) 1 Octet (0..255) TP-Protocol-Identifier (TP-PID) 1 Octet section 9.2.3.9 ETSI TS 100 901 TP-Validity-Period (TP-VP) 1 Octet 7 Octets 7 Octets

relative case, see above 0..255 seconds as Service-Centre-Time-Stamp TP-Status-Report-Request (TP-SRR) 1 Bit TP-Reply-Path (TP-RP) 1 Bit TP-Reject-Duplicates (TP-RD) 1 Bit TP-User-Data (TP-UD)

IEI SMSC Control Parameter 1 Octet IEI Concatenated SM, 8-bit Reference 1 Octet

- 62 -

maximumNumberOf8BitSMInConcatenatedSM sequenceNumberof8BitSM concatenated16BitSMHeader concatenated16BitSMReferenceNumber maximumNumberOf16BitSMInConcatenatedSM sequenceNumberof16BitSM applicationPort8BitHeader destination8BitPort originator8BitPort applicationPort16BitHeader destination16BitPort originator16BitPort dataHeaderSourceIndicator OriginalSender OriginalReceiver SMSC wirelessControlHeader GenericUserValue

Octet

1 Octet IEI Concatenated SM, 16-bit Reference 2 Octet 1

Octet

1 Octet IEI Application port addressing scheme 1 Octet 1 Octet IEI Application port addressing scheme 2 Octet 2 Octet 1 Octet

1-n

Octet(s)

parameterValue genericUserData Class Compressed ShortMessageText CHOICE{ IA5codedshortMessageTextType iA5Coded OctetCoded UniCoded octetCoded compressedCoded} uniCoded compressedCoded shortMessageTextData SmsExtension CHOICE{ Extension SEQUENCE OF EXTENSION}

D.2

TP-Data-Coding-Scheme (TP-DCS) 2 Bit 1 Bit 2 Bit TP-Data-Coding-Scheme (TP-DCS)

TP-User-Data not mappable

smsDeliver invoke APDU

smsDeliver invoke APDU (QSIG) Calling Party Number Information Element

Called Party Number Information Element SmsDeliverArg of smsDeliver invoke APDU OriginatingAddress DestinationAddress

SmsDeliver (GSM) RP-Originating-Address (RP-OA) - SCA 1 Octet Address-Length 1 Octet Type-of-Address 1-n Octet Address-Value RP-Destination-Address (RP-DA) see RP-OA TP-Originating-Address (TP-OA) see RP-OA TP-Destination-Address (TP-DA)

- 63 -

OriginatingName SmDeliverParameter ProtocolIdentifier ServiceCentreTimeStamp Priority MoreMessagesToSend StatusReportIndication ReplyPath UserData smsExtension CHOICE{ Extension SEQUENCE OF EXTENSION}

D.3

see RP-OA not mappable TP-Protocol-Identifier (TP-PID) TP-Service-Centre-Time-Stamp (TP-SCTS) RP-Priority-Request (RP-PRI) TP-More-Messages-To-Send (TP-MMS) TP-Status-Report-Indication (TP-SRI) TP-Reply-Path (TP-RP) as described in section D.1 in annex D not mappable

smsStatusReport invoke APDU

smsStatusReport invoke APDU (QSIG) Calling Party Number Information Element

Called Party Number Information Element SmsStatusReportArg of smsStatusReport invoke APDU MessageReference ServiceCentreTimeStamp DischargeTime RecipientAddress RecipientName DestinationAddress Status priority MoreMessagesToSend StatusReportQualifier ProtocolIdentifier UserData SmsExtension CHOICE{ Extension, Sequence of Extension}

SmsStatusReport (GSM) RP-Originating-Address (RP-OA) - SCA 1 Octet Address-Length 1 Octet Type-of-Address 1-n Octet Address-Value RP-Destination-Address (RP-DA) see RP-OA TP-Message-Reference (TP-MR) TP-Service-Centre-Time-Stamp (TP-SCTS) TP-Discharge-Time (TP-DT) TP-Recipient-Address (TP-RA) not mappable TP-Status (TP-ST) RP-Priority-Request (RP-PRI) TP-More-Messages-To-Send (TP-MMS) TP-Status-Report-Qualifier (TP-SRQ) TP-Protocol-Identifier (TP-PID) as described in D.1 in annex D not mappable

- 64 -

D.4

smsCommand invoke APDU smsCommand invoke APDU (QSIG) SmsCommandArg destinationAddress messageReference messageNumber protocolIdentifier commandType commandData statusReportRequest smsExtension CHOICE{ Extension, Sequence of Extension}

D.5

SmsSubmitReport – Ack (GSM) TP-Service-Centre-Time-Stamp (TP-SCTS) TP-Protocol-Identifier (TP-PID) TP-User-Data (TP-DU)

smsSubmit return error APDU/ smsCommand return error APDU smsSubmit return error APDU smsCommand return error APUD(QSIG) SmsSubmitError SEQUENCE{ failureCause serviceCentreTimeStamp protocolIdentifier userData

D.7

TP-Destination-Address (TP-DA) TP-Message-Reference (TP-MR) TP-Message-Number (TP-MN) TP-Protocol-Identifier (TP-PID) TP-Command-Type (TP-CT) TP-Command-Data (TP-CD) TP-Status-Report-Request (TP-SRR)

smsSubmit return result APDU/ smsCommand return result APDU smsSubmit return result APDU smsCommand return result APDU (QSIG) SmsSubmitRes{ serviceCentreTimeStamp, protocolIdentifier, userData, smsExtension}

D.6

SmsCommand (GSM)

SmsSubmitReport – Error (GSM) TP-Failure-Cause (TP-FCS) TP-Service-Centre-Time-Stamp (TP-SCTS) TP-Protocol-Identifier (TP-PID) TP-Data-Coding-Scheme (TP-DCS) TP-User-Data (TP-UD)

smsDeliver return result APDU/ smsStatusReport return result APDU smsDeliver return result APDU smsStatusReport return result APDU (QSIG) SmsDeliverResponseChoice{ Null, ProtocolIdentifier, userData, Sequence of{ ProtocolIdentifier, userData}} smsExtension

SmsDeliverReport – Ack (GSM)

TP-Protocol-Identifier (TP-PID) TP-User-Data (TP-UD)

- 65 -

D.8

smsDeliver return error APDU/ smsStatusReport return error APDU smsDeliver return error APDU smsStatusReport return error APDU (QSIG) SmsDeliverError SEQUENCE{ failureCause protocolIdentifier userData scAddresseSaved}

SmsDeliverReport – Error (GSM) TP-Failure-Cause (TP-FCS) TP-Protocol-Identifier (TP-PID) TP-Data-Coding-Scheme (TP-DCS) TP-User Date (TP-DU) not mappable

- 66 -

- 67 -

Annex E (normative)

Description of APDU elements

NOTE E.1 In this annex the term Sending User is used, although certain information might be provided either by the Sending User, the Sending User PINX or the Sending User Message Centre. The point of provision of information is dependent on the specific network configuration. It is in the responsibility of the PISN entity that composes a certain APDU to provide all necessary information. NOTE E.2 In this annex the term Receiving User is used, although certain information might be provided either by the Receiving User, the Receiving User PINX or the Receiving User Message Centre. The point of provision of information is dependent on the specific network configuration. It is in the responsibility of the PISN entity that composes a certain APDU to provide all necessary information.

E.1

Elements in smsSubmit invoke APDU Refer to section 6.5 for the related procedures and further elements of the smsSubmit invoke APDU.

E.1.1

messageReference The messageReference is a value between 0 and 255 which is incremented by one and allocated to each Short Message and Command that is sent by the Sending User or the Sending User PINX if not provided by the Sending User. If the value is 255 and the messageReference is incremented, it starts again with value 0.

E.1.2

smsSubmitParameter

E.1.2 .1

proto co lIdentif ier The protocolIdentifier indicates either a higher layer protocol being used or interworking with a certain type of telematic device. Table E.1 lists all currently defined values for the element protocolIdentifier, which are identical to those specified in ETSI TS 100 901. For the straightforward case of simple Short Message transfer the element protocolIdentifier is set to “noIw” (0). For protocolIdentifier values between (1) and (31) it indicates the protocol used between the Sending and Receiving Short Message entity. If the protocolIdentifier contains values between (32) and (63) it indicates interworking with a certain type of telematic device and requests the Service Centre to convert the SM into a form suited for that device type. If the destination network is ISDN the SC must also select the correct service indicators for connecting to a device of that type. If the protocolIdentifier contains a “replaceShortMessageType” then the Service Centre on receipt of an smsSubmit invoke APDU containing such a protocolIdentifier will check the originatingAddress and replace any existing Short Message having the same protocolIdentifier value and originatingAddress with the content of the new smsSubmit invoke APDU. If there is no message to be replaced the Service Centre shall store the new Short Message in the normal way. If a “replaceShortMessageType” type code is not present the Service Centre shall store the message in the normal way.

- 68 -

Table E.1 - Values for element protocolIdentifier (1 octet) noIw

iwUCI

telex

reserved

group3Telefax

reserved

group4Telefax

iwMessageHandlingFacility

voiceTelephone

iwX400MessageHandlingSystem

eRMES

iwInternetElectronicMail

nationalPagingSystem

reserved (5 combinations)

51 - 55

videotex

teletexUnspecifiedCarrier

values specific to each SC, usage based on 56 - 62 mutual agreement between the Short Message Entity and the SC

teletexPSPDN

iwGSMMobileStation

teletexCSPDN

shortMessageType0

teletexAnalogPSTN

replaceShortMessageType1

teletexDigitalISDN

replaceShortMessageType2

uci

replaceShortMessageType3

reserved

replaceShortMessageType4

reserved

replaceShortMessageType5

messageHandlingFacility

replaceShortMessageType6

x400MessageHandlingSystem

replaceShortMessageType7

internetElectonicMail

reserved

reserved (5 combinations)

19 - 23

returnCallMessage

values specific to each SC, usage based on mutual agreement between the Short Message Entity and the SC

24 -30

reserved

72 - 94 95 96 - 124

meDataDownload

125

gsmMobileStation

meDePersonalizationShortMessage

126

iwImplicit

simDataDownload

127

iwTelex

iwTelefaxGroup3

iwTelefaxGroup4

iwVoiceTelephone

iwERMES

iwNationalPagingSystem

iwVideotex

iwTeletexCarrierUnspecified

iwTeletexPSPDN

iwTeletexCSPDN

iwTeletexAnaloguePSTN

iwTeletexDigitalISDN

- 69 -

E.1.2 .2

va lidity Period The Validity Period enables the Sending User to indicate the time period during which the Sending User considers the Short Message to be valid, i.e. for how long the SC shall guarantee its existence in the SC and try to deliver the Short Message to the Receiving User. After expiry of the Validity Period, the SC shall delete the Short Message. The Validity Period may be given in one of the following ways: -

either relative Validity Period (validityPeriodRel), see table E.2

or absolute Validity Period (validityPeriodAbs), formatted as Generalized Time String

or enhanced Validity Period (validityPeriodeEnh).

The enhanced Validity Period indicates that the SC shall try only once to send the SM to the Receiving User if element singleShotSM is set to TRUE and optionally allows to indicate the Validity Period either -

in relative format (see table E.2)

or in seconds

or in semi-octet format (validityPeriodSemi), see table E.3.

The ASN.1 structure of element validityPeriodEnh might be extended with additional formats for the coding of the Validity Period in the future. Table E.2 - Coding Rules for ValidityPeriodRel (1 octet) Value

Validity Period Value

0 to 143

(value+1) x 5 minutes (i.e. 5 mins. intervals up to 12 hours)

144 to 167

12 hours + ((value – 143) x 30 minutes)

168 to 196

(value-166) x 1 day

197 to 255

(value-192) x 1 week

Table E.3 - Coding Example for ValidityPeriodSemi (3 octet) Octet 1 Octet 2 Octet 3

24 hours 30 minutes 57 seconds

E.1.2 .3

statusReportRequest If statusReportRequest is set to TRUE Status Reports are requested by the Sending User from the Sending User for this particular Short Message about status changes of the SM in the SC.

E.1.2 .4

replyPat h If replyPath is set to TRUE in an smsSubmit invoke APDU the Sending User requests the Service Centre to handle a Short Message sent in reply (reply SM) to this smsSubmit via the same Service Centre.

- 70 -

If the Sending Users Service Centre and the Receiving User PINX both support the Reply Path option, the following definitions and procedures shall apply: -

the Sending User of the original SM is the Receiving User of the reply SM, this user is called the Sending User and

the Receiving User of the original SM is the Sending User of the reply SM, this user is called the Receiving User.

The address information in the reply SM shall be set accordingly. The Receiving User PINX shall send the reply SM directly to the Service Centre the Sending User, i.e. the Receiving Users Service Centre is not involved in the handling of the reply SM. E.1.2 .5

rej e ctDuplic ates Reject Duplicates indicates to the SC whether it shall accept or reject a Short Message with the same messageReference and destinationAddress as a previously submitted Short Message from the same originatingAddress. If rejectDuplicates is set to FALSE the Service Centre will accept a Short Message already held in the SC, if it is set to TRUE the Service Centre is instructed to reject such a Short Message. If the duplicate Short Message is accepted the duplicate SM shall not overwrite the already held Short Message. For procedures to replace an already existing SM by a new SM please refer to the specific protocolIdentifier values in section E.1.2.1. If the duplicate Short Message is rejected an appropriate failureCause will be returned to the Sending User in the smsDeliver return error APDU.

E.1.3

userData

E.1.3 .1

userData Header If a userDataHeader is present it indicates a special type of Short Message. The element userDataHeader may contain one or more of the following headers. In GSM-SMS the length of the userDataHeader together with the shortMessageText shall not exceed the maximum length of a single (i.e. not concatenated) Short Message, i.e. 140 octets. Due to ASN.1 coding it cannot be guaranteed within a PISN that this length restrictions are kept. In case of interworking a Service Centre may want to provide a specific interworking functionality. This interworking functionality is out of scope of this Standard.

E.1.3 .1.1 smscCo ntrolPa ra met erHeader This header allows to expand the userDataHeader in a flexible way and controls the Service Centre with regard to the request for Status Reports. The Sending User may request a Status Report for -

Transaction completed (bit 0), if this bit is set to TRUE a Status Report shall be returned when the Short Message transaction is completed;

permanent Error (bit 1), if set to TRUE a Status Report shall be returned when a permanent error occurs and the SC is not making any more transfer attempts;

temporary Error, SC not trying anymore (bit 2), if set to TRUE a Status Report shall be returned when a temporary error occurs and the SC is not making any more transfer attempts;

temporary Error, SC still trying (bit 3), if set to TRUE a Status Report shall be returned when a temporary error occurs and the SC is still trying to transfer the Short Message;

cancel a Status Report Request for concatenated Short Messages (bit 6): a Status Report generated by this Short Message, due to a permanent or last temporary error, cancels the Status Report Requests of the rest of the Short Messages in a concatenated Short Message. This feature can only be used where the SC is aware of the segmentation of a concatenated Short Message and is therefore an implementation matter.

request the original userDataHeader to be included into the Status Report (bit 7): if set to TRUE the original UDH shall be included into the Status Report.

- 71 -

The smscControlParameterHeader element is only enabled if the statusReportRequest bit of smsSubmit invoke APDU is set to TRUE. In the case of concatenated Short Messages smscControlParameterHeaders must be identically present in every Short Message making up that concatenated Short Message. E.1.3 .1.2 concatenated8 BitSM Header Longer messages (which exceed the length of one Short Message) can be formed by concatenating several Short Messages. The concatenated8BitSMHeader contains a concatenated8BitSMReferenceNumber, maximumNumberOf8BitSMInConcatenatedSM and a sequenceNumberOf8BitSM element.

The concatenated8BitSMReferenceNumber element contains a modulo 255 counter and indicates the Reference Number of a particular concatenated Short Message. This Reference Number shall remain constant for every Short Message which makes up a particular concatenated Short Message. The maximumNumberOf8BitSMInConcatenatedSM element is a value in the range 0 to 255 and indicates the total number of Short Messages within the concatenated Short Message. The value shall start at 1 and remain constant for every Short Message which makes up the concatenated Short Message. If the value is zero then the receiving entity shall ignore the whole concatenated8BitSMHeader. The sequenceNumberOf8BitSM element is a value in the range 0 to 255 and indicates the sequence number of a particular Short Message within the concatenated Short Message. The value shall start at 1 and increment by one for every Short Message sent within the concatenated Short Message. If the value is 0 or the value is greater than the maximumNumberOf8BitSMInConcatenatedSM then the receiving entity shall ignore the whole concatenated8BitSMHeader. E.1.3 .1.3 concatenated16 BitSMHeader The concatenated16BitSMHeader is an enhanced variant of the concatenated8BitSMHeader, it contains a concatenated16BitSMReferenceNumber, a maximumNumberOf16BitSMInConcatenatedSM and a sequenceNumberOf16BitSM element. The concatenated16BitSMReferenceNumber element contains a modulo 65536 counter and indicates the Reference Number of a particular concatenated Short Message. This Reference Number shall remain constant for every Short Message which makes up a particular concatenated Short Message. Elements maximumNumberOf16BitSMInConcatenatedSM and sequenceNumberOf16BitSM shall be used in the same way as the according elements described in section E.1.3.1.2 for concatednated8BitSMHeader. E.1.3 .1.4 applicat io nPo rt8 Bit Header The applicationPort8BitHeader element allows Short Messages to be routed directly to one of multiple applications in the Terminal Equipment. The applicationPort8BitHeader contains a destination8BitPort and an originator8BitPort element. The destination8BitPort element is a value in the range 0 to 255 and indicates the receiving port, i.e. application, in the receiving device. The originating8BitPort is a value in the range 0 to 255 and indicates the sending port, i.e. application, in the sending device. Port numbers in the range 0 to 239 are reserved and port numbers in the range 240 to 255 are available for allocation by applications. In the case of concatenated Short Messages the applicationPort8BitHeader shall be included in every Short Message making up the concatenated Short Message. E.1.3 .1.5 applicat io nPo rt16 Bit Header The applicationPort16BitHeader element allows Short Messages to be routed directly to one of multiple applications in the Terminal Equipment. The applicationPort16BitHeader contains a destination16BitPort and an originator16BitPort element.

- 72 -

The destination16BitPort element is a value in the range 0 to 65535 and indicates the receiving port, i.e. application, in the receiving device. The originating16BitPort is a value in the range 0 to 65535 and indicates the sending port, i.e. application, in the sending device. Port numbers in the range 0 to 15999 are as allocated by IANA (http://www.IANA.com), port numbers in the range 16000 to 16999 are available for allocation by applications, all other values are reserved. In the case of concatenated Short Messages the applicationPort16BitHeader shall be included in every Short Message making up the concatenated Short Message. E.1.3.1.6 dataHeaderSourceIndicator The dataHeaderSourceIndicator element is used to separate userDataHeaders created by the Sending User from userDataHeaders created by the Service Centre and by the Receiving User. The dataHeaderSourceIndicator is placed in front of the content inserted by the source. The indicated content (one or more User Data Header) ends at the next dataHeaderSourceIndicator or at the end of the User Data Headers. The Separator is intended to be used especially in Status Reports, but can also be used by the Service Centre to add information into a Short Message. The default content for a User Data Header in a smsDeliver is the headers inserted by the Sending User, and the default content for a User Data Header in a smsStatusReport is the headers copied from the smsDeliver report. The dataHeaderSourceIndicator may contain the values originalSender (1, valid in case of Status Report), originalReceiver (2, valid in case of Status Report) or SMSC (3, can occur in any message or report). E.1.3 .1.7 wirelessContro lHeader The wirelessControlHeader element is used to transport Wireless-Control-Message-Protocol (WCMP) messages. The OCTET STRING associated with the wirelessControlHeader shall contain a WCMP protocol data unit. In the case of concatenated Short Messages the wirelessControlHeader shall be included identically in every Short Message making up the concatenated Short Message. E.1.3 .1.8 g enericUserVa lue The genericUserValue element is reserved for further extensions introduced in GSM 03.40. E.1.3 .2

class The class element indicates how to handle a received Short Message with respect to displaying, storing and acknowledging. If element class is set to 0 the Receiving User PINX/ Receiving User Message Centre shall display the Short Message immediately and send an smsDeliver return result APDU to the Service Centre, irrespective of whether there is memory available or not. The Short Message shall not automatically be stored. If it is not possible to display the Short Message automatically the Receiving User PINX/Receiving User Message Centre shall treat the Short Message as though there were no message class. If element class is set to 1 the Receiving User PINX/Receiving User Message Centre shall send a smsDeliver return result APDU to the Service Centre when the Short Message has reached the Receiving User PINX/ Receiving User Message Centre and can be stored. If element class is set to 2 the Receiving User PINX/Receiving User Message Centre shall ensure that the Short Message has been transferred to the SMS data field in the SIM before it sends an smsDeliver return result APDU. If element class is set to 3 it indicates GSM specific handling and shall be treated as if value 1 was indicated.

E.1.3.3

comp ressed If it is set to ONE it indicates that the text contained in shortMessageText is compressed using the standard compression algorithm. The standard compression algorithm is described in GSM 03.42.

- 73 -

E.1.3 .4

s ho rtMe ssag eText The shortMessageText element contains one of the following elements.

E.1.3 .4.1 iA5Coded The iA5Coded element contains between 0 and 140 byte Short Message Text, i.e. a maximum of 160 characters. E.1.3 .4.2 o ctetCoded The octetCoded element contains between 0 and 140 byte Short Message Text, i.e. a maximum of 140 characters. E .1 .3 .4 .3 u n iC o d ed The uniCoded element contains between 0 and 140 byte Short Message Text coded according to ISO/IEC 10646-1, i.e. a maximum of 70 characters. E.1.3 .4.4 compressedCoded The compressedCoded element contains between 0 and 140 byte compressed Short Message Text including the Compressed Data Header and Footer as described in GSM 03.42. If the Short Message Text is compressed the compressed element shall be set to ONE.

E.2

Elements in smsSubmit return result APDU Refer to section 6.5 for the related procedures and further elements of the smsSubmit return result APDU.

E.2.1

serviceCentreTimeStamp The serviceCentreTimeStamp indicates the time of arrival of a Short Message at the Service Centre. The Service-Centre-Time-Stamp, and any other time value representations that are defined in this specification, represent the time local to the sending entity of the specific APDU. The date and time representation follows ISO 8601. The serviceCentreTimeStamp contains the time of arrival with an accuracy of a second. If two or more messages arrive at the Service Centre at the same time the SC shall modify the serviceCentreTimeStamp in such a way that:

E.2.2

all messages to one Receiving User contain different time stamps,

the modification of the time stamps is kept to a minimum.

protocolIdentifier The protocolIdentifier shall be sent as received within the smsSubmit invoke APDU, see section E.1.2.1 in annex E.

E.2.3

userData The userData element in an smsSubmit return result APDU is only available for use by the Service Centre. The elements shall be used as described in E.1.3 in annex E. If included the userData element in an smsSubmit return result APDU shall include the userData as received in the smsSubmit invoke APDU. It is possible for the Service Centre to include further User Data Headers in the smsSubmit return result APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements.

E.3 E.3.1

Elements in smsSubmit return error APDU failureCause Element failureCause is a value in the range 0 to 255 and contains the reason for the smsSubmit failure. For the purpose of giving a better overview, table E.4 lists all possible failureCause values which might occur in a return error APDU for any SMS specific invoke APDU (all other values are reserved).

- 74 -

Table E.4 - Possible Failure Causes failureCause

value Reason

telematicInterworkingNotSupported

(128)

The telematic interworking as requested in element protocolIdentifier cannot be provided by the Service Centre.

shortMessageType0NotSupported

(129)

The Message Type 0 as indicated in element protocolIdentifier is not supported by the Service Centre.

canNotReplaceShortMessage

(130)

A SM cannot be replaced as requested in element protocolIdentifier.

unspecifiedProtocolIdentifierError

(143)

An unspecified error due to the processing of element protocolIdentifier has occurred.

alphabetNotSupported

(144)

The indicated alphabet (either iA5Coded or octetCoded or uniCoded or compressedCoded) in element shortMessageText is not supported by the receiving entity.

messageClassNotSupported

(145)

The class of the SM as indicated in element class is not supported.

unspecifiedDcsError

(159)

An unspecified error due to the processing of element shortMessageText and class has occurred.

commandCanNotBeActioned

(160)

The command, as indicated in element commandType in the smsCommand invoke APDU, cannot be actioned by the SC. No further reason given.

commandUnsupported

(161)

The command, as indicated in element commandType in the smsCommand invoke APDU, is not supported by the SC.

unspecifiedCommandError

(175)

An unspecified error due to the processing of the smsCommand invoke APDU has occurred.

pduNotSupported

(176)

This error can only occur in interworking cases with other networks, as the other network might send this failureCause. Within a PISN configuration this error will be handled by a reject APDU to the specific invoke APDU.

scBusy

(192)

The SC cannot handle the received invoke APDU.

noScSubscription

(193)

The user sending the invoke APDU and identified by the related address information (i.e. PartyNumber element) is not subscribed at the SC, i.e. is not allowed to use SMS at this SC.

scSystemFailure

(194)

A general SC system failure has occurred.

invalidSmeAddress

(195)

The address (i.e. PartyNumber) of the Short Message Entity which should receive the invoke APDU is not valid.

- 75 -

E.3.2

destinationSmeBarred

(196)

The Short Message Entity which should receive the invoke APDU is barred and therefore cannot handle the invoke APDU.

smRejectedDuplicateSm

(197)

Element rejectDuplicates in an smsSubmitInvoke APDU was set to TRUE and the SC recognised the received SM as already held in the SC, due to identical elements messageReference and destinationAddress and originatingAddress of the held and the newly received SM.

validityPeriodFormatNotSupported

(198)

The format of element validityPeriod is not supported by the SC.

validityPeriodNotSupported

(199)

The Validity Period functionality is not supported by the SC.

simSmsStorageFull

(208)

This error can only occur if the Receiving Users terminal equipment provides a socalled SIM storage, as available e.g. in chip cards. The Receiving Users SIM storage does not allow to store further Short Messages.

noSmsStorageCapabilityinSIM

(209)

This error can only occur if the Receiving Users terminal equipment provides a socalled SIM storage, as available e.g. in chip cards. The Receiving Users SIM storage does generally not allow to store Short Messages.

errorInTE

(210)

An error in the Receiving Users terminal equipment has occurred.

memoryCapacityExceeded

(211)

The SM was not stored as the Short Message Entity receiving the invoke APDU did not have memory available.

simApplicationToolkitBusy

(212)

This error can only occur if the Receiving Users terminal equipment provides a socalled SIM storage, as available e.g. in chip cards. The Receiving Users SIM storage did report a Toolkit-Busy error.

simDataDownloadError

(213)

This error can only occur if the Receiving Users terminal equipment provides a socalled SIM storage, as available e.g. in chip cards. The Receiving Users SIM storage did report a Data-Download error.

unspecifiedErrorCause

(255)

An unspecified error occurred.

serviceCentreTimeStamp As described in E.2.1 of annex E.

E.3.3

protocolIdentifier As described in E.1.2.1 in annex E.

E.3.4

userData The userData element in an smsSubmit return error APDU is only available for use by the Service Centre. The elements shall be used as described in 1.3 in annex E.

- 76 -

If included the userData element in an smsSubmit return error APDU shall include the userData as received in the smsSubmit invoke APDU. It is possible for the Service Centre to include further User Data Headers in the smsSubmit return error APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements.

E.4 E.4.1

Elements in smsDeliver invoke APDU originatingName Name of the Sending User if available to the Service Centre. Name restrictions shall apply accordingly.

E.4.2

smsDeliverParameter

E.4.2 .1

proto co lIdentif ier As described in E.1.2.1 in annex E.

E.4.2.2

serv ic eC entreTimeStamp As described in E.2.1 of annex E.

E.4.2 .3

prio rity If the priority element is set to FALSE the message transfer should be stopped if the SC address is already contained in the SMWD field.

E.4.2 .4

mo reMessag esToSend If the moreMessagesToSend element is set to TRUE it indicates that there are more messages waiting for this Receiving User in that particular Service Centre. Messages as used here refers to both Status Reports (for Short Messages for which this user acted as a Sending User) and Short Messages.

E.4.2 .5

statusReportIndicat ion If the statusReportIndication element is set to TRUE it indicates that a Status Report will be returned to the Sending User of the Short Message.

E.4.2 .6

replyPat h If replyPath is set to TRUE it indicates that the reply path for the Short Message exists, e.g. that the Receiving User may reply via this Service Centre although it may not be the default Service Centre. Refer to E.1.2.4 for further details.

E.4.3

userData This element contains the userData element as received from the Sending User PINX/Sending User Message Centre in the smsSubmit invoke APDU as described in E.1.3 in annex E. It is possible for the Service Centre to include further User Data Headers in the smsDeliver invoke APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements.

E.5

Elements in smsDeliver return result APDU The smsDeliver return result APDU shall either contain none, one or both of the following two elements.

E.5.1

protocolIdentifier As described in E.1.2.1 in annex E.

E.5.2

userData The userData element in an smsDeliver return result APDU is only available for use by the Receiving User PINX/Receiving User Message Centre and contains elements as described in E.1.3. It is possible for the Receiving User PINX/Receiving User Message Centre to include further User Data Headers in the smsDeliver return result APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements.

- 77 -

E.6 E.6.1

Elements in smsDeliver return error APDU failureCause The failureCause element contains the reason for the smsDeliver failure. All possible failureCauses are listed and described in section E.3.1.

E.6.2

protocolIdentifier As described in E.1.2.1 in annex E.

E.6.3

userData If included the userData element in a smsDeliver return error APDU shall include the userData as received in the smsDeliver invoke APDU. It is possible for the Receiving User PINX/ Receiving User Message Centre to include further User Data Headers in the smsDeliver return error APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements. The userData element shall be used according to E.1.3 in annex E.

E.6.4

scAddressSaved If the scAddressSaved element is set to TRUE it indicates that the Receiving User PINX/ Receiving User Message Centre stored the Service Centre address in the SMWD, hence the Service Centre does not have to repeat the delivery procedure periodically and the Receiving User PINX/Receiving User Message Centre will send an scAlert invoke APDU.

E.7 E.7.1

Elements in smsStatusReport invoke APDU messageReference The messageReference in an smsStatusReport invoke APDU shall contain the messageReference of the smsSubmit or smsCommand invoke APDU to which the Status Report refers. If the Status Report refers to an smsCommand invoke APDU and the commandType was an “Enquiry” the messageReference element shall contain the messageNumber contained in that smsCommand invoke APDU (e.g. the messageReference of the previously received Short Message to which the Enquiry refers).

E.7.2

serviceCentreTimeStamp The serviceCentreTimeStamp element shall contain the serviceCentreTimeStamp of the Short Message to which the Status Report refers. This will allow the Sending User to associate a Short Message with a Status Report by correlating the serviceCentreTimeStamps.

E.7.3

dischargeTime The dischargeTime element indicates the time at which a previously submitted Short Message was successfully delivered to the Receiving User or attempted to deliver to the Receiving User or disposed of by the SC. The representation of the dischargeTime follows ISO 8601. In the case of “transaction completed” the time shall be the time of the completion of the transaction. In the case of “SC still trying to transfer SM” the time shall be the time of the last transfer attempt. In the case of “permanent or temporary error – SC not making any more transfer attempts” the time shall be time of either the last transfer attempt of the time at which the SC disposed of the SM according to the Status outcome in the status element.

E.7.4

recipientAddress The recipientAddress element contains the address of the Receiving User of the previously submitted Short Message.

E.7.5

recipientName The recipientName element contains the name of the Receiving User of the previously submitted Short Message if it is available to the Service Centre and not restricted. Name restrictions shall apply accordingly.

- 78 -

E.7.6

status The status element indicates the status of a previously submitted Short Message and certain Commands for which a Status Report has been requested. Table E.5 - Possible values for status element Status

E.7.7

Value

smReceivedBySME

smForwardedButSCUnableToConfirmDelivery

smReplacedByTheSC

tempCongestion

tempSMEBusy

tempNoResponseFromSME

tempServiceRejected

qualityOfServiceNotAvailable

tempErrorInSME

remoteProcedureError

incompatibleDestination

connectionRejectedBySME

notObtainable

permanentQualityOfServiceNotAvailable

noInterworkingAvailable

iwValidityPeriodExpired

smDeletedByOriginatingSME

smDeletedBySCAdministration

smDoesNotExist

congestion

sMEBusy

noResponseFromSME

serviceRejected

tempQualityOfServiceNotAvailable

100

errorInSME

101

priority As described in E.4.2.3 in annex E.

E.7.8

moreMessagesToSend As described in E.4.2.4 in annex E.

E.7.9

statusReportQualifier If the statusReportQualifier is set to FALSE the Status Report is the result of a Short Message, if it is set to TRUE the Status Report is the result of a Command, e.g. an Enquiry.

- 79 -

E.7.10 protocolIdentifier The protocolIdentifier element in an smsStatusReport invoke APDU shall contain the same settings as received in the related smsSubmit invoke APDU, described in E.1.2.1 in annex E.

E.7.11 userData If included the userData element in a smsStatusReport invoke APDU shall include the userData as received in the smsDeliver return result APDU. It is possible for the Service Centre to include further User Data Headers in the smsStatusReport invoke APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements. The userData element shall be used according to section E.1.3 in annex E.

E.8

Elements in smsStatusReport return result APDU The smsStatusReport return result APDU shall either contain one or both of the following elements.

E.8.1

protocolIdentifier As described in E.1.2.1 in annex E.

E.8.2

userData If included the userData element in a smsStatusReport return result APDU shall include the userData as received in the smsStatusReport invoke APDU. It is possible for the Sending User PINX/ Sending User Message Centre to include further User Data Headers in the smsStatusReport return result APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements. The userData element shall be used according to section E.1.3 in annex E.

E.9 E.9.1

Elements in smsStatusReport return error APDU failureCause As described in E.3.1 of annex E.

E.9.2

protocolIdentifier As described in E.1.2.1 of annex E.

E.9.3

userData If included the userData element in a smsStatusReport return error APDU shall include the userData as received in the smsStatusReport invoke APDU. It is possible for the Sending User PINX/ Sending User Message Centre to include further User Data Headers in the smsStatusReport return error APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements. The userData element shall be used according to section E.1.3 in annex E.

E.9.4

scAddressSaved As described in E.6.4 of annex E.

E.10 Elements in smsCommand invoke APDU E.10.1 messageReference The messageReference is a value between 0 and 255 which is incremented by one and allocated to each Command that is sent by the Sending User. If the value is 255 and the messageReference is incremented, it starts again with value 0.

- 80 -

E.10.2 messageNumber The messageNumber element contains the Message Reference of the Short Message to which the Command refers, e.g. the messageReference of a previously submitted Short Message. The messageNumber is only necessary for Commands that operate on a specific Short Message, else it shall be ignored.

E.10.3 protocolIdentifier As described in E.1.2.1 of annex E.

E.10.4 commandType The commandType element specifies which operation is to be performed on a Short Message. The commandType consists of one octet and can be set to “Enquiry” (0), “CancelSRR” (1), “DeletePreviouslySubmittedSM” (2) and “EnableSRRrelatingToPreviouslySubmittedSM” (3). The values from 224 to 255 are specific for each Service Centre, all other values are reserved.

E.10.5 commandData The commandData element contains data related to the operation requested by the Sending User.

E.10.6 statusReportRequest The statusReportRequest element indicates whether or not the Command requests a Status Report. It shall be set TRUE for commandType “Enquiry”, otherwise it shall be set FALSE.

E.11 Elements in smsCommand return result APDU E.11.1 serviceCentreTimeStamp As described in E.2.1 of annex E.

E.11.2 protocolIdentifier As described in E.1.2.1 of annex E.

E.11.3 userData The userData element in an smsCommand return result APDU is only available for use by the Service Centre. It is possible for the Service Centre to include further User Data Headers in the smsCommand return result APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements. The userData element shall be used according to section E.1.3 in annex E.

E.12 Elements in smsCommand return error APDU E.12.1 failureCause As described in E.3.1 of annex E.

E.12.2 serviceCentreTimeStamp As described in E.2.1 of annex E.

E.12.3 protocolIdentifier As described in E.1.2.1 of annex E.

E.12.4 userData The userData element in an smsCommand return error APDU is only available for use by the Service Centre. It is possible for the Service Centre to include further userDataHeader in the smsCommand return error APDU by adding the dataHeaderSourceIndicator and other userDataHeader elements. The userData element shall be used according to section E.1.3 in annex E.

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-325 — Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Short message service (QSIG-SMS) (June 2001)

Related documents