目录
GUTI
3GPP TS 23.003
2.8 Globally Unique Temporary UE Identity (GUTI)
2.8.1 Introduction
The purpose of the GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the Evolved Packet System (EPS). It also allows the identification of the MME and network. It can be used by the network and the UE to establish the UE's identity during signalling between them in the EPS. See 3GPP TS 23.401 [72].
The GUTI has two main components:
- one that uniquely identifies the MME which allocated the GUTI; and
- one that uniquely identifies the UE within the MME that allocated the GUTI.
Within the MME, the mobile shall be identified by the M-TMSI.
The Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier (MMEI).
The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC).
The GUTI shall be constructed from the GUMMEI and the M-TMSI.
For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the M-TMSI.
The operator shall need to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.
NOTE: In some network sharing cases it is required that the MMEC and NRI values are coordinated between the sharing operators, as described in 3GPP TS 23.251 [101]. In order to achieve CS/PS coordination in shared GERAN/UTRAN networks, the MMEC included in the GUTI can be set to identify the CS operator serving the UE.
The GUTI shall be used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signalling procedures (e.g. paging and Service Request).
The format and size of the GUTI is therefore the following:
<GUTI> = <GUMMEI><M-TMSI>,
where <GUMMEI> = <MCC><MNC><MME Identifier>
and <MME Identifier> = <MME Group ID><MME Code>
MCC and MNC shall have the same field size as in earlier 3GPP systems.
M-TMSI shall be of 32 bits length.
MME Group ID shall be of 16 bits length.
MME Code shall be of 8 bits length.
2.8 全局唯一临时UE标识（GUTI）
2.8.1 简介
GUTI的目的是提供UE的明确标识，该标识不会暴露UE或用户在演进分组系统（EPS）中的永久身份。它还允许识别MME和网络。它还能被网络和UE用于在EPS的信令中建立UE的身份。参见3GPP TS 23.401[72]。
GUTI有两个主要组成部分：
- 一个是唯一标识分配了GUTI的MME；和
- 一个是唯一标识分配了GUTI的MME中UE。
在MME内，移动设备应由M-TMSI识别。
全球唯一MME标识符（GUMMEI）应由MCC、MNC和MME标识符（MMEI）构成。
MMEI应由MME组ID（MMEGI）和MME代码（MMEC）构成。
GUTI应由GUMMEI和M-TMSI构成。
出于寻呼目的，使用S-TMSI寻呼移动设备。S-TMSI应由MMEC和M-TMSI构成。
运营商应确保MMEC在MME池区域内是唯一的，如果使用重叠池区域，则应确保MMEC在重叠MME池区域内是唯一的。
注：在某些网络共享情况下，需要在共享运营商之间协调MMEC和NRI值，如3GPP TS 23.251【101】中所述。为了在共享的GERAN/UTRAN网络中实现CS/PS协调，可以将包括在GUTI中的MMEC设置为正服务于UE的CS运营商。
GUTI应用于支持用户身份保密，并以S-TMSI的缩写形式支持更高效的无线信令过程（例如寻呼和服务请求）。
因此，GUTI的格式和大小如下：
<GUTI> = <GUMMEI><M-TMSI>，
其中 <GUMMEI> = <MCC><MNC><MME Identifier>
并且 <MME Identifier> = <MME Group ID><MME Code>
MCC和MNC应具有与早期3GPP系统中相同的字段大小。
M-TMSI的长度应为32位。
MME组ID的长度应为16位。
MME代码的长度应为8位。
S-TMSI
2.9 Structure of the S-Temporary Mobile Subscriber Identity (S-TMSI)
The S-TMSI is the shortened form of the GUTI to enable more efficient radio signalling procedures (e.g. paging and Service Request). For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the M-TMSI:
<S-TMSI> = <MMEC><M-TMSI>
See clause 2.8 for these definitions and the mapping.
2.9 缩写的-临时移动用户标识（S-TMSI）的结构
S-TMSI是GUTI的缩写形式，用于实现更高效的无线信令过程（例如寻呼和服务请求）。出于寻呼目的，使用S-TMSI寻呼移动设备。S-TMSI应由MMEC和M-TMSI构成：
<S-TMSI> = <MMEC><M-TMSI>
这些定义和映射见第2.8条。
GUTI和S-TMSI结构图
根据上面信息得到GUTI和S-TMSI结构图，如下：
|<----------------------------- GUTI ----------------------------->|
|<------------ GUMMEI ----------->| |
| |<-------- MMEI --------->| |
|==================================================================|
|MCC|NNC| MMEGI | MMEC | M-TMSI |
|==================================================================|
| |<--------------- S-TMSI ---------------->|GUTI和S-TMSI结构图
<GUTI> = <GUMMEI><M-TMSI>，
其中 <GUMMEI> = <MCC><MNC><MMEI>
并且 <MMEI> = <MMEGID><MME Code>
M-TMSI的长度应为32位。
MMEGID的长度应为16位。
MMEC的长度应为8位。
<S-TMSI> = <MMEC><M-TMSI>
GUTI重新分配过程
3GPP TS 24.301
5.4.1 GUTI reallocation procedure
5.4.1.1 General
The purpose of the GUTI reallocation procedure is to allocate a GUTI and optionally to provide a new TAI list or a new DCN-ID or both to a particular UE.
The reallocation of a GUTI is performed by the unique procedure defined in this subclause. This procedure can only be initiated by the MME in state EMM-REGISTERED.
The GUTI can also be implicitly reallocated at attach or tracking area updating procedures. The implicit reallocation of a GUTI is described in the subclauses which specify these procedures (see subclause 5.5.1 and 5.5.3).
The PLMN identity in the GUTI indicates the current registered PLMN.
NOTE 1: The GUTI reallocation procedure is usually performed in ciphered mode.
NOTE 2: Normally, the GUTI reallocation will take place in conjunction with another mobility management procedure, e.g. as part of tracking area updating.
5.4.1.2 GUTI reallocation initiation by the network
The MME shall initiate the GUTI reallocation procedure by sending a GUTI REALLOCATION COMMAND
message to the UE and starting the timer T3450 (see example in figure 5.4.1.2.1).
The GUTI REALLOCATION COMMAND message shall include a GUTI and may include a TAI list or a DCN-ID or both.
Figure 5.4.1.2.1: GUTI reallocation procedure
5.4.1 GUTI 重新配过程
5.4.1.1 概述
GUTI重新分配过程的目的是分配GUTI，并可选地向特定UE提供新的TAI列表或新的DCN-ID或两者。
GUTI的重新分配由本子条款中定义的唯一过程执行。此过程只能由处于EMM-REGISTERED状态的MME启动。
GUTI还可以在attach或TAU过程中隐式重新分配。隐性重新分配GUTI的描述在规定这些过程的子条款（见子条款5.5.1和5.5.3）中。
GUTI中的PLMN标识表示当前注册的PLMN。
注1：GUTI再分配程序通常在加密模式下执行。
注2：通常情况下，GUTI重新分配将与另一个机动性管理程序一起进行，例如作为跟踪区域更新的一部分。
5.4.1.2 GUTI 重新分配由网络发起
MME应通过向UE发送GUTI重新分配命令消息并启动计时器T3450来启动GUTI重新分配过程（见图5.4.1.2.1中的示例）。
GUTI再分配命令消息应包括GUTI，并可包括TAI列表或DCN-ID或两者。
图 5.4.1.2.1: GUTI 重新分配过程
GUTI应用举例
1、如何确定本用户的GUTI？
从终端日志查看GUTI一般在ATTACH ACCEPT或TAU ACCEPT中
1）展锐日志中的GUTI
（1）展锐空口日志ATTACH_ACCEPT中的GUTI：
9277-23 03:33:53.621 SIM2 FF <- ATTACH_ACCEPT
guti //解析见3GPP 24.301 9.9.3.12 EPS mobile identity
no_mobile_id = 0xb
mobile_id_size = 0xc
mobile_id
[0] = 0xf6 //GUTI
[1] = 0x64 // MCC MNC
[2] = 0xf0
[3] = 0x0
[4] = 0x4 //MME Group ID
[5] = 0x60
[6] = 0x80 //MME Code
[7] = 0xf5 //M-TMSI
[8] = 0xd5
[9] = 0x21
[10] = 0xfb
（2）展锐空口日志TRACKING_AREA_UPDATE_ACCEPT中的GUTI：
10569-108 03:34:57.437 SIM2 FF <- TRACKING_AREA_UPDATE_ACCEPT
guti
no_mobile_id = 0xb
mobile_id_size = 0xc
mobile_id
[0] = 0xf6
[1] = 0x64
[2] = 0xf0
[3] = 0x0
[4] = 0x4
[5] = 0x60
[6] = 0x80
[7] = 0xf5
[8] = 0x52
[9] = 0x89
[10] = 0x24
2）高通日志中的GUTI
（1）高通日志Attach accept中的GUTI（已经解析好了）
2022 Feb 16 10:03:42.967 [1B] 0xB0EC LTE NAS EMM Plain OTA Incoming Message -- Attach accept Msg
guti_incl = 1 (0x1)
guti
id_type = 6 (0x6) (GUTI)
odd_even_ind = 0 (0x0)
Guti_1111 = 15 (0xf)
mcc_1 = 4 (0x4)
mcc_2 = 6 (0x6)
mcc_3 = 0 (0x0)
mnc_3 = 15 (0xf)
mnc_1 = 0 (0x0)
mnc_2 = 1 (0x1)
MME_group_id = 39424 (0x9a00)
MME_code = 202 (0xca)
m_tmsi = 3862446943 (0xe638435f)
（2）高通日志Tracking area update accept中的GUTI
2022 Feb 16 10:03:56.817 [7C] 0xB0EC LTE NAS EMM Plain OTA Incoming Message -- Tracking area update accept Msg
guti_incl = 1 (0x1)
guti
id_type = 6 (0x6) (GUTI)
odd_even_ind = 0 (0x0)
Guti_1111 = 15 (0xf)
mcc_1 = 4 (0x4)
mcc_2 = 6 (0x6)
mcc_3 = 0 (0x0)
mnc_3 = 15 (0xf)
mnc_1 = 0 (0x0)
mnc_2 = 1 (0x1)
MME_group_id = 39424 (0x9a00)
MME_code = 202 (0xca)
m_tmsi = 4130882399 (0xf638435f)
（3）高通日志0xB0EE LTE NAS EMM State中的GUTI
2022 Feb 16 10:03:42.970 [FF] 0xB0EE LTE NAS EMM State
Subscription ID = 2
Version = 2
EMM state = EMM_REGISTERED
EMM sub-state = EMM_REGISTERED_NORMAL_SERVICE
PLMN_ID:
MCC digit 1 = 4
MCC digit 2 = 6
MCC digit 3 = 0
MNC digit 3 = 15
MNC digit 1 = 0
MNC digit 2 = 1
Guti valid = True
Guti {
Guti Ue Id = GUTI_ID
PLMN {
MCC digit 1 = 4
MCC digit 2 = 6
MCC digit 3 = 0
MNC digit 3 = 15
MNC digit 1 = 0
MNC digit 2 = 1
}
MME Group Id = { 0, 154 }
MME Code = 202
M TMSI = 0xE638435F
}
2、如何确定LTE中的PAGING是否在寻呼自己？
10439-209 03:34:51.636 SIM1 LTE FF <- PAGING
paging
pagingRecordList
ue-Identity
s-TMSI
mmec = '11011010'B
m-TMSI = '11001001000110001001110110000110'B
cn-Domain = ps
ue-Identity
s-TMSI
mmec = '11010110'B
m-TMSI = '11001101000010110000111111110110'B
cn-Domain = ps
如何确定该PAGING中有没有在寻呼自己？
最简单的方法是：如果UE紧接着有发起SERVICE REQUEST，则在RRCCONNECTIONREQUEST中的s-TMSI就是自己的，和PAGING中的s-TMSI进行比较就可以了。
S-TMSI可从终端发起service request时的
10439-249 03:34:51.639 -- FF -> SERVICE_REQUEST
10447-14 03:34:51.673 SIM1 LTE FF -> RRCCONNECTIONREQUEST
rrcConnectionRequest
criticalExtensions
rrcConnectionRequest-r8
ue-Identity
s-TMSI
mmec = '11010110'B
m-TMSI = '11001101000010110000111111110110'B
establishmentCause = mt-Access
spare = '0'B
如果没有SERVICE REQUEST，或有丢LTE PAGING的情况，在用另一台设备监听所有PAGING，则用上面确定本用户的GUTI的方法来确定有没有在寻呼自己，因为S-TMSI是GUTI的一部分。
1997
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
