51学通信技术论坛

标题: paging response后网络侧发起pdp deactivate [打印本页]

作者: z36306610 时间: 2011-9-13 14:29:50 标题: paging response后网络侧发起pdp deactivate

统计paging response后信令发现有几下几个问题:
1、paging response后是否一定需要rab分配？
2、paging response后网络侧发起deactivate，哪些情况网络侧会触发deactivate
3、service request rab建立成功后一段时间RNC发送iu release request消息，其中原因值主要为ue-generated-signalling-connect-release和network optimization，请问这两类原因主要发生情况？看有关资料ue-generated-signalling-connect-release主要是终端触发的，network optimization主要是RNC触发的，由于只有iupscp的数据，所以无法看到最后一个数据包和iu release request之间的时长，所以这两个定时器的时长如何设置不太清楚，望高手指点！

作者: 爱卫生 时间: 2011-9-13 16:47:47

回复 z36306610 的帖子

我先说下前两个问题。第3个问题得去查查资料再说。
1、paging response后是否一定需要rab分配？
不一定。因为RAB仅用于用户面的payload传递，而信令面对应的承载是一个Iu Connection。所以如果这个paging是因为有一个网络侧发起的信令，那完全不需要分配RAB。本例就是这样，网络侧发起的去激活，要去找这个PMM-IDLE状态的UE。
2、paging response后网络侧发起deactivate，哪些情况网络侧会触发deactivate
很多情况。SGSN/GGSN/HLR都可以发起。GSN节点通常可以设置PDP Context Inactive Timer，超时将发起去激活。另外如果用户欠费了，或者PS业务关闭了，或者违反了运营商的策略规则例如每月流量超过了10个G等等。那PCRF可以通知GGSN将用户去激活，HLR也可以通过cancel location消息通知SGSN将用户去激活。
3 这个cause在TS25.413中定义的。可以再去查下规范。

作者: z36306610 时间: 2011-9-14 10:31:35

通过数据统计发现从pdp activate到net pdp deactivate的时长非固定的，有2分钟、15分钟，但大部分是10分钟，您提到的PDP Context Inactive Timer在诺西设备里有吗？我在ned中没有找到这个timer，从某个用户流程统计推测是不是有这种可能性，用户的某个后台软件开启后会自动要求pdp 激活，但pdp激活后用户并没有流量产生，RNC定时器超时，发起iurelease request，cause为network optimization，15分钟后用户网络侧认为用户pdp inactive 所以发起deactivate请求。这里比较费解的就是这个inactive time不固定。

作者: 爱卫生 时间: 2011-9-15 17:10:29

z36306610 发表于 2011-9-14 10:31
通过数据统计发现从pdp activate到net pdp deactivate的时长非固定的，有2分钟、15分钟，但大部分是10分钟， ...

  先来回顾一下Iu connection释放的几种情况，华为有篇文档叫“WCDMA Iu接口协议介绍”。可以在百度文库下载或在线阅览。http://wenku.baidu.com/view/faf106db50e2524de5187ef4.html 第20页有明确提到Iu连接释放的几种场景。摘过来如下：
“Iu连接释放原因正常情况下都是由CN主动发起Iu释放，CN主动发起Iu释放的原因：
- UE和CN间事务结束
- CN接收到了IuRelease Request消息
- SRNS的重定位结束
RNC只有在接入侧发生异常的情况下才会发起Iu释放请求，其主动发起Iu释放请求的原因有：
- O&M 干预
- 非特定原因
- 用户非活动态
- 一致性检查失败
- UE产生的信令连接释放与UE的无线连接丢失”
  这个说法和23060是基本吻合的。或者简单一点来说，在包里看到Iu Release Request消息，那一定是RNC因为某种异常请求SGSN来释放一个Iu连接。因为核心网才具备管理控制功能。RAN相对于核心网来说只是用户面，要听从核心网的指挥。
  另外，Iu连接的释放还涉及到用户MM状态的切换，将会从PMM-CONNECTED切换到PMM-IDLE。
  第三，UE可以在Attach Request和RAU Request消息中将Follow-on Request Pending bit置1，这样SGSN收到这个请求后，给UE发attach accept或RAU accept后，不会释放Iu连接。因为这个bit置1，代表UE接下来马上会有消息或数据要发送，需要核心网延长Iu连接。反过来，如果没有置1，则SGSN将马上释放掉这个Iu连接。这个是在TS24008中有说明的，见4.7.3.1.1 GPRS attach procedure initiation----
In UMTS, if the MS wishes to prolong the established PS signalling connection after the GPRS attach procedure (for example, the MS has any CM application request pending), it may set a follow-on request pending indicator on (see subclause 4.7.13).
  你的包里这个bit没有设置为1，所以SGSN将在attach或RAU流程之后立即释放掉Iu连接，UE进入到PMM-IDLE。后续如果有下行数据的话将对UE进行寻呼。

  那个PDP Inactivy Timer我不知道在诺西里面有没有，但如果有的话，应该不在SGSN这里。有可能是在GGSN上。可以找找GGSN的手册看看。另外，网络侧发起的去激活有很多种情况，上篇回复已经列举出了一些。所以并不见得一定是因为PDP Inactivty Timer超时所触发的。如果有核心网的抓包的话，可以对照看看。例如如果是HLR发起的去激活，那应该有cancel location消息，如果是GGSN发起的，则应有GGSN发给SGSN的delete pdp context request消息。如果是SGSN直接发起的，则Gn和Gr接口都不会有由HLR和GGSN下发的去激活信令。

  最后，你说的那种情况PDP激活后用户没有流量产生，RNC定时器超时发起Iu release request我觉得是有可能的。但我觉得这种情况应该cause值不是network optimization(116),而是user-inactivity (16)。network optimization我查了一下，在2000年TS25.413的V3版本就出现了，并且只给出了含糊的说明，并且将这个原因值归到了杂类项，应该是不太常见的原因值。并且留给了厂家自由发挥的空间。例如RNC需要将流量从板卡1切换到板卡2，算不算network optimization呢？这个就看各厂家具体的实现了，规范并没有定死。

作者: 爱卫生 时间: 2011-9-15 17:19:45

回复爱卫生的帖子

  关于User Inactivity在TS23060的12.7.3 Iu Release Procedure章节中还有说明：
“The RAN notices that the RRC connection has been released or detects a need to release the radio resources. It sends an Iu Release Request (Cause) message to the SGSN. Cause indicates the reason for the release (e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated Integrity Checking Failure, or Release due to UE generated signalling connection release). User Inactivity means that the RAN decided to release an MS that shows no more activity, in the case where the MS has only non real-time RABs established, in order to optimise the radio usage after the RRC-Connection-Release timer expired.”
  因此，如果你看到在包里有Iu release request消息由RNC因为User Inactivity的原因请求SGSN释放Iu连接，那实际上是由RNC侧的RRC-Connection-Release timer来监管的。
  最后，需要说明的是Iu连接的释放和PDP上下文的去激活是两个完全独立的流程，可以分别执行。也就是有可能在PDP上下文去激活之前Iu连接就已经释放了。所以在这里首先要确定你提到的2分钟、10分钟时间不固定是针对PDP去激活，而不是Iu连接的。然后根据核心网侧的包去看下是谁发起的去激活，SGSN/GGSN还是HLR。再到对应的节点上去找有没有关于PDP Inactivty Timer的配置。如果没有，看有没有默认值。然后观察一个用户，确认在这个Timer期间，UE和SGSN之间确实没有流量交互。因为这个很难说，比如QQ的心跳包等等。

作者: z36306610 时间: 2011-9-16 14:15:18

结合IUPS+GN接口发现是GGSN发起的delete pdp request，同时出现这种类似情况均是漫游用户造成的，附件中的流程似乎与规范中的流程不太一致，3GPP 23060 9.2.4.3中1、GGSN send delete pdp context request to sgsn 2、sgsn send deactivate pdp context request to UE 3、ue send deactivate pdp context accept to sgsn 4、sgsn send delete pdp context response to ggsn。而抓包流程是delete pdp完成后才deactivate pdp。还有一个问题想请教一下什么情况下会触发delete pdp请求，同时通过诺西traffic查询这个deactivate 请求是由于ggsn_initiated_c 0x39 = Indicates that a GGSN-initiated PDP Context Modification is started，而抓包数据中并没有Modification过程啊，如何解释？请斑竹赐教，谢谢！

作者: 爱卫生 时间: 2011-9-16 22:09:34

本帖最后由爱卫生于 2011-9-16 22:10 编辑

回复 z36306610 的帖子

  一起交流吧。赐教谈不上。GGSN发起delete pdp context request消息会有很多种情况啊，上面的回复也介绍过。例如GGSN上的pdp context inactive timer超时，或者GGSN上手工删除了用户数据或发生了板卡重启或用指令将GPRS service挂起，或GGSN收到BOSS系统的指令要求将用户去激活（因为用户超过每月流量的上限需要关闭GPRS服务），或者收到OCS的请求要求GGSN将用户PDP Context删除（因为用户欠费了）。
  在这个例子里，我感觉还是在GGSN上的pdp context inactive timer超时引起的。因为在460013820696545.pcap这个文件中，UE的PDP上下文激活是在#10号包，1.53秒。而GGSN发起delete消息给SGSN是在#18号包，901.42秒。正好相隔900秒，也就是15分钟，这也太巧了。
  包里的流程与规范确实有出入，个人感觉是不是因为SGSN没法给UE发deactivate pdp context消息，因为Iu连接已经在之前被释放掉了，所以SGSN发起了一个paging，paging之后才是SGSN给UE法的deactivate pdp context request消息。
  最后你的问题说GGSN的cause #39是modification流程，这个就真不知道了。盼高手给你解答。

作者: z36306610 时间: 2011-9-18 14:42:27

统计发现部分是湖南漫游过来的用户，后通过和（湖南PS工程师）联系，是由于湖南的GGSN PDP lisence不够，所以设置了Session time out为10分钟，也就是用户激活后10分钟没有流量就会发起去激活。呵呵，谢谢版主解答

作者: feile99 时间: 2011-9-19 22:01:33

回复爱卫生的帖子

回复一下问题3：

问题3出现由无线侧主动释放RRC连接，进而释放Iu口的连接。
在无线侧有一个feature叫做fast dormancy。一般是在无流量的情况下，
可以是：1. UE发起， UE发signaling release indication给RNC，RNC收到后释放RRC，Iu口
2. 后面规范发展由RNC来根据无流量的时间长短进行主动释放，不需要UE参与。

可以搜索一下fast dormancy的功能解释......

作者: 爱卫生 时间: 2011-9-19 23:25:21

feile99 发表于 2011-9-19 22:01
回复爱卫生的帖子

回复一下问题3：

谢谢补充哦。找了TS25331规范，找到了你说的UE发起的信令连接释放指示，在TS25.331 V8.10.0的8.1.14章节有介绍这个流程。部分说明如下：“the UE may determine whether any subsequent indications from upper layers that there is no more PS data for a prolonged period in which case it triggers the transmission of a single SIGNALLING CONNECTION RELEASE INDICATION message according with clause 8.1.14.2。”

作者: z36306610 时间: 2011-9-20 10:38:20

release 8之后的终端会有release cause为“UE Requested PS Data Session End”。对于release 8之前的手机那时候协议中没有定义，就不会有这种原因值的释放请求。release 8之前手机的释放原因值应该和普通的手机主动拆线携带的原因值是一样的，RNC上有个feature可以控制fast dormancy。但这个feature只有在pch存在的情况下才会起作用。

作者: arrowbroken 时间: 2011-10-12 14:13:24

回复爱卫生的帖子

对于GGSN的cause #39是modification流程，

这个可以理解DELETE PDP 也是一种特殊的MODIFICATION吧，这个cause 39是厂家自己内部定义的一些错误代码，并不一定像规范一样有严格的严谨性，不要太纠结！

作者: 爱卫生 时间: 2011-10-12 20:57:14

回复 arrowbroken 的帖子

谢谢指教！感谢！

作者: arrowbroken 时间: 2011-10-13 09:54:23

回复爱卫生的帖子

大家同勉！敬佩爱总得专业精神

作者: syluofeng 时间: 2012-9-21 11:53:00

谢谢楼主，学习了

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)