最近在新项目中处理了一个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则为FDD制式，>32为TDD制式。从Rel13.2.0，引入了新的FDD制式B65和B66。
(Before Rel 13, FDD bands <= 32 and TDD bands >32. But from Rel13.2.0, FDD new bands B65 and B66 was introduced )
(Rel 12)
(Rel 13.2.0)
频率范围倒是没有什么特殊的，还是复用之前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 IE in 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必须存在的前提条件就是dl-CarrierFreq设置为maxEARFCN，即65535（dl-CarrierFreq 65535） ( This extension IE must be present if dl-CarrierFreq is set to maxEARFCN, that is,dl-CarrierFreq 65535)
协议里规定如果存在扩展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, which lead 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: After rel_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. )
（本文完）
来源：CSDN
作者：知不足而奋进
链接：https://blog.csdn.net/ZhongGuoRenMei/article/details/103679388