Initial Attach and Tunnels towards multiple APNs (示意图）

wenliu

找到了一部分运营商对自己网络的介绍信息。不过原文不好贴上来。。翻译部分内容出来以完善对这个网络拓扑图的解释。附件中对于OFCS的链接点改变了，从PGW 移到到SGW上，附件已经更新 。 （开始理解29212有误，以为OFCS和OCS都连像了PCEF，也就是PGW, 其实规范中写的是Gateway，也可以在SGW上。在SGW 上应该更make sense，毕竟SGW是用户面数据的掌控点）

目前对LTE+IMS+Other PDN的假定：
1. UE 可以连接到如下的PDNs：
   A. IMS PDN使用 IPV6地址（IMS PDN -- 开机登入）
    --- IMS Apps： 短信 & 呈现业务
    需要建立的用户面
    --- 默认承载
    --- SIP 专用承载

2. App PDN tye 使用 IPV4V6地址分配原则 （On Demand） （意思只有当用户发起时才会建立?)
   --- 只有默认承载

3. Internet PDN 使用 IPV4V6地址分配 （PDN created On Demand）
   --- 只有默认承载

4. Admin PDN 使用IPV6地址 (PDN created On Demand）
   --- 只有默认承载

5. 企业PDN  使用IPV4V6地址  （PDN Created On Demand）
   -- 只有默认承载
   -- 每个企业PDN都有专属的PDN 名称
   -- 企业UE 不允许访问 Internet PDN

6. 固定IP地址PDN （PDN Created On Demand）
   -- 只有默认承载
   -- UE 使用静态分配的IP，需要连接到指定的PGW上。

在初期，UE只允许同时连接到3个PDN上。

图中用三种不同颜色的线标示了3个不同的APN。
另外图太大，截图截不下来，原图中还包括了计费中心的 diameter 链接，放在附件中给大家下载。 计费的方式由 PCRF 推送给PGW。
UE initial Attach 的时候是连向了xxxims 这个APN， 因此首先建立了 和xxxims 的defuault Bearer 以及跑SIP 信令所用的dedicated Bearer。随后UE 再通过PDN Connectivity Req, 建立了另外两条default Tunnel。

从现场PCAP看到，MME 和SGW之间只有一条Control Plane 存在， 但是在SGW 和PGW 之间，对于每条default Bearer都用相互独立的Control Plane在控制。

因为PCAP里有点用户信息，不好直接放上来给大家对照。
如果大家对图中某段流程有兴趣，我可以截下相关部分的pcap贴出来给大家参考。

hycl5410

图画的真好~~赞一个~~

snakend

楼主的图，真心不错，多谢分享！

watson100

楼主真用心，如果能把pcap共享就好了。

wenliu

watson100 发表于 2012-12-22 12:28
楼主真用心，如果能把pcap共享就好了。

毕竟是从公司途径拿到的现场的traffic，不大好直接放给大家下载。不过如果大家对其中有一部分message 内容有兴趣，我可以把用户数据抹掉，重新做一段pcap出来给大家，但是全做的话，量太大了点。。

watson100

谢谢楼主呀，我对如何触发dedicated bearer很感兴趣，是不是由Rx口触发的呢？

wenliu

watson100 发表于 2012-12-24 13:56
谢谢楼主呀，我对如何触发dedicated bearer很感兴趣，是不是由Rx口触发的呢？

Rx是AF 和PCRF 的接口吧。  目前我拿到的PCAP中，关于PCC 推送的部分只有Gx interface，位于 PCEF 和PCRF 的。因为需要为IMS注册信令建立用户面，所以得提前建立承载SIP 信令的 dedicated Beaer，这部分的QOS要求不需要AF的参与，所以用不到Rx。


Rx 接口的规则，我推测是发起VOIP call 的时候，由PCSCF 在收到 SIP 最终相应 200 OK 时，通知 PCRF用户应用层的事件，然后PCRF 根据应用层QOS要求，转换成承载层的QOS要求，然后下发给PCEF（PGW), PGW 再开始建立 dedicate Bearer 用来承载RTP流。



我待会贴一段Gx interface CCA消息中，有关这Policy 和Charing 的AVPs

wenliu

CCA , GX PCRF->PCEF， 在Charging-Rule-Install 中有有两条Charging-Rule-Definition-AVP，分别对应了对于xxxims 这个APN所要建立的beaer的Policy和Charing信息。
从第二张截图中，具体到QOS-Information，可以看到QCI的信息。并且通过Flow-Description AVP，可以看到随后的TFT的信息。 SIP 是用5060端口做filter。 其他为default  服务的是any to any。

我感觉有趣的是，Precedence AVP, 规范上讲是值低的优先级越高，这个优先级不晓得在那个地方体现。是用户的数据流首先采用5060 这个TFT来过滤？ 如果没有匹配的，再用any to any 这个TFT来匹配？ 这个地方就不晓得具体实现了。

watson100

wenliu 发表于 2012-12-25 09:22
Rx是AF 和PCRF 的接口吧。  目前我拿到的PCAP中，关于PCC 推送的部分只有Gx interface，位于 PCEF 和PCRF ...

这个例子里面用户已经建立IMS这个APN的dedicated Bearer了，这个bearer是AF触发的吗？

hycl5410

我感觉有趣的是，Precedence AVP, 规范上讲是值低的优先级越高，这个优先级不晓得在那个地方体现。是用户的数据流首先采用5060 这个TFT来过滤？ 如果没有匹配的，再用any to any 这个TFT来匹配？ 这个地方就不晓得具体实现了。
个人理解应该是这条rule的优先级，因为不同的rule的TFT可能存在overlapping的情况，比如这里有any any的，那么逻辑上就存在了overlapping。
PCEF/GGSN在处理动态rule的时候，可能会参考Precedence。所以default bearer的any any应该分配最低的Precedence。
以上说的都是动态rule，PCEF/GGSN也可以配置静态rule，当没有任何动态rule可以匹配到的时候使用。一般静态rule在实现上优先级要低于动态rule。

另外请教一下，port 5060是否可以cover所有的IMS信令及数据？

wenliu

hycl5410 发表于 2012-12-26 09:23
我感觉有趣的是，Precedence AVP, 规范上讲是值低的优先级越高，这个优先级不晓得在那个地方体现。是用户的 ...

基本上5060可以覆盖掉SIP信令了。5060 是对SIP的保留端口。

不晓得你指的IMS数据还有什么意思？ IMS的媒体流么？

wenliu

watson100 发表于 2012-12-25 19:41
这个例子里面用户已经建立IMS这个APN的dedicated Bearer了，这个bearer是AF触发的吗？

不需要AF来触发。 因为这个dedicate Beaer建立是为了承载SIP信令。在这个时段内，EPC 还没有为UE建立到IMS的通道。完全是PCRF通过预定义的PCC 来建立这条dedicated Bearer

hycl5410

wenliu 发表于 2012-12-26 09:44
基本上5060可以覆盖掉SIP信令了。5060 是对SIP的保留端口。

不晓得你指的IMS数据还有什么意思？ IMS的 ...

是指媒体流，或者叫payload？throughput？
因为我对IMS不太了解，不清楚信令过程和媒体流是否都会使用固定的5060端口。

我的意思是，有没有这样的可能，只使用5060端口作为TFT不能完全匹配到所有的IMS信令或者是媒体流？

admin

hycl5410 发表于 2012-12-26 14:37
是指媒体流，或者叫payload？throughput？
因为我对IMS不太了解，不清楚信令过程和媒体流是否都会使用固 ...

H大侠应该是指的用户的语音部分吧。这个帖子里有个SIP基本呼叫的建立过程，供参考：http://www.gprshome.com/forum.php?mod=viewthread&tid=141&page=1#pid3276。

IMS里面的控制面协议是SIP，端口5060。另外还有一个描述用户面媒体信息的协议SDP（会话描述协议）。IMS的用户面协议为RTP/UDP。端口号通常是大于1024的随机端口。所以光靠5060应该只能描述控制面的信令。

不正确的地方请wen大侠指正哈！

hycl5410

admin 发表于 2012-12-26 22:49
H大侠应该是指的用户的语音部分吧。这个帖子里有个SIP基本呼叫的建立过程，供参考：http://www.gprshome. ...

哦，那用户面如果需要其他QOS（比如GBR）的话，还是需要有其他的rule才行。这个预定义的rule只是保证SIP信令的，我记得QCI=5好像就是为了IMS signaling用的。
不过这么配置确实很合理。

IMS用户面dedicate bearer建立，是不是就可以像watson100说的那样，通过AF触发？
当然，没有AF其实一样也可以用各种方法实现，尤其是在实验局。。。

watson100

现网这么实现的话，1个IMS就需要3个bearer，太复杂了吧。其实IMS信令直接用default bearer，QCI=5就好，然后dedicated bearer再通过SDP里面的描述进行分配。这样的方式是不是更合理一些呢？

wenliu

watson100 发表于 2012-12-27 08:15
现网这么实现的话，1个IMS就需要3个bearer，太复杂了吧。其实IMS信令直接用default bearer，QCI=5就好，然后 ...

这个地方和IMS之间的通道设计，我觉得可以多样化，可能运营商也在尝试不用的解决方案。因为不但考验着到服务器的承受能力，也考验着IP网络的承受能力。
在我看来，第一条 default Bearer的建立就是为了维护 IP链接的，实现ip always online的概念。并且OCI的分配已经被固定化了，除非运营商自己内部定义QCI=5的时候也可以作为default Bearer处理。

另外IMS中可能会遇到的DNS之类的查询可以通过第一条default Bearer来完成。随后再dedicated Bearer来完成SIP信令。并且如果dedicated Bearer 如果被误拆除，还有一条default Bearer 来让UE 重新建立IMS链接。从网络保护角度看，将维持IP通道和 走用户应用面通道分割开，也有必要。

所以目前看，用两条bearer来实现default 和IMS的承载也不错。但是的确tunnel一多，网络间的通信就变的更为复杂。估计运营商用这种方式也在测试自己的服务器和IP网络的的承受能力。

针对传输RTP 流的dedicated Bearer通道，这个是随着SIP session 建立释放而 随时建拆，并不需要和之前两条Bearer一样一直保持。

不过不晓得对IMS应用+HTTP应用同时发生的情况下，会有多少条dedicated Bearer而存在。

IMS 用户 ： 用户同时发起Voip和session message 这种都有媒体protocol 参与的情况，不晓得会不会放一条dedicated Bearer中。

IMS业务和LTE的tunnel的联调的估计还比较远。 目前可能就专心做VoLTE。（不过吐槽下，装个SKYPE，QQ就行了。。花这么多力气调试IMS，弄的LTE这么复杂，运营商不晓得还有没有动力去做）

hycl5410

现网这么实现的话，1个IMS就需要3个bearer，太复杂了吧。其实IMS信令直接用default bearer，QCI=5就好，然后dedicated bearer再通过SDP里面的描述进行分配。这样的方式是不是更合理一些呢？

default bearer就给QCI5的话，是不是太浪费了？即使为IMS信令预留了QCI5的dedicate bearer资源，资源消耗一定会小于一直使用时的情况，而且使用率不会那么高；可是一旦default bearer给了QCI5，那系统资源的消耗可就太大了。初期用户少还没问题，用户量上来以后怎么办？


不过不晓得对IMS应用+HTTP应用同时发生的情况下，会有多少条dedicated Bearer而存在。

IMS 用户 ： 用户同时发起Voip和session message 这种都有媒体protocol 参与的情况，不晓得会不会放一条dedicated Bearer中。

dedicate bearer现在看基本还是网络触发，UE触发场景支持不好。所以，网络配置什么样的策略，就可以让数据流通过什么样的bearer走。PCEF负责数据流检测，PCRF负责下发策略。