Gb Over IP中IP Endpoint变更的几种场景及实例(Resource Distribution for IP)

爱卫生

  本帖来自3GPP 规范TS48.016 V8.0.0的附录B，Recommended usage of Resource Distribution for IP。主要介绍了在Gb Over IP的环境中，如果通信的双方即BSS和SGSN之间，如果某一方或双方需要同时进行IP Endpoint的变更，则对应有4种典型的场景。将分别介绍如下。
  先看两个术语：
NS SDU Control bits ：用于控制IP Endpoint变更的控制bit
R-bit = Request Change Flow bit  置1代表请求进行IP端点的变更
C-bit = Confirm change flow bit  置1代表对IP端点变更请求的确认，确认后将按变更后的路径进行数据发送。
LSP: Link Selector Parameter 用于IP端点间的负荷分担目的。
Example 1: Both NS entities trigger resource distribution (refer to figure B.1).如果通信双方都需要变更IP Endpoint
  The BSS receives an uplink LLC PDU from the mobile and creates a mobile context. Now the BSS selects the source IP/UDP1 endpoint (internal implementation dependent) and a destination IP/UDP3 endpoint (IP load sharing dependent) on which to send NS SDUs associated with the mobile.
  The BSS sends the uplink NS-UNITDATA (with R-bit set and the LSP corresponding to the IP endpoints selected) to the SGSN from IP/UDP1 to IP/UDP3. On receipt of uplink NS-UNITDATA for the mobile the SGSN may also choose to change the IP endpoint at which it wishes to receive uplink NS-UNITDATA for the mobile to IP/UDP4. The SGSN responds by sending a downlink NS-UNITDATA with R-bit and C-bit set to 1 from the IP/UDP4 at to IP/UDP1.
  Subsequent uplink and downlink NS-UNITDATA for the mobile shall follow the dotted path (IP/UDP1 and IP/UDP4) through the IP sub-network.
  BSS从MS收到了一个上行的LLC PDU并创建了一个MS的上下文。现在BSS将选择源端及本地的IP/UDP1这个IP端点（取决于内部实现或内部配置）以及一个目的IP/UDP3这个IP端点（基于IP的符合分担机制来选择）来发送相应的NS SDU（即用户的NS层的payload）。
  BSS这时发送一个上行的NS-UNITDATA（将R-bit置1并且根据LSP来选择对应的IP端点）通过IP/UDP1发给SGSN侧的IP/UDP3.一旦SGSN接收到这个上行的NS-UNITDATA，SGSN也可以选择变更自己这一侧的IP端点，也就是SGSN期望后续的上行数据BSS发到自己这测的IP/UDP4这个IP端点。那么SGSN将响应一个下行的NS-UNITDATA给BSS，并且将R-bit置1以及C-bit也置1，并且从IP/UDP4发给BSS侧的IP/UDP1.由于C-bit也置1，代表对BSS这边的IP端点IP/UDP1进行了确认。
  所以，后续的数据将在BSS侧的IP/UDP1和SGSN侧的IP/UDP4之间发送。

Example 1 of both NS entities requesting change flow

爱卫生

Example 2: Only one NS entity triggers resource distribution (refer to figure B.2).
  The BSS sends an uplink NS-UNITDATA with R-bit set from IP/UDP1 to IP/UDP3 at the SGSN. The SGSN may choose not to trigger resource distribution, but the SGSN confirms receipt of the "request change flow" by sending the in the next downlink NS-UNITDATA with C-bit set to IP/UDP1.
  Subsequent uplink data transfer for the mobile will follow the dotted paths from IP/UDP1 to IP/UDP3 and downlink data transfer from IP/UDP4 to IP/UDP1.
  这次是SGSN侧不动，只有BSS侧想改IP端点。
  BSS发送一个上行NS-UNITDATA并带上R-bit，从本端的IP/UDP1发向SGSN侧的IP/UDP3。SGSN并不想触发IP端点的重新分配，因此，SGSN只是通过IP/UDP4（本地选择的）发送了一个下行的NS-UNITDATA并带上C-bit给BSS侧的IP/UDP1，代表对BSS侧请求IP端点变更的确认。
  由于得到了SGSN侧的确认，所以下行方向的数据，SGSN将发给BSS侧的IP/UDP1，而SGSN侧并没有变化，因此上行数据仍从BSS侧的IP/UDP1发向SGSN的IP/UDP3，而不是IP/UDP4。
  

Example 2 of only one NS entity requesting change flow

爱卫生

Example 3: NS entity triggering resource distribution without data在没有数据要发送的情况下触发IP端点的变更
The SGSN may wish to receive uplink data for a mobile at IP/UDP4 and not IP/UDP3. The SGSN may not have downlink data, in which case the SGSN may send a downlink NS-UNITDATA (with R-bit set) containing a BSSGP DL UNITDATA with an LLC PDU of length 0.
Subsequent uplink data transfer for the mobile will follow the dotted path from IP/UDP1 to IP/UDP4 through the IP sub network.
这个例子是SGSN想改IP端点，但又没有下行数据发送，不能由业务来触发。怎么办呢？
也就是说这里SGSN希望从IP/UDP4这个IP Endpoint收上行数据，而不是之前的IP/UDP3这个IP Endpoint。但这个时候SGSN并没有下行数据要发送给BSS来通知这个变化，那SGSN将发送一个下行的NS-UNITDATA并且将R-bit置为1，（R bit就是后面抓包里的R-bit = Request Change Flow bit),并且在LLC PDU的长度设置为0，仔细看下抓包，这点也是吻合的。

然后就是说接下来上行方向的用户数据就按照虚线的方向从BSS侧的IP/UDP1发向SGSN侧的IP/UDP4了。（参考图例中的虚线部分是后续的上行流量走向）。  

Example 3 of NS entity requesting change flow without data

   再附上上面说明里提到的抓包文件截图。感谢tobino1在帖子http://www.gprshome.com/forum.php?mod=viewthread&tid=771&page=1&extra=中分享了这个抓包。

爱卫生

Example 4: NS entities without any resource distribution function  The BSS and SGSN may not care which IP endpoint data arrives at as long as the requirements for the load sharing function are met.
  In this case the paths taken by the uplink and downlink data are independent.
  这个例子就是说NS实体也就是BSS或SGSN不希望改变IP端点，即他们并不关注自己更期望用哪个IP端点来收发数据，只要能收能发就行，这样的话上下行的数据发送和接收的路径可以是完全独立的，就是去是一条，回可以走另一条路径。类似IP网络的路由，去程和回程并不一定是同一条。图例如下：

Example 4 of NS entity not requesting change flow

xiner

整理了一份PPT，有相关数据包示例

爱卫生

回复 xiner 的帖子

  非常感谢分享！很好的总结！

samsin

楼主，你好：
这个图： Example 3 of NS entity requesting change flow without data
是否 “IP/UDP2 <----->IP/UDP4” 更合适？？？

Darcy2011

顶顶顶顶顶

chenxiaoan503

弱弱的问一句爱总，什么情况下BSS侧和SGSN侧会有这种修改IP Endpoint的情景呢，一般情况下应该是只要能收能发就行吧，是不是BSS侧PCU单元有很多个的时候，每个PCU单元都有自己的地址就存在选路。

chenxiaoan503

chenxiaoan503 发表于 2013-6-25 16:14
弱弱的问一句爱总，什么情况下BSS侧和SGSN侧会有这种修改IP Endpoint的情景呢，一般情况下应该是只要能收能 ...

正常情况下，Example 4: NS entities without any resource distribution function这种是最常见的吧，如果是割接（比如BSC侧修改了PCU地址）那相当于是重建GB链路，那就是初始化的意思，相当于原来那条GB  link就直接不用了，是重新生成，不存在修改吧。这种情况是不是在做SGSN POOL迁移的时候，类似那种软切的情况。本人刚接触GPRS网络，可能有些简单的东西不是很明白，有些钻牛角尖。