看包详解带3GDT的PDP上下文激活流程

admin

yonka 发表于 2012-9-24 22:34
In case of a pre-release 7 GGSN, error indications from the RNC are treated as if they came from the ...

这段话是这么理解的：

预置条件：

1）基于3GDT的PDP上下文已经激活。

2）UE开始发送和接收数据，RNC和GGSN之间传送用户数据。

3）GGSN发送下行数据给RNC，但RNC发现没有对应的RAB对应。RNC丢弃该GTP-U PDU并通过GTP-U的Error Indication通知GGSN。

- 这时，如果该GGSN是3GPP R7版本之前的，那么它是不支持3GDT的（3GDT是在3GPP R7才有的）。因此，RNC送过来的用户面error indication，GGSN仍将认为是SGSN送过来的（因为R7之前的GGSN认为控制和用户面都是和SGSN通信，而没有RNC），因此既然认为是SGSN送过来的，那自然不会再通知SGSN了。这样就可能导致该PDP上下文已经在GGSN侧被释放，而SGSN侧由于没有得到任何通知，所以还认为这是一个有效的PDP上下文。这就叫hanging的PDP上下文。SGSN和GGSN上的状态不同步了。

- 如果该GGSN是3GPP R7之后的，那是支持3GDT的，所以能够分别出该错误指示是RNC发过来的。因此，GGSN将通知SGSN做相应的处理，PDP上下文不会释放。但SGSN收到通知后会将RAB释放掉。

admin

admin 发表于 2012-9-25 20:39
这段话是这么理解的： 预置条件： 1）基于3GDT的PDP上下文已经激活。 2）UE开始发送和接收数据，RNC和GGS ...

不好意思，上面的说法有点不正确。文字已经更正。

查了下规范23007，这种场景下RNC发送error indication，并不是RNC的用户面出现了什么问题。而是RNC收到了下行方向GGSN侧的用户数据，但某种原因RNC侧的RAB已经释放了，RNC采取的操作时丢弃该下行数据并发送error indication给GGSN。通过该指示，还可以通知GGSN fallback到非3GDT的环境下。原文如下：“

When the RNC/BSC receives a GTP U PDU for which no RAB context exists, the RNC/BSC shall discard the GTP U PDU and return a GTP error indication to the originating node that may be SGSN or GGSN if Direct Tunnel is established.”

如果是SGSN的话，SGSN也应丢弃该下行PDU并发送error indication通知GGSN。“When the SGSN receives a GTP U PDU from the GGSN for which no PDP context exists, it shall discard the GTP U PDU and send a GTP error indication to the originating GGSN.”

GGSN也是一样的。“When the GGSN receives a GTP U PDU for which no PDP context exists, it shall discard the GTP U PDU and return a a GTP error indication to the originating node (the SGSN or, if Direct Tunnel is established, the RNC).”

如果是UE正在发送上行数据的情况下出现了这种事，那GGSN将通知SGSN错误指示，SGSN将因此去激活PDP上下文，MS也要去激活PDP上下文。原文：“When the GGSN receives a tunnel PDU for which no PDP context exists it discards the tunnel PDU and sends an Error indication message to the originating SGSN. The SGSN deactivates the PDP context and sends an Error indication to the MS. The MS may then re-activate the PDP context.”