有关IU-PS接口RANAP的问题

ARG

在下最近在看IU-PS接口的数据包，有以下两个问题
1 IU-PS接口的协议栈一般是SCTP----M3UA----SCCP----RANAP这样子，但是当SCCP的message type是DF1时，在SCCP中好像没有字段说明他的上层是RANAP，那怎么判断上层协议究竟是不是RANAP
2 一般用户的附着和pdp激活信息会在RANAP的NAS-PDU单元中，具体报文格式与Gb接口下的一致，但是当数据包含有不同用户的报文时，我如何能过滤出单一用户的报文，就是同一个用户的附着和PDP激活过程，在GRPS中，我可以通过BSSGP层的TLLI作为标准，在IU-PS中如何做到
希望知道的朋友讲一下，谢谢大家~

爱卫生

1 是SCCP层的called pary address中的SSN 142来标识上层是RANAP。
2 参考这个帖子：http://www.gprshome.com/forum.php?mod=viewthread&tid=1957&highlight=。

ARG

首先谢谢版主的热心解答，明白了很多东西
在下还有一些问题
您说RANAP是由SCCP层的called pary address中的SSN标识的，这个我看到了，我想问当SCCP的message type是data form1时，sccp里没有called pary addresscalling pary 或address，那如何看出上层是RANAP
第2个问题我按照帖子中的方法过滤，发现PDP激活的过程是处在一个独立的Iu连接中，并没有和用户的附着在同一个连接中，那我如何把PDP激活过程和该用户的附着过程联系起来，是用RANAP common id中的imsi吗

爱卫生

ARG 发表于 2012-6-28 19:24
首先谢谢版主的热心解答，明白了很多东西
在下还有一些问题
您说RANAP是由SCCP层的called pary address中 ...

是这样的。如果是data form1，是没有SSN来标识上层用户的，这是因为SCCP层的连接已经建立起来了。在data form1类型的RANAP消息建立之前，一定会有一个SCCP层的连接建立过程。因为Iu-C接口使用的RANAP采用的承载协议SCCP是面向连接的。所有Iu-C的信令要传，先要建立好SCCP层的连接（类似Http Over TCP）。这个建立或称是SCCP层的CR(connection request)和CC(connection confirm)两条消息建立的。建立好之后，会分配Source和Destination local reference来在双方标识这条连接及上层用户。后续的话都不会再出现SSN来标识用户了，就通过这个SLR和DLR就可以区分。因为SSN一定是第一个建立连接的SCCP层消息CC和CR里才会出现的。知道这个SCCP层连接被拆除。

common-id可能不行。因为并不是所有的信令流程都有common-id。这个没有办法偷懒。最好的办法也是通过SLR和DLR来区分。

ARG

谢谢版主，第一个问题已经明白了
第二个问题可能是我问的不清楚，我将Iu口的gmm附着请求消息进行过滤，发现附着的过程是一个完整的Iu连接，但是附着完成后该连接就释放了
那么如果要发起PDP激活就要重新建立连接，此时SLR和DLR就应该已经变了吧，那么我想问我如何知道这个PDP激活对应的是哪个UE的附着，因为最终我想取得一个用户完整的附着和PDP激活过程
再次谢谢版主~

hycl5410

ARG 发表于 2012-7-2 10:39
谢谢版主，第一个问题已经明白了
第二个问题可能是我问的不清楚，我将Iu口的gmm附着请求消息进行过滤，发现 ...

楼主描述的情况很常见的。原因在于W有PMM-IDLE这个状态。提一个思路供参考，当用户在PMM-IDLE下，想激活PDP的话，是会先发service request（type=signaling），这里是带P-TMSI的，用这个可以过滤出下一个IU连接的第一个包。
之后的事情就简单了。wireshark有自带的SCCP分析功能，点上之后会把所有相关信令都弄一块去。

right click the SCCP protocol stack of that message and choose “Protocol Reference” -> “Trace Associations”
Then there will be Association ID shown in SCCP stack
right click the Association ID and choose “Apply as Filter” -> “selected”

如果不幸遇到了P-TMSI变化，那么只好一跳一跳的找了，虽然麻烦，但是可以把从ATTACH之后所有事件都过滤出来，估计这个也是楼主希望得到的吧。

另外吐槽一下ITC，做个UE的全接口trace就那么难么？而且做成这德行都能拿去卖钱，真不知是让谁情何以堪啊。。。

ARG

好的，基本了解了，谢谢大家！