1、 TIA-4946 February 2012System Requirements for Unstructured Supplementary Services Data NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvem
2、ent 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 member or non-member of TIA from manufacturing or selling products not confo
3、rming 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 adopted by TIA in accordance with the American National Standards Institute
4、 (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 address all safety problems associated with its use or all applicable regulatory
5、 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-4946, formulated under the cognizance of the TIA TR-45 Mobile (b) there is n
6、o 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 process. The use or practice of contents of this Document may involve the use of
7、 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 patent applications are claimed and called to TIAs attention, a statement from t
8、he 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 neither be a party to discussions of any licensing terms or conditions, which
9、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 suggested or provided in the Manual have been complied with as respects the Docume
10、nt 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 designated as a standard, specification, recommendation or otherwise), whether such
11、 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 IPR or letters of assurance relating to any such Normative Reference; (ii) T
12、IAs 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 records or publications of the other SSO shall not constitute identification to TI
13、A 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 products, designs or services or any claims of compliance with the contents of the
14、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 MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PRO
15、PERTY 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, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE
16、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, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQ
17、UENTIAL 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 IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DA
18、MAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. 3GPP2 S.R0147-0 v1.0 EDITOR Aleksandar Gogic, +1 858 651 5386, REVISION HISTORY REVISION HISTORY Revision Description of changes Date Ver. 1.0 Initial Publica
19、tion December 2011 3GPP2 S.R0147-0 v1.0 i Table of Contents 1 Table of Contents .i 2 FOREWORD ii 3 1 SCOPE 1 4 1.1 Document Conventions .1 5 2 REFERENCES 1 6 3 INTRODUCTION .1 7 4 DEFINITIONS AND ABBREVIATIONS 2 8 5 GENERAL FEATURE DESCRIPTION .2 9 5.1 Description .2 10 5.2 Use Cases and Example Ser
20、vices 3 11 6 DETAILED REQUIREMENTS 5 12 6.1 Requirements Scope .5 13 6.2 System Requirements .5 14 6.3 Radio Interface Requirements .6 15 6.4 Mobile Station Requirements 6 16 6.5 Network Requirements 6 17 6.6 Performance Goals and Requirements .6 18 19 20 3GPP2 S.R0147-0 v1.0 ii FOREWORD 1 2 This st
21、andard was prepared by Third Generation Partnership Project 2 (3GPP2) 3 TSG-S. 4 This foreword is not part of this document. 5 6 3GPP2 S.R0147-0 v1.0 1 1 SCOPE 1 This document describes support for Unstructured Supplementary Services 2 Data (USSD) in cdma200011.1 Document Conventions 4 circuit-switc
22、hed systems. 3 “Shall” and “shall not” identify requirements to be followed strictly to conform 5 to this document and from which no deviation is permitted. “Should” and 6 “should not” indicate that one of several possibilities is recommended as 7 particularly suitable, without mentioning or excludi
23、ng others, that a certain 8 course of action is preferred but not necessarily required, or that (in the 9 negative form) a certain possibility or course of action is discouraged but not 10 prohibited. “May” and “need not” indicate a course of action permissible within 11 the limits of the document.
24、“Can” and “cannot” are used for statements of 12 possibility and capability, whether material, physical or causal. 13 14 2 REFERENCES 15 Informative References 16 The following documents do not contain provisions of the specification. They 17 are listed to aid in better understanding this specificat
25、ion. 18 19 1 3GPP TS 22.090, USSD Stage 1 20 2 3GPP TS 29.002, Mobile Application Part (MAP) specification 21 3 3GPP TS 23.038, Alphabets and Language Specific Information 22 23 3 INTRODUCTION 24 USSD is a mechanism to provide basic data services to devices with 25 simple user interface capabilities
26、 and low data rates that has previously 26 been implemented in GSM systems 1. This specification describes an 27 adaptation to cdma2000 systems that are compatible with GSM USSD 28 servers. 29 30 1cdma2000is the trademark for the technical nomenclature for certain specifications and standards of the
27、 Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States. 3GPP2 S.R0147-0 v1.0 2 4 DEFINITIONS AND ABBREVIATIONS 1 2 Term Definition GSM Global System f
28、or Mobility DBM Data Burst Message kbps kilo-bits per second MAP Mobile Application Part MMI Man-Machine Interface MS Mobile Station SMS Short Message Service UA User Agent USSD Unstructured Supplementary Services Data 3 5 GENERAL FEATURE DESCRIPTION 4 5.1 Description 5 Unstructured Supplementary Da
29、ta Services offer a simple but broad 6 category of mobile data services, without use of Internet Protocol on the 7 MS, making it available on basic mobile devices with limited multimedia 8 and protocol support. 9 There are two modes of USSD: 10 (a) Man-Machine Interface (MMI) mode 11 In MMI-mode USS
30、D-enabled MS transports user-entered character 12 strings to the network; or the MS displays to the user character 13 strings generated by a network entity. This provides a simple, 14 interactive, text-based user interface. 15 (b) Application mode 16 In application mode USSD allows the transport of
31、data between a 17 network entity and a User Agent (UA) entity within the Mobile Station 18 (MS). This UA entity is something other than a simple display of 19 received text. For example, for network generated Application Mode 20 USSD communication, the data may not represent a legible string of 21 c
32、haracters but may be an application-specific message; hence it is not 22 to be written on the MSs display. 23 3GPP2 S.R0147-0 v1.0 3 USSD is generally characterized by short transmissions of small 1 amounts of data, not requiring a high data rate (less than 1 kbps is 2 typically sufficient). Hence a
33、 radio transmission mechanism such as the 3 Data Burst Message (DBM) in cdma2000 is sufficient to support this type 4 of communication. 5 Note that the data rate of 1 kbps is meant to convey an order of 6 magnitude, not a precise or absolute limit; higher data rates are 7 permissible. Considering th
34、e small payloads expected in USSD, a data 8 rate of this order of magnitude is sufficient to provide acceptable 9 performance. 10 5.2 Use Cases and Example Services 11 There are numerous examples of usage of USSD to provide a variety of 12 telecommunication services and applications. Some illustrati
35、ve examples 13 are briefly described here. Potential for new types of services and 14 applications is significant. 15 Account Balance: Getting information for the balance of a prepaid 16 phone. The balance can be requested by the user or can be sent to 17 the user, e.g., if it falls below a certain
36、amount. A similar 18 application would be to obtain bank balance, or confirmation of a 19 banking or credit card transaction (e.g., on an account shared with 20 a minor); 21 Election Results: Voting results can be viewed and voting statistics 22 obtained on mobile phones during vote counting in an e
37、lection. It 23 can be provided real time, and elaborated for different regions of a 24 country. 25 Location-Specific Data: Tourists can obtain information that varies 26 depending on their location. This can be particularly useful in 27 cases of many visitors, e.g. during large sporting events. A se
38、rvice 28 such as this was implemented during 2008 Summer Olympics in 29 Beijing, China. Tourists can use a USSD application to get 30 coupons for events in a visited location (Russian tourists can use 31 such an application when visiting Turkey). 32 3GPP2 S.R0147-0 v1.0 4 Parking Management System:
39、Some European cities have 1 deployed a parking management system using USSD. When using 2 city street parking, the driver sends a message to a number 3 displayed on street signs (numbers vary from parking zone to 4 parking zone). The content of the message is the car license plate 5 number. The repl
40、y confirms the parking ticket purchase and gives 6 the expiry time, as well as charge information. Parking 7 enforcement personnel have access to the database of all parked 8 cars, and can check if parking is valid for any car parked on the 9 street (e.g. by querying by license plate number from the
41、 database). 10 The driver gets 5-minute warning on the mobile phone that 11 parking ticket is about to expire, so he/she can extend it, or move 12 the vehicle. 13 This last example is illustrative of potential intricacy of some USSD 14 applications, as well as their value. In this case, the applicat
42、ion involves 15 not only sending a message (and the associated telephone company 16 accounting), but also city accounting/transaction processing (a 17 mCommerce transaction), maintaining of current database of parked 18 cars and parking expiration times, triggering of the expiry messages, as 19 well
43、 as a system of allowing the parking attendants to access the 20 database remotely and perform queries, to name a few service 21 components. Though the user experience is simple text messaging 22 available on any phone, the associated USSD application has many 23 valuable facets of a complex and use
44、ful service, but one that is much 24 less complex to implement than installing parking meters and collecting 25 coins. 26 27 3GPP2 S.R0147-0 v1.0 5 6 DETAILED REQUIREMENTS 1 6.1 Requirements Scope 2 The intent of the requirements outlined is to describe features for a 3 cdma2000 based communication
45、system that supports USSD. This does 4 not represent an imposition for network entities involved or MS to 5 support such capabilities in a given product; nor is there an imposition 6 of any deployment requirements on a network operator. 7 8 6.2 System Requirements 9 USSD-01 Direction and Modes of Co
46、mmunication: The system shall 10 support two-way USSD capability for two different modes of 11 communication between the MS and a USSD service entity: 12 MMI mode (displayable character string) and application 13 mode (not-to-be-displayed strings). 14 USSD-02 Compatibility: cdma2000 based USSD syste
47、m shall 15 interwork with existing USSD applications. They shall use 16 USSD protocol messages, USSD message parameters and 17 USSD error codes that are identical to or easily translated to 18 or from the USSD protocol elements defined in GSM version 19 of the service (see 1, 2, and 3). 20 USSD-03 V
48、oice Service Simultaneity: It shall be possible to conduct 21 USSD communication while an MS is on a voice call. It shall 22 be possible to conduct USSD communication when an MS is 23 not on a voice call. 24 USSD-04 Protocol Characteristics: The USSD communication 25 should employ a protocol with lo
49、w signaling overhead. 26 USSD-05 Roaming Ability: USSD shall be supported while roaming if 27 the roaming partner network supports USSD. 28 USSD-06 Character Set Support: USSD shall support comprehensive 29 international character sets (see 3). Any given 30 implementation may be confined to a limited number of 31 character sets (e.g., those relevant in geographic locality). 32 There should be graceful handling by both the MS and the 33 USSD application servers of any character set 34 incompatibility. 35 36 3GPP2 S.R0147-0 v1.0 6 6.3 Radio In
