通信｜我是谁？网络ID之我的外号们(P-TMSI、GUTI、5G-GUTI)有关系吗？

那么P-TMSI、GUTI、5G-GUTI到底有没有关系？有怎样的关系呢？又为什么要有这样的关系呢？

今天就来聊一聊（文末有点儿料！！！）。

各个临时ID之间的mapping关系

我们已经知道了在2/3G中用户的临时ID为P-TMSI，4G中临时ID为GUTI，5G中的临时ID为5G-GUTI，因为移动通信的移动性，那么终端用户必然不会静止不前，而在位置移动的过程中，由于信号强弱和覆盖面积等等问题，就会出现在大商场用的5G，结果走到地下车库就只有4G了，再往角落走一走，肯能只有2/3G了，正所谓我的地盘用我的ID，所以在不同网络覆盖的地方必然要使用对应网络的临时ID才可以。

但是由于不同网络之间的临时ID是不一样的，如何才能保证用户移动性管理中的用户会话连续性呢？正所谓上有政策下有对策，你有张良计我有过墙梯，3GPP制定的过程中也规范了在各个系统间切换过程中各个临时ID的mapping关系。

RAI/P-TMSI到GUTI的mapping

当用户从2/3G移动到4G网络发起Request(Attach、TAU等)，首先手机终端需要将2/3G所得到的RAI/P-TMSI转换成4G的临时ID——GUTI，规则如下：

作为网络标识的PLMN——MCC+MNC不改初衷，自然填充到GUTI中的MCC+MNC位。

RAI中的LAC转换成GUMMEI中的MMEGID，而MMEC则由P-TMSI中的23-16位来填充：这个时候如果SGSN in pool的话，那么23-16位就是部分NRI了，因为标准来说23bit到14bit共10bit都可以是NRI，这就回到了之前问题位了保证NRI可以完全map到MMECode，NRI长度在真正使用中应该被最大设定为8Bit，保证跟MMECode的长度一致。

RAI中的RAI则填充了M-TMSI中的23-16bit位，M-TMSI中剩余的bit位则由P-TMSI中剩余的bit位来填补。

为了区别从2/3G LAC mapped的MMEGID和MME中真实配置的MMEGID的不同，3GPP中规定了LAC的最高bit位需要为0，而MMEGID的最高位为1。然而由于2、3G的过早问世，所以早已经有LAC的最高bit位为1，那么索性就可以放弃最高位1和0的纷争，只要能保证一个网络中的LAC和MMEGID不重叠即可(网络规划的时候要特别注意:-D)。

对于New MME而言收到一个带有mapped GUTI的用户请求，需要将mapped GUTI在转化为RAI/P-TMSI从而得到Old SGSN的信息，最后通过本地配置或者DNS查询得到Old SGSN的IP，然后New MME即可以向Old SGSN索要此用户的IMSI等相关信息。

GUTI到RAI/P-TMSI的mapping

当MME收到一个使用Mapped GUTI的UE请求（如TAU），MME需要将这个Mapped GUTI转换回RAI/P-TMSI；当用户附着到4G之后移动到2/3G的网络辖区下，UE也需要首先完成GUTI到RAI/P-TMSI的转换然后发送request给SGSN，GUTI到RAI/P-TMSI的转换规则如下：

从图中我们可以看到，MCC/MNC作为网络标示，不管是4G还是2/3G保持不变，其他的ID：

• MME的Group ID——MMEGID转换成了RAI中的LAC。
• MMEC不仅仅转换成了RAI中的RAC，同时也填充到了P-TMSI的23-16bit（如果SGSN Pool功能开启，这个就是NRI的位置）。
• M-TMSI作为MME分配的随机ID将29-24和15-0bit位对应到了P-TMSI的29-24和15-0bit位，mapped P-TMSI的31和30两位依照标准直接置为1。
• 同时M-TMSI的23-16bit位填充给了P-TMSI signature的23-16bit位，而P-TMSI signature的15-0bit位则由终端用户用其可信赖的NAS-Token来填充(3GPP 33.401)。

当New SGSN收到用户的Request之后通过mapped RAI/P-TMSI提取出Old MME信息，通过本地配置或者DNS查询得到old MME的IP后向old MME发起索要用户信息如IMSI的请求，而Old MME此时再将mapped RAI、P-TMSI和P-TMSI signature对应回GUTI以匹配自己所保存的用户信息。

GUTI和5G-GUTI的mapping

首先说明一点，如果说GUTI纯纯指的是4G里的概念，而5G里一定要说5G-GUIT。

当用户在4G和5G间移动，GUTI和5G-GUTI就需要有对应的mapping关系，这两个ID的比特位一样，所以mapping关系相对容易，规则如下：

比较复杂的部分就是GUMMEI和GUAMI的mapping，其中网络标识PLMN的MCC和MNC直接映射，我们重点说一下MMEID和AMFID的mapping关系：

从4G到5G，UE需要将MMEGroupID和MMECode进行拆分，重新组合：

• MMEGID的高8比特位映射到ARI(AMF Region ID)；
• MME GID的低8比特位和MMEC的高2比特位，共10比特位映射到ASI(AMF Set ID)；
• MMEC的低6比特位直接映射到AP(AMF Pointer);

从5G到4G，需要将AMF Set ID进行拆分后和AMF Region ID以及AMF Point组合后map到MMEID：

• ARI的8比特位和ASI的高8比特位，共16比特位映射到MMEGID；
• ASI的低2比特位和AP的6比特位，共8比特位映射到MMEC；

最后4G的M-TMSI和5G的5G-TMSI因为都是32位的TMSI，可以直接互相映射。

以上就是2/3G到4G以及4G到5G的临时ID之间的映射关系，如果想从2/3G直接映射到5G，需要以4G的ID为中间件进行转换。

因为各个临时ID相对完美的对应关系，终端在网络移动的过程中就可以畅通无阻的完成无缝衔接，从而保证一次开机后的用户会话的连续性。

当然ID仅仅是一个开始，在移动过程中还需要一系列的验证和交互从而达到会话的连续。

以上就是数据核心网中的用户身份ID的简单介绍和至关重要各个临时ID的对应关系，内容参考以下3GPP整理：

• 3GPP 23.003——Numbering, addressing and identification
• 3GPP 23.236——Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes
• 3GPP 33.401——System Architecture Evolution (SAE); Security architecture

在2/3/4/5G移动的过程中，我们经常需要在GUAMI、GUMMEI和NRI等ID间进行换算，从而做出准确的网络规划，或者完成DNS配置，亦或者来证实请求是否来自正确的网络，从而能快速的进行网络规划配置、问题分析、信令包解析等，而这些ID之间有着很明确的对应关系，因此在Windows下，我使用C#写了一个名叫ngg的工具，所谓ngg就是NRI、GUMMEI和GUAMI的首字母，已经作为开源项目发布到我的Github中，欢迎下载使用，源码地址如下：

• https://github.com/MinpuKang/nri-gummei-guami
• 直接可运行的exe文件在bin/Release/下。