VoLTE端到端业务详解 | S1AP协议

Posted 2022-08-18 COCOgsta

书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

---

S1AP服务可分为如下两类。

· 非UE相关的服务：其涉及eNB和MME之间的所有S1接口实例，利用一个非UE相关的信令连接。

· UE相关的服务：其与一个UE相关，提供这些服务的S1AP功能与一个UE保持的相关信令连接有关系。

S1AP协议的各个消息类别、作用等信息详见表4-1。

4.1.1 移动性管理

相对于固定通信网络，移动通信网络有两个核心的业务，一个是移动性管理，另一个是无线资源管理。顾名思义，移动性管理就是管理用户的移动性。在网络覆盖到的范围内，无论用户移动到哪里，网络都能跟踪和记录到用户的位置信息：（1）确保该用户可以随时发起呼叫；（2）确保其他用户随时可以呼叫到该用户。相对于无线资源管理，移动性管理的内容变化不大，无论是2G、3G、4G还是5G，无论是电路交换还是全IP交换，无论网络的物理单元、结构和功能分配如何变化，移动性管理的核心思想都没有改变。

要想实现移动性管理，首先要对PLMN网的无线覆盖区域进行分区和编码标识，然后要对移动用户进行编码和标识。在移动性管理中，这两个标识同等重要，比如，2G网络的识别位置区的标识是LAC，全地球表面的每一寸面积都包含于一个位置区中。识别用户的标识是IMSI，每一个移动用户具有全球唯一识别的IMSI。网络只要跟踪和判断某个IMSI位于哪个位置区内，移动性管理的目标就实现了。

移动性管理流程包含附着/去附着流程、正常/周期性位置更新流程、用户被叫流程、用户主叫流程。

1.附着流程

附着成功流程如图4-1所示，当MME在Attach Accept中携带了新的GUTI给UE时，UE需要返回Attach Complete，反之，UE不需要返回Attach Complete消息。

附着失败流程如图4-2所示，Attach Reject常见失败场景说明见表4-2。

（1）在Attach Request中主要关注5个信元。

① Attach Type。

用于指示附着流程类型，取值为EPS Attach、Combined EPS/IMSI Attach、EPS Emergency Attach或Reserved。

对于VoLTE终端来说，一般会在附着请求中携带请求类型为“Combined EPS/IMSI Attach”。

当MME收到这样的附着请求时，就会在用户附着MME成功后代替用户去CS域做附着，这时如果不是UE自己选网到CS域去做附着，那么在MME上就得配置LTE网络的TAC和2G/3G网络的LAC的对应关系表，配置的位置区域和实际网络覆盖的位置区域会存在差异，这个差异会导致用户实际位置覆盖的LAC1、网络侧MME上配置的位置是LAC2，对于VoLTE用户感知的影响是在做CSFB（Circuit Service Fall Back，电路域业务回落）业务时需要做位置更新流程。

针对这个回落问题，笔者需要做一个详细阐述，因为VoLTE用户的一个业务保障措施就是当LTE无线信号较好，但VoLTE业务使用不畅时，VoLTE用户会主动或被动进行业务回落，即做CSFB业务，对VoLTE用户的回落问题处理依然是一个关键环节。

首先我们要清楚CSFB语音业务解决方案是一个怎样的业务过程，CSFB基于LTE网络只有分组域的概念产生了CSFB语音解决方案。3GPP定义的电路域回落机制，保证用户同时注册在EPS和传统电路域网络，用户发起语音业务时，由EPS指示用户回落到电路域网络后再发起语音呼叫。

CSFB的三个基本过程如下。

· 开机选网驻留：优先驻留在LTE，即终端开机→LTE及2G/3G电路域联合注册（确保用户同时注册在EPS和GSM电路域网络）→驻留LTE，这个过程是CSFB业务最基本的过程，只有这个过程成功了才能实现下面两个过程。

· 呼叫请求回落：网络指示终端先重选回到2G/3G网络，由传统的CS网络提供语音服务。

· 通话结束返回：终端完成呼叫后返回到LTE网络驻留。

CSFB的各个基本过程如图4-3所示，简要描述如下。

A.1 开机选网。

终端会按照自己的PLMN优先级和制式、频段支持的配置进行网络选择，当选择了一个LTE网络附着时，MME会按照附着流程完成相关工作并使合法有效用户附着LTE网络成功，同时，MME知道本次附着的用户是一个CSFB用户，还需要代替用户去传统CS域附着，即发起联合位置更新过程。

A.2 联合注册。

MME上存储TAC（LTE Tracking Area Code）与LAC（2G Location Area Code）的对应关系，根据用户附着请求消息中的TAC代替用户通过SGs接口注册到对应LAC的MSC上，MSC会为用户分配一个TMSI，同时标记用户是CSFB业务。

B.1 呼叫请求。

呼叫分为主叫和被叫两个过程，当CSFB用户发起主叫业务时，会发Extended Service Request消息给MME以表示本次是CSFB的语音业务，MME就会告知基站让用户回落到CS域去做语音业务。

B.2 回落至2G CS提供语音。

基站接收到MME本次业务为CSFB时，会直接释放本次LTE网络空口连接，并告知用户回落到具体哪个频点（现网一般设置R8重定向方式，虽然R9重定向方式可缩短单端2s以上，但R9方式网络侧改动较大），终端收到这样的连接释放消息后就会主动去搜索这个频点的信号并接入。

C语音结束后返回LTE网络。

用户的语音业务结束后，需要返回LTE网络，即意味着用户空闲态时是驻留在LTE网络的。

这几个基本过程里最需要解读的是联合位置更新过程，这与传统的移动网络位置更新过程会有哪些不同呢？传统的移动用户位置更新过程，是UE发现当前无线网络广播信号中的LAC和手机里存储的LAC不同时，主动告知核心网进行LAC更新的一个过程。这个过程主要是与移动用户做被叫业务时网络侧需要先寻呼用户有关，那我们就又需要了解移动用户做被叫的过程。

我们都知道移动电话与固定电话的区别就是：一个是有线连接，一个是无线连接，如果是有线连接，网络侧就将连接的这根线进行编号，当有人要呼叫这个号码时，网络侧去查询编号，然后就能寻找到这个用户并唤醒用户。而如果是无线连接，网络侧是不会为这个用户分配一个固定的连接，所以需要用一个类似于广播找人的方式来唤醒用户。比如，在车站如果人走丢了，我们会去寻求车站广播室进行广播找人，当你要找的那个人听到广播后就会按照广播的要求到指定地点去会合，这解决了本次人走丢的业务问题。移动电话的被叫业务过程也是类似的，我们会在协议里规定好哪些空口无线连接是网络侧专门用来唤醒你的信道，当我们在各个基站下闲逛时，手机会按照协议规定时间去周期地拜访唤醒我的信道（专业术语就是寻呼信道），如果在这个信道听到了广播，我们就会去主动向基站申请业务信道来完成被叫业务。

CSFB用户联合位置更新到CS域的过程，因为用户是在LTE网络选网，但为了后续语音业务能正常完成，MME会根据用户当前所在的LTE网络跟踪区去人为定义用户当前所在区域的CS域网络的位置区信息，MME代替用户去CS域做联合位置更新的LAC信息有可能和用户实际所处的LAC信息不一致。那为什么会存在不一致的情况呢？这是因为我们在做LTE网络和传统CS域网络规划时是要求一个TAC覆盖的范围和一个LAC覆盖的范围是重叠的，但由于频率、站址、制式等因素总是在边缘区域不那么一致，因此就可以看到联合位置更新的LAC和语音业务回落的LAC存在以下三种场景，如图4-4所示。

场景1：“联合位置更新时LAC”等于“用户实际所处位置区域的LAC”，此场景下用户做CSFB业务成功且不需要位置更新过程。

场景2：“联合位置更新时LAC”不等于“用户实际所处位置区域的LAC”，两个LAC由一个CS域交换机管理，此场景下用户做CSFB业务成功且需要位置更新过程。

场景3：“联合位置更新时LAC”不等于“用户实际所处位置区域的LAC”，两个LAC由不同CS域交换机管理，此场景下用户做CSFB业务失败（基于目前CS域核心网是POOL组网的情况，此场景仅会出现在一个城市多个POOL组网或两个城市之间的边缘地带）。

② MS网络能力。

用于给网络侧提供MS的GPRS相关信息，携带SRVCC能力信息，其中SRVCC能力信息包括从UTRAN HSPA到GERAN/UTRAN、从E-UTRAN到GERAN/UTRAN两种情况。

MME收到UE这个能力参数之后，如果MME也支持SRVCC功能，则会在给HSS的ULR消息中携带上SRVCC相关能力参数，以便HSS将STN-SR插入MME，为VoLTE用户呼叫业务过程中发生SRVCC做准备，SRVCC完整业务过程将会在SRVCC篇章中完整描述。

③ 语音域偏好和用户设备使用设置。

如果UE支持CSFB、SMS over SGs和IMS语音，则UE在附着请求或TAU请求消息中需要携带该信元。该字段包含如下两部分内容。

· UE’s usage setting（用户设备使用设置）

· 当Bit第3位是“0”时，表示“Voice centric”（语音业务为中心）。

· 当Bit第3位是“1”时，表示“Data centric”（数据业务为中心）。

· Voice domain preference for E-UTRAN（E-UTRAN网络的语音域偏好）

· 当Bit前两位分别为“0 0”时，表示“CS Voice only”（仅使用CS语音）。

· 当Bit前两位分别为“0 1”时，表示“IMS PS Voice only”（仅使用IMS PS语音）。

· 当Bit前两位分别为“1 0”时，表示“CS Voice preferred, IMS PS Voice as secondary”（CS语音优先，IMS PS语音次选）。

· 当Bit前两位分别为“1 1”时，表示“IMS PS Voice preferred, CS Voice as secondary”（IMS PS语音优先，CS语音次选）。

常见消息中的参数如图4-5所示。

说明：

· 当UE不支持IMS语音时，E-UTRAN网络的语音域偏好为“CS Voice only”。

· 当UE只支持IMS语音时，E-UTRAN网络的语音域偏好为“IMS PS Voice only”。

目前，大多数VoLTE终端中Voice domain preference和UE’s usage setting设置为“11”和“0”，这意味着语音业务优先，数据业务次之，语音业务优先使用VoLTE方案、次之使用CSFB方案，当参数Voice domain preference设置为“IMS PS Voice preferred、CS Voice as secondary”时，MME收到附着请求消息，知道这个用户的VoLTE终端，首先去HSS下载签约数据以核实用户是否签约了VoLTE业务，如果签约了则会等待用户主动发起IMS APN的PDN连接建立请求，待用户的IMS APN的PDN连接建立成功之后，MME会代替用户去CS域做联合位置更新，UE若收到MME的Attach Accept或Activate Default EPS Bearer Request消息中包含与VoLTE业务相关的P-CSCF地址、UE IP地址等信息，以及与CSFB业务相关的CS域TMSI、LAC等信息，则UE认为目前网络支持语音业务。

对于UE’s usage setting参数，如果是设置为“Voice centric”，当在附着过程中没有收到网络侧与VoLTE业务相关的P-CSCF地址、UE IP地址等信息，以及与CSFB业务相关的CS域TMSI、LAC等信息时，UE会认为当前LTE网络不能提供语音业务，终端会自己重新选网到2G/3G的传统CS域，因为终端认为语音业务是自己最需要的业务。现在虽然有很多社交软件可以用于交流，但重要的事情还是优先使用电话业务进行沟通，听见为实。

④ PCO（Protocol Configuration Option，协议配置选项）。

PCO包含002H( )参数，指示建立IMS信令承载；包含00CH（），指示请求P-CSCF地址。

PCO分两个方向：一个是用户发给网络侧的，携带用户向网络侧请求的相关信息；一个是网络侧发给用户的，携带网络侧给用户分配的相关信息。

用户给网络侧发送的PCO参数如图4-6所示，一般承载在Attach Request或PDN Connect Request消息中。

PCO请求的参数有什么呢？对于VoLTE用户，PCO请求的参数是要获取到网络侧给自己分配的一个可以在网络中使用的地址以及用户可以接入的P-CSCF地址，网络侧给自己分配的一个地址信息如图4-7所示。

用户可以接入的P-CSCF地址如下，可以看到网络侧告知用户可以接入两个P-CSCF网元，但用户只能注册在其中一个网元上，当发现这个网元不可用时，用户可以主动尝试去另一个P-CSCF上注册，如图4-8所示。

⑤ PDP类型。

指示请求UE的IP地址类型，如IPv4、IPv6或IPv4v6。

（2）在Attach Accept中主要关注两个信元

① T3412值。

此定时器如图4-9所示，用于控制UE发送周期性跟踪区更新请求的时间间隔，在UE从ECM连接态变为ECM空闲态时启动。超时后，UE发起跟踪区更新流程。此信元包含两个参数：unit和timer-value，如下。

Unit这个参数的取值：

· 0 0 0: 定时器为2s的倍数；

· 0 0 1: 定时器为1min的倍数；

· 0 1 0: 定时器为1/10h的倍数（6min的倍数）。

这个值如何计算呢？从图4-10的例子就可以看到T3412=unit（6min）×timer-value（9）=54min。

② EPS网络特征支持。

用于指示网络是否支持特定的特性，如图4-11所示。

PS会话的IMS语音业务指示。

· 0：不支持S1模式PS会话的IMS语音业务。

· 1：支持S1模式PS会话的IMS语音业务。

VoLTE用户只有在收到网络侧的附着接受消息中PS会话的IMS语音业务指示时，才会继续向网络侧请求建立IMS APN的PDN连接。

2.去附着流程

去附着流程包含用户发起和网络侧发起两种流程，如图4-12和图4-13所示。

在Detach Request主要关注两个信元，如图4-14所示。

① Detach类型。

用于指示分离类型。

UE主动发起Detach操作时所带的类型参数如下。

MME主动发起Detach操作时所带的类型参数如下。

当网络侧告知UE本次Detach操作时，如果让用户立即重新附着，则所带的类型参数是0 0 1: re-attach required。

② EMM cause。

只有MME主动发起的Detach过程才会带这个信元，用于指示UE发起的EMM请求被网络拒绝的原因，比如0 0 0 0 0 1 1 1: EPS services not allowed，即告知UE不允许使用4G业务。

常见的拒绝原因如下。

· 0 0 0 0 0 0 1 0: IMSI unknown in HSS（HSS中未知的IMSI）

· 0 0 0 0 0 0 1 1: Illegal UE（非法UE）

· 0 0 0 0 0 1 0 1: IMEI not accepted（IMEI不接受）

· 0 0 0 0 0 1 1 0: Illegal ME（非法ME）

· 0 0 0 0 0 1 1 1: EPS services not allowed（EPS服务不允许）

· 0 0 0 0 1 0 0 0: EPS services and non-EPS services not allowed（EPS服务和非EPS服务不允许）

· 0 0 0 0 1 0 0 1: UE identity can not be derived by the network（MS身份不能由网络导出）

· 0 0 0 0 1 0 1 0: Implicitly detached（隐式分离）

· 0 0 0 0 1 0 1 1: PLMN not allowed（PLMN不允许）

· 0 0 0 0 1 1 0 0: Tracking Area not allowed（跟踪区域不允许）

· 0 0 0 0 1 1 0 1: Roaming not allowed in this tracking area（跟踪区域内不允许漫游）

· 0 0 0 0 1 1 1 0: EPS services not allowed in this PLMN（PLMN内EPS服务不允许）

· 0 0 0 0 1 1 1 1: No Suitable Cells In tracking area（跟踪区域内无合适的小区）

· 0 0 0 1 0 0 0 0: MSC temporarily not reachable（MSC临时不可达）

· 0 0 0 1 0 0 0 1: Network failure（网络失败）

· 0 0 0 1 0 0 1 0: CS domain not available（CS域不可用）

· 0 0 0 1 0 0 1 1: ESM failure（ESM失败）

· 0 0 0 1 0 1 0 0: MAC failure（MAC故障）

· 0 0 0 1 0 1 0 1: Synch failure（同步失败）

· 0 0 0 1 0 1 1 0: Congestion（拥塞）

· 0 0 0 1 0 1 1 1: UE security capabilities mismatch（UE安全能力不匹配）

· 0 0 0 1 1 0 0 0: Security mode rejected, unspecified（安全模式拒绝,未定义）

· 0 0 0 1 1 0 0 1: Not authorized for this（CSG未授权此CSG）

· 0 0 0 1 1 0 1 0: Non-EPS authentication unacceptable（非EPS认证不可接受）

· 0 0 1 0 0 1 1 1: CS domain temporarily not available（CS域暂时不可用）

· 0 0 1 0 1 0 0 0: No EPS bearer context activated（没有激活的EPS承载上下文）

· 0 1 0 1 1 1 1 1: Semantically incorrect message（语义错误消息）

· 0 1 1 0 0 0 0 0: Invalid mandatory information（无效的必带信元）

· 0 1 1 0 0 0 0 1: Message type non-existent or not implemented（消息类型不存在或不能实现）

· 0 1 1 0 0 0 1 0: Message type not compatible with the protocol state（与协议状态不兼容的消息类型）

· 0 1 1 0 0 0 1 1: Information element non-existent or not implemented（信息单元不存在或未实施）

· 0 1 1 0 0 1 0 0: Conditional IE error（条件信元错误）

· 0 1 1 0 0 1 0 1: Message not compatible with the protocol state（与协议状态不兼容的消息）

· 0 1 1 0 1 1 1 1: Protocol error, unspecified（协议错误，未指定）

3.正常跟踪区更新流程

当VoLTE用户进入新的跟踪区之后，用户接收到包含跟踪区编码信息的广播消息，与用户保存的原跟踪区列表信息比较，发现不一致，由此判断进入了新的跟踪区，马上发起位置更新流程。

跟踪区更新成功流程如图4-15所示，当MME在TAU Accept中携带了新的GUTI给UE，UE需要返回TAU Complete，反之，UE不需要返回TAU Complete消息。

跟踪区更新失败流程如图4-16所示，TAU Reject常见失败场景说明见表4-3。

（1）在TAU Request中主要关注三个信元

① EPS更新类型。

“Active” Flag:

· 0：无承载建立请求；

· 1：为承载建立请求。

当TAU Request中的“Active”Flag=1时，在本次TAU过程中MME需要为用户建立EPS承载，完整的信令流程如图4-17所示。

EPS更新类型值。

· 0 0 0：TA Updating。

· 0 0 1：联合TA/LA Updating。

· 0 1 0：带IMSI附着的联合TA/LA Updating。

· 0 1 1：周期Updating。

② EPS Bearer Context Status。

指示可用EPS Bearer Identity标识的EPS承载上下文的状态。

只有EPS Bearer ID=5的承载是激活状态。

③ GUTI类型。

指示本次TAU是4G网络内两个TAC之间的TAU还是用户从2G/3G返回4G网络的TAU。

表示本次TAU是4G网络内两个TAC之间的TAU。

表示本次TAU是用户从2G/3G返回4G网络的TAU。

（2）TAU Accept主要关注两个信元

① T3412 Value。

此定时器的作用同“附着流程”中的介绍，在附着接受中也有这个信元，那么不同点是什么呢？主要区别是这个信元在TAU Accept中是可选参数，即意味着当MME上配置的T3412参数有变化时，这个信元在TAU Accept中才告诉UE，如果没有变化则不需携带此信元。

UE收到这个信元之后会去与自己前期保存的T3412参数进行比对，如果不同，则更新为新的T3412参数。

② EPS网络功能支持。

此信元同“附着流程”中的介绍，同样地，此信元在TAU Accept中是可选的，但与T3412的可选含义不同，如果在TAU Accept中没有携带“PS会话的IMS语音业务指示”这个参数，则UE会认为网络侧不支持VoLTE，如果网络侧一直支持VoLTE，则在TAU Accept中携带此信元也就成了必选参数。

4.周期性跟踪区更新流程

如同传统移动通信网络一样，当移动用户在一段时间内没有和网络交互任何信息时，网络侧会告知UE在规定时间之内做一次周期性位置更新，以便网络侧了解用户当前所在的位置区/跟踪区，当网络侧有业务要发给用户时，可以寻呼到用户，2G/3G网络时代是以位置区为单位进行寻呼；4G网络时代是以跟踪区列表为单位进行更新，实际4G网络部署时考虑到了网络的复杂度，一般一个跟踪区列表只包含一个跟踪区，因而4G网络时代的周期性跟踪区更新流程同2G/3G网络时代一样，网络侧可以通过与用户发生业务时的信令交互来获取用户当前的TAC，当用户在T3412定时器的时间之内与网络侧没有任何信令交互时，用户会主动发起周期性跟踪区更新过程与网络侧进行信令交互，从而网络侧知道用户当前所在的跟踪区。周期性TAU的流程如图4-18所示。

图4-19所示的周期性跟踪区更新中的EPS Update type value=3（0 1 1），表明本次是周期更新。

实际网络中周期性跟踪区更新事件很少，是因为现在用户使用业务的频次很高，一般来说网络侧设置的T3412=54min，然而用户在54min内没有使用任何业务的概率很小，所以现在网络上的周期性TAU的信令很少。

另外，周期性TAU和正常TAU的区别是周期性TAU中下面的两个信元的值是相同的，即用户手机里存储的TAC（如图4-20所示）和当前网络广播的TAC（如图4-21所示）是相同的，但因为周期性跟踪区更新定时器超时了，所以我们要通过周期性TAU以便网络侧知道是可及的，如果后续网络侧有包要发送给我们，则可以在这个TAC下寻呼我们。

如果在T3412+隐式分离时长的时间之内用户没有做周期性跟踪区更新且没有任何信令消息与网络侧交互，则当网络侧有包发给用户时，网络侧不会寻呼用户，直接告诉业务侧此用户处于不可及状态，这个功能的目的是防止用户长期脱网时网络侧不断寻呼用户而浪费资源。

5.用户主叫业务流程

成功的业务请求过程如图4-22所示，即MME给基站发送了初始上下文建立请求，基站给UE发送了RRC重配置消息。

失败的业务请求过程如图4-23所示，网络侧是没有任何响应消息的，UE收不到RRC重配置的信令，在这种失败场景下UE是在发出Service Request之后启用一个定时器等待基站的RRC重配置消息，如果定时器超时，终端会返回空闲状态。

在Service Request中主要关注一个信元RRC Establishment Cause，用于向MME指示RRC Connection Establishment的原因，常见的包含下面三种原因。

· mt-Access

· mo-Signalling

· mo-Data

主叫业务请求就是mo-Data，指用户有包发送，所以才向网络侧申请建立业务信道来传送包。

被叫业务请求可能是mt-Access，那对于什么业务这个信元会是mo-Signalling？从字面的意思来看就是主叫业务且是信令，这样就联想到是不是TAU或Attach过程，例如，现网的TAU（如图4-24所示）或Attach（如图4-25所示）消息。

可以看到，UE发起的TAU、Attach请求的RRC建立原因均为mo-Signalling。

6.用户被叫业务流程

成功的用户被叫业务流程如图4-26所示，与成功的用户主叫业务流程不同的是被叫业务流程多了“网络侧先给UE下发的寻呼消息”，当用户监听到网络侧的寻呼消息之后就会申请空口RRC连接建立并发Service Request给MME，只是在Service Request消息中携带的RRC Connection Establishment的原因为mt-Access。

7.S1切换流程

（1）切换准备

切换准备过程的目的在于通过EPC在目标侧请求准备资源。对于某一UE，同一时间仅能进行一个切换准备过程。

切换准备成功消息如图4-27所示。

切换准备失败消息如图4-28所示。

（2）切换资源分配

切换资源分配过程的目的在于在目标eNB处为UE切换保留资源。

资源分配成功消息如图4-29所示。

资源分配失败消息如图4-30所示。

（3）切换通知

当UE已经在目标小区被识别，同时成功完成SI切换时，目标eNB将向MME发送Handover Notify消息，如图4-31所示。

8.X2切换流程

当UE从一个eNB的小区切换到另一个eNB小区时，两个eNB会通过X2接口发生一系列的信令交互配合，切换成功后，目标eNB要通过Path_Switch_Request告知MME用户已经切换到该基站下面，用于向MME请求通知SGW修改S1-U口下行基站侧的GTP-U隧道相关信息。请求MME通知SGW修改成功如图4-32所示，请求MME通知SGW修改失败如图4-33所示。

4.1.2 安全管理

1.鉴权流程

（1）网络侧决定鉴权失败

当MME收到UE的鉴权响应消息时，会判断用户的鉴权是否通过，当失败时会返回用户Authentication Reject（鉴权拒绝）消息，如图4-34所示。

在鉴权请求中我们主要关注的信元是Authentication Parameter RAND（用于网络侧给UE提供一个随机数，计算鉴权响应RES以及加密密码CK和完整性键值IK）和Authentication Parameter AUTN（用于网络侧给UE提供一种鉴权网络的参数），如图4-35所示。

在鉴权响应中我们主要关注的信元是RES信元，如图4-36所示。

（2）UE侧决定鉴权失败

当UE收到网络侧的鉴权请求时，首先会对网络进行鉴权，如果鉴权失败，则给网络侧返回鉴权失败消息，网络侧可以向用户要IMSI，向HSS获取用户的鉴权参数重新进行鉴权过程，如图4-37所示。

这里要解释一下UE收到网络侧的鉴权请求消息时对网络进行鉴权的原理。

从3G网络时代就开始了五元组鉴权的概念，与三元组鉴权的区别就是不但网络对UE进行鉴权，同时UE对网络也进行鉴权。

五元组包含的参数：

· RAND（Random Challenge，随机数）：由随机数发生器产生，长16 Byte，主要作为计算五元组中其他参数的基础。

· XRES（Expected Response，期望响应）：UMTS对鉴权请求的期望响应，长4～16 Byte。

· CK（Cipher Key，加密密钥）：长16 Byte，用来实现存取数据的完整性（Access Link Data Confidentially），用来加密被认为是机密的信令信息元素（对某些逻辑信道进行加密）。不同的网络类型[CS（Circuit Switch）和PS（Packet Switch）]分别对应一个CK：CKCS和CKPS。

· IK（Integrity Key，完整性密钥）：长16 Byte，用来实现连接数据存取的保密性（Access Link Data Confidentially）。因为大多数发送给MS和网络的控制信令信息都被认为是敏感数据，必须进行完整性保护。不同的网络类型（CS和PS）分别对应一个IK：IKCS和IKPS。

· AUTN（Authentication Token，鉴权标记），长16 Byte，包括以下内容：SQN+AK，其中SQN（序列号）与AK（匿名密钥）分别长6 Byte；USIM将验证AUC产生的SQN是否是最新的，并作为鉴权过程的一个重要组成部分。

AMF（鉴权管理域）长2 Byte。

MAC（消息鉴权编码）长8 Byte；MAC-A用来验证RAND、SQN、AMF的数据完整性并提供数据源；MAC-S则由USIM发送给AUC作为重新同步过程中鉴权的数据源。

如果USIM认为SQN不在可用的范围内，则返回同步失败（Synchronisation Failure）消息，如图4-38所示，消息包含了AUTS参数。

2.加密流程

加密流程包含两种，如图4-39所示，加密成功或失败。失败时UE返回的是加密模式拒绝消息，用于网络发送此信息给UE建立NAS信令安全。

该流程中我们主要关注Selected NAS Security Algorithms信元，指示UE网络侧选择的加密和完整性保护算法。

完整性保护算法类型：

· 0 0 0: EPS Integrity Algorithm EIA0 (Null Integrity Protection Algorithm)

· 0 0 1: EPS Integrity Algorithm 128-EIA1

· 0 1 0: EPS Integrity Algorithm 128-EIA2

· 0 1 1: EPS Integrity Algorithm EIA3

· 1 0 0: EPS Integrity Algorithm EIA4

· 1 0 1: EPS Integrity Algorithm EIA5

· 1 1 0: EPS Integrity Algorithm EIA6

· 1 1 1: EPS Integrity Algorithm EIA7

加密算法类型：

· 0 0 0: EPS Encryption Algorithm EEA0 (Null Ciphering Algorithm)

· 0 0 1: EPS Encryption Algorithm 128-EEA1

· 0 1 0: EPS Encryption Algorithm 128-EEA2

· 0 1 1: EPS Encryption Algorithm EEA3

· 1 0 0: EPS Encryption Algorithm EEA4

· 1 0 1: EPS Encryption Algorithm EEA5

· 1 1 0: EPS Encryption Algorithm EEA6

· 1 1 1: EPS Encryption Algorithm EEA7

网络侧通常选择的是加密算法为不加密，而完整性保护算法为EIA2，如图4-40所示。

4.1.3 承载管理

1.E-RAB建立流程

如图4-41所示，E-RAB建立过程的目的在于为一个或若干个E-RAB的Uu和S1分配资源，以及为一个给定的UE建立相应的数据无线承载。

成功和失败都在E-RAB Setup Response中响应基站。

（1）E-RAB Setup Request主要关注的信元是E-RAB建立列表，至少为每一个用户建立一个E-RAB。其中，包含4个必选子信元和一个可选子信元，如图4-42所示。

必选子信元：

① E-RAB ID：该信元唯一标识特定UE的无线接入承载，在每个S1连接上E-RAB ID唯一；

② E-RAB Level QoS Parameters：定义了应用于一个E-RAB的QoS，包含QCI和Allocation and Retention Priority两个子信元；

③ Transport Layer Address：定义了一个IP地址，用于传输层解析；

④ GTP-TEID：定义了GTP隧道端点标识，用于eNB和服务网关之间的用户面传输。

可选子信元：

⑤ NAS-PDU：在建立默认承载时携带的是Activate Default EPS Bearer Context Request消息或在建立专用承载时候携带的是Activate Dedicated EPS Bearer Context Request消息，因为在E-RAB建立时同时需要UE激活E-RAB，否则建好了也不能使用。

Activate Dedicated EPS Bearer Context Request消息如图4-43所示。

专用承载建立的时候会指明这个专用承载关联的默认承载ID。

（2）E-RAB Setup Response主要关注的信元：

· 如果建立成功，其E-RAB列表应该包含在E-RAB Setup List IE中。

· 如果建立失败，其E-RAB列表应该包含在E-RAB Failed to Setup List IE中。

2.E-RAB修改流程

如图4-44所示，E-RAB修改过程旨在使对于给定的UE，其已经建立E-RAB的修改有效。

成功和失败都在E-RAB Modify Response中响应MME。

E-RAB修改的流程和建立的流程关注的信元含义一样，只是信元的名称有变化。

（1）请求消息

请求修改的E-RAB的列表包含在E-RAB to be Modified List中。

（2）响应消息

如果修改成功，那么其E-RAB的列表包含在E-RAB Modify List IE中；如果修改失败，那么E-RAB的列表包含在E-RAB Failed to Modify List IE中。

3.E-RAB释放流程（MME主动）

如图4-45所示，E-RAB释放过程旨在对于给定UE，释放其已经建立的E-RAB。

eNB释放E-RAB成功与失败均在E-RAB Release Response消息中反馈。

E-RAB释放的流程和建立的流程关注的信元含义是一样的，只是信元的名称有变化。

（1）请求消息

请求释放的E-RAB的列表包含在E-RAB to be Released List中。

（2）响应消息

如果释放成功，那么其E-RAB的列表包含在E-RAB Release List中；如果释放失败，那么其E-RAB的列表包含在E-RAB Failed to Release List中。

4.E-RAB释放流程（eNB主动)

如图4-46所示，不同于MME主动释放E-RAB流程，主要在于基站给MME主动发送了E-RAB Released Indication消息，包含了E-RAB Released List IE信元，随后MME告诉基站释放E-RAB Released List IE信元中的E-RAB。

注：如果eNB想要移掉所有剩余的E-RAB，例如，对于用户处于不活动状态（User Inactivity）的情况，将使用UE上下文释放请求过程替代。

4.1.4 上下文管理

1.初始上下文建立流程

初始上下文建立的目的在于建立全面必要的初始UE上下文，包含E-RAB上下文、安全密钥、切换限制列表、UE无线性能以及UE安全性能等。

如图4-47所示，上下文建立请求中的E-RAB to be Setup List至少有一个E-RAB建立成功的流程。

如图4-48所示，上下文建立请求中的E-RAB to be Setup List所有E-RAB都建立失败的流程。

（1）Initial Context Setup Request消息中主要关注的信元。

① E-RAB to be Setup List：同承载管理中承载建立请求中的E-RAB to be Setup List信元，区别在于NAS-PDU的子信元是可选的，因为初始上下文里的EPS承载一般在UE和MME上都是激活的。

② UE Security Capabilities：UE的安全能力。

③ Security Key：安全密钥。

④ UE Radio Capability：UE的无线能力。

⑤ CS Fallback Indicator：指示基站本次业务是CS域需要进行回滚。

⑥ SRVCC Operation Possible：指示基站UE和MME都支持SRVCC。

（2）Initial Context Setup Response消息中主要关注的信元和E-RAB Setup Response主要关注的信元一样。

· 如果建立成功，其E-RAB列表应该包含在E-RAB Setup List IE中。

· 如果建立失败，其E-RAB列表应该包含在E-RAB Failed to Setup List IE中。

（3）Initial Context Setup Failure消息中主要关注的信元是Cause，针对cause信元需要特别说明。

首先我们来看一下Cause信元：图4-49的S1切换定时器超时；图4-50的无线连接失败；图4-51的正常释放。

这个Cause包含两部分：一部分是协议层信息，另一部分是具体的原因。

协议层包含三种类型：无线网络、传输网络、NAS。

2.上下文修改流程

如图4-52所示，UE上下文修改（UE Context Modification）过程的目的在于部分地修改建立的UE上下文[例如安全密钥（Security Key）或者无线接入类型/频率优先权签约模板]。

3.上下文建立释放流程（MME主动）

如图4-53所示，UE上下文释放（UE Context Release）过程的目的在于使得MME能够命令释放掉与UE相关的逻辑连接，这基于各种原因，例如，完成UE和EPC之间的传输，或者成功完成切换，或者完成取消切换，或者当UE已经发起建立新的与UE相关的逻辑S1连接之后，检测到与同一UE相关的逻辑S1连接有两种，那么就要释放掉旧的与UE相关的逻辑S1连接。

4.上下文建立释放流程（基站主动）

如图4-54所示，UE上下文释放请求（UE Context Release Request）过程的目的在于由于E-UTRAN产生的原因（例如“TX2RELOCOverall超时”），eNB能够请求MME释放与UE相关的逻辑S1连接。

4.1.5 NAS消息管理

关于NAS消息本身包含哪些信元已经在前面章节介绍过，在此主要介绍S1-MME接口的eNB UE S1AP ID IE和MME S1AP ID IE是怎么建立的。

Initial UE Message消息带上了基站为该用户分配的eNB UE S1AP ID，但没有携带MME S1AP ID这个信元，因为这个信元待MME为该用户分配。

1.初始UE消息

如图4-55所示，当eNB已经从无线接口接收到RRC连接上传输的第一条UL NAS消息，并要向上传递给MME时，eNB将调用NAS传输过程，并且向MME传输初始UE消息，第一条UL NAS消息包含移动性管理中的附着请求、去附着请求、跟踪区更新请求、业务请求消息。

如图4-56所示的附着请求消息，包含5个信元，依次是eNB UE S1AP ID、NAS、TAI、eCGI、RRC建立原因。

2.下行NAS消息传送

如图4-57所示，当MME收到基站的初始UE消息时，如果没有建立与该UE相关的逻辑S1连接，那么该MME将为该UE分配唯一的MME UE S1AP ID，并包含于Downlink NAS Transport消息中，通过在eNB处接收MME UE S1AP ID IE，建立起与该UE相关的逻辑S1连接。

比如在附着请求的业务过程中，MME给UE发的Authentication Request消息就是一条下行NAS消息，这条消息中携带了MME为UE分配唯一的MME UE S1AP ID，如图4-58所示。

这条消息还包含了基站为UE分配的eNB UE S1AP ID，如图4-59所示，eNB UE S1AP ID就是初始UE消息中基站为UE分配的ID，结合第4.1.5节中的初始UE消息即附着请求消息可以看到，eNB UE S1AP ID信元的值相同。

3.上行NAS消息传送

如图4-60所示，当eNB已经通过无线接口接收到一条要传递给MME的NAS消息，其中存在一条与该UE相关的逻辑S1连接时，该eNB将向MME发送Uplink NAS Transport消息，包含作为NAS-PDU IE的NAS消息，如图4-61和图4-62所示。该eNB将在每一条S1AP Uplink NAS Transport消息中包含当前小区的TAI和ECGI，如图4-63所示。

4.1.6 应用实例一

为了更好地理解S1AP协议，通过下面的一个案例可以了解到S1AP ID的概念对于S1-MME接口问题的处理有着深远的意义，比如，如何关联一个VoLTE用户的空口信令、无线信号质量和核心侧信令，都是依赖于这对S1AP ID。

1.问题现象

某日某地的4G基站出现很多S1复位告警信息。

2.问题分析

通过基站和MME共同抓包分析定位原因，具体分析过程如下。

（1）基站侧处理过程

通过提取基站的信令信息可以看到，S1-MME口的Reset信令过程是MME收到初始UE消息之后立即返回复位信令消息，消息流程如下。

· 基站上跟踪到的S1-MME口Reset信令流程，如图4-64所示。

· 基站上跟踪到Reset事件对应的Uu口信令；RRC信令请求及建立正常；S1复位后，基站向UE发送RRC_CONN_REL消息，如图4-65所示。

S1-MME口分析S1AP-Initial_UE_MSG消息；TAU类型是Combined-TA-Updating with IMSI-Attach，如图4-66所示，RRC建立原因是mo-Signalling，如图4-67所示。

从上面的消息过程可以看到复位事件的发生过程，如图4-68所示。

通过基站的S1-MME和Uu两个接口消息跟踪，可以确认Reset事件是MME认为UE的初始化请求消息异常，至于原因是什么，尚需MME进一步确认。

（2）MME侧处理过程

MME发给eNB的S1AP-Reset消息，复位原因是“未指定”，如图4-69所示，S1AP-Reset消息中的eNB-UE-S1AP-ID=5217145。

那MME给eNB发送的Reset消息是针对eNB给MME发送的哪条消息的响应呢？我们可以根据Reset消息中的eNB-UE-S1AP-ID字段找到其对应的S1AP-Initial-UE-Message消息。图4-70所示为eNB发给MME的S1AP-Initial-UE-Message消息，其中的NAS消息是TAU流程。

由上面消息可以看到用户的业务场景是在从3G网络位置区46000D11E路由区0重选到4G网络跟踪区460005143出现了S1接口复位问题。

S1接口复位消息产生的场景。

分析MME上该用户的日志信息，发现S1ap Reset过程如下。

① UE离开4G网络后，SGSN并没有通知到用户原来所在的MME该UE已经离开了4G网络，MME上还有该UE的上下文、承载等信息。

② UE在4G网络的承载没有删除，所以PGW还能接收到业务服务器的下行数据分组，并发往SGW，SGW发现没有该UE的S1-U口承载则通知MME，MME发现用户处于空闲态则寻呼该UE。

③ 在MME寻呼UE的过程中UE发起了TAU，MME收到UE的TAU后，根据TAU中携带的2G/3G网络相关信息向SGSN发送查询消息（SGSN Context Request），SGSN返回的SGSN Context Response消息中携带了UE的IMSI信息。

④ MME发现这个IMSI的UE已经在4G网络下。

⑤ 因为寻呼还在进行中，且寻呼器还没有超时，所以MME忽略了该用户的TAU，同时发S1-Reset消息到基站eNB，以告诉基站这个TAU消息在MME上处理异常，从而基站释放了该UE的空口RRC连接。

3.问题原因

S1接口复位消息产生的原因分析。

① UE登记在4G网络上，在移动过程中从4G信号强的地方到了4G信号弱的地方，从而重选到了2G/3G的网络。

② UE从4G网络向2G/3G网络移动发生RAU。

③ SGSN通过DNS解析到该用户原先所处的MME的地址，发SGSN Context Request消息给该MME，但实际用户所处的W**MME13并没有接收到SGSN的SGSN Context Request，所以MME不会转换MM Context及EPS Bearer，当PGW受到业务服务器侧发给该UE的数据分组时转发给SGW，SGW仍会通知MME有下行数据下发。

④ MME收到Downlink Data通知。

⑤ MME会寻呼该UE。

⑥ 在MME寻呼用户的过程中UE正在从2G/3G网络返回4G网络。

过程①～⑥如图4-71所示。

⑦ UE从2G/3G网络返回4G网络，并向用户原来在4G网络附着的W**MME13发送TAU请求。

⑧ MME向SGSN发送SGSN Context Request消息。

⑨ SGSN向MME发送SGSN Context Response消息，MME根据响应消息发现IMSI在MME中已有并且调度过程在继续，MME侧认为EPC出现异常并通过重置过程解决。

⑩ MME向UE发送S1AP Reset消息。

过程⑦～⑩如图4-72所示。

从上面的过程可以看到关键的一个问题，就是当用户从4G网络移动到2G/3G网络的RAU过程中，UE原先所处的MME为什么没有收到SGSN的SGSN Context Request消息？

下面就针对这个问题进行详细的分析。

SGSN对所有MME的Gn解析进行了检查，结果如表4-4所示。

从表4-4可以看到，SGSN解析WMME13得到221...3和221...130两个Gn地址，而实际上WMME13的Gn地址为221...3，221...130是W**MME01的Gn地址。

根据这个信息可以看到UE从WMME13向其他SGSN发起RAU时，SGSN通过DNS解析得到两个Gn地址，而Gn地址的使用是轮询的，如果采用221...3，则WMME13能接收到SGSN发来的SGSN Context Request，后续过程就能正常处理，不会发生本案例中所述的S1口复位事件。

如果SGSN采用221...130，则SGSN Context Request发送给WMME01，而WMME01没有该用户的任何信息，因此，路由区更新（RAU，Route Area Update）会失败，UE会重新附着到SGSN上，这样SGSN和WMME13上就都有了该UE的信息，当UE重新发起TAU到WMME13时就会发生S1接口复位的故障，因为W**MME13上已有该UE相关信息，MME认为此用户的业务出现异常需要复位来重置该UE的所有信息。

同样，对于UE Attach情况下的S1ap Reset事件是类似的。

S1接口复位消息问题产生的根本原因。

发生S1ap Reset的根源是SGSN解析的WMME13的Gn地址多了指向WMME01的Gn地址，出现这种情况可能是由于W**MME01是测试局，修改了MMEGI和MMEC后没有将DNS中原有的记录删除造成的。

4.解决方案

修改DNS配置，删除WMME13 Gn地址记录中多余的221..**.130，然后观察S1ap Reset情况，同时注意清除所有SGSN的缓存。

5.问题延伸

UE由4G网络重选或重定向到3G网络后，SGSN上根据用户RAU中的LAC和RAC两个参数通过DNS获取两个Gn口地址（WMME13和WMME01），当SGSN随机选择到WMME01的Gn口地址时（出现了图4-71中的第3步描述情况），WMME13没有收到SGSN的SGSN Context Request请求，用户的业务承载还在LTE上，当PGW还在向SGW发下行数据分组时，MME就会尝试去寻呼用户，在寻呼的过程中，如果收到TAU就不会处理，同时会向eNB发S1 Reset消息。

注：4G到3G的RAU消息中的旧LAC和旧RAC是由W**MME13的MMEGI和MMEC形成的；3G到4G的TAU消息中的旧GUTI是由用户之前所在SGSN分配的P-TMSI和所处的LAC RAC形成的。

从上面的案例处理过程可以看到，当处理网络疑难问题时，需要对各个接口的信令流程很熟悉，用户在使用网络业务时都会经过哪些网元，经过各个网元的时候都是用哪些信令消息来表达自己的业务请求，对应网元又是用哪些信令消息来回应我们的业务请求。

4.1.7 应用实例二

1.问题现象

在CSFB语音解决方案调测过程中，出现iPhone-5c用户在某些区域登不上4G网络，登在3G网络上。

2.问题分析问题复现的测试网络如图4-73所示。

在MME上跟踪用户消息，发现用户在4G网络上发起了附着请求，且核心网侧给终端返回了EPS附着接受但联合位置更新失败，因而，可以看出来4G信号是没有问题的，终端也无问题，4G网络的数据配置疏漏导致用户联合位置更新失败，而iPhone-5c是语音优先的，当发现当前网络不能提供CS语音业务时，要按照协议规范重新搜索3G网络。

联合位置更新失败。

（1）流程如图4-74所示

（2）联合位置更新请求

我们从UE发起的TAU-Req消息可以看出是联合位置更新请求，如图4-75所示。

（3）MME未发起CS域位置更新（联合位置更新失败）

MME返回的TAU-Accept中带了CS Domain Not Avaliable的EMM原因，如图4-76所示。

EMM原因是“CS Domain Not Available”，按照3GPP TS 24.301对这个原因值描述是：The UE shall not attempt combined attach or combined tracking area Update procedure with current PLMN until switching off the UE or the UICC containing the USIM is removed。（UE不再在当前PLMN网络尝试联合附着或联合跟