CDMA Network Adjunct Workshop

Transcription

CDMA Network Adjunct
Workshop
January 2011
Mumbai
Agenda
 9:30 – 9:45 AM – Welcome and Introductions
 9:45 – 10:00 AM - Workshop format and information exchange outline
 10:00 – 11:30 AM - Device Tracking Requirements – ESN Tracker, EIR proposal
 11:30 – 11:45 - Coffee
 11:45 AM – 1:00 PM – Device Tracking Requirements – ESN Tracker, EIR (continued)
 1:00 – 2:00 PM - Lunch
 2:00 – 3:00 PM – OTAF, OTASP
 3:00 – 3:45 – USSD and Flash SMS
 4:00 – 5:00 PM – USSD and Flash SMS (continued)
 5:00 – 6:00 PM – Wrap-up and Next Steps
2
Qualcomm Proprietary and Confidential MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
2
Purpose of workshop today
 Over the past two years, the rollout of the OMH Initiative across India and South East Asia
markets has revealed that under the auspices of the CDG, member partners can collaborate to
build CDMA device, network and test specifications that allows for

A common harmonized implementation of handsets to generate economies of scale, increased device variety and bolster
the CDMA ecosystem
 OMH operators have highlighted additional areas of opportunities for harmonization of
network and adjunct harmonization across CDMA operators especially as it related to device
tracking and management, device configuration and device / network based value added
services
 Our session is focused on generating high level business, technical, regulatory and operational
requirements across 3 key areas

CDMA Device Tracking and Management and CDMA Equipment Identity Register

CDMA Device Provisioning – OTASP (evaluate incremental changes required due to OMH)

CDMA Value Added Services through USSD
 The focus in each area will be on what is possible today with no Standards or Software Impact
on network and device; as well as what is possible tomorrow with additional changes
3
3
Format
 Qualcomm team is here to facilitate the discussion
 Some basic slides describing problem statements and known
solutions in the context of our discussion today have been
developed
 Our goal is to get an interactive but structured discussion
focused primarily on
 Requirements Gathering including Technical, Business, Regulatory and
Operational aspects of these areas
 Qualcomm team will capture the discussion including all
requirements, and then circulate these in the form of a High
Level Requirements document from which standardized
specifications can be developed
4
4
Device Tracking and a Proposed EIR for CDMA
5
5
EIR – Problem Statement
 Prevent stolen devices or devices with invalid
hardware IDs from making calls
 Management of SIM card activations with specific
devices for the purposes of marketing bundles
 Operator awareness of specific models of devices, and device capability
that is associated with certain subscriptions and customers
6
HW ID tracking and EIR Solutions
Possible Solution
7
Pros
Cons
ESN Tracker with no EIR
(Present Status)
•Device and RUIM card hw identifiers
are made available to the network
•Allows the network to always
associate a subscription with a
specific device
•Cannot identify a black-listed device
without EIR database
•Latency in associating a subscription
with a specific device
ESN Tracker with EIR
Integration
In addition to the above:
•Allows ESN tracker database to
query EIR to determine if the device
is allowed to make a call
•ESN tracker obtains ESN/MEID of
the device as well as the
UIMID/EUIMID OTA, so it can use
the HW ID of the device to query the
EIR
• Calls for invalid devices can only be
disconnected with some latency after
the call is setup successfully, since
ESN tracker message uses SMS to
send the HW ID OTA to the network
• Non-standard implementation; ESN
tracker NW entity will need to
interface with EIR and also MSC or
HLR/VLR to release call when
blacklisted device is detected
Standards based EIR
Solution
• Signaling based mechanism to
detect blacklisted devices
• Similar to GSM
•Standards compliant
• Not available in 1x rel 0 (P_REV 6)
• Requires release E (P_REV 12)
changes for the network to be able to
query and receive device HW ID
and/or RUIM HW ID OTA
Open Discussion
8
Executive Summary
 3GPP2 Standards for MEID support an EIR as a carrier option. Possible solutions for
EIR implementation have been discussed.
 EIR operation is defined in 3GPP2 for MEID only, not ESN. A legacy/bogus mobile
with an ESN cannot be checked with the standard messaging.
 The current ESN Tracker implementation by CDMA carriers in India may be enhanced
to track ESN/MEID based devices by adding Normal(‘White’), Block(‘Black’) and
Track(‘Grey’) lists in the independent proprietary databases maintained by the carriers
and block services to the stolen, unauthorized, or defective mobile stations. Ultimately,
the success of such a solution to identify stolen phones depends on the extent to
which these independent databases of different operators are interconnected.
 Important to note that even linking of EIR databases/ESN Tracker databases of
different operators may not help in effectively detecting cloning of valid IMEIs in GSM
networks or MEIDs in CDMA networks.
 The ESN Tracking Applications on the RUIM cards can be made to send tracking SMS
periodically(without Network trigger) based on status commands as a timer e.g. the
ESN\MEID could be sent back to the server after every N status commands.
 Standards solution will require P_REV_12(1X Rev E also called 1x Advanced)
upgrades to Infrastructure and devices.
 Possible Vendor for CDMA EIR available.
9
Mobile Station Identifiers in CDMA
Technical Specification 3GPP2 C.S0023-D v1.0
 Electronic Serial Number (ESN) : An Electronic Serial Number (ESN) is a 32 bits
unique identifier for the Mobile Equipment. ESN is used as an input to CAVE
authentication and can be used to derive the Public Long Code Mask (PLCM).
 Mobile Equipment Identifier (MEID): Mobile Equipment Identifier (MEID) is a 56 bits
number which is used to replace ESN as the unique identification number for mobile
equipment since the ESN address space is exhausted.
 User Identity Module ID (UIMID): User Identity Module ID (UIMID) is a 32 bits unique
identification number for the Removable User Identity Module (R-UIM) card. UIMID
replaces ESN in the air interface messages and TIA-41 messages, when R-UIM card
is programmed to use UIMID instead of ESN.
 Expanded UIMID (EUIMID) : An Expanded UIMID (EUIMID) is a unique identifier for
the R-UIM that replaces the older UIMID because UIMID is also expected to be
exhausted in the near future. There are two forms of EUIMID, namely SF_UIMID and
LF_UIMID.
 Short Form UIMID (SF_UIMID): The Short Form EUIMID (SF_EUIMID) is a 56-bit identifier,
sharing address space with the MEID. A section of the MEID space would be reserved for
EUIMID allocation.
 Long Form UIMID ( LF_UIMID): The Long Form EUIMID (LF_EUIMID) is equal to the value of
Integrated Circuit Card Identifier (ICCID) of the card. The ICCID is an 18-digit BCD (72-bit)
identifier assigned to the physical R-UIM card. The ICCID is currently present on all R-UIM
cards (as well as GSM SIM cards). The ICCID is typically printed on the card, and is also
stored electronically.
10
Current challenges
 IMEI is a unique 15-digit number that identifies a mobile. It prevents the use of stolen
handsets for making calls and allows security agencies to track down a specific user.
However, handsets sold in the grey market do not come with the IMEI, a matter of
concern for security agencies, especially because most of the handsets are brought
into the country from China or Taiwan.
 Due to the lack of centralized EIR databases and no interconnection between
independent EIR databases of different carriers, preventing inter-operator cloning of
IMEIs is currently a challenge.
 CDMA carriers currently do not have EIR databases in place yet.
 There are limitations in CDMA2000 Release 0 (P_REV 6) Air Interface signaling for
simultaneously querying MEID/ESN of the device and SF_EUIMID/RUIMID of the
RUIM subscription.
 CDMA carriers currently make use of ESN Tracking wherein Device/RUIM identifiers
are tracked through SMS based mechanisms and stored in proprietary databases
independently maintained by carriers.
 Even though ESN Tracker applications help in recording card RUIM_ID and device
ESN/Pseudo-ESN/MEID pair, it still does not meet the Regulatory requirement by
Government of India barring services to stolen, unauthorized, or defective mobile
stations.
11
Suggestions by Industry bodies and GSMA
 Cellular Operators Association of India (COAI), the body representing GSM operators, has
suggested that the central registry (National Database of IMEIs) be maintained either by the
government, or the regulator or by an authorized third party, and it be linked to the GSMA
database having the white/grey/black list of all the handsets available in the market to
reduce the efforts, risk of error and cost of updating the database separately by each service
provider.
 This would also ensure that a global database of stolen devices is maintained. This also
allows devices stolen in India to be blocked in other countries thereby maximizing the value
of blacklisting as it is generally recognized that stolen devices travel across national borders.
 Adopt laws similar to that of the UK and make re-programming of IMEI numbers a criminal
offence. This position has been supported by several mobile phone operators.
 Mobile Standards Alliance of India (MSAI) is the official reporting body of GSMA for
providing Genuine IMEI numbers to GSM Devices and mobile Handsets in India. MSAI also
provides IMEI related assistance to regulatory bodies, network operators and security
agencies.
 In coordination with TIA and GSMA , the MSAI has launched the MEID service in addition to
the already existing service for Genuine IMEI Issuance [http://www.msai.in/meid.pdf]
 MSAI has support from 4 CDMA carriers(Tata Indicom, Reliance, MTS and Virgin Mobile) in
India.
12
Equipment Identity Register in CDMA Networks
 Standards for MEID support an EIR as a carrier option.
 3GPP2 X.S0008 added capabilities to ANSI-41 for
 Communication of MEID to EIR
 Communication of MEID to VLR and HLR
 EIR maintains three different lists of MEIDs, and can be queried using the
new TIA–41 CHECKMEID message:
 •Normal (‘White’) list –A list of assigned MEID code ranges (not a list of
individual MEID codes).
 •Block (‘Black’) list –A list of MEIDs that should be denied service (e.g.
because they represent stolen phones or those with service-impacting
hardware issues).
 •Track (‘Grey’) list –A list of MEIDs to be tracked (but not denied service).
This includes lost phones and those with minor hardware issues.
 EIR’s need to be globally linked or centralized to maximize their ability to
track mobile equipment.
13
Current Mechanisms used in CDMA to track
devices
 ESN Tracker Application
ESN tracker is a pre-loaded application resident on a R-UIM card that can send SMS
containing the appropriate identifier of the device’s shell (i.e. MEID or ESN if it is a
non-MEID equipped device) to the network based upon a trigger and then some
validation checks made at the back end to verify whether this particular MEID or ESN
is present in the database and is not in the black list.
 The primary objective of ESN Tracker application is to capture the serial number i.e.
ESN/Pseudo-ESN/MEID of the RUIM based devices so as to have a database of the
RUIM_ID and ESN/Pseudo-ESN/MEID pair. The ESN Tracker databases are
proprietary to the Mobile carriers.
 Lack of Central database of device serial numbers
1. Currently there is no centralized database of device serial numbers (ESN/MEID
based).
2. Even though ESN Tracker applications help in recording card RUIM_ID and device
ESN/Pseudo-ESN/MEID pair, it still does not meet the Regulatory requirement by
Government of India barring services to stolen, unauthorized, or defective mobile
stations.
14
Modified ESN Tracker Solution
 Use ESN tracker to obtain device HW ID OTA (just
as it is done today)
 Use the received HW ID to check against the EIR for
validity
 Call disconnection is requested by the ESN Tracker
network entity upon detection of black listed devices
 Requires the ESN tracker network entity to interface
with EIR (to check validity of device HW ID) and
MSC/HLR/VLR (to request call disconnect when
required)
15
Standards Solution
 CDMA200 1X Rev E (P_REV_12) upgrade: CDMA200 1X Rev E (P_REV_12 ) defined
‘MEID_ME” field to query MEID strictly as MEID from Handset and not from the RUIM card. Not
that MS (legacy) may respond with Mobile Station Reject Order if this new information is not
supported.
 Requires P_REV_12 upgrade to Network infrastructure for specifically querying the MEID of the
handset and also needs P_REV_12 terminals.
 Mobile Station Modem (MSM) and Cell Site Modem (CSM) supporting P_REV_12 are now
available from Qualcomm.
16
Standards Solution continued…
 3GPP2 C.S000x-E – 1X Advanced Specification (Radio Access)
Supports Status Request messages to provide access to the following identifiers:
1. EUIMID (SF_EUIMID or LF_EUIMID).
2. MEID_ME (the MEID even when UsgInd bit 2 indicates that SF_EUIMID overrides
MEID).
3. ESN_ME (the ESN even when UsgInd bit 1 indicates that UIMID overrides ESN).
 3GPP2 X.S0008 (TIA-928) – MEID in ANSI-41 (Core Network)
1. Revision 0 of this specification (published 07/2004) provided: Transmission of MEID
from MSC to VLR to EIR.
2. In the later revisions, MAP (Mobile Application Part) support for MEID was added.
3. The standard revisions may require possible software upgraded to




17
Interface
Interface
Interface
Interface
between
between
between
between
MSC and EIR (F-interface)
the MSC and its associated VLR (B-interface)
the HLR and the MSC (C-interface)
the HLR and the VLR (D-interface)
Check MEID procedures in CDMA
Technical specification 3GPP2 X.S0008-0
18
Check MEID procedures in CDMA
continued…
 The VLR sends a STATREQ to the Serving MSC with the MSID parameter set to
identify the target MS. The RECORD_TYPE parameter is set to request the MEID
information record.
 The mobile (may) return its MEID in the Status Response message. If it is a RUIM
based MS , then the MS will only be able to send MEID if it is specifically requested for
MEID (via MEID_ME field) that came in P_REV_12 OR if EF USGIND bit 2 value
provisioned on the R-UIM is set to 0 else SF_EUIMID will override MEID.
 The MSC sends a statreq with the requested MEID to the VLR.
 The VLR can now check the MEID in the EIR database. The VLR sends the MEID to
the EIR in the CHECKMEID.
 The EIR returns the requested equipment status to the VLR in the checkmeid. The
status may be Normal, Block, Track, or No Entry.
 Normal (‘White’) list –A list of assigned MEID code ranges (not a list of individual
MEID codes).
 Block (‘Black’) list –A list of MEIDs that should be denied service (e.g. because they
represent stolen phones or those with service-impacting hardware issues).
 Track (‘Grey’) list –A list of MEIDs to be tracked (but not denied service). This
includes lost phones and those with minor hardware issues.
19
Possible vendor for CDMA EIR
 Equipment Identify Register ZXUN EIR from ZTE Corporation.
 ZXUN EIR supports multi-network, multi-service integration and has the
ability of evolution. It simultaneously supports PSTN, PHS, GSM, UMTS, TDSCDMA, CDMA, IMS, WiMAX, wide-narrow-band access network user data
storage and service processes. It is integrated with SHLR, PHS HLR, GSM /
UMTS HLR, CDMA HLRe, HSS, EIR, MNP, FNR, AAA and other network
entities.
 ZXUN EIR realizes easily network evolution, network element integration and
management; benefits to the introduction of new services and the service
integration; facilitates data mining and analysis capabilities. With data fusion,
it leads to easy integration or converged services. The Operators regain
control of network, users, and services from converged data application,
which enhances the commercial value of primary data.
 More information about the product available at
http://wwwen.zte.com.cn/en/products/core_network/mobile_core_network/su
bscriber_profile_management/201003/t20100308_180985.html
20
References
 MEID and EUIMID Migration, [CDG 158 v2.0], Sep 2008
 Standards for MEID and Expanded UIMID (E-UIMID) v2.0 ,[email protected], May 2010
 3rd Generation Partnership Project; Technical Specification Group Services and
System Aspects; International Mobile station Equipment Identities (IMEI) (Release 7),
3GPP TS 22.016 V7.2.0 (2009-09)
 3rd Generation Partnership Project; Technical Specification Group Core Network and
Terminals; Mobile Application Part (MAP) specification (Release 9), 3GPP TS 29.002
V9.3.0 (2010-09)
 3rd Generation Partnership Project; Technical Specification Group Services and
Systems Aspects; Network architecture (3G TS 23.002 version 3.1.0)
 MAP Support for the Mobile Equipment Identity (MEID), 3GPP2 X.S0008-0,
Version 3.0, Jan 2009
 MEID Standards Update (version 1.8.4 –April 2006), TIA Committee TR-45
 Signaling Test Specification for Mobile Station Equipment Identifier (MEID) Support for
cdma2000 Spread Spectrum Systems, 3GPP2 C.S0073-A Version 1.0,Mar 2008
 Moving Forward on MEID and Expanded UIMID (E-UIMID), Revision A, Feb 2008
 http://www.gsmworld.com/our-work/public-policy/handset_theft.htm
21
 http://wwwen.zte.com.cn/en/products/core_network/mobile_core_network/subscriber_p
rofile_management/201003/t20100308_180985.html
USSD – Benefits
 USSD (Unstructured Supplementary
Services Data) is a service, which allows
interactive communication between
the user and the application
 Examples 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)
 Operator Interest
 USSD reduces operational costs (unbilled
voice calls, IVR operations)
 Increases ARPU by offering interactive
services
 Rapid implementation of new services
using USSD menu trees
 Subscriber Advantage
 Convenient, accessible from home menu
of the handset
 Interactive quick response
 Easy access using the same dialing
sequence worldwide
 Contests, Mobile Money transactions
22
22
Device Provisioning
23
23
Overview
OMH related impact
 Concatenated PRL Overview
 cPRL Provisioning
 OTASP Server Requirements
24
Concatenated PRL Overview
 Concatenated PRL (cPRL) is a concatenation of the PRL defined in IS-683A, and the Extended
PRL defined in IS-683C
 R-UIM needs to store both PRL and Extended PRL information to work with 1x and 1x/DO
terminals
 PRL required for 1x only terminal
 Extended PRL required for Hybrid Access Terminal
 cPRL was introduced to allow C.S0023-0 cards to work with 1x only and hybrid terminals
 C.S0023-0 based RUIM cards only support one file to store PRL information (EFprl). cPRL allows
download and storage of PRL and Extended PRL in EFprl.
 cPRL support was provided in AMSS for C.S0023-0 card initially. It is however, applicable to all
versions of cards including OMH RUIM.
 cPRL can be downloaded using OTASP, CCAT SMS-PP data download or UTK SMS-PP data
download methods
 A UI front end to the OTAF system, to allow input of IS-683A and IS-683C PRLs independently in
ASCII format which in turn generates a CPRL in binary form for transfer OTA, allows easy
management of PRLs
 Without this front end, a binary CPRL has to be generated off-line and provided as input to the OTAF
system (assuming the system allows binary input of PRLs for OTA provisioning)
25
PRL and Extended PRL
 PRL
Extended PRL
1x / EV-DO
IS-683-C (SSPR_P_REV=3)
 1x only
 IS-683-A
 IS-683-C (SSPR_P_REV=1)
26
PR_LIST_SIZE
16
PR_LIST_ID
16
PREF_ONLY
1
DEF_ROAM_IND
8
NUM_ACQ_RECS
9
NUM_SYS_RECS
14
EXT_ACQ_TABLE
Variable
SYS_TABLE
Variable
RESERVED
0 to 7
PR_LIST_CRC
16
PR_LIST_SIZE
16
PR_LIST_ID
16
CUR_SSPR_P_REV
8
PREF_ONLY
1
DEF_ROAM_IND
8
NUM_ACQ_RECS
9
NUM_COMMON_SUBNET_RECS
9
NUM_SYS_RECS
14
RESERVED
7
ACQ_TABLE
Variable
COMMON_SUBNET_TABLE
Variable
EXT_SYS_TABLE
Variable
RESERVED
0 to 7
PR_LIST_CRC
16
Concatenated PRL Format
Concatenated PRL Format
Concatenate PRL and Extended PRL,
followed by the package CRC.
The package CRC is calculated on all
bits of the both PRL and Extended
PRL excluding the bits of the package
CRC itself.
The concatenated PRL is stored in the
EFprl (EF 6F30).
When the existing 1x terminal reads
the EFprl containing the concatenated
PRL, it checks the PR_LIST_SIZE and
ignores the appended part (Extended
PRL and Package CRC).
Hybrid Access Terminal reads the
EFprl and determines if the appended
part exists. If it does, the Hybrid
Access Terminal uses the Extended
PRL.
27
PRL
PR_LIST_SIZE
PR_LIST_ID
PREF_ONLY
Concatenated PRL
SYS_TABLE
RESERVED
PRL
Extended PRL
Package_CRC
PR_LIST_CRC
Extended PRL
PR_LIST_SIZE
PR_LIST_ID
CUR_SSPR_P_REV
EXT_SYS_TABLE
RESERVED
PR_LIST_CRC
Concatenated PRL
PRL:
SSPR_P_REV=1
1X
Extended PRL:
SSPR_P_REV=3
1X
EV-DO
CDMA450
PACKAGE_CRC
Concatenated Preferred Roaming List Field
PR_LIST_SIZE
PR_LIST_ID
PREF_ONLY
DEF_ROAM_IND
NUM_ACQ_RECS
NUM_SYS_RECS
EXT_ACQ_TABLE
SYS_TABLE
RESERVED
PR_LIST_CRC
PR_LIST_SIZE
PR_LIST_ID
CUR_SSPR_P_REV
PREF_ONLY
DEF_ROAM_IND
NUM_ACQ_RECS
NUM_COMMON_SUBNET_RECS
NUM_SYS_RECS
RESERVED
ACQ_TABLE
COMMON_SUBNET_TABLE
EXT_SYS_TABLE
RESERVED
PR_LIST_CRC
PACKAGE_CRC
Length(bits)
16
16
1
8
9
14
Variable
Variable
0 to 7
16
16
16
8
1
8
9
9
14
7
Variable
Variable
Variable
0 to 7
16
16
Comments
Length of 683A PRL
CRC of 683A PRL
Length of Extended PRL
PRL Revision #
CRC of Extended PRL
CRC for concatenated PRL
cPRL update using OTASP
 cPRL provisioning using OTASP is done, just as PRL provisioning
per IS-683A.
 Substitute 1x only PRL with cPRL in the SSPR Download Request Message
 After verifying the package crc, ME loads cPRL into EFprl
29
System Selection with CPRL
 Legacy 1x phone will only read out the first PRL
 No backward compatibility issues
 Hybrid Access Terminal will examine whether a
second PRL is present after power on
 If a second PRL is present, first PRL will be ignored and
second PRL will be read out and used for system selection
30
Requirements for OTASP Server
 cPRL provisioning using OTASP is done, just as PRL provisioning
per IS-683A.
 Substitute 1x only PRL with cPRL in the SSPR Download Request Message
 Based on the above requirement, OTASP server needs to be
capable of replacing a PRL (IS-683A) with a concatenation of
PRL, Extended PRL (IS-683C) and a package crc, as defined
earlier in this presentation.
 The server needs to provide a user interface through which it
can accept PRL and Extended PRL, and generate a cPRL for
transmission in the SSPR Download Request Message
31
USSD and Flash SMS
32
32
USSD – Requirements for CDMA
 USSD for CDMA
 CDMA specifications today do not support USSD
 Need to be addressed
 Provide easy access to services for CDMA users
 Provide fastest, and lowest cost harmonized solution for operators to
define USSD with a focus on additional revenue generation
33
33
USSD – Scope of Solutions
34
Solution
Description
Implementation
Impact to
MS
Impact to
Network
Scope of solution
Flash SMS
Prepaid balance
tracking
Uses setting in
SMS field that
allows message
to be displayed
but not stored
No impact
No impact (SMS
message needs
to be generated
with appropriate
parameter
setting)
Push only - No
interactivity; Network
initiated push SMS with
prepaid balance;
Available today after
integration of Prepaid
IN with CDMA Network
Dialed Digits
based USSD
Full GSM-like
USSD service for
CDMA
Requires all
MSC routing
tables to be preconfigured with
dialed digit
strings or
Destination SMS
address
No impact
No network
software impact;
MSC routing and
digit analysis to
be updated for
routing based on
dial-string or
SMS Address
Full interactivity;
Requires MSC
configuration effort
across network; New
application client
required on the device;
Available today;
Compatible with
existing devices
New USSD
Service
definition
Full GSM-like
USSD service for
CDMA
New data burst
message (DBM)
introduced in
3GPP2
standards for
USSD
Minor sw
impact, MS
needs to be
upgraded to
interpret new
DBM
Minor sw impact,
RAN/MSC needs
to be upgraded
to interpret /
parse new DBM
Full interactivity;
Requires handset and
network software
upgrades including
application client; Not
compatible with existing
devices
34
Reference Architecture
Value Added
Service LAYER
3rd Party
App Servers
3rd Party
App Servers
HTTP/XML
USSD Service
LAYER
SMPP
IS-41/SS7
Operator VAS
Network Elements
SMPP
Network
Management/OSS
USSD Gateway
Platform
Operator Charging,
Provisioning
HLR
Data/IP
IS-41/SS7
OPERATOR
ACCESS LAYER
SMSC
IS-41/SS7
MSC
Packet Data
Core
IOS
RAN
35
MS
Flash SMS – Prepaid Balance Tracking
Value Added
Service LAYER
3rd Party
App Servers
3rd Party
App Servers
HTTP/XML
USSD Service
LAYER
SMPP
Operator VAS
Network Elements
SMPP
Network
Management/OSS
USSD Gateway
Platform
Not required
IS-41/SS7
Operator Charging,
Provisioning
HLR
Data/IP
IS-41/SS7
OPERATOR
ACCESS LAYER
SMSC
IS-41/SS7
MSC
Packet Data
Core
IOS
RAN
Configuration impact only
36
MS
Dialed Digits Based USSD
Value Added
Service LAYER
3rd Party
App Servers
3rd Party
App Servers
HTTP/XML
USSD Service
LAYER
SMPP
Operator VAS
Network Elements
SMPP
Network
Management/OSS
USSD Gateway
Platform
IS-41/SS7
Operator Charging,
Provisioning
HLR
Data/IP
IS-41/SS7
OPERATOR
ACCESS LAYER
SMSC
IS-41/SS7
MSC
Packet Data
Core
IOS
RAN
Configuration impact only
New element
37
MS
New USSD Data Burst Message Type
Value Added
Service LAYER
3rd Party
App Servers
3rd Party
App Servers
HTTP/XML
USSD Service
LAYER
SMPP
IS-41/SS7
Operator VAS
Network Elements
SMPP
Network
Management/OSS
USSD Gateway
Platform
Operator Charging,
Provisioning
HLR
Data/IP
IS-41/SS7
OPERATOR
ACCESS LAYER
SMSC
IS-41/SS7
MSC
Packet Data
Core
IOS
RAN
Software / Standards impact
New element
38
MS
USSD – Open Discussion
 Business requirements
 Technical and Operational requirements (and constraints)
 Regulatory requirements
39
39

CDMA Network Adjunct Workshop

Transcription

Similar documents

REAL Mobile Activation Guide

Youth leaving care Pathways into adulthood OCMW GENT

Dates - ESN Jena

Fireman`s Lift - Aoife`s Notes

pdf-download

Muon Spin Rotation as a Probe of Superconductivity

full product brief

How to access ESN?

Nordisk Mobiltelefon - CDMA Development Group