Upload
claud-tate
View
227
Download
3
Tags:
Embed Size (px)
Citation preview
Migrations:
ESN to MEID&
UIMID to EUIMIDApril 2007
April 2007
2
Outline• Executive Summary• Background & Terminology• Migrations
– ESN to MEID
– UIMID to EUIMID
• Standards Involved in the Migrations• Actions for Carriers
– Non-RUIM Carrier
– RUIM Carrier
• Administration of MEID, ICCID and EUIMID• Summary• Reference Information and documents• Glossary• Appendix – Call Flow Diagrams
April 2007
3
Executive Summary • The latest (3/07) TIA projection shows that ESN address space for handsets will exhaust at late
07/early 08. The UIMID space for R-UIMs is also expected to be exhausted in the near future.
• In response to these events, the cdma2000 industry is migrating handsets from ESN to MEID-based addressing, and R-UIMs from UIMID to EUIMID-based addressing.
– Non-unique values will be used in ESN/UIMID fields, previously depended upon to be unique
• If there are no steps taken in the network and back-end systems to accommodate this change, possible impacts include:
– Crosstalk, interference and dropped calls due to PLCM collision– Mis-addressed air interface messaging (e.g. receive other users’ SMS)– Inability to provision and/or bill some subscribers (fail uniqueness check in back-end)– Spurious Fraud Detection alerts may occur at the backend systems due to the non-uniqueness of pESN/pUIMID
• The ESN to MEID migration has already started– Several major C2K operators have already upgraded their network and deployed MEID-based handsets
• All C2K carriers are recommended to upgrade their network to support TIA-1082 and deploy TIA-1082-compliant handsets, to minimize PLCM collisions
• The UIMID to EUIMID migration should be addressed by several, parallel, efforts– Maximally utilize the unassigned UIMID blocks– Refarm the obsolete ESN (legacy AMPS phone) through TIA and/or recycle used UIMID, if possible. – Carefully study the two options available for EUIMID addressing (Short and Long Form EUIMID)
April 2007
4
Background & Terminology
April 2007
5
High Level Overview of Relationship between Addresses
ESN MEID
pESN
UIMID
Short Form EUIMID
pUIMID
Long Form EUIMID(ICCID)
Handset
R-UIM
32 bit space 56 bit space 72 bit space
or
or
Migration Relationship
Derivation Relationship
SHA-1 Hashing
SHA-1 Hashing
SHA-1 Hashing
April 2007
6
Electronic Serial Number (ESN)
• An Electronic Serial Number (ESN) is the unique identification number for the Mobile Equipment.
• ESN is a 32 bit number that is presently used on CDMA networks.• ESN is used as an input to CAVE authentication.• ESN can be used to derive the Public Long Code Mask (PLCM)• Total no. of distinct ESNs ~ 4.3 billion, ESNs come in one of two
different formats: – 8 bits Manufacturer Code + 24 bits serial number ( i.e., ~16.7 million
distinct ESNs per manufacturer code)
– 14 bits Manufacturer Code + 18 bits serial number ( i.e., ~262K distinct ESNs per manufacturer code)
April 2007
7
Mobile Equipment Identifiers (MEID)
• MEID (14 Hexadecimal Digits, 56 bits).
• MEID Format• 8 Hex Digit Manufacturer Code (MC)
• RR - Regional Code. A0-FF are assigned by the Global Hexadecimal MEID Administrator (GHA). Codes 00-99 are reserved for use as IMEIs. RR=99 is reserved for MEIDs that can also be used as IMEIs. The first digit must be “A” to “F” to distinguish MEID from IMEI.
• XXXXXX - 6 hexadecimal digit code assigned by the administrator to a manufacturer for a line of phones.
• Serial Number – Assigned by manufacturer to identify an individual device.
• CD (Checksum Digit) – Not transmitted.
• Total no. of distinct MEIDs ~ 2.7 x 1016
April 2007
8
Pseudo-ESN (pESN)• With the introduction of MEID, device no longer has an ESN
• As ESN is a required field in many address formats, the solution is to derive a “pseudo-ESN” from MEID: “compress” longer identifier into 32-bit ESN length
• Pseudo ESN is a 32 bit number that has the reserved ESN manufacturer code (i.e. 0x80), followed by a 24 bit hash of the 56 bit MEID using the SHA-1 algorithm
• MEID to Pseudo ESN mapping is fixed • Pseudo ESN not unique (MEID to pESN mapping is many-to-one)• Pseudo ESN do not match any UIMID or ESN (also referred as true ESN),
because they have a unique manufacturer code of 0x80
For MEID-equipped mobile, pseudo ESN is used in place where ESN is used:
• RN_HASH_KEY, to randomize the start of transmission in CDMA systems
• CAVE Authentication input• ESN based PLCM if (P_REV<9)• Pseudo-random number generator for CDMA timer-based registration• CDMA status response / extended status response message
April 2007
9
User Identity Module ID (UIMID)
• UIMID is a 32 bit number that is unique to a R-UIM card for use on CDMA networks
• UIMID shares same 32 bit address space with ESN
• Each UIMID should be unique, it does not match to any other assigned UIMID or ESN
• UIMID exhaust issue is similar to ESN, but not exactly the same: Reusing of old technologies (AMPS, TDMA, etc.) ESNs as UIMIDs may delay UIMID exhaust.
• UIMID replaces ESN in air interface and TIA-41 messages, when R-UIM card is programmed to use UIMID instead of ESN (i.e. R-UIM usage indicator = “UIMID”)
April 2007
10
Integrated Circuit Card Identifier (ICCID)• Every RUIM card (including existing card) has an unique ICCID• It follows ITU Recommendation E.118, maximum 19 Hexadecimal digits
(18 + 1 CD)• It is stored in EF(ICCID) at MF level of the card with BCD coding• It is an option for the expansion of UIMID, called as Long Form EUIMID
April 2007
11
Expanded UIMID (EUIMID)
• There are two options available for EUIMID
– Short Form EUIMID (56 bits, similar to MEID)• Referred to here as MEID-like approach• Sharing the same 56-bit space of MEID• A new ID for the card
– Long Form EUIMID (76 bits, using ICCID)• Referred to here as ICCID approach• Maximal 19 Hexadecimal digits (18 BCD + 1 CD)
• Properties and choice on SF or LF EUIMID will be explained in the section “Migration : UIMID to EUIMID”.
April 2007
12
Pseudo UIMID (pUIMID)• With the introduction of EUIMID, card no longer has a true UIMID
• In order to fill the required ESN address field, the solution is to derive a “pseudo UIMID” from EUIMID: “compress” longer identifier into 32-bit UIMID length.
• Pseudo UIMID is a 32 bit number that has the reserved ESN manufacturer code (i.e. 0x80, same as pESN), followed by a 24 bit hash of the Expanded UIMID using the SHA-1 algorithm
• Pseudo UIMID does not match to any true UIMID or ESN
• pUIMID may be duplicate of pUIMID or pESN derived from another EUIMID or MEID - like pESN, pUIMID is NOT unique.
• pUIMID will be used wherever UIMID is expected to be used
• pUIMID can be derived from one of the two approaches:• 56-bit MEID-like EUIMID (SF EUIMID) via SHA-1 algorithm• 76-bit ICCID (LF EUIMID) via SHA-1 algorithm
April 2007
13
Migration : ESN to MEID
April 2007
14
MEID to Pseudo-ESN• 24 bit hash of 32 bit pESN is derived from 56 bit MEID using the
Secure Hash Algorithm (SHA-1)• Upper 8 bits are set to a fixed value of 0x80. This guarantees a unique
space in the ESN address space for pESNs.
• pESN replaces the ESN wherever the latter may be used.
56 Bit MEID
SHA-1
0x80 24 Bit Hash
32 Bit pESN
April 2007
15
Pseudo-ESN Collisions
• Since multiple MEIDs map to the same pESN, there is a non-zero probability that handsets using pESN will collide– Collision probability is low but mobiles that do collide will always collide
and if in the same cell cannot make calls at the same time
• pESNs will not collide with regular ESNs– Collisions only occur with other handsets using pESN or pUIMID
• For more details on the probability of pESN collisions and under what conditions do they happen see white paper on pESN collisions at– http://www.tiaonline.org/standards/resources/esn/index.cfm#meid
April 2007
16
C.S0072 / TIA-1082 Standard Overview
• TIA-1082 / C.S0072 covers the following:– Mechanism for a pre-REV D MS to indicate its MEID capability– Mechanism for BS to query “MEID” information from the MS– New Channel Assignment and Handoff Messages to assign
different PLCM types (since pESNs can collide)
• TIA-1082 / C.S0072 does NOT support:– MEID based addressing on reverse access channels or forward
paging channels.– Mechanism for BS to indicate its MEID capability
• Not needed
• TIA-1082 / C.S0072 does NOT address changes to IOS and ANSI-41 interfaces. There are corresponding standards for IOS and ANSI-41. See “Standards Involved in the Migrations” in the later section.
April 2007
17
• MS can indicate its MEID capability by setting bit 4 of the SCM (Station Class Mark). – SCM is carried by Page Response, Registration, Origination messages and
“Terminal Info” Information Record.
• Once BS determines MS is equipped with MEID, BS can send Rev D-like channel assignment message with PLCM fields included (“MEID ECAM” : New message type)
– PLCM types (not based on ESN) can be used to avoid PLCM collision
• Once MS is on the traffic channel, Rev D-like handoff message (‘MEID UHDM”: New message type) can be sent to this MS containing PLCM fields
• “MEID ECAM” and “MEID UHDM” have the following properties:– PLCM related fields In the same position as defined in Rev C– All other fields are according to MS/BS protocol revision (P_REV_IN_USE)
• LAC fields and all other L3 messages formatted as per P_REV_IN_USE.
C.S0072 / TIA-1082 Standard Details (1/2)
April 2007
18
MEID Solution Details (2/2)
• How does a Pre-Rev D BS indicate it supports this specification?– It is not required for BS to explicitly indicate supporting the MEID
specification; MS does not require this as well.
– BS will act according to specification when it detects an MEID capable MS (Based on SCM bit 4 setting = 1)
• Are ESN and BS Assigned Public Long Code Mask (PLCM) the only options available for PLCM assignment?– No, alternatives are:
• MEID based PLCM: Requires more messaging, and reduces but does not eliminate PLCM collisions
• IMSI based PLCM: Collisions are only eliminated when in home network, does not work for international roamers
– As a result, BS PLCM Assignment is the preferred approach.
April 2007
19
MS / BS Protocol Revisions and BS Assigned PLCM
MS Protocol Revision (MOB_P_REV)
BS Protocol Revision (P_REV)
BS Assigned PLCM allowed?
Comments
=< 7 =< 7 No
(Only ESN-based PLCM)
Standard scenario prior to ESN exhaustion
=< 7 =< 7
+ TIA-1082
No
(Only ESN-based PLCM)
Only BS upgraded to support 1082 (i.e., MS is ESN provisioned)
=< 7
+ TIA-1082
=< 7 No
(Only pESN-based PLCM)
Only MS upgraded to support 1082 (i.e., MS is MEID provisioned)
=< 7
+ TIA-1082
=< 7
+ TIA-1082
YES Both MS and BS upgraded to support 1082.
April 2007
20
Handoff Scenarios for MEID Capable MS
Target BS does not support TIA-1082
Target BS supports TIA-1082
Source BS does not support TIA-1082
Continue pESN-based PLCM in UHDM
Continue pESN-based PLCM in UHDM
Subsequent UHDM could change to a different PLCM
Source BS supports TIA-1082
Change to pESN-based PLCM in UHDM
Could continue with newer PLCM type used, e.g. BS assigned PLCM
April 2007
21
OTASP Support for MEID
• OTASP support for MEID is needed to identify mobiles uniquely during service provisioning
• Published as a 3GPP2 document C.S0066-02 : “Over the Air Service Provisioning for MEID Equipped Mobile Stations In Spread Spectrum Systems”
• “Protocol Capability Request Message” and “Extended Protocol Capability Response Message” have been enhanced to add a new “CAP_RECORD_TYPE” of value “00000010” to support MEID query.
April 2007
22
MEID Impact on EV-DO (1/3)
• Combinations of DO network revision, MS/AT provisioning, and expected hardware ID response are shown below
• As can be seen, hardware ID response is independent of DO Revision of AN, and only dependent on whether MEID is provisioned in MS/AT or not.
DO Revision of the Access Network
MEID provision in MS/AT?
Hardware ID Response
IS-856-0 Yes HW ID Type = ‘0x00ffff’ (MEID)
IS-856-0 No HW ID Type = ‘0x010000’ (ESN)
IS-856-A Yes HW ID Type = ‘0x00ffff’ (MEID)
IS-856-A No HW ID Type = ‘0x010000’ (ESN)
April 2007
23
MEID Impact on EV-DO (2/3)
• Default Address Management Protocol was modified in IS-856-A to include MEID as shown below.
• Notice that this applies to both IS-856-0 (DO Release 0) as well as IS-856-A (DO Rev A) since the Default Address Management Protocol was changed.
HardwareIDType field Meaning
0x010000 Electronic Serial Number (ESN)
0x00ffff Mobile Equipment Identifier (MEID)
0x00NNNN, where NNNN is in the range 0x0000 to 0xfffe, inclusive.
See C.R1001-D, Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards
0xFFFFFF NULL
All other values invalid
April 2007
24
MEID Impact on EV-DO (3/3)• Hardware-ID is optionally included in A12 authentication.
(However, as of today, April 07, none of the carriers has adopted this approach.)
• If Hardware-ID is used for this purpose, upgrade to AN to handle MEID is needed when MEID-equipped devices are deployed:
– MEID-equipped AT will return MEID as Hardware-ID – AN can’t choose to receive pESN instead
– Hardware-ID from AT is not simply encapsulated on A12 interface (AN to AN-AAA) – instead AT Type of Identity from A.S0016-C (IOS) is used to indicate MEID
(A.S0016-C)(A.S0008-B – for A12)
001 ≠ 0x00ffff
April 2007
25
Migration : UIMID to EUIMID
April 2007
26
• Two options are available for EUIMID– Short Form EUIMID (56 bits, same as MEID)
• Referred to here as MEID-like approach• Shares the same 56-bit space of MEID
– Long Form EUIMID (76 bits, using ICCID)• Referred to here as ICCID approach• Maximal 19 Hexadecimal digits (18 BCD + 1 CD)
EUIMID Options: Short and Long Form
April 2007
27
ICCID Approach – China Unicom ProposalEvery RUIM card has an unique ICCID. It is stored in EF(ICCID) at MF level of the card with BCD coding. When the card uses Long Form EUIMID (i.e. ICCID),
• Both the two service indicators b7 & b8 from Service n8 of EF(CST) will be set to ‘0’• Pseudo UIMID (pUIMID) derived from the 76-bit ICCID shall be stored into EF(RUIMID) for
backward compatibility operations• In this case,
• b2 of EF(USGIND) has no meaning and is by default set to “0”.• b1 of EF(USGIND) is set to indicate whether the 32 bits of the RUIMID or ESN_ME is used as the “ESN” value for CAVE authentication and MS identification.
EF(USGIND) indicates whether the 32 bits of the RUIMID or ESN_ME is used as the “ESN” value for CAVE authentication and MS identification.
April 2007
28
Features of ICCID Approach
• Decouple the extension of card’s ID with that of Mobile Equipment (ME)’s ID– RUIM Card: from UIMID to ICCID– ME: from ESN to MEID
• UIMID was created by China Unicom when introducing RUIM card to CDMA, to – emulate ESN functions when needed
• These functions will still be performed with pUIMID after migration. And it’s sufficient.
– not be really used as the ID of the card
• ICCID already exists– Each ICC card has its own ICCID– 19 Hexadecimal digits (18 BCD + 1 CD)– Allocation and administration mechanisms already well established– Qualified to be used as the ID of RUIM card and the source for pUIMID
derivation
April 2007
29
Mechanism for Clone Detection and Stolen Phone Blocking – for ICCID Approach
• Clone Detection– HLR/AC needs to store MIN/IMSI, pUIMID (or store ICCID and derive pUIMID
accordingly), A key.– Retrieve and validate ICCID of RUIM card over the air is not possible based
on the current standards. – Therefore, it is recommended to turn on CAVE Authentication, or concede to
pUIMID/IMSI binding validation. Cloning is defeated by use of existing CAVE authentication. CAVE is not weakened by the presence of a duplicate pUIMID, as this information is assumed to be available to the attempted cloner anyway.
• Stolen Phone Blocking– For current RUIM device using ESN, no matter using pUIMID or existing
UIMID RUIMs, when b1 of EF(USGIND)=1, ESN cannot be detected over the air currently.
– For RUIM device using MEID, use of ICCID as EUIMID means handset MEID can still be retrieved over the air for theft prevention via SRM. For BS supports TIA-1082 / C.S0072, MEID can be retrieved via SRM - Status Request Message and Status Response Message
– X.S0008 describes Equipment Identification Register (EIR) functions to manage phone theft.
April 2007
30
MEID-like Approach
When the card uses Short Form EUIMID (i.e. 56-bit MEID alike SF EUIMID),
• Both indicators of Service n8 of EF(CST) will be set to ‘1’• A 56-bit ID (called SF EUIMID) is stored in a new EF(SF EUIMID)• Pseudo UIMID (pUIMID) derived from the SF EUIMID shall be stored into
EF(RUIMID) for backward compatibility operations• b2 of EF(USGIND) is used to indicate whether MEID shall be replaced by SF
EUIMID over the air
EF(USGIND) indicates whether the 32 bits of the RUIM_ID or ESN_ME is used as the “ESN” value for CAVE authentication and MS identification.EF(USGIND) also indicates whether the 56-bit of the SF EUIMID or MEID shall be used as the “MEID” field over the air when Service n8 is allocated.
April 2007
31
Features of MEID-like Approach
• Still bind the extension of card’s ID with that of ME’s ID– Complicate the GHA administration and allocation– Additional usage of number space– Need new EF in RUIM card
• Comparing with ICCID approach,– No additional benefit over ICCID if b2 of EF(USGIND) is ‘0’– The values are doubtable even if b2 of EF(USGIND) is set to ‘1’
• It will disable EIR function• Network should have no need to know the card’s ID, given it
can get the IMSI (the ID of the user) and get pUIMID for ESN-emulation processing
– unless the operator wants to provide OTASP to a blank card
April 2007
32
Mechanism for Clone Detection and Stolen Phone Blocking – for MEID-like Approach
• Clone Detection– HLR/AC needs to store A key, MIN/IMSI, pUIMID (or store SF EUIMID and
derive pUIMID accordingly).– It is recommended to turn on CAVE Authentication, or concede to pUIMID/IMSI
binding validation. Cloning is defeated by use of existing CAVE authentication. CAVE is not weakened by the presence of a duplicate pUIMID, as this information is assumed to be available to the attempted cloner anyway.
• Stolen Phone Blocking– Handset MEID can be retrieved over the air for theft prevention via SRM. For BS
supports TIA-1082 / C.S0072, MEID can be retrieved via SRM - Status Request Message and Status Response Message. This requires b2 of EF(USGIND) to be “0”. (For b2=1, it will get SF EUIMID instead of MEID, so EIR function is not useful in this case.)
– X.S0008 describes Equipment Identification Register (EIR) functions to manage phone theft.
April 2007
33
RUIM card to support these two approaches
These two approaches are supported by the new RUIM card standards, C.S0023-C and C.S0065-0:
• C.S0023-C: the latest RUIM card spec for CDMA2000• Set b7 and b8 in Service n8 of EFCST (CDMA Service Table)• Set b1 and b2 in EF(USGIND)
• C.S0065-0: the first UICC based RUIM card spec for CDMA2000
• Set bits in Service n34 of EFCST (CSIM Service Table)• Set b1 and b2 in EF(USGIND)
• ICCID approach actually can be used with pre-Rev C card.• By manual provisioning the pUIMID (derived from
ICCID by SHA-1) into EF(RUIMID) of the RUIM card
April 2007
34
EUIMID Impact on EV-DO
• EUIMID should have no impact on EV-DO– DO MD5 authentication uses IMSI (through NAI) instead of ESN or
UIMID
– DO CAVE-based authentication (for pre-C.S0023-B cards) uses UIMID/pUIMID
– DO uses ATI based PLCM, which is assigned by AN• UIMID to EUIMID migration will not cause PLCM collision issue in
DO
– SF EUIMID with b2 of EF(USGIND)=1 may have some impact on EV-DO if the AT shell has MEID as Hardware-ID
• AT’s Hardware-ID will be replaced by SF EUIMID over the air.• Carriers are recommended NOT to use Hardware-ID for billing and
authentication purposes. IMSI could be used instead. Again, as of today, April 07, none of the carriers has adopted this approach.)
April 2007
35
Recommendation – ICCID Approach or MEID-like Approach?
• Though the new RUIM card standards (C.S0023-C or C.S0065-0) support both approaches, i.e. either ICCID or the MEID-like,
• The ICCID– Is already present on all RUIMs today– Requires no new files on the RUIM– Does not prevent tracking of stolen mobiles via MEID– Is the EUIMID option already chosen by China
Unicom, a large RUIM carrier.
April 2007
36
Scenarios of Different Combinations of R-UIM, MS and BS (1 of 3: Legacy R-UIM)
Notes:• RUIMID Usage Indicator = bit 1 (b1) of Efusgind EF in R-UIM. "0" indicates use ESN_ME, "1" indicates use UIM_ID• In practice, R-UIM Usage Indicator is typically expected to be set to “1”.
April 2007
37
Scenarios of Different Combinations of R-UIM, MS and BS (2 of 3: R-UIM with LF E-UMIID)
Notes:• RUIMID Usage Indicator = bit 1 (b1) of Efusgind EF in R-UIM. "0" indicates use ESN_ME, "1" indicates use UIM_ID• In practice, R-UIM Usage Indicator is typically expected to be set to “1”.
April 2007
38
Scenarios of Different Combinations of R-UIM, MS and BS (3 of 3: R-UIM with SF EUIMID)
Notes:• RUIMID Usage Indicator = bit 1 (b1) of Efusgind EF in R-UIM. "0" indicates use ESN_ME, "1" indicates use UIM_ID• In practice, R-UIM Usage Indicator is typically expected to be set to “1”.• Bit b2 indicates whether to use MEID of handset (set to “0”) or SF EUIMID of card (set to “1”)
April 2007
39
Standards Involved in the Migrations
April 2007
40
A list of all MEID, UIMID extension related standards:
• TSG-C (Air Interface)• C.S0072, MEID support (Pre_Rev.D solution)• C.S0073, Signaling Test Specification for MEID Support• C.S0023-C, RUIM for Spread Spectrum System• C.S0066, Over-the-Air Service Provisioning for MEID-Equipped Mobile Stations in Spread
Spectrum Systems• C.S0065, cdma2000 Application on UICC for Spread Spectrum Systems
• TSG-A (IOS)- IOS5.0• TSG-X (Core Network)
• X.S0008-0 v2.0 MAP Support for the Mobile Equipment Identity (MEID)• X.S0033 “OTA Support for MEID”• Possibly X.P0011-D (IS-835-D): ESN is present in Packet Data Accounting Record, Operators
may want to add MEID in Packet Data Accounting Record.
• Other 3GPP2 Specifications• C.R0048 “3G Mobile Equipment Identifier (MEID) Stage 1”• SC.R4002 “Mobile Equipment Identifier (MEID) GHA (Global Hexadecimal Administrator)
Assignment Guidelines and Procedures”• S.R0111 “Expanded R-UIM Identifier”• SC.P4003-0 v0.6, Expanded R-UIM Numbering Administration Procedures.
• CIBER and other billing specifications may need to be upgraded• CIBER ESN/IMEI field has been extended to include ESN/IMEI/MEID. (pESN, UIMID &
pUIMID are a subset of the ESN space, and SF EUIMID is a subset of MEID space.)
List of Standards
April 2007
41
Actions for Carriers
April 2007
42
Actions for Non-RUIM Carriers
• As pESN will not be unique,• Ensure HLR/AuC & VLR will not check the uniqueness of ESN• Check whether OTASP (if used) requires a unique handset identifier
• A potential example would be as an index to a file of A-keys provided from the handset vendor, to associate with a subscription
• Add support for C.S0066 and possibly X.S0033
• Ensure that network will NOT reject call attempt from MEID handset with SCM bit 4 = “1”.
• To avoid PLCM collision caused by duplicated pESN,• C.S0072 MEID-equipped handsets are recommended.• Upgrade network to support C.S0072.
• Update background management tools to use MEID or IMSI (instead of ESN) as the ID for handset management.
April 2007
43
• Choice of EUIMID format (LF EUIMID is recommended)
• As pUIMID will not be unique,• Ensure HLR/AuC & VLR will not check the uniqueness of ESN• Check whether OTASP (if used) requires a unique card identifier
• A potential example would be as an index to a file of A-keys provided from the card vendor, to associate with a subscription
• An alternative in this case would be to generate the A-key dynamically during the OTASP session
• Ensure network will NOT reject call attempt from MEID handset with SCM bit 4 = “1”.
• Upgrade the network to support C.S0072 to avoid PLCM collisions. However, “pUIMID provisioned R-UIM card in ESN phone” will still be at risk of PLCM collision.
• To avoid PLCM collision caused by duplicated pUIMID and pESN, • C.S0072 MEID-equipped handsets are recommended.• Upgrade network to support C.S0072.
• Update the background management tools to start to use ICCID (instead of UIMID) as the ID for card management.
Actions for RUIM Carriers
April 2007
44
Administration ofMEID, ICCID and EUIMID
April 2007
45
Administration
MEID• A Global Hexadecimal Administrator (GHA) assigns MEID code prefixes.• TIA, which already acts as the ESN administrator, also acts as the GHA.
ICCID• For Long Format EUIMID (76-bit ICCID), administration and assignment
continues to follow the current policy (ITU-T E.118) and be taken care by the regional regulatory agency and carriers/issuers.
EUIMID• For Short Format EUIMID (56-bit MEID like), administration and
assignment will follow 3GPP2 SC.P4003-0 v0.6, Expanded R-UIM Numbering Administration Procedures. It will be also administrated by TIA.
April 2007
46
Summary
April 2007
47
Summary • Carriers are recommended to have BS upgraded to support TIA-1082
/ C.S0072 for minimizing PLCM collision due to non-unique pESN/pUIMID. TIA-1082 / C.S0072 MEID-compliant MSs should also be deployed ASAP and even before network upgrade (provided that current network supports bit 4 of SCM = “1”).
• The shortage of UIMID should be addressed by several, parallel, efforts
– Utilize the unassigned UIMID blocks.
– Refarm the obsolete ESN (legacy AMPS phone) through TIA and/or recycle used UIMID, if possible.
– Carefully study the two options (Short and Long Form EUIMID) available for EUIMID addressing
April 2007
48
Reference Information and Documents
• For more details on the probability of pESN collisions and under what conditions do they happen see white paper on pESN collisions at– http://www.tiaonline.org/standards/resources/esn/index.cfm#meid
• CDG Reference Document – MEID Roaming Impacts– http://www.cdg.org/members_only/refdocs/137.zip
• CDG Reference Document – MEID Support for CDMA2000 Systems, Ver 1.0, March 3, 2005 – http://www.cdg.org/members_only/refdocs/107v1.0.zip
• MEID IOS Issue, CDG Technical Bulletin 070301IRT v1.0– http://www.cdg.org/members_only/teams/IntRoaming/docs/CDG%20Tech
%20Bulletin%20070301IRT%20MEID%20IOS%20Issue%20v1_0.doc
• Lucent contribution on PLCM collision probability– ftp://ftp.3gpp2.org/TSGC/Working/2003/2003-03-Vancouver/TSG-C-2003-
03-Vancouver/WG2/C20-20030317-018A_(LU)SHA_Response.pdf
April 2007
49
Glossary (1/2)AN Access Node
AT Access Terminal
BREW Binary Runtime Environment for Wireless
BS Base Station
CAVE Cellular Authentication and Voice Encryption
ECAM Extended Channel Assignment Message
EF Elementary File
ESN Electronic Serial Number
EUIMID Expanded UIMID
ICCID Integrated Circuit Card ID
IMEI International Mobile Equipment Identifier
IOS InterOperability Specification
LAC Link Access Control
LF EUIMID Long Form EUIMID
April 2007
50
Glossary (2/2)
MEID Mobile Equipment ID
MF Master File
MS Mobile Station
P_REV Protocol Revision
pESN pseudo ESN
PLCM Public Long Code Mask
pUIMID pseudo UIMID
r-csch reverse common signaling channel
SCM Station Class Mark
SF EUIMID Short Form EUIMID
SHA Secure Hash Algorithm
TIA Telecommunications Industry Association
UHDM Universal Handoff Direction Message
UIMID User Identity Module ID
April 2007
51
Appendix – Call Flow Diagrams
April 2007
52
MEID Call Flows 1: Call Setup for non-MEID MS*
MS BS
R-csch:Origination or Page Response Message
LAC address included ESN if MSID_TYPE includes ESNSCM bit 4 set to 0
F-cschExtended Channel Assignment Meesage
(Only ESN based can be conveyed for p_rev_in_use < 9)
Traffic Channel Initialization:MS acquires BS, sends preambles.
BS acquires preambles, sends BS Ack OrderService negotiation etc.
Traffic ChannelUsing PLCM Type specified in ECAM
* BS capability does not matter in this scenario
PLCM isn't specified in ECAM. ESN-based
PLCM is implied, but it's not actually present in the ECAM for p_rev<9
April 2007
53
MEID Call Flows 2: Call Setup between MEID Capable MS and MEID Capable BS*
MS BS
R-csch:Origination or Page Response Message
LAC address included p-ESN if MSID_TYPE includes ESNSCM bit 4 set to 1
F-cschStatus Request Message
(MEID Request)
R-csch:Extended Status Response Message
(MEID Information Record)
F-cschMEID-Extended Channel Assignment Meesage
(PLCM_TYPE set to any of the valid PLCM types)
Traffic Channel Initialization:MS acquires BS, sends preambles.
BS acquires preambles, sends BS Ack OrderService negotiation etc.
F-dschStatus Request Message
(MEID Request)
R-dsch: Status Response Message(MEID Information Record)
Optional Query for MEID on
csch
Optional Query for MEID on
dsch
If p_rev_in_use is >=9, regular ECAM can be used
since that carries PLCM_TYPE fields
Note: BS has to know/query for MEID if using MEID based PLCM on traffic. Once queried, BS can cache this information for future calls
April 2007
54
MEID Call Flows 3: Call Setup between MEID Capable MS and non-MEID Capable BS*
MS BS
R-csch:Origination or Page Response Message
LAC address included p-ESN if MSID_TYPE includes ESNSCM bit 4 set to 1
F-cschExtended Channel Assignment Meesage
(Only ESN based PLCM can be conveyed for p_rev_in_use < 9)
Traffic Channel Initialization:MS acquires BS, sends preambles.
BS acquires preambles, sends BS Ack OrderService negotiation etc.
Traffic ChannelUsing PLCM Type specified in ECAM
Note: For this case MS will be operational using p-ESN. PLCM collisions can occur on traffic channel if multiple MSs hash to the same p-ESN, if BS uses ESN based
PLCM
April 2007
55
MEID Call Flows 4: Handoff between an MEID Capable source BS and target BS*
MSMEID
BS
Traffic ChannelUsing any valid PLCM Type
MEIDBS
F-dtchMEID UHDM Message
(PLCM_TYPE set to any valid PLCM type,PLCM_TYPE_INCL=0 to continue same PLCM type)
Traffic ChannelUsing specified PLCM Type
R-dtchHandoff Completion Message
Source Target
Regular UHDM can also be sent if no
PLCM type change is needed
April 2007
56
MEID Call Flows 5: Handoff between MEID Capable source BS and non-MEID Capable target BS
MSMEID
BS
F-dtchMEID UHDM Message
(PLCM_TYPE set to ESN-based PLCM typeIf target BS PREV is less than 9)
Traffic ChannelUsing previously selected PLCM Type
R-dtchHandoff Completion Message
Non-MEID
BS
Traffic ChannelUsing Any Valid PLCM Type
source target
Note: Source BS has to explicitly change the PLCM Type as required by target BS;
MS will not change it autonomously
April 2007
57
MEID Call Flows 6: Handoff between non-MEID Capable source BS and MEID Capable target BS
MSNon-MEID
BS
F-dtchUHDM Message
Traffic ChannelUsing ESN-based PLCM Type
R-dtchHandoff Completion Message
MEIDBS
Traffic ChannelUsing ESN-based PLCM Type
Traffic ChannelUsing specified PLCM Type
F-dtchMEID UHDM Message
(PLCM_TYPE set to any valid PLCM type)
R-dtchHandoff Completion Message
Optional:The MEID BS may use MEID
UHDM to change the
PLCM_Type to any type allowed
source target
Note: This can be BS assigned PLCM if source BS and MS have p_rev_in_use >=9
April 2007
58
MEID Call Flows 7: OTASP Capability RequestMS BS
F-dtchData Burst Message
(Extended OTASP Protocol Capability Request – MEID Info)
R-dtch:Extended OTASP Protocol Capability Response Message
(MEID Information Record)
Traffic Channel:Conversation State
April 2007
59
END