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

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 2

3. Synopsis TAC continues to exist conceptually – But no specific digits are used for TAC TRRTTTTTSSSSSS Current IMEI Structure Reporting Body ID TAC Serial Number MRRMMMMMST Proposed IMEI Structure Manufacturer Code TAC & Serial Number Reporting Body ID 3

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 4

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 5

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 6

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 7

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 8

9. Supplemental Slides Outline of Procedures and Operation 9

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 = {,,, …} – is character string as recorded during M-Block request/assignment M-Block and Type_Alloc_Rec assignments are pillars of IMEI database 10

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 11

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

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 13

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 14

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 15

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 16