|
阅读提要： 前两期连载文章从物联网的接入网技术以及核心网流程进行了解读，详情请戳 本期我们从物联网重要技术标准分支NB-IoT的下行物理层流程入手继续解读。 蜂窝式物联网技术大体分为两种，一种是NB-IoT技术，一种是非NB-IoT技术（例如eMTC等），这两种技术在物理层架构，协议标准上有所区别。 NB-IoT技术提供了一种低功耗的网络接入方式。目前NB-IoT协议只支持FDD（频分双工）工作模式，载波带宽180kHz，相当于LTE网络的一个PRB的带宽，子载波间隔可以是3.75kHz或者15kHz。NB-IoT与Rel-8定义的LTE网络技术，UE是相对独立的，像跨系统移动性，切换，测量报告，GBR，载波聚合，双连接，CSFB回落，物物通信等技术功能在NB-IoT是不支持的。 NB-IoT与LTE大网之间的共存模式有三种，分别是In-band(带内),Guard-band（保护带）,Standalone（独立）。这也意味着NB-IoT如何组网，采取带内组网方式部署较容易，同厂家升级较快，但是对于LTE网内的资源调度会有一定影响。保护带组网方式相比带内频率效率更高，但是需要考虑和大网的干扰共存。独立组网方式与LTE大网可以完全分开，独立运维，但是需要额外的FDD频谱资源。 UE通过小区同步，解读MIB-NB系统消息可以得知组网的模式。 NRS（Narrowband Reference Signal）如同LTE的CRS，窄带参考信号也是NB-IoT里面重要的物理层信号，作为信道估计与网络覆盖评估的重要参考依据。在UE没有解读到MIB-NB里面的operationModeInfo字段时，UE默认NRS窄带参考信号分别在子帧0,4和9（不包含NSSS）上进行传输。当UE解码MIB-NB中的operationModeInfo字段指示为guardband或者standalone模式后，在UE进一步解码SIB1-NB前，UE默认NRS在子帧0,1,3,4和9（不包含NSSS）上进行传输。如果解码SIB1-NB后，UE默认NRS在每个不含NPSS或者NSSS的NB-IoT下行子帧进行传输。当UE解码MIB-NB中的operationModeInfo字段指示为inband-SamePCI 或者inband-DifferentPCI模式后，在UE解码SIB1-NB之前，UE默认NRS在子帧0,4,9（不包含NSSS）上进行传输。当UE解码SIB1-NB之后，UE默认在每个不含NPSS或者NSSS的NB-IoT的下行子帧进行传输。 单天线端口NRS位置vs双天线端口NRS位置（注：NB-IoT最多只支持下行双天线端口传输） 主同步信号NPSS（Narrowband primary synchronization signal） NB-IoT的主同步信号仅作为小区下行同步使用。在NB-IoT中主同步信号传输的子帧是固定的，同时对应的天线端口号也是固定的，这也意味着在其他子帧传输的主同步信号的端口号并不一致。 蓝色部分为CRS的位置，黄色部分为NPSS位置 值得注意的是，传输NPSS的5号子帧上没有NRS窄带参考信号，另外如果在带内组网模式下与CRS小区参考信号重叠，重叠部分不计作NPSS，但是仍然作为NPSS符号的一个占位匹配项（详见36.211. R13 10.2.7.1.2） 辅同步信号NSSS（Narrowband secondary synchronization signal） 与NPSS位置部署原则大体一致，NSSS部署在偶数无线帧的9号子帧上，从第4个OFDM符号开始，占满12个子载波。该9号子帧上没有NRS窄带参考信号，另外如果在带内组网模式下与CRS小区参考信号重叠，重叠部分不计作NSSS，但是仍然作为NSSS符号的一个占位匹配项。 与LTE大网中PCI需要通过PSS和SSS联合确定不同，窄带物联网的物理层小区ID仅仅需要通过NSSS确定（依然是504个唯一标识），这意味着NSSS的编码序列有504组。 蓝色部分为CRS的位置，黄色部分为NSSS位置 通过UE角度看，NB-IoT下行是半双工传输模式，子载波带宽间隔是固定的15kHz,每一个NB-IoT载波只有一个资源块（resource block）。下行窄带参考信号被布置在每个时隙的最后两个OFDM符号中，每个下行窄带参考信号都对应一个天线端口，NB-IoT天线端口是1个或者2个。物理层同样被分配了504个小区ID，UE需要确认NB-IoT的小区ID与LTE大网PCI是否一致，如果二者一致，那么对于同频的小区，UE可以通过使用相同天线端口数的LTE大网小区的CRS（小区级参考信号）来进行解调或者测量。UE除了根据NSSS(Narrowband Secondary Synchronization Signal)确定小区物理ID之外，还需要像LTE大网小区驻留流程一样，根据这两个同步信号进行下行同步，NPSS的位置位于每个无线帧的第6子帧的前11个子载波，NSSS的位置位于每个无线帧的第10子帧上的全部12个子载波。 NB-IoT的下行物理信道与LTE大网的物理信道区别不大 NPBCH（Narrowband physical broadcast channel）以64个无线帧为循环，在mod64=0的无线帧上的0号子帧进行传输，同样的内容在接下来连续的7个无线帧中的0号子帧进行重复传输，NPBCH不可占用0号子帧的前三个OFDM符号，避免与LTE大网的CRS以及物理控制信道的碰撞。根据3GPP 36.211 R13定义，一个小区的NPBCH需要传输1600比特，采取QPSK调制，映射成800个调制符号，而每8个无线帧重复传输，64个无线帧将这800个调制符号传完，意味着每8个无线帧重复传输100个调制符号，那么在这8个无线帧的每个0号子帧中需要传输这100个调制符号。这里进行一个简单的计算，一个NB-IoT子帧包含12*7*2=168个RE，扣掉前三个OFDM符号，再扣掉NRS占用的RE，再扣掉CRS占用的RE（假设为双端口发射），那么一共168-12*3-4*4-4*2=100个RE，恰好对应100个QPSK调制符号，因此每个无线帧上的0号子帧恰好装满了NPBCH的符号。 蓝色部分为CRS的位置，斜线部分为NRS的位置，黄色部分为NPBCH位置 NPDCCH(Narrowband physical downlink control channel)，相比LTE下行较多的物理控制信道，NB-IoT只有NPDCCH信道传递控制信息。窄带物理控制信道通过连续的一个或者聚合两个NCCE（Narrowband control channel element）的方式进行传输。一个NCCE占据6个连续的子载波，其中NCCE0占据0~5子载波，NCCE1占据6~11子载波。每个NPDCCH是以R个连续的NB-IoT下行子载波进行重复传输的。NPDCCH有三种。第一种是Type1-NPDCCH公共搜索空间，UE通过检测该搜索空间获取寻呼消息。第二种是Type2-NPDCCH公共搜索空间，UE通过检测该搜索空间获取随机接入响应消息（RAR）。第三种是UE专用NPDCCH搜索空间，UE通过检测专属空间获取专属控制信息。 我们先计算一下NPDCCH的起始子帧位置，如果是Type1-NPDCCH公共搜寻空间模式，以k0为起始位置，这也是寻呼的起始位置。 这里有必要多说一下寻呼，寻呼消息是在寻呼帧（Paging Frame,PF）的寻呼子帧（Paging Occasion,PO）上发出的，因此UE需要周期性的监听这些位置。如果defaultPagingCycle=rf256,nB=twoT,SFN mod T= (T divN)*(UE_ID mod N),i_s = floor(UE_ID/N)mod Ns,UE_ID=IMSI mod 4096(LTE UE_ID=IMSI mod 1024), 例如IMSI为460003313889448经过计算UE_ID为168，那么PF为mod256=168的无线帧，PO为0号子帧，那么UE就需要侦听无线帧为168，子帧0上是否有P-RNTI，并且以256无线帧为周期循环侦听P-RNTI。 UE还需侦听连续的R-1个子载波获得可靠的重复发送NPDCCH，R是根据Rmax和DCI子帧连续数共同决定。UE如果没有把连续的Rmax通过获取小区系统消息块SystemInformationBlockType2-NB中的控制信息radioResourceConfigCommon中的参数npdcch-NumRepetitionPaging获取，该参数取值范围 { r1, r2, r4, r8, r16, r32, r64,r128,r256,r512, r1024, r2048} 假设Rmax取值64，DCI子帧重复数取值为3，查表（36.213 R13 表16.6-2）可知对应R取值为8，那么根据以上寻呼起始位置的计算，意味着UE需要周期侦听无线帧168+256n(n=0,1,2,3....)，子帧0，同时连续重复8个子帧获取NPDCCH中的寻呼消息。值得一提的是，这里DCI子帧连续数并不是高层消息告知UE的，在这里UE采取盲检机制逐步尝试检测所有的DCI模式。如果没有检测到连续的控制信息，UE会将已检测到的NPDCCH丢弃。从这点来看，NB-IoT对于控制信道的解码可靠性还是极为看重的，要么不收，要么收全。 当然，在网络侧实际配置NPDCCH时需要与NPBCH的时隙错开，因此UE会尝试在非子帧0的其他子帧开始尝试检测NPDCCH。NB-IoT也可以采取多载波的方式进行数据传输，网络侧需要将NPSS,NSSS,NPBCH与UE专属NPDCCH分别配置在不同的载波。NPDCCH在子帧中的起始位置lNPDCCHStart取决于SIB1-NB里的eutraControlRegionSize参数设置，对于Type2-NPDCCH和UE专属NPDCCH的起始位置确定方式与Type1有所不同，具体细节可参考36.213 R13 16.6。 NPDSCH(Narrowband physical downlink shared channel) NB-IoT对于NPDSCH的传输稳定性极为关注，通过重复传递同一NPDSCH的方式确保传输的质量，这也是NB-IoT宣称的强化覆盖技术手段之一。NPDSCH可以承载BCCH，例如承载系统消息，也可以承载一般的用户数据传输。对应这两种承载，传输信号加扰的方式有所不同。同时，子帧重复传输的模式也有所不同。 承载NPDSCH的子帧以及占位有一定规则，NPDSCH的子帧不可以与NPBCH，NPSS或者NSSS的子帧复用。另外，承载子帧中NRS和CRS的位置既不作为NPDSCH，也不作为符号匹配。 在收到传输NPDCCH以及DCI的最后一个子帧n后，UE尝试在n+5子帧为其实之后的N个连续下行子帧（不含承载系统消息的子帧）进行对应NPDSCH的解码。这N个连续下行子帧的取决于两个因素，也就是N=Nrep*NSF,一个是Nrep,意味着每一个NPDSCH子帧总共重复传输的次数，NSF意味着待传数据需要占用的子帧数量，这两个因素都是根据对应的DCI解码得出的，在协议中可以查表得出对应关系（36.213 R13 16.4.1.3）。根据不同的DCI（N1，N2）格式，需要注意的是在UE预期的n+5子帧以及实际传输NPDSCH的起始子帧之间存在调度延迟，如果是N2格式，该调度延迟为0。如果是N1格式，可以根据DCI的延迟指示Idelay和NPDCCH的最大重传Rmax依据协议规定（36.213 R13 表16.4.1-1）共同确定调度延迟。协议规定，UE在NPUSCH上传数据之后的三个下行子帧之内不认为网络会传输NPDSCH数据，另外一种在物理层体现延迟传输NPDSCH的技术是设置GAP，GAP的长度由系统消息中的公共资源配置参数决定的，这也为多用户的数据错峰传输预留了空间。 NPDSCH承载系统消息和承载非系统消息数据的物理层流程以及帧结构有所不同。承载非系统消息数据的NPDSCH每个子帧先重复发送，直到N=Nrep*NSF个子帧都传输完。而承载系统消息的NPDSCH先以NSF个子帧传输完，在循环重复，直到N=Nrep*NSF个子帧都传输完。这两种传输方式占用资源的方式相似，之所以在重复传输机制上有所差异，可能主要还是考虑UE对于系统消息响应的及时程度。对于承载非系统消息数据的NPDSCH是通过对应NPDCCH加扰的P-RNTI,临时C-RNTI或者C-RNTI进行解码的，同时NPDSCH持续占用的子帧情况也是通过解码DCI予以明确的。而与之不同的是，承载系统消息的NPDSCH起始无线帧以及重复传输占用子帧情况是通过解码小区ID和MIB-NB消息中的 schedulingInfoSIB1参数获得的，当然这样承载系统消息的NPDSCH是通过SI-RNTI进行符号加扰的。SIB1-NB是在子帧4进行传输的。对于在子帧内具体的起始位置则取决于组网方式，如果NPDSCH承载SIB1-NB并且是带内组网模式，则从第4个OFDM符号开始（避开前三个OFDM符号），其他组网模式从第一个OFDM符号（0号OFDM符号）。如果NPDSCH承载其他信息，说明此时已经正确解码了SIB1-NB，那么通过解读SIB1-NB中的eutraControlRegionSize参数（这是可选参数）来获取起始位置，如果该参数没有出现，那么从0号OFDM符号开始传输。 除了承载系统消息以及非系统消息（一般用户数据，寻呼信令等），NPDSCH还承载对上行信道NPUSCH的ACK/NACK消息，UE在NPUSCH传完子帧之后的第4个子帧进行侦听。 通过对于整个NB-IoT下行物理层结构以及流程的了解，NB-IoT利用了延迟以及重传帧结构设计保障了数据传输的稳定性以及可靠性，提升了“软性”的覆盖， 同时也考量了与LTE大网的兼容共存，这可能是由于NB-IoT业务定位导向（设计NB-IoT的初衷据说就是为了查水表）进行调整设计的，这也再次指明了技术标准的一个发展方向，即不以技术本身的指标为考量，反而更多的以契合应用需求为准绳。 结束这篇文章的同时，也抛出给小问题给有兴趣的读者思考，既然组网模式有三种，那么在保护带模式，独立组网模式下，为什么NPBCH还要空出前三个OFDM符号呢？ |
|
|
