通信人家园

标题: [原创]有高人知道杭州移动SGSN设备采用的哪个厂家的吗？看到SGSN错误的信令流程很纠结 [查看完整版帖子] [打印本页]

时间: 2010-1-13 18:41

作者: 简单的生活 标题: [原创]有高人知道杭州移动SGSN设备采用的哪个厂家的吗？看到SGSN错误的信令流程很纠结

本人目前从事手机侧的协议部分技术支持工作，每次分析到杭州发回来的log时都很纠结，因为杭州的log中移动TD的SGSN这个东东对SERVICE REQUEST流程的处理是错误的。有没有高人知道杭州的SGSN采用的是哪里的设备啊？

本人之前也做过4年的UMTS/LTE协议栈，都是NAS部分的开发测试，对NAS的协议流程比较熟悉，技术支持工作是最近刚换的。

3GPP协议24008上说，SERVICE REQUEST发起场合有三种：
数据触发，信令触发，寻呼触发。

在PMM-IDLE状态下，信令/寻呼/数据触发SERVICE REQUEST，网络侧会发起安全模式控制流程，那么对于MS高层来讲，收到底层的安全信息就认为SERVICE REQUEST流程已经结束，GMM可以离开SERVICE REQUEST INITIATED；

在PMM-CONNECTED状态下，数据触发SERVICE REQUEST，网络侧会发送SERVICE ACCEPT，那么对于MS高层来讲，收到SERVICE ACCEPT就认为SERVICE REQUEST流程已经结束，GMM可以离开SERVICE REQUEST INITIATED；

可是杭州发来的log中，每次PDP激活在空闲状态下发起而触发的SERVICE REQUEST之后，网络侧都会先发起安全模式控制流程，又回复SERVICE ACCEPT。因为MS完成了安全模式控制流程之后，已经认为SERVICE REQUEST流程结束了，又收到SERVICE ACCEPT，当然认为错误了，结果每次都回复一个GMM STATUS消息。

每次看到这个信令，我都特别纠结，可是移动的人貌似又很强势。

虽然之后也还能进行正常的PDP激活流程，但是这无谓的信令交互(有三秒多)，会导致用户在联网时花费稍微稍长的时间，感受上不是很好。

同学们别说是MS自己的问题哦，我看到那么多北京和深圳发回的log，对于这个流程就非常正常，产品还是同一个，在不同的城市就跑出了不同的流程，所以我很肯定杭州移动的SGSN设备对于这个流程的处理有误。

时间: 2010-1-13 18:43

作者: 简单的生活

消灭零回复自己顶一下下

时间: 2010-1-13 18:47

作者: 简单的生活

咋木人理偶捏？

表这么打击新人。。。

时间: 2010-1-13 20:25

作者: 从新开始308

MOTO

时间: 2010-1-14 13:28

作者: fsgod

MOTO和NSN的SGSN

时间: 2010-1-14 19:52

作者: teleinfor

你还是好好学习学习信令流程吧，呵呵。SERVICE REQUEST/AUTH AND CIPHER这个是正常的流程。怎么你那里就不认识了？

你们做的啥手机啊？？？很是怀疑能用么？

时间: 2010-1-18 15:42

作者: dery

PDP激活后发起CM Req是不需要Service Accept的，LZ发现收到了Service Accept。觉得是错的。对不对？

时间: 2010-1-20 22:21

作者: netman2020

杭州移动好像是用NSN的SGSN

时间: 2010-1-21 13:50

作者: leaven

PDP激活后发起CM Req是不需要Service Accept的，LZ发现收到了Service Accept。觉得是错的。对不对？

应该没有Service Accept

时间: 2010-10-20 10:58

作者: 小狗快跑

顶一下，LZ是牛淫。。。。。。。。。。

通信人家园 (https://www.txrjy.com/)