TIA-4968-A-2013 Unstructured Supplementary Service Data (USSD) Service Options for Spread Spectrum Systems Service Options 78 and 79.pdf

1、 TIA-4968-A (Revision of TIA-4968) June 2013Unstructured Supplementary Service Data (USSD) Service Options for Spread Spectrum Systems: Service Options 78 and 79 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between

2、manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any me

3、mber or non-member of TIA from manufacturing or selling products not conforming to such Standards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publications are a

4、dopted by TIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to addres

5、s all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (From Project No. TIA-PN-49

6、68-A, formulated under the cognizance of the TIA TR-45 Mobile (b) there is no assurance that the Document will be approved by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing proc

7、ess. The use or practice of contents of this Document may involve the use of intellectual property rights (“IPR”), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending pate

8、nt applications are claimed and called to TIAs attention, a statement from the holder thereof is requested, all in accordance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will ne

9、ither be a party to discussions of any licensing terms or conditions, which are instead left to the parties involved, nor will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices sugges

10、ted or provided in the Manual have been complied with as respects the Document or its contents. If the Document contains one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designa

11、ted as a standard, specification, recommendation or otherwise), whether such reference consists of mandatory, alternate or optional elements (as defined in the TIA Engineering Manual, 4thedition) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for

12、IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs policy of encouragement of voluntary disclosure (see Engineering Manual Section 6.5.1) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IPR in the record

13、s or publications of the other SSO shall not constitute identification to TIA of a claim of Essential Patent(s) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise investigate product

14、s, designs or services or any claims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS

15、MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATION

16、, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCL

17、UDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN

18、 IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. 3GPP2 C.S0105-A v1.0 Revision History Revision Description of Changes Date Rev 0 v1

19、.0 Publication June 2012 Rev A v1.0 Addition of capability of sending a USSD message over an access channel. June 2013 3GPP2 C.S0105-A v1.0 i Table of Contents 1 1 Introduction 1 2 1.1 Scope . 1 3 1.2 Requirements Language . 1 4 1.3 Normative References . 2 5 1.4 Informative References . 2 6 1.5 Ter

20、ms and Abbreviations . 2 7 2 Mobile signaling protocol . 3 8 2.1 Operation . 3 9 2.2 Parameters 3 10 2.2.1 Data Burst Type (BURST_TYPE) 3 11 2.2.2 Service Options . 3 12 2.2.3 USSD Message Format . 3 13 2.3 MS Signaling Procedures 4 14 2.3.1 Negotiation for the USSD Service Option . 4 15 2.3.2 MS Se

21、nding USSD Message 4 16 2.3.3 MS Receiving USSD Message 5 17 2.3.4 USSD Client Actions . 5 18 19 3GPP2 C.S0105-A v1.0 ii Table of Tables 1 Table 1 USSD Message Format . 3 2 3 3GPP2 C.S0105-A v1.0 iii Foreword 1 This foreword is not part of this document. 2 This document is related to: 3 3GPP2 C.R100

22、1-H v1.0, that provides service option number assignments. 4 3GPP2 X.S0065-0 v1.0, that provides core network support. 5 3GPP2 C.S0105-A v1.0 1 1 Introduction 1 1.1 Scope 2 This document defines radio interface support for USSD in cdma20001Spread 3 Spectrum Systems. 4 Unstructured supplementary serv

23、ice data (USSD) allows the Mobile Station (MS) 5 user and a PLMN operator defined application to communicate in a way which is 6 transparent to the MS and to intermediate network entities. The mechanism 7 allows development of PLMN specific supplementary services. 8 There are two modes of USSD: MMI-

24、mode and application mode. MMI-mode 9 USSD is for the transparent transport of MMI strings entered by the user to the 10 network and for the transparent transport of text strings from the network that 11 are displayed by the mobile for user information. 12 Application mode USSD is for the transparen

25、t transport of data between the 13 network and the UE. Application mode USSD is intended to be used by 14 applications in the network and their peer applications in the UE. 15 USSD may be initiated by the MS user, or by the network. Unlike Short Message 16 Service (SMS) messages, USSD messages creat

26、e a real-time connection during a 17 USSD session. The connection remains open, allowing a two-way exchange of a 18 sequence of data. Several examples of how USSD Services are used include: Pre-19 paid balance Inquiry, Balance Transfer (payment from ones balance to another 20 balance), Voting (“Plea

27、se rate our customer service: 1=Good, 2=OK, 3=Bad” after 21 a call to a Customer Service Center), and Call Me (requesting another party to 22 call you). 23 1.2 Requirements Language 24 “Shall” and “shall not” identify requirements to be followed strictly to conform to 25 this document and from which

28、 no deviation is permitted. “Should” and “should 26 not” indicate that one of several possibilities is recommended as particularly 27 suitable, without mentioning or excluding others, that a certain course of action 28 is preferred but not necessarily required, or that (in the negative form) a certa

29、in 29 possibility or course of action is discouraged but not prohibited. “May” and 30 “need not” indicate a course of action permissible within the limits of the 31 document. “Can” and “cannot” are used for statements of possibility and 32 capability, whether material, physical or causal. 33 1cdma20

30、00 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United Sta

31、tes. 3GPP2 C.S0105-A v1.0 2 1.3 Normative References 1 The following specifications contain provisions which, through reference in this 2 text, constitute provisions of this specification. At the time of publication, the 3 editions indicated were valid. All specifications are subject to revision, an

32、d 4 parties to agreements based on this specification are encouraged to investigate 5 the possibility of applying the most recent editions of the specifications indicated 6 below. 7 Throughout this specification reference to a tag constitutes a reference to the 8 specification identified below. 9 Ta

33、g Specification Source C.S0004 3GPP2 C.S0004-E v3.0. 3GPP2 Signaling Link Access Control (LAC) Standard for cdma2000 Spread Spectrum System. June 2011. C.S0005 3GPP2 C.S0005-E v3.0. 3GPP2 Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems. June 2011. C.S0015 3GPP2 C.S0015-

34、B v2.0. Short Message Service (SMS) for Wideband Spread Spectrum Systems. September 2005. TS24.080 3GPP TS 24.080. 3GPP Mobile radio interface layer 3 supplementary services specification. Formats and coding. TS24.090 3GPP TS 24.090. Unstructured Supplementary Service Data (USSD); Stage 3. 1.4 Infor

35、mative References 10 Tag Specification Source C.R1001 3GPP2 C.R1001-G v1.0. 3GPP2 Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Systems. June 2009. 11 1.5 Terms and Abbreviations 12 Term Definition DBM Data Burst Message C.S0005 GSM_USSD_MSG A tunneled GSM USSD message a

36、s defined in TS24.080 and explained in TS24.090 USSD_DBM_BURST 001001 USSD Unstructured Supplementary Service Data 3GPP2 C.S0105-A v1.0 3 2 Mobile signaling protocol 1 2.1 Operation 2 The MS operation is performed when the MS is to send a USSD message to the 3 USSD Gateway or when the MS receives a

37、USSD message from the USSD 4 Gateway. The operation for the MS sending the USSD message is described in 5 section 2.3.2. The operation for the MS receiving the USSD message is described 6 in section 2.3.3. 7 2.2 Parameters 8 2.2.1 Data Burst Type (BURST_TYPE) 9 The BURST_TYPE for this DBM C.S0005 is

38、 USSD_DBM_BURST which is also 10 listed in C.R1001. 11 2.2.2 Service Options 12 Service options SO 78 for rate set 1 and SO 79 for rate set 2 are used for USSD, 13 see C.R1001. 14 2.2.3 USSD Message Format 15 The format of a USSD message is a DBM using the format in the following table: 16 Table 1 U

39、SSD Message Format 17 Field Length (bits) Value MSG_NUMBER 8 1 BURST_TYPE 6 USSD_DBM_BURST NUM_MSGS 8 1 NUM_FIELDS 8 The Length of the USSD message in octets. CHARi 8 * NUM_FIELDS GSM_USSD_MSG 3GPP2 C.S0105-A v1.0 4 2.3 MS Signaling Procedures 1 2.3.1 Negotiation for the USSD Service Option 2 See C.

40、S0015 section 2.4.1.1.2.1. Treat SO 6 as SO 78, SO 14 as SO 79 and 3 “SMS Service Option” as “USSD Service Option”. 4 2.3.2 MS Sending USSD Message 5 If an MS is to send a USSD message, the USSD client within the MS shall 6 construct the message according to Table 1. The GSM_USSD_MSG part of the 7 U

41、SSD message is constructed according to TS24.080. The functional 8 definitions and contents for a GSM_USSD_MSG are defined in TS24.090. 9 If the MS is to send the USSD message over an Access Channel, Enhanced 10 Access Channel, or Reverse Common Control Channel, the transmission of the 11 Originatio

42、n Message shall follow the procedures defined in section 2.6.2.6 of 12 C.S0005. Authentication of the Origination Message may be conducted 13 according to the procedures defined in C.S0004. 14 If the MS is to send the USSD message over a traffic channel, the MS shall 15 request Service Option 78 for

43、 rate set 1 or Service Option 79 for rate set 2 if the 16 MS is in idle mode, using an Origination Message with no dialed digits to set up 17 a traffic channel to transmit the USSD message. Authentication of the 18 Origination Message may be conducted according to the procedure defined in 19 C.S0004

44、. Call processing following the transmission of the Origination Message 20 shall follow the procedures defined in C.S0005. When the MS enters the 21 Conversation Substate, the MS may transmit the USSD message. 22 If the MS has already been assigned a traffic channel, the MS shall continue to 23 use

45、the associated SO for that traffic channel. 24 The MS shall send the USSD message using the following procedures: 25 o The MS shall construct a DBM according to Table 1. 26 o The MS shall use the CHARi portion to construct the GSM_USSD_MSG 27 using the FACILITY, REGISTER, or RELEASE COMPLETE message

46、 type 28 defined in TS24.080 and described in TS24.090. 29 o The MS shall transmit the DBM on the Access Channel, Enhanced 30 Access Channel, Reverse Common Control Channel, or Traffic Channel. 31 If any SO other than SO 78 or SO 79 is connected, the MS shall remain in the 32 Conversation Substate a

47、fter acknowledgement of the DBM. 33 3GPP2 C.S0105-A v1.0 5 2.3.3 MS Receiving USSD Message 1 An MS supporting USSD shall process all DBMs addressed to the MS on the 2 Paging Channel, Forward Common Control Channel or Traffic Channel and 3 having the BURST_TYPE USSD_DBM_BURST C.R1001. The MS shall di

48、scard 4 the message without further processing if any of the following is true: 5 MSG_NUMBER field is set to a value other than 1; 6 NUM_MSGS field is set to a value other than 1; 7 NUM_FIELDS field is set to zero; 8 Otherwise, the MS shall parse the CHARi fields of the received DBM as a USSD 9 mess

49、age and shall send it to the USSD client. The USSD client shall process the 10 USSD messages according to TS24.080. The signaling procedures for the 11 received USSD DBM is as is any kind of DBM and shall be according to 12 C.S0005. 13 2.3.4 USSD Client Actions 14 The actions taken by the USSD client are as follows: 15 When a USSD transaction is to be initiated: 16 The USSD Client shall send a USSD message as defined in section 2.3.1. The 17 GSM_USSD_MESSAGE field shall be a REGISTER message containing a 18 ProcessUnstructur