51学通信技术论坛

标题: 求助：请教Gb Over IP中的负荷分担和资源重分配机制？ [打印本页]

作者: tobino1 时间: 2011-8-25 09:56:54 标题: 求助：请教Gb Over IP中的负荷分担和资源重分配机制？

如题，在48016中4.4 load sharing function 和4.4a resource distribution function 中关于“change the IP endpoint“本人看的不是很明白，主要是针对gb-oip，不知道谁有这方面相关的翻译版本。
The BSS or SGSN may choose not to initiate any request for change in IP endpoints for any MS and rely on the underlying load sharing function to properly distribute NS user traffic. However, if the BSS or SGSN receives a request to change the IP endpoint at which NS SDUs are received for an MS, then the higher layers shall be informed of this change by an indication in the Link Selector Parameter. That is, if the SGSN (BSS) receives a request to change the remote IP endpoint for an MS then subsequent downlink (uplink) data for the mobile shall be sent to that remote IP endpoint indicated by the request.
说BSS和SGSN可以选择不提出任何改变MS的IP端点的请求，但是如果有这个request，那么随后的下行（上行）的移动数据应被发送到该远程IP端点的请求表示；在48.018中找到相关描述：

If the Gb-interface is supported using an IP sub-network , then the Resource Distribution function at the SGSN may transmit a BSSGP DL-UNITDATA PDU with an LLC-PDU Length Indicator set to 0. The BSS uses this DLUNITDATA to change the IP endpoint at the SGSN to which any future UL-UNITDATA for the TLLI (indicated in the DL-UNITDATA) is sent. The LLC-PDU with a Length Indicator set to 0 is not sent across the radio interface.

If the Gb-interface is supported using an IP sub-network , then the Resource Distribution function at the BSS may transmit a BSSGP UL-UNITDATA PDU with an LLC-PDU Length Indicator set to 0. The SGSN uses this UL-UNITDATA to change the IP endpoint at the BSS to which any future DL-UNITDATA for the TLLI (indicated in the ULUNITDATA) is sent.

以下是我找到的相关包，SGSN发往68，随后收到UL-UNITDATA（request change flow:set/llc-PDU Length:0）是在77上发起请求的，随后SGSN便下发至77；

[attach]831[/attach]

作者: 爱卫生 时间: 2011-8-26 10:50:44

本帖最后由爱卫生于 2011-8-26 10:51 编辑

回复 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.

[attach]832[/attach]

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:51

回复爱卫生的帖子

呵呵
不好意思
，其实我的问题还没有写出来，如果我上面理解正确的话，拿下面这几种情况是否正确？
情况一、
按照协议描述：The BSS or SGSN may choose not to initiate any request for change in IP endpoints for any MS and rely on the underlying load sharing function to properly distribute NS user traffic。那么下面这种情况是否就是协议所描述的呢？
之前的下行数据包是由SGSN（10.129.185.46）发给BSC（10.128.189.80），但在27#28#包中，SGSN地址变成185.50,BSC地址变成189.71,随后BSC上发UL-UNITDATA消息要求改变SGSN发给BSC的地址为189.75。不知道27和28# 这2个包的地址变化是否正常？

作者: tobino1 时间: 2011-8-26 17:09:47

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

呵呵

[attach]840[/attach]

作者: tobino1 时间: 2011-8-26 17:13:13

tobino1 发表于 2011-8-26 17:09

同样在附近中的378#，379#包中找到SGSN和BSC地址的变化：
SGSN由46——>48
BSC由75——>74

作者: 爱卫生 时间: 2011-8-27 11:11:58

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 时间: 2011-8-29 10:57:11

回复爱卫生的帖子

其实，到底是资源重分配还是负荷分担我现在还是没有弄清楚，所以只能过滤多个包来看问题，也请爱总再帮忙分析分析，最好可以帮忙总结几句话，如bsc怎么选择ip，sgsn怎么选择ip（和bsc发的ip有没有关系）；
下面是我又遇见的一种情况，为了方便看我截图xls，详见附件cap。

[attach]846[/attach]

作者: 爱卫生 时间: 2011-8-29 14:08:37

回复 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:41

回复爱卫生的帖子

首先谢谢爱总的帮助，我还是有几个疑问，希望可以有更加详细的解答：
1.NS SDU Control Bit里面的R-bit为1，则是Resourse distribution function，这点已经确定，目前共有3类information：UL-UNITDATA,DL-UNITDATA和SN-UNITDATA（从上面的截图可以看出），我过滤很多包，DL-UNITDATA很少且不考虑，SN-UNITDATA的R-bit全部为0，因此认定UL-UNITDATA（request change flow:set/llc-PDU Length:0）即Resourse distribution function，根据规范：if the SGSN (BSS) receives a request to change the remote IP endpoint for an MS then subsequent downlink (uplink) data for the mobile shall be sent to that remote IP endpoint indicated by the request，如果SGSN（BSS）接收到改变远程IP一个请求，那么随后的下行（上行）的移动数据都是应送交请求指示该远程IP端点（与1楼图吻合：BSC在77上发起UL-UNITDATA，那么随后的SGSN便发送至该地址）；问题是7楼图中：bsc发起请求的是在不同的ip（74和84）（包54#73#）但后续的下行包却发送至83；
问题1.既然有ul-unitdata，那么为什么不按照规范“then subsequent downlink (uplink) data for the mobile shall be sent to that remote IP endpoint indicated by the request”
问题2.bsc发的2次ul-unitdata为什么不一样，后续的包怎么没有按照后一个ul-unitdata要求sgsn发送至10.128.189.84呢？
问题3.后续包发送至10.128.189.83，会不会和82#包有关系？
根据爱立信的说法“ 路由选择是由初始业务触发时选择的--终端触发业务后:a. BSC的本地EP是固定的（小区固定在一个RP内），然后选择远端EP （SGSN）
b. SGSN 可以选择本地EP，远端EP根据收到的信息（从BSC传过来的）确定，也就是不能再选择其他的EP”似乎和问题3情况吻合；但是根据规范4.4a：The The Resource Distribution Function overrides the Load Sharing function for the selection of the remote IP endpoint. 说资源分配的优先级应该高于负荷分担才对，那么这样又解释不通了。

另外：在所有的包中并没有confirm change 置1的情况，不知怎么解释。

2.2楼你的解释说1楼图是第三种情况：这个例子是SGSN想改IP端点，但又没有下行数据发送，不能由业务来触发。怎么办呢？请问这里的“without data”是指什么？另外我仔细把48.016附录中的4中情况研读了一遍，发现（eg1,2,3）中的图和他的话对应不上，不知道里面的sgsn和bsc的位置是否可以互换？我觉得这张图倒可以解释通
[attach]851[/attach]

作者: tobino1 时间: 2011-8-30 11:00:12

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

其实，到底是资源重分配还是负荷分担我现在还是没有弄清楚，所以只能过滤多个包来看问 ...

对于7楼中为什么BSC上发UL-UNITDATA的本端地址不一样的原因（包54#73#和包122#138#）我又分析了数据包，发现原来是cell发生了变化，根据规范4.4.2.3.1中The BSS may disassociate the LSP from the remote IP endpoint when an MS makes a cell change or when the MS context is deleted. The SGSN shall associate an MS with the last used
remote IP endpoint as long as the SGSN has location information for the MS on cell level，当MS发生cell变化时，SGSN将使用MS最后使用的地址作为远端ip端口；从下图看出：54#的cell=21972,73#的cell=23112,82#的cell=23118，因此，SGSN将使用最后一次cell变化的ip（10.128.189.83）作为远端ip，sgsn下发至bsc的ip为10.128.189.83（见后续包85#86#）；
[attach]852[/attach][attach]854[/attach][attach]853[/attach]

作者: 爱卫生 时间: 2011-8-30 15:56:47

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:01

回复爱卫生的帖子

有几个问题我有疑问：
问题3中，你说是是#77号包R-bit置1，但77#是信令包啊，协议上4.4a“The resource distribution function is only available for data traffic when an IP sub-network is used”只用于数据流啊，所以我觉得不太对，不知道能否用10楼我的这个回答呢？问题1中ul-unitdata的r-bit是置1的。
问题7中，“一种是用SNS-Change-Weight PDU变更IP端点（属于load sharing功能）”但这个说的是signalling traffic，为什么不是4.4.2.3.1Selection of remote IP endpoint for data traffic的三种情况呢？
a.If the LSP has not been associated with a remote IP endpoint, then ....
b.Once a remote IP endpoint is selected for the LSP.....
c.The BSS may disassociate the LSP from the remote IP endpoint when an MS makes a cell change or when the MS context is deleted........

作者: 爱卫生 时间: 2011-8-30 21:11:05

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:03

回复爱卫生的帖子

呵呵谢谢爱总给解疑，还是刚才问题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#包不属于这类包

作者: 爱卫生 时间: 2011-8-31 14:38:03

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的。也就是没有强制要求。

作者: tobino1 时间: 2011-9-1 15:05:51

回复爱卫生的帖子

谢谢爱总，我刚才看了下确实和example2描述的一样，77#是bsc从189.83（ip1）发送SGSN185.51（ip3），且R-bit=1，随后的上下包82#便是从ip1->ip3，但下行包变成185.50（ip4）->ip1

作者: lily 时间: 2011-9-27 14:00:09

sorry,请别介意我来歪一下楼。
我刚刚学习这个问题，对这个地方不太明白，请帮忙解答好么？谢谢
爱卫生在上面提到“第二种场景，即只有一个NS实体希望改变IP端点。参考Example 2,如果需要改变的话，那就将R-bit置1，通知对方就可以了。对方将C-bit置1进行确认。但这里的包并没将C-bit置1，只不过前面也提到了C-bit是可选置1的。也就是没有强制要求。”
我的问题是，如果只有SGSN支持资源重分配机制，BSC不支持，那么当SGSN想改变IP端点时，将R-bit置1通知BSC,BSC会对该消息作出回应么？如果会，是固定将C-bit置1么？还是根本不会回应SGSN？（这样就意味着BSC不支持RDF时，SGSN无法单方面更改IP端点了）。
谢谢

作者: 爱卫生 时间: 2011-9-27 18:54:55

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

作者: lily 时间: 2011-9-28 09:12:41

回复爱卫生的帖子

" 但如果真的是不支持，那就要看厂家的实现了，是否能识别NS层的C-bit了。不一定所有厂家的实现都一样。"
您是想说，依赖于各个厂家的实现，BSC能否识别NS层的R-bit么？
但是看Example 3: NS entity triggering resource distribution without data，似乎不需要BSC对SGSN的R-bit做出C-bit的回应，BSC就会朝SGSN更改后的endpiont发信息了呀？

作者: 爱卫生 时间: 2011-9-28 16:40:02

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不支持资源重分配机制的情况的。

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