migrations: esn to meid & uimid to euimid april 2007

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


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)



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


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 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


(PLCM_TYPE set to ESN-based PLCM typeIf target BS PREV is less than 9)

Traffic ChannelUsing previously selected PLCM Type


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


MEIDBS

Traffic ChannelUsing ESN-based PLCM Type

Traffic ChannelUsing specified PLCM Type


(PLCM_TYPE set to any valid PLCM type)


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

migrations: esn to meid & uimid to euimid april 2007

Documents

bits serial number

used uimid

meid migration

meidbased addressing

hexadecimal digit code

distinct esns

uimid space

unique identification