EPC网络中的P-GW发起的承载去激活流程

admin

（以下内容翻译自3GPP规范TS23.401的5.4.4.1　P-GW发起的承载去激活章节）

S5/S8接口基于GTP协议的P-GW发起的承载去激活流程如图31所示。

在此过程中，假设UE处于ECM-CONNECTED连接状态。这个承载去激活过程可以去激活单个专有承载或者去激活一个PDN地址下的所有承载。如果属于一个PDN 连接的缺省承载被去激活了，那么P-GW将去激活属于这个PDN 连接的所有承载。

1. 如果动态PCC策略没有配置，QoS策略的改变或者收到MME发起的承载去激活请求都可以触发P-GW发起承载去激活流程。PCRF发送PCC decision provision (QoS policy)消息给P-GW也可能触发承载去激活流程，这跟PCRF发起的IP-CAN Session修改流程中的初始步骤或者PCEF发起的IP-CAN Session 修改流程的响应消息中的IP-CAN Bearer signalling相对应。如果没有配置动态PCC策略，P-GW将应用本地的QoS策略。这跟3GPP TS 23.203中的PCRF或者PCEF发起的修改IP-CAN Session流程相对应。当从3GPP网络 执行一个非优化的切换到non-3GPP网络，此时也会导致P-GW发起承载去激活流程。在这种场景下，与此PDN地址相关的所有承载，包括缺省承载和专有承载，都会被释放掉，但是PDN地址还是会保存在P-GW中。

2. P-GW发送一个Delete Bearer Request (PTI, EPS Bearer Identity,Cause)消息给S-GW。本步骤和后续步骤中的PTI参数只有当该流程是由“UE Requested Bearer Resource Modification procedure”触发的时才使用。
   在此消息中可以包含一个指示释放与一个PDN连接相关的所有承载。

注： 如果用户因为欠费而导致PDN GW发起删除承载流程，或者当从3GPP执行非优化切换到非3GPP而引起承载删除时，都可以通过Delete Bearer Request message消息中的'Cause'信元值的设置来体现。

3a. S-GW发送Delete Bearer Request (PTI, EPS Bearer Identity，Cause)消息给MME。在此消息中可以包含一个指示释放与一个PDN连接相关的所有承载的指示，Cause信元指示MME承载删除的原因，如UE从3GPP网络切换到non-3GPP网络。

3b. 如果ISR激活，S-GW发送Delete Bearer Request (PTI, EPS Bearer Identity, Cause)消息给SGSN。在此消息中可以包含一个指示释放与一个PDN连接相关的所有承载的指示，SGSN释放这个PDN连接的所有承载资源，Cause信元指示MME承载删除的原因，如UE从3GPP网络切换到non-3GPP网络。如果用户因为欠费而导致PDN GW发起删除承载流程，‘Cause’信元应该指示用户欠费。

如果SGSN发现UE的所有的承载被删除，且删除的原因为UE从3GPP切换到non-3GPP或者欠费导致的，则SGSN将分离UE，在GERAN网络内SGSN将UE的MM状态设置为IDLE状态，在UTRAN网络内SGSN将UE的MM状态设置为PMM-DETACHED状态。

4. 如果MME已经处理了E-UTRAN网络中的承载释放，那么步骤4-7可以省略。否则MME发送S1-AP Deactivate Bearer Request (EPS Bearer Identity)给eNodeB。MME构造一个包含需要被释放的EPS Bearer Identity的NAS Deactivate EPS Bearer Request 消息, 而且把整个NAS消息包含在S1-AP Deactivate Bearer Request 消息中。如果承载去激活流程是由UE的请求触发的，这个NAS Deactivate EPS Bearer Context Request消息需要包含PTI信息。

5. eNodeB发送RRC Connection Reconfiguration 消息，其中包含EPS Radio Bearer Identity ，给UE。如果步骤4中的S1-AP 消息中包含了NAS PDU ，那么RRC消息也包含此NAS PDU 。

6. UE发送RRC Connection Reconfiguration Complete消息给eNodeB确认无线承载的释放radio bearer release。UE RRC层释放调步骤5中RRC消息指示的无线承载，而且将radio bearer status 指示给UE NAS层。UE NAS层根据UE RRC层的radio bearer status指示移除相关的UL TFTs和 EPS Bearer Identity。

6b. eNodeB发送一个Deactivate Bearer Response (EPS Bearer Identity)消息给MME确认承载去激活bearer deactivation。

7a.  UE发送Direct Transfer（Deactivate EPS Bearer Context Accept）消息给eNodeB。Deactivate EPS Bearer Context Accept消息由UE在NAS层构造，其中包含EPS Bearer Identity。

7b.  eNodeB发送Uplink Direct Transport（Deactivate EPS Bearer Context Accept）消息给MME。

8a. MME删除相关专有承载上下文并发送Delete Bearer Response (EPS Bearer Identity)消息给S-GW确认承载去激活。

8b.  SGSN删除相关专有承载上下文并发送Delete Bearer Response (EPS Bearer Identity)消息给S-GW确认承载去激活。

9. 如果ISR激活，当接收到MME和SGSN发送的Delete Bearer Response消息；或者ISR未激活，接收到 MME发送的Delete Bearer Response消息，S-GW删除相关专有承载上下文并发送Delete Bearer Response (EPS Bearer Identity)消息给P-GW确认承载去激活。

10. P-GW删除相关专有承载上下文。如果专有承载去激活流程是由PCRF发送PCC Decision Provision消息给P-GW而触发的，那么P-GW发送指示PCRF requested PCC decision是否已经被执行。PCRF处理，在PCRF发起 IP CAN Session 修改流程中或者PCEF发起IP-CAN Session修改流程，完成IP CAN bearer信令交互的后续流程。

当UE处于ECM-IDLE空闲态，流程中步骤4到步骤7不会执行。EPS bearer state的同步可以在下次UE的状态从ECM-IDLE空闲态转移到ECM-CONNECTED连接态（执行服务请求Service Request 或者位置更新流程 TAU procedure）时通过UE与网络侧交互流程执行。

对于MME，当UE所有承载被释放，MME将会把UE的MM状态迁移到EMM-DEREGISTERED未注册态。如果承载删除的原因为UE从3GPP网络切换到non-3GPP网络导致的，则MME将会本地分离UE，不发送分离请求消息给UE。并且MME发送S1 Release Command消息给eNodeB，eNodeB回复S1 Release Complete消息给MME，同时触发释放UE与eNodeB之间存在的RRC连接RRC connection。

如果UE探测到自己所有的承载被释放，UE也会将自己的MM状态迁移到EMM-DEREGISTERED未注册态。

paul

最近在学习EPC的东东，有没有基础的学习资料可以提供？从入门级开始的

amr

图和步骤稍微有点不匹配，我看的是V10的版本文档，我就贴这个图吧：



step4说如果MME已经处理了E-UTRAN网络中的承载释放，骤4-7可以省略。

不理解这个场景，按文中的意思，这个承载已经释放了。现在又收到了一条删除请求消息，删除该EPS ID的承载。由于已经释放，所以就可以跳过实际删除的操作，直接由MME告知S-GW已经删除成功了。---- 这是不是因为之前因为某种场景，MME发起的detach已经释放过E-RAB的资源的关系？

step6b eNB回复MME Deactivate Bearer Response消息


这个消息是不是回复早了？

这里有两对Request和Response，

ME to eNB：E-RAB RELEASE COMMAND --- 消息的NAS-PDU是MME配置的Deactivate EPS Bearer Context Request，属于NAS消息发给UE的。
eNB to MME：E-RAB RELEASE RESPONSE --- eNB发给MME的响应消息，回应哪些E-RAB释放失败


eNB to UE：RRC ConnectionReconfiguration --- eNB转发的MME请求删除哪些承载
UE to eNB：RRC Connection Reconfiguration Complete ---  UE响应的消息并没有告知eNB承载释放成功与否，这个消息是不携带产数的。


直到step7a，UE发送的NAS UL Information消息中包含Deactivate EPS Bearer Context Resoponse，这才知道是否释放成功。

一个或多个甚至全部承载去激活消息是否能在一个request消息中请求，还是一个承载去激活对应一条request消息？

amr

另外为何P-GW和S-GW发出的消息是删除承载请求，而MME发起的是去激活承载请求，这两个动作是有区别的吧

爱卫生

amr 发表于 2013-11-3 18:15
图和步骤稍微有点不匹配，我看的是V10的版本文档，我就贴这个图吧：

step4说如果MME已经处理了E-UTRAN网络中的承载释放，骤4-7可以省略。

不理解这个场景，按文中的意思，这个承载已经释放了。现在又收到了一条删除请求消息，删除该EPS ID的承载。由于已经释放，所以就可以跳过实际删除的操作，直接由MME告知S-GW已经删除成功了。---- 这是不是因为之前因为某种场景，MME发起的detach已经释放过E-RAB的资源的关系？
    答：我查了下资料。有些资料是这样说的。UE的空中接口无线承载因为某些原因被释放（例如资源受限或eNB的能力不再允许eNB为UE持续维护所有的GBR承载）。这样当无线承载和E-RAB都因为空中接口的原因而现行释放，所以4-7就可以忽略了。应该是这个意思吧。

爱卫生

amr 发表于 2013-11-3 18:15
图和步骤稍微有点不匹配，我看的是V10的版本文档，我就贴这个图吧：

看看这个图是不是清楚一点？

一个请求应该是可以释放多个承载的。典型的场景应该是释放默认承载伴随释放多个专有承载的过程，即整个PDN链接都释放了。理论依据是S1AP的规范关于E-RAB release command的定义和流程说明，如下：

“The MME initiates the procedure by sending an E-RAB RELEASE COMMAND message.

The E-RAB RELEASE COMMAND message shall contain the information required by the eNB to release at least one E-RAB in the E-RAB To Be Released List IE. If a NAS-PDU IE is contained in the message, the eNB shall pass it to the UE.

Upon reception of the E-RAB RELEASE COMMAND message the eNB shall execute the release of the requested E-RABs. For each E-RAB to be released the eNB shall release the corresponding Data Radio Bearer and release the allocated resources on Uu. ”

因为规范里定义了E-RAB to be released list这个参数，所以一次可以释放多个。

个人理解。