[原创]有高人知道杭州移动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设备对于这个流程的处理有误。