|
1. 關(guān)于LTE中UE能力的問題，也是大家經(jīng)常提問的地方之一。 比如 ” UE支持的RAT？ / UE支持的Frequecy band ？ / UE的功率等級？ / UE是否支持CA，且是那種類型的CA？ / UE是否支持PS HO ？ / UE是否支持SRVCC？ / 現(xiàn)在系統(tǒng)間移動性大多采用Redirect而不是PS HO, 是UE能力不支持么？ / UE支持哪些安全算法（加密/完保）？”…… 等等，這些問題都牽扯到UE能力。 所以今天春天工作室試圖對其進(jìn)行梳理和解析。 2. UE能力可分為無線接入相關(guān)能力及核心網(wǎng)相關(guān)能力。The UE Capability information is made up of the UE Radio Capabilityinformation and the UE Core Network Capability information。 涉及到UE能力的規(guī)范比較多，這里先列出規(guī)范號，分別是36.101/36.306/23.401/36.331/24.008。 3. 網(wǎng)絡(luò)側(cè)在做各種事件判決或執(zhí)行各種算法時，均需知道UE的能力，才能做出最切合的判決。比如，UE如果支持CSFB發(fā)起聯(lián)合附著，那么此時網(wǎng)絡(luò)側(cè)對其執(zhí)行和處理的過程會不一樣； 如果UE不支持PS HO的inter-RAT的mobility時， 那么網(wǎng)絡(luò)也只能采取NACC/CCO或者Redirct來實現(xiàn)系統(tǒng)間互操作了；所以，由于UE的能力各不相同且差異較大，那么網(wǎng)絡(luò)需要獲知UE的能力。 這就要求UE能力可以通過某種方式上報并同步了。 4. UE的能力上報及同步，是UE第一次ATTACH或TAU的時候，UE會主動上報自己的能力，此屬于NAS過程； 而無線側(cè)在RRC規(guī)范中，也有UE能力查詢過程，獲取并傳遞UE能力。 5. 下面貼圖是一次完成的attach的過程。我們可以把UE能力查詢及上報的過程，放在整個信令流程中去理解。
而在協(xié)議設(shè)計中，為了減少空口信令開銷，MME會保存UE Radio Capability信息，而在S1流程INITIAL CONTEXT SETUP REQUEST消息中，MME還會把UE能力傳遞給eNB，故此時eNB無需針對UE發(fā)起UECapabilityEnquiry過程，因為UE能力可知。 但是，在UE在執(zhí)行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連接態(tài)轉(zhuǎn)移到RRC空閑態(tài)下，UE的RRC連接的上下文會釋放，自然eNB針對某個UE的能力信息也將刪除。但此時MME不會刪除UE的能力信息的，因為MME依然是MM-REGISTERED，除非UE去附著（detach）或其他。 2. UE無線能力信息如果發(fā)生改變，UE需要先發(fā)起detach，再attach。 一個很簡單的例子，比如我們把CMCC的5模手機(jī)現(xiàn)在鎖死在LTE單模下工作，相當(dāng)于人為的改變了UE的能力，此時我們會發(fā)現(xiàn)UE的信號圖標(biāo)，會暗了，再亮了。 如果去跟信令的話，這就會是一次“UE能力改變”導(dǎo)致的“去附著 附著“ 的過程。這樣去附著 附著機(jī)制，保證了UE能力信息的同步。 進(jìn)一步說，在附著過程中，與UE能力相關(guān)的信令，會有2個 —— NAS EMM信令 ATTACH REQUEST 及 RRC信令UE Capability Enquiry / Information。之前的貼圖中已經(jīng)標(biāo)注。 可以看出，在Attach request中，UE會將自己的安全能力（支持的EEA/EIA算法）上報， 其目的是協(xié)商UE和MME之間的NAS安全性，并對隨后的NAS信令交互進(jìn)行加密和完整性保護(hù)。 另外注意到，除了UE network capability之外， UE還會上報跟23G相關(guān)的MS Radio Access capability，后者對現(xiàn)在234G共存的情況下變得重要。截圖如下： 6. RRC過程中與UE能力相關(guān)的主要是UECapabilityEnquiry及UECapabilityInformation。其中最豐富的是UECapabilityInformation，規(guī)范中的截圖如下：
截圖限于篇幅并沒有完整的截完，具體參考TS36.331等規(guī)范。這里對某些IE做簡要解釋： accessStratumRelease： 接入版本，其實就是3GPP版本，比如R9、R10。 ue-Category： 就是我們通常所說的手機(jī)種類。見下截圖，其中藍(lán)字部分為Release8中定義的內(nèi)容，綠字部分為Release10定義的內(nèi)容。UE Category 有時也被稱作 UE Class。eNodeB和UE之間需用通過UE Category來確定UE的傳輸能力。
pdcp-Parameters： UE支持的ROHC頭壓縮算法的能力情況。 rf-Parameters： UE射頻能力，表示UE能夠支持的band。 FGI（Feature group indicators）： 這項非常重要但也比較繁瑣，顯示了UE的各種實際能力，不同的能力的支持，在網(wǎng)絡(luò)中就會有不同體現(xiàn)。 eNB也會根據(jù)這些能力做不同判斷。 而在36.331附錄B1中，對FGI的各個bit所對應(yīng)的能力做了完整的定義，置1表示支持，置0表示不支持，感興趣的請參考。 interRAT-Parameters： UE對于異系統(tǒng)的支持能力，這是eNB判決UE能否進(jìn)行互操作的重要依據(jù)。
在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。 關(guān)于CA的類別，見后面的截圖。
附錄1：23401中關(guān)于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 most up to date UE RadioCapability information to the E?UTRAN in the S1 interface INITIAL CONTEXT SETUPREQUEST message unless the UE is performing an Attach procedure or a TrackingArea Update procedure for the 'first TAU following GERAN/UTRANAttach' orfor a 'UE radio capabilityupdate'. NOTE 1: Fora GERAN/UTRAN/E-UTRAN capable UE, this UE Radio Capability information isbroadly equivalent to the combination of the MS Radio Access capability sent in theTS 24.008 [47] Attach Request message plus the Inter RAT Handoverinformation sent in the TS 24.008 [47] Attach Complete message. If the UE is performing an Attach procedureor a Tracking Area Update procedure for the 'first TAU followingGERAN/UTRAN Attach' or for 'UE radio capability update', the MMEshall delete (or mark as deleted) any UE Radio Capability information that ithas stored, and, if the MME sends an S1 interface INITIAL CONTEXT SETUP REQUESTmessage during that procedure, the MME shall not send any UE Radio Capabilityinformation to the E?UTRAN in that message. This triggers the E?UTRAN torequest the UE Radio Capability from the UE and upload it to the MME in the S1interface UE CAPABILITY INFO INDICATION message. If the UE is performing a Service Request(or other) procedure and the MME does not have UE Radio Capability informationavailable (or it is available, but marked as 'deleted'), then the MMEsends an S1 interface INITIAL CONTEXT SETUP REQUEST message to the E?UTRANwithout any UE Radio Capability information in it. This triggers the E?UTRAN torequest the UE Radio Capability from the UE and upload it to the MME in the S1interface UE CAPABILITY INFO INDICATION message. NOTE 2: Thisuse of the INITIAL CONTEXT SETUP REQUEST message means that for a signallingonly procedure such as a periodic Tracking Area Update, the UE Radio Capability would not be sent to the E?UTRAN. NOTE 3: If a 'first TAU following GERAN/UTRAN Attach' Tracking Area Update isperformed during ECM-CONNECTED mode, e.g. after an inter RAT handover, noINITIAL CONTEXT SETUP REQUEST is sent and the UE Radio Capability informationin the MME will remain deleted until the next ECM-IDLE to ECM-CONNECTEDtransition (or later, e.g. if the next activity from the UE is another TrackingArea Update). The UE Radio Capability is not provided directly from one CN node toanother. It will be uploaded to the MME when the E-UTRAN requests the UE RadioCapability information from the UE. During handover via the MME (both intra RAT and inter RAT), the UERadio Capability is transferred in the 'source to target transparent container'.Even in the case of handover from a different RAT, this UE Radio Capabilityshould be the full radio capability information for all of the 3GPP RATs thatthat UE supports. NOTE 4: For example in the case of a GERAN/UTRAN/E-UTRAN capable UE being handed over fromGERAN to E-UTRAN, the 'source to target transparent container' wouldcarry UTRAN, GERAN and E-UTRAN radio access capabilities. This is necessary toenable subsequent handovers to a different (and/or the original) RAT. To allow for the addition of future radio technologies, frequencybands, and other enhancements, the MME shall store the UE Radio CapabilityInformation even if it is larger than specified in TS 36.331 [37], upto a maximum size of 510 octets. NOTE 5: The510 octet value comes from the information element encoding rulesdescribed in TS 24.007 [45] and the assumption that the informationcontained within this UE Radio Capability Information Element stored by the MMEis the equivalent of information signalled in two information elements in theGERAN NAS signalling for the case of GERAN to E?UTRAN PS handover. The E?UTRAN stores the UE Radio Capability information, received inthe S1 interface INITIAL CONTEXT SETUP REQUEST message or obtained from the UE,for the duration of the RRC connection for that UE. If the UE's UE Radio Capability information changes while inECM-IDLE state (including cases of being in GERAN/UTRAN coverage), the UE shallperform a Tracking Area Update indicating 'UE radio capabilityupdate' when it next returns to E?UTRAN coverage. NOTE 6: Inthis release of the specifications, 'UE radio capability update' isonly supported for changes of GERAN and UTRAN radio capabilities in ECM-IDLE.Any change in the UE's E?UTRAN capabilities requires the UE to detach and thenre-attach to the system. 5.11.3 UE Core Network CapabilityThe UE Core Network Capability is splitinto the UE Network Capability IE (mostly for E-UTRAN access related corenetwork parameters) and the MS Network Capability IE (mostly for UTRAN/GERAN accessrelated core network parameters) and contains non radio-related capabilities,e.g. the NAS security algorithms etc. Both the UE Network Capability and the MSNetwork Capability are transferred between CN nodes at MME to MME, MME to SGSN,SGSN to SGSN, and SGSN to MME changes. (……) 附錄2：36331中關(guān)于UE能力中的FGI的定義 B.1 Feature group indicators This annex contains the definitions of thebits in field featureGroupIndicators. In this release of the protocol, the UE shall include the field feature Group Indicators in the IE UE-EUTRA-Capability. All the functionalities defined within the field feature Group Indicators defined in Table B.1-1 are mandatory for the UE, if the related capability (frequency band, RAT or SR-VCC) is also supported. For a specific indicator, if all functionalities for a feature group listed in Table B.1-1 have been implemented and tested, the UE shall set theindicator as one (1), else (i.e. if any one of the functionalities in a featuregroup listed in Table B.1-1, which have not been implemented or tested), the UE shall set the indicator as zero (0). The UE shall set all indicators that correspond to RATs not supported by the UE as zero (0). The UE shall set all indicators, which do not have a definition in Table B.1-1, as zero (0). If the optional field featureGroupIndicators is not included by a UE of a future release,the network may assume that all features pertaining to the RATs supported bythe UE, listed in Table B.1-1 and deployed in the network, have beenimplemented and tested by the UE. In Table B.1-1, a 'VoLTE capable UE'corresponds to a UE that is capable of the 'Voice domain preference for E-UTRAN' defined in TS 24.301 [35] being set to 'IMS PS voiceonly', 'IMS PS voice preferred, CS voice as secondary' or 'CS voice preferred, IMS PS voice as secondary'. Table B.1-1: Definitions of feature groupindicators
Clarificationfor mobility from EUTRAN and inter-frequency handover within EUTRAN There are several feature groups related to mobility from E-UTRAN and inter-frequency handover within EUTRAN. The description of these features is based on the assumption that we have 5 main 'functions'related to mobility from E-UTRAN: A. Supportof measurements and cell reselection procedure in idle mode B. Supportof RRC release with redirection procedure in connected mode C. Supportof Network Assisted Cell Change in connected mode D. Supportof measurements and reporting in connected mode E. Supportof handover procedure in connected mode All functions can be applied for mobility to Inter-frequency to EUTRAN, GERAN, UTRAN, CDMA2000 HRPD and CDMA2000 1xRTT except for function C) which is only applicablefor mobility to GERAN. Table B.1-2 below summarises the mobility functions thatare supported based on the UE capability signaling (band support) and thesetting of the feature group support indicators. Table B.1-2: Mobility from E-UTRAN
In case measurements and reporting functionis not supported by UE, the network may still issue the mobility procedures redirection(B) and CCO (C) in a blind fashion. ---------------------------------------------------------------------------------------------------- 春天工作室致力于打造國內(nèi)專業(yè)級無線技術(shù)知識分享及探討平臺，主要專注于2345G技術(shù)研究。聯(lián)系微信：icehero312 |
|
|
來自： 昵稱38228073 > 《文件夾1》
