USSD (Unstructured Supplementary Service Data) is a new GSM-based interactive data services when you use the phone keypad to enter some of the network has pre-established number or symbol such as * #, etc., then send that is, you can dial key to network sends a command, the network according to your instructions you need to choose the services available to you.
CDMA Adjunct Workshop, Mumbai, Jan 18, Meeting Minutes Doc#: TBA January, 2011 Contents 1 Background, Purpose, and Scope .................................................................... 4 1.1 Purpose and Scope ............................................................................................ 4 2 Attendees List..................................................................................................... 5 3 EIR/Device Management Session ..................................................................... 6 4 USSD Session..................................................................................................... 9 5 OTAPA/OTASP Session ................................................................................... 12 ii Tables Table 2-1 CDMA Adjunct Workshop Attendees ..................................................................... 5 Table 3-1 EIR/Device Management - Session ....................................................................... 8 Table 4-1 Unstructured Supplementary Services Data (USSD) - Session ........................... 11 Table 5-1 OTAPA/OTASP – Session .................................................................................. 12 iii 1 Background, Purpose, and Scope A lot of effort has been already spent in streamlining device specifications, SIM card specifications, addressing network impact related to both device and SIM cards from OMH perspective and also addressing testing requirements. The next set of requirements is to harmonize and streamline technology requirements in the adjunct spaces especially ESN Tracking/Device Management/Device Provisioning, services such as USSD, and the longer term goal is to get to where GSM has been for many years in terms of ease of deployment for CDMA carriers. There were 3 adjunct areas identified by operators and vendors who attended the OMH SIG meeting in Delhi on Nov 16th, 2010: EIR or EIR like support to address regulatory and law enforcement requirements Device management to address business requirement of tracking device activations USSD, a application that CDMA does not have that can generate additional revenues for CDMA operators (GSM supports USSD) Streamlining of Over the Air Service provisioning based upon both a mix of SIM cards and handset only devices. Qualcomm organized a CDMA adjunct workshop in Mumbai on Jan 18 th to gather high level requirements for the adjuncts. This document captures the key meeting minutes of the areas brought up and discussed by operators and vendors in the workshop. The detailed high level requirement documents for EIR, USSD and OTASP adjunct will be developed and shared seperately. 1.1 Purpose and Scope The purpose of this document is to provide minutes and describe the key areas discussed for Device Management from EIR perspective, USSD, and OTASP features during the CDMA Adjunct workshop held in Mumbai on Jan 18 th 2011. The work shop was attended by CDMA operators and vendors. The meeting discussion areas captured in this document can be used as a starting point to generate detailed requirements documents for each feature. 4 2 Attendees List Table 2-1 lists the attendees in the CDMA Adjunct Workshop. No First Name: Last Name: Email Address: Company: 1. Eddie DeCurtis email@example.com Interop Technologies 2. Amit Sethi firstname.lastname@example.org PT. Smart Telecom 3. Vaibhav Surve email@example.com Reliance Communications 4. Trishala Nambiar firstname.lastname@example.org Reliance Communication 5. Vinay Agrawal email@example.com Reliance Communications 6. Suresh Dabbara firstname.lastname@example.org Reliance Communications 7. Pravin Ubale email@example.com Reliance communications 8. Lakshana Panchal firstname.lastname@example.org Reliance Communications 9. Karan Talwar email@example.com Reliance Communications 10. Hari Cherukuri firstname.lastname@example.org Reliance Communications 11. Ashish Malik email@example.com Reliance Communications 12. Ankit Kumar firstname.lastname@example.org Reliance Communications 13. Anand Muthiah Sankar email@example.com Reliance Communications Ltd 14. Amrut Kale firstname.lastname@example.org Reliance Communications 15. Rajesh Gandhi email@example.com TTSL 16. Manish B. firstname.lastname@example.org TTSL 17. Pradeep Roy email@example.com TTSL 18. Krishna P.S,R firstname.lastname@example.org TTSL 19. Sistema Shyam TeleServices Manoj Shrivastava email@example.com Limited 20. Sistema Shyam TeleServices Pradeep Kumar firstname.lastname@example.org Limited 21. Sistema Shyam TeleServices Ajay Jha email@example.com Limited 22. Sistema Shyam TeleServices Anil Kumar Tiwari firstname.lastname@example.org Limited 23. Prem Kumar email@example.com CDG 24. Pulin Patel firstname.lastname@example.org Indusface 25. Nakul Duggal email@example.com Qualcomm 26. Siva Veerepalli firstname.lastname@example.org Qualcomm 27. Hardeep Saini email@example.com Qualcomm 28. Ranjoo Koshy firstname.lastname@example.org Qualcomm 29. Arun Handoo email@example.com Qualcomm 30. Nirmesh Yadav firstname.lastname@example.org Qualcomm 31. Keyur Shah email@example.com Qualcomm 32. Gaurav Lamba firstname.lastname@example.org Qualcomm Inc Table 2-1 CDMA Adjunct Workshop Attendees 5 3 EIR/Device Management Session In the EIR discussions, 3 possible solutions were discussed in the adjunct workshop: ESN Tracker with no EIR(current status) ESN Tracker with EIR 3GPP2 Standards Based Solution Table 3-1 covers the key areas discussed during the EIR and Device Management Session. No Key Areas Discussed Notes 1 Telecom Regulatory Authority Of India (TRAI) requires all CDMA While carriers have implemented ESN operators in India to implement an EIR, and block devices with tracking type proprietary solutions a invalid or all Zero ESN/MEID. There are 2 sources of invalid central EIR data base is not yet devices: available. Illegal import Local reflash that results in all-zero ESN Most operators have implemented some sort of proprietary ESN tracking solutions to track the association between the MEID/ESN of the device with the SF_EUIMID/RUIMID of the card. However, this information is not currently being used to actively block devices with invalid HW IDs from making calls. This requires sending both the HW id of the device and HW Id of the card OTA to the operator and appropriate action taken to block the call if the device has invalid ESN/MEID 2 CDMA operators require mechanisms to authenticate valid GSM IMEI Authentication Advantage: ESN/MEIDs of devices registering on their network. This will require type approval bodies such as TEC to maintain a IMEI authenticity is available database of valid ESNs/MEIDs. via a unique 6 digit TAG codes are released and uploaded on GSMA site in a private The ESN/MEID allocation is done by TIA. This data needs to be database which carriers have rd shared in an open manner (GSMA like, via a 3 party central access to database) and a formal process put in place to ensure a central All IMEIs are registered with database is maintained to ensure the sanctity of the data. . type approval local bodies, such as TEC in India) to 6 Unlike GSM operators, CDMA operators currently do not have identify whether an IMEI is access to ESN/MEID information of the open market devices valid or not. registering on their network. A GSM handset is not allowed to register on the network if its TAG code is not on GSMA site (IMEI is not registered). 3 All CDMA operators require a central EIR database containing MSAI may be the logical entity in India white list, black list and grey list, set up by a neutral 3rd party that to set up EIR database. Smart Telecom can be shared by local Indian operators and possibly operators requested if MSAI is going to set up outside of India. such a data base in India how can non- India carriers such as Smart Telecom A white list contains the identity of devices that are allowed to get access to the data base. MTS access service for normal operation. mentioned that the central database will help in launching value added A black list contains identity of devices that are not allowed to applications access service (for example, stolen devices with invalid HW Id). A grey list contains identity of devices that need to be actively tracked. 4 All operators require management of SIM activations with specific devices for the purpose of marketing bundles to ensure operator awareness of specific models of devices, and device capability that is associated with certain subscription and customers. Carriers are looking for return on subsidy given to the customer on usage behavior 5 A standards based solution is preferred by operators due to There is a standards based solution following limitations of ESN Tracker solution CDMA Rel E with Prev 12 (1x Advanced) will not solve the problem ESN tracker adds latency to stolen device detection and completely due to the missing pieces in it does not meet the regulatory requirement of not the solution and following limitations: allowing stolen devices with invalid ESN to access the network. Association between the MEID Reliability of MO SMS in SMS tracker application is not and subscription identification good. At times the ESN tracker SMS is generated by the (card ID) is still not addressed device before the subscription is activated by the network in the standard resulting in rejection of the SMS. Will not work on Rel 0 legacy devices 6 To address current EIR requirement, a short term and a long Qualcomm will generate high level term approach is needed. system requirements and share with all participants. Subsequent to finalization Carriers recommend the following options: of these, QC will propose a solution and corresponding design Short Term Approach: ESN Tracking + EIR requirements to accomplish the same 7 Longer Term Approach: 3GPP2 standards based solution (when Prev 12 is available) + EIR 7 A GSM like device management solution is needed in CDMA GSM uses a triplet IMSI/IMEI/MISDN to ecosystem. Most GSM devices have a device manager client query a device. CDMA can use the application based on GSM 11.14 standard on RUIM. OMA-DM following triplet MEID, RUIM ID, MDN can be used to provide a similar functionality for CDMA device management. OMA-DM client on device can be triggered via network initiated or mobile initiated sessions to turn on and turn off features OTA (e.g. voice chats) 8 Most ESN tracking proprietary solutions use SMS bearer. Hence Qualcomm will investigate the provisioning of SMSC address should be done in the RUIM card possibility of addressing SMSC to address roaming. address to the RUIM card to address roaming requirement 9 There is a need to include MEID in CDR records or a mechanism to correlate EIR information with CDR records Table 3-1 EIR/Device Management - Session 8 4 USSD Session USSD (Unstructured Supplementary Services Data) is a service, which allows interactive communication between the user and the application. USSD has been launched by many GSM carriers and some of the popular services launched using USSD include: Menu browsing, Balance Enquiry, Prepaid Recharge, Music Service, Group Calls, Conference Service, Callback Service, Information Services (News, Sports, Weather, Stock quotes),“Push” Services (Voting, Emergency Information, Customer Care),Contests, Mobile Money transactions, etc. There is considerable interest in CDMA operators to launch similar services. Three approaches were discussed in the adjunct workshop: Flash SMS based USSD o This solution provides limited USSD services for non-interactive applications. Dialed Digit based USSD o This solution is GSM like and it supports interactive applications. Standards Based Solution (using a new data burst type) Table 4-1 covers the key areas discussed during the USSD Session. No Key Areas Discussed Notes 1 CDMA operators do not offer USSD type services due to a lack of solution. Not having USSD service puts CDMA at a competitive disadvantage against GSM. A GSM like USSD solution is needed by CDMA operators. 2 For non-interactive USSD services like tracking pre-paid balance, Flash SMS can be used. The requirements on defining flash SMS and displaying the flash SMS are defined in standards or GHRC CDG Doc 191. 9 3 Many handsets in market today do not support flash SMS. Flash SMS support should be made mandatory for open market handsets. 4 Some device manufactures do not parse the SMS header correctly to display flash SMS on screen and instead route the flash SMS to SMS inbox by treating it like normal SMS. It is required that device manufacturers parse SMS header and detect and display flash SMS as specified in standards or CDG 191. 5 Usage of USSD is increasing. USSD is being increasingly tied to advertising, and now it is also being used to plug in with enterprise services, device management, and in M2M market. New requirements will be needed to address these areas of growth in USSD usage. 6 A dialed digit based USSD solution is required and is perhaps the most promising solution. A separate specification is needed to cover dialed digit based USSD feature. The specification should cover: o End to End interactive session set up o Maintaining Session continuity for interactivity o Thin UI client existence on the device for presentation layer. Leverage native UI defined in CDG 191 for presentation layer o Allow SIM based application or downloadable applications to provide presentation layer functionality. o If a downloadable application provides presentation layer functionality it should override native UI o Dialed string are sent to the network, o End to End call flows showing sending and receiving of the digits by the device, digits trapping by MSC, and routing to USSD gateway thereby bypassing SMSC o Solution should have no impact to the core network o Home SMSC address provisioned on RUIM/Device 10 7 For dialed digit solution, some codes may be reserved by the OEM for activating hidden menus for testing and debugging. This may be one of the limitations of this solution. 8 For dialed digit USSD sessions requiring session continuity the USSD session can be set up on SMS bearer using service option 14 (traffic channel). This will also alleviate any issues related to latency. 9 For dialed digit USSD sessions not requiring session continuity (balance check) the USSD session can be set up on SMS bearer using service option 6 (access channel) 10 Any proposed solution for USSD should allow appropriate This is highly desirable, however, this is fallback mechanisms for legacy devices to provide some USSD a difficult requirement to meet for functionality without the need for operator core network changes legacy devices that cannot download applications from the network. QC will investigate this further 11 Standards based 3GPP2 stage 2 proposal adds a new data burst type for USSD, but the general consensus was that this approach has many limitations: MSC changes are needed for detecting new data burst type and routing to USSD gateway Will not work with Legacy devices New registration mechanism for USSD needed so that the network knows which devices support USSD. The network may need to maintain a database to differentiate USSD capable devices from non-USSD capable devices There is a need to review the 3GPP2 stage 2 proposal and evaluate its pros and cons and compare it against dialed digit USSD solution Table 4-1 Unstructured Supplementary Services Data (USSD) - Session 11 5 OTAPA/OTASP Session New requirements for OTAPA/OTASP were also discussed. Table 5-1 covers the key areas discussed during the OTAPA/OTASP Session. No Key Areas Discussed Notes 1 Operators need to get their vendors to implement a front end to the OTAF system to allow creation of a concatenated PRL binary from IS-683A and IS-683C PRLs, for provisioning over the air using OTAPA/SP 2 3GPD parameters update needed using OTASP. Some OTAF vendors already support this. Operators have not been successful in pushing this requirement through OEMs. A request was made to add these requirements to OMH specifications so that it can be addressed internally by Qualcomm 3 There are fields in OMH cards that cannot be updated over OTASP (e.g. URLs, service provider names, etc) as some additional fields were added to RUIM rev D and OTASP specs have not been updated since. There is a need to review new fields that need to be incorporated in OTASP specifications 4 Investigate and check if Bearer Independent Protocol (BIP) will work on RUIMs Table 5-1 OTAPA/OTASP – Session 12
Pages to are hidden for
"LDC.C R1"Please download to view full document