category ue 协议_LTE中UE能力（UE Capability）的梳理和解析

1.  关于LTE中UE能力的问题，也是大家经常提问的地方之一。  比如” UE支持的RAT？  /  UE支持的Frequecy band ？ /  UE的功率等级？ /  UE是否支持CA，且是那种类型的CA？  /  UE是否支持PS HO ？ /  UE是否支持SRVCC？ /  现在系统间移动性大多采用Redirect而不是PS HO, 是UE能力不支持么？  /  UE支持哪些安全算法(加密/完保)？”……  等等，这些问题都牵扯到UE能力。  所以今天春天工作室试图对其进行梳理和解析。

2.  UE能力可分为无线接入相关能力及核心网相关能力。The UE Capability information is made up of the UE Radio Capabilityinformationand the UE Core Network Capability information。 涉及到UE能力的规范比较多，这里先列出规范号，分别是36.101/36.306/23.401/36.331/24.008。

3.  网络侧在做各种事件判决或执行各种算法时，均需知道UE的能力，才能做出最切合的判决。比如，UE如果支持CSFB发起联合附着，那么此时网络侧对其执行和处理的过程会不一样；  如果UE不支持PS HO的inter-RAT的mobility时， 那么网络也只能采取NACC/CCO或者Redirct来实现系统间互操作了；所以，由于UE的能力各不相同且差异较大，那么网络需要获知UE的能力。 这就要求UE能力可以通过某种方式上报并同步了。

4.   UE的能力上报及同步，是UE第一次ATTACH或TAU的时候，UE会主动上报自己的能力，此属于NAS过程； 而无线侧在RRC规范中，也有UE能力查询过程，获取并传递UE能力。

5.      下面贴图是一次完成的attach的过程。我们可以把UE能力查询及上报的过程，放在整个信令流程中去理解。

参考上图，如果消息9中，携带了UE Radio Capability 的IE，则eNB不会发送UECapabilityEnquiry消息给UE，即没有10/11/12的过程； 否则，如果消息9中没有携带UE能力，则基站会发起UE能力查询过程，这在第一次入网(ATTACH/TAU)的过程中经常会看到。而UE上报了无线能力信息到eNB之后，eNB再给MME发送Capability Info Indication消息，传递并上报UE的能力信息至MME。

而在协议设计中，为了减少空口信令开销，MME会保存UE Radio Capability信息，而在S1流程INITIAL CONTEXT SETUP REQUEST消息中，MME还会把UE能力传递给eNB，故此时eNB无需针对UE发起UECapabilityEnquiry过程，因为UE能力可知。

但是，在UE在执行attach或者“first TAU following GERAN/UTRANAttach” 或“UE radio capability update”时， MME不会在INITIAL CONTEXT SETUP REQUEST消息中带UE Radio Capability信息给eNB的， 并会把本地保存的UE Radio Capability信息删除，故这三种情况，eNB会问UE要UE能力，在eNB获知之后还需上报给MME。

注：'UEradio capability update' TAU is only supported for changes of GERAN and UTRAN radio capabilities in ECM-IDLE。

这里面有2个推论：  1. 在RRC-CONNECTED下，eNB也会一直保存UE Radio Capability信息。反过来，UE从RRC连接态转移到RRC空闲态下，UE的RRC连接的上下文会释放，自然eNB针对某个UE的能力信息也将删除。但此时MME不会删除UE的能力信息的，因为MME依然是MM-REGISTERED，除非UE去附着(detach)或其他。    2.  UE无线能力信息如果发生改变，UE需要先发起detach，再attach。  一个很简单的例子，比如我们把CMCC的5模手机现在锁死在LTE单模下工作，相当于人为的改变了UE的能力，此时我们会发现UE的信号图标，会暗了，再亮了。 如果去跟信令的话，这就会是一次“UE能力改变”导致的“去附着 附着“ 的过程。这样去附着 附着机制，保证了UE能力信息的同步。

进一步说，在附着过程中，与UE能力相关的信令，会有2个 ——NAS EMM信令 ATTACH REQUEST 及 RRC信令UE Capability Enquiry / Information。之前的贴图中已经标注。

可以看出，在Attach request中，UE会将自己的安全能力(支持的EEA/EIA算法)上报， 其目的是协商UE和MME之间的NAS安全性，并对随后的NAS信令交互进行加密和完整性保护。 另外注意到，除了UE network capability之外， UE还会上报跟23G相关的MS Radio Access capability，后者对现在234G共存的情况下变得重要。截图如下：

6.      RRC过程中与UE能力相关的主要是UECapabilityEnquiry及UECapabilityInformation。其中最丰富的是UECapabilityInformation，规范中的截图如下：

截图限于篇幅并没有完整的截完，具体参考TS36.331等规范。这里对某些IE做简要解释：

accessStratumRelease：接入版本，其实就是3GPP版本，比如R9、R10。

ue-Category：就是我们通常所说的手机种类。见下截图，其中蓝字部分为Release8中定义的内容，绿字部分为Release10定义的内容。UE Category 有时也被称作 UE Class。eNodeB和UE之间需用通过UE Category来确定UE的传输能力。

pdcp-Parameters：UE支持的ROHC头压缩算法的能力情况。

rf-Parameters：UE射频能力，表示UE能够支持的band。

FGI(Feature group indicators)：这项非常重要但也比较繁琐，显示了UE的各种实际能力，不同的能力的支持，在网络中就会有不同体现。 eNB也会根据这些能力做不同判断。 而在36.331附录B1中