本帖最后由 爱卫生 于 2011-10-19 13:58 编辑
对于PS中寻呼的定义是这样子的: 在用户GMM状态为standby下(3G类似),如果有下行数据过来,SGSN会在RA范围内对MS进行寻呼。 这里要弄清楚三个问题。 1)下行数据过来要发给standby状态下的MS,那GGSN首先要将下行数据发给SGSN,但网络中又没有Gc接口,GGSN也不负责移动性管理,GGSN又怎么知道要找哪个SGSN呢(有可能这个MS只是做了附着然后切换到standby状态,而附着是不需要通知GGSN的,所以GGSN并没有在附着阶段存储和SGSN的映射关系)? 答:其实,所有的下行给MS的数据业务,即网络侧发起的下行业务包括彩信,手机报等。实际上都是先给MS一条短信。然后MS去发起激活流程去网络侧的Server上去取。实际上还是MS发起的。因此这个过程并不涉及到寻呼。
2)如果彩信,手机报这些看似网络侧直接发起的下行数据业务,并没有经过寻呼,那到底什么场景需要寻呼呢? 答:实际上,最常见的一种场景还是等ready timer超时,即默认的44秒。MS和SGSN都会将MM状态从ready切换到standby,你可能会问,不会吧。如果是这样的话,那就是说: 当MS在浏览网页时,44秒ready timer超时,切换到standby状态。这时有下行数据过来SGSN会寻呼。出现这种情况可能就是:1个宽屏手机,屏幕大,信息量大。 MS在44秒还没翻页就切换到standby状态了。那 1) 如果MS再点翻页按钮的话,也是MS发起的流程,不涉及到寻呼。 2) 如果MS不点翻页按钮,那网络侧也不会有下行数据过来啊。 除非是: 3) MS发了一个浏览网页的请求给HTTP Server,但HTTP Server在44秒内都没响应,MS切换到standby。然后HTTP Server在45秒即以后回了响应。但怎么可能呢?IP承载网也太烂了吧 。 实际上,上述说的逻辑上都是对的。只不过忽略了一些具体的手机应用。最常见的就是手机QQ。QQ服务器为了探测手机QQ是否在线(因为很多手机开了QQ就一直挂在那,不发任何消息,和server没有任何交互。这时QQ服务器和MS之间会有周期性的信息交互,例如手机QQ像服务器周期性报告是否在线,从而将状态切换为离线,在线等,还有服务器经常发的系统广播消息都会触发寻呼)。而这个消息的timer一般非常短,所以SGSN收到后就会非常频繁的发起寻呼,从而将MS的状态切换到ready。但44秒后,MS状态又会切换到standby,这样不断循环,将特别频繁的去消耗空口资源。因此,在实际网络中,有可能针对某种特殊的应用,来相应的调整ready timer的值,最好就是ready timer的值大于这个应用服务器去探测客户端的周期性timer的值,就可以解决这个问题了。
3)第二个问题里,其实还隐含了一个问题。那就是为什么手机QQ的寻呼请求,GGSN可以将这个下行数据发给SGSN,而彩信、手机报这些业务却不行,只能通过短信,然后MS去server去取呢? 答:其实很简单。如果是QQ的话,MS在PS附着完成后,实际上还要做一个QQ的登录过程,状态会变成隐身、在线等各种状态。而QQ的登录过程,实际上是包含了MS的PDP上下文激活过程。因此实际上MS登录了QQ之后,是有一个IP地址的。那如果有下行的数据过来(例如QQ Server发的探测消息),GGSN其实并不知道这个消息需不需要寻呼,而是将这个IP包(其实QQ Server发的探测消息就是个普通的IP包)通过Gn接口找到SGSN,怎么找对应的SGSN呢?根据MS的IP地址就可以了。如果是MS的多个PDP上下文,还要加上TFT,就可以定位到SGSN,以及对应的PDP上下文了。而彩信这些业务,手机开机只是做附着,并不需要到彩信服务器上登录,因此并没有做PDP激活,因此GGSN上没有关于MS的地址信息等来完成和SGSN、PDP上下文的映射。自然也就无法完成下行方向的路由到SGSN了。 |