最近在新項目中處理了一個T-Mobile non-stock產品入庫的case，第一次聽說了這個神奇的B66，期間查閱了相關協議文檔，最終成型了這篇類似技術Memo的東東。相比較於讓我幹讀協議進行純理論學習，我更喜歡這種on-job training，有動力且不枯燥。
目前LTE FDD B66隻有北美有部署，且只有4家運營商，稍大點就是美帝的T-Mobile了
(Currently, LTE FDD B66 is deployed onlyat North America area and There are only 4 Mobile Carriers to support it, oneof which is T-Mobile at biggest. )
對於更多信息，請查閱以下連結（說句題外話，聊天得知讀者裡有各司負責海外運營商需求的朋友們和產品經理們，請收藏下這個連結，裡面有海外各國家地區各運營商頻段分布的具體信息哦，不謝）
For more, https://www.frequencycheck.com/bands/lte-band-66-1700-2100.
在Rel 13之前， FDD和TDD band的分水嶺就是32，32為TDD制式。從Rel13.2.0，引入了新的FDD制式B65和B66。
(Before Rel 13, FDD bands 32. But from Rel13.2.0, FDD new bands B65 and B66 was introduced )
(Rel 12)
頻率範圍倒是沒有什麼特殊的，還是復用之前B1, B4, B10的，但是EARFCN號分配的異常大，66436到67335， 如下表 (the frequency of B66 is overlapped with B1/4/10 but the EAFRCN used by B66 is super big, from 66436 to 67335 )
這樣帶來的影響有（The affect of B66 introduction）
1.跟頻段指示相關的信元，如freqBandIndicator IEin SIB1或者multiBandInfolist
翻閱TS36.331，指示小區頻段的freBandIndicator IE取值範圍最大到64，無法滿足指示B66需求( Afterlooking up in TS 36.331, The freBandIndicator IE in SIB1 to indicate cellband reaches 64 at max and cannot indicate Band 66 in it)
3GPP通過一個新的擴展IE，加了後綴的-v9e0的FreqBandIndicator-v9e0來解決這種問題
(To resolve this issue, a new extension IE with suffix –v9e0 namedFreqBandIndicator-v9e0 came for this )
其中，
這個擴展IE必須存在的前提條件就是freqBandIndicator設置為maxFBI，即64（freqBandIndicator 64） ( This extension IE must be present iffreqBandIndicator is set to maxFBI, that is, freqBandIndicator 64 )
協議裡規定如果存在擴展IE，終端一定且只能使用擴展IE，忽略不帶後綴的freqBandIndicator。( Spec says if an extension is signaled using the extended value, the UE shall only use this extension and ignore the original field)
對於本文中的B66，實例為
2.跟channel號/EARFCN相關的信元，如 dl-CarrierFreq in SIB5, 或者ul-CarrierFreq in SIB2等
翻閱TS36.331，指示小區EARFCN的dl-CarrierFreqIE取值範圍最大到65535，無法滿足指示B66需求?(After looking up in TS 36.331, The dl-CarrierFreq IE in SIB5 to indicate cell channel No reaches 65535 at max and cannot meet Band 66 requirement)
同樣地，3GPP也通過一個新的擴展IE，加了後綴的-v9e0的dl-CarrierFreq-v9e0來解決這種問題(To resolve this issue, a new extension IE with suffix –v9e0 named dl-CarrierFreq-v9e0 came for this )
其中，
協議裡規定如果存在擴展IE，終端一定且只能使用擴展IE，忽略不帶後綴的EARFCN值。( Spec says if an extension is signaled using the extended value, the UE shall only use this extension and ignore the original field)
舉個ul-CarrierFreq in SIB2的例子：
引入MFBI後，情況更加複雜，那麼何為MFBI呢？MFBI = Multiple Frequency Band Indicator. 隨著每個新的Rel引入新的LTE bands越來越多，很多band間頻率實際上是重疊復用的。所以一個cell可能既是Band A同時也是Band B，下圖示例為B38和B41。隨之MFBI應運而生。
( After MFBI is involved, the situation becomes more complicated. So what is so-called MFBI? MFBI = Multiple Frequency Band Indicator. When more and more LTE bands were introduced by each new Release version, the frequency used among LTE bands has more chance to be overlapped. Like one cell can be both of B38 and B41 at same time. As a result, MFBI came into our eyes )
以本文中的Rel 13.2.0引入的B66為例，實際上在上下行方面分別和已有Band發生重疊，如下圖所示：
( Taking LTE B66 as example, It has many overlapped frequencies with existing legacy LTE Bands both in UL and DL like B1/4/10 in DL direction)
MFBI主要通過multiBandInfoList IE來表示對於UE如何識別那些重疊的頻率具體是哪個band，其中freqBandIndicator優先級高於multiBandInfoList裡的band列表，只有當UE不支持freqBandIndicator指定的Band且支持MFBI（FGI31 = 1）時，才會繼續讀取multiBandInfoList裡的第一個band。
( MFBI function is using multiBandInfoList to present how to recognize the Band for overlapped frequency on UE side.The priority Of freqBandIndicator is higher than ones in multiBandInfoList. Only if UE not support the band specified in freqBandIndicator and supports MFBI( FGI31=1 ), It shall apply the first listedband in multiBandInfoList IE. )
當以上的知識點全部交織在一起時，3GPP TS36.331中列出了一個有趣的例子：
(a funny sample in 3GPP TS36.331 mixing up all the knowledges mentioned in today's topic )
前面這些熱身已經完畢，大家都get到相關知識點後，讓我們回到文中開始提到的那個問題。
( Warm up is done and I truely believe everyone gets the basic knowledge. Let's back to the issue reported from T-Mobile lab entry )
先看看W網絡重定向的內容
（Let's see the RRC redirection signalling in WCDMA NW）
20:10:46.806 LTE RRC/High[ lte_rrc_utils.c 2370] UTILS:Invalid LTE Band for EARFCN (65535)
UE並沒有識別出擴展IE --- rrcConnectionRelease-vb50ext，即Rel 11.5.0引入的新IE。
( UE cannot recognize vb50ext IE of earfcn 66886. So it thinks DL reserved EARFCN value 65535 is invalid, whichlead to W->L Redirection failure)
繼續調查當前UE支持的Rel版本號。從UECapabilityInformation信令看，只寫了大版本為Rel 11，很粗略.
( Continue to find out the latest Rel version UE supports at current. From accessStratumRelease IE, It is Rel 11. For sub version of R11, Knows nothing from it.)
2018 Sep 6 20:10:11.532 [58] 0xB0C0 LTE RRC OTA Packet -- UL_DCCH / UECapabilityInformation
查看Lte_rrc_capabilities.c子模塊列印可得知Rel_version = 0x82, 0x82為Q內部枚舉，實際對應LTE_3GPP_REL11_MAR14. 有代碼的童鞋可查看lte.h文件。究竟是13年3月14日還是14年3月14日呢？不得而知。
( From below trace in lte_rrc_capabilities.c, we can know Rel_version is 0x82 which corresponds to LTE_3GPP_REL11_MAR14 in lte.h but it is 2013.3.14 or 2014.3.14? who knows )
20:09:47.632 LTE RRC/High [lte_rrc_capabilities.c 3327] CAP: Afterrel_ver 0x82, ta_en 0, ca_en 1,cat 15, cap_sent_after_switch 1, ca_detach_needed 0
明顯這個vb50擴展IE是在2013年9月19日RAN#61次會議提出的（Rel11.5.0），我只好大膽推測LTE_3GPP_REL11_MAR14是2013年3月14日，所以當前Rel版本早於Rel11.5.0，UE無法識別
( Obviously, this vb50ext IE was introduced at RAN#61 on 2013-09-19. I have to assume LTE_3GPP_REL11_MAR14 is 2013.3.14 earlier than Rel 11.5.0. Thus, It is normal that UE based on that rel version cannot recognize this vb50ext IE. )
（本文完）
公眾號請掃碼：