lte中ue能力(uecapability)的梳理和解析

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 Capabilityinformation and 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中，对FGI的各个bit所对应的能力做了完整的定义，置1表示支持，置0表示不支持，感兴趣的请参考。interRAT-Parameters： UE对于异系统的支持能力，这是eNB判决UE能否进行互操作的重要依据。

在R10中引入了CA载波聚合，故支持CA的UE需要在接入的时候上报其CA的支持情况，其中会有

ca-BandwidthClassDL-r10 ca-BandwidthClassUL-r10等IE，见前面的截图。 比如，如果ca-BandwidthClassDL-r10 为a类别，就说明UE下行只支持1个载波； 如果

ca-BandwidthClassDL-r10 为c类别，就说明UE下行支持2个CC的载波聚合。 Class A: aggregated transmitted BW configuration <= 100PRBs and 1 component carrier。 Class C: aggregated transmitted BWconfiguration of 101 to 200 PRBs and 2 component carriers。 关于CA的类别，见后面的截图。 附录1：23401中关于UE能力处理过程的描述5.11 UE Capability Handling5.11.1 GeneralThe UE Capability information is made up of the UE Radio Capabilityinformation and the UE Core Network Capability information.5.11.2 UE Radio Capability HandlingThe UE Radio Capability information contains information on RATsthat the UE supports (e.g. power class, frequency bands, etc). Consequently,this information can be sufficiently large (e.g. >50 octets) that it isundesirable to send it across the radio interface at every transition from ECM?IDLEto ECM?CONNECTED. To avoidthis radio overhead, the MME stores the UE Capability information during ECM?IDLEstate and the MME shall, if it is available, send its

本文来源：https://www.bwwdw.com/article/9kdd.html