51学通信技术论坛

 找回密码
 立即注册
搜索
查看: 5705|回复: 8
打印 上一主题 下一主题

S1接口SCTP的问题 [复制链接]

Rank: 2Rank: 2

跳转到指定楼层
楼主
发表于 2015-1-22 11:57:01 |只看该作者 |倒序浏览
一键分享 一键分享
各位大神,我所做的需求是对S1接口的数据进行采集分析,提取出UE的相关信息(承载和GUTI等)有几个问题存在:
1.EnB和MME之间标识S1逻辑连接的是ENb_S1_ID和MME_S1_ID,但是在使用中可能会将多个EnodeB和MME的数据汇聚在一起,因此可能会存在不同的S1接口上分配的ENb_S1_ID和MME_S1_ID(一致的情况),那么我就无法区分汇聚的数据相同的ID的两个UE了,请问下各位有什么区分的办法或者参数吗?我想过使用IP,但是因为传输层为SCTP,IP地址可能会变化,如果使用其作为key或者查找条件建hash表也不行。

2.SCTP的偶联建立一般在什么情况下建立或重建,一个S1物理接口是不是只会存在一个偶联建立?对于1中存在的问题,可不可以通过分析SCTP的init和initack来知道两端可能存在的ip地址去解决?我个人觉得不可行。
希望各位给点意见,谢谢了。

Rank: 9Rank: 9

沙发
发表于 2015-1-27 09:49:53 |只看该作者
先回答第二个问题。SCTP的偶联建立是通过4次握手(上层协议触发的),就和TCP一样的,TCP连接也是上层例如HTTP触发建立。所以S1接口的偶联就是由上层S1AP触发,S1AP有一个S1 Setup流程,会触发建立SCTP偶联。
S1-MME接口可以有多个偶联。
51学通信(www.51xuetongxin.com):致力打造最好的通信技术在线学习平台 。

使用道具 举报

Rank: 2Rank: 2

板凳
发表于 2015-1-27 11:11:37 |只看该作者
admin 发表于 2015-1-27 09:49
先回答第二个问题。SCTP的偶联建立是通过4次握手(上层协议触发的),就和TCP一样的,TCP连接也是上层例如H ...

多谢回复!我看到华为的资料里面说明两个端点之间只能建立一个偶联啊,就是说一个EnodeB和一个MME之间只能存在一个偶联,这个偶联提供给这个S1接口的多个用户使用吧?而不是一个用户UE会存在一个偶联吧?多谢了

使用道具 举报

Rank: 9Rank: 9

地板
发表于 2015-1-27 14:12:19 |只看该作者
tracy 发表于 2015-1-27 11:11
多谢回复!我看到华为的资料里面说明两个端点之间只能建立一个偶联啊,就是说一个EnodeB和一个MME之间只能 ...

对。是给多个用户共用的。建可以建多个啊,但用的时候,就只有1个啦。
51学通信(www.51xuetongxin.com):致力打造最好的通信技术在线学习平台 。

使用道具 举报

Rank: 2Rank: 2

5#
发表于 2015-1-27 20:15:05 |只看该作者
tracy 发表于 2015-1-27 11:11
多谢回复!我看到华为的资料里面说明两个端点之间只能建立一个偶联啊,就是说一个EnodeB和一个MME之间只能 ...

偶联的目的是啥。。。。。。。是为了给SCTP协议报文传输路径做可靠性备份,主链路出错的时候fallover,恢复的时候fallback。


使用道具 举报

Rank: 2Rank: 2

6#
发表于 2015-1-27 20:19:52 |只看该作者
只要UE-context一直存活着,在同一个MME下,GUTI与M-TMSI一致,都可以表示一个唯一UE。

使用道具 举报

Rank: 2Rank: 2

7#
发表于 2015-1-28 10:50:59 |只看该作者
frameworks 发表于 2015-1-27 20:19
只要UE-context一直存活着,在同一个MME下,GUTI与M-TMSI一致,都可以表示一个唯一UE。

嗯 我知道MME范围内M-TMSI可以唯一标识UE,但是不是所有的S1接口的数据都包括这个。我只能通过ENB_S1_AD和MME_S1_ID去提取UE。但是如果跨MME的话我要唯一标识UE,就只能通过MME的标识+ENB_S1_AD和MME_S1_ID了。

使用道具 举报

Rank: 8

VIP 论坛核心会员 特殊贡献奖

8#
发表于 2015-1-28 14:10:27 |只看该作者
本帖最后由 hycl5410 于 2015-1-28 14:11 编辑

这就是外部抓包的局限性了。
如果能抓到s1-setup(enb与MME之间,不涉及UE任何信息)过程和sctp association建立过程,那么可以根据global-ENB-ID把enb地址(可能有多个)跟实际enb对应起来,或者这么说,把MME跟enb之间的SCTP association对应起来。
这样就不怕ENB_S1_AD重复的问题了(仅针对多enb可能分配相同ID场景,不保证同一enb释放后重用场景)。

在不满足以上条件的情况下,根据IP来区分enb也许是可行的,很多情况下enb就只有一个S1-C的业务地址,但是MME可能有很多个S1-C地址。
如果没有MME pool的话,enb只连一个MME,这种方法的可操作性就更大一些,一个enb连接多个MME的话需要增加MME地址,跟enb地址一起组成index。。。


或者有条件的话,能拿到enb和MME网元地址规划表,就会对可能的SCTP association的地址组合做出判断。

总之一句话,简单通过外部抓包来匹配所有信令流程不那么容易(否则MME还搞个P啊)。
而且这还是NAS不加密的时候能看到GUTI,NAS加密了的话就彻底别搞了。

另:enb侧有可能会支持UE trace的一个部分功能,把所有跟UE相关的S1连接信息都记录下来。具体叫什么名字记不住了。

使用道具 举报

Rank: 2Rank: 2

9#
发表于 2015-1-28 14:25:10 |只看该作者
hycl5410 发表于 2015-1-28 14:10
这就是外部抓包的局限性了。
如果能抓到s1-setup(enb与MME之间,不涉及UE任何信息)过程和sctp associati ...

嗯 多谢多谢。至于NAS加密的事情再说了。现在就是这样打算的。就是使用SCTP的主通道,如果主通道出现问题切换其他通道导致IP对不上,那么对这个UE的跟踪结束就结束了。因为实在是没有什么其他好的办法了。不像iu接口一样,还可以通过MTP3层的信令点码进行区分不同的设备。很感谢你的回复。因为就我一个人看很多事情都在纠结着。

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-4-19 20:55 , Processed in 0.024120 second(s), 12 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部