sgsn pool中的default sgsn有什么用?为什么每个pool里的sgsn都需要配置相同的nri表?
如下图:
[attach]3226[/attach]
在本图中,SGSN1属于pool 1。sgsn11和sgsn13属于pool2。
sgsn1还有sgsn2和sgsn3(未在信令流程图里给出)组成pool1。这3个sgsn上要配置相同的nri表。如下:
nri sgsn sgsn ip 服务的RA
1 sgsn1 10.1.1.1 ra1、ra2和ra3
2 sgsn2 10.1.1.2 ra1、ra2和ra3
3 sgsn3 10.1.1.3 ra1、ra2和ra3
右边的sgsn11和sgsn13和sgsn12(sgsn12在图上未画出)组成pool 2。这3个sgsn上要配置相同的nri表。如下:
nri sgsn sgsn ip 服务的RA
11 sgsn11 20.1.1.11 ra11、ra12和ra13
12 sgsn12 20.1.1.12 ra11、ra12和ra13
13 sgsn13 20.1.1.13 ra11、ra12和ra13
inter-ra更新过程中图上的信令场景,一定是在pool的边界才发生的。因为如果是同一个pool的话,是不会发生跨sgsn的ra更新的,同一个pool内总是由同一个sgsn为用户提供服务,不管用户在pool的哪个ra下。
结合本信令流程,ue开始是在sgsn13下(即pool2),sgsn13给ue分配了pt-msi(nri=13),并且sgsn13所对应的ra是ra13。
接下来ue从ra13移动到了pool1的服务范围,也就是sgsn1的服务区ra1。
首先ue发了ra更新请求给sgsn1,里面携带了old-ptmsi(包含了nri=13)和old rai=ra13。由于sgsn13属于pool2,sgsn1上的nri table并没有sgsn13的nri映射关系,因此后续的sgsn context request消息不知道往哪发。
这时候sgsn1上有两种方式获取sgsn13的ip地址以发起后续的信令流程(gtp-c的sgsn context reuqest消息)。
1 在sgsn1上配置缺省sgsn和相邻的ra(本例中卫sgsn11),相邻的ra是ra13。这样sgsn1可以将sgsn context requet请求发给sgsn11,消息中包含了(nri13和ra13),缺省sgsn(sgsn11)是属于pool2的。所以sgsn11上的nri table中有nri13和sgsn13的ip地址的对应关系。这样sgsn11可以把该消息转发送给正确的sgsn13来完成后续的inter-sgsn ra更新过程。
2 还有一种方式是通过dns来查询。通过dns查询又有两种方式:
2.1 dns支持基于nri的查询(增强方式)
sgsn1在送给dns的查询请求是发送的nri13,dns基于nri来查询,直接返回sgsn13的地址。后续的信令消息由sgsn1直接发给sgsn13,不通过缺省sgsn。
2.2 dns不支持nri的查询(传统方式)
sgsn1在送给dns的查询请求是发送的old rai(即ra13),dns基于rai来查询,返回的是缺省sgsn的地址(即sgsn11),后续的流程和方法是一样的。
所以综上所述,pool内每个sgsn都需要定义池组内其他sgsn的nri和ip地址的映射关系,换句话说:池组内所有sgsn的nri表是完全一样的。
欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/) | Powered by Discuz! X2 |