S tandard ECMA-324
June 2001
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – 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-324
June 2001
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – Short Message Service (SMSSD)
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
ECMA-324.DOC
04-09-02 09,41
.
Brief History
This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00227. This particular Standard specifies the Short Message Service. 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-324 10 Ju ly 2002
Summary Following is a summary of errors detected and corrected in Standard ECMA-324, Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – Short Message Service.
Clause 1 To clarify the scope of this Standard, a paragraph is being added in clause 1 and the note is being modified. Original NOTE 1 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 it is only necessary to implement a QSIG interface and some interworking in the Service Centre in order to use it in the herein described network. 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.
- i -
Table of contents 1
Scope
1
2
Conformance
1
3
R eferences ( normat ive)
1
4
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 Co mma n d 4.2 .2 Messag e Cen tr e 4.2 .3 Me s sag e Cen tr e Cas e 4.2 .4 ScA ler t 4.2 .5 Serv ice Centr e ( SC) 4.2 .6 Sho rt Me ss ag e (S M) 4.2 .7 Sho rt Me ss ag e W a iting D a ta 4.2 .8 Status Repor t 4.2 .9 Ter min al Case
2 2 2 2 2 2 2 3 3 3 3 3
5 6
A cro nym s S S-S hort Me s sage S ervic e stag e 1 s p ec if icat ion 6.1 D escr ip tion 6.1 .1 G ener a l d e scr ip tion 6.1 .2 Qu alif ication s on app licab ility to teleco mmu n ications serv ices 6.2 Procedur es 6.2 .1 Provision /withdr awal 6.2 .2 Nor mal p rocedur es 6.2 .3 Ex cep tional pro c edur es 6.3 In ter action s w ith o ther Supp leme n tar y Serv ices/ Add ition al N e twork Features 6.3 .1 Calling Line Id en tif ication Presen tation ( SS- CLI P) 6.3 .2 Connected Lin e Iden tification Pr esen ta tion (SS- COLP) 6.3 .3 Calling /Conn ected Line Id en tif ication Restr iction ( SS- CLIR) 6.3 .4 Calling Name Id en tif ication Pr esentation (SS-CNIP) 6.3 .5 Calling /Conn ected N a me Id en tif ication Restr iction ( SS- CNIR) 6.3 .6 Connected N a me Id en tif ication Pr esen tation ( SS-CON P) 6.3 .7 Co mp letion of Calls to Busy Sub scrib er (SS-CCBS) 6.3 .8 Co mp letion of Calls on No Rep ly ( SS-CCN R) 6.3 .9 Call Tr an sfer ( SS- CT ) 6.3 .10 Call Forw ard ing Un cond ition al (SS- CFU ) 6.3 .11 Call Forw ard ing Bu sy (SS- CF B) 6.3 .12 Call Forw ard ing No Rep ly ( SS- CFN R) 6.3 .13 Call Def lection ( SS- CD) 6.3.14 P a th R ep la ce me n t ( A N F - P R )
3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6
- ii -
7
6.3 .15 Call Off er (SS- CO) 6.3 .16 Call In tru s ion ( SS- CI ) 6.3 .17 Do No t D isturb (SS-DND) 6.3 .18 Do No t D isturb Overr ide (SS-DNDO) 6.3 .19 Adv ice of Ch arge (SS-AO C) 6.3.20 Recall (SS-RE) 6.3 .21 Call In tercep tion (AN F-CINT) 6.3 .22 Tran sit Coun ter (AN F-TC) 6.3 .23 Rou te Re striction Class ( ANF- RRC) 6.3 .24 Messag e W aiting Ind ication ( SS- MW I) 6.3 .25 W ir e le ss Ter min al Location Reg istration (SS-WTLR) 6.3 .26 Wirele ss Termin al Mob ility In co ming Call (ANF-WTMI) 6.3 .27 Wirele ss Termin al Mob ility Ou tgo ing Call (ANF-WTMO) 6.3 .28 Au th en tication of a W TM u ser (SS-W TAT) 6.3 .29 Au th en tication of the PI SN (SS-WTA N) 6.3 .30 Priv ate User Mob ility In co ming Call (ANF-PUMI) 6.3 .31 Priv ate User Mob ility Ou tgo ing Ca ll (ANF-PUMO) 6.3 .32 Priv ate User Mob ility Reg istration (SS-PUMR) 6.3 .33 Co mmo n Infor mation (ANF-CMN) 6.3 .34 Call Pr ior ity In terrup tion ( Pro tection) (SS-CPI( P)) 6.3 .35 Sing le Step Call Tr an sfer ( SS- SSCT ) 6.3 .36 Simp le D ialog ( SS- SD) 6.3 .37 Call Id entification and Call Link age (ANF-CIDL) 6.4 In terwork ing consid er ations 6.5 Ov erall SDL
6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 7 7 8
Short Messag e Serv ic e stag e 2 descript ion 7.1 Fun c tion al mo d e l 7.1 .1 Fun c tion a l mo d e l d es crip tion 7.1 .2 Descrip tion of Functional En tities 7.1 .3 Relation ship of fun c tion al mod e l to Basic Call fun c tion al mo d e l 7.2 Infor mation f low s 7.2 .1 D ef in ition of in for mation f low s 7.2 .2 Infor mation f low sequ en ces 7.3 Fun c tion al En tity action s 7.3 .1 Fun c tion al En tity action s of FE1 7.3 .2 Fun c tion al En tity action s of FE2 7.3 .3 Fun c tion al En tity action s of FE3 7.3 .4 Fun c tion al En tity action s of FE4 7.3 .5 Fun c tion al En tity action s of FE5 7.3 .6 Fun c tion al En tity action s of FE6 7.3 .7 Fun c tion al En tity action s of FE7 7.4 Fun c tion al En tity beh av iour 7.4 .1 Beh av iour of FE1 7.4 .2 Beh av iour of FE2 7.4 .3 Beh av iour of FE3 7.4 .4 Beh av iour of FE4
11 11 11 11 13 13 13 21 26 26 26 27 27 28 28 28 28 29 30 30 32
- iii -
7.4 .5 Beh av iour of FE5 7.4 .6 Beh av iour of FE6 7.4 .7 Beh av iour of FE7 7.5 Allo cation of Functional En tities to ph ysical equ ip men t 7.6 In terwork ing consid er ations
35 35 36 38 38
An nex A - D es cript ion of PDU elemen ts
39
1
Scope This Standard specifies the Short Message Service (SMS). SMS enables a user to send and receive Short Messages (SMs) to and from another user. 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 kind of basic service but is described in this document in the style of a supplementary service. Supplementary service specifications are produced in three stages, according to the method described in ETS 300 387. This Standard contains the stage 1 and stage 2 specifications of SMS. The stage 1 specification (clause 6) specifies the service as seen by users of PISNs. The stage 2 specification (clause 7) identifies the functional entities involved in the service and the information flows between them.
2
Conformance In order to confirm to this Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the service specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clause 6 (stage 1) and clause 7 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.
3
References (normative) The following standards contain provisions which, through 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-142
Private Integrated Services Network (PISN) - Circuit Mode 64kbit/s Bearer Services - Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
ECMA-155
Private Integrated Services Networks - Addressing (International Standard ISO/IEC 11571)
ECMA-163
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Name Identification Supplementary Services (International Standard ISO/IEC 13864)
ECMA-241
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Message Waiting Indication Supplementary Service (International Standard ISO/IEC 15505)
GSM 03.38
Digital cellular telecommunications systems (Phase 2+); Alphabets and languagespecific information
ETSI TS 100 901
Digital cellular telecommunications systems (Phase 2+); Technical realization of the Short Message Service (SMS) (GSM 03.40)
GSM 03.42
Digital cellular telecommunications systems (Phase 2+); Compression algorithm for text messaging services
- 2 -
4
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:
4.2
-
Basic Service
(ITU-T Rec. I.210)
-
Private Integrated services Network eXchange (PINX)
(ECMA-133)
-
Private Integrated Services Network (PISN)
(ECMA-133)
-
Service
(ITU-T Rec. I.112)
-
Signalling
(ITU-T Rec. I.112)
-
Supplementary Service
(ITU-T Rec. I.210)
-
User
(ECMA-142)
Other definitions NOTE 3 Further PDU elements are described in annex A.
4.2 .1
Co mmand A Short Message data unit which enables the Sending User to request the Service Centre to perform a certain action, which might be related to a previously sent Short Message from the same Sending User. As far as acknowledging and delivery is concerned, Commands are treated like Short Messages. In the case of certain Commands a Status Report may be sent in response from the SC which contains the outcome of the action.
4.2 .2
M essage Centre The entity that activates or deactivates the Message Waiting Indication against the Receiving User as a result of the storage or retrieval of Short Messages. The Message Centre can serve as a sending, storing and receiving entity for Short Messages on behalf of the Sending and/ or the Receiving User.
4.2 .3
M essage Centre Ca se This describes that either the Sending Users terminal or the Receiving Users terminal or both are not able to handle the procedures that are required by the SMS. In this case a Message Centre can act on behalf of these terminals. The procedures how a user can compose and retrieve SMS related information via a Message Centre are out of the scope of this Standard.
4.2 .4
ScA lert Information provided to an SC that has previously initiated unsuccessful Short Message delivery attempt(s) to a specific Receiving User, that the Receiving User is now recognised to have recovered operation or to have memory available again.
- 3 -
4.2 .5
Serv ic e C entre ( SC) A function within the network that receives Short Messages from Sending Users. The SC is responsible for the relaying and store-and-forwarding of these Short Messages to the Receiving Users. If a Receiving User is not able to receive a Short Message, the Service Centre has to store the Short Message and attempt to deliver the Short Message again at a later time. The Service Centre is responsible for a Short Message until it is successfully delivered to the Receiving User or the Validity Period expires. Depending on the implementation of Short Message Waiting Data the SC either repeats the delivery attempt automatically in certain intervals or attempts to deliver the Short Message upon reception of a ScAlert information. An SC may receive Commands from the Sending User and perform the requested actions. Additionally, the Service Centre may provide Status Reports to a Sending User.
5
4.2 .6
Short Messag e (SM ) Data unit containing the Short-Message-Text and additional data necessary for the transmission of the Short-Message-Text from the Sending to the Receiving User.
4.2 .7
Short Messag e Wa it ing Da ta SMS user specific information containing address information of one or more SCs, which unsuccessfully attempted to deliver a Short Message to a Receiving User while the user was not able to receive the Short Message (e.g. did not have memory available or was not reachable). The Short Message Waiting Data is used to alert the SC when the Receiving User has memory available or is reachable again.
4.2 .8
Status R epo rt Information optionally sent from the SC to the Sending User containing the status of a Short Message submitted to a Receiving User or the outcome of a Command submitted to an SC. A Status Report for a Command or a Short Message is sent from the SC to the Sending User if it has been requested in the Short Message or Command.
4.2.9
T e r m in a l C a se This describes that either the Sending Users terminal or the Receiving Users terminal or both are able to handle the procedures that are required by the SMS.
Acronyms ANF
Additional Network Feature
FE
Functional Entity
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
PNP
Private Numbering Plan
SC
Service Centre
SCTS
Service-Centre-Time-Stamp
SDL
Specification and Description Language
SM
Short Message
SMS
Short Message Service
SMSC
Short Message Service Centre
SMWD
Short Message Waiting Data
VP
Validity Period
- 4 -
6
SS-Short Message Service stage 1 specification
6.1
Description
6 .1 .1
G en e ra l d es c r ipt io n The Short Message Service provides a means of sending messages of limited size point-to-point between network users. The provision of SMS makes use of a Service Centre which acts as a store-and-forward centre for Short Messages, i.e. all Short Messages are sent using a Service Centre which receives Short Messages from the Sending User, stores them and delivers them to the Receiving User. Thus the network needs to support the transfer of Short Messages between Sending User, Service Centre and Receiving User. The Sending User sends the Short Message to the Service Centre where the Short Message is stored. The Service Centre attempts to deliver the Short Message to the Receiving User. If a Short Message cannot be delivered within a specific time (Validity Period) the Service Centre deletes the Short Message. Other messages besides the user defined Short Messages can be sent using SMS: -
Status Reports inform the Sending User about the status of a previously sent Short Message or Command;
-
Commands allow users to manipulate Short Messages already stored in a Service Centre or the behaviour of the Service Centre with regard to the Status Report procedure.
NOTE 4 The functionality of the Service Centre in this specification is identical to the functionality of a Service Centre in GSM. 6.1 .2
6.2
Q ua lif ica tion s o n ap p lic ab ility to t e le co mmun icat ion s ser v ic es This service does not apply directly to any basic telecommunication service.
Procedures
6.2 .1
Prov ision/wit hdra wal SMS may be provided after pre-arrangement with the service provider, or may be available generally to all users. SMS may be withdrawn on request of the user or for administrative reasons.
6.2 .2 No rma l procedures 6.2 .2.1 A ct ivat ion/dea ct ivat ion/reg ist rat ion/interrogat ion Not applicable. 6.2 .2.2
6.2 .2.2.1
Invo cat ion and operat ion All information shall be delivered by setting up a new call independent connection. Release of the call independent connection is in the responsibility of its initiator. No rma l o perat ion A Sending User shall be able to submit a Short Message to a Service Centre at any time, independently of whether or not there is a call in progress. An indication shall always be returned to the Sending User; either confirming that the SC received the Short Message or informing the Sending User that it was not possible to deliver the Short Message to the SC, including the reason why. A Sending User shall be able to submit a Command to a Service Centre at any time, independently of whether or not there is a call in progress. The Service Centre shall receive Commands from the Sending User and execute them. Upon reception of a Command the Service Centre shall execute the Command on the Short Message specified by the Short Message Number and the Originating-Address given in the Command information. An indication shall always be returned to the Sending User, either confirming the reception/ execution of the Command or indicating that the reception/ execution of the command failed, including the reason why. A Receiving User shall be able to receive a Short Message from a Service Centre at any time, independently of whether or not there is a call in progress. An indication shall always be returned to
- 5 -
the SC; either confirming that the Receiving User received the Short Message, or indicating that the reception of the Short Message failed, including the reason why. If either a Short Message or a Command submitted to the Service Centre from a Sending User requests a Status Report, and the Status Report capabilities are included in the SC, it shall return one or more Status Reports to the Sending User. The Sending User shall be able to receive Status Reports from a Service Centre at any time, independently of whether or not there is a call in progress. An indication shall always be returned to the Service Centre, either confirming the reception of the Status Report or indicating that the reception failed, including the reason why. It shall be possible for the Sending User to send several correlated Short Messages, which together form a longer Message (Concatenated Short Message). NOTE 5 The acknowledging of a successful reception of a Short Message or a Status Report by the receiving entity does not imply that the Short Message or the Status Report has been displayed or in any other way delivered to the user. 6.2 .3 Except ional pro c edures 6.2 .3.1 A ct ivat ion/dea ct ivat ion/interrogat ion Not applicable. 6.2 .3.2
Invo cat ion and operat ion If the Service Centre is not able to receive a Short Message from the Sending User it shall return an indication to the Sending User containing the Failure-Cause. If the Service Centre is not able to receive/execute a command submitted from the Sending User it shall return an indication to the Sending User containing the Failure-Cause. If the Receiving User is not able to receive a Short Message delivered from the Service Centre the Receiving User shall return an indication to the Service Centre containing the Failure-Cause. If the Sending User is not able to receive a Status Report from the Service Centre the Sending User shall return an indication to the Service Centre containing the Failure-Cause. If the Service Centre is not able to deliver a Short Message to a Receiving User because there is no memory available or the user is not reachable, the entity responsible for that Receiving User shall set an internal indication that a Service Centre attempted to deliver a Short Message to this user and store the address of that SC in the Short Message Waiting Data. When the Receiving User has memory available or is reachable again the entity shall send an ScAlert to the Service Centre, containing the address of the Receiving User and upon reception of an ScAlert confirmation delete the SC address from the SMWD list. The implementation of the Short Message Waiting Data is optional. If it is not implemented it is up to the SC to repeat the delivery attempt periodically until the Validity Period expires.
6.3
Interactions with other Supplementary Services/ Additional Network Features Interactions with other supplementary services and ANFs for which PISN standards were available at the time of this Standard are specified below.
6.3 .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 interaction.
6.3 .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 interaction.
6.3 .3
Ca lling /Con ne ct ed Lin e Id ent if icat ion Re st ric t ion (SS-C LIR ) No interaction.
6.3 .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 interaction.
6.3 .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 interaction.
- 6 -
6.3 .6
Con ne ct ed Na me Id en tif i cat ion P re s entat io n (S S-CON P) No interaction.
6.3 .7
Co mple t ion of Ca lls to Busy Subscriber (SS-CC BS) No interaction.
6.3 .8
Co mplet ion of Ca lls on No Reply (SS-CCNR) No interaction.
6.3 .9
Ca ll Transfer (SS-CT) No interaction.
6.3 .10
Ca ll Forwarding Uncondit iona l (SS-CFU ) Call forwarding shall not apply for Short Message Service.
6.3 .11
Ca ll Forwarding Busy ( SS-C FB) Call forwarding shall not apply for Short Message Service.
6.3 .12
Ca ll Forwarding No Reply ( SS-CFN R) Call forwarding shall not apply for Short Message Service.
6.3 .13
Ca ll D ef lect ion (SS-CD) Call deflection shall not apply for Short Message Service.
6.3 .14
Pa th R eplacement (ANF-PR) No interaction.
6.3 .15
Ca ll Off er ( SS-CO) No interaction.
6.3 .16
Ca ll Int rusion (SS-CI) No interaction.
6.3 .17
Do No t D isturb (SS-DND) Do Not Disturb shall not apply for Short Message Service.
6.3 .18
Do No t D isturb Ov erride ( SS-DNDO) No interaction.
6.3 .19
Adv ic e of Cha rg e (S S-AOC ) No interaction.
6.3 .20
R eca ll (SS-R E) No interaction.
6.3 .21
Ca ll Int e rcept ion (ANF-CIN T) Call Interception shall not apply for Short Message Service.
6.3 .22
Tra nsit Count er (ANF- TC) No interaction.
6.3 .23
Route Restrict io n C lass (ANF-RRC) No interaction.
6.3 .24
M essage Wa it ing Indicat ion (SS-MWI) The Message Centre may act as a sending entity for Short Messages and Commands and as a storage entity for Short Messages and shall indicate the reception of new Short Messages to the Receiving User.
6.3 .25
Wireless Termina l Locat ion Reg ist rat ion (SS-WTLR) No interaction. NOTE 6 A Short Message may be directed to the new location.
- 7 -
6.3 .26
Wireless Termina l Mobility Incoming Ca ll (ANF-WTMI) No interaction.
6.3 .27
Wireless Termina l Mobility Outgo ing Ca ll (ANF-WTMO) No interaction.
6.3 .28
Authent icat ion of a WTM user (SS-WTA T) No interaction.
6.3 .29
Authent icat ion of t he PISN (SS-WTAN) No interaction.
6.3 .30
Privat e U ser Mobility Incoming Ca ll (AN F- PUM I) No interaction.
6.3 .31
Privat e U ser Mobility Outgo ing Ca ll (AN F- PUMO) No interaction.
6.3 .32
Privat e U ser Mobility R eg ist rat ion (SS-PUMR) No interaction.
6.3 .33
Co mmon Info rmat io n (AN F-CMN) No interaction.
6.3 .34
Ca ll Pr io r ity Int e rr uption (P rot ect ion ) ( SS-CP I( P)) No interaction.
6.3 .35
Sing le St ep Ca ll Transf er (SS-SSC T) No interaction.
6.3 .36
Simple D ia log ( SS- SD) No interaction.
6.3 .37
Ca ll Ident ificat ion a nd Ca ll Linkag e (AN F-CID L) No interaction.
6.4
Interworking considerations A Service Centre may be connected to other networks than a PISN and receive Short Messages from and send Short Messages to the other networks.
- 8 -
6.5
Overall SDL SMS-Idle
Send_SM Request from Sending User
Send_Command Request from Sending User
A
Memory available (internal)
Status Report from SC
Yes
SMWD empty?
Status Report Response to SC
No Status Report Indication to Sending User
Send SM to Service Centre
Send Command to Service Centre
SMSWaitForResponse
Send ScAlert to Service Centre
SMS-Idle
Figure 1 - Overall SDL (sheet 1 of 3)
- 9 -
SMS-Idle
Short Message from Service Centre
Memory available?
No
Yes
save Short Message
SMWD implemented?
No
Yes Short Message Response to Service Centre
save SC Address in SMWD
New SM Indication to Receiving User
Short Message Error to Service Centre
SMS-Idle
Figure 2 - Overall SDL (sheet 2 of 3)
- 10 -
SMSWaitForResponse
Send_SM Response from Service Centre
Send_SM Indication to Sending User
Send_SM Error from Service Centre
Send_SM Error Indication to Sending User
Send Command Response from Service Centre
Send Command Error from Service Centre
Command Response Indication to Sending User
Commmand Error Indication to Sending User
ScAlert Response from Service Centre
ScAlert Error from Service Centre
Delete SC Address from SMWD
Repeat?
Yes
No A
SMSIdle
Figure 3 - Overall SDL (sheet 3 of 3)
- 11 -
7
Short Message Service stage 2 description
7.1
Functional model
7.1 .1
Funct iona l mo del descript ion The functional model shall comprise the following Functional Entities (FEs): FE1
Short Message Sending User Agent
FE2
Sending User Service Control Entity
FE3
Service Centre Control Entity
FE4
Receiving User Service Control Entity
FE5
Short Message Receiving User Agent
FE6
Sending User Message Centre
FE7
Receiving User Message Centre
The following relationships shall exist between these FEs: ra
between FE1 and FE2
rb
between FE2 and FE3 and FE6 and FE3
rc
between FE3 and FE4 and FE4 and FE7
rd
between FE4 and FE5
Figure 4 shows these FEs and relationships.
FE1
ra
FE2
rb
FE3
rc
rb
FE6
FE4
rd
FE5
rc
FE7 Figure 4 - Functional Entities
7.1 .2 D escript ion of Funct iona l Ent it ies 7.1 .2.1 Short Messag e Sending U s er Agent, FE1 This Functional Entity:
7 .1 .2 .2
-
submits the Short-Message-Text and optional elements to FE2;
-
submits Command elements to FE2;
-
receives Submit Confirmations for sent SMs or Commands from FE2;
-
receives Status Reports from FE2;
-
submits Delivery Confirmation elements for received Status Reports to FE2.
S en d ing U se r S erv i ce C o n t ro l E nt it y , F E2 This Functional Entity: -
composes Short Messages using the Short-Message-Text and optional elements from FE1, adding additional elements if necessary, and sends them to FE3;
-
composes Commands using the elements from FE1, adding additional elements if necessary, and sends them to FE3;
- 12 -
7.1 .2.3
7.1.2.4
-
receives Submit Confirmations and Status Reports from FE3;
-
sends Submit Confirmations and Status Reports to FE1;
-
receives Delivery Confirmation elements from FE1 and sends them to FE3.
Serv ic e C entre Contro l En t ity, FE3 This Functional Entity: -
receives Short Messages from FE2 or FE6, stores them and attempts to deliver them to FE4 until the Validity Period expires;
-
composes and sends Submit Confirmations and Status Reports to FE2 or FE6;
-
deletes Short Messages when the Validity Period is expired;
-
receives Commands from FE2 or FE6 and executes them on the Short Messages given in the Command Data if they are still available in the SC;
-
receives Delivery Confirmations from FE4 and
-
optionally, receives SC-Alerts from FE4.
R ec e iv in g U se r S e rv ice C o n t ro l En t i t y , F E4 This Functional Entity: -
receives Short Messages from FE3;
-
sends the Short-Message-Text and optional elements to FE5 or
-
sends the Short Messages to FE7;
-
receives Delivery Confirmations from FE5 or FE7 and sends them to FE3 and
in the Terminal Case, optionally -
keeps a list of SC (SMWD) which attempted to deliver a Short Message while the Receiving User was not reachable and
-
sends ScAlert messages to FE3 or
in the Message Centre Case, optionally -
7.1 .2.5
7.1 .2.6
7.1 .2.7
receives ScAlerts from FE7 and sends them to FE3.
Short Messag e R eceiv ing User Agent, FE5 This Functional Entity: -
receives Short-Message-Text and optional elements from FE4;
-
submits Delivery Confirmation elements to FE4;
-
delivers the Short Message to the Receiving User.
Sending U ser Messag e C ent re, FE6 This Functional Entity -
receives Short Message or Command elements;
-
composes and sends Short Messages to FE3;
-
composes and sends Commands to FE3;
-
receives Submit Confirmations from FE3;
-
receives Status Reports from FE3;
-
sends Delivery Confirmations to FE3.
R eceiv ing U ser M essag e C ent re, FE7 This Functional Entity: -
receives Short Messages from FE4 and stores them;
- 13 -
-
submits Delivery Confirmations to FE4;
-
indicates the reception of a new Short Message to the Receiving User and
in the Message Centre Case, optionally -
7.1 .3
7.2
keeps a list of SC (SMWD) which attempted to deliver a Short Message while the Receiving User was not reachable and sends SC-Alert messages to FE4.
R e lat ionship of f unct iona l model to Ba sic Ca ll f unct iona l model No relationship between functional model and basic call functional model.
Information flows
7.2 .1
D ef init io n of info rmation f lo ws In the tables listing the elements in information flows, the column headed “Request” indicates which of these elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed “Confirm” (confirmed information flows only) indicates which of these elements are mandatory (M) and which are optional (O) in a response/confirmation information flow. Further descriptions of the PDU elements can be found in annex A.
7.2 .1.1
ra_SmsSubmit ra_SmsSubmit is a confirmed information flow across ra from FE1 to FE2 used to submit Short Message elements from the Short Message Sending User Agent to the Sending User Service Control Entity. Table 1 lists the elements within the ra_SmsSubmit information flow. Table 1 - Contents of ra_SmsSubmit Element
Request
Confirm
Receiving User’s number
M
Sending User’s number
O
Short Message Reference
O
Protocol Identifier
O
Status-Report-Request
O
Reply-Path
O
Reject-Duplicates
O
Class
O
O
Compressed
O
O
Short-Message-Text
M
O (Note 7)
Validity-Period
O
User Data Header
O
O (Note 7)
SMSC Control Parameters
O
O
Service-Centre-Time- Stamp
O
M
NOTE 7 This element is only available in an SmsSubmit response/ confirmation for use by the Service Centre.
- 14 -
7.2 .1.2
rb_S ms Submit rb_SmsSubmit is a confirmed information flow across rb from FE2 to FE3 or from FE6 to FE3 used to submit the Short Message from the Sending User Service Control Entity or Sending User Message Centre, respectively, to the Service Centre Entity. Table 2 lists the elements within the rb_SmsSubmit information flow. Table 2 - Contents of rb_SmsSubmit Element
Request
Confirm
Receiving User’s number
M
Sending User’s number
M
Short Message Reference
M
Protocol Identifier
M
Status-Report-Request
M
Reply-Path
M
Reject-Duplicates
M
Class
O
O
Compressed
M
O
Short-Message-Text
M
O (Note 8)
Validity-Period
O
User Data Header
O
Service-Centre-Time-Stamp
O
O (Note 8) M
NOTE 8 This element is only available in an SmsSubmit response/ confirmation for use by the Service Centre.
- 15 -
7.2 .1.3
rc_ SmsDeliv er rc_SmsDeliver is a confirmed information flow across rc from FE3 to FE4 or from FE4 to FE7 used to submit the Short Message from the Service Centre Entity to the Receiving User Service Control Entity and from the Receiving User Service Control Entity to the Receiving User Message Centre. Table 3 lists the elements within the rc_SmsDeliver information flow. Table 3 - Contents of rc_SmsDeliver Element
Request Confirm
Sending User’s number
M
Receiving User’s number
M
Protocol Identifier
M
Service-Centre-Time-Stamp
M
Priority
M
More-Messages-to-Send
M
Status-Report-Indication
M
Reply-Path
M
Class
O
O
Compressed
M
O
Short-Message-Text
M
O (Note 9)
User Data Header
O
O (Note 9)
Sending User’s name
O
O
NOTE 9 This element is only available in an SmsDeliver response/ confirmation for use by the Receiving User entity.
- 16 -
7.2 .1.4
rd_SmsD e liv er rd_SmsDeliver is a confirmed information flow across rd from FE4 to FE5 used to submit the Short Message from the Receiving User Service Control Entity to the Short Message Receiving User Agent. Table 4 lists the elements within the rd_SmsDeliver information flow. Table 4 - Contents of rd_SmsDeliver Element
Request
Confirm
Sending User’s number
M
Receiving User’s number
O
Protocol Identifier
O
Service-Centre-TimeStamp
O
Priority
O
More-Messages-to-Send
O
Status-Report-Indication
O
Reply-Path
O
Class
O
O
Compressed
O
O
Short-Message-Text
M
O (Note 10)
User Data Header
O
O (Note 10)
Sending User’s name
O
O
NOTE 10 This element is only available in an SmsDeliver response/ confirmation for use by the Receiving User entity.
- 17 -
7.2 .1.5
ra_SmsStatusR epo rt ra_SmsStatusReport is a confirmed information flow across ra from FE2 to FE1 used to submit a Status Report from the Sending User Service Control Entity to the Short Message Sending User Agent. Table 5 lists the elements within the ra_SmsStatusReport information flow. Table 5 - Contents of ra_SmsStatusReport Element
Request
Confirm
Short Message Reference
O (Note 11)
Service-Centre-Time-Stamp
M
Discharge-Time
M
Receiving User’s number
M
Destination Address
M
Status
M
Priority
O
More-Messages-to-Send
O
Status-Report-Qualifier
O
Receiving User’s Name
O
Protocol Identifier
O
O
Class
O
O
Compressed
O
O
Short-Message-Text
O
O (Note 12)
User Data Header
O
O (Note 12)
NOTE 11 Where the SmsStatusReport is the result of an SmsCommand and the Command Type was an Enquiry, the Short Message Reference returned in the SmsStatusReport shall be the Short Message Number which was sent in the SmsCommand (i.e. the Short Message Reference of the previously submitted Short Message to which the Enquiry refers). NOTE 12 This element is only available in an SmsStatusReport response/ confirmation for use by the Receiving User entity.
- 18 -
7.2 .1.6
rb_SmsStatusR epo rt rb_SmsStatusReport is a confirmed information flow across rb from FE3 to FE2 or from FE3 to FE6 used to submit a Status Report from the Service Centre Entity to the Sending User Service Control Entity and from the Service Centre Entity to the Sending User Message Centre. Table 6 lists the elements within the rb_SmsStatusReport information flow. Table 6 - Contents of rb_SmsStatusReport Element
Request
Confirm
Short Message Reference
M (Note 13)
Service-Centre-Time-Stamp
M
Discharge-Time
M
Receiving User’s address
M
Destination Address
M
Status
M
Priority
M
More-Messages-to-Send
M
Status-Report-Qualifier
M
Receiving User’s Name
O
Protocol Identifier
O
O
Class
O
O
Compressed
O
O
Short-Message-Text
O
O (Note 14)
User Data Header
O
O (Note 14)
NOTE 13 Where the SmsStatusReport is the result of an SmsCommand and the Command Type was an Enquiry, the Short Message Reference returned in the SmsStatusReport shall be the Short Message Number which was sent in the SmsCommand (i.e. the Short Message Reference of the previously submitted Short Message to which the Enquiry refers). NOTE 14 This element is only available in an SmsStatusReport response/ confirmation for use by the Receiving User entity.
- 19 -
7.2 .1.7
ra_SmsCommand ra_SmsCommand is a confirmed information flow across ra from FE1 to FE2 used to transfer a Command from the Short Message Sending User Agent to the Sending User Service Control Entity. Table 7 lists the elements within the ra_SmsCommand information flow. Table 7 - Contents of ra_SmsCommand Element
Request
Receiving User’s address
M
Short Message Reference
O
Short Message Number
M
Protocol Identifier
M
Command-Type
M
Command-Data
O
Status-Report-Request
O
Service-Centre-Time-Stamp Short-Message-Text
Confirm
O
M O (Note 15)
Class
O
Compressed
O
User Data Header
O (Note 15)
NOTE 15 This element is only available in an SmsCommand response/ confirmation for use by Service Centre.
- 20 -
7.2 .1.8
rb_SmsCommand rb_SmsCommand is a confirmed information flow across rb from FE2 to FE3 or FE6 to FE3 used to transfer a Command from the Sending User Service Control Entity to the Service Centre Entity and from the Sending User Message Centre to the Service Centre Control Entity, respectively. Table 8 lists the elements within the rb_SmsCommand information flow. Table 8 - Contents of rb_SmsCommand Element
Request
Receiving User’s address
M
Short Message Reference
M
Short Message Number
M
Protocol Identifier
M
Command-Type
M
Command-Data
O
Status-Report-Request
O
Confirm
O
Service-Centre-Time-Stamp
M
Short-Message-Text
O (Note 16)
Class
O
User Data Header
O (Note 16)
Compressed
O
NOTE 16 This element is only available in an SmsCommand response/ confirmation for use by Service Centre. 7.2 .1.9
rd_ScA lert rd_ScAlert is a confirmed information flow across rd from FE5 to FE4 used to transfer a ScAlert from the Short Message Receiving User Agent to the Receiving User Service Control Entity. Table 9 lists the elements within the rd_ScAlert information flow. Table 9 - Contents of rd_ScAlert Element Sending User’s number
7.2 .1.10
Request
Confirm
O
O
rc_ ScA lert rc_ScAlert is a confirmed information flow across rc from FE4 to FE3 or from FE7 to FE4 used to transfer a ScAlert from the Receiving User Service Control Entity to the Service Centre Entity and from the Receiving User Message Centre to the Receiving User Service Control Entity, respectively. Table 10 lists the elements within the rc_ScAlert information flow. Table 10 - Contents of rc_ScAlert Element Sending User’s number
Request
Confirm
M
M
- 21 -
7.2 .1.11
smsDeliv erErro r smsDeliverError is an unconfirmed information flow across rc from FE4 to FE3 and rd from FE5 to FE4 or rc from FE7 to FE4 used to transfer an error indication due to the Short Message Receiving User Agent or the Receiving User Message Centre not being able to save a received rd_SmsDeliver/ rc_SmsDeliver. Table 11 lists the elements within the smsDeliverError information flow. Table 11 - Contents of smsDeliverError Element
Request
failureCause
M
protocolIdentifier
O
userDataHeader
O (Note 17)
class
O
compressed
O
shortMessageText
O (Note 17)
scAddressSaved
M
NOTE 17 This element is only available in an smsDeliverError request for use by the Receiving User entity. 7.2 .2
Info rmat ion f lo w sequences A stage 3 standard for SS-SMS shall provide signalling procedures in support of the information flow sequences specified in the figures. In addition, signalling procedures should be provided to cover sequences arising from error situations, interactions with Basic Calls, interactions with other supplementary services, different topologies etc. Within a column representing an SS-SMS Functional Entity, the numbers refer to Functional Entity actions listed in 7.3.
7.2 .2.1
Submission of a Short M essage Figure 5 shows in generic form the information flow sequence for submission of a Short Message when in the case when the Short Messages are stored in and sent from a Terminal.
- 22 -
FE1
101
ra
FE2
rb
201
rb_SmsSubmit
FE3
rc
FE4
rd
FE5
ra_SmsSubmit req/ind
req/ind 301 rb_SmsSubmit 102
ra_SmsSubmit
202
con/res
con/res 302
rc_SmsDeliver req/ind
401 rd_SmsDeliver req/ind 501
402
rd_SmsDeliver con/res
rc_SmsDeliver 303
con/res
Figure 5 - Information flow sequence for Short Message Transfer, Terminal-case
- 23 -
Figure 6 shows in generic form the information flow sequence for submission of a Short Message from FE6 to FE7.
FE6
rb
601
rb_SmsSubmit req/ind
602
rc
FE3
rc
FE4
FE7
304
rb_SmsSubmit con/res 302
rc_SmsDeliver req/ind
403 rc_SmsDeliver req/ind 701 404
303
rc_SmsDeliver
rc_SmsDeliver con/res
con/res
Figure 6 - Information flow sequence for Short Message transfer - Message-Centre-case 7.2 .2.2
D e livery of a Stat us Repo rt Figure 7 shows in generic form the information flow sequence for the submission of a Status Report from FE3 to FE1.
FE1
ra
FE2
rb
FE3
rb_SmsStatusReport 203
req/ind
204
rb_SmsStatusReport
rc
FE4
305
ra_SmsStatusReport req/ind 103 ra_SmsStatusReport res/con
res/con
306
Figure 7 - Information flow sequence for Status Report Transfer - Terminal-case
rd
FE5
- 24 -
Figure 8 shows in generic form the information flow sequence for the submission of a Status Report from FE3 to FE6. rb
FE6
FE3
rb_SmsStatusReport
rc
FE4
rd
FE5
307
req/ind 603 rb_SmsStatusReport res/con
308
Figure 8 - Information flow sequence for Status Report Transfer - Message-Centre-case 7.2 .2.3
Tra nsfer of a n SmsCommand Figure 9 shows in generic form the information sequence flow for the transfer of an SmsCommand from FE1 to FE3.
FE1
104
ra
FE2
rb
FE3
rc
FE4
ra_SmsCommand req/ind
205 rb_SmsCommand req/ind 309 rb_SmsCommand
105
ra_SmsCommand
206
res/con
res/con
Figure 9 - Information flow sequence for Command Transfer - Terminal-case
rd
FE5
- 25 -
Figure 10 shows in generic form the information flow sequence for the submission of a Command from FE6 to FE3. rb
FE6
rc
FE3
rd
FE4
FE5
604 rb_SmsCommand req/ind 310 rb_SmsCommand 605
res/con
Figure 10 - Information flow sequence for Command Transfer - Message-Centre-case 7.2 .2.4
FE1
Unsuccessful Transf er of an SmsD eliver a nd fo llo wing transfer of an ScA lert Figure 11 shows in generic form the information flow sequence for the transfer of an ScAlert from FE4 to FE3. ra
FE2
rb
FE3 302
rc
FE4
rd
rc_SmsDeliver req/ind 401
rd_SmsDeliver req/ind rd_SmsDeliverError req/ind
rc_SmsDeliverError 311
FE5
req/ind rc_ScAlert
405
406
req/ind 312 rc_ScAlert res/con
407
Figure 11 - Information flow sequence for ScAlert Transfer - Terminal-case
502
- 26 -
Figure 12 shows in generic form the information flow sequence for the transfer of an ScAlert from FE7 to FE3.
FE1
ra
FE2
rb
FE3 302
rc
rc
FE4
FE7
rc_SmsDeliver 403
req/ind
rc_SmsDeliver 702
req/ind rc_SmsDeliverError 311
rc_smsDeliverError
req/ind
408
req/ind
rc_ScAlert req/ind rc_ScAlert 312
703
409
req/ind
rc_ScAlert 410
res/con
rc_ScAlert res/con
704
Figure 12 - Information flow sequence for ScAlert Transfer - Message-Centre-case
7.3 7.3 .1
7.3 .2
Functional Entity actions Funct iona l Ent ity act ions of FE1 101 Send ra_SmsSubmit request/indication to FE2 as received from the user. 102
Receive ra_SmsSubmit response/confirmation from FE2 and deliver it to the user.
103
Receive ra_SmsStatusReport request/indication from FE2 and deliver it to the user. Send ra_SmsStatusReport response/confirmation to FE2.
104
Send ra_SmsCommand request/indication to FE2 as received from the user.
105
Receive ra_SmsCommand response/confirmation from FE2 and deliver it to the user.
Funct iona l Ent ity act ions of FE2 201 Receive ra_SmsSubmit request/indication from FE1, add additional elements if necessary and send rb_SmsSubmit request/indication to FE3. 202
Receive rb_SmsSubmit response/confirmation response/confirmation to FE1.
from
FE3
and
send
ra_SmsSubmit
- 27 -
7.3 .3
7.3 .4
203
Receive rb_SmsStatusReport request/indication from FE3, check the elements and send ra_SmsStatusReport request/indication to FE1.
204
Receive ra_SmsStatusReport response/confirmation from FE1 and send rb_SmsStatusReport response/confirmation to FE3.
205
Receive ra_SmsCommand request/indication from FE1, add additional elements if necessary and send rb_SmsCommand request/indication to FE3.
206
Receive rb_SmsCommand response/confirmation from FE3 and send ra_SmsCommand response/confirmation to FE1.
Funct iona l Ent ity act ions of FE3 301 Receive rb_SmsSubmit request/indication from FE2, check if parameters are correct and store the Short Message. Send rb_SmsSubmit response/confirmation to FE2. 302
Compose rc_SmsDeliver request/indication message using the stored Short Message data and send it to FE4.
303
Receive rc_SmsDeliver response/confirmation from FE4; this may trigger the sending of rb_SmsStatusReport (see action 305).
304
Receive rb_SmsSubmit request/indication from FE6, check if parameters are correct and store the Short Message. Send rb_SmsSubmit response/confirmation to FE6.
305
If the user requested a Status Report in a previously sent SmsSubmit or SmsCommand then compose rb_SmsStatusReport request/indication message and send it to FE2.
306
Receive rb_SmsStatusReport response/confirmation from FE2.
307
If the user requested a Status Report in a previously sent SmsSubmit or SmsCommand then compose rb_SmsStatusReport request/indication message and send it to FE6.
308
Receive rb_SmsStatusReport response/confirmation from FE6.
309
Receive rb_SmsCommand request/indication from FE2 and action it on the Short Message identified by the elements in the command. Send rb_SmsCommand response/confirmation to FE2.
310
Receive rb_SmsCommand request/indication from FE6 and action it on the Short Message identified by the elements in the command. Send rb_SmsCommand response/confirmation to FE6.
311
Receive rc_SmsDeliverError request/indication from FE4, this may trigger the sending of rb_SmsStatusReport (see action 305).
312
Receive rc_ScAlert request/indication from FE4 and send rc_ScAlert response/confirmation to FE4. If there are Short Messages or Status Reports waiting to be delivered to this Receiving User invoke delivery procedure (see action 302).
Funct iona l Ent ity act ions of FE4 401 Receive rc_SmsDeliver request/indication from FE3, check if elements are correct and send rd_SmsDeliver request/indication to FE5. 402
Receive rd_SmsDeliver response/confirmation response/confirmation to FE3.
from
403
Receive rc_SmsDeliver request/indication from FE3, check if elements are correct and send rc_SmsDeliver request/indication to FE7.
404
Receive rc_SmsDeliver response/confirmation response/confirmation to FE3.
405
Receive rd_SmsDeliverError request/indication from FE5 and send rc_SmsDeliverError request/indication to FE3, optionally, save Sc-Address if not saved already.
406
Send rc_ScAlert request/indication to FE3 (only in Terminal Case).
407
Receive rc_ScAlert response/confirmation from FE3 (only in Terminal Case).
from
FE5
FE7
and
and
send
send
rc_SmsDeliver
rc_SmsDeliver
- 28 -
7.3 .5
408
Receive rc_SmsDeliverError request/indication from FE7 and send rc_SmsDeliverError request/indication to FE3.
409
Receive rd_ScAlert request/indication from FE7, add additional elements if necessary, and send rc_ScAlert request/indication to FE3.
410
Receive rc_ScAlert response/confirmation response/confirmation to FE7.
7.3 .7
7.4
FE3
and
send
rd_ScAlert
Funct iona l Ent ity act ions of FE5 501 Receive rd_SmsDeliver request/indication from FE4, deliver the Short Message to the user and send rd_SmsDeliver response/confirmation to FE4. 502
7.3 .6
from
Receive rd_SmsDeliver request/indication from FE4. If the received Short Message cannot be saved, then send rd_SmsDeliverError request/indication to FE4.
Funct iona l Ent ity act ions of FE6 601 On request of the user send rb_SmsSubmit request/ indication to FE3. 602
Receive rb_SmsSubmit response/ confirmation from FE3 and indicate result to the user.
603
Receive rb_SmsStatusReport request/indication from FE3 and indicate it to the user. Send rb_SmsStatusReport response/confirmation to FE3.
604
On user request send rb_SmsCommand request/indication to FE3.
605
Receive rb_SmsCommand response/confirmation from FE3 and indicate result to the user.
Funct iona l Ent ity act ions of FE7 701 Receive rc_SmsDeliver request/indication from FE4, store the Short Message if possible, indicate the reception of the new message to the user and send rc_SmsDeliver response/confirmation to FE4. 702
Receive rc_SmsDeliver request/indication from FE4. If it is not possible to store the Short Message send rc_SmsDeliverError request/indication to FE4 and optionally, save SCAddress if not saved already.
703
On an internal indication send an rc_ScAlert request/indication to FE4.
704
Receive an rc_ScAlert response/confirmation from FE4.
Functional Entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1999).
- 29 -
7.4 .1
Behav iour of FE1 Figure 13 shows the normal behaviour of FE1. Output signals to the left and input signals from the left represent primitives to and from the Sending User. Output signals to the right and input signals from the right represent information flows to and from FE2.
FE1_Idle
Send_SM_Request from Sending User
101
Send_Command Request from Sending User
ra_SmsSubmit req/ind
ra_SmsCommand req/ind
FE1_Submit Invoked
FE1_Command Invoked
ra_smsSubmit resp/conf
Result Indication to the Sending User
102
ra_smsCommand resp/conf
104
ra_ SmsStatusReport req/ind
ra_ SmsStatusReport resp/conf
Result Indication to the Sending User
105
Result Indication to the Sending User
FE1_Idle
Figure 13 - SMS, SDL for Functional Entity 1
103
- 30 -
7.4 .2
Behav iour of FE2 Figure 14 shows the normal behaviour of FE2. Output signals to the left and input signals from the left represent information flows to and from FE1. Output signals to the right and input signals from the right represent information flows to and from FE3.
FE2_Idle
ra_SmsSubmit req/ind
201
add elements if necessary
ra_SmsCommand req/ind
rb_SmsCommand req/ind
FE2_Submit Invoked
FE2_Command Invoked
ra_SmsSubmit resp/conf
202
rb_SmsCommand resp/conf
rb_ SmsStatusReport req/ind
203
ra_ SmsStatusReport req/ind
add elements if necessary
rb_SmsSubmit req/ind
rb_SmsSubmit resp/conf
205
FE2_SR Invoked
ra_ SmsStatusReport resp/conf
206
ra_SmsCommand resp/conf
204
add elements if necessary
rb_ SmsStatusReport resp/conf
FE2_Idle
Figure 14 - SMS, SDL for Functional Entity 2 7.4 .3
Behav iour of FE3 Figure 15 and figure 16 show the normal behaviour of FE3. Output signals to the left and input signals from the left represent information flows to and from FE2 or FE6. Output signals to the right and input signals from the right represent information flows to and from FE4.
- 31 -
FE3_Idle
rb_SmsSubmit req/ind (from FE2 or FE6)
rb_SmsCommand req/ind (from FE2 or FE6)
301 304
save SM
309 310
action Command
rb_SmsSubmit resp/conf (to FE2 or FE6)
rb_SmsCommand resp/conf (to FE2 or FE6)
rc_SmsDeliver req/ind
302
FE3_Deliver Invoked
rc_SmsDeliverError req/ind
Status Report requested? No
311
rc_SmsDeliver resp/conf
303
Yes Status Report requested? rb_ SmsStatusReport req/ind (to FE2 or FE6)
305 307
No
FE3_ StatusReport Invoked
rb_ SmsStatusReport resp/conf (from FE2 or FE6)
FE3_ AwaitAlert
Yes
rb_ SmsStatusReport req/ind (to FE2 or FE6)
305 307
FE3_ StatusReport Invoked
306 308
rb_ SmsStatusReport resp/conf (from FE2 or FE6)
FE3_Idle
Figure 15 - SMS, SDL of Functional Entity 3 (sheet 1 of 2)
306 308
- 32 -
FE3_ AwaitAlert
rc_ScAlert req/ind
312
rc_ScAlert resp/conf
rc_SmsDeliver req/ind
302
FE3_Deliver Invoked
Figure 16 - SMS, SDL for Functional Entity 3 (sheet 2 of 2) 7.4 .4 Behav iour of FE4 7.4 .4.1 M essage Centre case Figure 17 and figure 18 show the normal behaviour of FE4. Output signals to the left and input signals from the left represent information flows to and from FE3. Output signals to the right and input signals from the right represent information flows to and from FE7.
FE4_Idle
rc_SmsDeliver req/ind
rc_SmsDeliver req/ind
403
rc_SmsDeliver resp/conf
rc_SmsDeliver resp/conf
404
rc_ScAlert resp/conf
410
rc_ScAlert resp/conf
FE4_Idle
Figure 17 - SMS, SDL of Functional Entity 4 - Message Centre case (sheet 1 of 2)
- 33 -
FE4_Idle
rc_ScAlert req/ind
409
rc_ScAlert req/ind
rc_SmsDeliverError req/ind
408
rc_SmsDeliverError req/ind
FE4_Idle
Figure 18 - SMS, SDL of Functional Entity 4 - Message Centre case (sheet 2 of 2) 7.4.4.2
Terminal ca se Figure 19 shows the normal behaviour of FE4. Output signals to the left and input signals from the left represent information flows to and from FE3. Output signals to the right and input signals from the right represent information flows to and from FE5 or internal primitives.
- 34 -
FE4_Idle
rc_SmsDeliver req/ind
401
rd_SmsDeliver req/ind
FE4-Deliver Invoked
rd_SmsDeliver resp/conf
rc_SmsDeliver resp/conf
FE4_Idle
402
rd_SmsDeliverError req/ind
405
save SC Address
rc_SmsDeliverError req/ind
FE4_ WaitIndication
Indication memory available
rc_ScAlert req/ind
406
FE4_ AlertInvoked
rc_ScAlert resp/conf
407
FE4_Idle
Figure 19 - SMS, SDL of Functional Entity 4, Terminal case
- 35 -
7.4 .5
Behav iour of FE5 Figure 20 shows the normal behaviour of FE5. Output signals to the left and input signals from the left represent information flows to and from FE4. Output signals to the right and input signals from the right represent information flows to and from the Receiving User.
FE5_Idle
rd_SmsDeliver req/ind
save Short Message
possible?
No
Yes
rd_SmsDeliver resp/conf
501
rd_SmsDeliverError req/ind
502
FE5_Idle
Figure 20 - SMS, SDL of Functional Entity 5 7.4 .6
Behav iour of FE6 Figure 21 shows the normal behaviour of FE6. Output signals to the left and input signals from the left represent information flows to and from the Sending User. Output signals to the right and input signals from the right represent information flows to and from FE3.
- 36 -
FE6_Idle
Send_CommandRequest from Sending User
Send_SM-Request from Sending User
rb_SmsSubmit req/ind
601
FE6_Submit Invoked
rb_SmsSubmit resp/conf
Result indication to the Sending User
rb_SmsCommand req/ind
rb_ SmsStatusReport req/ind
604
rb_SmsCommand resp/conf
Status Report indication to the Sending User
rb_ SmsStatusReport resp/conf
FE6_Command Invoked
602
603
605
Result indication to the Sending User
FE6_Idle
Figure 21 - SMS, SDL of Functional Entity 6 7.4 .7
Behav iour of FE7 Figure 22 shows the normal behaviour of FE7. Output signals to the left and input signals from the left represent information flows to and from FE4. Output signals to the right and input signals from the right represent information flows to and from the Receiving User.
- 37 -
FE7_Idle
rc_SmsDeliver req/ind
save Short Message
possible?
No
Yes
rc_SmsDeliver resp/conf
FE7_Idle
701
rc_SmsDeliverError req/ind
702
save SC Address
FE7_ WaitIndication
Indication memory available
rc_ScAlert req/ind
703
FE7_ AlertInvoked
rc_ScAlert resp/conf
FE7_ Idle
Figure 22 - SMS, SDL for Functional Entity 7
704
- 38 -
7.5
Allocation of Functional Entities to physical equipment The allocation of FEs to physical locations as shown in table 12 shall apply. Table 12 - Scenarios for the allocation of FEs to physical equipment
7.6
User A
User A
User A
User B
User B
User B
FE1
FE2
FE6
FE3
FE4
FE5
FE7
Scenario 1
TE
PINX
-
Service Centre
PINX
TE
-
Scenario 2
-
-
MC
Service Centre
PINX
-
MC
Scenario 3
TE
PINX
-
Service Centre
PINX
-
MC
Scenario 4
-
-
MC
Service Centre
PINX
TE
-
Interworking considerations In the cases where FE4, FE5 or FE7 is in another network, information pertaining to relationship rc or rd shall be passed as appropriate to the other network by the Service Centre. The Service Centre shall contain a mapping function which will map the received information flows to the appropriate information flows of the other network (e.g. GSM-SMS). In the cases where information is received from a FE located in another network the Service Centre shall map the information flows from that network (e.g. GSM-SMS) to the appropriate information flows in a PISN.
Table 13 - Scenarios for the allocation of FEs to physical equipment in the case of interworking with other networks User A
User A
User A
User B
User B
User B
FE1
FE2
FE6
FE3
FE4
FE5
FE7
Scenario 1
TE
PINX
-
Service Centre
other network
other network
-
Scenario 2
other network
other network
-
Service Centre
PINX
TE
-
Scenario 3
-
-
MC
Service Centre
other network
other network
-
Scenario 4
other network
other network
-
Service Centre
PINX
-
MC
- 39 -
Annex A (normative)
Description of PDU elements
A.1
Class Indication how the message was handled at the Sending Users terminal and shall be handled at the Receiving Users terminal (concerning displaying, storage, acknowledging).
A.2
Command Data Data relating to the action that the Sending User requests the Service Centre to perform. This Data may be part of a Command initiated by the Sending User.
A.3
Command Type Type of action that the Sending User requests the Service Centre to perform. Command Types can be used e.g. for an enquiry of the status of a previously submitted SM, deletion of a previously submitted SM, etc.
A.4
Compressed Indication whether the text of the Short Message is compressed or not.
A.5
Discharge Time Indicates the time at which a previously submitted Short Message was
A.6
-
successfully delivered to the Receiving Users Service Control Entity or
-
attempted to deliver to the Receiving Users Service Control Entity or
-
disposed of by the Service Centre.
More-Messages-to-Send Indication that there are more messages waiting in that Service Centre to be sent to that particular Receiving User.
A.7
Priority Requests a delivery attempt from the Service Centre to the Receiving User irrespective of whether or not the Receiving User has been identified as temporarily absent or having no memory available.
A.8
Protocol Identifier This refers to a higher layer protocol or indicates interworking with a certain type of telematic device. In the case of interworking the sending terminal requests the SC to convert the SM into a format suitable for that Receiving Users terminal.
A.9
Receiving Users Name This is the Receiving Users name, restrictions for name presentation shall apply accordingly.
A.10
Receiving Users Number This is the Receiving Users PISN number.
A.11
Reject-Duplicates Instructs the SC to reject or accept a Short Message already held in the Service Centre.
A.12
Reply-Path Request from the Sending User to a SC to handle a reply SM sent in response to a previously received SM. In this case the Sending User of the reply SM is the Receiving User of the previously sent SM. The Sending User of the previously sent SM is the Receiving User of the reply SM. This may happen even though this SC is not known to the receiving terminal.
- 40 -
A.13
Sending User’s Name This is the Name of the Sending User, restrictions for name presentation shall apply accordingly.
A.14
Sending User’s Number This is the Sending User’s PISN number.
A.15
Service-Centre-Time-Stamp Time of Arrival of the Short Message at the Service Centre. The same time value will also be carried in the SmsStatusReport to the Sending User relating to this particular Short Message. This will allow the Sending User to associate a particular sent SM with a subsequently received Status Report by correlating the two Service-Centre-Time-Stamp values.
A.16
Short Message Number Short Message Reference of a previously submitted Short Message on which a specific Command shall be performed. This value is not identical with the Short Message Reference of the Command itself. For Command Types which are not for a specific Short Message this field shall be ignored when received.
A.17
Short Message Reference This is a Reference-Number identifying the Short Message (or a Command) uniquely to the Service Centre.
A.18
Short-Message-Text 140 octet of data containing the message text and all optional User Data Headers.
A.19
SMSC Control Parameters Control Parameters specifying on which condition the SC shall return a Status Report to the Sending User (e.g. after successful delivery of the SM to the Receiving User, due to permanent error, etc.). Status-ReportRequest must be set in order to enable SMSC Control Parameters.
A.20
Status Indicates the status of a previously submitted Short Message and certain Commands for which a Status Report has been requested.
A.21
Status Report Indication Indication of whether or not the Sending User has requested a Status Report.
A.22
Status Report Qualifier Indication of whether this Status Report is a response to a previously sent SM or Command.
A.23
Status-Report-Request Request from the Sending User to the Service Centre to send a Status Report for a SM or a Command. Additionally, the SMSC Control Parameter may be included, indicating the conditions on which a Status Report shall be returned.
A.24
User Data Header Sequence of one or more User Data Header(s). A User Data Header may be used to send a SM directly to an applications within the Receiving Users terminal, to transfer control information to the Service Centre or to concatenate Short Messages.
A.25
Validity-Period Time to live for a Short Message in a Service Centre. After the expiration of the Validity Period the SM shall be deleted within the Service Centre and a Status Report might be returned to the Sending User.
.
.
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.