Migrations: ESN to MEID & UIMID to EUIMID 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 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 Background & Terminology

April 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 Migration Relationship Derivation Relationship SHA-1 Hashing

April 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 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 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 10 16

April 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 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 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 ( 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 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 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 Migration : ESN to MEID

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

April 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 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 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 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 No (Only ESN-based PLCM) Standard scenario prior to ESN exhaustion =< 7 + TIA-1082 No (Only ESN-based PLCM) Only BS upgraded to support 1082 (i.e., MS is ESN provisioned) =< 7 + TIA-1082 =< 7No (Only pESN-based PLCM) Only MS upgraded to support 1082 (i.e., MS is MEID provisioned) =< 7 + TIA-1082 =< 7 + TIA-1082 YESBoth MS and BS upgraded to support 1082.

April Handoff Scenarios for MEID Capable MS Target BS does not support TIA-1082 Target BS supports TIA-1082 Source BS does not support TIA Continue pESN-based PLCM in UHDM Subsequent UHDM could change to a different PLCM Source BS supports TIA Change to pESN-based PLCM in UHDM Could continue with newer PLCM type used, e.g. BS assigned PLCM

April OTASP Support for MEID OTASP support for MEID is needed to identify mobiles uniquely during service provisioning Published as a 3GPP2 document C.S : “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 “ ” to support MEID query.

April 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-0YesHW ID Type = ‘0x00ffff’ (MEID) IS-856-0NoHW ID Type = ‘0x010000’ (ESN) IS-856-AYesHW ID Type = ‘0x00ffff’ (MEID) IS-856-ANoHW ID Type = ‘0x010000’ (ESN)

April 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 (DO Release 0) as well as IS-856-A (DO Rev A) since the Default Address Management Protocol was changed. HardwareIDType fieldMeaning 0x010000Electronic Serial Number (ESN) 0x00ffffMobile 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 0xFFFFFFNULL All other valuesinvalid

April 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 Migration : UIMID to EUIMID

April 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 ICCID Approach – China Unicom Proposal Every 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 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 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 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 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 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 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 EF CST (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 EF CST (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 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 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 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 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 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 Standards Involved in the Migrations

April 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.S 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.P 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 Actions for Carriers

April 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 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 Administration of MEID, ICCID and EUIMID

April 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.P v0.6, Expanded R-UIM Numbering Administration Procedures. It will be also administrated by TIA.

April Summary

April 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 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 – CDG Reference Document – MEID Roaming Impacts – CDG Reference Document – MEID Support for CDMA2000 Systems, Ver 1.0, March 3, 2005 – MEID IOS Issue, CDG Technical Bulletin IRT v1.0 – %20Bulletin% IRT%20MEID%20IOS%20Issue%20v1_0.dochttp:// %20Bulletin% IRT%20MEID%20IOS%20Issue%20v1_0.doc Lucent contribution on PLCM collision probability –ftp://ftp.3gpp2.org/TSGC/Working/2003/ Vancouver/TSG-C Vancouver/WG2/C A_(LU)SHA_Response.pdfftp://ftp.3gpp2.org/TSGC/Working/2003/ Vancouver/TSG-C Vancouver/WG2/C A_(LU)SHA_Response.pdf

April Glossary (1/2) ANAccess Node ATAccess Terminal BREWBinary Runtime Environment for Wireless BSBase Station CAVECellular Authentication and Voice Encryption ECAMExtended Channel Assignment Message EFElementary File ESNElectronic Serial Number EUIMIDExpanded UIMID ICCIDIntegrated Circuit Card ID IMEIInternational Mobile Equipment Identifier IOSInterOperability Specification LACLink Access Control LF EUIMIDLong Form EUIMID

April Glossary (2/2) MEIDMobile Equipment ID MFMaster File MSMobile Station P_REVProtocol Revision pESNpseudo ESN PLCMPublic Long Code Mask pUIMIDpseudo UIMID r-cschreverse common signaling channel SCMStation Class Mark SF EUIMIDShort Form EUIMID SHASecure Hash Algorithm TIATelecommunications Industry Association UHDMUniversal Handoff Direction Message UIMIDUser Identity Module ID

April Appendix – Call Flow Diagrams

April MEID Call Flows 1: Call Setup for non-MEID MS* * 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 MEID Call Flows 2: Call Setup between MEID Capable MS and MEID Capable BS*

April MEID Call Flows 3: Call Setup between MEID Capable MS and non-MEID Capable BS*

April MEID Call Flows 4: Handoff between an MEID Capable source BS and target BS*

April MEID Call Flows 5: Handoff between MEID Capable source BS and non-MEID Capable target BS

April MEID Call Flows 6: Handoff between non-MEID Capable source BS and MEID Capable target BS

April MEID Call Flows 7: OTASP Capability Request

April END