1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) M. Montemurro, Ed.
Request for Comments: 7254 A. Allen
Category: Informational Blackberry
ISSN: 2070-1721 D. McDonald
Eircom
P. Gosden
GSM Association
May 2014
<span class="h1">A Uniform Resource Name Namespace</span>
<span class="h1">for the Global System for Mobile Communications Association (GSMA)</span>
<span class="h1">and the International Mobile station Equipment Identity (IMEI)</span>
Abstract
This specification defines a Uniform Resource Name (URN) namespace
for the Global System for Mobile Communications Association (GSMA)
and a Namespace Specific String (NSS) for the International Mobile
station Equipment Identity (IMEI), as well as an associated parameter
for the International Mobile station Equipment Identity and Software
Version number (IMEISV). The IMEI and IMEISV were introduced as part
of the specification for the GSM and are also now incorporated by the
3rd Generation Partnership Project (3GPP) as part of the 3GPP
specification for GSM, Universal Mobile Telecommunications System
(UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and
IMEISV are used to uniquely identify Mobile Equipment within these
systems and are managed by the GSMA. URNs from this namespace almost
always contain personally identifiable information and need to be
treated accordingly.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7254">http://www.rfc-editor.org/info/rfc7254</a>.
<span class="grey">Montemurro, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Montemurro, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Namespace Registration Template .................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Specification ...................................................<a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. IMEI Parameters ............................................<a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. IMEI Format ................................................<a href="#page-9">9</a>
<a href="#section-4.2.1">4.2.1</a>. Type Allocation Code (TAC) ..........................<a href="#page-9">9</a>
<a href="#section-4.2.2">4.2.2</a>. Serial Number (SNR) .................................<a href="#page-9">9</a>
<a href="#section-4.2.3">4.2.3</a>. Spare ..............................................<a href="#page-10">10</a>
<a href="#section-4.2.4">4.2.4</a>. Binary Encoding ....................................<a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. IMEISV Format .............................................<a href="#page-10">10</a>
<a href="#section-4.3.1">4.3.1</a>. Type Allocation Code (TAC) .........................<a href="#page-10">10</a>
<a href="#section-4.3.2">4.3.2</a>. Serial Number (SNR) ................................<a href="#page-11">11</a>
<a href="#section-4.3.3">4.3.3</a>. Software Version Number (SVN) ......................<a href="#page-11">11</a>
<a href="#section-4.3.4">4.3.4</a>. Binary Encoding ....................................<a href="#page-11">11</a>
<a href="#section-5">5</a>. Community Considerations .......................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Namespace Considerations .......................................<a href="#page-12">12</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. Security and Privacy Considerations ............................<a href="#page-12">12</a>
<a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-14">14</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-14">14</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-14">14</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-15">15</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This specification defines a Uniform Resource Name (URN) namespace
for the Global System for Mobile Communications Association (GSMA)
and a Namespace Specific String (NSS) for the International Mobile
station Equipment Identity (IMEI), as well as an associated parameter
for the International Mobile station Equipment Identity and Software
Version number (IMEISV) as per the namespace registration requirement
found in <a href="./rfc3406">RFC 3406</a> [<a href="#ref-1" title=""Uniform Resource Names (URN) Namespace Definition Mechanisms"">1</a>]. The Namespace Identifier (NID) 'gsma' is for
identities used in GSM, Universal Mobile Telecommunications System
(UMTS), and Long Term Evolution (LTE) networks. The IMEI and the
IMEISV are managed by the GSMA, so this NID is managed by the GSMA.
While this specification currently defines only the 'imei' NSS under
the 'gsma' NID, additional NSS under the 'gsma' NID may be specified
in the future by the GSMA, using the procedure for URN NSS changes
and additions (currently through the publication of future
Informational RFCs approved by IETF consensus).
<span class="grey">Montemurro, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
The IMEI is 15 decimal digits long and includes a Type Allocation
Code (TAC) of 8 decimal digits and a Serial Number (SNR) of 6 decimal
digits plus a Spare decimal digit. The TAC identifies the type of
the Mobile Equipment and is chosen from a range of values allocated
to the Mobile Equipment manufacturer in order to uniquely identify
the model of the Mobile Equipment. The SNR is an individual serial
number that uniquely identifies each Mobile Equipment device within
the TAC. The Spare digit is used as a Check digit to validate the
IMEI and is always set to the value 0 when transmitted by the Mobile
Equipment.
The IMEISV is 16 decimal digits long and includes the TAC and SNR,
same as for the IMEI, but also includes a 2 decimal digit Software
Version Number (SVN), which is allocated by the Mobile Equipment
manufacturer to identify the software version of the Mobile
Equipment.
The information here is meant to be a concise guide for those wishing
to use the IMEI and IMEISV as URNs. Nothing in this document should
be construed to override 3GPP Technical Specification (TS) 23.003
[<a href="#ref-2" title=""Numbering, addressing and identification"">2</a>], which specifies the IMEI and IMEISV.
The GSMA is a global trade association representing nearly 800 mobile
phone operators across 220 territories and countries of the world.
The primary goals of the GSMA are to ensure that mobile phones and
wireless services work globally and are easily accessible. Further
details about the GSMA's role in allocating the IMEI and the IMEISV,
as well as the IMEI and IMEISV allocation guidelines, can be found in
GSMA Permanent Reference Document (PRD) TS.06 [<a href="#ref-3" title=""IMEI Allocation and Approval Guidelines"">3</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-4" title=""Key words for use in RFCs to Indicate Requirement Levels"">4</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Namespace Registration Template</span>
Namespace ID: 'gsma'
Registration Information:
Registration version number: 1
Registration date: 2014-01-12
<span class="grey">Montemurro, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
Declared registrant of the namespace:
Registering organization:
Name: GSM Association
Address: 1st Floor, Mid City Place,
71 High Holborn, London, England
Designated contact person:
Name: Paul Gosden
Coordinates: pgosden@gsma.com
Declaration of syntactic structure:
The identifier is expressed in American Standard Code for
Information Interchange (ASCII) characters and has a hierarchical
structure expressed using the Augmented Backus-Naur Form (ABNF)
defined in <a href="./rfc5234">RFC 5234</a> [<a href="#ref-5" title=""Augmented BNF for Syntax Specifications: ABNF"">5</a>], as follows:
gsma-urn = "urn:" gsma-NID ":" gsma-NSS
gsma-NID = "gsma"
gsma-NSS = imei-specifier / future-gsma-specifier
imei-specifier = "imei:" ( imeival / ext-imei )
[ ";" sw-version-param ]
[ ";" imei-version-param ]
ext-imei = gsma-defined-nonempty ;GSMA defined and
;IETF consensus
;required
sw-version-param = "svn=" software-version
imei-version-param = "vers=" imei-version-val
software-version = 2DIGIT
imei-version-val = DIGIT
future-gsma-specifier = future-specifier
*( ";" future-param )
future-specifier = gsma-defined-nonempty ;GSMA defined
future-param = par-name [ EQUAL par-value ]
par-name = gsma-defined-nonempty
par-value = gsma-defined-nonempty
EQUAL = "="
gsma-defined-nonempty = 1*gsma-urn-char
gsma-urn-char = ALPHA / DIGIT
/ "-" / "." / "_" / "%" / ":"
<span class="grey">Montemurro, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
An NSS for the IMEI is defined under the 'gsma' NID.
An IMEI is an identifier under the 'gsma' NID that uniquely
identifies the mobile devices used in the GSM, UMTS, and LTE
networks.
The representation of the IMEI is defined in 3GPP TS 23.003 [<a href="#ref-2" title=""Numbering, addressing and identification"">2</a>].
To accurately represent an IMEI received in a cellular signaling
message (see 3GPP TS 24.008 [<a href="#ref-6" title=""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"">6</a>]) as a URN, it is necessary to
convert the received binary (Binary Coded Decimal (BCD)) encoded
bit sequence to a decimal digit string representation. Each field
has its representation for humans as a decimal digit string with
the most significant digit first.
The following ABNF includes the set of core rules in <a href="./rfc5234">RFC 5234</a> [<a href="#ref-5" title=""Augmented BNF for Syntax Specifications: ABNF"">5</a>];
the core rules are not repeated here.
A URN with the 'imei' NSS contains one 'imeival', and its formal
definition is provided by the following ABNF (<a href="./rfc5234">RFC 5234</a>) [<a href="#ref-5" title=""Augmented BNF for Syntax Specifications: ABNF"">5</a>]:
imeival = tac "-" snr "-" spare
tac = 8DIGIT
snr = 6DIGIT
spare = DIGIT
<future-gsma-specifier> and <gsma-defined-nonempty> can comprise
any ASCII characters compliant with the above ABNF.
The GSMA will take responsibility for the 'gsma' namespace,
including the 'imei' NSS.
Additional NSS may be added for future identifiers needed by the
GSMA, at their discretion. Only URNs with the 'imei' NSS are
considered to be "GSMA IMEI URNs", and use in IETF protocols of
other NSS that might be defined in the future will require IETF
consensus.
Relevant ancillary documentation:
See IMEI Allocation and Approval Guidelines (GSMA PRD TS.06) [<a href="#ref-3" title=""IMEI Allocation and Approval Guidelines"">3</a>]
and 3GPP TS 23.003 [<a href="#ref-2" title=""Numbering, addressing and identification"">2</a>].
<span class="grey">Montemurro, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
Identifier uniqueness considerations:
Identifiers under the 'gsma' NID are defined and assigned by the
GSMA after ensuring that the URNs to be assigned are unique.
Uniqueness is achieved by checking against the IANA registry of
previously assigned names.
Procedures are in place to ensure that each IMEI is uniquely
assigned by the Mobile Equipment manufacturer so that it is
guaranteed to uniquely identify that particular Mobile Equipment
device.
Procedures are in place to ensure that each IMEISV is uniquely
assigned by the Mobile Equipment manufacturer so that it is
guaranteed to uniquely identify that particular Mobile Equipment
device and the specific software version installed.
Identifier persistence considerations:
The GSMA is committed to maintaining uniqueness and persistence of
all resources identified by assigned URNs.
As the NID sought is 'gsma' and "GSMA" is the long-standing
acronym for the trade association that represents the mobile phone
operators, the URN should also persist indefinitely (at least as
long as there is a need for its use). The assignment process
guarantees that names are not reassigned. The binding between the
name and its resource is permanent.
The TAC and SNR portions of the IMEI and IMEISV are permanently
stored in the Mobile Equipment, so they remain persistent as long
as the Mobile Equipment exists. The process for TAC and SNR
assignment is documented in GSMA PRD TS.06 [<a href="#ref-3" title=""IMEI Allocation and Approval Guidelines"">3</a>], and once assigned,
the TAC and SNR values are not reassigned to other Mobile
Equipment devices. The SVN portion of the IMEISV may be modified
by software when new versions are installed but should be
persistent for the duration of the installation of that specific
version of software.
Process of identifier assignment:
The GSMA will manage the <NSS> (including 'imei') and
<future-gsma-specifier> identifier resources to maintain
uniqueness.
The process for IMEI and IMEISV assignment is documented in GSMA
PRD TS.06 [<a href="#ref-3" title=""IMEI Allocation and Approval Guidelines"">3</a>].
<span class="grey">Montemurro, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
Process for identifier resolution:
Since the 'gsma' NSS is not currently globally resolvable, this is
not applicable.
Rules for Lexical Equivalence:
Two GSMA IMEI URNs are equivalent if they have the same 'imeival'
value, and the same parameter values in the same sequential order,
with the exception that the 'vers=0' parameter is to be ignored
for the purposes of comparison. All of these comparisons are to
be case insensitive.
Any identifier in the 'gsma' NSS can be compared using the normal
mechanisms for percent-encoded UTF-8 strings (see <a href="./rfc3629">RFC 3629</a> [<a href="#ref-7" title=""UTF-8, a transformation format of ISO 10646"">7</a>]).
Conformance with URN Syntax:
The string representation of the 'gsma' NID and of the 'imei' NSS
is fully compatible with the URN syntax (see <a href="./rfc2141">RFC 2141</a> [<a href="#ref-8" title=""URN Syntax"">8</a>]).
Validation mechanism:
The IMEI can be validated using the mechanism defined in Annex B
of 3GPP TS 23.003 [<a href="#ref-2" title=""Numbering, addressing and identification"">2</a>]. There is no mechanism defined to validate
the SVN field of the IMEISV.
Scope: The GSMA URN is global in scope.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Specification</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. IMEI Parameters</span>
The optional 'vers' parameter and the 'ext-imei' field in the ABNF
are included for extensibility of the 'imei' NSS -- for example, if
the IMEI format is extended in the future (such as with additional
digits or using hex digits). In this case, the 'vers' parameter
would contain a non-zero value and the 'ext-imei' would be further
defined to represent the syntax of the extended IMEI format. A value
of the 'vers' parameter equal to 0 or the absence of the 'vers'
parameter means the URN format is compliant with the format specified
here.
Any change to the format of the 'imei' NSS requires the use of the
procedure for URN NSS changes and additions (currently through the
publication of future Informational RFCs approved by IETF consensus).
The use of the 'vers' parameter was chosen for extensibility instead
of defining a new NSS (e.g., 'imei2') because it is likely that many
<span class="grey">Montemurro, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
applications will only need to perform string compares of the
'imeival'. So, even if the format or length of the 'imeival' changes
in the future, such applications should continue to work without
having to be updated to understand a new NSS.
<a href="./rfc7255">RFC 7255</a> [<a href="#ref-10" title=""Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID"">10</a>] specifies how the GSMA IMEI URN can be used as an
instance ID as specified in <a href="./rfc5626">RFC 5626</a> [<a href="#ref-11" title=""Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)"">11</a>]. Any future value of the
'vers' parameter other than 0, or the definition of additional
parameters that are intended to be used as part of an instance ID,
will require an update to <a href="./rfc7255">RFC 7255</a> [<a href="#ref-10" title=""Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID"">10</a>].
For example:
urn:gsma:imei:90420156-025763-0;vers=0
The IMEISV is an identifier that uniquely identifies mobile devices
and their associated software versions used in the GSM, UMTS, and LTE
networks. The representation of the IMEISV is defined in 3GPP TS
23.003 [<a href="#ref-2" title=""Numbering, addressing and identification"">2</a>].
To represent the IMEISV, the URN parameter 'svn' is appended to the
GSMA IMEI URN and set equal to the decimal string representation of
the two software version number (svn) digits in the IMEISV, and the
Spare digit in the IMEI 'imeival' is set to zero.
For example:
urn:gsma:imei:90420156-025763-0;svn=42
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. IMEI Format</span>
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Type Allocation Code (TAC)</span>
The TAC is an 8 decimal digit value. The TAC identifies the type of
the Mobile Equipment and is chosen from a range of values allocated
to the Mobile Equipment manufacturer in order to uniquely identify
the model of the Mobile Equipment.
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Serial Number (SNR)</span>
The SNR is a 6 decimal digit value. The SNR is an individual serial
number that uniquely identifies each Mobile Equipment device within
the TAC.
<span class="grey">Montemurro, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>. Spare</span>
The Spare is a single decimal digit. When the IMEI is stored on the
Mobile Equipment and network equipment, it contains a value that is
used as a Check digit and is intended to avoid manual reporting
errors (e.g., when customers register stolen mobiles at the
operator's customer care desk) and also to help guard against the
possibility of incorrect entries being provisioned in the network
equipment. The Spare is always set to zero when transmitted by the
Mobile Equipment (including when in the IMEI URN format). Annex B of
3GPP TS 23.003 [<a href="#ref-2" title=""Numbering, addressing and identification"">2</a>] specifies a mechanism for computing the actual
Check digit in order to validate the TAC and SNR.
<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>. Binary Encoding</span>
When included in a cellular signaling message, the IMEI format is 15
decimal digits encoded in 8 octets, using BCD as defined in 3GPP TS
24.008 [<a href="#ref-6" title=""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"">6</a>]. Figure 1 is an abstract representation of a BCD-encoded
IMEI stored in memory (the actual storage format in memory is
implementation specific). In Figure 1, the most significant digit of
the TAC is coded in the least significant bits of octet 1. The most
significant digit of the SNR is coded in the least significant bits
of octet 5. The Spare digit is coded in the least significant bits
of octet 8. When included in an identity element in a cellular
signaling message, the most significant digit of the TAC is
included in digit 1 of the identity element in Figure 10.5.4 of
3GPP TS 24.008 [<a href="#ref-6" title=""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"">6</a>].
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | S|
| T | S | p|
| A | N | a|
| C | R | r|
| | | e|
+--+-----+-----+-----+--+--+-----+-----+--+--+
1 2 3 4 5 6 7 8 Octets
Figure 1: IMEI Format
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. IMEISV Format</span>
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Type Allocation Code (TAC)</span>
The TAC is the same as the TAC in the IMEI (see <a href="#section-4.2.1">Section 4.2.1</a>).
<span class="grey">Montemurro, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. Serial Number (SNR)</span>
The SNR is the same as the SNR in the IMEI (see <a href="#section-4.2.2">Section 4.2.2</a>).
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. Software Version Number (SVN)</span>
The Software Version Number is allocated by the mobile device
manufacturer to identify the software version of the mobile device.
<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>. Binary Encoding</span>
When included in a cellular signaling message, the IMEISV format is
16 decimal digits encoded in 8 octets using BCD as defined in 3GPP TS
24.008 [<a href="#ref-6" title=""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"">6</a>]. Figure 2 is an abstract representation of a BCD-encoded
IMEISV stored in memory (the actual storage format in memory is
implementation specific). In Figure 2, the most significant digit of
the TAC is coded in the most significant bits of octet 1. The most
significant digit of the SNR is coded in the most significant bits of
octet 5. The most significant digit of the SVN is coded in the most
significant bits of octet 8. When included in an identity element in
a cellular signaling message, the most significant digit of the TAC
is included in digit 1 of the identity element in Figure 10.5.4 of
3GPP TS 24.008 [<a href="#ref-6" title=""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"">6</a>].
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | |
| T | S | S |
| A | N | V |
| C | R | N |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 2 3 4 5 6 7 8 Octets
Figure 2: IMEISV Format
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Community Considerations</span>
GSM, UMTS, and LTE mobile devices will be interoperating with
Internet devices for a variety of voice and data services. To do
this, they need to make use of Internet protocols that will operate
end to end between devices in GSM/UMTS/LTE networks and those in the
general Internet. Some of these protocols require the use of URNs as
identifiers. Within the GSM/UMTS/LTE networks, mobile devices are
identified by their IMEI or IMEISV. Internet users will need to be
able to receive and include the GSMA URN in various Internet protocol
elements to facilitate communication between pure Internet-based
devices and GSM/UMTS/LTE mobile devices. Thus, the existence and
<span class="grey">Montemurro, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
syntax of these namespaces need to be available to the general
Internet community, and the namespace needs to be reserved with IANA
in order to guarantee uniqueness and prevent potential namespace
conflicts both within the Internet and within GSM/UMTS/LTE networks.
Conversely, Internet implementations will not generally possess IMEI
identifiers. The identifiers generated by such implementations will
typically be URNs within namespaces other than 'gsma' and may,
depending on context, even be non-URN URIs. Implementations are
advised to be ready to process URIs other than 'gsma' namespaced
URNs, so as to aid in interoperability.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Namespace Considerations</span>
A URN was considered the most appropriate URI to represent the IMEI
and IMEISV, as these identifiers may be used and transported
similarly to the Universally Unique Identifier (UUID), which is
defined as a URN in <a href="./rfc4122">RFC 4122</a> [<a href="#ref-12" title=""A Universally Unique IDentifier (UUID) URN Namespace"">12</a>]. Since specifications for
protocols that are used to transport device identifiers often require
the device identifier to be globally unique and in the URN format, it
is necessary that the URN formats are defined to represent the IMEI
and IMEISV.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
In accordance with <a href="https://www.rfc-editor.org/bcp/bcp66">BCP 66</a> (<a href="./rfc3406">RFC 3406</a>) [<a href="#ref-1" title=""Uniform Resource Names (URN) Namespace Definition Mechanisms"">1</a>], IANA has registered the
Formal URN Namespace 'gsma' in the "Uniform Resource Names (URN)
Namespaces" registry, using the registration template presented in
<a href="#section-3">Section 3</a> of this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security and Privacy Considerations</span>
IMEIs (but with the Spare value set to the value of the Check digit)
are displayable on most mobile devices and in many cases are printed
on the case within the battery compartment. Anyone with brief
physical access to the mobile device can therefore easily obtain the
IMEI. Therefore, IMEIs MUST NOT be used as security capabilities
(identifiers whose mere possession grants access). Unfortunately,
there are currently examples of some applications that are using the
IMEI for authorization. Also, some service provider's customer
service departments have been known to use knowledge of the IMEI as
"proof" that the caller is the legitimate owner of the mobile device.
Both of these are inappropriate uses of the IMEI.
While the specific software version of the mobile device only
identifies the lower-layer software that has undergone and passed
certification testing, and not the operating system or application
software, the software version could identify software that is
vulnerable to attacks or is known to contain security holes.
<span class="grey">Montemurro, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
Therefore, the IMEISV MUST only be delivered to trusted entities
within carrier networks and not provided to the Internet at large, as
it could help a malicious device identify that the mobile device is
running software that is known to be vulnerable to certain attacks.
This concern is similar to concerns regarding the use of the
User-Agent header in the Session Initiation Protocol (SIP) as
specified in <a href="./rfc3261">RFC 3261</a> [<a href="#ref-13" title=""SIP: Session Initiation Protocol"">13</a>]. Therefore, the IMEISV (that is, the IMEI
URN with a 'svn' parameter) MUST NOT be delivered to devices that are
not trusted. IMEIs are almost always personally identifiable
information, and so these URNs MUST be treated as personally
identifiable information in all cases. In order to prevent violating
a user's privacy, the IMEI URN MUST NOT be included in messages
intended to convey any level of anonymity.
Since the IMEI is permanently assigned to the mobile device and is
not modified when the ownership of the mobile device changes (even
upon a complete software reload of the device), the IMEI URN MUST NOT
be used as a user identifier or user address by an application.
Using the IMEI to identify a user or as a user address could result
in communications destined for a previous owner of a device being
received by the new device owner or could allow the new device owner
to access information or services owned by the previous device owner.
Additionally, since the IMEI identifies the mobile device, it
potentially could be used to identify and track users for the
purposes of surveillance and call data mining if sent in the clear.
Since the IMEI is personally identifiable information, uses of the
IMEI URN with IETF protocols require a specification and IETF Expert
Review [<a href="#ref-14" title="">14</a>] in order to ensure that privacy concerns are
appropriately addressed. Protocols carrying the IMEI URN SHOULD at a
minimum use channels that are strongly hop-by-hop encrypted, and it
is RECOMMENDED that end-to-end encryption be used.
Additional security considerations are specified in 3GPP TS 22.016
[<a href="#ref-9" title=""International Mobile station Equipment Identities (IMEI)"">9</a>]. Specifically, the IMEI is to be incorporated in a module that
is contained within the terminal. The IMEI SHALL NOT be changed
after the terminal's production process. It SHALL resist tampering,
i.e., manipulation and change, by any means (e.g., physical,
electrical, and software).
<span class="grey">Montemurro, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
This document draws heavily on the 3GPP work on Numbering,
Addressing, and Identification in 3GPP TS 23.003 [<a href="#ref-2" title=""Numbering, addressing and identification"">2</a>] and also on the
style and structure used in <a href="./rfc4122">RFC 4122</a> [<a href="#ref-12" title=""A Universally Unique IDentifier (UUID) URN Namespace"">12</a>]. The authors would like to
thank Cullen Jennings, Lisa Dusseault, Dale Worley, Ivo Sedlacek,
Atle Monrad, James Yu, Mary Barnes, Tim Bray, S. Moonesamy, Alexey
Melnikov, Martin Duerst, John Klensin, Paul Kyzivat, Christer
Holmberg, Barry Leiba, and Stephen Farrell for their help and
comments.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
<a href="https://www.rfc-editor.org/bcp/bcp66">BCP 66</a>, <a href="./rfc3406">RFC 3406</a>, October 2002.
[<a id="ref-2">2</a>] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003
(Release 8), March 2014, <<a href="ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/">ftp://ftp.3gpp.org/Specs/</a>
<a href="ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/">archive/23_series/23.003/</a>>.
[<a id="ref-3">3</a>] GSM Association, "IMEI Allocation and Approval Guidelines", PRD
TS.06 (DG06) Version 6.0, July 2011,
<<a href="http://www.gsma.com/newsroom/wp-content/uploads/2012/06/ts0660tacallocationprocessapproved.pdf">http://www.gsma.com/newsroom/wp-content/uploads/2012/06/</a>
<a href="http://www.gsma.com/newsroom/wp-content/uploads/2012/06/ts0660tacallocationprocessapproved.pdf">ts0660tacallocationprocessapproved.pdf</a>>.
[<a id="ref-4">4</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-5">5</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-6">6</a>] 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 (Release 8), June
2013, <<a href="ftp://ftp.3gpp.org/Specs/archive/24_series/">ftp://ftp.3gpp.org/Specs/archive/24_series/</a> 24.008/>.
[<a id="ref-7">7</a>] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, <a href="./rfc3629">RFC 3629</a>, November 2003.
[<a id="ref-8">8</a>] Moats, R., "URN Syntax", <a href="./rfc2141">RFC 2141</a>, May 1997.
[<a id="ref-9">9</a>] 3GPP, "International Mobile station Equipment Identities
(IMEI)", 3GPP TS 22.016 (Release 8), December 2009,
<<a href="ftp://ftp.3gpp.org/Specs/archive/22_series/22.016/">ftp://ftp.3gpp.org/Specs/archive/22_series/22.016/</a>>.
<span class="grey">Montemurro, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-10">10</a>] Allen, A., Ed., "Using the International Mobile station
Equipment Identity (IMEI) Uniform Resource Name (URN) as an
Instance ID", <a href="./rfc7255">RFC 7255</a>, May 2014.
[<a id="ref-11">11</a>] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol (SIP)",
<a href="./rfc5626">RFC 5626</a>, October 2009.
[<a id="ref-12">12</a>] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", <a href="./rfc4122">RFC 4122</a>, July 2005.
[<a id="ref-13">13</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-14">14</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>, May 2008.
<span class="grey">Montemurro, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7254">RFC 7254</a> The GSMA and IMEI URN May 2014</span>
Authors' Addresses
Michael Montemurro (editor)
Blackberry
4701 Tahoe Dr.
Mississauga, Ontario L4W 0B4
Canada
EMail: mmontemurro@blackberry.com
Andrew Allen
Blackberry
1200 Sawgrass Corporate Parkway
Sunrise, Florida 33323
USA
EMail: aallen@blackberry.com
David McDonald
Eircom
EMail: David.McDonald@meteor.ie
Paul Gosden
GSM Association
1st Floor, Mid City Place, 71 High Holborn
London
England
EMail: pgosden@gsma.com
Montemurro, et al. Informational [Page 16]
</pre>
|
