sgsn pool中的default sgsn有什么用?为什么每个pool里的sgsn都需要配置相同的nri表? 如下图: 在本图中,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表是完全一样的。 |