meid and euimid migration - cdma2000...meid instead of a (unique) esn, this is not to say that the...
TRANSCRIPT
MEID and EUIMID Migration
CDG Document 158
Version 2.1
February, 2011
CDMA Development Group 575 Anton Boulevard, Suite 560 Costa Mesa, California 92626 PHONE +1 888 800-CDMA
+1 714 545-5211 FAX +1 714 545-4601
http://www.cdg.org [email protected]
Notice Each CDG member acknowledges that CDG does not review the disclosures or contributions of any CDG member nor does CDG verify the status of the ownership of any of the intellectual property rights associated with any such disclosures or contributions. Accordingly, each CDG member should consider all disclosures and contributions as being made solely on an as-is basis. If any CDG member makes any use of any disclosure or contribution, then such use is at such CDG member’s sole risk. Each CDG member agrees that CDG shall not be liable to any person or entity (including any CDG member) arising out of any use of any disclosure or contribution, including any liability arising out of infringement of intellectual property rights.
February, 2011 ii
1. Executive Summary 1
2
• Issue. It has been known for several years that the ESN numbering resource, 3
used for both the handset’s Electronic Serial Number and for R-UIM UIMID 4
codes, is close to exhaustion. Due to stringent conservation and reclamation of 5
codes the life of the resource was extended several years beyond the first 6
predictions. However, the last virgin (never before assigned) ESN code was 7
assigned in 2008 and the last applications for assignments using reclaimed codes 8
were accepted by the administrator (TIA) on June 30th 2010. 9
• Industry Response. In response to these events, the CDMA2000® industry has 10
been migrating handsets from ESN to MEID-based addressing, and R-UIMs from 11
UIMID- to EUIMID-based addressing, and several operators have completed this 12
transition. 13
o Non-unique values, known as pESN (pseudo-ESN) or pUIMID 14
(pseudo-UIMID), will be used in ESN/UIMID fields, previously 15
depended upon to be unique. 16
• Potential Impact. If there are no steps taken in the network and back-end 17
systems to accommodate this change, possible impacts include: 18
o Crosstalk, interference, blocked and dropped calls. 19
o Misaddressed air interface messaging (e.g. SMS received by wrong 20
user). 21
o Inability to provision and/or bill some subscribers. 22
o Spurious Fraud Detection alerts. 23
• Migration Status. The migrations have already started 24
o Several major CDMA2000® operators have already upgraded their 25
network and deployed MEID-based handsets. 26
o EUIMID-based R-UIMs have already been deployed by several 27
operators. 28
• Recommended Actions. All CDMA2000® operators are recommended to 29
o Upgrade their network to support C.S0072 to minimize PLCM collisions. 30
o Remove any requirement in their back-end systems (e.g. HLR, VLR, 31
billing, provisioning) for a unique ESN/UIMID value. 32
o Use MEID-equipped devices. 33
o Choose either Long or Short EUIMID format and provision future R-UIM 34
or CSIM cards with this identifier. 35
Contents 1
1. Executive Summary.........................................................................................................................ii 2
2. The Need for Migration ...................................................................................................................9 3
2.1 Exhaust Impacts – Consequences of Inaction ....................................................................10 4
2.1.1 ESN Usage .............................................................................................................10 5
2.1.2 Duplication Impact..................................................................................................11 6
2.1.3 Collision Impact ......................................................................................................12 7
2.1.4 MEID/EUIMID Support ...........................................................................................13 8
2.2 Resource Utilization and Timelines ......................................................................................15 9
2.2.1 Predicted Timelines................................................................................................15 10
2.2.2 Current Resource Utilization..................................................................................15 11
2.2.3 Migration Activities .................................................................................................15 12
2.3 Likelihood of Impacts .............................................................................................................16 13
2.3.1 Basic Duplication Probability .................................................................................16 14
2.3.2 Duplications in a group of cards/devices ..............................................................16 15
2.3.3 PLCM Collision Probability ....................................................................................17 16
3. Hardware Identifiers Involved......................................................................................................19 17
3.1 Identifier Relationships ..........................................................................................................19 18
3.2 Existing Identifiers..................................................................................................................20 19
3.2.1 Electronic Serial Number (ESN)............................................................................20 20
3.2.2 User Identity Module Identifier (UIMID) ................................................................21 21
3.2.3 Integrated Circuit Card Identifier (ICCID) .............................................................23 22
3.3 New Identifiers .......................................................................................................................24 23
3.3.1 Mobile Equipment Identifier (MEID) ......................................................................24 24
3.3.2 Expanded UIMID (EUIMID) ...................................................................................25 25
3.4 Derived Identifiers ..................................................................................................................27 26
3.4.1 Secure Hash Algorithm 1 (SHA-1) ........................................................................27 27
3.4.2 Pseudo-ESN (pESN)..............................................................................................27 28
3.4.3 Pseudo-UIMID (pUIMID)........................................................................................29 29
4. Standards Involved........................................................................................................................31 30
4.1 MEID .......................................................................................................................................31 31
MEID and EUIMID Migration Contents
February, 2011 iv
4.1.1 Requirements .........................................................................................................31 1
4.1.2 Administration .........................................................................................................31 2
4.1.3 Billing .......................................................................................................................31 3
4.1.4 Air Interface.............................................................................................................32 4
4.1.5 ANSI-41 MAP Updates ..........................................................................................34 5
4.1.6 Over-the-Air Activation ...........................................................................................34 6
4.1.7 Interoperability and Testing ...................................................................................35 7
4.2 Expanded UIMID (EUIMID)...................................................................................................37 8
4.2.1 Requirements .........................................................................................................37 9
4.2.2 Administration .........................................................................................................37 10
4.2.3 CDMA R-UIM..........................................................................................................37 11
4.2.4 CDMA SIM Application ..........................................................................................37 12
5. EUIMID Migration Options ............................................................................................................38 13
5.1 Long-Form EUIMID................................................................................................................38 14
5.2 Short-Form EUIMID...............................................................................................................39 15
5.3 CDMA Card Application Toolkit (CCAT) ..............................................................................40 16
5.4 Device Compatibility with EUIMID ........................................................................................41 17
6. Recommendations.........................................................................................................................42 18
6.1 Operators with non-R-UIM-equipped handsets ...................................................................42 19
6.2 Operators with R-UIM-equipped handsets...........................................................................45 20
7. Scenarios.........................................................................................................................................49 21
7.1 Device / R-UIM Combinations of Interest.............................................................................50 22
7.2 Non-R-UIM Operator .............................................................................................................51 23
7.2.1 Basic Operation ......................................................................................................51 24
7.2.2 Data Services .........................................................................................................57 25
7.2.3 Lost/Stolen Phone ..................................................................................................58 26
7.2.4 Over the Air Service Provisioning .........................................................................59 27
7.2.5 Roaming..................................................................................................................62 28
7.3 R-UIM Operator – existing R-UIM in MEID device ..............................................................64 29
7.3.1 Basic Operation ......................................................................................................64 30
7.3.2 Data Services .........................................................................................................68 31
7.3.3 Lost/Stolen Phone ..................................................................................................68 32
7.3.4 Over the Air Service Provisioning .........................................................................69 33
7.3.5 Roaming..................................................................................................................70 34
7.4 R-UIM Operator – Short-Form EUIMID................................................................................71 35
7.4.1 Basic Operation ......................................................................................................71 36
MEID and EUIMID Migration Contents
February, 2011 v
7.4.2 Data Services .........................................................................................................74 1
7.4.3 Lost/Stolen Phone ..................................................................................................74 2
7.4.4 Over the Air Service Provisioning .........................................................................76 3
7.4.5 Roaming..................................................................................................................77 4
7.5 R-UIM Operator – Long-Form EUIMID ................................................................................78 5
7.5.1 Basic Operation ......................................................................................................78 6
7.5.2 Data Services .........................................................................................................79 7
7.5.3 Lost/Stolen Phone ..................................................................................................80 8
7.5.4 Over the Air Service Provisioning .........................................................................80 9
7.5.5 Roaming..................................................................................................................81 10
8. Terminology ....................................................................................................................................82 11
9. References ......................................................................................................................................86 12
13
14
15
MEID and EUIMID Migration Contents
February, 2011 vi
Figures 1
Figure 3-1: Identifier Relationships............................................................................. 19 2
Figure 3-2 - ESN Manufacturer's code allocation ....................................................... 21 3
Figure 3-3 - Usage Indicator Function........................................................................ 22 4
Figure 3-4 - Structure of ICCID .................................................................................. 23 5
Figure 3-5 - MEID Structure (Hexadecimal) ............................................................... 24 6
Figure 3-6 - Derivation of the pESN ........................................................................... 28 7
Figure 3-7 - Derivation of the pUIMID ........................................................................ 29 8
Figure 7-1 - Device & Card Combinations.................................................................. 50 9
Figure 7-2 - MEID MS Registration - no X.S0008 support .......................................... 51 10
Figure 7-3 - MEID MS Registration - X.S0008 supported........................................... 52 11
Figure 7-4 - Authentication of MEID device................................................................ 53 12
Figure 7-5 - MEID Origination/Termination................................................................. 54 13
Figure 7-6 - ESN-based addressing conflict ............................................................... 55 14
Figure 7-7 - MEID Handoff ......................................................................................... 56 15
Figure 7-8 - OTASP Data Flow .................................................................................. 59 16
Figure 7-9 - UIMID Registration - no X.S0008 support ............................................... 64 17
Figure 7-10 - UIMID Registration - X.S0008 supported .............................................. 65 18
Figure 7-11 - CheckMEID Operation.......................................................................... 69 19
Figure 7-12 - SF_EUIMID Registration with X.S0008 support .................................... 72 20
21
MEID and EUIMID Migration Contents
February, 2011 vii
Tables 1
Table 3-1 - Sample duplicate pESNs (Hexadecimal format) ...................................... 28 2
Table 3-2 - Sample duplicate pUIMIDs ...................................................................... 29 3
Table 3-3 - Sample pESN to pUIMID duplications...................................................... 30 4
Table 4-1 - EVDO HardwareIDType values ............................................................... 34 5
Table 7-1 - Handoff matrix for C.S0072 support levels............................................... 56 6
7
Revision History 1
2
Date Version Description
2007-05-08 0.1 Document Outline
2007-05-22 0.2 (Incomplete) Draft for comments
2007-06-22 0.3 Update following internal review
2007-10-12 0.4 Draft for use in CDG MEID/EUIMID Seminars
2007-11-12 0.5 Updated draft for CDG website
2007-11-30 1.0 Formatted for posting as CDG White Paper
2008-04-02 1.1 Added band class issue
2008-09-30 2.0 Updated with the latest information from operators, vendors and standards organizations
2010-11-30 2.1 Updated to reflect the latest status of the resources and the migration.
3
2. The Need for Migration 1
This section describes the impacts of the exhaust of the Electronic Serial Number 2
(ESN) and (Removable) User Identity Module Identifier (UIMID) resource, the 3
likelihood of these impacts occurring, and estimates of the dates of total depletion of 4
these resources. 5
The specific identifiers are described in further detail in Section 3. For the purposes 6
of understanding the discussion in this section, the following definitions are used: 7
• ESN. Existing 32-bit identifier for a mobile station. Essentially exhausted and 8
assignment applications no longer being accepted. 9
• UIMID. 32-bit card identifier that typically replaces the handset ESN 10
(ESN_ME) in ESN protocol fields1. Essentially exhausted and assignment 11
applications are no longer being accepted. Allocated from the same 12
numbering space as the ESN. 13
• MEID. Replacement2 56-bit identifier for the ESN. 14
• EUIMID. Replacement2 identifier for the UIMID. This can be the SF_EUIMID 15
(which may substitute for the handset MEID (MEID_ME) in MEID protocol 16
fields) or LF_EUIMID (ICCID). 17
• pESN. Non-unique identifier used in place of the ESN, derived from MEID. 18
• pUIMID. Non-unique identifier used in place of the UIMID, derived from the 19
EUIMID. 20
In this document, “ESN”, when unqualified, can refer to a unique, “true” ESN 21
assigned to a mobile station, and also to the “ESN” field in a particular protocol 22
message, which may be populated by a (true) ESN, or another 32-bit identifier, e.g. 23
UIMID, pESN, or pUIMID. The term “ESN_ME” is used to explicitly refer to the value 24
stored in the mobile station. 25
1 UIMID does not replace ESN as the HardwareID parameter in EVDO.
2 Although the MEID is a replacement for the ESN in the sense that a mobile station will be assigned a MEID instead of a (unique) ESN, this is not to say that the MEID is used in messaging everywhere an ESN-assigned mobile would use its ESN. Likewise for EUIMID and UIMID. In both cases a pseudo-ESN or pseudo-UIMID is calculated for backwards compatibility with signaling.
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 10
2.1 Exhaust Impacts – Consequences of Inaction 1
At the most simplistic level, the immediate impact of the exhaust of a required, 2
unique identifier like the ESN or UIMID would be a halt to CDMA2000® mobile 3
manufacturing unless some form of re-use, expansion or other relaxation of the 4
uniqueness requirement were implemented. 5
To enable the industry to proceed, new, longer identifiers have been defined in 6
various standards - see Sections 3. - 4. To maintain backwards compatibility, 7
non-unique “pseudo” values derived from these new identifiers are used 8
wherever the protocols require an ESN or UIMID value. 9
This subsection describes the network impacts arising because a value that was 10
previously reliably known to be uniquely assigned to a particular handset or card 11
can now be used by multiple handsets or cards. Additional impacts relating to the 12
way a handset advertises that it uses the new identifier are discussed in Section 13
2.1.4. 14
Section 6. recommends actions to avoid or mitigate the impacts listed here – those 15
actions involve changes to various parts of the network and supporting systems. 16
The current section assumes that those actions have not been carried out. 17
2.1.1 ESN Usage 18
ESNs are used in CDMA systems in a variety of places. In some cases this usage is 19
based on an assumption that the ESN is unique, in most cases it is not. The bullets 20
below list the major standardized uses of ESN. (Note: The UIMID, if present, may 21
override the ESN. All ESN usage listed below can also apply to the UIMID, except 22
the final bullet – see Section 3.2.2) 23
• Layer 2 Link Access Control (LAC) Addressing. The ESN forms an 24
optional part of the LAC addressing fields used to identify mobiles over the 25
air. Most operators use the “IMSI + ESN” addressing option on the access 26
channel (more strictly known as the reverse common signaling channel, r-27
csch). On the paging channel (or forward common signaling channel, f-28
csch), either IMSI- (or Temporary Mobile Station Identity, TMSI) or ESN-29
based addressing can be used, but not the combination of both as on the 30
access channel. 31
• Public Long Code Mask (PLCM). The ESN is used to generate the PLCM, 32
which distinguishes one call from another. PLCM “collision” is a key concern 33
when duplicate ESN or UIMID are present in a network. 34
• Non-programmed IMSI. Part of the ESN is used to form the default IMSI of 35
a mobile when an IMSI value has not been explicitly programmed. This value 36
is non-unique today, and no impact is expected from the resource exhaust. 37
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 11
• Access Probe Timing. The ESN (as RN_HASH_KEY) is used to compute a 1
delay applied to mobile access sub-attempts3. As there are only 512 2
possible values, collisions occur today and are resolved by existing 3
procedures. No impact is expected from the resource exhaust. 4
• Authentication input. The ESN is used as one of the inputs to compute the 5
Authentication Response value in the Cellular Authentication and Voice 6
Encryption (CAVE) algorithm. Since CAVE was designed to combat cloning, 7
where a subscriber’s IMSI and ESN is copied by a fraudster, its security is 8
not compromised by a non-unique ESN value. 9
• Registration Timer Pseudorandom Number Generator. The ESN is one 10
of the inputs to the pseudorandom number generator used in some cases in 11
timer-based registration. Collisions are currently possible with this generator, 12
and no impacts are expected due to the resource exhaust. 13
• Back-end systems. Individual operators may have used the ESN as a 14
“unique key” for any number of internal systems. Although not subject to 15
standardization, ESN usage could typically include: an index into a device 16
information/capabilities database; a uniqueness check at provisioning time; a 17
billing integrity check; or simply because ESN uniqueness was believed to 18
be a requirement. This is most likely for applications where IMSI is not 19
available, such as initial service provisioning or pre-sale logistics tracking. 20
• EVDO Hardware ID. The ESN is used in EVDO and associated network 21
protocols as the HardwareID parameter. The UIMID will not be transmitted 22
as HardwareID in R-UIM equipped EVDO devices. 23
2.1.2 Duplication Impact 24
In this document, “duplication” refers to two mobile stations sharing the same pESN 25
or pUIMID value, used whenever the signaling protocol (or other scenario) calls for 26
an ESN. Without any other changes in the network or mobiles, these mobiles 27
function as if they have a duplicate ESN. The mobiles may in general be located 28
anywhere within an operator’s network or that of their roaming partners. Note that 29
legitimate mobiles must have different IMSIs. 30
Impacts of duplication are generally felt in back-end systems. While the exact 31
impacts are operator specific, some of the more likely impacts are listed below: 32
• No Provisioning. The provisioning system may reject attempts to provision 33
mobiles that share the same ESN value. 34
3 See http://www.3gpp2.org/Public_html/specs/C.S0003-0_v3.0.pdf
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 12
• Incorrect Provisioning. The provisioning system may retrieve a record for the 1
wrong device when a database is indexed by a (non-unique) ESN, resulting in 2
the incorrect provisioning of a mobile or R-UIM. 3
• Billing errors. A billing system or clearinghouse may generate errors for Call 4
Detail Records (CDRs) received with one ESN but with different MINs/IMSIs. 5
• Fraud alerts. A fraud system might generate multiple false alarms on seeing 6
call attempts or CDRs from the same ESN with different MINs/IMSIs. 7
• No Service. Some core network elements (such as HLRs and VLRs) may not 8
allow multiple mobiles to be registered with the same ESN preventing two or 9
more subscribers presenting the same pESN or pUIMID from obtaining 10
service. 11
• Duplicate NAIs. If an ESN- or UIMID-based NAI is used today, this will 12
become non-unique with the use of pseudo-identifiers, potentially leading to 13
authentication failures and denial of data service. 14
In most cases equipment vendors can supply patches or upgrades to eliminate 15
these problems. 16
2.1.3 Collision Impact 17
In this document, “collision” refers to two duplicate-ESN mobiles that are active in 18
the same carrier-sector or in two or more interfering sectors. The mobiles may be 19
active for several reasons including attempting to make (or receive) calls at about 20
the same time. Collision is thus a specific case of duplication. 21
When messages are addressed by ESN to one of multiple duplicate-ESN mobiles in 22
the same area4 the messages may be processed by two or more mobiles. See the 23
[Collisions WP] for a listing of the impact of each message that may be addressed in 24
this way, and Section 7.2.1.6 for a particular example where a mobile can receive 25
an SMS intended for someone else. 26
Note that the alternative addressing method (via IMSI) may be susceptible to similar 27
effects if a non-subscribed mobile were programmed with the IMSI of a legitimate 28
mobile in the same area. However, the likelihood of this occurring is much less. This 29
is because a mobile with a duplicate IMSI could not get any other services (it would 30
fail authentication) and it would only cause interference if it stayed in the vicinity of 31
the legitimate phone. The most likely scenario where this could occur is when a 32
subscriber gets a new phone and the IMSI is transferred to that phone. 33
4 i.e. the area over which the message is sent
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 13
The impact of collisions derives from the fact that in current networks, the Public 1
Long Code Mask (PLCM5) is derived from the mobile’s ESN. 2
2.1.3.1 What is a PLCM? 3
The PLCM is a 42-bit number used to generate the public long code, a pseudonoise 4
sequence used for scrambling on the forward CDMA traffic channel and spreading 5
on the reverse CDMA traffic channel6. On the forward traffic channel, distinct Walsh 6
codes further distinguish individual users’ traffic. However on the reverse traffic 7
channel, only the ESN-derived portion of the PLCM differentiated users’ traffic until 8
Release D and 3GPP2 C.S0072 provided other derivation methods. 9
In CDMA2000® networks, the PLCM comprises a channel-specific header plus a 10
permutation of the mobile’s ESN. 11
(Note by contrast that for CDMA 1xEV-DO networks, the PLCM is not derived from 12
a hardware identifier permanently associated with the Access Terminal.) 13
2.1.3.2 Impact of PLCM collision 14
The [Collisions WP] describes in detail the effects of PLCM collisions. In brief, the 15
effects may include: 16
• Cross-talk. Both parties engaged in calls using the same PLCM may hear the 17
reverse audio from only one mobile (the one whose traffic arrives at the base 18
station with greater power) 19
• Interference and call drops. If the signals from both mobiles arrive at similar 20
power, they will interfere destructively resulting in a high frame error rate and 21
the possibility of both calls dropping. 22
2.1.4 MEID/EUIMID Support 23
A particular situation not directly related to non-unique ESN values has been 24
encountered in some network configurations. In this instance, the way in which the 25
mobile advertises that it uses one of the new identifiers results in an illegal 26
parameter value being generated on a particular interface. The impact is that none 27
of these mobiles can receive service. Investigations to date suggest that the issue 28
was confined to a single operator that has since resolved the issue. For more 29
information, see the [MEID Failure Bulletin]. 30
In EV-DO Revision 0 networks that include the Hardware Identifier in the A12 31
interface, access authentication failures may result for MEID-equipped mobiles on a 32
5 Not to be confused with the Private Long Code Mask. Private Long Code Masks are rarely used in current networks, and are not discussed in this document. See [Collisions WP] for a brief treatment
6 For (much) more detail, see http://www.3gpp2.org/Public_html/specs/C.S0002-0_v3.0.pdf
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 14
non-upgraded network. See Section 7.2.2.2 for more information. Failures may also 1
be observed in non-upgraded EV-DO networks where the MEID cannot be sent in 2
the airlink record by the PCF, or is not expected/supported at the PDSN or AAA. 3
Some R-UIM handsets in the market do not support EUIMID-equipped R-UIMs (see 4
section 5.4 ). 5
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 15
2.2 Resource Utilization and Timelines 1
2.2.1 Predicted Timelines 2
The Telecommunications Industry Association (TIA) administers the ESN and 3
UIMID manufacturer code space, and publishes regular reports on utilization. Virgin 4
ESN code blocks were completely exhausted by the end of 2008. Assignments 5
continued beyond that date using reclaimed codes but the TIA stopped accepting 6
new applications for assignments on June 30th 2010. 7
The UIMID manufacturer code space for R-UIMs (a subset of the same resource) 8
has actually already been exhausted, with assignments continuing only because the 9
ESN administrator has been able to continue to reclaim codes from older 10
technologies (AMPS analog and TDMA digital) and transfer them to the UIMID 11
administrator where they are allocated efficiently in blocks of ~260,000 codes with 12
14 bit manufacturer code prefixes. The TIA also stopped accepting applications for 13
new UIMID code blocks on June 30th 2010 although assignments will continue for 14
some time with previously received applications as need for codes is demonstrated 15
and as reclaimed codes become available. 16
2.2.2 Current Resource Utilization 17
An overview of the ESN manufacturer code assignments is available on the TIA 18
website7. 19
Usage of pESNs and pUIMIDs removed one 8-bit manufacturer code (~16.8 million 20
codes) from assignment but otherwise did not negatively impact the ESN/UIMID 21
resource space – these pseudo values always use a pre-allocated manufacturer 22
code (0x80) that does not conflict with other assignments. The use of MEID and 23
EUIMID has a positive impact in that every device manufactured with one of these 24
codes is one less ESN or UIMID that needs to be allocated from the rapidly 25
diminishing pool. 26
2.2.3 Migration Activities 27
MEID assignment commenced in October, 2005 (also under administration by the 28
TIA). MEID-equipped devices have already been commercially deployed by several 29
large operators, who have also upgraded their networks to support many/all of the 30
recommendations in Section 6. (In this document however, “current” or “existing” 31
networks refer to non-upgraded networks). 32
7 http://www.tiaonline.org/standards/resources/esn/codes.cfm
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 16
EUIMID assignment commenced in 2007, with several major R-UIM manufacturers 1
supplying millions of EUIMID-equipped cards to their operator customers. The 2
SF_EUIMID is assigned by the MEID administrator (TIA) and the LF_EUIMID is 3
assigned nationally. 4
2.3 Likelihood of Impacts 5
An important question for operators to understand is “how likely is a problem to 6
occur?”, related to the non-uniqueness of the ESN parameter. As a general 7
comment, it is important to note that the probability of duplication or collision cannot 8
be given without considering other inputs, e.g. the size of the sample group, call 9
arrival rate in the busy hour, etc. Several different calculations are available, and are 10
shown in the subsections below. 11
2.3.1 Basic Duplication Probability 12
Since there are 224 different pESN/pUIMID code values, the probability of any two 13
pESNs/pUIMIDs chosen at random being the same is 14
P(any 2 pUIMIDs/pESNs same) =
!
1
224
=1
16,777,216 15
2.3.2 Duplications in a group of cards/devices 16
As the number of cards or devices in a group grows, the probability of duplication 17
rises faster than might be intuitively thought, due to a phenomenon known as the 18
Birthday Problem8. The value is calculated as follows for a group of n cards/devices: 19
P(≥1 duplication in n) = 1 – P(no duplications) 20
!
=1"224 "1
224
#224 " 2
224
# ...224 " n "1( )224
$
% &
'
( ) 21
or, using the factorial notation, “!”: 22
!
=1"224!
224n
• (224 " n)!
#
$ %
&
' ( 23
When n reaches approximately 4800, the probability of at least one duplication 24
reaches 50%. With n = 10000, the probability is approximately 95%. 25
8 Named for the surprising fact that with a group of only 23 people, there is a 50% chance of a common birthday. See http://mathworld.wolfram.com/BirthdayProblem.html
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 17
Although these numbers are not realistic for users in a single sector, they can be 1
significant at the network-wide level – back-end systems (such as HLRs, billing and 2
provisioning systems) will very likely have to deal with duplicate pESNs/pUIMIDs as 3
the number of deployed MEIDs and EUIMIDs grows. 4
The probability of a specific number of duplications is given by: 5
P(exactly x duplications in group of n) =
!
1
NnS(n,n " x)
N!
(N " n + x)!, 6
where N = 224, and S(n,k) is the Stirling number of the second kind9. This formula 7
can in theory be used to derive the expected number of duplications within a batch 8
of R-UIMs or MEID phones, although the numbers involved in the calculations 9
quickly become unwieldy. 10
2.3.3 PLCM Collision Probability 11
Several documents aim to provide a sense of how often PLCM collisions might be 12
expected to occur in a network (assuming the upgrade steps described in Section 6. 13
are not implemented). 14
The primary reference is the [Collisions WP] document, which derives an expected 15
number of collisions in a day for the network. This is the sum of the expected 16
collisions per hour, which is given by: 17
E(hourly collisions in the network) ( ) 2
212
!µ
UN
If +" , 18
where: 19
• U: the total number of carrier sectors in the operator’s network. 20
• λ: expected number of calls made per hour in an average sector. 21
• 1/µ: average call holding time (in fractions of an hour). 22
• ƒ: fraction of the calls that use pESN based handsets or pUIMID R-UIMs 23
• I: number of neighboring sectors that interfere with an average sector. 24
• N: the possible values for the public long code mask (PLCM): 224. 25
One scenario in this document estimated daily collisions in a large system with 26
60,000 sectors, each of which had 6 neighboring sectors. It estimated that they 27
would rise from zero with no pESNs or pUIMIDs to almost 600 per day (throughout 28
the entire system) if all mobiles transmitted a pESN or pUIMID. This is a rate of just 29
9 See http://mathworld.wolfram.com/StirlingNumberoftheSecondKind.html
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 18
under 4 collisions per million calls over the day or just under 6 collisions per million 1
calls during busy hour. Obviously this problem is eliminated if precautions against 2
pESN/pUIMID collisions are taken. 3
Alternatively, a Lucent standards contribution from 200310 calculated the expected 4
number of call replacements (i.e. an existing call finishing to be replaced by a new 5
call on the sector) until a collision occurs, as: 6
E(replacements until collision) 1!
=m
N, 7
where N is 224 as before, and m is the number of potentially colliding users, i.e. the 8
number of active calls on the sector and interfering sectors. 9
m (number of potentially colliding users)
E (expected number of calls before collision occurs)
10 1,864,135
20 883,011
30 578,524
40 430,185
50 342,392
60 284,359
70 243,148
80 212,369
90 188,508
100 169,466
10
10 http://ftp.3gpp2.org/TSGC/Working/2003/2003-03-Vancouver/TSG-C-2003-03-Vancouver/WG2/C20-20030317-018A_(LU)SHA_Response.pdf
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 19
3. Hardware Identifiers Involved 1
This section presents the formats and characteristics of the existing and new 2
hardware identifiers for CDMA2000® devices and R-UIMs. 3
3.1 Identifier Relationships 4
Figure 3-1 below shows a summary of the relationships between the various 5
identifiers possible for the device and the R-UIM. The following subsections 6
describe each identifier in more detail. 7
ESN
pESN
UIMID
pUIMID
MEID
Short Form
EUIMID
Long Form
EUIMID
(ICCID)
32-bit Address Space 56-bit Address Space 72-bit Address Space
OR
Migration
Derivation
(hashing)
Device
R-UIM
8
Figure 3-1: Identifier Relationships 9
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 20
3.2 Existing Identifiers 1
3.2.1 Electronic Serial Number (ESN) 2
The Electronic Serial Number (ESN) is a 32-bit number assigned by the mobile 3
station manufacturer, uniquely identifying the mobile station equipment. ESNs are 4
typically represented as an eight-character hexadecimal string or as an 11-digit 5
decimal number11. ESNs are used by AMPS, TDMA and CDMA air interface 6
protocols. In CDMA and related standards, the ESN is used for a variety of functions 7
(see Section 2.1.1 for more detail). 8
A 32-bit address space gives a maximum pool of 232 ≈ 4.3 billion unique ESNs. 9
Generous allocation, inefficient usage and the huge number of cellular devices 10
manufactured since the 1980s have led to the current shortage. 11
ESNs were initially allocated by assigning an 8-bit manufacturer’s code to a cellular 12
phone manufacturer. The manufacturer would allocate the remaining 24-bits as 13
unique serial numbers to up to approximately 16.7 million wireless devices12 14
although many manufacturers produced far fewer devices leaving many codes 15
stranded. This could be repeated for each of the 256 manufacturer codes. More 16
recently, in an attempt to allocate the rapidly diminishing resource more efficiently, 17
14-bit manufacturer codes have been assigned (~260,000 values per code). These 18
two allocation schemes represent administrative approaches to assigning the 32-bit 19
number range, and do not change the way the ESN is transmitted over the air or 20
carried in other network signaling. Although the CIBER manual describes three 21
different ways to construct a decimal representation of an ESN, in practice only one 22
method is in common use, which assumes an 8-bit manufacturer code and converts 23
this and the remaining 24-bits separately to decimal before concatenation. 24
ESN manufacturer codes are currently administered by the Telecommunications 25
Industry Association (TIA). The serial number portion of the ESN is administered by 26
the manufacturer. 27
11 The decimal representation is formed by concatenation of the decimal representation of the first 2, and last 6 hex characters, rather than direct hex-to-decimal conversion of the entire value. Thus hex ESN 9D124886 is written as 15701198214, not 02635221126. This corresponds to the Manufacturer’s Code and Serial Number for 8 bit Manufacturer Codes, but not for 14 bit codes.
12 Technically the ESN was divided into an 8 bit manufacturer’s code, 6 reserved bits, followed by an 18 bit serial number (~262 thousand codes). However, most manufacturers used the reserved bits to bring the serial number to 24 bits (~16.8 million codes).
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 21
Figure 3-2 below shows the two methods used for segmenting the ESN allocation 1
space. 2
Manufacturer’s Code
8 bits
Serial Number
24 bits
Manufacturer’s Code
14 bits
Serial Number
18 bits
0232431
31 01718
bit #
bit #
3 4
Figure 3-2 - ESN Manufacturer's code allocation 5
For more information, see the TIA website13, and the definition in [C.S0005]. The 6
TIA also produces a regular ESN Administrator’s Report, available from Gary 7
Pellegrino, the TIA TR-45 EUMAG chair ([email protected]), or 8
the ESN administrator, John Derr ([email protected]). 9
3.2.2 User Identity Module Identifier (UIMID) 10
The UIM Identifier (UIMID) is a unique 32-bit number assigned to an R-UIM. It is 11
defined in [C.S0023] (including earlier versions than the one referenced in this 12
document). Earlier versions allowed the UIMID to be up to 56 bits in length to 13
anticipate future evolution. This size change has been superseded by the migration 14
to EUIMID described in the latest standard revision and in this document, and the 15
UIMID is now understood to be a unique 32-bit number only. It may also be written 16
as UIM_ID. 17
The UIMID shares a 32-bit addressing space with the ESN. UIMID allocations 18
include both “virgin” codes (codes that have never been assigned as ESNs – 19
identifiable by “(not currently available for other CDMA technology use)” in the on-20
line ESN assignment table14), and “reclaimed” codes, that were previously allocated 21
as ESNs, but have been identified as unused, or used for older (e.g. AMPS-only) 22
devices (and thus unlikely to clash with CDMA-only devices using these R-UIMs). 23
The TIA currently administers the UIMID space. 24
In 1x voice and data modes the UIMID can be used instead of the ESN from the 25
device wherever the ESN is signaled over the air or used in calculations (e.g. CAVE 26
authentication).15 This behavior is controlled by a variable on the R-UIM, the Usage 27
13 http://www.tiaonline.org/standards/resources/esn/
14 http://www.tiaonline.org/standards/resources/esn/codes.cfm
15 Some signaling messages defined in C.S0066-0 v2.0, C.S0016-C v2.0 and CDMA 2000 Release E explicitly call for the use of ESN_ME and will not substitute UIMID.
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 22
Indicator (EFUSGIND). Figure 3-3 shows the function of the usage indicator (only bit 1 1
is relevant here – the function of bit 2 is discussed in Section 3.3.2). Note that the 2
value of this indicator is not explicitly available to the network. This is not true in EV-3
DO where the HardwareID is sourced from the ME identifier (ESN or MEID) 4
regardless of the value of EFUSGIND. 5
6
b8 b7 b6 b5 b4 b3 b2 b1
b1=0: ESN_ME is used for CAVE Authentication and MS Identification
b1=1: UIMID is used for CAVE Authentication and MS Identification
b2=0: MEID_ME is used for MS Identification.
b2=1: SF_EUIMID is used for MS identification
Reserved for future use
Figure 3-3 - Usage Indicator Function 7
In practice, all operators using R-UIM are believed to set b1 to 1, i.e. the UIMID 8
replaces the ESN wherever it is used in a 1X mode. This is for compatibility with 9
ANSI-41 mobility management protocol that relies on each IMSI/MIN being 10
associated with a single ESN. Moving a UIM from one phone to another will 11
associate the IMSI/MIN with a different hardware ESN, but the UIMID will remain the 12
same. 13
For more information, see [C.S0023]. The TIA produces a regular UIM 14
Administrator’s Report, available via email and by distribution to various 15
standards organizations. 16
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 23
3.2.3 Integrated Circuit Card Identifier (ICCID) 1
The Integrated Circuit Card Identifier (ICCID) is an 18-digit BCD (72-bit) identifier 2
assigned to the physical R-UIM card. Since the storage on the R-UIM (EFICCID) is 80 3
bits (room for 20 digits) 3GPP2 C.S0023-C v2.0 recommends that the check digit is 4
also included as the nineteenth digit along with a single filler digit (0xf) as the 5
twentieth. Since there is no demarcation within this field to distinguish the portions, 6
and some non-standard identifiers are known to exist, the entire 80 bit field will be 7
returned in response to an OTASP query for the ICCID or EXT_UIM_ID (if 8
LF_EUIMID is used)16, and will be used as an input to the hash function to compute 9
the pUIMID if LF_EUIMID is used (see section 3.4.2). 10
The ICCID is currently present on all R-UIM cards (as well as GSM SIM cards). It is 11
defined in [E.118] (which is referenced indirectly from [C.S0023]). The ICCID is 12
typically printed on the card, and is also stored electronically. 13
Figure 3-4 below shows the structure of the ICCID: 14
15
Figure 3-4 - Structure of ICCID 16
16 The ability to query for these identifiers is added in C.S0066 v2, in C.S0016-C v2 and via Status Request messages in Revisions D and E of C.S0005 (CDMA2000 radio interface level 3).
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 24
3.3 New Identifiers 1
3.3.1 Mobile Equipment Identifier (MEID) 2
The Mobile Equipment Identifier (MEID) is a new 56-bit identifier placed in a mobile 3
station by its manufacturer, uniquely identifying the mobile station equipment. The 4
MEID addresses the exhaust of the ESN resource providing unique identification of 5
orders of magnitudes more mobile devices. It may be represented as a 14-character 6
hexadecimal string, or as an 18-digit decimal number. 7
The structure of the MEID is shown in Figure 3-5 below (using hexadecimal format). 8
9
Figure 3-5 - MEID Structure (Hexadecimal) 10
The subfields are defined as follows: 11
RR: Reporting Body Identifier. Currently restricted to the range A0 – FF. 12
This ensures separation from the GSM International Mobile 13
Equipment Identity (IMEI), which also uses a 56-bit space, but is 14
restricted to BCD values only (i.e. 14 decimal digit representation). 15
The RR values 00-99 can be used by dual-mode devices – in this 16
case the IMEI and MEID will be the same value (the remaining digits 17
of the MEID are also restricted to BCD values). 18
XXXXXX: Manufacturer code. In practice, this value has been segmented 19
across multiple manufacturers for some existing assignments by 20
treating the leftmost digit of the Serial Number as an additional 21
digit.17 22
ZZZZZZ: Serial Number, assigned by the manufacturer (possibly within 23
segmented range as above, in which the leftmost digit is treated as 24
part of the Manufacturer code). 25
17 Current assignment practices allow the identifier to be treated as if the Manufacturer Code was 9 (or more) digits long and the Serial Number only 5 (or fewer) digits long. This makes allocation more efficient for smaller manufacturers, with only one million (or fewer) numbers being assigned at a time instead of close to 17 million.
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 25
C: Check Digit for use when an MEID is printed (e.g. on packaging or on 1
the exterior of an MS). The check digit is not part of the MEID and is 2
not transmitted when the MEID is transmitted. It is calculated using 3
the Luhn algorithm modified to use base-16 arithmetic when the 4
MEID is in the hexadecimal range (RR=A0 – FF). 5
With RR in the range A0 – FF, the available pool of MEIDs is 96 × 248 ≈ 27 thousand 6
trillion, or approximately 6.3 million times the size of the ESN address space. 7
MEID administration is performed by the Global Hexadecimal Administrator (GHA). 8
TIA currently serves as the GHA. Assignment of MEIDs with decimal RR codes is 9
performed by administrators approved by the GSMA, including TIA in the range 10
RR=99 and BABT in the range RR=35. 11
For more information, see the TIA website18. See [X.S0008] for information on 12
the decimal representation of MEID, as well as checksum calculation details. 13
The TIA produces a regular MEID Administrator’s Report, available from the TIA 14
EUMAG chair ([email protected]) and also on the 3GPP2 TSG-15
S FTP site. 16
3.3.2 Expanded UIMID (EUIMID) 17
The Expanded UIMID (EUIMID) is a new identifier designed to address the exhaust 18
of the UIMID resource. It is defined in [C.S0023], where two different forms of 19
EUIMID are described: 20
• Short Form EUIMID (SF_EUIMID): The SF_EUIMID shares the same 21
address space as the MEID. R-UIM card manufacturers are allocated MEID 22
manufacturer codes in the same manner, and from the same range, as 23
handset manufacturers. No identifier will be allocated as both an MEID and 24
an SF_EUIMID. 25
• Long Form EUIMID (LF_EUIMID): This is equal to the value of the ICCID of 26
the card. In practice this is the 20 digit/80 bit contents of EFICCID which will 27
probably include a check digit and filler digit (0xf) as well as the ICCID which 28
is probably 18 digits/72 bits in size. 29
When the SF_EUIMID is used, bit 2 of the Usage Indicator describes whether the 30
SF_EUIMID of the card replaces the MEID of the device wherever it is used (see 31
Figure 3-3).19 32
18 http://www.tiaonline.org/standards/resources/meid/
19 Strictly speaking, the Usage Indicator is only described in the standard as denoting MEID override in C.S0004 (radio interface), not C.S0016 (OTA). Nevertheless, handset manufacturers have interpreted this as a total override of MEID, consistent with the behavior of UIMID with respect to ESN, and facilitates OTASP provisioning of SF_EUIMID-equipped R-UIMs
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 26
The relative merits of the two approaches are discussed in Section 5. . Note that the 1
EUIMID may be variously referred to as the Extended UIMID, Expanded R-UIM 2
Identifier, EXT_UIM_ID, EUIM-ID or E-UIMID in some sources. 3
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 27
3.4 Derived Identifiers 1
With the use of new, longer identifiers, devices and cards no longer have a true 2
(i.e. unique) ESN or UIMID. However, “ESN” is a required field in many messages. 3
Therefore there is a need to derive a 32-bit identifier to populate this field. 4
3.4.1 Secure Hash Algorithm 1 (SHA-1) 5
The Secure Hash Algorithm 1 (SHA-1) is used to produce a condensed, 160-bit 6
digest of an input number or text string. Although not important for this application, 7
this process is intended to be one-way only, i.e. given a particular digest (or “hash”), 8
it is not easy to work out what the input message might have been. 9
More importantly, like all well-designed hash functions, SHA-1 spreads its results 10
uniformly across its result space, regardless of the relationship between input 11
messages (i.e. inputs differing only slightly, perhaps by one bit, do not produce 12
outputs that are more similar than two very different inputs). 13
SHA-1 is the algorithm used in CDMA standards to derive a digest from the (56- or 14
80-bit20) input. In this case, the complete SHA-1 output (160 bits) is actually longer 15
than the input message – as a result only the 24 least-significant bits of the output 16
are used (combined with an 8-bit “manufacturer code” of 0x80 to give the required 17
32-bit identifier and to ensure that there cannot be a conflict with any assigned 18
codes that will never use the 0x80 prefix). 19
For more information, see RFC3174 (http://www.ietf.org/rfc/rfc3174.txt). 20
Implementations of the SHA-1 hashing algorithm are freely available on the 21
internet (e.g. http://www.slavasoft.com). 22
3.4.2 Pseudo-ESN (pESN) 23
The Pseudo-ESN (pESN) is a 32-bit identifier derived from the MEID, used in place 24
of the ESN. It is constructed by concatenating the ESN 8-bit manufacturer code 25
0x80 (reserved for this purpose) with the least significant 24 bits of the SHA-1 digest 26
of the MEID. The pESN is stored in the Mobile Station as the value of the ESNp 27
Permanent Mobile Station Indicator (the variable that otherwise stores the (true) 28
ESN). 29
Figure 3-6 below shows the derivation of the pESN. Since there is a defined (albeit 30
one-way) relationship between MEID and pESN, it is possible to derive the pESN 31
even if only the MEID is received by any particular entity. 32
20 3GPP2 C.S0023-C v2.0 clarifies that the input to the SHA-1 algorithm for LF_EUIMID is the entire 80 bits of the EFICCID, usually including the check digit and a filler digit (0xf).
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 28
56-bit MEID
160-bit digest
SHA-1
last 24 bits
0x8032-bit pESN 1
Figure 3-6 - Derivation of the pESN 2
Since there are more possible MEIDs than pESNs, more than one MEID will map to 3
the same pESN21. By way of example, Table 3-1 below shows several pairs of 4
MEIDs with a common pESN. It is this lack of uniqueness in the pESN that 5
represents the main impact to operator networks and business processes. The 6
likelihood of this kind of duplication occurring is discussed in Section 2.3 . 7
MEID1 MEID2 pESN
A0000000001BC2 A0000000003472 80003C21
A00000000000A6 A0000000003422 80066CDE
A0000000002277 A0000000003584 80270ABB
Table 3-1 - Sample duplicate pESNs (Hexadecimal format) 8
The pESN space is not segmented or administered in any way. Due to the behavior 9
of the hash function, pESNs derived from a specific MEID range may occupy any 10
part of the pESN address space. The specific manufacturer code (0x80) ensures 11
that a pESN will not clash with any true (unique) ESN or UIMID. 12
For more information, see [C.S0072]. A calculator including a pESN-generator 13
and other related functions is available on the CDG website22. 14
21 Simple division, and an assumption of uniformity in the hashing function yields each pESN value being shared by ~1.6 billion MEIDs.
22 http://www.cdg.org/devices/meid/meid_euimid_calculator.asp
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 29
3.4.3 Pseudo-UIMID (pUIMID) 1
The Pseudo-UIMID (pUIMID) is a 32-bit identifier derived from the EUIMID (either 2
Short or Long Form), and used in place of the UIMID (which itself typically replaces 3
the ESN). 4
The pUIMID is derived from the EUIMID in the same manner as the pESN is derived 5
from the MEID (and therefore shares the same space as the pESN), as shown 6
below: 7
80- or 56-bit EUIMID
160-bit digest
SHA-1
last 24 bits
0x8032-bit pUIMID 8
Figure 3-7 - Derivation of the pUIMID 9
Since there are more possible EUIMIDs than pUIMIDs, more than one EUIMID will 10
map to the same pESN. By way of example, Table 3-2 below shows three pairs of 11
(in this case, Long Form) EUIMIDs with a common pUIMID. (Note that the hash 12
function is computed over the LF_EUIMID as a BCD number, not simple decimal, 13
and includes the check digit and Hex ‘F’ filler). 14
LF_EUIMID-123 LF_EUIMID-223 pUIMID
8991001000000021981f 8991001000000081654f 80E7F275
8991001000000037789f 8991001000000116740f 809F9406
8991001000000087735f 8991001000000088642f 8059659C
Table 3-2 - Sample duplicate pUIMIDs 15
MEID and EUIMID Migration 3. Hardware Identifiers Involved
February, 2011 30
The pUIMID space is not segmented or administered in any way. Due to the 1
behavior of the hash function, pUIMIDs derived from a specific EUMID range may 2
occupy any part of the pUIMID address space. pUIMIDs and pESNs share the same 3
address space: a pESN may clash with another pESN or a pUIMID. Table 3-3 below 4
shows three examples of pESN – pUIMID clashes. The specific manufacturer code 5
(0x80) ensures that a pUIMID will not clash with any true (unique) ESN or UIMID. 6
MEID LF_EUIMID23 pESN/pUIMID
A0000000000D00 8991001000000005182f 80B270AD
A0000000002559 8991001000000081878f 802E9C53
A0000000002A85 8991001000000039298f 808840E4
Table 3-3 - Sample pESN to pUIMID duplications 7
8
23 Values are shown as stored in the R-UIM card with the 19th digit the check digit and the 20th digit the 0xf filler.
4. Standards Involved 1
Since the ESN is a fundamental identifier in a CDMA system, many standards are 2
impacted by the migration to MEID (and the corresponding UIMID to EUIMID 3
migration). The following subsections provide a brief overview of the function of the 4
various standards documents. The categorization into subsections is purely an 5
editorial convenience, and does not reflect any official designation. 6
4.1 MEID 7
4.1.1 Requirements 8
[S.R0048] is a brief document from 3GPP2 TSG-S that provides the Stage 1 9
requirements for MEID. 10
4.1.2 Administration 11
3GPP2 Steering Committee MEID GHA Assignment Guidelines and 12
Procedures[SC.R4002] describes the role of the MEID Global Hexadecimal 13
Administrator (GHA) in assigning manufacturer codes for MEIDs, and ensuring that 14
assigned resources are utilized efficiently. The allocation of responsibility between 15
the GHA and the Global Decimal Administrator (GDA) for IMEIs is further described 16
in the Global Wireless Equipment Numbering Administration Procedures 17
[SC.R4001]. 18
4.1.3 Billing 19
The Cellular Intercarrier Billing Exchange for Roamer (CIBER) record specification 20
includes an ESN field in many of its defined record types. The meaning of this field 21
has been expanded to include MEID as an alternate identifier, and a new value 22
signifying MEID has been defined for the associated indicator field. It is not possible 23
to include both a pESN or pUIMID and an MEID in a single CIBER record.24 24
24 CIBER is a proprietary protocol owned by MACH.
MEID and EUIMID Migration 4. Standards Involved
February, 2011 32
4.1.4 Air Interface 1
4.1.4.1 IS-2000 Release D and E 2
MEID was originally intended to be introduced in conjunction with IS-2000 Release 3
D. In this standard, MEID can replace the ESN as the device identifier used over the 4
air in the Link Access Control (LAC) layer. 5
Release D also allows the use (first added in Release C) of Public Long Code Mask 6
(PLCM) types not based on the ESN. 7
At present, there are no plans to commercialize IS-2000 releases B through D. 8
Because of this, the necessary changes for MEID (not including LAC address 9
modifications) have been retrofitted into earlier releases of IS-2000 (see Section 10
4.1.4.2 ). Capabilities provided only by Release D are not discussed further in this 11
document, and should not be anticipated by operators. 12
Release E (September, 2009) was designed in a modular fashion (with some 13
features not requiring P_REV changes) and allows access to the full range of 14
hardware identifiers (MEID_ME and ESN_ME) and card identifiers (SF_EUIMID, 15
LF_EUIMID and ICCID) via new record types in Status Request messages. These 16
new capabilities can be safely implemented in devices otherwise conforming to 17
older specifications. 18
4.1.4.2 Updates to earlier releases of IS-2000 19
[C.S0072] (TIA-1082) retrofits MEID into pre-Release D versions of IS-2000. It 20
provides the following capabilities: 21
• A Mobile Station (MS) can be equipped with an MEID, and can indicate this 22
by setting bit 4 of the Station Class Mark (SCM) to 1. Previously this bit had 23
the meaning of “IS-54 Power Class” and was always 0 for CDMA devices. 24
The SCM is already included by the MS in various messages. 25
Note: The Base Station (BS) does not advertise its support for MEID usage. 26
• New messages for the BS to assign a PLCM that is not derived from the 27
ESN (or pESN), and to manage handoffs (including inter-system hard 28
handoffs) with this new PLCM 29
• A new record type allowing the BS to retrieve the MEID from the MS via the 30
Status Request Message. 31
Note that the MEID is not used to form the MS LAC address used on the 32
access or paging channels. The address continues to use the ESN (or pESN, 33
in the case of a MEID-equipped MS). 34
C.S0072 uses the new PLCM types defined in IS-2000 Release D: 35
• PLCM specified by the Base Station (BS-assigned) 36
MEID and EUIMID Migration 4. Standards Involved
February, 2011 33
• PLCM derived from IMSI (2-types) 1
• PLCM derived from MEID 2
Of these types, IMSI-based PLCMs have limitations on their use for roamers from 3
other networks, and MEID-based PLCMs require extra messaging (to retrieve the 4
MEID from the MS before the PLCM can be assigned) and are not guaranteed to be 5
unique (as the MEID length is greater than that of the PLCM). Therefore the 6
recommended approach, and the one assumed throughout this document, is 7
BS-assigned PLCM. The IMSI and MEID PLCM types may be useful on system 8
borders the complexity of synchronizing the PLCM usage with BSs of another 9
operator may be greater than the tiny risk of collisions. 10
All MEID-equipped devices are expected to support C.S0072 (i.e. there should be 11
no devices launched with MEIDs that do not support the new messaging in 12
C.S0072). Some R-UIM capable devices are known to exist which have MEIDs, but 13
set SCM bit 4 to 0. This behavior is not recommended, and can lead to PLCM 14
collisions when EUIMID-equipped R-UIMs are used that cannot be resolved even 15
when all base stations are upgraded to support C.S0072. 16
Base stations should support at least the BS-assigned PLCM type. 17
4.1.4.3 1xEV-DO Revision A 18
Revision A of [C.S0024] adds support for an Access Terminal (AT) to use MEID as 19
its Hardware Identifier (HardwareID). HardwareID is optionally used in EVDO – it is 20
sent by the AT only if the Access Network (AN) explicitly requests it via the 21
HardwareIDRequest message. Most commercial networks are believed to request 22
the HardwareID from the AT (e.g. as a way to identify and tear down hung 23
sessions). 24
MEID support is defined in such a way (modifying the Default Address Management 25
Protocol, and using a HardwareIDType value for MEID from a range previously 26
allowed in Release 0) that a MEID-equipped AT can also return MEID as its 27
HardwareID to an EVDO Release 0 network. The possible values are shown in 28
Table 4-1: 29
HardwareIDType field value Meaning
0x010000 ESN
0x00ffff MEID
0x00NNNN, where NNNN is in the range 0x0000 to 0xfffe, inclusive.
See 3GPP2 C.R1001
0xffffff Null
All other values Invalid
MEID and EUIMID Migration 4. Standards Involved
February, 2011 34
Table 4-1 - EVDO HardwareIDType values 1
Note that only the ESN and MEID are defined for inclusion in the HardwareID field. 2
C.S0024-B v3.0 (September, 2009) clarifies that even when an R-UIM or CSIM is 3
inserted in an EV-DO device that the ESN or MEID should continue to be 4
transmitted, not the UIMID or EUIMID. There is no concept of a pESN in EV-DO – 5
an MEID device will return the MEID as its HardwareID. 6
4.1.5 ANSI-41 MAP Updates 7
ANSI-41 MAP provides a number of mobility management functions. Most of its 8
signaling messages include ESN as a mandatory parameter. The protocol does not 9
itself require uniqueness, but applications based on the protocol may make this 10
assumption. ANSI-41 does assume a fixed relationship between a MIN/IMSI and an 11
ESN or UIMID. It is this assumption that forces R-UIM equipped mobiles to transmit 12
UIMID or pUIMID rather than ESN or pESN. 13
[X.S0008] adds support for MEID into ANSI-41. It adds MEID as an optional 14
parameter in many messages that contain the ESN. Note that the 15
mandatory/optional status of the ESN parameter remains unchanged. The UIMID, 16
pESN or pUIMID can be used instead of ESN, transparently to ANSI-41. 17
X.S0008 also adds messaging to enable Equipment Identity Register (EIR) 18
functionality, which provides functions such as combating device theft by checking 19
the MEID against a list of known stolen devices or comparing with a list of 20
problematic devices. A generic request message that can be used to order retrieval 21
of the MEID from the MS is also added. This capability is effectively disabled if the 22
Short Form EUIMID replaces the hardware MEID in air interface signaling unless 23
the MEID_ME Status Request information record from CDMA2000 Release E is 24
implemented. 25
X.S0008 network modifications provide additional capabilities but are not considered 26
essential elements in MEID or EUIMID support. 27
4.1.6 Over-the-Air Activation 28
Over-the-Air activation is affected by the migration away from ESN, because ESN is 29
often used as the only unique identifier for an unprovisioned mobile. When a non-30
unique pESN is provided a mechanism to obtain a unique identifier to ensure the 31
correct device is being provisioned is needed. 32
[C.S0066] is a modification to C.S0016 / IS-683 that adds a mechanism for the 33
Over-the-Air Function (OTAF) platform to retrieve the MEID from a device, via the 34
Extended Protocol Capability Response Message. As with other OTAF messaging, 35
the information is carried back to the OTAF inside the SMS_BearerData parameter 36
of an ANSI-41 SMSDeliveryPointToPoint (SMDPP) message. This means that it is 37
possible to transmit MEID within the OTA protocol layer even when lower layers 38
(e.g. ANSI-41) do not support MEID. 39
MEID and EUIMID Migration 4. Standards Involved
February, 2011 35
[C.S0066] provides equivalent MEID handling capabilities to C.S0016-C/TIA-683-D 1
(with the exception of MEID LAC addressing), but it allows these capabilities to be 2
used with earlier revisions of C.S0016. 3
A negative interaction was discovered between MEID and band-class information in 4
both [C.S0016] and [C.S0066] that meant that information on band classes other 5
than 0 (Cellular 800 MHz), 1 (US PCS 1900), 3 (Japan 800 MHz) and 6 (IMT2000, 6
2.1 GHz) is only available during provisioning for mobiles that have been 7
provisioned with an MEID. 3GPP2 has addressed this issue in C.S0016-C v2.0 8
(October, 2008) and C.S0066-0 v2.0 (July, 2008). 9
The same new versions of C.S0016 and C.S0066 also allow the MEID_ME, ICCID 10
and EUIMID to be transmitted from a mobile equipped with R-UIM to the OTAF. 11
Previous versions only allowed the MEID to be transmitted (or the SF_EUIMID if 12
UsgInd bit 2 was set to ‘1’). 13
[X.S0033] is a modification to 3GPP2 N.S0011 / TIA IS-725 to support MEID. It adds 14
MEID as an optional parameter to various OTASP- and OTAPA-related messages. 15
Some of the content overlaps with X.S0008. 16
4.1.7 Interoperability and Testing 17
4.1.7.1 CDMA2000® Access Network Interoperability 18
The interoperability Specification (IOS) suite of standards ([A.S001x]) has been 19
updated (as of Version 5.0) to include support for MEID. MEID is added as an 20
optional parameter in many messages. Support is also added for the new PLCM 21
types. IOS Version 5.0.1 is compatible with C.S0072. 22
The MEID capabilities of this standard revision are primarily designed to support the 23
MEID handling as defined in IS-2000 Release D (i.e. MEID in the LAC address). 24
The transport options for MEID allowed by C.S0072 (Status Request Message) and 25
C.S0066 (Extended Protocol Capability Response Message) may be encapsulated 26
unchanged even by earlier revisions of IOS. Transport of the new PLCM types may 27
be necessary for inter-BSC soft handoff. 28
See [MEID Failure Bulletin] for a potential service-affecting issue related to the 29
interpretation of SCM bit 4 on this interface. The only known occurrence of this 30
problem was resolved in 2010. 31
These standards also define transport of the MEID over the A8/9 and A10/11 32
interfaces for packet data sessions. 33
4.1.7.2 HRPD Access Network Interoperability 34
[A.S0008] provides (in Revision A and later) support for MEID in the various “A” 35
interfaces for 1xEV-DO. Among other changes, Hardware-ID is added as an 36
optional parameter for A12 authentication, and MEID is listed as a possible 37
HardwareIDType. 38
MEID and EUIMID Migration 4. Standards Involved
February, 2011 36
4.1.7.3 CDMA2000® Signaling Testing for MEID 1
[C.S0073] provides a signaling test specification for MEID equipped CDMA2000® 2
mobile stations. Revision A of this specification (April, 2008) included test 3
sequences for MEID mobile stations with an R-UIM inserted, when EUIMID is the 4
card identifier. 5
4.1.7.4 CDMA2000® Wireless IP Network Standard 6
[X.S0011] defines requirements for support of wireless packet data networking 7
capability on a third generation wireless system based on CDMA2000®. Revision D 8
includes modifications to allow MEID to be carried on the various network interfaces, 9
and particularly for its inclusion in the “airlink record” and in Usage Data Records 10
(UDRs). 11
12
MEID and EUIMID Migration 4. Standards Involved
February, 2011 37
4.2 Expanded UIMID (EUIMID) 1
4.2.1 Requirements 2
3GPP2 TSG-S report Error! Reference source not found. provides the Stage 1 3
requirements for the EUIMID. Note that only C.S0016-C v2.0 and C.S0066-0 v2.0 4
contain the capabilities to fully satisfy all the requirements for OTAPA/OTASP and 5
CDMA2000 Release E contains all the capabilities to fully satisfy all the air interface 6
protocol requirements. 7
4.2.2 Administration 8
3GPP2 Steering Committee report [SC.R4003] describes the administration 9
procedures of the EUIMID, both short-and long-form. The document essentially 10
devolves LF_EUIMID administration to the existing ITU-T ICCID process, and 11
SF_EUIMID administration to the MEID administration process. 12
4.2.3 CDMA R-UIM 13
[C.S0023] defines the capabilities of the CDMA Removable User Identity Module 14
(R-UIM). Revision C added, among other things, a description of the Long Form 15
(LF) and Short Form (SF) EUIMID (see Section 3.3.2). This specification was 16
updated in C.S0023-C v2.0 to clarify the storage order of the SF_EUIMID and 17
describe how the pUIMID is calculated from the LF_EUIMID (ICCID). 18
4.2.4 CDMA SIM Application 19
[C.S0065] describes the CDMA Subscriber Identity Module (CSIM), an application 20
residing on the Universal Integrated Circuit Card (UICC). UICC provides a generic 21
platform for applications such as CSIM, and the UMTS Subscriber Identity Module 22
(USIM) used in GSM-evolved 3G systems. CSIM represents an evolution from the 23
existing R-UIM standard, however C.S0065 provides equivalent capabilities to 24
C.S0023 with respect to EUIMID. 25
In this document, the term R-UIM is used generically to refer to Identity Module card 26
for CDMA networks, and can include the CSIM as well. 27
[C.S0065] was updated in July 2008 (C.S0065-0 v2.0) to clarify the storage order of 28
the SF_EUIMID and describe how the pUIMID is calculated from the LF_EUIMID. 29
5. EUIMID Migration Options 1
An important decision for an R-UIM operator is the nature of EUIMID to which the 2
operator will migrate. As discussed in Section 3.3.2, two forms of EUIMID are 3
defined in the standards. This section discusses the advantages and disadvantages 4
of the two approaches. In many cases, examples and call-flows for the specific 5
cases are given in Section 7. 6
5.1 Long-Form EUIMID 7
The LF_EUIMID is an identifier that can be up to 72 bits long, and is equal to the 8
existing ICCID of the card25. Advantages and disadvantages are as follows: 9
Advantages: 10
• Simplicity. The ICCID is an existing identifier for the card. There are no new 11
storage requirements in terms of files on the R-UIM to support LF_EUIMID. 12
Administration procedures are already established for ICCID. 13
• Backward compatibility. With no new data structures to support, current 14
cards (that may not support C.S0023-C) can simply have the pUIMID 15
programmed into the EFRUIMID file on the card, and operate as LF_EUIMID 16
cards26. There are no new requirements on devices to support LF_EUIMID 17
unless access to the identifier is required. PLCM collisions are possible if the 18
device in which the card is inserted does not support C.S0072. 19
• EIR Support. Since the device MEID (if present) remains available to the 20
network, use of LF_EUIMID allows easier implementation of an EIR to 21
track/block lost/stolen devices. 22
• Retrievable During Provisioning. If C.S0016-C v2.0 or C.S0066-0 v2.0 is 23
implemented in mobiles and in the OTAF the LF_EUIMID will be available 24
during provisioning with OTASP. 25
25 In practice the full 80 bit value contained in the R-UIM field EFICCID is used, which includes a check digit and filler digit (0xf) in addition to the ICCID.
26 A theoretical problem scenario arises when a TMSI is used (stored on the card), the handset pESN is used for identification (Usage Indicator b1 = 0), and the card is moved between two different MEID handsets that have the same pESN. A non-C.S0023-C-compliant card cannot receive the handset MEID, and can therefore not detect that it has been inserted in a different handset, and that the TMSI must be rebound to the new MEID.
MEID and EUIMID Migration 6. Recommendations
February, 2011 39
• Retrievable At Other Times. If the appropriate components of the 1
CDMA2000 Release E air interface are implemented by both the RAN and the 2
ME it is possible to retrieve the LF_EUIMID using a Status Request message. 3
Disadvantages: 4
• Not retrievable. The LF_EUIMID is only retrievable from the card via 5
messaging in C.S0016-C v2.0 (October, 2008), C.S0066-0 v2.0 (July, 2008) 6
and CDMA2000 Release E (September, 2009). It may also be accessible 7
through the CDMA Card Application Toolkit (CCAT, see Section 5.3 below). If 8
not available, there may be an impact on OTASP sessions, where (depending 9
on operator implementation) a unique card identifier may be needed to access 10
card-specific information. 11
• Long Identifier. The 72-bit ICCID, if used to track the card (e.g. from a 12
logistics perspective), will require separate handling from the device MEID. As 13
a longer identifier it is also arguably more prone to keying errors (although a 14
check digit mechanism is also defined for ICCIDs). 15
• Issuer Identifier Number (IIN) Limitations. Countries with 3 digit telephony 16
country codes (as defined in ITU-T E.164) are restricted to only 100 unique 17
IINs. Countries with 2 digit country codes have 1000 unique IINs and those 18
with 1 digit country codes (e.g. North America and the Caribbean) have 10,000 19
IINs available. This is only a minor limitation because the IIN is generally 20
assigned to an operator, which then assigns arbitrary sized subsets to their R-21
UIM suppliers. 22
5.2 Short-Form EUIMID 23
The SF_EUIMID is a 56-bit identifier, sharing address space with the MEID. An 24
R-UIM indicates its use of SF_EUIMID via service n8 in the CDMA Service Table27. 25
An additional option is available with use of the SF_EUIMID, namely the setting of 26
bit 2 of the Usage Indicator octet. When the bit is set to 0 (SF_EUIMID does not 27
override the ME’s MEID), use of the SF_EUIMID shares the disadvantages but not 28
the advantages of the LF_EUIMID – it is not retrievable from the card without 29
support for C.S0066-0 v2.0, C.S0016-C v2.0 or CDMA2000 Release E, yet it 30
requires new storage and handling capabilities. One benefit – that of using a 31
common identifier size to track both cards and devices – does not seem sufficient to 32
warrant the use of this configuration. Accordingly, the advantages and 33
27 See C.S0023-C Section 3.4.18
MEID and EUIMID Migration 6. Recommendations
February, 2011 40
disadvantages listed below assume the Usage Indicator bit 2 is set to 1 – i.e. the 1
SF_EUIMID is used in place of the ME MEID.28 2
Advantages: 3
• Familiarity. Use of the SF_EUIMID represents a minimum change from 4
current operation, where the UIMID overrides the device ESN. 5
• Retrievable. The unique SF_EUIMID is available from the MS in either the 6
Status Response Message, or the Extended Protocol Capability Response 7
Message (both methods require the device itself to have an MEID). 8
• Common Identifier. Both the card and the device can be managed by a 9
commonly formatted and administered 56-bit identifier. (Although both the 10
MEID of the device and the SF_EUIMID of the R-UIM are only available via air 11
interface signaling if C.S0016-C v2.0. C.S0066-C v2.0 or CDMA2000 Release 12
E is implemented.) 13
14
Disadvantages: 15
• Card/device requirements. The SF_EUIMID is defined in C.S0023-C v2.0 16
and C.S0065-0 v2.0. Cards and devices which do not support this level of 17
either standard (or at least, this aspect of this level of the standard) will not be 18
able to override the device MEID. Many R-UIM-based devices in commercial 19
use today do not support C.S0023-C v2.0. 20
• No EIR. Since the device MEID is unlikely to be transmitted to the network by 21
legacy mobiles, it may not be feasible to take advantage of the new X.S0008 22
CheckMEID operation to track lost, stolen or malfunctioning phones through 23
communications with an EIR. 24
5.3 CDMA Card Application Toolkit (CCAT) 25
[C.S0035] defines the CDMA Card Application Toolkit (CCAT). CCAT defines the 26
means by which an application resident on the R-UIM interacts with the ME and can 27
initiate communication with the network. It may be possible to define a CCAT 28
application which can retrieve and send the LF_EUIMID (e.g. inside an SMS to an 29
address that terminates to a network-based application). Comments elsewhere in 30
this document to the effect that “LF_EUIMID cannot be transmitted to the network” 31
do not reflect this possibility. 32
28 A theoretical problem scenario could arise in IS-2000 Release D, if the MSID_TYPE is IMSI + MEID, but bit 1 and bit 2 of the Usage Indicator are not set to the same value: in this case, the input to the CAVE algorithm may not be available to the network to check the authentication result.
MEID and EUIMID Migration 6. Recommendations
February, 2011 41
Similarly, the ME’s MEID could be sent to the network even if normally overwritten 1
by the SF_EUIMID29. The equivalent note applies to other references in this 2
document to the inaccessibility of this value to the network. 3
The UIM Tool Kit (UTK) is an alternative R-UIM application mechanism to CCAT, 4
which may provide equivalent opportunities for transfer of otherwise inaccessible 5
identifiers to the network. UTK is less formally standardized (see CDG reference 6
Document #76), but may be in wider commercial deployment than CCAT. 7
5.4 Device Compatibility with EUIMID 8
An issue has been identified with some devices currently in the field that prevents 9
them operating when an EUIMID-equipped R-UIM is inserted. These devices 10
contain the software feature to support MEID but do have an ESN rather than an 11
MEID provisioned. Operators should check with their handset suppliers for affected 12
models.13
29 R-UIM access to the ME’s MEID may depend on the card activating service n9 (“MEID Support”). Some early commercially released EUIMID-equipped did not support n9.
1
6. Recommendations 2
The subsections below list recommended actions for operators as they migrate to 3
MEID-equipped devices, and (possibly) EUIMID-equipped R-UIMs. 4
The recommendations are divided according to usage of R-UIMs. In several cases 5
the same recommendation applies to both types of operator. 6
6.1 Operators with non-R-UIM-equipped handsets 7
The following actions are recommended: 8
• Ensure basic MEID backwards compatibility. An immediate 9
recommendation is for operators to ensure that MEID-equipped devices can 10
receive service. Actions involve investigation, and if necessary patches and/or 11
upgrades to the MSC/BSC. See the [MEID Failure Bulletin] for more 12
information. 13
• Add C.S0072 support in the network. C.S0072 allows BS-assigned PLCMs 14
to prevent cross-talk and dropped calls due to pESN-based PLCM, and also 15
allows the MEID to be retrieved from the device. 16
• Do not hash check at the BS/MSC. Hash checking implies verifying that the 17
received “MEID” value will hash to the received “ESN” value. While this may 18
be a valid assumption for the operator’s own subscribers, it may not hold true 19
for inbound roamers present on the operator’s network (e.g. if they use 20
LF_EUIMID, or a unique UIMID, the UIMID/pUIMID will not be hash-related to 21
the ME MEID). Although such checking is not believed to be common, if 22
implemented it may erroneously deny service to a valid subscriber. 23
• Stop ESN-based addressing on paging channel. Duplicated pESNs can 24
cause unpredictable results since more than one mobile may process a 25
message intended for a single MS. The alternative is to move to IMSI-based 26
addressing where this problem cannot occur with legitimate mobiles. 27
• Remove network element and back-end dependency on unique ESN. The 28
specific actions will depend on the operator’s systems, and may apply to HLR, 29
VLR, billing, provisioning, fraud systems etc. Either the uniqueness check may 30
be relaxed, or the check may be applied to the MEID instead (assuming MEID 31
is reliably available at the necessary location). 32
MEID and EUIMID Migration 6. Recommendations
February, 2011 43
• Support C.S0066 for OTASP. If OTASP is used in the operator’s network, 1
and there is a need to reference device-specific information (e.g. A-key, SPC) 2
during the OTASP process, then C.S0066-0 v2.0 should be supported to allow 3
the MEID to be transferred to the OTAF. 4
• Index OTASPCallEntry by Activation_MIN. The use of Activation_MIN 5
allows concurrent OTASP sessions for mobiles with the same pESN. 6
• Evaluate X.S0008 support. Operators may choose to implement X.S0008 7
(MEID for ANSI-41) in their networks. This can be of use for stolen phone 8
scenarios, and in general allows a unique device identifier to be stored in the 9
HLR. 10
• Evaluate MEID inclusion in CDRs. Operators may choose to include MEID in 11
their MSC billing records, with associated upgrades to the billing. 12
Note: The previous two recommendations both require retrieval of the MEID 13
over the air interface, at some small capacity cost. Some vendors may 14
automatically initiate MEID retrieval whenever the MS indicates it has an 15
MEID. 16
• Ensure Uniqueness of NAIs. Network Access Identifiers (NAIs) derived from 17
the ESN should be replaced with a unique alternative, such as MEID-derived 18
NAIs (e.g. MEID@realm). 19
• Check support for MEID in PCF, PDSN and AAA. The airlink record sent 20
between the PCF and PDSN, and used to form the PDSN UDR that is sent to 21
the AAA, contains either MEID or ESN. While pESN may be used in non-22
upgraded 1X systems, the pESN is not available in EVDO unless it is 23
calculated from the MEID. 24
• Add support for MEID as EVDO Hardware ID. Operators who use the 25
Hardware ID in A12 authentication should ensure that MEID is supported as 26
per A.S0008-A. 27
• Outbound Roaming Support. Operators should recognize that not all 28
roaming partners will necessarily support the MEID/EUIMID migration to the 29
same degree. MEID inclusion should not be mandatory (from the perspective 30
of the receiving entity and any subsequent processing) on any inter-network 31
interface, including: 32
o ANSI-41 Interfaces 33
o CIBER Records 34
o A12 Authentication 35
36
MEID and EUIMID Migration 6. Recommendations
February, 2011 44
o CIBER Record Population. Assuming both a 32- and 56-bit 1
identifier are captured in the MSC CDR (which may be either 2
ESN/pESN/UIMID/pUIMID or MEID/SF_EUIMID respectively), it is 3
recommended that the 32-bit identifier be included until it is either 4
verified that all roaming partners support MEID or SF_EUIMID in 5
CIBER records or the system is capable of storing the capability of 6
every roaming partner individually. 7
Note that inbound roamers may use R-UIMs, even if the operator’s own 8
subscribers do not. 9
• Unique pESNs. If operators are struggling to accommodate duplicate pESNs 10
in the required timeframe, a potential mitigation approach is to require only 11
unique pESNs be delivered to them from handset manufacturers. This is a last 12
resort action only, and is discouraged for the following reasons: 13
o It may distract operators from properly addressing the required 14
updates 15
o It may impose an unreasonable management burden on handset 16
manufacturers, and cause them to “waste” large numbers of 17
MEIDs30. 18
o It becomes progressively more difficult to implement as the number 19
of deployed pESNs rises. 20
o Only ~16.7 million different pESNs are available – beyond this 21
uniqueness is not possible. 22
o Collisions or duplications due to roamers are not addressed – these 23
may still occur beyond the operator’s control. 24
o It is only possible with handsets purchased by the operator. 25
• Authentication. S.S0053-0 v2.0 specifies that authentication operations 26
specify ESN, including in CAVE calculations and A-Key checksum generation, 27
pESN should be used instead. There is no loss of security even though this 28
input may not be unique. 29
30 With multiple handset manufacturers supplying a single operator, each manufacturer may be restricted to a portion of the pESN address space for that operator, further increasing the wastage of MEIDs.
MEID and EUIMID Migration 6. Recommendations
February, 2011 45
6.2 Operators with R-UIM-equipped handsets 1
The following actions are recommended: 2
• Ensure basic MEID backwards compatibility. An immediate 3
recommendation is for operators to ensure that MEID-equipped devices can 4
receive service. Actions involve investigation, and if necessary patches and/or 5
upgrades to the MSC/BSC. See the [MEID Failure Bulletin] for more 6
information. 7
• Add C.S0072 support in the network. C.S0072 allows BS-assigned PLCMs 8
to prevent cross-talk and dropped calls due to pUIMID-based PLCM, and also 9
allows the MEID/SF_EUIMID to be retrieved from the device. 10
• Do not hash check at the BS/MSC or HLR. Hash checking implies verifying 11
that the SHA-1 hash of the received “MEID” matches the received “ESN” 12
value. Use of the LF_EUIMID, or unique UIMID (or SF_EUIMID in a MEID-13
equipped device that does not support C.S0023-C) will result in a 32-bit 14
identifier being sourced from the R-UIM, and a 56-bit identifier from the ME, 15
which will not be hash-related. Any such checking may erroneously deny 16
service to a valid subscriber. 17
• Stop ESN-based addressing on the paging channel. Duplicate pUIMIDs 18
can cause unpredictable results since more than one mobile may process a 19
message intended for a single MS. The alternative is to move to IMSI-based 20
addressing where this problem cannot occur with legitimate mobiles. 21
• Decide on EUIMID format. The operator should consider the characteristics 22
discussed in Section 5. and then choose either Long Form or Short Form 23
EUIMID. 24
• Verify handset compatibility with EUIMID. The operator should check 25
whether any handset models currently in circulation will fail to operate with an 26
EUIMID-equipped R-UIM (see Section 5.4 ). 27
• Verify device/card support for EUIMID. In particular this applies to 28
SF_EUIMID, which imposes new requirements on the card and device. 29
• Deploy MEID-equipped devices. Even with C.S0072 support in the network, 30
an EUIMID-equipped R-UIM in an ESN-equipped device is susceptible to 31
PLCM collision, and may prove challenging for OTASP without custom 32
handling as discussed below. 33
• Remove network element and back-end dependency on unique UIMID 34
and ESN. The specific actions will depend on the operator’s systems, and may 35
apply to HLR, VLR, billing, provisioning, fraud systems etc. Either the UIMID 36
uniqueness check may be relaxed, or the check may be applied to the EUIMID 37
instead (assuming EUIMID is reliably available at the necessary location). 38
MEID and EUIMID Migration 6. Recommendations
February, 2011 46
Inventory management etc may also need to move from the ESN to the MEID 1
to track/report on devices (even though these identifiers may not be available 2
in air interface signaling). 3
• Support OTASP modifications if unique card information required. If 4
OTASP is used in the operator’s network, the card does not come pre-5
provisioned with MDN, MIN or IMSI, and there is a need to reference card-6
specific information (e.g. A-key, SPC) during the OTASP process, then 7
C.S0066-0 v1.0 should be supported to allow the SF_EUIMID to be transferred 8
to the OTAF or C.S0066-0 v2.0 to allow both the MEID and EUIMID (either 9
form) to be transferred. Alternatively, and to achieve the ability to provision 10
EUIMID cards in ESN mobiles, the EUIMID can be stored in fields such as 11
MDN and IMSI_T that are accessible to all ESN mobiles and that may not 12
need to contain the intended data prior to provisioning. 13
• Avoid static card-specific information in OTASP if unique identifier 14
unavailable. If no unique card identifier is retrievable, alternative approaches 15
to card-specific information can be used instead of indexing a pre-provisioned 16
database. These could include: 17
o Secure generation of A-key during OTASP session 18
o Cards issued with default SPC (Service Programming Code), set to 19
random value during OTASP session 20
The lack of a unique identifier may also prompt operators to implement PIN-or 21
PRL-based methods to ensure that the activation is completed to the correct 22
operator. 23
• Index OTASPCallEntry by Activation_MIN. The use of Activation_MIN 24
allows concurrent OTASP sessions for mobiles with the same pUIMID. 25
• Evaluate X.S0008 support. Operators may choose to implement X.S0008 26
(MEID for ANSI-41) in their networks. This can be of use for stolen phone 27
scenarios (with LF_EUIMID), or to allow a unique card identifier to be stored in 28
the HLR (with SF_EUIMID). Implementation of an Equipment Identity Register 29
is at the operator’s discretion. 30
• Evaluate MEID/SF_EUIMID inclusion in CDRs. Operators may choose to 31
include MEID/SF_EUIMID in their MSC call detail records, with associated 32
upgrades to the billing system to parse this new record. 33
Note: The previous two recommendations both require retrieval of the 34
MEID/SF_EUIMID over the air interface, at some small capacity cost. Some 35
vendors may automatically initiate MEID/SF_EUIMID retrieval whenever the 36
MS indicates it has an MEID and the system has not recently retrieved it. 37
• Check support for MEID in PCF, PDSN and AAA. The airlink record sent 38
between the PCF and PDSN, and used to form the PDSN UDR that is sent to 39
the AAA, contains either MEID or ESN. While pESN may be used in non-40
MEID and EUIMID Migration 6. Recommendations
February, 2011 47
upgraded 1X systems, the pESN is not available in EVDO unless it is 1
calculated from the MEID. 2
• Ensure Uniqueness of NAIs. Network Access Identifiers (NAIs) derived from 3
the UIMID should be replaced with EUIMID-derived NAIs 4
(e.g. EUIMID@realm). 5
• Add support for MEID as EVDO Hardware ID. Operators who use the 6
Hardware ID in A12 authentication should ensure that MEID is supported as 7
per A.S0008-A. The Hardware ID is either ESN_ME or MEID_ME, never 8
UIMID or EUIMID. 9
• Outbound Roaming Support. Operators should recognize that not all 10
roaming partners may support the MEID/EUIMID migration to the same 11
degree. MEID/SF_EUIMID inclusion should not be mandatory (from the 12
perspective of the receiving entity and any subsequent processing) on any 13
inter-network interface, including: 14
o ANSI-41 Interfaces 15
o CIBER Records 16
o A12 Authentication 17
o CIBER Record Population. Assuming both a 32- and 56-bit 18
identifier are captured in the MSC CDR (which may be either 19
ESN/pESN/UIMID/pUIMID or MEID/SF_EUIMID respectively), it is 20
recommended that the 32-bit identifier be included until it is either 21
verified that all roaming partners support MEID or SF_EUIMID in 22
CIBER records or the system is capable of storing the capability of 23
every roaming partner individually. 24
• Unique pUIMIDs. If operators are struggling to accommodate duplicate 25
pUIMIDs in the required timeframe, a potential mitigation approach is to 26
require only distinct pUIMIDs be delivered to them from R-UIM manufacturers. 27
This is a last resort action only, and is discouraged for the following reasons: 28
o It may distract operators from properly addressing the required 29
updates 30
o It may impose an unreasonable management burden on R-UIM 31
manufacturers, and cause them to “waste” large numbers of 32
EUIMIDs31. 33
o It becomes progressively more difficult to implement as the number 34
of deployed pUIMIDs rises. 35
o Only ~16.7 million different pUIMIDs are available – beyond this 36
uniqueness is not possible. 37
31 With multiple card manufacturers supplying a single operator, each manufacturer may be restricted to a portion of the pUIMID address space for that operator, further increasing the wastage of EUIMIDs.
MEID and EUIMID Migration 6. Recommendations
February, 2011 48
o Collisions or duplications due to roamers are not addressed – these 1
may still occur beyond the operator’s control. 2
• Authentication. S.S0053-0 v2.0 specifies that everywhere that authentication 3
operations specify ESN, including in CAVE calculations and A-Key checksum 4
generation, UIMID should have been used in R-UIM devices. Now, pUIMID 5
should be used instead. There is no loss of security even though this input 6
may not be unique. 7
8
7. Scenarios 1
This section describes specific scenarios, the changes imposed by the migration to 2
MEID/EUIMID, and/or the impacts caused by duplicate 32-bit identifiers. Note that 3
the call-flow diagrams presented in this section are intended to highlight relevant 4
aspects, and may not include all messages/responses for the scenario in question. 5
The scenarios are grouped according to different operator choices about the type of 6
device and/or R-UIM that their subscribers use. Except when explicitly noted, the 7
assumption is made that the network supports C.S0072. In some cases, information 8
may be duplicated, or refer to previously described scenarios. 9
MEID and EUIMID Migration 7. Scenarios
February, 2011 50
7.1 Device / R-UIM Combinations of Interest 1
Figure 7-1 below shows the expansion of different R-UIM and device combinations, 2
and highlights the ones that will be considered (although potentially found to be 3
problematic) in the scenarios below. For all R-UIM cases, the assumption is made 4
that bit 1 of the usage indicator is set to 1 (i.e. UIMID overrides ESN) – this is 5
consistent with current R-UIM operator practice. 6
As an example, the branch on the extreme right of the diagram represents the 7
following combination: 8
• Device Type: R-UIM 9
• UIM Type: UIMID 10
• EUIMID Type: N/A 11
• SF_EUIMID Usage Indicator: N/A 12
• Device ID Type: MEID 13
ESN
MEID
Use EUIMID Use MEID
ESN
MEID
ESN
MEID
ESN
MEID
SF_EUIMID LF_EUIMID
EUIMID UIMID
R-UIMNo R-UIMDevice Type
UIM Type
EUIMID Type
SF_EUIMID Usage Ind
Device ID Type
X Combination for consideration
X
X
Existing operation – no change
No benefit over LF_EUIMID 14
Figure 7-1 - Device & Card Combinations 15
MEID and EUIMID Migration 7. Scenarios
February, 2011 51
7.2 Non-R-UIM Operator 1
The scenarios in this subsection apply to an operator whose subscribers use 2
devices that do not require an R-UIM. Only new cases (i.e. MS is equipped with 3
MEID) are considered – any new standards impose no changes on present-day 4
operation. 5
7.2.1 Basic Operation 6
7.2.1.1 Registration – No X.S0008 support 7
This scenario describes registration for an MEID-equipped MS. The network has not 8
implemented the ANSI-41 changes to support MEID. The steps are shown in Figure 9
7-2 below: 10
HLR
VLR + MSC + BS
a
b
cregnot
d
REGNOT [MSID, pESN]
RGM [IMSI, pESN, SCM]
ORDM
11
Figure 7-2 - MEID MS Registration - no X.S0008 support 12
Steps are as follows: 13
a) MS sends a Registration Message, including its IMSI, pESN and Station 14
Class Mark set to indicate MEID support. The MS cannot include its MEID in 15
this message. 16
b) Although the MSC is aware that the MS has a MEID, it takes no specific 17
action. It proceeds with the RegistrationNotification INVOKE message, 18
including the pESN and the Mobile Station Identity (MSID – either MIN or 19
IMSI) 20
c) The HLR validates the subscription on the basis of MSID-pESN. This 21
combination is unique even though the same pESN value may be used by 22
other MSs with different IMSIs although some HLRs are known to reject 23
REGNOT messages with a pESN that matches a pESN that is already 24
stored. The HLR returns the subscriber profile to the MSC. 25
d) Optionally, the BS sends a Registration Accepted Order to the MS 26
MEID and EUIMID Migration 7. Scenarios
February, 2011 52
7.2.1.2 Registration – X.S0008 supported 1
This scenario describes registration for an MEID-equipped MS. The network has 2
implemented the ANSI-41 changes to support MEID. The steps are shown in Figure 3
7-3 below: 4
HLR
VLR + MSC + BS
a
b
c
regnot [MEIDValidated]d
REGNOT [MSID, pESN, MEID]
e
RGM [IMSI, pESN, SCM]
STRQM
STRPM [MEID]
fORDM
5
Figure 7-3 - MEID MS Registration - X.S0008 supported 6
Steps are as follows: 7
a) MS sends a Registration Message, including its IMSI, pESN and Station 8
Class Mark set to indicate MEID support. The MS cannot include its MEID in 9
this message. 10
b) Based on the SCM, the MSC recognizes that the mobile has a MEID, and 11
that the MSC does not know this value. It solicits the MEID via the Status 12
Request Message (new Information Record in C.S0072). 13
c) The MS returns its MEID in the Status Response Message 14
d) The MSC sends a RegistrationNotification to the HLR, including the MSID, 15
pESN (required for backwards compatibility) and the MEID. 16
e) Text extracted from X.S0008: “Based on the existence of a provisioned 17
MEID value for this subscription, and the presence of the MEID parameter in 18
the REGNOT, the HLR includes an MEID comparison in the validation of the 19
subscription. The HLR then registers the indicated MS and returns a regnot 20
to the Serving VLR. The regnot includes the MEIDValidated parameter to 21
inform the Serving VLR/MSC that the MEID associated with the system 22
access has been validated.” 23
f) Optionally, the BS sends a Registration Accepted Order to the MS 24
MEID and EUIMID Migration 7. Scenarios
February, 2011 53
7.2.1.3 Authentication 1
This scenario provides a representative example of the various authentication use 2
cases possible. If X.S0008 is supported, MEID may be included in various 3
authentication messages, but it is not used in actual authentication computations. 4
The steps are shown in Figure 7-4: 5
HLR/AC
VLR + MSC + BS
a
b
c
AUTHREQ [MSID, pESN, AUTHR]
(System Access [pESN, AUTHR])
authreq
6
Figure 7-4 - Authentication of MEID device 7
Steps are as follows: 8
a) MS makes a system access. It includes its pESN and the Authentication 9
Response parameter (other authentication-related information and SCM not 10
shown). 11
b) The MSC determines it needs to request authentication at the HLR/AC (e.g. 12
SSD is not shared, or this is the first system access). The MSC sends an 13
AuthenticationRequest to the HLR/AC. MEID may also be requested by the 14
MSC and included in the AUTHREQ. 15
c) The AC computes the challenge result and compares it with the received 16
response. The pESN is used in the calculation, but not the MEID, even if it is 17
received. The HLR/AC returns an authreq to the MSC to advise that the 18
challenge was successfully passed. 19
An Authentication scenario not involving signaling is the calculation of the 6-digit 20
checksum used when entering the A-key manually via the handset keypad. The 21
algorithm is defined in S.S005332, where the A-key and the ESN are used as inputs. 22
This standard makes no mention of MEID. At least one operator is known to have 23
specified MEID to replace pESN as the input to this algorithm but S.S0053-0 v2.0 24
clarifies that the same value used for CAVE authentication should be used 25
(i.e. pESN). 26
32 http://www.3gpp2.org/Public_html/specs/S.S0053-0_v2.0.pdf
MEID and EUIMID Migration 7. Scenarios
February, 2011 54
7.2.1.4 Call Origination/Termination 1
In this scenario, the mobile makes or receives a call. Since the mobile is MEID-2
equipped, the network assigns a PLCM explicitly rather than using one derived from 3
the pESN. The steps are shown in Figure 7-5: 4
BS
a
b
cMECAM [PLCM]
d
e
ORM or PRM [pESN, SCM]
STRQM
STRPM [MEID]
f
Traffic Channel Initialization
STRQM
STRPM [MEID]g
5
Figure 7-5 - MEID Origination/Termination 6
Steps are as follows: 7
a) The MS sends an Origination Message or a Page Response Message, 8
including its pESN and SCM 9
b-c) Optionally, the MSC queries the MEID via a Status Request Message over 10
the paging channel, and the MS responds. This would be required if the 11
MSC used the MEID-based PLCM type. 12
d) Since the MS has advertised that it has a MEID via the SCM, the MSC 13
sends an MEID Enhanced Channel Assignment Message (new for 14
C.S0072). The message includes the PLCM_TYPE field, and (if the 15
PLCM_TYPE indicates BS-assigned) the PLCM itself. 16
e) The traffic channel is initialized as normal, using the PLCM as agreed above 17
f-g) Optionally, the MSC can query the MEID via a Status Request Message sent 18
on the traffic channel, and the MS responds. 19
7.2.1.5 Billing Record Production 20
MSC Call Detail Records (CDRs) typically include the MIN/IMSI and ESN of a 21
mobile. With the migration to MEID-equipped MSs, operators may wish to retain a 22
unique identifier for the mobile hardware in their CDRs. Obtaining this identifier (the 23
MEID) will require operators to support the retrieval of the MEID via the Status 24
Request Message either at registration time or call time (see Sections 7.2.1.2 and 25
7.2.1.4 respectively). 26
MEID and EUIMID Migration 7. Scenarios
February, 2011 55
7.2.1.6 Mobile Terminated SMS 1
This scenario shows an undesirable result of a message addressed by ESN only. 2
Even with C.S0072 support in the network, this effect can still occur. The Data Burst 3
Message used to carry the SMS is only one example of a message that could be 4
addressed in this way – see Section 2.1.3 for more details. The steps are shown in 5
Figure 7-6 below - in this diagram, MS1 and MS2 are both in the same sector: 6
BS
a
b
c
d
e
GPM [IMSI]
MS1 MS2
Same pESN
PRM
DBM [pESN, Message]
(Ack)
(Ack)
7
Figure 7-6 - ESN-based addressing conflict 8
Steps are as follows: 9
a) The BS sends a General Page Message (GPM) to alert the mobile that there 10
is an SMS message for it. The GPM is addressed to the IMSI of the mobile 11
for whom the SMS is intended (MS1). This message is typically sent over a 12
wide area in order to find the mobile. 13
b) MS1 responds to the page. 14
c) The BS sends a Data Burst Message (DBM) containing the SMS. The DBM 15
is typically sent only on the sector on which the MS responded to the page. 16
In this example, the message length is such that the network chooses to 17
send it on the paging channel, rather than establishing a traffic channel, and 18
the message is addressed using the “ESN” address type. The value in the 19
ESN field is the pESN, which happens to be common to both MS1 & MS2. 20
Both mobiles receive the text message. 21
d-e) Both mobiles send an acknowledgment. 22
Note that the alternative addressing (IMSI-based) may be susceptible to a similar 23
problem if the operator sends Data Burst Messages on the paging channel, but this 24
requires that a mobile is provisioned with the IMSI of a mobile it wishes to receive 25
text messages for and must remain in the vicinity of the target mobile. Legitimate 26
mobiles will not receive IMSI-addressed text messages destined for other mobiles 27
as only one mobile will ever be the legitimate holder of an IMSI at any one time. The 28
most likely scenario where multiple delivery will be found is when a subscriber 29
purchases a new phone and, while the old phone is still powered on and in the 30
vicinity of the new phone, notices that SMS messages are still received by their old 31
phone. 32
MEID and EUIMID Migration 7. Scenarios
February, 2011 56
7.2.1.7 Handoff 1
C.S0072 defines the new MEID Universal Handoff Message (MUHDM). This 2
message allows the PLCM to be specified/modified at handoff time. Figure 7-7 3
shows an MEID-equipped mobile handing off between two C.S0072-compliant Base 4
Stations: 5
Target BS Source BS
a
b
c
d
Traffic Channel (BS-assigned PLCM)
MUHDM
HOCM
Traffic Channel (BS-assigned PLCM)
6
Figure 7-7 - MEID Handoff 7
Steps are as follows: 8
a) The MS is operating on a traffic channel in communication with the source 9
BS. AS per Section 7.2.1.4 , the MS uses a BS-assigned PLCM. 10
b) The source BS sends a MUHDM. This message can include the PLCM type 11
if it is to be changed, or omit it to retain the same PLCM. 12
c) The MS sends a Handoff Complete Message to the Target BS. 13
d) The traffic channel is established with the new BS. 14
If the handoff requires coordination via the MSC, IOS 5.0.1 (or higher) must be 15
implemented on that interface to carry the PLCM information. 16
If the source and target BSs differ in their support of C.S0072 (e.g. during the 17
network upgrade process), a PLCM change may be required at handoff. Table 7-1 18
lists the various combinations: 19
Target BS
Source BS No C.S0072 Support C.S0072 Support
No C.S0072 Support Continue pESN-based PLCM in UHDM
Continue pESN-based PLCM in UHDM. Subsequent MUHDM could change to a different PLCM
C.S0072 Support Change to pESN-based PLCM in MUHDM
Could continue with BS-assigned PLCM via MUHDM
Table 7-1 - Handoff matrix for C.S0072 support levels 20
MEID and EUIMID Migration 7. Scenarios
February, 2011 57
7.2.2 Data Services 1
7.2.2.1 CDMA2000® Packet Data 2
Some operators use a Network Access Identifier (NAI) of the format ESN@realm. 3
Default provisioning of this value should be changed to a unique value, such as 4
MEID@realm. 5
Origination and PLCM assignment is as for voice. 6
Either MEID or pESN (or both) is included in the airlink record sent from the PCF to 7
the PDSN33, and included in the PDSN UDR sent to the AAA. If MEID is sent, the 8
receiving entity must be capable of accepting it (and if the pESN is absent the 9
receiving entity must not consider it required). 10
7.2.2.2 1xEV-DO Packet Data 11
An AT can provide its Hardware ID in response to a HardwareIDRequest Message. 12
When the AT is provisioned with an MEID, it will include this value as its Hardware-13
ID, with a specific HardwareIDType. 14
In order to include this identifier on the A12 interface, the AN must recode the 15
HardwareIDType to the value specified in A.S0008-A. In other words, the AN cannot 16
simply pass the information received from the AT transparently – it must explicitly 17
understand the “MEID” HardwareIDType, and recode this to the “Type of Identity” 18
coding for MEID, as specified in A.S0016-C (referenced from A.S0008-A Annex E) 19
in order to build a properly formatted A12 message. 20
Only the MEID is available to be included into an airlink record and subsequently 21
into the PDSN UDR (assuming derivation of the pESN is not performed). The PCF, 22
PDSN and AAA must all be capable of receiving the MEID instead of an ESN field. 23
7.2.2.3 Other Applications 24
Any applications (e.g. Java, LBS, MediaPlayer for DRM etc) that today use ESN as 25
a unique equipment identifier should be modified to use MEID instead. In the event 26
that the application uses IMSI, or IMSI+ESN as a unique (subscriber and/or 27
equipment) identifier, this scheme can be retained with the move to MEID. 28
33 See A.S0017-C v2 sections 2.3 and 4.2.13, and X.S0011-005-D v1 section 3.2.1
MEID and EUIMID Migration 7. Scenarios
February, 2011 58
7.2.3 Lost/Stolen Phone 1
A subscriber whose phone has been lost or stolen typically contacts Customer 2
Service from an alternate number. Assuming the subscriber’s identity is verified 3
satisfactorily, the HLR subscription may be call-barred to prevent charges to the 4
subscriber’s account. 5
To prevent the stolen phone later being reprogrammed with a new number, the ESN 6
is typically logged as stolen in the provisioning system. For an MEID-equipped 7
device, the MEID should be logged instead (since using the pESN may incorrectly 8
affect other, legitimate phones with the same pESN). This implies that the MEID of 9
the device must be known to the network – possible mechanisms for this include: 10
• Recording the MEID at the point of sale 11
• Recording the MEID during an OTASP session (see Section 7.2.4) 12
• Capturing the MEID in billing records (see Section 7.2.1.5 ) 13
• Support of [X.S0008] and provisioning of the MEID in the HLR 14
• Support of X.S0008 and implementation of an Equipment Identity Register 15
(see Section 7.3.3) 16
MEID and EUIMID Migration 7. Scenarios
February, 2011 59
7.2.4 Over the Air Service Provisioning 1
Over-the-air Service Provisioning (OTASP) is a process by which a prospective 2
subscriber buys a new, unprogrammed device, and has the necessary information 3
(e.g. IMSI) downloaded to the device while making a call to the Customer Service 4
Center (CSC). 5
At the start of the programming session, the MEID may be the only unique identifier 6
available for the device. 7
Figure 7-8 shows a simplified typical message flow for an OTASP call. For more 8
detail see IS-725-A34. Note that the exact steps are to some extent implementation-9
dependent, and will depend on the way the operator has integrated the OTAF and 10
the OTASP sales channel into their business processes. 11
OTAFVLR +
MSC + BS
a
b
c
d
ORM [*228, pESN, SCM]
CSC/DBHLR/AC
Information Transfer
Extend Call [TRN]
Dialog
SMDPP [MIN, TRN, ACTCODE]
smdpp [pESN]
DBM [OTASP Message]
SMDPP [MIN, OTASP Message]
DBM [Response]smdpp [Response]
e
f
g
h
i
j
kDevice Info
Provisioning
l
m
Authentication
Subsequent OTASP Messages
n
12
Figure 7-8 - OTASP Data Flow 13
Steps are as follows: 14
a) The MS originates a call to the OTASP feature code (typically *228), 15
including its pESN and SCM as with other originations 16
b) Recognizing the OTASP code, the MSC assigns a Temporary Reference 17
Number (TRN) from a pool and sets this as the Calling Party Number 18
(CgPN). It extends the call to the CSC. 19
34 http://www.3gpp2.org/Public_html/specs/N.S0011-0_v1.0.pdf
MEID and EUIMID Migration 7. Scenarios
February, 2011 60
c) The CSC (shown here co-located with a provisioning database for simplicity) 1
answers the call. The prospective subscriber may enter into a dialog with a 2
Customer Service Representative, or an automated system. Subscribers 3
provide sufficient information (e.g. credit card number, or code allocated at 4
point of sale) to allow the operator to authorize them for service. 5
d) The CSC provides the TRN to the OTAF. 6
e) The OTAF sends a SMDPP to the MSC. The message includes the TRN (to 7
identify the call in progress), and a temporary Activation_MIN assigned by 8
the OTAF. 9
Note: At this point, the OTAF has no knowledge of the device MEID, or even 10
the pESN. If two handsets with the same pESN made simultaneous OTASP 11
calls, the OTAF would still be able to distinguish them based on the TRNs 12
assigned by the MSC, and assign unique Activation_MINs. 13
f) The MSC returns the pESN of the device. Optionally, if the network 14
requested the device MEID via an earlier STRQM, the MEID could be 15
included here as per X.S0008/X.S0033. Note however that the MEID can be 16
transferred to the OTAF without the need for X.S0008 or X.S0033 (see 17
below). Another SMDPP at this point (not shown) releases the TRN back 18
into the MSC’s pool. From this point the Activation_MIN is used to identify 19
the call. 20
g) Optionally, the OTAF may, in conjunction with the HLR/AC, instruct the MS 21
to generate a new A-key. The same A-key value is securely generated in 22
both the AC and MS so that it does not need to be transferred over the air. 23
h) The OTAF sends an SMDPP containing an OTASP Protocol Capability 24
Request Message. Based on the presence of a pESN (identifiable by its 25
manufacturer code), the OTAF includes in the message a request for the 26
MEID. 27
i) The MSC passes the message on to the MS encapsulated in a DBM. 28
j) The MS returns its MEID (together with other capabilities requested) 29
k) The MSC returns the MEID to the OTAF. The MEID is embedded in the 30
SMS_BearerData of the smdpp and does not explicitly require ANSI-41 / IS-31
725 modifications. 32
l) The OTAF may query a database for information about the device, for 33
example the Service Programming Code (SPC). The contents of the 34
database are typically provided by the handset manufacturer, and are 35
indexed by ESN/MEID (but should not be indexed by pESN). 36
m) Multiple SMDPP/DBM messages may be used to program the desired IMSI, 37
download Preferred Roaming List information, and other tasks. At the 38
conclusion of the OTASP session, the Activation_MIN is released for re-use. 39
n) The CSC (via the provisioning system) creates an entry in the HLR to match 40
the information in the device just programmed. The entry associates a 41
MIN/IMSI with the pESN and/or MEID. If the A-key has not been generated 42
during the OTASP session, a pre-programmed value may be retrieved from 43
MEID and EUIMID Migration 7. Scenarios
February, 2011 61
the device information database. Again, a unique device identifier is required 1
here to ensure the correct record is retrieved. 2
IS-725-A (3GPP2 N.S0011-0) defines the temporary call record that may exist 3
during an OTASP session at any/all of the MSC, VLR, HLR or AC, and names it the 4
OTASPCallEntry. The standard provides several methods to identify this record, 5
including the Activation MIN and the ESN (extended by X.S0033 to include MEID). 6
The identifier needs to be unique, so ESN is not recommended as a method. Use of 7
MEID requires X.S0008/X.S0033 support in the network. 8
MEID and EUIMID Migration 7. Scenarios
February, 2011 62
7.2.5 Roaming 1
The following scenarios describe cases when a device is not in its home network. 2
Due to varying levels of operator readiness, network support for MEID-equipped 3
mobiles may be different in the visited network to that experienced at home, and 4
expected by other elements in the home network. More information is available in 5
[CDG Ref Doc 137]. 6
7.2.5.1 Outbound Roaming 7
The following scenarios may occur when an operator’s MEID-equipped devices 8
roam into another network: 9
• No support for MEID devices. One network was identified which could not 10
serve MEID-equipped mobiles at all. It was upgraded in 2010 but it is possible 11
that other networks with similar problems may exist. See the [MEID Failure 12
Bulletin] for more detail. 13
• No C.S0072 support in visited network. If the visited network does not 14
support C.S0072, the roamer may be at risk of PLCM collisions. Collisions, 15
although very rare, could occur with other roamers, or with the visited 16
network’s own subscribers (e.g. if the serving operator had chosen to deploy 17
only unique pESNs for its own subscribers – see Section 6. ). Furthermore, the 18
MEID will not be available on any interface. 19
• No X.S0008 support in visited network. Even if C.S0072 is implemented, 20
the visited network may not support the transfer of the MEID in ANSI-41 21
messages. Alternatively, the home network may not support X.S0008, but the 22
serving network does, and MEID is received unexpectedly in inter-network 23
messages. This should have no consequences as long as unrecognized 24
parameters in ANSI-41 are properly ignored, and as long as MEID-capable 25
networks properly treat MEID as an optional parameter. 26
• MEID presence in CIBER. The CIBER record contains only one field for MEID 27
or pESN. Different roaming partners may populate this field differently. It is 28
therefore recommended that MEID be accepted but that the field is populated 29
with pESN as long as any roaming partners perform MIN/ESN validation. 30
• Uniqueness Checks. A network may refuse to allow two subscribers with the 31
same ESN (e.g. duplicate pESN) to be registered in a VLR, HLR or MSC, 32
resulting in one (or more) mobiles being blocked. 33
• MEID in 1X Packet Data UDR. The MEID may be included in the UDR instead 34
of the ESN, or vice versa, which may differ from the home operator’s own 35
network practice. 36
MEID and EUIMID Migration 7. Scenarios
February, 2011 63
7.2.5.2 Inbound Roaming 1
An operator serving roamers from other networks has no control over the 2
deployment timeframe and options implemented by the home operator – the 3
roamers could be using R-UIMs equipped with UIMIDs or EUIMIDs even if the 4
serving operator’s own subscribers only use non-R-UIM devices. The relevant 5
issues are addressed in the Outbound Roaming sections of the various operator 6
configurations. 7
Assuming the serving operator has already deployed MEID-equipped devices and 8
C.S0072 support, inbound roamers with pESN/pUIMID should not cause issues for 9
the serving operator. Communication and negotiation with roaming partners may be 10
useful to address the implementation differences described in Section 7.2.5.1 . 11
MEID and EUIMID Migration 7. Scenarios
February, 2011 64
7.3 R-UIM Operator – existing R-UIM in MEID device 1
The scenarios in this section apply to an operator whose subscribers use R-UIM 2
devices. Here, an existing R-UIM with a unique UIMID has been inserted into a new, 3
MEID-equipped device. 4
7.3.1 Basic Operation 5
7.3.1.1 Registration – No X.S0008 support 6
Without support for X.S0008, this scenario is indistinguishable at the HLR from the 7
existing case (i.e. unique UIMID in unique ESN device). The steps are shown in 8
Figure 7-9: 9
HLR
VLR + MSC + BS
a
b
cregnot
d
REGNOT [MSID, UIMID]
RGM [IMSI, UIMID, SCM]
ORDM
10
Figure 7-9 - UIMID Registration - no X.S0008 support 11
Steps are as follows: 12
a) MS sends a Registration Message, including its IMSI, UIMID, and Station 13
Class Mark set to indicate MEID support. The MS cannot include its MEID in 14
this message. 15
b) Although the MSC is aware that the MS has a MEID, it takes no specific 16
action. It proceeds with the RegistrationNotification INVOKE message, 17
including the UIMID and the Mobile Station Identity (MSID – either MIN or 18
IMSI) 19
c) The HLR validates the subscription on the basis of MSID-UIMID. This is the 20
same information the HLR receives if the subscriber had inserted their R-21
UIM in an ESN-equipped device. The HLR returns the subscriber profile to 22
the MSC 23
d) Optionally, the BS sends a Registration Accepted Order to the MS 24
MEID and EUIMID Migration 7. Scenarios
February, 2011 65
7.3.1.2 Registration – X.S0008 supported 1
When the serving network does support X.S0008, the MEID can be included in the 2
REGNOT. The ability to receive information relating both to the card and the device 3
is new: the device ESN is not available to the HLR today. The steps are shown in 4
Figure 7-10: 5
HLR
VLR + MSC + BS
a
b
c
regnot d
REGNOT [MSID, UIMID, MEID]
e
RGM [IMSI, UIMID, SCM
STRQM
STRPM [MEID]
fORDM
6
Figure 7-10 - UIMID Registration - X.S0008 supported 7
Steps are as follows: 8
a) MS sends a Registration Message, including its IMSI, UIMID and Station 9
Class Mark set to indicate MEID support. The MS cannot include its MEID in 10
this message. 11
b) Based on the SCM, the MSC recognizes that the mobile has a MEID, and 12
that the MSC does not know this value. It solicits the MEID via the Status 13
Request Message. 14
c) The MS returns its MEID in the Status Response Message. 15
d) The MSC sends a RegistrationNotification to the HLR, including the MSID, 16
UIMID, and the MEID. The UIMID is not hash-related to the MEID, so no 17
checking should be performed by the MSC to ensure this. 18
e) The HLR will presumably not track the MEID value, as the subscriber may 19
transfer the R-UIM to another ME at any time (although it may be recorded 20
to assist in a future lost/stolen report – see Section 7.2.3). In any case, the 21
HLR should not perform a hash-relation check between the two values. Even 22
if the HLR supports X.S0008, it will not include the MEIDValidated parameter 23
in the regnot. 24
f) Optionally, the BS sends a Registration Accepted Order to the MS. Since the 25
MEIDValidated parameter was not present in the regnot, the MEID retrieved 26
from the mobile in step c is not used by the MSC in validating subsequent 27
system accesses. 28
MEID and EUIMID Migration 7. Scenarios
February, 2011 66
7.3.1.3 Authentication 1
Authentication is unchanged from existing operation. The UIMID is used as an input 2
to various CAVE computations. The MEID may be included in various network 3
operations if X.S0008 is supported, but it is not used as an authentication input. 4
7.3.1.4 Call Origination/Termination 5
Although the traditional (in this case UIMID-based) PLCM would not be susceptible 6
to collisions, the network is expected to use a BS-assigned PLCM instead, due to 7
the SCM bit 4 being set to 1. 8
Note: The MSC could in theory examine the first 8 bits of the received ESN to 9
determine whether this was a unique (ESN/UIMID) or non-unique (pESN/pUIMID) 10
value. However the ESN is not a mandatory field in the MSID (as defined in 11
C.S0004), so C.S0072 implies that the decision is made solely on the basis of the 12
SCM. An equipment vendor may choose to require both SCM bit 4 = 1 and an 13
“ESN” beginning with 0x80 before assigning a non-UIMID-based PLCM. Similarly, 14
some MEID-equipped handsets have been observed to set the SCM bit 4 to 0 when 15
a unique UIMID-equipped R-UIM is inserted. This behavior is not explicitly covered 16
in existing standards – the “default” behavior expected is that the SCM bit 4 will be 17
set to 1 if the ME has an MEID, irrespective of the type of R-UIM inserted. This 18
custom handset/network behavior will deactivate EIR capabilities for the mobile but 19
will not result in any collision problems as the PLCM derived from the UIMID will be 20
unique. 21
7.3.1.5 Call Detail Record Production 22
Similar to the registration case in Section 7.3.1.2 , both the MEID and UIMID may be 23
available in the MSC CDR, a change from current operation where only the UIMID is 24
available and not the handset ESN. Billing system changes would presumably be 25
needed if the operator wished to take advantage of this new information (e.g. for 26
statistical information on handset usage). This does not apply to some billing record 27
formats such as the CIBER inter-carrier format, in which only one hardware identifier 28
can be included. In this case it may be desirable to include the pUIMID instead of 29
the MEID to allow validation of a matched pair of identifiers (the MEID will change if 30
the R-UIM is moved but the pUIMID comes from the card along with the IMSI). 31
7.3.1.6 Mobile Terminated SMS 32
MT-SMS and other paging-channel messages are not susceptible to the mis-33
addressing problem described in Section 7.2.1.6 for this scenario, as message 34
addressed by ‘ESN’ will actually contain the unique UIMID. 35
MEID and EUIMID Migration 7. Scenarios
February, 2011 67
7.3.1.7 Handoff 1
Handoff scenarios are as per Section 7.2.1.7 - the handset and network capabilities 2
determine the outcome, not the nature of the R-UIM (assuming the SCM bit 4 is set 3
to 1). 4
MEID and EUIMID Migration 7. Scenarios
February, 2011 68
7.3.2 Data Services 1
7.3.2.1 CDMA2000® Packet Data 2
Operator provisioning using an NAI constructed as UIMID@realm is unaffected by 3
insertion into an MEID-equipped ME. 4
Origination and PLCM assignment is as for voice. 5
In 1X mode the UIMID or MEID or both may be included in the airlink record and the 6
subsequent PDSN UDR. For EVDO, the MEID may be included but the UIMID will 7
not be included unless it is calculated from the MEID. 8
7.3.2.2 1xEV-DO Packet Data 9
Devices obtain the HardwareID from the device (MEID in this scenario), not the R-10
UIM.35 In this scenario the network must be upgraded to handle the new MEID 11
HardwareIDType, as described in Section 7.2.2.2 . 12
7.3.2.3 Other Applications 13
Applications would typically be expected to honor the R-UIM usage indicator bit, and 14
therefore use the UIMID as the “ESN” value. In this case no change from existing 15
behavior would be required for this scenario. 16
If the application used the device ESN, then use of the MEID instead as per Section 17
7.2.2.3 is recommended, although note that “subscription mobility” (moving the R-18
UIM to a different ME) may be compromised in this case regardless of MEID issues. 19
7.3.3 Lost/Stolen Phone 20
A subscriber whose phone has been lost or stolen typically contacts Customer 21
Service from an alternate number. Assuming the subscriber’s identity is verified 22
satisfactorily, the HLR subscription may be call-barred to prevent charges to the 23
subscriber’s account. 24
R-UIM devices present a particular challenge for the stolen phone case, as the thief 25
can replace the legitimate subscriber’s R-UIM with their own (e.g. if the device had 26
more functionality than the thief’s). Prior to the introduction of MEID, there was no 27
way for the network to track the device independently of the R-UIM (assuming the 28
usage indicator was set to replace the ESN with the EUIMID). 29
35 The 3GPP2 specification for EV-DO was originally not clear on this point. To rectify this C.S0024-B v3.0 states that, “The unique ID [HardwareID Value] is never assigned to the terminal using an identifier stored in a Removable User Identity Module.”
MEID and EUIMID Migration 7. Scenarios
February, 2011 69
X.S0008 and C.S0072 address this issue by allowing the device MEID to be 1
retrieved, and checked against a record held in a new network element, the 2
Equipment Identity Register (EIR). The new CheckMEID operation is defined for this 3
purpose, as shown in Figure 7-11. Note that in order for the MEID to be listed as 4
stolen in the EIR, the network must have previous knowledge of which MEID was in 5
use for the stolen IMSI (see Section 7.2.3): 6
EIR
VLR / MSC
a
b
c
d
STRQM
CHECKMEID [MEID]
STRPM [MEID]
checkmeid [MEIDSTATUS]
7
Figure 7-11 - CheckMEID Operation 8
Steps are as follows: 9
a-b) The VLR/MSC does not have the current MEID, and so retrieves it via Status 10
Request/Response Message. 11
c) The VLR sends the CheckMEID message to the EIR containing the MEID. 12
d) The EIR returns the MEID Status (e.g. Normal, Block, Track). 13
Ultimately, the success of EIR deployment to identify stolen phones depends on the 14
extent to which EIRs of different operators are interconnected – from GSM 15
experience, the “SIM/R-UIM lock” which restricts a device to a particular operator 16
can often be defeated by the thief. At the time of writing, no CDMA operators were 17
known to have deployed or be actively pursuing deployment of an EIR. 18
7.3.4 Over the Air Service Provisioning 19
OTASP provisioning for the “UIMID in MEID” scenario is the same as the existing 20
“UIMID in ESN” flow (assuming the MSC does not autonomously include the MEID 21
in the initial smdpp to the OTAF). The unique UIMID would not trigger the OTAF to 22
request the MEID from the handset. The unique UIMID can be used to index a 23
database to retrieve card-specific information (e.g. A-key, SPC). 24
MEID and EUIMID Migration 7. Scenarios
February, 2011 70
7.3.5 Roaming 1
7.3.5.1 Outbound Roaming 2
The bullet points below relate to the potential issues outlined in Section 7.2.5.1 3
above. 4
• No support for MEID devices. The “UIMID in MEID” configuration is 5
susceptible to this issue. 6
• No C.S0072 support in visited network. Since the UIMID is unique, there is 7
no risk of PLCM collision even if C.S0072 is not supported. 8
• No X.S0008 support in visited network. X.S0008 support is of limited use in 9
this scenario, as the subscriber may move their R-UIM between MEs without 10
advising the operator. X.S0008 support would be beneficial to address stolen 11
phone scenarios while roaming. 12
• MEID presence in CIBER. The two identifiers (UIMID and MEID) potentially 13
available for inclusion in the CIBER record are not hash-related. Use of the 14
UIMID is recommended in this case (see Section 6. ) 15
• No MEID in A12 authentication. Some operators may not send HardwareID 16
in A12 at all. Others may support ESN as HardwareID, but not MEID. 17
• MEID in UDR. In 1x mode the MEID may be included in the UDR instead of 18
the UIMID, or vice versa, which may differ from the home operator’s own 19
network practice. In EVDO mode the MEID may be included but the UIMID 20
cannot be included unless it is calculated from the MEID. 21
7.3.5.2 Inbound Roaming 22
Assuming an equivalent network capability to that in Section 7.2.5.2 , there should 23
be no difference to the network’s ability to serve roamers from other markets. 24
Operators who themselves use R-UIMs may be more cognizant of the potential 25
CIBER ramifications of including the MEID rather than the UIMID. 26
MEID and EUIMID Migration 7. Scenarios
February, 2011 71
7.4 R-UIM Operator – Short-Form EUIMID 1
The scenarios in this section apply to an operator whose subscribers use R-UIM 2
devices. The operator has chosen to deploy Short-Form EUIMID. Following the 3
argument in Section 5.2 , the assumption here is that Bit 2 of the Usage Indicator is 4
set to 1, i.e. the SF_EUIMID overrides the device MEID if present. The EUIMID-5
equipped R-UIMs may be inserted into devices that are equipped with either an 6
ESN, or an MEID. MEID equipped devices are assumed to be C.S0023-C/C.S0065 7
capable (see Section 5.2 ), unless otherwise noted. 8
Note that in the case where an ESN-equipped handset includes the necessary 9
software to support MEID, it might be thought that the handset would use the 10
SF_EUIMID and report MEID availability. However C.S0023-C specifically prohibits 11
an ESN-equipped ME from interpreting the SF_EUIMID Usage Indicator bit. Such a 12
device will operate as a pure ESN device and SF_EUIMID will not be used. 13
In general, insertion of a SF_EUIMID card into an ESN-equipped device is shown to 14
create potential for PLCM collisions, regardless of the network support for C.S0072. 15
7.4.1 Basic Operation 16
7.4.1.1 Registration – No X.S0008 support 17
This scenario is equivalent to that shown in Section 7.2.1.1 , except that pUIMID is 18
sent in the ESN parameter instead of pESN. HLR validation is performed on the 19
basis of the MIN/IMSI – pUIMID combination. 20
MEID and EUIMID Migration 7. Scenarios
February, 2011 72
7.4.1.2 Registration – X.S0008 supported 1
In this scenario, the SF_EUIMID can be included in the registration message, as 2
shown in Figure 7-12. This is only possible if the handset has an MEID (even though 3
the MEID itself is not sent to the network), since C.S0023 prohibits use of the 4
SF_EUIMID for MEID protocol fields if the mobile is not provisioned with an 5
MEID_ME. 6
HLR
VLR + MSC + BS
a
b
c
regnot [MEIDValidated]d
REGNOT [MSID, pUIMID, SF_EUIMID]
e
RGM [IMSI, pUIMID, SCM]
STRQM
STRPM [SF_EUIMID]
fORDM
7
Figure 7-12 - SF_EUIMID Registration with X.S0008 support 8
Steps are as follows (for MEID-equipped ME): 9
a) MS sends a Registration Message, including its IMSI, pUIMID and Station 10
Class Mark set to indicate MEID support. The MS cannot include its MEID or 11
the SF_EUIMID in this message. 12
b) Based on the SCM, the MSC recognizes that the mobile has a MEID, and 13
that the MSC does not know this value. It solicits the MEID (or MEID_ME if 14
both BS and ME support this) via the Status Request Message (new 15
Information Record in C.S0072 for MEID and new Information Record in 16
CDMA2000 Release E for MEID_ME). 17
c) The MS responds with a Status Response Message. Based on the value of 18
the Usage Indicator and the Information Record requested, the SF_EUIMID 19
may be returned instead of the MEID. 20
d) The MSC sends a RegistrationNotification to the HLR, including the MSID, 21
pUIMID (required for backwards compatibility) and the MEID or SF_EUIMID. 22
e) Text extracted from X.S0008: “Based on the existence of a provisioned 23
MEID value for this subscription, and the presence of the MEID parameter in 24
the REGNOT, the HLR includes an MEID comparison in the validation of the 25
subscription. The HLR then registers the indicated MS and returns a regnot 26
to the Serving VLR. The regnot includes the MEIDValidated parameter to 27
inform the Serving VLR/MSC that the MEID associated with the system 28
access has been validated.” In this case, the value included in the MEID 29
parameter may be the SF_EUIMID. In this case, even if the subscriber 30
transfers the R-UIM to another (MEID-equipped) device, this value will 31
remain constant, and can therefore be reasonably expected to be stored in 32
MEID and EUIMID Migration 7. Scenarios
February, 2011 73
the HLR. If the MEID_ME is transferred to the HLR this will change for a 1
given subscription if a R-UIM card is moved to a different ME. 2
f) Optionally, the BS sends a Registration Accepted Order to the MS 3
7.4.1.3 Authentication 4
Authentication is performed on the basis of the pUIMID. The SF_EUIMID, if 5
included, will not be used for authentication calculations. 6
A-key checksum calculations should use the pUIMID as an input for verification 7
although other implementations may be possible in devices predating S.S0053-0 8
v2.0 (May, 2009). 9
7.4.1.4 Call Origination/Termination 10
If the SF_EUIMID-equipped R-UIM is inserted in an MEID-equipped ME, PLCM 11
assignment will be as per Section 7.2.1.4 (i.e. network recognizes SCM and 12
provides BS-assigned PLCM). pUIMID and SF_EUIMID replace pESN and MEID 13
respectively from the earlier scenario. 14
If however the card is inserted in an ESN-equipped ME, this device will not 15
understand the new PLCM types or set the SCM bit flag. The pUIMID-based PLCM 16
will be used, and there is a risk of PLCM collision. 17
7.4.1.5 Call Detail Record Production 18
The two identifiers available (pUIMID and SF_EUIMID) for inclusion in the CDR are 19
hash-related, but since both are associated with the R-UIM, there is no opportunity 20
to capture information about specific hardware usage. 21
It is recommended that operators include the pUIMID since it is more compatible 22
with existing billing systems until it can be verified that all roaming partners will 23
accept a 56-bit identifier for billing. Note that an operator serving a roamer cannot 24
determine whether the 56-bit identifier is SF_EUMID (and therefore associated with 25
the subscription) or an MEID (and therefore not associated with the subscription, but 26
with the phone hardware). 27
Note that some billing record formats, notably CIBER, do not support the inclusion 28
of two hardware identifiers. 29
7.4.1.6 Mobile Terminated SMS 30
ESN-addressed messages over the paging channel would in this configuration use 31
the pUIMID derived from the SF_EUIMID. Regardless of whether the card was 32
inserted in an ESN- or MEID-equipped device, messages could be received by 33
other mobiles in addition to the intended recipient due to pUIMID duplication. 34
MEID and EUIMID Migration 7. Scenarios
February, 2011 74
7.4.1.7 Handoff 1
Handoff scenarios are as per Section 7.2.1.7 - the handset and network capabilities 2
determine the outcome, not the nature of the R-UIM. If the R-UIM is inserted in an 3
ESN-equipped device, BS-assigned PLCM is not possible, regardless of the status 4
of C.S0072 support in the network. 5
7.4.1.8 Handset Compatibility Issues 6
If the R-UIM is inserted in a device affected by the issue described in Section 5.4 , 7
the device may indicate “Service Required”, or otherwise refuse to operate. 8
If the R-UIM is inserted into an MEID-equipped device without C.S0023-C support, it 9
will return the handset shell (ME) MEID rather than the desired SF_EUIMID. 10
7.4.2 Data Services 11
7.4.2.1 CDMA2000® Packet Data 12
Data originations when an ESN-equipped device is used are subject to the same 13
potential for PLCM collision as for voice. 14
NAI assignment using UIMID@realm will no longer be unique – an upgrade to 15
another value that is unique, such as SF_EUIMID@realm is necessary. 16
For 1x packet data SF_EUIMID or pUIMID or both may be included in the airlink 17
record and subsequent PDSN UDR. 18
7.4.2.2 1xEV-DO Packet Data 19
HardwareID handling (if implemented) should be upgraded to accept the MEID 20
format as described in Section 7.2.2.2 . This parameter will be the MEID or ESN not 21
the UIMID or EUIMID. 22
If an MEID-equipped handset is used, then the handset MEID will be present in the 23
airlink record and subsequent PDSN UDR (unless the associated pESN is 24
calculated from the MEID by the PCF/PDSN). 25
7.4.2.3 Other Applications 26
Applications should use the EUIMID in preference to the pUIMID as a unique 27
identifier. The exact access method for the application to obtain the EUIMID is 28
beyond the scope of this document. 29
7.4.3 Lost/Stolen Phone 30
Overriding the ME’s MEID with the SF_EUIMID means that a stolen device cannot 31
be tracked/blocked independently of its R-UIM unless both the terminal and network 32
support protocols that allow explicit transmission of MEID_ME. Without these 33
MEID and EUIMID Migration 7. Scenarios
February, 2011 75
updates a thief would be able to replace the legitimate subscriber’s R-UIM with their 1
own without the network being aware of the change. 2
This limitation is essentially equivalent to the situation today with UIMID cards in 3
ESN devices. 4
MEID and EUIMID Migration 7. Scenarios
February, 2011 76
7.4.4 Over the Air Service Provisioning 1
OTASP (when the SF_EUIMID R-UIM is inserted into an MEID ME) is essentially 2
equivalent to the non-R-UIM MEID device scenario shown in Section 7.2.4, with 3
pUIMID and SF_EUIMID replacing pESN and MEID respectively. 4
When the card is inserted into an ESN device, it may not be possible to retrieve the 5
SF_EUIMID36. In fact, the OTASP session may fail, as the ESN-equipped handset 6
may not handle the additional fields in the Protocol Capability Request Message37. 7
A solution is to store the SF_EUIMID or a unique provisioning identifier in fields that 8
are accessible to ESN mobiles but not filled with data until the time of provisioning, 9
fields such as MDN and IMSI_T. 10
The new capabilities introduced in C.S0066 v2.0 and C.S0016-C v2.0 allow the 11
retrieval of both the SF_EUIMID and the handset MEID during the OTASP session. 12
36C.S0023-C Section 4.3.2.1 implies the ME is required to process the additional fields in the Protocol Capability Request Message (including the request for MEID) not the R-UIM.
37 C.S0066 (Section 4.3.1) states “The base station shall not send the Protocol Capability Request Message with additional fields to the mobile stations which don’t support the additional fields”, yet the presence of the pUIMID means that OTAF may assume the mobile does support these fields.
MEID and EUIMID Migration 7. Scenarios
February, 2011 77
7.4.5 Roaming 1
7.4.5.1 Outbound Roaming 2
The bullet points below relate to the potential issues outlined in Section 7.2.5.1 3
above. 4
• No support for MEID devices. When inserted in a MEID-equipped device, 5
the SF_EUIMID R-UIM is susceptible to this issue. 6
• No C.S0072 support in visited network. In this case the pUIMID will be used 7
to form the PLCM, with the associated risk of collision. 8
• No X.S0008 support in visited network. As per Section 7.2.5.1 , the 9
SF_EUIMID may not be available in ANSI-41 messaging. 10
• SF_EUIMID presence in CIBER. The two identifiers (pUIMID and 11
SF_EUIMID) potentially available for inclusion in the CIBER record are hash-12
related. There may be a preference for the unique identifier (i.e. SF_EUIMID), 13
although it is likely that roaming partner behavior will vary. 14
• No MEID in A12 authentication. Some operators may not send HardwareID 15
in A12 at all. Others may support ESN as HardwareID, but not MEID. 16
• Uniqueness Checks. A network may refuse to allow two subscribers with the 17
same ESN (e.g. duplicate pUIMID) to be registered in a VLR, HLR or MSC, 18
resulting in one (or more) mobiles being blocked. 19
• MEID in UDR. The SF_EUIMID may be included in a 1X UDR instead of the 20
pUIMID, or vice versa, which may differ from the home operator’s own network 21
practice. For EVDO modes, the serving network may not be able to include the 22
MEID or pUIMID in the UDR. 23
7.4.5.2 Inbound Roaming 24
Assuming an equivalent network capability to that in Section 7.2.5.2 , there should 25
be no difference to the network’s ability to serve roamers from other markets. 26
MEID and EUIMID Migration 7. Scenarios
February, 2011 78
7.5 R-UIM Operator – Long-Form EUIMID 1
The scenarios in this section apply to an operator whose subscribers use R-UIM 2
devices. The operator has chosen to deploy Long-Form EUIMID. The full 3
LF_EUIMID can be retrieved remotely from the MS via C.S0016-C v2.0 or C.S0066-4
0 v2.0 OTASP/OTAPA messaging, via CDMA2000 Release E signaling or through 5
the use of a special CCAT/UTK application (see Section 5.3 ). The EUIMID-6
equipped R-UIMs may be inserted into devices that are equipped with either an 7
ESN or an MEID 8
In general, insertion of a LF_EUIMID card into an ESN-equipped device is shown to 9
create potential for PLCM collisions, regardless of the network support for C.S0072. 10
7.5.1 Basic Operation 11
7.5.1.1 Registration – No X.S0008 support 12
This scenario is equivalent to that shown in Section 7.2.1.1 , except that pUIMID is 13
sent in the ESN parameter instead of pESN. HLR validation is performed on the 14
basis of the MIN/IMSI – pUIMID combination. 15
7.5.1.2 Registration – X.S0008 supported 16
When X.S0008 is supported, the registration scenario is equivalent to that shown in 17
Section 7.3.1.2 , except that pUIMID replaces the UIMID. No checking for a hash 18
relationship between the received 32- and 56-bit identifiers should be performed. 19
7.5.1.3 Authentication 20
Authentication is performed on the basis of the pUIMID. 21
A-key checksum calculations should use the pUIMID as an input for verification, 22
although other implementations may be possible in devices predating S.S0053-0 23
v2.0 (May, 2009). 24
7.5.1.4 Call Origination/Termination 25
If the LF_EUIMID-equipped R-UIM is inserted in an MEID-equipped ME, PLCM 26
assignment will be as per Section 7.2.1.4 (i.e. network recognizes SCM and 27
provides BS-assigned PLCM). pUIMID replaces pESN from the earlier scenario, but 28
the MEID_ME may still be retrieved via the Status Request/Response Messages. 29
If however the card is inserted in an ESN-equipped ME, this device will not 30
understand the new PLCM types or set the SCM bit flag. The pUIMID-based PLCM 31
will be used, and there is a risk of PLCM collision. 32
MEID and EUIMID Migration 7. Scenarios
February, 2011 79
7.5.1.5 Call Detail Record Production 1
Similar to the registration case in Section 7.5.1.2 , both the MEID and pUIMID may 2
be available in the MSC CDR, a change from current operation where only the 3
UIMID is available and not the handset ESN. Billing system changes would 4
presumably be needed if the operator wished to take advantage of this new 5
information (e.g. for statistical information on handset usage). The unique 6
LF_EUIMID is not available unless protocols such as the Release E Status Request 7
messages are implemented by the ME, RAN and Core Network. The inclusion of 8
two hardware identifiers may not be supported by all CDR formats, and is not 9
supported by the CIBER billing record format. In this case it may be desirable to 10
include the pUIMID instead of the MEID to allow validation of a matched pair of 11
identifiers (the MEID will change if the R-UIM is moved but the pUIMID comes from 12
the card along with the IMSI). 13
7.5.1.6 Mobile Terminated SMS 14
ESN-addressed messages over the paging channel would in this configuration use 15
the pUIMID derived from the LF_EUIMID. Regardless of whether the card was 16
inserted in an ESN- or MEID-equipped device, messages could be received by 17
mobiles in addition to the intended recipient due to pUIMID duplication. IMSI-18
addressed messages significantly reduce this problem. 19
7.5.1.7 Handoff 20
Handoff scenarios are as per Section 7.2.1.7 - the handset and network capabilities 21
determine the outcome, not the nature of the R-UIM. If the R-UIM is inserted in an 22
ESN-equipped device, BS-assigned PLCM is not possible, regardless of the status 23
of C.S0072 support in the network. 24
7.5.1.8 Handset Compatibility Issues 25
If the R-UIM is inserted in a device affected by the issue described in Section 5.4 , 26
the device may indicate “Service Required”, or otherwise refuse to operate. 27
7.5.2 Data Services 28
7.5.2.1 CDMA2000® Packet Data 29
Data originations when an ESN-equipped device is used are subject to the same 30
potential for PLCM collision as for voice. 31
NAI assignment using UIMID@realm will no longer be unique – an upgrade to a 32
unique value such as LF_EUIMID@realm is necessary. 33
Either MEID or pUIMID or both may be included in the airlink record and subsequent 34
PDSN UDR. 35
MEID and EUIMID Migration 7. Scenarios
February, 2011 80
7.5.2.2 1xEV-DO Packet Data 1
HardwareID handling (if implemented) should be upgraded to accept the MEID 2
format as described in Section 7.2.2.2 . Devices source the HardwareID from the 3
device (ESN or MEID), not the R-UIM. 4
If an MEID-equipped handset is used, then the handset MEID will be present in the 5
airlink record and subsequent PDSN UDR (unless the associated pESN is 6
calculated from the MEID by the PCF/PDSN). 7
7.5.2.3 Other Applications 8
Applications should use the EUIMID in preference to the pUIMID as a unique 9
identifier. The exact access method for the application to obtain the EUIMID is 10
beyond the scope of this document. 11
7.5.3 Lost/Stolen Phone 12
The stolen phone scenario for LF_EUIMID is equivalent to the “UIMID in MEID” 13
case shown in Section 7.3.3, provided the lost phone is MEID-equipped. If the MEID 14
has been previously recorded, it could be marked as stolen in the EIR, and blocked 15
from further usage within the scope of connectivity to that EIR. 16
If the device is ESN-equipped, its ESN is not transmitted to the network, and 17
therefore the device cannot be barred from operating using a different R-UIM. 18
7.5.4 Over the Air Service Provisioning 19
OTASP using LF_EUIMID can present some challenges, as the LF_EUIMID often 20
cannot be retrieved from the card (only the new capabilities recently added in 21
C.S0066-0 v2.0,C.S0016-C v2.0 and CDMA2000 Release E provide standard 22
methods for this). If there is any card-specific information stored in a database (e.g. 23
A-key and/or SPC) but no IMSI on the R-UIM it is difficult to retrieve data for 24
provisioning accurately. In addition, subsidy protection may present a challenge as it 25
may not be possible to determine that a particular card was sold by a particular 26
operator. 27
An alternative to retrieving pre-programmed card-specific information is to generate 28
it during the OTASP session (after which it can be associated with the programmed 29
IMSI). IS-725-A and IS-683 contain procedures for securely creating the A-key in 30
the AC and MS during the OTASP session. Similarly, the SPC could be initially set 31
to a default value, and then changed to a random value using existing OTASP 32
procedures. A PIN issued at the point of sale (as well as the default Preferred 33
Roaming List in the card) can help ensure that the prospective subscriber ultimately 34
obtains service from the correct operator. 35
MEID and EUIMID Migration 7. Scenarios
February, 2011 81
Another approach is to provision the LF_EUIMID in fields that are accessible to all 1
mobiles supporting R-UIM, and not required to be filled with valid information prior to 2
provisioning, such as the MDN and IMSI_T fields. 3
7.5.5 Roaming 4
The bullet points below relate to the potential issues outlined in Section 7.2.5.1 5
above. 6
• No support for MEID devices. When inserted in a MEID-equipped device, 7
the LF_EUIMID R-UIM is susceptible to this issue. 8
• No C.S0072 support in visited network. In this case the pUIMID will be used 9
to form the PLCM, with the associated risk of collision. 10
• No X.S0008 support in visited network. X.S0008 support is of limited use in 11
this scenario, as the subscriber may move their R-UIM between MEs without 12
advising the operator. X.S0008 support would be beneficial to address stolen 13
phone scenarios while roaming. 14
• MEID presence in CIBER. The two identifiers (pUIMID and MEID) potentially 15
available for inclusion in the CIBER record are not hash-related. Use of the 16
pUIMID is recommended in this case (see Section 6. ). 17
• Uniqueness Checks. A network may refuse to allow two subscribers with the 18
same ESN (e.g. duplicate pESN) to be registered in a VLR, HLR or MSC, 19
resulting in one (or more) mobiles being blocked. 20
7.5.5.1 Inbound Roaming 21
Assuming an equivalent network capability to that in Section 7.2.5.2 , there should 22
be no difference to the network’s ability to serve roamers from other markets. 23
8. Terminology 1
0x Hexadecimal (base 16) format indicator
3GPP2 Third Generation Partnership Project 2
AAA Authentication, Authorization and Accounting
AC Authentication Center
A-key Authentication Key
AMPS Advanced Mobile Phone Service
AN Access Network
ANSI-41 American National Standards Institute 41 – TIA mobility standard (also known as 3GPP2 X.S0004)
AT Access Terminal
AUTHR AuthenticationResponse
AUTHREQ AuthenticationRequest Invoke
authreq AuthenticationRequest Return Result
BCD Binary Coded Decimal
BS Base Station
CAVE Cellular Authentication and Voice Encryption algorithm
CCAT CDMA Card Application Toolkit
CDMA Code Division Multiple Access
CDR Call Detail Record
CIBER Cellular Intercarrier Billing Exchange for Roamer
CSC Customer Service Center
MEID and EUIMID Migration 8. Terminology
February, 2011 83
CSIM CDMA Subscriber Identity Module
DBM Data Burst Message
DRM Digital Rights Management
EF Elementary File
EIR Equipment Identity Register
ESN Electronic Serial Number. Used in a general sense or to refer to a protocol field. See also ESN_ME.
ESN_ME The permanent and unchangeable ESN stored in an ME. A protocol field that will never include UIMID.
EUIMID Expanded (Removable) User Identity Module Identifier
f-csch Forward common signaling channel
GDA Global Decimal Administrator (currently GSMA and other administrators authorized by them)
GHA Global Hexadecimal Administrator (currently TIA and other administrators authorized by them)
GPM General Page Message
GSM Global System for Mobile
HLR Home Location Register
HOCM Handoff Complete Message
ICCID Integrated Circuit Card Identifier
IMEI International Mobile Equipment Identifier
IMSI International Mobile Subscriber Identity
IOS Interoperability Specification
IRM International Roaming MIN
ITU-T International Telecommunication Union – Standardization Sector
LAC Link Access Control
MEID and EUIMID Migration 8. Terminology
February, 2011 84
LBS Location-Based Services
LF_EUIMID Long Form EUIMID
MAP Mobile Application Part
ME Mobile Equipment (phone ‘shell’ without R-UIM or CSIM)
MECAM MEID Enhanced Channel Assignment Message
MEID Mobile Equipment Identifier. Used in a general sense or to refer to a protocol field. Also see MEID_ME.
MEID_ME The permanent and unchangeable MEID stored in an ME. A protocol field that will never include SF_EUIMID.
MIN Mobile Identification Number
MS Mobile Station
MSC Mobile Switching Center
MT Mobile Terminated
MUHDM MEID Universal Handoff Direction Message
NAI Network Access Identifier
ORM Origination Message
OTAF Over-The-Air Function
OTASP Over The Air Service Provisioning
PCF Packet Control Function
PDSN Packet Data Serving Node
pESN Pseudo-ESN
PIN Personal Identification Number
PLCM Public Long Code Mask
PRL Preferred Roaming List
PRM Page Response Message
MEID and EUIMID Migration 8. Terminology
February, 2011 85
pUIMID Pseudo-EUIMID
r-csch Reverse common signaling channel
R-UIM Removable User Identity Module
SCM Station Class Mark
SF_EUIMID Short Form EUIMD
SHA Secure Hash Algorithm
SMDPP ShortMessageDeliveryPointToPoint Invoke
smdpp ShortMessageDeliveryPointToPoint Return Result
SPC Service Programming Code
SSD Shared Secret Data
STRPM Status Response Message
STRQM Status Request Message
TDMA Time Division Multiple Access
TIA Telecommunications Industry Association
TMSI Temporary Mobile Station Identity
TRN Temporary Reference Number
UDR Usage Data Record
UHDM Universal Handoff Direction Message
UICC Universal Integrated Circuit Card
UIM User Identity Module
UIMID (Removable) User Identity Module Identifier
UMTS Universal Mobile Telephone Service
USIM Universal Subscriber Identity Module
UTK UIM Tool Kit
1
9. References 1
[A.S001x] 3GPP2 A.S001x-D (TIA-2001.x). Interoperability Specification (IOS) for CDMA2000® Access Network Interfaces. v2.0. August, 2009. http://www.3gpp2.org/Public_html/specs/tsga.cfm.
• A.S0011. Overview
• A.S0012. Transport
• A.S0013. Features
• A.S0014. A1, A1p, A2, and A5 Interfaces
• A.S0015. A3 and A7 Interfaces
• A.S0016. A8 and A9 Interfaces
• A.S0017. A10 and A11 Interfaces
[A.S0008] 3GPP2 A.S0008-C (TIA-878). Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Access Network. v3.0. June, 2010. http://www.3gpp2.org/Public_html/specs/A.S0008-C_v3.0_100621.pdf
[C.S0005] 3GPP2 C.S0005-E (IS-2000). Upper Layer (Layer 3) Signaling Standard for CDMA2000 Spread Spectrum Systems. v2.0. June, 2010. http://www.3gpp2.org/Public_html/specs/C.S0005-
E_v2.0_cdma2000_1x_L3_Signaling.pdf
[C.S0016] 3GPP2 C.S0016-D (TIA-683). Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Standards. v1.0. January, 2010. http://www.3gpp2.org/Public_html/specs/C.S0016-
D%20v1.0_OTASP.pdf
[C.S0023] 3GPP2 C.S0023-D (TIA-820). Removable User Identity Module for Spread Spectrum Systems. v1.0. July, 2009. http://www.3gpp2.org/Public_html/specs/C.S0023-D_v1.0_R-UIM-
090720.pdf
[C.S0024] 3GPP2 C.S0024-B (TIA-856-A). CDMA2000 High Rate Packet Data Air Interface Specification. v3.0. September, 2009. http://www.3gpp2.org/Public_html/specs/C.S0024-B_v3.0_HRPD.pdf
[C.S0035] 3GPP2 C.S0035-A. CDMA Card Application Toolkit (CCAT). v2.0.
MEID and EUIMID Migration 9. References
February, 2011 87
August 2007. http://www.3gpp2.org/Public_html/specs/C.S0035-A_v2.0_070731.pdf
[C.S0065] 3GPP2 C.S0065-B (TIA-1080). CDMA2000 Application on UICC for Spread Spectrum Systems. v1.0. January, 2010. http://www.3gpp2.org/Public_html/specs/C.S0065-
B_v1.0_cdma2000_Application_for_UICC.pdf
[C.S0066] 3GPP2 C.S0066-0 (TIA-158). Over-the-Air Service Provisioning for MEID-Equipped Mobile Stations in Spread Spectrum Systems. v2.0. July, 2008. http://www.3gpp2.org/Public_html/specs/C.S0066-
0_v2.0_080729.pdf
[C.S0072] 3GPP2 C.S0072-0 (TIA-1082). Mobile Station Equipment Identifier (MEID) Support for CDMA2000 Spread Spectrum Systems. v1.0. July 22, 2005.
http://www.3gpp2.org/Public_html/specs/C.S0072-0_v1.0_050727.pdf
[C.S0073] 3GPP2 C.S0073-B. Signaling Test Specification for Mobile Station Equipment Identifier (MEID) Support for CDMA2000 Spread Spectrum Systems. v1.0. August, 2009. http://www.3gpp2.org/Public_html/specs/C.S0073-
B_V1.0_MEID_Test_Spec.pdf
[CDG Ref Doc 137]
CDG Reference Document #137, Mobile Equipment Identifier Roaming Recommendations. v1.0, December 2006.http://www.cdg.org/members_only/refdocs/137.zip
[Collisions WP]
Pellegrino, Gary; Quick, Frank. White Paper on Pseudo-ESN Collisions. TIA TR-45 ESN/UIM Ad Hoc Group. May 26, 2005. http://www.tiaonline.org/standards/resources/esn/documents/Collisions_pE
SN_wp.pdf
[GSMA TS.06]
GSMA TS.06 (formerly DG.06). IMEI Allocation and Approval Guidelines. December 2010.
http://gsmworld.com/documents/TS06_5v1_Approved.pdf
[E.118] ITU-T Recommendation E.118. The international telecommunication charge card. May 2006. http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.118-200605-
I!!PDF-E&type=items
[MEID Failure Bulletin]
CDG Technical Bulletin 070301IRT. MEID IOS Issue. v1.0, March 2007. http://www.cdg.org/members_only/teams/IntRoaming/docs/CDG%20Tech
%20Bulletin%20070301IRT%20MEID%20IOS%20Issue%20v1_0.doc
MEID and EUIMID Migration 9. References
February, 2011 88
[SC.R4001] 3GPP2 SC.R4001-0. Global Wireless Equipment Numbering Administration Procedures. v2.0. December, 2010. http://www.3gpp2.org/public_html/Specs/SC.R4001-0_v2.0_Global
Wireless Equipment Numbering Admin Procedures.pdf
[SC.R4002] 3GPP2 SC.R4002-0. Mobile Equipment Identifier (MEID) GHA (Global Hexadecimal Administrator), Assignment Guidelines and Procedures. v6.0. July, 2010. http://www.3gpp2.org/public_html/Specs/SC.R4002-0_v6.0_GHA_Assignment_Procedures_for_MEID_and_SF_EUIMID-100723.pdf
[SC.R4003] 3GPP2 SC.R4003. Expanded R-UIM Numbering Administration Procedures. v1.0. May, 2007. http://www.3gpp2.org/Public_html/Specs/SC.R4003-0_v1.0_EUIMID_Procedures_070521.pdf
[S.R0048] 3GPP2 S.R0048-A (TIA-928). 3G Mobile Equipment Identifier (MEID), Stage 1. v4.0. November, 2005. http://www.3gpp2.org/Public_html/specs/S.R0048-A_v4.0_050630.pdf
[S.R0111] 3GPP2 S.R0111-0. Expanded R-UIM Identifier, Stage 1 Requirements. v2.0. May 2007. http://www.3gpp2.org/public_html/specs/S.R0111-0_v2.0_070521.pdf
[X.S0008] 3GPP2 X.S0008-0 (TIA-928). MAP Support for the Mobile Equipment Identity (MEID). v3.0. January, 2009. http://www.3gpp2.org/Public_html/specs/X.S0008-0_v3.0_090130.pdf
[X.S0011] 3GPP2 X.S0011-xxx-E (TIA-835). CDMA2000 Wireless IP Network Standard, v1.0, November, 2009. http://www.3gpp2.org/Public_html/specs/tsgx.cfm
[X.S0033] 3GPP2 X.S0033-0 (TIA-1074). OTA Support for MEID. v2.0. March, 2006. http://www.3gpp2.org/Public_html/specs/X.S0033-0_v2.0_060301.pdf
1