Dedicated Bearer建立实例

wenliu

信令流程可以参见这个帖子 ：http://www.gprshome.com/thread-763-1-1.html


这边就不在多写。pcap中的流程完全符合规范的信令流。 PCRF和PGW 之间交互的Diameter消息没有覆盖。


下面针对消息的我认为值得关心的部分列下：

1. 在消息点开之后，看到第一条PGW->SGW 的Create Bearer Req中， 有个EBI = 5 ， 这个是之前建立的default Bearer的EBI，现在建立的dedicated     Bearer 需要引用这个BearerID，也就是Linked Bearer ID。
   其次，在 Bearer Context中，目前对这条dedicated Bearer的EBI还未分配，所以暂时为0.
    Context 中的TEID 应该不用多说，是为了GTP-U所建立的PGW 上行通道。




2. 点开TFT，比较有趣：TFT operation Code 是： 1 Create new TFT， 说明当前随着Dedicated Bearer的建立，需要在终端侧新建立一个TFT，这个TFT和default Bearer不一样。并且这个TFT随着后面用户dedicated Bearer的释放而释放。




3. 然后分别再点开Packet Filter，可以看到这两个filter是分别对应Uplink 和Downlink的 用户面traffic的port口。、
当然上下行都是5060端口，走的是UDP。。 意味着后面将会在这条dedicated Bearer的用户面走SIP信令。

wenliu

随后SGW 发给PGW 的Create Bearer REQ 与 PGW发出的类似，没有太大的变化，唯一多的就是SGW 分配出了自己用于建立GTP-U的TEID信息。

wenliu

随后MME需要向eNobde 下发NAS 层的Activate dedicated EPS bearer Req 消息， 该NAS消息通过S1AP的 E-RABSetup 消息封装。
（对比与Initial Attach 所建立的default Bearer过程来讲， NAS层的Activate default EPS bearer Context Req 是被封装在S1AP的initialContextSetup消息中）

首先S1AP出现的还是两个UE和MME 的两个S1AP-ID.随后NAS 层消息是被封装在E-RABToBeSetupListBearerSUreq 这ITEM中：

在这个S1AP ITEM layer可以看到分配出来的E-RAB-ID，MME用来关联和管理和S1接口Bearer Context。
随后给出的transportLayerAddress和gtp-TEID，大家可以对比下这两个value是SGW 之前在Create Bearer Req 带出来的用户面的信息。这样子MME 就将SGW 用户面的连接信息告知了UE。




点开NAS 层结构：
1。可以明确的看到当前MME为这条dedicated Bearer分配的EBI， 以及很明确的标出了Link EBI。
2。值得注意的是这边的Procedure transaction identity : 0 .
这个value在INITIAL ATTACH中，Default PDN Connectivity里标示为1. 有兴趣的可以自己查阅下规范中有关 ESM部分transcation的管理。
3。之后TFT带的data部分与GTP 消息中带的一样。

wenliu

1. 随后eNodeB 侧回送了1条S1AP 对应于E_RABSetup的Response 消息，上报eNodeB的S1-U Tunnel的TEID以及IP地址信息。
2. eNodeB发给MME 一条 Activate dedicated EPS Bearer context accept 消息，对应与之前的NAS 层的请求
3. MME ->SGW Create Bearer Resp
    SGW->PGW  Create Bearer Resp。

用户面的下行通道的TEID在这个过程中分配完毕，并且EBI ID这时候已经填上了6.

Dedicated Bearer 建立完成~

wenliu

学习爱好者 发表于 2013-12-22 12:11
点开NAS层后里面的消息被加密了，看不到EBI以及LBI的信息，能否把详细信息贴出来看看呢？

我这个pcap里NAS应该没有被加密啊。