(以下内容翻译自3GPP规范TS23.401的5.3.8 S1 Release功能章节)
这个过程用于释放一个UE的逻辑S1-AP信令连接(在S1-MME)和所有S1承载(在S1-U)。 该过程把UE和MME从ECM-CONNECTED状态迁移到ECM-IDLE状态,并且所有UE相关的上下文信息在eNodeB被删除。
S1释放过程有以下两种方式:
- eNodeB发起释放,原因是操作维护干预,不明原因的失败,用户休止状态,重复的RRC信令完整性检查失败,由于UE发生的信令连接失败而引起的S1释放等;
- MME发起的释放,由于鉴权失败,去附着等。
eNodeB发起释放和MME发起的S1释放过程,如图26所示。
[attach]2605[/attach]
1. 如果eNodeB检测出需要释放UE的信令连接和所有的无线承载, eNodeB发出一条S1 UE上下文释放请求(S1 UE Context Release Request)(起因)消息到MME。起因表明释放的原因(即O&M干预,不明的失败,用户休止状态,重复的RRC信令完整性检查失败,由于UE发生的信令连接失败引起的S1释放等)。
注: 当eNodeB发起S1释放过程时只执行第1步。当MME发起S1释放过程时,从第2步开始执行该过程。
2. MME 发送一条 更新承载请求(Update Bearer Request) 消息给S-GW,来请求释放所有的S1-U 承载。该消息是由来自eNodeB的S1释放请求(S1 Release Request)消息触发或者另一个MME事件触发 。如果P-GW请求了UE位置信息,则MME也会在该消息中包含用户位置信息参数。
3. S-GW释放所有eNodeB相关UE信息(地址和TEIDs)并且响应一条更新承载响应(Update Bearer Response)消息给MME。该UE的S-GW上下文的其它信息单元不受影响。 S-GW保留了S-GW为该UE的承载所分配的S1-U配置。如果有给UE的下行数据分组包,S-GW开始缓存下行给UE的分组包,并发起网络触发的服务请求(Network Triggered Service Request)过程。
4. MME通过发送S1 UE上下文释放命令(S1 UE Context Release Command)消息给eNodeB释放S1。其消息中指明S1释放的理由。
5. 如果RRC连接还没有释放,则eNodeB以AM模式发送一条RRC连接释放(RRC Connection Release)消息给UE。一旦UE应答了该消息,则eNodeB删除UE的上下文。
6. eNodeB向MME返回S1 UE上下文释放完成(S1 UE Context Release Complete)消息以确认S1释放成功。这步是在第4步之后立即执行,比如在eNodeB没有从UE收到释放RRC连接应答情况下不会被延迟。
MME删除与eNodeB有关的该UE的MME上下文信息(地址和TEIDs),但保留UE的其余MME上下文的包括S-GW的S1-U配置信息(地址和TEIDs)。 为UE建立的所有EPS承载被保存在MME和S-GW内。
如果S1释放的起因是与用户不激活不同,如 RRC连接丢失,MME将在S1释放过程完成后触发MME发起的专用承载去激活过程。
hbdzzc 发表于 2014-2-24 17:43
按照23401-b20版本5.3.5章中描述的,MME向SGW发的消息是“Release Access Bearer Request”(而不是上面图中 ...
欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/) | Powered by Discuz! X2 |