你从一个世界来到我的世界-TAU下

2022-04-19 15:56:17 浏览数 (1)

好久不更了，转眼就到了2016年的尾声，好忧伤~

终于在最近的忙碌生活中断断续续的完成了TAU下的整理，希望来的还不晚~

之前我们已经赘述了4G的附着过程(关键字attach获取)，简单的整理了网络身份ID——GUTI、P-TMSI以及他们的mapping关系(关键字id获取)，然后讲述了4G中移动性管理的TAU上——4G内部的TAU消息(以Inter-MME with SGW change为例，关键字tau获取)；接下来我们继续简单赘述一下TAU的其他相关内容。

1

TAU分类

首先我们继续看一下整理的TAU类型图：

TAU上我们讲述了左边来自4G的TAU，今天我们赘述一下右半部分来自2/3G的TAU。

从图中我们可以看到来自2/3G的TAU只有两种类型，而关键就是是否到4G之后更换了核心网设备SGSN-MME。

为了更好的资源利用，网络部署和演进的过程中，自然要针对当前资源来发挥最大的作用才是王道，所以对于核心网资源的SGSN只处理2/3G业务自然而然的演进成为在4G中的SGSN-MME来处理2/3/4G业务。

2

TAU类型判断

那么一个三接入的SGSN-MME怎么判断一个TAU Request的类型呢？

这个时候就要从TAU Request消息细细分析提供的用户之前的信息了。

首先SGSN-MME看Request中的Old GUTI type，如下，Old GUTI Type有Native GUIT和Mapped GUTI两种类型：

如果是Mapped GUTI，就是一个来自于2/3G的TAU类型了。

然后MME开始查看Old GUTI，并根据3GPP 23.003的mapping关系来提取一组LAC-RAC对：

上图是不是很熟悉很美丽(就是网络ID里的图呀，我好懒，图就重复用，只因为画的漂亮呀)？

有朋友也许会有这样的问题，这是RAI/P-TMSI mapped到GUTI的图呀，MME应该用GUTI mapped到P-TMSI的图才对呀？其实我们说的mapping关系是UE的行为，UE根据mapping关系来封装消息，那么在网络节点解析的时候就要反用UE中的mapping关系。

所以根据上图的mapping关系，New MME从Old GUTI中提取MMEGID mapped到LAC，提取M-TMSI的23-16bit位mapped到RAC，构成LAC-RAC对，New MME进行对其进行本地LAC-RAC表匹配检测(LAC-RAC表？我自己给起的名字，就是SGSN服务区下的2、3G位置信息)。

如果可以匹配上，那么就是类型7.ISC-Intra SGSN-MME TAU(without SGSN-MME changed)；如果没有匹配上，那么就是类型6.ISC Inter SGSN-MME TAU(with SGSN-MME changed)，此时MME需要构建RAC FQDN并发送DNS请查询SGSN Gn IP(我们这里主要说Gn based的网络)。

3

来自2/3G TAU的网络拓扑

来自2/3G TAU的网络拓扑如下：

上图是一个跨SGGN-MME的ISC-TAU拓扑图，从图中我们不仅可以看到即将要发送的TAU，还可以看出什么猫腻呢？

有两点：

  1. 信号覆盖问题：2/3G信号完全可以跟4G信号有交集，甚至重叠。
  2. 关于GGSN/PDN GW的问题：在讲述4G内部TAU的时候最后提了一个问题，是关于TAU时不管是更换MME也好还是更换SGW也好，但是就是不会换PGW，从而保证了用户整个Session的连贯性一致性。 那么从2/3G到4G的TAU要怎么办呢？从图中可以发现，GGSN和PGW是要合设的，从而解决Session的连贯性问题。

4

Type6.ISC Inter SGSN-MME TAU信令简析

当用户本来注册在2/3G小区内，水往低处流，人往高处走，而对于终端来说也是要往高处走的，所以当终端探寻到4G信号之后，迅速发起TAU请求，信令图如下：

其实整个信令具体内容跟上一篇TAU的信令内容没有太大的出入，只是在一些前期跟MME、MME跟SGSN交互的内容自然不同：

  1. 终端搜索到4G信号，一下子兴奋了：终于可以摆脱2/3G的破速度，4G，俺老孙来也！
  2. 终端封装TAU Request消息到NAS中，包括：自己的Old GUTI、Old GUTI Type(mapped GUTI)、在2/3G时的P-TMSI signature以及至少一个Active Bearer的flag等信息：么么哒，亲，我千辛万苦来找你了~
  3. eNodeB封装用户当前位置信息TAI(TA1)、ECGI等到S1AP中，然后转发终端的NAS消息到New MME。
  4. New MME通过Old GUTI Type判断此用户为2/3G升级上来的，迅速从mapped Old GUTI提取LAC-RAC对，并进行本地表匹配，木有匹配成功，那么构建RAC FQDN进行DNS 查询，DNS返回Old SGSN Gn IP。
  5. New MME拿到Old SGSN Gn IP之后，将Old GUTI mapping回P-TMSI，然后封装P-TMSI signature之后发送SGSN Context Request到Old SGSN索要此用户的信息包括MM(Mobility Management) Context。
  6. Old SGSN收到SGSN Context Request之后开启定时器用来控制何时删除此用户的Context信息，并将用户信息告知New MME，包括MM Context、所有PDP Context，以及GGSN即PGW的FQDN(后边会解释^_^)。
  7. New MME可能会发起对用户合法性的验证，包括对HSS的AIR/AIA消息来获取鉴权向量等消息，以及和终端的Authentication/Security消息来完成双向鉴权，并完成加密算法等的协商(具体可以参考4G初始附着流程，可关注后回复attach获取)。
  8. New MME构建用户当前所在区域的TAI FQDN，并进行DNS查询得到服务于此TAI的一系列SGW。
  9. New MME在此时可能回复SGSN Context ACK给Old SGSN。
  10. 一切准备就绪了，New MME针对用户的Active Bearer Flag信息开始发起Create Session Request到New SGW并且包含有之前PDN的context和PGW信息。
  11. New SGW通过Modify Bearer Request消息将自己的信息更新给PGW。 11a，如果使用了PCC，PGW收到更新请求之后，将发起到PCRF的IP-CAN Session的更新。
  12. PGW将更新后的消息如Charging ID，S5/S8-U IP/TEID等response给SGW。
  13. New SGW更新自己的Bearer Context之后回复Create Session Response给New MME，其中包括自己的C面信息如IP和TEID，也包含了U面的S1-U IP和TEID信息。
  14. New MME通过Update Location Request消息通知HSS针对此用户MME已经改变的事实。
  15. HLR/HSS得到最新消息之后给Old SGSN发一条带有IMSI和Cancellation Type为Update Procedure Flag的Cancel Location信息。
  16. 如果第6步的定时器没有开启，此时Old SGSN删除用户Context，否则则等待计时器超时才删除用户信息；不管是否删除用户信息，Old SGSN都将回复Cancel Location ACK给HLR/HSS。
  17. HSS通过Update Location ACK回复IMSI/Subscriber Data信息给New MME。
  18. 于此同时，由于终端发起的是Combine TAU，New MME此时发起到MSC的Location Update Request。
  19. MSC收到消息之后发起CS域的各种更新，并分配一个CS域的TMSI给用户。
  20. 然后MSC将分配的TMSI通过Location Update Accept消息回复给New MME。
  21. 到此如果没有任何意外，TAU的主体流程基本完成，New MME分配一个New GUTI给终端用户标志了TAU的已经走完了90%的里程，接下来New MME将信息同步给eNodeB和终端即可，因此到终端的TAU Accept消息诞生，包括了给终端的New GUTI，New TA List，网络侧能力，和给eNodeB的SGW的S1-U IP和TEID。
  22. 终端终于完成了跟目前商用最尖端的网络4G的对接，并获得了4G的网络接入资格：多谢收留，TAU Complete啦~

到此一个ISC Inter SGSN-MME TAU完成，终于不用再在龟速的2/3G中堵车了，速度真好，横着走都可以，就是一个爽~

5

可能存在的问题

毕竟跨界的事不容易，适配等等问题都不容忽视，而2/3G和4G的位置更新涉及到的最大的问题就是Session的连续性，如何保证4G中选择的PGW就是2/3G中的GGSN是各个厂商都要解决的问题。

  1. 首先要保证GGSN和PGW是合设的，这个是大前提，非合设，自然会出错。
  2. 就是MME选择的PGW如何就是2/3G中的GGSN呢？目前知道的两种办法：
    1. 如信令中第6步所说，Old SGSN返回给New MME的context中包含有GGSN/PGW的FQDN，那么就证明此GGSN有PGW的能力而且被此用户使用。 但是问题来了，我们知道2/3G的时候在选择GGSN的时候只需要一个最简单的基于APN的A查询即可，如果要得到FQDN必然要进行NAPTR查询。 所以此办法就要有三个前提：
      1. 2/3G的DNS中定义针对GGSN即PGW的NAPTR等相关查询。
      2. SGSN支持针对APN的NAPTR查询。
      3. 终端要告知SGSN自己有4G能力，需要对我发起业务的APN进行NAPTR查询。
    2. 另一种解决办法就是Old SGSN在回复SGSN response消息里包含一个特殊字段GGSN initial IP即A查询的时候得到的GGSN IP。

    然后MME进行APN的NATRP查询得到一系列PGW的FQDN和对应的IP，并跟从SGSN得到的GGSN initial IP一一匹配从而得到一个Combine GGSN/PGW的节点。

但是不管怎样，只要在位置更新时保证GGSN/PGW不换是唯一宗旨。

以上TAU的内容就简单赘述完毕，在各个厂家的信令处理上会略有不同，我们就见招拆招，兵来将挡水来土掩，以不变应万变~

tcp/ip http 网络安全 dns

0 人点赞