一个SGSN和MME同时组pool的问题。

snakend

现在有这样一个情况：1。在一个网络中，我一共6个SGSN/MME，其中4个是2/3G的SGSN，另2个是2/3/4G的SGSN-MME（就是所说的3接入节点）。
2。SGSN的pool由这6个sgsn共同组成；
3。同时，那2台triple-access的SGSN-MME，再自组一个MME的pool；
4。要求支持triple-access的终端可以通过triple-access的SGSN-MME，完成2/3G到4G，或者是4G到2/3G的系统间切换。

问题是，NRI的选择是不是必须是8bit，必须与MMECODE一致？
如果pool内的RAU是通过pool awareness的方式实现的（也就是RAU，通过发送NRI+RAI到DNS，找old SGSN）时候，NRI必须是8 bits长，与MMECODE必须一致吗？

在此先谢过了！

爱卫生

回复 snakend 的帖子

不太清楚哦。为什么要选8bit呢？有什么依据吗？通常都是5bit就够了的。POOL没有那么大啊！

snakend

一说是MMECODE的长度是8bits，所以需要NRI的长度也是8bits，但是我不知道这是不是必须的。

爱卫生

个人感觉没这么必要吧。因为NRI是用于RNC/BSC来找SGSN的，而MMEC是用于eNB来找MME的，本身二者在信令流程里也没有交集啊。唯一有可能的就是：
先做个编号，2G/3G POOL的SGSN为SGSN1-6，MME POOL的MME为2G/3G POOL里的SGSN5和SGSN6。
那在系统间切换的时候，有可能MME POOL里的SGSN5要找到2G/3G POOL里的SGSN1。例如源MME给目标SGSN发送前传重定位请求，但发送之前MME应根据规范将EPS承载映射成为PDP上下文，这时候MMEC已经完成到NRI的转换了，这时候送到DNS去查的时候已经是NRI了。应该就可以查询到目标SGSN了。另外，因为这里总共只有6个SGSN或MME，足够被NRI的5个bit覆盖了。不会存在一对多的映射。

snakend

规范23003中，2.8.2.2节有
“The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code.”这样的定义，

我想这就是NRI必须定义为8bits长度的原因吧！

snakend

这样的话NRI长度在SGSN中必须保留为8bits，但是这样的话可用的用户比特在P-TMSI中就只有17bits了，用户数就只能支持131072个，可以客户买得sgsn是1000K的，这就出矛盾了。

hycl5410

没配置过这种情况，但是可以就一些东西跟大家讨论一下。首先看要求
4。要求支持triple-access的终端可以通过triple-access的SGSN-MME，完成2/3G到4G，或者是4G到2/3G的系统间切换。
这样就存在一个情况，假如UE首先在2/3G SGSN注册，然后向MME切换。当2/3G SGSN向MME切换的时候，UE是发TAU的，这里的GUTI是由P-TMSI映射过来的，于是target MME会去DNS查source SGSN而不是MME（R10以下版本是靠一个bit来标识GUTI是MME分配还是P-TMSI映射的）。映射规则具体在那个协议上不记得了，手边没有，23.401上应该会有说。回到正题，MME怎么知道NRI的长度？这是一个问题。应该在映射规则的那个协议（23.003？）好好查查，很有可能就因此固定了NRI长度。

这样的话NRI长度在SGSN中必须保留为8bits，但是这样的话可用的用户比特在P-TMSI中就只有17bits了，用户数就只能支持131072个，可以客户买得sgsn是1000K的，这就出矛盾了。

还是查查产品文档或者问问产品线的人吧。。。怎么感觉这里面不太对啊。。。这也太影响容量了啊。。。
持续关注中，希望楼主保持更新。

hycl5410

查了一下23.003，考虑到MME情况，NRI长度可以比8短，但是不能比8长。
The NRI shall be coded in bits 23 to 14. An NRI shorter than 10 bits shall be encoded with the most significant bit of the NRI field in bit 23.
NRI在P-TMSI中的位置是bit23-14（考虑MME情况是23-16,8bit）。但是，与MME互联的情况下，NRI长度虽然可以比8短，假如是5，但是后3个bit也不能用于分配。原因请看下面的P-TMSI到GUTI映射规则。
2.8.2.2        Mapping from RAI and P-TMSI to GUTI
2.8.2.2.2        Mapping in the UE
The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code.
GERAN/UTRAN <P TMSI> maps as follows:
-        6 bits of the GERAN/UTRAN <P TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and down to bit 24 of the E UTRAN <M-TMSI>;
-        16 bits of the GERAN/UTRAN <P TMSI> starting at bit 15 and down to bit 0 are mapped into bit 15 and down to bit 0 of the E UTRAN <M-TMSI>.
2.8.2.2.3        Mapping in the new MME
In order to retrieve the UE's information, e.g. the IMSI, from the old SGSN, the new MME extracts the RAI and P-TMSI from the GUTI via the reverse mapping procedure to that specified in subclause 2.8.2.2.2.

容量问题，减掉8个bit的NRI占位，可以分配的值是4,194,304（2^22）. 22=6+16或者32-2-8

从上述角度考虑，说NRI长度固定为8也是可以的。因为即使长度不是8, 23-16这段也都不会被map到M-TMSI里。不知道SGSN实现过程是否考虑这点，即使NRI长度不是8也可以不分配其余bit，否则就需要配置NRI长度8了。

hycl5410

不好意思，没考虑到P-TMSI signature！考虑到P-TMSI signature，那么bit23-16是可以完全或者部分分配的。只要算法写的好，就不会出现无法辨别UE的情况（即使其他22个bit都完全一样）。
所以，这个问题还是要问产品或者研发。。。

snakend

多谢7楼的参与哈{:soso_e100:}

“容量问题，减掉8个bit的NRI占位，可以分配的值是4,194,304（2^22）. 22=6+16或者32-2-8”
                                             31 ~ 25                                 24   
这提些不同看法哈，P-TMSI=7bits（P-TMSI Generation）+ 1 bit(Set in standardization) + max 10bits ( NRI) + min 14 bits (P-TMSI identification).
也就是说，用于用户表示的只有1 bit(Set in standardization) + NRI + P-TMSI identification，一共25bits，如果保留8bits用于NRI的话就只用17bit可用于用户表示了。所以容量才这么小。

snakend

恩，我感觉应该是问题已经清楚了。

一。我提到的这种case，SGSN的NRI应该是只能预留为8bits。
二。当NRI为8bits，那么SGSN下的每RA最多只能支持2^17=131072 个用户，不过SGSN下挂的RA不多的情况下，就很可能浪费sgsn的容量，当然可以通过增加RA充分使用SGSN的容量；另一方每RA的容量就比较小了，需要密切的监视，以免新用户来到这个RA被拒绝，但是可以通过RA resize及radio的Rehome减小覆盖的区域控制RA的用户数。

hycl5410

回复 snakend 的帖子

bit 31-25，bit 24这段定义是在哪个规范上说的？23.003好像只说bit 31,30固定设置成11（SGSN）。

snakend

恩，29060和23060都refer 23003，但是23003上并没有把每个字段说清楚，我是找到的一个胶片。找了半天也没有找到规范上哪有定义ptmsi format的。

这个肯定是对的：

hycl5410

好吧。
我在想是不是我们把问题想复杂了。。。假设NRI长度是3，UE从SGSN得到的是P-TMSI，然后TAU到MME时UE就直接把bit23-bit16映射成MME code，根本就不管你NRI多长。。。然后MME再顺利还原回P-TMSI。
就看怎么理解这句话了
The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code.

snakend

"我在想是不是我们把问题想复杂了。。。假设NRI长度是3，UE从SGSN得到的是P-TMSI，然后TAU到MME时UE就直接把bit23-bit16映射成MME code，根本就不管你NRI多长。。。然后MME再顺利还原回P-TMSI。"

我觉得这样理解是有问题的，如果NRI为3，那么后5位就是SGSN随即分配的用户编码的一部分，也就是说不可预期，但是这些比特影射到GUTI后，要被用作MMECode，e-node要用这个找MME的，如果不可预期，那就失去了意义。

所以呀，SGSN一定要保留8bit，虽然低级的几位可能不用但是也要用确定的数字占着，比如“0”，或者“1”，这样影射到MMECode就是一个可以预期的数，只要MMECODE编号和这个数字一致，这个来自你的规划，就没有问题了。

爱卫生

snakend 发表于 2012-3-6 15:24
"我在想是不是我们把问题想复杂了。。。假设NRI长度是3，UE从SGSN得到的是P-TMSI，然后TAU到MME时UE就直接把 ...

谢谢几位的分享。个人感觉几位说的都有道理。P-TMSI到MMEC的映射规则确实没有注意到。说下我的理解。

1 个人比较同一NRI要预留8个bit。不能定义为低于8位。原因正如snakend提到的如果低于8位，后面的bit位则是给用户使用，随机分配。不可预期，则无法完成映射。

2 映射规则，应该就是hycl5410提到的从bit 23开始，一直到bit16的值取出来，映射成8bit的MMEC。因为NRI的长度在TS23.236里有明确说明。如右：" The NRI is coded in bits 23 to 14 of TMSI or P-TMSI. Regardless of the NRI length the most significant bit of the NRI is always in bit 23 of TMSI or P-TMSI (examples of NRI position are given in annex A.2), see also 3GPP TS 23.003 [18]. " 这里的most significant bit翻译成中文就是最高有效位。也就是说P-TMSI里的NRI一定是从第23 bit开始，最大到14 bit结束。

3 关于P-TMSI的组成，我也没找到特别准确的规范。但TS23.236和TS23.303里有一些说明。特别是TS23.236里还给出了一个案例说明（附录A.2）。参考它的案例，实际上P-TMSI的组成如下：

所以，容量方面。比较赞同hycl5410的说法。去掉8bit后，可使用的用户bit是32-2-8=22。因为这里的VLR-Restart Counter这5个bit是可以借的。附录A.2的案例就是有的只用了3bit，有的只用了4 bit。

hycl5410

我不确定NRI编码的头字节是不是编入NRI长度，有没有高人知道？

如果一个SGSN收到来自其他POOL区的RAU，它是怎么解对NRI的？还是这个SGSN要知道所有与其相连的POOL的NRI长度？
顺便请教一下，对于POOL区的source SGSN，dest SGSN如何解析地址？还用DNS么（解析NRI）？还是都本地配置？

爱卫生

回复 hycl5410 的帖子

长度位肯定没有。因为如果有长度位的话，那NRI的最大长度是10 bit。那长度位只要要4个bit才能表示。这样效率就太低了。本来P-TMSI就只有32个bit，还要拿4个bit给长度位。所以SGSN应该都是通过DNS来解析pool里的SGSN的。否则它自己肯定不知道从哪开始是UE ID的部分。问过一个同事，关于DNS上的record类似于下面的格式：

nri-sgsn000C.rac0001.lac12C8.mnc0001.mcc01fe.gprs.