51学通信技术论坛

标题: 请教一个SGSN POOL的问题 [打印本页]

作者: watson100 时间: 2011-6-27 21:25:10 标题: 请教一个SGSN POOL的问题

SGSN POOL里面配置CN-ID是做什么用的？在哪个字段体现出来的呢？

还有就是当SGSN需要卸载时，规范说：
When the CN node receives the Location Update, Routing Area Update or Attach request, it returns a new TMSI/P-
TMSI with a null-NRI, and a non-broadcast LAI/RAI in the accept message.

In the PS domain, a new Routing Area Update is triggered by setting the periodic routing area update timer to a sufficiently low value (recommended value is 4 seconds) in the accept message. The UE will shortly after send a new Routing Area Update that the RAN node then will route to a new SGSN due to the presence of a null-NRI.

我的疑问是：既然SGSN已经给UE的消息里面带的是non-broadcast RAI,那么UE就会发现这个RAI和原来的RAI不同，UE就会马上做RAU，不需要SGSN还特别设置周期性路由区更新时间是4秒了。

不知道我理解的对不对。

作者: 爱卫生 时间: 2011-6-28 21:57:08

本帖最后由爱卫生于 2011-6-28 21:59 编辑

我的感觉这个应该是一个无线侧的问题，而不单是SGSN POOL的问题。
RAU流程的发起确实是判别是否进入到了一个新的RA。那要判断就需要两个值，A：一个是上一次MS做RAU或者附着所驻留的RA。还有一个就是B: MS当前所在的RA。而前者是在RAU Accept或者Attach Accept消息里会携带的，MS收到以后会存到手机里。后面那个MS所在的RA是由MS不断监听BCCH信道上的广播消息SI13，或者PBCCH信道上的广播消息PSI13。这些广播消息里就会包含MS当前所在的RAC的信息。这样，MS就可以做判断这两个值是否相等，要不要做RA更新了。
（这个SI13里的内容，可以参考TS44.018的表格10.5.2.37b.2）。
关于SI13，如下截图，是通过BCCH收到的，仔细看，里面有一行包含的是RAC。

因此，即使MS收到了“SGSN已经给UE的消息里面带的是non-broadcast RAI”,MS也不会去做RA更新。因为这个RAI不作为判断是否进入新RA的依据，而是要以无线广播信道BCCH或PBCCH信道收到的RAI作为依据。
个人理解，谨供参考。

作者: watson100 时间: 2011-6-29 09:14:17

即使MS收到了“SGSN已经给UE的消息里面带的是non-broadcast RAI”,MS也不会去做RA更新。因为这个RAI不作为判断是否进入新RA的依据，而是要以无线广播信道BCCH或PBCCH信道收到的RAI作为依据。
==================

如果这样的话，那也没有必要设置周期性路由区更新的时间呀。
因为无线广播信道BCCH或PBCCH信道广播的时间一定是小于4s的呀，这样UE也能知道RAI变化了。

作者: 爱卫生 时间: 2011-6-29 20:22:25

本帖最后由爱卫生于 2011-6-29 20:24 编辑

回复 watson100 的帖子

非常感谢。你问得太好了。带着你的问题，我找了半天，终于找到了答案。答案肯定是准确的。虽然不是3GPP规范里提到的，但是是中国移动的规范。http://wenku.baidu.com/view/d5a6dfd3240c844769eaeec1.html 中国移动Gb_Iu-PS_Flex技术规范.doc。这个文档是免费的。我准备单独发一篇帖子来介绍。
首先，解释下，为什么叫Non-Broadcast RAI。为什么叫非广播的。原来这个名字的由来，是因为它不需要在不需要在系统信息广播消息中广播。也就是上面提到的BCCH和PBCCH中的系统广播消息里不会包含这个RAC。因此手机就收不到当前所在RAI信息了。自然就只能等待周期性的来做RAU了。
摘录如下：
“3.Non-Broadcast RAI

特殊的RAI，与普通的RAI统一编码，不需要在系统信息广播消息中广播。在SGSN Pool内进行负荷迁移的处理中，用于触发MS重新发起位置更新。Pool中的每个核心节点需要分配一个特殊的Non-Broadcast RAI，并且可以识别Pool内其它核心节点的Non-Broadcast RAI。

4.Null-NRI

特殊的NRI，与普通的NRI统一编码。在SGSN Pool进行负荷迁移时，用于指示NNSF功能网元依照负荷均衡的原则，为MS新选一个可用的服务SGSN。”

截取一个因上面描述的迁移用户而引起的RAU流程如下：

[attach]662[/attach]

作者: watson100 时间: 2011-6-29 20:32:49

感谢。那我还有另一个疑问：
手机在发起新的RAU过程中，带的RAI是NON-Broadcast RAI,如果按照文档的描述，那它应该带的是BCCH广播的RAI才对。所以说UE还是接受了原来SGSN下发的消息里面的NON-Broadcast RAI，并把这个RAI作为最新的RAI才对呀。

作者: watson100 时间: 2011-6-29 20:33:24

感谢。那我还有另一个疑问：
手机在发起新的RAU过程中，带的RAI是NON-Broadcast RAI,如果按照文档的描述，那它应该带的是BCCH广播的RAI才对。所以说UE还是接受了原来SGSN下发的消息里面的NON-Broadcast RAI，并把这个RAI作为最新的RAI才对呀。

作者: 爱卫生 时间: 2011-6-29 20:46:46

watson100 发表于 2011-6-29 20:33
感谢。那我还有另一个疑问：
手机在发起新的RAU过程中，带的RAI是NON-Broadcast RAI,如果按照文档的描述， ...

后面的流程图和移动的规范文档并不矛盾啊。
在正常的RAU流程中，假设一个最常见的场景，MS从SGSN1负责的RA1做了附着或者RA更新，SGSN1在RAU Accept消息里会把RA1作为当前的RAI告诉MS。MS存到手机里。这时MS移动到了SGSN2负责的RA2，这个RA2就是通过BCCH的系统广播消息广播的。因此MS发起了一次RAU。但这个RAU Request里带的RAI是Old RAI，而不是Current RAI。也就是RAU Request消息里带的RAI是RA1，而不是RA2。这样SGSN2才能根据收到的RA1解析出SGSN1的地址信息，从而去向SGSN1去要MS的MM上下文信息。
那回到这个例子，也是类似的。MS在收到SGSN回的RAU Accept消息时，得到的RAI是Non-Broadcast RAI。这个RAI在MS下一次发起RAU请求时，就变成了Old RAI，从而出现在RAU request消息里。这和BCCH信道里广播的RAI无关，因为广播的RAI是当前的RAI，不应该出现在RAU Request消息里。
之所以不让这个RAI广播，并不是不让它出现在RAU Request消息里。而是让BCCH信道里接收不到当前RAI的信息，从而无法和Old RAI进行比较去发起RAU流程。这样就只能等待周期性RAU计时器超时了。
谨供参考！

作者: watson100 时间: 2011-6-29 20:58:53

这样又回到我的第二个回复的问题了。

non-broadcast只是在SGSN上配置的，但是手机目前所在的小区还是会正常广播小区配置的rai信息，这个RAI是和non-broadcast不同的，既然不同，那么手机就会触发RAU过程呀。

你的意思是BCCH接收不到当前RAI的信息，我是表示怀疑的，我认为：BCCH不会广播non-broadcast RAI，但是还是会广播原来配置的RAI.这样就会造成手机RAU。

作者: 爱卫生 时间: 2011-6-29 22:26:59

回复 watson100 的帖子

谢谢你的回复。我仔细找了一下相关说明。一个华为的SGSN POOL手册。里面明确提到了“MS/UE 结束当前的业务后，Non-broadcast RAI 将触使MS/UE 在4 秒（默认）后进行路由区更新，因为Non-broadcast RAI 与MS/UE 所在的RNC 广播的RAI 不同。”，另外我还查找了MSC POOL中的说明，发现MSC POOL的用户迁移使用Non-broadcast RAI 的方法和SGSN也是一样的。都提到了是因为收到的Non-broadcast RAI 和BSC/RNC广播的RAI不同而发起的。
  所以，你的上述怀疑是对的。我说的不对。也就是如你所说的，BCCH信道里仍然会广播当前的RAI信息。MS将收到的RAI和RAU Accept消息里的Non-broadcast RAI 对比，发现肯定不同，因此立即发起RAU更新。
  所以，这就回到了你最开始的提问。"既然SGSN已经给UE的消息里面带的是non-broadcast RAI,那么UE就会发现这个RAI和原来的RAI不同，UE就会马上做RAU，不需要SGSN还特别设置周期性路由区更新时间是4秒了。”。
  我的理解就是。对啊，UE会马上RAU，并不需要等4秒超时，但这不正是网络侧想要的结果吗？因为SGSN上因为负载过高，要做用户迁移。它巴不得用户一秒都不等立即做RAU来转移到别的SGSN。
  退一步，如果小区无线信号不好，MS在BCCH信道没有收到当前的RAI。那在4秒之后也会发起RAU。因此，无论如何，不管小区信号怎样，MS都会在4秒内发起RAU，从而达到SGSN希望立即迁移用户的目的。
  个人理解，谨供参考（紫色字后面的内容纯属猜的，呵呵）。谢谢你的怀疑啊。呵呵，又去查了些文档，学了不少。

作者: heropoet 时间: 2011-6-30 12:49:57

好贴!通透!

作者: watson100 时间: 2011-7-2 14:02:26

版主呀，我还有1个问题呀。就是CN-ID，这个字段用在什么地方呀。

作者: 爱卫生 时间: 2011-7-3 00:26:17

本帖最后由爱卫生于 2011-11-20 19:41 编辑

回复 watson100 的帖子

  好问题。不好意思，忽略了。
  首先，CN-ID的用途是对POOL内SGSN节点的标识。一个POOL内的SGSN可以有多个NRI，但只能有一个CN-ID来标识他。取值为0-4095。再加上MNC，MCC就变成了Global-CN-ID。
  查了规范并我加上自己的理解，这个CN-ID和PS域的SGSN POOL无关。但和MSC POOL有关。
  规范TS23.236是这么说的：“In A/Gb mode in case a MSC/VLR sends a paging-request/paging with IMSI (i.e. the paging message does not contain a TMSI), the NAS node selection function in the BSC shall upon reception temporarily store the Global-CN- ID of the node that issued the paging-request/paging message. If the NAS node selection function in A/Gb mode receives a paging-response with an IMSI then it should check the temporarily stored Global-CN-ID on entries matching this IMSI and forward the paging-response to the node identified by this Global-CN-ID.”
  规范总共才39页。搜索CN-ID的关键字总共才出现了不到10次。我仔细检查了，发现全部与MSC有关。就如上所说的那样。
上面翻译过来说白了就是，如果MSC以IMSI来寻呼用户的话，则BSC收到这个寻呼请求的时候，应将MSC的CN-ID保存下来，然后在收到MS的寻呼响应消息时，能够根据手机的IMSI和刚刚保存的CN-ID的对应关系，将这个寻呼响应能够发送到池组里正确的MSC上面去。
  这个很好理解，因为MSC是用IMSI来寻呼的，而BSC不可能有IMSI和NRI的对应关系。所以BSC就没有办法将寻呼响应根据NRI来寻址MSC了，只能根据CN-ID和IMSI的映射查找到对应的MSC。
  但PS域没有这个问题，因为PS的寻呼总是用的P-TMSI，没有用IMSI来寻呼的。而且PS的寻呼是针对standby用户的寻呼，这些用户肯定已经分到了P-TMSI。因此BSC根据节点选择功能根据P-TMSI的NRI选择POOL里对应的SGSN就可以了。
  至于CS，为什么MSC可以用IMSI来寻呼用户。属于CS的规范，这是允许的。在百度上搜索下“MSC 寻呼 IMSI”，有很多解释。例如部分摘录：“华为的寻呼策略是：MSC最多支持5次寻呼重发，采用TMSI还是IMSI寻呼可由MSC设置。”

作者: watson100 时间: 2011-7-4 09:53:12

感谢版主呀。一直在传到授业解惑。

作者: 爱卫生 时间: 2011-7-4 19:43:31

回复 watson100 的帖子

客气了。其实谈不上授业解惑。我只是在尽自己的力去找答案，因为有些问题我也不知道答案。不过后来不管找不找得到，自己也都能得到提高，还能和论坛的朋友们一起交流、分享。还是很不错的啊！而且，希望能抛砖引玉，有更多的朋友分享自己的经验。
也谢谢你对论坛的支持啊！

作者: feile99 时间: 2011-10-6 22:04:57

回复爱卫生的帖子

这段话看的我很迷糊啊。

一会说CN-ID标识SGSN。一会又是寻址MSC。

还有就是通过IMSI来寻呼UE和SGSN有什么关系，一个是CS域，一个PS域。两者之间没啥关系啊。

作者: 爱卫生 时间: 2011-10-7 16:04:11

feile99 发表于 2011-10-6 22:04
回复爱卫生的帖子

这段话看的我很迷糊啊。

不好意思啊。确实让人晕。是这样的，这里扯上MSC和IMSI寻呼只是为了回答之前问到的CN-ID的使用场景问题，并借此对比了一下和PS域的区别。因为回答CN-ID使用场景问题，查到规范的话，规范里并不叫PS域的SGSN POOL或CS域的MSC POOL，而是统一的角Gb Flex还有Iu Flex。规范是混在一起的，而且很多场景规范里是用的MSC来举的例子。我也只能照搬过来了。但实际上CS域的MSC POOL和PS域的SGSN POOL在实现方式上相似度确实非常高。互相都是可以借鉴的，我觉得这两个可能90%都类似吧。

作者: gaohui2008 时间: 2011-10-13 17:42:34

１、＂上面翻译过来说白了就是，如果MSC以IMSI来寻呼用户的话，则BSC收到这个寻呼请求的时候，应将MSC的CN-ID保存下来，然后在收到MS的寻呼响应消息时，能够根据手机的IMSI和刚刚保存的CN-ID的对应关系，将这个寻呼响应能够发送到池组里正确的SGSN上面去。＂翻译意思对，但是最后＂发送到池组里正确的SGSN上面去＂应该是＂发送到池组里正确的ＭＳＣ上面去＂，那来那去吗。电路域如果有单独的ＩＭＳＩ　ＰＡＧＩＮＧ，分组域也应该有单独的ＩＭＳＩ　ＰＡＧＩＮＧ，ＩＭＳＩ　ＰＡＧＩＮＧ应该用于全局寻呼，这时ＴＭＳＩ／ＰＴＭＳＩ都不起作用了，因此分组域也应该有Global-CN- ID 的概念．把版主翻译的ＭＳＣ替换成ＭＳＣ／ＳＧＳＮ更好．
2、看了版主的解释，明白了null-NRI, a non-broadcast LAI/RAI作用，非常感谢。但是后面对周期性路由区更新设置成4秒，解释的有些牵强，因为如果空口无线信号不好，MS收不到non-broadcast LAI/RAI，它也收不到一个ACCEPT信令的周期时间。

作者: hijake 时间: 2011-11-18 23:32:21

貌似是先前收到的accept消息当中会设置一个周期时间4秒，收不到信令消息自然会触发RAU

作者: nil 时间: 2012-1-20 16:47:36

能不能解释一下，为什么PS域中的寻呼，不使用IMSI而且总是对STANDBY用户的寻呼么？
是不是因为目前PS没有被叫业务？但是规范中并没有说没有被叫业务吧？

作者: xrytiancai 时间: 2012-11-4 23:51:18

学习ing••••••

作者: sw25256 时间: 2013-6-28 16:56:54

请教一个问题
When the RNC receives a message with a 'null-NRI' it uses the NAS Node Selection Function for selecting a CN node where to forward the message. CN node(s) with re-distribution in progress should be excluded from the NAS Node Selection algorithm in the RNC. This is done by O&M configuration in the RNC.

RNC从何得知哪个节点是发起卸载的，因为发上来的是NNRI，所有节点都是一致的，难道是从PTMSI中提取NRI来判断的吗？

作者: hycl5410 时间: 2013-7-3 11:43:39

本帖最后由 hycl5410 于 2013-7-3 11:56 编辑

似乎需要在SGSN做offload前，先在RNC上手工设置一下SGSN状态？这样不想被选中的SGSN就被踢出去了。。。

RANAP协议貌似还没有设计动态更新的SGSN load的功能，但是到了S1AP就可以了（至少可以不让traffic进来）。

作者: hou3331 时间: 2014-6-23 17:33:37

我看到ps paging消息中把IMSI，PTMSI，global CNID都携带了

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