1、 Standard ECMA-325 June 2001 Standardizing Information and Communication Systems Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.ch Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Short Message Service . Standard ECMA-32
2、5 June 2001 Standardizing Information and Communication Systems Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.ch IW ECMA-325.doc 04-09-02 09,38 Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Short Message Service (QSI
3、G-SMS) . 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 Ope
4、n 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 PSS
5、1 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 pra
6、gmatic 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 Septem
7、ber 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 S
8、msSubmitRes := SEQUENCE serviceCentreTimeStamp ServiceCentreTimeStamp, protocolIdentifier 2 IMPLICIT ProtocolIdentifier OPTIONAL, userData 3 IMPLICIT UserData OPTIONAL, smsExtension SmsExtension OPTIONAL Corrected SmsSubmitRes := SEQUENCE serviceCentreTimeStamp ServiceCentreTimeStamp, protocolIdenti
9、fier 3 IMPLICIT ProtocolIdentifier OPTIONAL, userData 4 IMPLICIT UserData OPTIONAL, smsExtension SmsExtension 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
10、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.
11、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, recipientAd
12、dress PartyNumber, recipientName Name OPTIONAL, destinationAddress PartyNumber, staus Staus, priority BOOLEAN DEFAULT FALSE, moreMessagesToSend BOOLEAN DEFAULT FALSE, statusReportQualifier BOOLEAN DEFAULT FALSE, protocolIdentifier ProtocolIdentifier OPTIONAL, userData UserData OPTIONAL, smsExtension
13、 SmsExtension OPTIONAL Corrected SmsStatusReportArg := SEQUENCE messageReference MessageReference, serviceCentreTimeStamp ServiceCentreTimeStamp, dischargeTime DischargeTime, recipientAddress PartyNumber, recipientName 10 Name OPTIONAL, destinationAddress PartyNumber, staus Staus, priority 11 IMPLIC
14、IT 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 imp
15、licitly tagged CHOICE-structures as shown in the table below. It shows that the context-specific 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 conte
16、xt-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
17、 them were received by the decoder, it is not clear which of the three elements is received. PartyNumber := CHOICE unknownPartyNumber 0 IMPLICIT NumberDigits, publicPartyNumber 1 IMPLICIT PublicPartyNumber, dataPartyNumber 3 IMPLICIT NumberDigits, telexPartyNumber 4 IMPLICIT NumberDigits, privatePar
18、tyNumber 5 IMPLICIT PrivatePartyNumber, nationalStandardPartyNumber 8 IMPLICIT NumberDigits Name := CHOICE namePresentationAllowed NamePresentationAllowed, namePresentationrestricted NamePresentationRestricted, nameNotAvailable NameNotAvailable NamePresentationAllowed := CHOICE namePresentationAllow
19、edSimple 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 ambi
20、guity (optional elements indistinguishable). Original SmSubmitParameter := SEQUENCE protocolIdentifier ProtocolIdentifier, validityPeriod ValidityPeriod OPTIONAL, statusReportRequest BOOLEAN DEFAULT FALSE, replyPath BOOLEAN DEFAULT FALSE, rejectDuplicates BOOLEAN DEFAULT FALSE Corrected SmSubmitPara
21、meter := SEQUENCE protocolIdentifier ProtocolIdentifier, validityPeriod ValidityPeriod OPTIONAL, statusReportRequest 11 IMPLICIT BOOLEAN DEFAULT FALSE, replyPath 12 IMPLICIT BOOLEAN DEFAULT FALSE, rejectDuplicates 13 IMPLICIT BOOLEAN DEFAULT FALSE Reason for change: see above. Insert tags to remove
22、ambiguity (optional elements indistinguishable). Original SmDeliverParameter := SEQUENCE protocolIdentifier ProtocolIdentifier, serviceCentreTimeStamp ServiceCentreTimeStamp, priority BOOLEAN DEFAULT FALSE, moreMessagesToSend BOOLEAN DEFAULT FALSE, statusReportIndication BOOLEAN DEFAULT FALSE, reply
23、Path BOOLEAN DEFAULT FALSE Corrected SmDeliverParameter := SEQUENCE protocolIdentifier ProtocolIdentifier, serviceCentreTimeStamp ServiceCentreTimeStamp, priority 11 IMPLICIT BOOLEAN DEFAULT FALSE, moreMessagesToSend 12 IMPLICIT BOOLEAN DEFAULT FALSE, statusReportIndication 13 IMPLICIT BOOLEAN DEFAU
24、LT FALSE, replyPath 14 IMPLICIT BOOLEAN DEFAULT FALSE Reason for change: see above. Insert tags to remove ambiguity. Original SmsDeliverResChoice := CHOICE nul NUL, protocolIdentifier ProtocolIdentifier, userData UserData, resChoiceSeq ResChoiceSeq ResChoiceSeq := SEQUENCE protocolIdentifier Protoco
25、lIdentifier, userData UserData SmsStatusReportResponseChoice := CHOICE nul NUL, protocolIdentifier ProtocolIdentifier, userData UserData, resChoiceSeq ResChoiceSeq Corrected SmsDeliverResChoice := CHOICE nul NUL, protocolIdentifier ProtocolIdentifier, userData 0 IMPLICIT UserData, resChoiceSeq 1 IMP
26、LICIT ResChoiceSeq ResChoiceSeq := SEQUENCE protocolIdentifier ProtocolIdentifier, userData UserData SmsStatusReportResponseChoice := CHOICE nul NUL, protocolIdentifier ProtocolIdentifier, userData 0 IMPLICIT UserData, resChoiceSeq 1 IMPLICIT ResChoiceSeq Reason for change: Elements UserData and Res
27、ChoiceSeq 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 July 2002 Summary Following is a summary of errors detected and corrected in Standard ECMA-325, Private Integrated Service
28、s 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 t
29、he 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 Ident
30、ifier 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) shortmessage-service-operations-asn1-97(1) Corrected iso(1) identified-organiz
31、ation(3) icd-ecma(12) standard(0) qsig-short-message-service(325) shortmessage-service-operations-asn1-97(1) - i - Table of contents 1 Scope 1 2 Conformance 1 3 References (normative) 1 4 Definitions 2 4.1 External definitions 2 4.2 Other definitions 3 4.2.1 Receiving User Case 3 4.2.2 Receiving Use
32、r PINX 3 4.2.3 Sending User PINX 3 4.2.4 Sending User Message Centre 3 4.2.5 Short Message Entity 3 4.2.6 Receiving User Message Centre 3 5 Acronyms 3 6 Signalling Protocol for the support of SMS 4 6.1 SMS description 4 6.2 SMS operational requirements 4 6.2.1 Provision/Withdrawal 4 6.2.2 Requiremen
33、ts on a Sending User PINX 4 6.2.3 Requirements on a Sending User Message Centre 4 6.2.4 Requirements on a Service Centre 4 6.2.5 Requirements on a Receiving User PINX 4 6.2.6 Requirements on a Receiving User Message Centre 4 6.3 SMS coding requirements 5 6.3.1 Operations 5 6.3.2 Information Elements
34、 11 6.3.3 Messages 11 6.4 SMS State definitions 11 6.4.1 States at the Sending User PINX and at the Sending User Message Centre 11 6.4.2 States at a Service Centre 12 6.4.3 States at a Receiving User PINX 12 6.4.4 States at a Receiving User Message Centre 12 6.5 SMS signalling procedures 13 6.5.1 Ac
35、tions at a Sending User PINX/ Sending User Message Centre 13 6.5.2 Actions at a Sending User Message Centre 15 6.5.3 Actions at a Service Centre 15 6.5.4 Actions at a Receiving User PINX 19 6.5.5 Actions at a Receiving User Message Centre 21 6.6 SMS impact on interworking with public ISDNs 22 6.7 SM
36、S impact on interworking with non-ISDNs 22 - ii - 6.8 Protocol Interactions between SMS and supplementary services and ANFs 22 6.8.1 Calling Line Identification Presentation (SS-CLIP) 23 6.8.2 Connected Line Identification Presentation (SS-COLP) 23 6.8.3 Calling/ Connected Line Identification Restri
37、ction (SS-CLIR) 23 6.8.4 Calling Name Identification Presentation (SS-CNIP) 23 6.8.5 Calling/ Connected Name Identification Restriction (SS-CNIR) 23 6.8.6 Connected Name Identification Presentation (SS-CONP) 23 6.8.7 Completion of Calls to Busy Subscriber (SS-CCBS) 23 6.8.8 Completion of Calls on No
38、 Reply (SS-CCNR) 23 6.8.9 Call Transfer (CT) 23 6.8.10 Call Forwarding Unconditional (SS-CFU) 23 6.8.11 Call Forwarding Busy (SS-CFB) 23 6.8.12 Call Forwarding No Reply (SS-CFNR) 23 6.8.13 Call Deflection (SS-CD) 23 6.8.14 Path Replacement (ANF-PR) 23 6.8.15 Call Offer (SS-CO) 23 6.8.16 Call Intrusi
39、on (SS-CI) 23 6.8.17 Do Not Disturb (SS-DND) 23 6.8.18 Do Not Disturb Override (SS-DNDO) 23 6.8.19 Advice of charge (SS-AOC) 24 6.8.20 Recall (SS-RE) 24 6.8.21 Call Interception (ANF-CINT) 24 6.8.22 Transit Counter (ANF-TC) 24 6.8.23 Route Restriction Class (ANF-RRC) 24 6.8.24 Message Waiting Indica
40、tion (SS-MWI) 24 6.8.25 Wireless Terminal Location Registration (SS-WTLR) 24 6.8.26 Wireless Terminal Mobility Incoming Call (SS-WTMI) 24 6.8.27 Wireless Terminal Mobility Outgoing Call (SS-WTMO) 24 6.8.28 Authentication of a WTM user (SS-WTAT) 24 6.8.29 Authentication of the PISN (SS-WTAN) 24 6.8.3
41、0 Private User Mobility Incoming Call (ANF-PUMI) 24 6.8.31 Private User Mobility Outgoing Call (ANF-PUMO) 24 6.8.32 Private User Mobility Registration (SS-PUMR) 24 6.8.33 Common Information (ANF-CMN) 24 6.8.34 Call Priority Interruption (Protection) (SS-CPI(P) 24 6.8.35 Single Step Call Transfer (SS
42、-SSCT) 24 6.8.36 Simple Dialog (SS-SD) 24 6.8.37 Call Identification and Call Linkage (ANF-CIDL) 24 6.9 SS-SMS Parameter values (Timers) 25 6.9.1 Timer T1 25 6.9.2 Timer T2 25 6.9.3 Timer T3 25 6.9.4 Timer T4 25 6.9.5 Timer T5 25 6.9.6 Timer T6 25 6.9.7 Timer T7 25 - iii - Annex A - Protocol Impleme
43、ntation Conformance Statement (PICS) Proforma 27 Annex B - Examples of message sequences 33 Annex C - Specification and Description Language (SDL) representation of procedures 43 Annex D - Mapping of QSIG-PDUs on GSM-PDUs 61 Annex E - Description of APDU elements 67 - iv - . 1 Scope This Standard sp
44、ecifies 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 fun
45、ctionality 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 thi
46、s 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 networ
47、k. 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 s
48、pecifications 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
49、 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. 2 Conformance In order to conform to this Standard, a PINX shall satisfy the requirements i
