lte中ue能力uecapability的梳理和解析.docx

lte中ue能力uecapability的梳理和解析.docx

《lte中ue能力uecapability的梳理和解析.docx》由会员分享，可在线阅读，更多相关《lte中ue能力uecapability的梳理和解析.docx（5页珍藏版）》请在冰豆网上搜索。

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

LTE中UE能力（UECapability）的梳理和解析

1.关于LTE中UE能力的问题，也是大家经常提问的地方之一。

比如”UE支持的RAT？

/UE支持的Frequecyband？

/UE的功率等级？

/UE是否支持CA，且是那种类型的CA？

/UE是否支持PSHO？

/UE是否支持SRVCC？

/现在系统间移动性大多采用Redirect而不是PSHO,是UE能力不支持么？

/UE支持哪些安全算法（加密/完保）？

”……等等，这些问题都牵扯到UE能力。

所以今天春天工作室试图对其进行梳理和解析。

2.UE能力可分为无线接入相关能力及核心网相关能力。

TheUECapabilityinformationismadeupoftheUERadioCapabilityinformationandtheUECoreNetworkCapabilityinformation。

涉及到UE能力的规范比较多，这里先列出规范号，分别是36.101/36.306/23.401/36.331/24.008。

3.网络侧在做各种事件判决或执行各种算法时，均需知道UE的能力，才能做出最切合的判决。

比如，UE如果支持CSFB发起联合附着，那么此时网络侧对其执行和处理的过程会不一样；如果UE不支持PSHO的inter-RAT的mobility时，那么网络也只能采取NACC/CCO或者Redirct来实现系统间互操作了；所以，由于UE的能力各不相同且差异较大，那么网络需要获知UE的能力。

这就要求UE能力可以通过某种方式上报并同步了。

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

5.下面贴图是一次完成的attach的过程。

我们可以把UE能力查询及上报的过程，放在整个信令流程中去理解。

参考上图，如果消息9中，携带了UERadioCapability的IE，则eNB不会发送UECapabilityEnquiry消息给UE，即没有10/11/12的过程；否则，如果消息9中没有携带UE能力，则基站会发起UE能力查询过程，这在第一次入网（ATTACH/TAU）的过程中经常会看到。

而UE上报了无线能力信息到eNB之后，eNB再给MME发送CapabilityInfoIndication消息，传递并上报UE的能力信息至MME。

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

但是，在UE在执行attach或者“firstTAUfollowingGERAN/UTRANAttach”或“UEradiocapabilityupdate”时，MME不会在INITIALCONTEXTSETUPREQUEST消息中带UERadioCapability信息给eNB的，并会把本地保存的UERadioCapability信息删除，故这三种情况，eNB会问UE要UE能力，在eNB获知之后还需上报给MME。

注：

'UEradiocapabilityupdate'TAUisonlysupportedforchangesofGERANandUTRANradiocapabilitiesinECM-IDLE。

这里面有2个推论：

1.在RRC-CONNECTED下，eNB也会一直保存UERadioCapability信息。

反过来，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个——NASEMM信令ATTACHREQUEST及RRC信令UECapabilityEnquiry/Information。

之前的贴图中已经标注。

可以看出，在Attachrequest中，UE会将自己的安全能力（支持的EEA/EIA算法）上报，其目的是协商UE和MME之间的NAS安全性，并对随后的NAS信令交互进行加密和完整性保护。

另外注意到，除了UEnetworkcapability之外，UE还会上报跟23G相关的MSRadioAccesscapability，后者对现在234G共存的情况下变得重要。

截图如下：

6.RRC过程中与UE能力相关的主要是UECapabilityEnquiry及UECapabilityInformation。

其中最丰富的是UECapabilityInformation，规范中的截图如下：

截图限于篇幅并没有完整的截完，具体参考TS36.331等规范。

这里对某些IE做简要解释：

accessStratumRelease：

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

ue-Category：

就是我们通常所说的手机种类。

见下截图，其中蓝字部分为Release8中定义的内容，绿字部分为Release10定义的内容。

UECategory有时也被称作UEClass。

eNodeB和UE之间需用通过UECategory来确定UE的传输能力。

pdcp-Parameters：

UE支持的ROHC头压缩算法的能力情况。

rf-Parameters：

UE射频能力，表示UE能够支持的band。

FGI（Featuregroupindicators）：

这项非常重要但也比较繁琐，显示了UE的各种实际能力，不同的能力的支持，在网络中就会有不同体现。

eNB也会根据这些能力做不同判断。

而在36.331附录B1中，对FGI的各个bit所对应的能力做了完整的定义，置1表示支持，置0表示不支持，感兴趣的请参考。

interRAT-Parameters：

UE对于异系统的支持能力，这是eNB判决UE能否进行互操作的重要依据。

在R10中引入了CA载波聚合，故支持CA的UE需要在接入的时候上报其CA的支持情况，其中会有ca-BandwidthClassDL-r10ca-BandwidthClassUL-r10等IE，见前面的截图。

比如，如果ca-BandwidthClassDL-r10为a类别，就说明UE下行只支持1个载波；如果ca-BandwidthClassDL-r10为c类别，就说明UE下行支持2个CC的载波聚合。

ClassA:

aggregatedtransmittedBWconfiguration<=100PRBsand1componentcarrier。

ClassC:

aggregatedtransmittedBWconfigurationof101to200PRBsand2componentcarriers。

关于CA的类别，见后面的截图。

附录1：

23401中关于UE能力处理过程的描述5.11UECapabilityHandling5.11.1GeneralTheUECapabilityinformationismadeupoftheUERadioCapabilityinformationandtheUECoreNetworkCapabilityinformation.5.11.2UERadioCapabilityHandlingTheUERadioCapabilityinformationcontainsinformationonRATsthattheUEsupports（e.g.powerclass,frequencybands,etc）.Consequently,thisinformationcanbesufficientlylarge（e.g.>50octets）thatitisundesirabletosenditacrosstheradiointerfaceateverytransitionfromECM?

IDLEtoECM?

CONNECTED.Toavoidthisradiooverhead,theMMEstorestheUECapabilityinformationduringECM?

IDLEstateandtheMMEshall,ifitisavailable,senditsmostuptodateUERadioCapabilityinformationtotheE?

UTRANintheS1interfaceINITIALCONTEXTSETUPREQUESTmessageunlesstheUEisperforminganAttachprocedureoraTrackingAreaUpdateprocedureforthe'firstTAUfollowingGERAN/UTRANAttach'orfora'UEradiocapabilityupdate'.NOTE1:

ForaGERAN/UTRAN/E-UTRANcapableUE,thisUERadioCapabilityinformationisbroadlyequivalenttothecombinationoftheMSRadioAccesscapabilitysentintheTS24.008[47]AttachRequestmessageplustheInterRATHandoverinformationsentintheTS24.008[47]AttachCompletemessage.IftheUEisperforminganAttachprocedureoraTrackingAreaUpdateprocedureforthe'firstTAUfollowingGERAN/UTRANAttach'orfor'UEradiocapabilityupdate',theMMEshalldelete（ormarkasdeleted）anyUERadioCapabilityinformationthatithasstored,and,iftheMMEsendsanS1interfaceINITIALCONTEXTSETUPREQUESTmessageduringthatprocedure,theMMEshallnotsendanyUERadioCapabilityinformationtotheE?

UTRANinthatmessage