51学通信技术论坛

标题: 1.3 E-UTRAN内的TAU（SGW和MME均变化） [打印本页]
作者: 爱卫生    时间: 2012-8-23 11:44:18     标题: 1.3 E-UTRAN内的TAU（SGW和MME均变化）

本帖最后由 爱卫生 于 2012-8-23 11:45 编辑

项目标题

RAU/TAU

分项目标题

移动用户处于E-UTRAN ECM-IDLE状态，进入非TA list的新TA中的TAU，Serving GW改变

测试目的

验证MME正确处理ECM-IDLE状态下UE发起的TAU，Serving GW改变。

测试预置条件

1)  EPS网络中各网元系统及操作维护台运行正常。

2)  用户已经签约EPS业务。

3)  UE已经附着，并处于 ECM-IDLE状态。

4)  在MME上建立S1接口跟踪，用户跟踪，GTPC跟踪。


测试步骤

1) UE移动到另一个TA中，该TA不属于原来的TA List。

2) 在网络侧查询用户的信息。

检查点

1) TAU是否成功。

2) 新侧和旧侧MME中用户的信息。

3) 消息跟踪是否能够跟踪到相应的消息，流程是否正确。

测试结果

1) TAU成功，New MME选择了一个New Serving GW。

2) Old MME中没有用户的信息。New MME中用户EMM状态为EMM-REGISTERED。

本例中说的场景是一个用户，本来属于TA List1，该TA List1包含TA1、TA2和TA3，但现在UE移动到了TA4，不属于当前的TA List，并且TA List1和TA4属于不同的MME管辖。并且发现到了TA4以后，有一个离用户更近的SGW可以为UE提供服务，这时候这种TAU涉及到MME的变更，但且需要发生SGW的重选。也就是“移动用户处于E-UTRAN ECM-IDLE状态，进入非TA list的新TA中的TAU，Serving GW和MME均变化”。这应该算是ECM-Idle状态下TAU最复杂的一种场景，但也非常普遍。

信令流程图如下：

[attach]1367[/attach]

1) UE发送TAU Request消息给New MME，发起TAU流程。TAU Request消息中将包含Old TAI，并且在S1AP消息中将包含当前的TAI以及ECGI。另外，还会包含Old MME分配的GUTI。

2) New MME首先要根据UE提供的GUTI得到Old MME的MMEC，并据此向DNS发起查询请求解析Old MME的IP地址。得到结果后发送Context Request消息给Old MME，消息中包含UE的GUTI以及Old TAI信息。Old MME返回Context Response消息，携带MM和Bearer上下文（如果UE仍有active Bearer的话），MM上下文中会包含没有用完的安全向量方便New MME对UE进行鉴权（不需要通过S6a接口去向HSS请求了）。Old MME启动一个定时器（用于后面的第7步）。

3) 如果Old MME没有返回安全向量，则New MME向HSS发送Authentication Information Request(IMSI)，HSS响应Authentication Information Answer消息，携带EPS安全向量。

4) New MME发起安全流程。

5) New MME发送Context Acknowledge消息给Old MME。

6) New MME通过TAI做为查询条件向DNS发起查询请求，DNS返回了New SGW的IP地址即帮助UE重新选择了一个新的Serving GW，New MME向New Serving GW发送Create Session Request消息，创建承载。

7) New Serving GW向PDN GW发送Modify Bearer Request消息，更新下行方向信令面和用户面的IP和TEID，PDN GW返回Modify Bearer Response更新成功。

8) New Serving GW向New MME发送Create Session Response消息，创建承载成功。

9) New MME向HSS发送Update Location Request消息更新位置，HSS收到消息后发送Cancel Location Request给Old MME，Old MME响应Cancel Location Answer，并当前面（第2步）的定时器超时之后删除用户上下文，HSS响应Update Location Answer，该消息里包含了签约数据。

10) Old MME当前面的定时器超时之后，向Old Serving GW发送Delete Session Request，指示Old Serving GW删除本地承载，不需要通知PDN GW，Old Serving GW发送Delete Session Response，删除承载成功。

11) New MME发送TAU Accept响应UE。该消息中包含了当前TAI、新分配的GUTI以及T3412参数值。需要注意：这个TAU Accept消息是封装到S1AP消息中发给eNB的。在S1AP消息中，New MME会将New SGW通过"Create Session Response"消息分配的用于上行方向用户面的TEID和IP地址通知eNB。这样eNB就可以将上行的用户面报文发送给New SGW。

12) 如果GUTI重新分配了，UE响应TAU Complete消息。


作者: ithinc    时间: 2013-3-10 15:31:19

第6步，如果存在多条PDN Connection的情况下，一条PDN Connection的default bearer在UE侧已经inactive，这条PDN Connection要怎么处理呢？23401里没有提及，比较困惑。
作者: admin    时间: 2013-3-11 14:33:45

如果是多PDN Connection的话，那每个PDN连接都需要有一个default bearer。所以，必须要都保持住的。另外，如果是inactive的状态，从会话管理EPS Bearer的角度看，这个EPS Bearer还是active的。你说的inactive应该是S1和radio bearer，这时候就看UE在TAU Request里有没有带active flag，如果带了的话，S1和空口的承载也会被激活。
作者: admin    时间: 2013-3-11 21:31:23

admin 发表于 2013-3-11 14:33
如果是多PDN Connection的话，那每个PDN连接都需要有一个default bearer。所以，必须要都保持住的。另外，如 ...

想请教下"UE在脱网状态下删除部分PDN Connection"这句话，有两个问题。请指教，谢谢。

1）脱网状态是指丢失了无线侧连接很长时间吗？

2）即使如第一种情况下丢失了无线侧连接很长时间，但这个PDN连接应该还是保持的吧。并没有一个UE侧的timer说超时就要删除PDN连接啊。

所以暂时还没想到这种场景。

作者: hycl5410    时间: 2013-3-12 10:38:38

9.9.2.1        EPS bearer context status
The purpose of the EPS bearer context status information element is to indicate the state of each EPS bearer context that can be identified by an EPS bearer identity.

实物可能比较难测，模拟器会比较容易。

个人理解，TAU的时候，MME不做任何操作，不告诉SGW也不在内部删除bearer等。如果以后存在冲突/状态不一致，比如UE对该PDN重新发起PDN connection流程，那么MME仍然可以先delete session再create session。相关描述可以参考23.401(rel a80) initial attach流程. 虽然场景和用法不是那么一样，但是感觉思路是一样的。其实23G下类似的事情也都是这么处理的，先delete再create pdp


7.        If there are active bearer contexts in the new MME for this particular UE (i.e. the UE re-attaches to the same MME without having properly detached before), the new MME deletes these bearer contexts by sending Delete Session Request (LBI) messages to the GWs involved. The GWs acknowledge with Delete Session Response (Cause) message. If a PCRF is deployed, the PDN GW employs an IP-CAN Session Termination procedure to indicate that resources have been released.
作者: ithinc    时间: 2013-3-12 12:34:07

本帖最后由 ithinc 于 2013-3-12 12:47 编辑
admin 发表于 2013-3-11 21:31
想请教下"UE在脱网状态下删除部分PDN Connection"这句话，有两个问题。请指教，谢谢。1）脱网状态是指丢失 ...

假设把手机放在铁盒子里10秒钟，在这10秒钟内关闭了之前激活的若干应用程序，这样手机就可以删除某些PDN连接了吧。不管怎么说，UE与MME不同步的情形是有的，24.301也有详细描述。我的问题是在23.401 v10.8.0 Section 5.3.3.1 Step 8，已经请教过Huawei开发人员了，大家先讨论。


作者: ithinc    时间: 2013-3-12 18:23:51

你是说Step 8写的很清楚？我是说Step 8的描述有些模糊点。

The MME releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer context at all, the MME rejects the TAU Request.

Dedicated bearer inactive可以推测在Create Session之后执行MME initiated dedicated bearer deactivation。
Default bearer inactive怎么操作是模糊不清的。
作者: hycl5410    时间: 2013-3-12 21:55:19

本帖最后由 hycl5410 于 2013-3-12 22:02 编辑
ithinc 发表于 2013-3-12 18:23
你是说Step 8写的很清楚？我是说Step 8的描述有些模糊点。

The MME releases any network resources rel ...

default bearer还能怎么操作？向旧SGW发delete session呗。。。并且指示需要发向PGW。default bearer都没了，PDN就会被disconnect掉。由于是UE指示的default bearer inactivate，所以就不会有NAS的PDN disconnect消息了，只向SGW PGW发delete session即可。
default bearer如果被UE inactivate了，那MME就不会再去查DNS并匹配SGW/PGW了，也就不会有新SGW。


作者: hycl5410    时间: 2013-3-13 13:35:45

不是想当然。多PDN情况下，一样可以发送delete session，delete session里可以带EPS-BEARER-ID.
口说无凭，有包为证。
作者: wenliu    时间: 2013-3-13 14:43:57

本帖最后由 wenliu 于 2013-3-13 14:53 编辑

ithinc 认为是在TAU 过程中 new MME 不能向 old SGW 发送Delete Session。  和你包里的情况有所不同。

TAU之后，虽然new MME最先被同步到UE侧的bearer情况，但是它是否应该先维持从老的 MME得到的context 的status呢？

在这种时候，UE 侧和网络侧的context 可能不同步：
1。 那这时候new MME就在TAU过程中直接发送delete 给SGW 来释放Default bearer么？
2.   还是new MME虽然收到UE侧有些bearer 是deactive的情况，但是为了保证网络侧一端的切换的同步性，还是尽量将TAU前后网络侧的context 先同步，随后再进行释放工作。
晓得ithinc是QQ哪位了。之前在QQ里讨论过。
我的想法，虽然MME收到UE 某些 bearer 是 inactive了，但是还是应该先保证TAU过程中 网络侧的 context 的一致性。这样网络侧出错的机会最小。随后根据UE的情况，再发起 去激活某些default bearer的过程。 “先保证一侧的同步，随后将不同步的部分删除。“

作者: hycl5410    时间: 2013-3-13 15:42:55

wenliu兄的想法与我最初的想法是一致的，详细可以见我5楼的回复。
但是ithinc兄拿出23.401 v10.8.0 Section 5.3.3.1 Step 8的描述，我觉得这个描述就很清楚了。

The MME releases any network resources related to EPS bearers that are not active in the UE.

ithinc兄纠结的地方不是要不要release，而是如何release，尤其是存在多PDN的default bearer情况下。

于是我在8楼回复，对于inactivate的PDN的default bearer，MME release的方式是向SGW/PGW发送delete session

ithinc兄在8楼点评的观点是，对于多PDN的情况，MME向SGW发送delete session会影响到其他PDN的default bearer。

我在9楼的抓包是证明，delete session不会对其他PDN的bearer造成影响。

确实我在9楼的抓包不是ithinc兄描述的场景，并且我也没有条件复现这种情况并抓包。当然我更希望ithinc兄拿出这种情况的抓包来给出结论。

不管怎样，讨论的过程非常有趣，个人觉得受益颇多。感谢各位~
作者: ithinc    时间: 2013-3-13 16:56:24

本帖最后由 ithinc 于 2013-3-13 19:43 编辑

我是说新MME不能向旧SGW发Delete Session，不是说MME不能向SGW发送拉。我已经知道Huawei是怎么做的了，大家讨论一下可以给其他人帮助。

两个路径：
1。old MME -> old SGW -> PGW
2。new MME -> new SGW -> PGW

大家可以把23.401里以下章节拿来比较，对问题会更为清楚。
Section 5.5.1.1.2 Step 2
Section 5.5.1.1.3 Step 2
Section 5.5.1.2.2 Step 15

作者: wenliu    时间: 2013-3-13 17:31:10

“The MME releases any network resources related to EPS bearers that are not active in the UE”

对于这段描述，也的确有点不清，但是我想应该是具体如何实现的问题。

MME 将这些RELAY给SGW,和PGW ， 那PGW 收到这些inactive的context ，

1. 是否将这些归于active 处理呢（随后通过delete释放），但是这样的话 PGW分配出来的TEID真的会去占用部分资源。
2.还是只是回个虚假的TEID，分配出来的TEID只是为了让MME 完成网络侧有关这个TAU切换。
作者: hycl5410    时间: 2013-3-13 21:10:29

ithinc 发表于 2013-3-13 16:56
我是说新MME不能向旧SGW发Delete Session，不是说MME不能向SGW发送拉。我已经知道Huawei是怎么做的了，大家 ...

非常感谢！
终于搞清楚了。
新MME发向新SGW的create session是可以带BearerContexts to be removed的
TS 29.274

This IE shall be included on the S4/S11 interfaces for theTAU/RAU/Handover cases where any of the bearers existing before theTAU/RAU/Handover procedure will be deactivated as consequence of theTAU/RAU/Handover procedure.

For each of thosebearers, an IE with the same type and instance value shall be included.


old MME发给old SGW的delete session终止在SGW（SGW change indicator in context-ack sent in s10 interface）。此步骤跟bearer context状态无关，只要SGW变了就会发。delete session per PDN。

新MME不能向old SGW发送delete session，尽管新MME知道old SGW的一切信息。因为如果发了delete session，后续old MME也要向old SGW发送delete session，这样就会导致old MME收到类似no exist一类的异常消息。
作者: hycl5410    时间: 2013-3-13 22:46:46

本帖最后由 hycl5410 于 2013-3-13 22:55 编辑

在思考这个问题的同时，我又想到另外一个有意思的问题：

预置条件：
SGW1与PGW1共节点，
SGW2与PGW2共节点，
SGW与PGW均可匹配成功且连通ok
SGW1服务TA1和TA2，
SGW2仅服务TA2
UE在TA1下激活两个APN--APN1 APN2，
APN1激活于SGW1 PGW1
APN2激活于SGW1 PGW2
MME1仅服务TA1，
MME2仅服务TA2。

问题：
当UE从TA1切换到TA2时，APN2一定会从SGW1切换到SGW2。那么APN1是否也一定会做SGW的切换（SGW1也是可以服务TA2的哦~）？

请感兴趣的同学分析作答并解释原因。

参考文献为TS 23.401和TS 29.274,线索就在14楼。
作者: ithinc    时间: 2013-3-14 12:15:53

hycl5410 发表于 2013-3-13 22:46
在思考这个问题的同时，我又想到另外一个有意思的问题：

预置条件：
当UE从TA1切换到TA2时，APN2一定会从SGW1切换到SGW2。那么APN1是否也一定会做SGW的切换（SGW1也是可以服务TA2的哦~）？

这个结论似乎是不确定的，我没看出有什么理由一定要切换SGW。一个用户只会使用一个SGW，并不会只切一个APN。

作者: hycl5410    时间: 2013-3-14 16:02:56

两个PDN,create session时Bearers to be Created填一个，inactive的那个被remove。
这样一条信令干两件事情好像也有点说不过去，毕竟协议也说create/delete session是per PDN的。

不这样搞那就只能先create再delete了，虽然看起来麻烦很多。。。

或者这么考虑，只有一个PDN一个default bearer，TAU时bearer-status什么都不带，新MME确实也没法发create session带被remove的EBI。那就只能先create再delete了。
作者: ithinc    时间: 2013-3-15 11:01:57

为什么要强制使用一个SGW呢？有没有想过？

我以为不需要想，你这么一说我糊涂了。
作者: ithinc    时间: 2013-3-15 11:06:53

hycl5410 发表于 2013-3-14 16:02
两个PDN,create session时Bearers to be Created填一个，inactive的那个被remove。
这样一条信令干两件事情 ...

最新的29.274 v11.5.0澄清了Modify Bearer Request里的类似问题，non-GBR (default) bearers to be removed必须放在Bearers to be Modified中，用户面F-TEID用假的。
作者: hycl5410    时间: 2013-3-15 22:47:48

本帖最后由 hycl5410 于 2013-3-15 23:17 编辑
ithinc 发表于 2013-3-15 11:01
我以为不需要想，你这么一说我糊涂了。

inter MME切换场景。
如果不限制一个UE的多个PDN必须在同一SGW上，那么理论上是存在这样一种可能的：
1）切换前，APN1激活于SGW1 PGW1， APN2激活于SGW2 PGW2
2）新MME查询DNS，匹配合适的SGW PGW对
3）新MME决定APN1匹配对为SGW1 PGW1，APN2为SGW1 PGW2 （*.tac.epc......配置很常见的吧,一般回的list里也不会只有一个SGW node吧）

问题就来啦，context acknowledge里的SGWCI怎么设？一个变了一个没变，这个字段又不是per bearer的。


当然啦，以上说法都是瞎猜，可能是牵强附会而已，深层次的设计思路没有抓住。
没准强制UE使用同一SGW是因，SGWCI不per bearer是果呢（没必要分啦）

从Indication flags字段结构看呢，SGWCI只占一个bit就够了，倒确实省地方。。。

作者: maqizhao    时间: 2014-11-25 16:15:24

谁知盘中餐,发帖真辛苦！
作者: aceworld    时间: 2015-2-7 15:43:44

本帖最后由 aceworld 于 2015-2-7 15:45 编辑
hycl5410 发表于 2013-3-13 13:35
不是想当然。多PDN情况下，一样可以发送delete session，delete session里可以带EPS-BEARER-ID.
口说无凭， ...

hycl5410 ，您好：
   我看了您上传的这个报文了，这个报文中第8，第21，第47条报文，这三个是同一个用户的三次Create Session Request ：


   1.为什么三个S11 MME GTP-C 的Teid都是一样的？


   2.第8和第21个报文是访问不同的APN，分配相同的S11 MME GTP-C  Teid，后面操作的时候怎么分清是哪个APN的动作吗？

   3.第21条报文之后有Delete Session的动作，但是在第47条报文的时候，又分配了跟第21条相同的S11 MME GTP-C Teid，MME对Teid的分配策略是什么？


可能有些问题问的比较浅显，但是我真的不知道，希望能得到答复。谢谢。[attach]3760[/attach][attach]3760[/attach]
作者: hycl5410    时间: 2015-2-26 09:53:20

aceworld 发表于 2015-2-7 15:43
hycl5410 ，您好：
   我看了您上传的这个报文了，这个报文中第8，第21，第47条报文，这三个是同一个用户 ...

这是一个UE激活多个PDN的场景。
第8个包是建立第一个PDN（APN）连接，第21个包是另外一个PDN（APN）连接。

然后就又回到之前说的事情了，一个UE的多个PDN必须要在同一个SGW上。因为从抓包看，MME与SGW之间的S11-C，对于一个UE来说，就只有一个tunnel，该UE内不同PDN实际上是通过EPS-beaer-ID来区分的。

注： PGW S5S8-C对于不同的PDN显然是必须要有不同的TEID的。




欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/) Powered by Discuz! X2