Outline of a TAC Conservation Approach

1. Outline of a TAC Conservation Approach Numbering JEM Teleconference, Nov. 3, 2010

2. Introduction • Purpose of presentation • Address one possible approach in TAC conservation, • Referring to in the JEM London Sept. 2009 meeting summary, Option 2 • Recommendation • Include in the analysis of Options in efforts of industry consensus building and decision making regarding alleviation of TAC depletion

3. Synopsis • TAC continues to exist conceptually • But no specific digits are used for TAC Current IMEI Structure R R T T T T T T S S S S S S TAC Serial Number Reporting Body ID Proposed IMEI Structure R R M M M M M M ST ST ST ST ST ST TAC & Serial Number Manufacturer Code Reporting Body ID

4. Administration • Administration procedures are very similar to existing ones • … but instead of TAC, administrator allocates M-blocks to manufacturers • Manufacturers can allocate serial number space in ST space to multiple “TACs” • Manufacturer can also allocate multiple M-blocks to same “TAC” • Manufacturer informs Administrator of new “TAC” and serial number allocations by virtue of database updates • Database is managed by Administrator, and is accessible to operators and other authorized entities

5. Usage • Database lookup is used to find out TAC • Entire IMEI is presented to the database • Database returns information such as manufacturer, "TAC", possibly even much more (e.g. date and place of manufacture) • Even in current usage, TAC digits are rarely entered manually, hence entering extra digits is not that burdensome • Databases can be implemented first • Retain the current TAC allocation regime at first • Allow operators and others to switch to the new scheme in an un-synchronized fashion

6. Strawman Timeline Objective: Allow un-synchronized transition to new IMEI allocation process over a period of time • 2010: JEM proposal finalized • 2011: Industry consensus building • 2012: Database structures and procedures developed • 2013 onward: No TAC allocations made until manufacturer certifies it has databases implemented • 2013-15: Operator back-office transition to use new IMEI structure • 2016: Allocation of M codes (new IMEI regime) begins

7. Implementation Considerations • Proposed timeline would allow sufficient time to design and build database structure (by end of 2012) • JEM could engage in developing requirements for such a structure, e.g.: • Minimum required contents • Access privilege management; Security requirements • Timeliness requirements • Details of access procedures for manufacturers and others • Capacity • Peak lookup rates • Caching capability • etc. • Some implementation issues outlined on subsequent slides

8. Conclusion • Proposal allows smooth migration from TAC with specific IMEI digits to TAC-like database • Database management process can be largely automated with small estimated adjustment of manufacturers’ record keeping processes • Proposal is a step toward alignment of GDA and GHA processes • M-block allocation is similar to current MEID allocation process • MEID capability could be aligned with the IMEI one (determination of UE type) by implementing similar database

9. Supplemental Slides Outline of Procedures and Operation

10. M-Block and “TAC” Requests • M-Block Request/Assignment • Manufacturer requests a block of serial numbers from Administrator • Similar to current process with possible adjustments in application forms • Administrator grants appropriate number of M-blocks (see slide 4) • “TAC” Request/Assignment • Can be very similar to current processes of TAC allocation • When new device type is planned, manufacturer notifies Administrator • Information supplied could be identical to current TAC request, e.g. band class(es), power, protocol support, … • Device type “Type_Alloc_Rec” is assigned similar to current TAC, but there is no association with IMEI digits nor restriction of format • Format of “Type_Alloc_Rec” to be standardized - illustrative • Type Allocation Record: Type_Alloc_Rec = {<manuf>, <model>, <revision>, …} • <manuf> is character string as recorded during M-Block request/assignment • M-Block and Type_Alloc_Rec assignments are pillars of IMEI database

11. Database Structure • Administrator maintains centralized database • When a new M-block or Type_Alloc_Rec is assigned, administrator records in database • Dynamic database with “staleness” period agreed by the industry: quarter, month, week, day, … • Database record structure • List of assigned M-blocks • List of Type_Alloc_Rec, and status (active, discontinued) • Segment(s) of serial numbers assigned to produced devices, e.g.: • Type_Alloc_RecXYZ: [p1 .. q1, p2 .. q2, …] • … where p, q are beginning and end of an IMEI segment

12. Database Population Process • Both Administrator and manufacturers responsible for populating database • M-Block Status (allocated/unallocated): Administrator • Type_Alloc_Rec Assignment: Administrator • Type_Alloc_Rec Segments Allocated: Manufacturer • Security • Manufacturer receives proper security credentials at the time of M-block allocation allowing it to populate Type_Alloc_Rec segments in a given M-block • Manufacturer has no access privileges in other than its own M-blocks • Each accredited operator is given security credentials for database queries (one-time event per operator)

13. Queries • Only accredited entities can query database • Primarily intended for operators to use • Database may be operationally cashed per agreed procedures and with required degree of security • Manufacturers can query its assigned M-blocks, but not others • Query input: Full IMEI • Query return: Type_Alloc_Rec contents for that IMEI • Database technology discussion • Nature of database: a series of entries (X to Y) have same information (terminal type, etc.) • Database can be structured to avoid repetition: A series of segments assigned to Type_Alloc_Rec entries • Lookup consists of searching to determine to which segment an entry belongs • Very simple algorithm conducive to efficient fast binary search

14. Process (1 of 2) • Process outline is meant as an illustration • Other implementations feasible • Intent is to show it is conducive to automation • IMEI storage in UE • IMEI programming procedure: Write to inalterable memory in UE • WORM - Write Once Read Mostly - technique akin to blowing fuses • Manufacturing records keeping • Manufacturer must keep close track which IMEI serial numbers are assigned to devices, so that it is assigned only once • As each production run is planned, manufacturer can set aside a segment of serial numbers for each model it produces • Similar process must be in place now with traditional TAC • Difference: manufacturer can share an M-block among multiple UE types, can segment IMEIs of a UE type among multiple M-blocks or non-contiguously within an M-block

15. Process (2 of 2) • IMEI database update • Manufacturer periodically updates central database • Update period may be with conventional staleness period (see slide 11), or may be more frequent • Example (weekly database updates assumed) • Manufacturer has at its disposal A remaining IMEIs from M-block X, upon having discontinued production of a UE type previously using this M-block • For this week’s production, it is anticipated that A segment will be used up, plus segment B (not more than that, could be fewer) from block X+1 • Factory reserves segments A and B for assignment to this type of UE, showing “reserved” status in internal database • An IMEI is programmed sequentially into each UE, from segment A, then B • At final inspection, IMEI is read from each UE, and database status changed from “reserved” to “produced” (can be done by updating M-block record segments, i.e., no need to have a distinct entry for each UE) • There could be a separate list of IMEI of failed UEs (detail of little relevance) • At the end of the week, manufacturer updates central database by aligning records with its internal ones

16. Protection of Sensitive Data • Problem: Manufacturer may require protection of competitive data such as production quantities of a device model • Security of central database information may not be trusted • Each manufacturer has own standards of sensitivity to disclosure • Solution: Manufacturer can obfuscate data in the central database • Central database records show a superset of actually allocated IMEIs • Looking up an IMEI actually allocated to a device yields correct “TAC” • Looking up a hypothetical IMEI not yet allocated may yield incorrect “TAC” or “ghost TAC”, but this is not a concern • Since M-block allocation must have a margin ahead of production, there is always capacity to conceal current production information • As production runs become old news over time, database is updated by removing “misleading” records, thus not wasting IMEI space • Obfuscation regime/algorithm can be randomized, to further conceal sensitive information