sml流程分析.pptVIP

Session Management流程分析 基于23.401的810+版本 dedicated bearer activation Step 7 eNB告知MME已激活承载，如果承载成功建立则返回的消息中会携带S1-TEID，不成功则不携带S1-TEID，此消息会一直上报到PCRF指示其发送的相应承载QoS是否合适。 - EPS Bearer Identity:唯一的标识此次所建立的承载，和以下参数关联，指出这些参数配置都属于这个承载。 - S1-TEID:指示下行eNB中的S1端口号，将由MME转发给 S-GW； - Session Management Response:指明此消息所属类型。 Step 8 MME告知S-GW已激活承载。 - EPS Bearer Identity:唯一的标识此次所建立的承载，和以下参数关联，指出这些参数配置都属于这个承载。 - S1-TEID:S-GW由此知道了下行到eNB的S1通路。 Step 9 由S-GW传给P-GW,告知P-GW已激活此承载。 - EPS Bearer Identity:唯一的标识此次所建立的承载，和以下参数关联，指出这些参数配置都属于这个承载。 - S5/S8-TEID：告知P-GW此承载S5/S8接口的下行端口号。 Step 10 如果这个专用承载激活过程是从PCRF由PCC Decision Provision触发的，就会有第10步过程。由P-GW来告知PCRF其所指定的PCC决定（QoS策略）是否已实施。这个指示是由eNB传上来的，可为什么在8、9步当中没有指示呢？若未实施，PCRF是否重新分配QoS呢，是否相应发起带QoS更新的承载修改过程？ UE requested bearer resource allocation Step 4 当需要PCRF时，P-GW与 PCRF有一个交互过程4a、4b，可 考虑用户的签约信息触发适当的 PCC决策下传给P-GW，相应的发 起专用承载激活或专用承载修改过 程。 同专用承载激活过程的第一步。 Step 6 通知PCRF其所分配的QoS是否已执行，与第4步相对照。 PDN GW initiated bearer deactivation Step 1 对于这个流程是假定UE处于ECM-CONNECTED状态的，本流程可用于删除一个专用承载和一个连接上的所有承载，默认承载的释放会在去注册时执行，或UE处于非连接态时网络侧执行局部去激活承载。 若未部署动态PCC，则不需要这一步，P-GW会使用静态配置的本地QoS。 若部署了动态PCC，PCRF通过这步将QoS Policy传给P-GW，P-GW将因此被触发发起承载去激活过程。 P-GW发起承载去激活过程也可以是由MME的请求触发，可见下个流程分析；或者是在从3GPP to non-3GPP HO时无最优化发生，这时和这个PDN地址相关的默认承载和所有专用承载都要被释放，但这个PDN地址仍要保持在PDN GW中。 Step 2 P-GW→S-GW 此消息中可包含一个标识，指示所有属于这个PDN连接的承载都释放掉。那么这个标识用什么参数来表示呢？如果需要全部删除一个PDN连接的承载，那么下面的这些参数是否都不需要携带了？ - PTI:Procedure Transaction Id,只有当这个过程是由UE Requested Bearer Resource Release Procedure发起时此参数才会使用，它是UE为UE请求的承载资源释放过程动态分配的一个编号，UE会尽可能确保先前使用的PTI号不会立即再被使用，当UE请求的承载资源释放过程完成时，PTI就会被释放。如果这个过程不是UE请求承载资源释放过程发起的，那这个消息里是否应该就不存在PTI？个人认为此参数是由UE分配的，如果不是UE发起的那么就不需携带这个参数。 - EPS Bearer Identity:表明要删除的承载号。 Step 3 S-GW→MME - PTI: (同上） Procedure Transaction Id,只有当这个过程是由UE Requested Bearer Resource Release Procedure发起时此参数才会使用，它是UE为UE请求的承载资源释放过程动态分配的一个编号，UE会尽可能确保先前使用的PTI号不会立即再被使用，当UE请求的承载资源释放过程完成时，PTI就会被释放。 - EPS Bearer Identity:表明要删除的承载号。 此消息中可包含一个指示，使所有属于这个PDN连接的承载都释放掉。 Step 4 MME建立