实际环境中PS分组域中寻呼GPRS业务Paging-PS（Paging for GPRS services）所存在的场

爱卫生

   对于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了。

爱卫生

jsmccjimmy 发表于 2011-8-1 17:26
是不是可以这么理解，网络侧发起寻呼的前提是MS必须建立过PDP激活？这样GGSN才能根据激活的IP地址找到SGSN， ...

  你说的一半对一半不对。说对是因为要寻呼MS，MS一定要有一个已经建立的PDP上下文，并且MM状态是在Standby。说不对是因为网络侧发起寻呼的前提并不是MS建立过PDP激活，而是MS处在Standby状态。
  另外，寻呼的发起者是在SGSN，而不是GGSN。GGSN收到Gi口的下行数据，通过GTP-U发给SGSN，SGSN发现这个用户是在Standby状态，这时候要开始缓存下行数据，等收到用户的确认后才删除。
  GGSN准确点说，是根据用户的PDP上下文找到SGSN，因为在创建PDP上下文过程中，GGSN会和SGSN分别交互用户面上下行方向的IP地址和TEID。GGSN通过SGSN用户面的TEID和IP地址就可以找到SGSN了。

爱卫生

samsin 发表于 2011-8-27 19:21
有点咬文嚼字了，什么是“前提”，只有RA（等价MM state standby）是前提、有下行数据是前提、有成功激活过 ...

  我说明一下，本帖主要侧重于讨论国内现网中寻呼有可能出现的场景，并且不讨论联合寻呼，只讨论针对数据业务的寻呼。当然在3GPP规范中还有可能出现很多寻呼的场景。不好意思，没有说清楚。
  谢谢samsin的补充，针对你的观点我说下我的看法。
1 你提到的RA是指的RA更新吗还是什么？如果是RA是PS域寻呼的原因，可能不对吧。因为RA更新本身和寻呼没有关系。
2 针对你提到的“前提”的定义，应该就是指的寻呼流程能够正常完成的必要条件，假设网络各接口都工作正常的情况下，我很同意你的观点，就是MS一定要有一个已经激活的上下文，即PDP上下文状态要是active的。另外一个前提条件就是MS是处于MM的standby状态。这两个条件缺一不可。
3 G-GSN是如何找到对应的S-GSN的？实际上又扯到上面的第2点了。分两种情况，如果用户只是在standby状态，但没有PDP激活，那GGSN是无法找到SGSN的，这时就只能给用户一个短信，通知有彩信等数据业务到达，然后用户做PDP激活再去取。所以GGSN要找到对应的SGSN，这个用户必要是有一个已经激活的PDP上下文，这点我们的观点是一致的。
BTW，
   你提到的问题，我记得好像论坛有一篇帖子提到过，但我也一时找不到，顺带在这里解答下。你也可以在论坛搜索GTP关键字，可能会找到一些你需要的东西。
1）如果只是纯信令消息，例如PDP的激活。则GTP-C协议栈为
GTP-C  --- 使用控制面TEID
UDP ---- port 2123
IP ---- 源IP为SGSN GTP-C IP，目的IP为GGSN GTP-C IP。都是公网IP，因为有可能涉及到运营商之间的国际漫游。
ETH ---- MAC地址逐跳改变。
2）如果是用户面消息，例如MS去访问一个新浪服务器。则GTP-U协议栈为
HTTP
TCP
IP ----- 源IP为MS IP，目的IP为新浪服务器IP。如果是走cmnet这个APN，则MS IP为私网地址，新浪服务器为公网地址。
GTP-U ---- 使用用户面TEID
UDP ---- port 2152
IP ----  源IP为SGSN GTP-U IP，目的IP为GGSN GTP-U IP。都是公网IP，因为有可能涉及到运营商之间的国际漫游。
Ethernet
   以上SGSN/GGSN侧的GTP-C和GTP-U地址规范并没有说不允许重叠，是允许相同的。设置不同的GTP tunnel是因为要做Qos，因为每个用户的Qos都不一样。需要在Gn接口进行映射，保证每个用户的公平使用。
  不知道以上有没有回答你的问题。{:soso_e100:}

爱卫生

samsin 发表于 2011-8-30 18:16
3 G-GSN是如何找到对应的S-GSN的？实际上又扯到上面的第2点了。分两种情况，如果用户只是在standby状态，但 ...

  呵呵，是我不好意思，这个系统是免费系统，可能是有些问题。
  两个问题说下我的看法。
1 "对这点有点疑问，我认为不管MS是否处。。。"
   答：这点可以明确答复，如果MS没有一个active的PDP上下文的话（也就是如果这个用户只是开机做了附着，ready timer超时后停留在standby状态而从没有做PDP激活，实际上很多上班族都是这样的），GGSN并不能发起所谓的请求PDP激活。这一点现网是不支持的。因此GGSN有一个接口Gc接口没有开。所以GGSN并不能在没有任何帮助（例如依赖已有的PDP上下文关联）的情况下主动找到SGSN。Gc接口是GGSN到HLR的接口。
2 "对于 RA的问题：。。。"
   答：对啊。这点我们的观点是一致的啊，呵呵。你的问题是？或者是我没理解清楚你的问题，呵呵。

爱卫生

  有道理啊，这种情况应该还很普遍哦，很多用户都有这样的习惯。谢谢补充！

爱卫生

回复 arrowbroken 的帖子

  非常感谢！说的很中肯。
  标题已改为PS分组域中寻呼所存在的场景，不知这样是否不容易引起混淆？
1和3 完全同意，已修正.
2 也完全同意。已更改为“这时QQ服务器和MS之间会有周期性的信息交互，例如手机QQ像服务器周期性报告是否在线，从而将状态切换为离线，在线等，还有服务器经常发的系统广播消息都会触发寻呼”。
  
  很感谢啊！能帮忙发现问题，这样就避免误导别人，还有一些不太准确的词语也容易引起误解，是一定要更正的，保持严谨吧。