求助：请教Gb Over IP中的负荷分担和资源重分配机制？

爱卫生

回复 tobino1 的帖子

  举个实例来说明吧。你的问题在48.016的附录B中有详细的说明。这个话题我准备再单独开一个帖子介绍给不太了解的朋友。我也是学习了不少。
  附录B的内容就是专门介绍IP的资源分发的。标题是
  Annex B (informative):
Recommended usage of Resource Distribution for IP
  里面的Example 3和你的抓包实例完全吻合，现英文摘过来如下：
Example 3: NS entity triggering resource distribution without data (refer to figure B.3).
   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.
   

Example 3 of NS entity requesting change flow without data

  也就是说如果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了。（参考图例中的虚线部分是后续的上行流量走向）。

爱卫生

tobino1 发表于 2011-8-26 17:08
回复 爱卫生 的帖子

呵呵

  我觉得你这里提到的IP地址变化并不是IP端点的重分配，因为在#27和#28的包虽然变更了IP地址，但实际上NS SDU Control bit里面的R bit（Request Change Flow bit)并没有置1，所以这里发生的IP端点地址变化（包括源和目的IP都变了）是因为Gb Over IP的符合分担功能实现的。
  这个功能是在TS48.016的4.4.2中描述。其中明确的提到了，如果使用负荷分担功能的话，SGSN和BSS可以按照如下规则来重新选择本地和远端的IP地址。
1）本端IP的选择见4.4.2.2 Selection of the local IP endpoint，明确提到选择本端IP的时候是由LSP(Link Selector Parameter)来决定的。而Link Selector Parameter is locally used at the BSS and at the SGSN and shall not be transmitted across the Gb interface,即在本地使用不用于传递，并且在选择本端IP地址的时候要满足5点要求，其余的可以由各厂家自行决定。
2）远端IP的选择见4.4.2.3 Selection of the remote IP endpoint,明确提到远端IP的选择是由对端NSE发过来的权重weight来决定的（0-255），可以通过SNS-Change Weight PDU来修改这个权重。
  所以源和目的的IP端点发生变化就不奇怪了。

爱卫生

回复 tobino1 的帖子

  我试着总结一下，仅供参考啊。根据TS48.016的规范，Gb Over IP中如果需要改变IP端点的话，有两种情况触发：
1 因为4.4.2提到的load sharing功能来触发。BSC和SGSN之间可以定义多个IP端点来传输上层NS-PDU，实现负荷分担的功能。这个过程是自动完成的，不需要人工干预。由BSC和SGSN根据一定的原则来选择到底是由哪个IP端点来传输数据。
2 因为4.4.a提到的Resourse distribution function功能来触发。这个通常是因为一些特定的事件需要改变IP的端点。一般需要人工干预。例如SGSN上板卡更换、IP地址割接或者是SGSN板卡升级需要导流量等等。需要将流量从某块板子上移除，则可以使用这种功能。
   通过这个抓包来反推。如何区分是上面1还是2这两种情况来触发的，很简单。
  如果发生了IP端点的变化，那就看NS层的NS SDU Control Bit里面的R-bit是否置1。
1）如果置1，则是由上述第二种情况即Resourse distribution function功能来触发的IP Endpoint变更，对方收到了后将C-bit置1，作为一个确认。这样IP的端点就变更了，后续的传输路径也就一起变化了。BSC和SGSN可以分别独立的来发起Resourse distribution function功能，即独立的将R bit置1，来完成本端IP端点的变更。
2）如果没有置1。则是第一种情况load sharing来触发的。是由系统根据下面的原则自动选出来的。
   然后再看如果是load sharing触发的。BSC或SGSN是怎样来选择IP端点的。IP端点包括本端端点和远端端点，即源IP和目的IP。
1 本端端点的选择（不论BSC还是SGSN）详见4.4.2.2章节。是由节点内部的LSP（链路选择参数）决定的。如果没有LSP，则取决于厂家的具体实现。
2 远端端点的选择（不论BSC还是SGSN）详见4.4.2.3章节。是由对方节点发过来的SNS-Change-Weight PDU里面所带的权重值决定的。例如BSC要根据负荷分担原则选择SGSN侧的IP端点，则会收到SGSN发过来的NS层的SNS-Change-Weight PDU，里面会携带并告知BSC，关于SGSN侧哪个IP端点的权重最高，则流量要多分担一些。
   不知道说清楚了没有哦！

爱卫生

tobino1 发表于 2011-8-29 18:06
回复 爱卫生 的帖子

首先谢谢爱总的帮助，我还是有几个疑问，希望可以有更加详细的解答：

  不好意思哈。你的回复中问题比较分散。我不确定都能答上。漏了可以提醒下我。
  我试着回答一下。
问题1.既然有ul-unitdata，那么为什么不按照规范“then subsequent downlink (uplink) data for the mobile shall be sent to that remote IP endpoint indicated by the request”。
     答：因为这里提到的then subsequent downlink 。。。这段话出自4.4a Resource distribution function这一章节，而不是来自load sharing这一章节。所以这段话的前提要求是R-bit置1。
问题2.bsc发的2次ul-unitdata为什么不一样，后续的包怎么没有按照后一个ul-unitdata要求sgsn发送至10.128.189.84呢？
     答：bsc发的2次ul-unitdata为什么不一样是因为load sharing的功能选择的本地和远端IP端点，而后续的包怎么没有按照后一个ul-unitdata要求sgsn发送至10.128.189.84呢？请看第#77号包。这个包R-bit置1了。所以后续的包就都根据要求发给83了。
问题3.后续包发送至10.128.189.83，会不会和82#包有关系？
     答:参见问题2的答案。是#77号包R-bit置1了。
问题4：在所有的包中并没有confirm change 置1的情况，不知怎么解释。
     答：根据规范7.6 Resource Distribution Procedure
When the NSE receives an NS-UNITDATA PDU with R-bit field set to "1" in the NS SDU Control Bits IE, it shall inform the higher layers to change the destination IP endpoint for that MS or MBMS session. All subsequent NS SDUs for the same MS or MBMS session shall be sent to this destination. The receiving NSE may optionally send an NS-UNITDATA PDU with the C-bit field set to "1" in the NS SDU Control Bits IE to confirm acknowledgement of the request to change the IP endpoint.因此，规范说C-bit是可选被置1，并没有强制说一定要求置1。
问题5：请问这里的“without data”是指什么？
     答：是指没有下行数据要发给BSC，这时候SGSN又想要变更本地的IP端点，例如在晚上割接升级的时候。
问题6：不知道里面的sgsn和bsc的位置是否可以互换？
     答：应该是可以互换的，因为规范里提到的是each NSE entity。所以SGSN和BSC都是可以的。
问题7：“爱立信的说法。。。”
     答：爱立信的这段话介绍了SGSN选择远端IP端点的方法，是由BSC传过来的。但BSC传过来有两种方法，一种是用SNS-Change-Weight PDU变更IP端点（属于load sharing功能），另一种是R-bit置1请求更改IP端点（属于Resource Distribution Procedure），当然后者更有优先级。所以整体来看，爱立信的这段话并没有和规范冲突，只不过是说的比较含糊罢了。
    个人意见，仅供参考哈！

爱卫生

tobino1 发表于 2011-8-30 20:28
回复 爱卫生 的帖子

有几个问题我有疑问：

  1 “问题3中，你说是是#77号包R-bit 。。。"
    答：#77不是信令包哦。是一个用户数据包。即payload。虽然是TCP的Syn报文，但在NS层看来，这仍然是用户的payload，而不应看成是信令消息（目的IP是到WAP网关的）。而且NS层的PDU Type也是NS_UNITDATA，BSSGP层的PDU Type是UL-UNITDATA。而且LLC层的SAPI也是User Data。所以#77肯定是用户的payload。（#77号包其实也有SNDCP层，只是TCP包太小了，没有被分段处理而已）因此#77包R-bit置1了，后续的包就都需要发给#77声明的IP端点即83了。因为R-bit的优先级是更高的。你在10楼的回答我也很认可，确实你发现问题细节的能力很强哦。如果#77的R-bit没有置1的话，可能就是你说的根据小区变化所引起的IP端点变更了，即BSS可以将LSP和远端IP端点的关系解除。根据10楼的回答，最后发生cell变化的是#82号包的Cell ID 23113，但实际上在之前#78号包，对端就将流量发给83了。
  2 "问题7中，“一种是用SNS-Change-Weight PDU变更。。。"
     答：其实我们说的是一回事啊。我说的SNS-Change-Weight PDU和你说的4.4.2.3.1提到的以及a、b、c三种情况也是一致的啊。4.4.2.3.1提到"The remote IP endpoints shall be selected in equal proportion to the data-weights assigned to the peer NSE's endpoints. Data-weights are assigned by the peer NSE and have a value range of 0 to 255. "，也就是说由对方NSE提供的IP端点的data-weight来提供的。而这个data-weight就是通过SNS-Change-Weight等PDU来分配和变更的。见4.4.2.1的最后一小段"(These relative weights are communicated using the SNS-CONFIG, SNS-ADD, and SNS-CHANGE-WEIGHT PDUs. Also, the remote IP endpoint can be changed by the peer NSE via the Resource Distribution Function (refer to sub-clause 4.4a.)"。你提到的情况a是说的根据data-weight来选择远端IP端点，情况b说的是维持这样一个关联。情况c说的是怎么样断开这样一个关联关系，有哪些常见的情况。所以我个人觉得我们的说法并不矛盾哦！

爱卫生

tobino1 发表于 2011-8-30 22:29
回复 爱卫生 的帖子

呵呵 谢谢爱总给解疑，还是刚才问题3，在48.016中的4.4a.1中还有进一步描述，BSSGP DL ...

  非常感谢啊！我算尝到分布式学习的一点甜头了。毕竟一个人看规范总会有遗漏的地方。感谢你的分享和补充。
  针对这个问题，我说下自己的理解。
问题："问题3，在48.016中的4.4a.1中还有进一步描述，BSSGP DL-UNITDATA (BSSGP UL-UNITDATA) with an LLC-PDU Length Indicator set to 0 is given in 3GPP TS 48.018)，其中明确指出了是BSSGP DL-UNITDATA 或BSSGP UL-UNITDATA两种类型的PDU，且LLC-PDU的length=0，不知道和77#包是否有冲突，因为77#包不属于这类包"。
   #77不属于这类包我是认同的。因为#77是有payload，那LLC-PDU长度肯定就不为0了。但我觉得并不影响#77能够通知远端来改变IP端点。因此根据48016的附录B，常见的关于资源分配的有4种场景。分别是：
Example 1: Both NS entities trigger resource distribution (refer to figure B.1).
Example 2: Only one NS entity triggers resource distribution (refer to figure B.2).
Example 3: NS entity triggering resource distribution without data (refer to figure B.3).
Example 4: NS entities without any resource distribution function (refer to figure B.4).
   我们这个问题你，你提到的LLC lenth=0应属于第三种场景。但#77号包我认为是属于第二种场景，即只有一个NS实体希望改变IP端点。参考Example 2,如果需要改变的话，那就将R-bit置1，通知对方就可以了。对方将C-bit置1进行确认。但这里的包并没将C-bit置1，只不过前面也提到了C-bit是可选置1的。也就是没有强制要求。

爱卫生

  呵呵。欢迎来歪楼啊！大家一起交流嘛。其实论坛就怕没有问题太安静了。有问题一起交流才好啊！
至于你提到的BSC不支持资源重分配机制的话会怎样， 这个问题基本上是不存在的。因为我粗略翻看了一下。TS48.016中关于资源重分配机制在2004年的R5.4就已经支持了。现在都已经到R10了。所以如果说不支持的话，除非这个BSC是3GPP R5之前的BSC。现在肯定都已经升级完了。
  但如果真的是不支持，那就要看厂家的实现了，是否能识别NS层的C-bit了。不一定所有厂家的实现都一样。

爱卫生

lily 发表于 2011-9-28 09:12
回复 爱卫生 的帖子

   " 但如果真的是不支持，那就要看厂家的实现了，是否能识别NS层的C-bit了。不一定所 ...

   一定会的。也就是BSC一定收到R-bit置1时，就会向新的IP端点发送。放心。根据是我又查了下TS48.016，http://www.3gpp.org/ftp/Specs/html-info/48016.htm，发现从有48.016开始，也就是TS48.016的第一个版本，2000年11月17日发布的。就已经支持资源重分配。里面也提到了上述的四个example。
   所以不会出现你说的BSC不支持资源重分配机制的情况的。