EMBMS空口协议介绍.docx

讨论范围1、 本文只讨论空口部分协议；2、 协议中有single cell的MBMS，以及multi cell协作的MBMSFN，第二种要求空口同频且帧同步，本文只讨论第二种情况。第二种情况的cell可以是混合小区（MBMS业务和单播业务同时存在），也在本文讨论范围。3、 UE的MBMS业务建立与删除流程不在本文讨论范围。基本概念信道MBMS在MAC层和物理层都用专门对应的信道传输信令与业务（数据）。MAC层的MCCH和MTCH分别用来传输多播信令与多播业务。物理层的“传输信道”中MCH与“物理信道”PMCH也专门用来MBMS传输，其中MAC层的MCCH与MTCH都对应到物理层的(P)MCH信道上。另外MAC层的BCCH（SIB13）用来广播MCCH的配置，MAC层的SIB2也用来定义MCH信道物理层信道风格。下图是物理层传输信道与物理信道的映射图。对于多播，MCH和PMCH可以认为没有区别，长用(P)MCH表示：下图是MAC层的信道与物理层传输信道的映射，可见MCCH和MTCH都映射到(P)MCH上。信道关系MAC层的MCCH用来传输多播相关的信令，包括PMCH配置，下行计数消息。MAC层的MTCH用来传输多播业务数据。MAC层的BCCH中SIB2用来规定PMCH的子帧风格，SIB13用来配置MCCH对应的(P)MCH。每个MTCH对应一个(P)MCH，和一个多播业务相对应，也和一个多播session相对应。每个多播域（MBMS Area）都和一个MCCH唯一对应，每个MCCH又和多个MTCH向对应。也就是说同一个Area的所有MTCH公用一个MCCH。而MCCH可以认为除了下面MTCH对应的PMCH以为，还有自己MCCH对应的一个PMCH。名词解释MBSFN Synchronization AreaMBMSFN就是MBMS单频网络。意思是所有网络频率相同，且是帧对齐的，PMCH子帧分配风格也是一样的，同一时间发送的多播数据也是一样的。UE可以同一时间接收多个MBMSFN Cell发送的数据，因为数据在物理层就是完全相同的。同一个频点下发送相同数据的所有小区，叫做MBSFN Synchronization Area。显然，一个小区只可能属于一个MBSFN Synchronization Area。MBMSFN Area每个MBSFN Synchronization Area下可以有多个MBMSFN Area，每个MBMSFN Area可以认为是一组子帧分配方式相同的小区集合（同一Area的PMCH占用的symbol也相同），同一Area有相同的MCCH。也就是是说，UE在同一个Area的小区中移动，不需要重新获取MCCH信息就能直接接收不同小区的数据。那么和MBSFN Synchronization Area有什么区别呢？Synchronization Area可能有多个Area，但每个Area用不同MCCH且用不同MTCH。在同一个Synchronization Area中每个小区发生的东西不会冲突，但可能有的小区发送多播业务1，有的小区发生多播业务2，且多播业务1和多播业务2对应于不同MCCH。相同的Area，所有小区发送的多播业务与MCCH对应关系是一样的，业务发生的时间与频域位置也是一样的。一个小区可以有多个 MBSFN Area。CSA每个MCCH（每个Area）有多个CSA风格（Common Subframe Allocation (CSA) Pattern）。每个CSA分隔的配置在相邻小区中都相同，这样UE可以方便的同时接收多个小区的MBMS资源并且移动时不需要再收PMCH配置等信息。多个CSA以一定周期重复（commonSF-AllocPeriod）重复。每个MCCH下的所有CSA的子帧统一编号。MSI与MSP多播业务调度有两种方式，一种是静态调度一种是动态调度。而MSI与MSP用于静态调度，在Area配置时就固定好了，指定了每个PMCH的调度的周期与子帧。每个MCH有固定的调度周期MCH scheduling period (MSP)，通过MCH scheduling information (MSI)通过MBSFNAreaConfiguration消息告知UE。DSIdynamic scheduling information（intreval）。动态调度信息。如果有该信息，则覆盖静态调度信息MSI。该信息与其他配置不同，是通过MAC层配置，而其他所有配置都是通过RRC消息配置的。该信息只在每个PMCH的最开始的第一个子帧发送。该方案是诺西提出，但爱立信反对，最后还是通过了。TMGI与sessionIdTGMI：Temporary Mobile Group Identity。标识了一个多播服务，由两个域组成：PLMN ID和service ID（24.008, 3byte）。可见LTE中的多播是按照运营商区分的。每个service ID（29.061，Sections 20.5, 17.7.11, 17.7.15）可能有多个session？ 一个TGMI+service ID可以标识一个正在使用的多播业务。logicalChannelIdentityMAC层的LCID，只在RNTI为M-RNTI时才有效。也就是说多播的LCID可能和单播的LCID值相同。USD与SAI UDS:user service description. 对于每个USD，应用层定义了一个TMGI与session，一个频点以及SAI。SAI: MBMS Service Area Identities（15.3 of TS 23.003）。该值在SIB15中广播，同时UE应用层保存了一份，知道自己当前的多播业务对应的SAI是多少。SIB15会广播邻区的SAI，如果UE发现邻区没有自己需要的SAI，当在IDLE时小区重选时，可能会优先选取自己感兴趣多播业务对应的小区。当UE在连接状态时，切换时可能会让target cell事先建立起多播业务以便多播业务不中断。由于对于单频网络，相同频点上总是相同的多播业务，因此SAI总和一个频点对应，一个频点上可以有多个SAI（最多64个）。SAI = PLMN-Id | LAC | SACLAC是位置域（LTE应该对应于TAC？）标识，SAC是The Service Area Code，见TS26.246.各个逻辑实体关系上图需要说明的时，图中PMCH和CSA的关系是多对多。最开始协议制定时是没有CSA的，而是类似的另外一个概念MSAP，与PMCH的关系是：一个MSAP对应多个PMCH（也就是一个MSAP对应多个多播业务，一个多播业务只能在一个MSAP而不能跨越MSAP）。不过一般的配置，PMCH都在CSA内不会跨越CSA。基本主流程主要流程是能让UE接收MBMS数据，eNB需要事先把各个多播业务对应的PMCH资源告知UE。UE就知道相应的多播业务在指定的时频资源接收多播数据了。大致流程如下：1、 SIB13广播所有MBMSFN Area的MCCH配置，以及修改Area修改参数的配置。可能有多个Area配置。该消息获取后，就知道每个MCCH的发送时频位置。2、 每个MCCH中MBSFNAreaConfiguration消息发送该Area的CSA配置和PMCH配置（每个MTCH对应的PMCH）。其中CSA配置也可以在SIB2中下发，SIB2中的配置不能和MCCH中配置冲突。有了CSA配置和PMCH配置，同时也就知道了PMCH和CSA的对应关系，知道了每个PMCH的静态发送时机以及对应的多播业务，UE就可以接收自己想接收的多播数据了。配置MCCH配置SIB13针对每个MBMSFN Area配置了一个MCCH，指明了该MCCH对应的PMCH在物理层上发送的时机，MCS，修改周期。同时指明了该Area内所有PMCH（MCCH和MTCH对应的所有PMCH）子帧用到的symbol。有了MCCH配置后，就能接收MBSFNAreaConfiguration消息或者DSI了。CSA与PMCH配置在MCCH，收MBSFNAreaConfiguration消息，则得到CSA配置与PMCH配置，以及两者的对应关系。协议首先定义了该Area内CSA的配置，然后定义了该Area内CSA的公共周期。其中CSA配置会指明帧号与子帧号，分配周期与帧号偏移。再加上SIB13中的symbol配置，就知道每个CSA对应的PMCH的所有时频资源。但是CSA指出的PMCH时频资源可能是给多个PMCH用的，也可能一个PMCH用到了多个CSA指出的时频资源。结合CSA的公共周期，然后把该周期内所有的子帧统一编号，以便PMCH配置用。PMCH配置（只指MTCH对应的PMCH，不包括MCCH对应的PMCH）指明了每个PMCH对应的多播业务，使用的LCID，以及使用的时频资源与MCS。PMCH的时域资源是通过相对子帧号指示的，而相对子帧号就是前面描述的CSA公共周期内的子帧统一编号。下面先看总的Area配置，包含三个参数：第一项commonSF-Alloc-r9是CSA列表，第二项是所有CSA的公共周期，第三项是PMCH列表配置。其中PMCH配置需要和前两项结合才能确定每个PMCH信息。- ASN1STARTMBSFNAreaConfiguration-r9 :=SEQUENCE commonSF-Alloc-r9CommonSF-AllocPatternList-r9,commonSF-AllocPeriod-r9ENUMERATED rf4, rf8, rf16, rf32, rf64, rf128, rf256,pmch-InfoList-r9PMCH-InfoList-r9,nonCriticalExtensionMBSFNAreaConfiguration-v930-IEsOPTIONALMBSFNAreaConfiguration-v930-IEs := SEQUENCE lateNonCriticalExtensionOCTET STRINGOPTIONAL,- Need OPnonCriticalExtensionSEQUENCE OPTIONAL- Need OPCommonSF-AllocPatternList-r9 :=SEQUENCE (SIZE (1.maxMBSFN-Allocations) OF MBSFN-SubframeConfig- ASN1STOPMBSFNAreaConfiguration field descriptionscommonSF-AllocMBSFNArea可能有多组MBSFN-Allocations(即对应一个CSA)，每组的第一个资源分配即commonSF-Alloc。commonSF-AllocPeriod所有CSA的重复周期。该参数肯定大于每个CSA内的radioframeAllocationPeriod。Indicates the period during which resources corresponding with field commonSF-Alloc are divided between the (P)MCH that are configured for this MBSFN area. The subframe allocation patterns, as defined by commonSF-Alloc, repeat continously during this period. Value rf4 corresponds to 4 radio frames, rf8 corresponds to 8 radio frames and so on. The commonSF-AllocPeriod starts in the radio frames for which: SFN mod commonSF-AllocPeriod = 0.CSA配置每个CSA其实就是一个子帧风格配置，规定了每个CSA帧的周期，偏移，以及包含哪些子帧。MBSFN-SubframeConfig information element- ASN1STARTMBSFN-SubframeConfig :=SEQUENCE radioframeAllocationPeriodENUMERATED n1, n2, n4, n8, n16, n32,radioframeAllocationOffsetINTEGER (0.7),subframeAllocationCHOICE oneFrameBIT STRING (SIZE(6),fourFramesBIT STRING (SIZE(24)- ASN1STOPMBSFN-SubframeConfig field descriptionsfourFrames子帧以4帧为一个分配周期A bit-map indicating MBSFN subframe allocation in four consecutive radio frames, “1” denotes that the corresponding subframe is allocated for MBSFN. The bitmap is interpreted as follows:FDD: Starting from the first radioframe and from the first/leftmost bit in the bitmap, the allocation applies to subframes #1, #2, #3 , #6, #7, and #8 in the sequence of the four radio-frames.TDD: Starting from the first radioframe and from the first/leftmost bit in the bitmap, the allocation applies to subframes #3, #4, #7, #8, and #9 in the sequence of the four radio-frames. The last four bits are not used. Uplink subframes are not allocated.oneFrame子帧以1帧为一个分配周期“1” denotes that the corresponding subframe is allocated for MBSFN. The following mapping applies:FDD: The first/leftmost bit defines the MBSFN allocation for subframe #1, the second bit for #2, third bit for #3 , fourth bit for #6, fifth bit for #7, sixth bit for #8.TDD: The first/leftmost bit defines the allocation for subframe #3, the second bit for #4, third bit for #7, fourth bit for #8, fifth bit for #9. Uplink subframes are not allocated. The last bit is not used.radioFrameAllocationPeriod, radioFrameAllocationOffsetRadio-frames that contain MBSFN subframes occur when equation SFN mod radioFrameAllocationPeriod = radioFrameAllocationOffset is satisfied. Value n1 for radioframeAllocationPeriod denotes value 1, n2 denotes value 2, and so on. When fourFrames is used for subframeAllocation, the equation defines the first radio frame referred to in the description below. Values n1 and n2 are not applicable when fourFrames is used.subframeAllocationDefines the subframes that are allocated for MBSFN within the radio frame allocation period defined by the radioFrameAllocationPeriod and the radioFrameAllocationOffset.PMCH配置每个MBSFNAreaConfiguration消息中配置了一组PMCH， 每个PMCH即对应一个多播业务，对应一个MTCH。每个PMCH配置了调度周期,MCS,子帧号（需要和前面的CSA配置结合）。其中调度周期、MCS与子帧号构成了MSI。PMCH-InfoList information element- ASN1STARTPMCH-InfoList-r9 :=SEQUENCE (SIZE (0.maxPMCH-PerMBSFN) OF PMCH-Info-r9PMCH-Info-r9 :=SEQUENCE pmch-Config-r9PMCH-Config-r9,mbms-SessionInfoList-r9MBMS-SessionInfoList-r9,.MBMS-SessionInfoList-r9 :=SEQUENCE (SIZE (0.maxSessionPerPMCH) OF MBMS-SessionInfo-r9MBMS-SessionInfo-r9 :=SEQUENCE tmgi-r9TMGI-r9,sessionId-r9OCTET STRING (SIZE (1) OPTIONAL, - Need ORlogicalChannelIdentity-r9INTEGER (0.maxSessionPerPMCH-1),.PMCH-Config-r9 :=SEQUENCE sf-AllocEnd-r9INTEGER (0.1535),dataMCS-r9INTEGER (0.28),mch-SchedulingPeriod-r9ENUMERATED rf8, rf16, rf32, rf64, rf128, rf256, rf512, rf1024,.TMGI-r9 :=SEQUENCE plmn-Id-r9CHOICE plmn-Index-r9INTEGER (1.6),explicitValue-r9PLMN-Identity,serviceId-r9OCTET STRING (SIZE (3)- ASN1STOPPMCH-InfoList field descriptionsdataMCSMTCH对应PMCH的MCS。Indicates the value for parameter in TS 36.213 23, Table 7.1.7.1-1, which defines the Modulation and Coding Scheme (MCS) applicable for the subframes of this (P)MCH as indicated by the field commonSF-Alloc. The MCS does however neither apply to the subframes that may carry MCCH i.e. the subframes indicated by the field sf-AllocInfo within SystemInformationBlockType13 nor for the first subframe allocated to this (P)MCH within each MCH scheduling period (which may contain the MCH scheduling information provided by MAC). mch-SchedulingPeriod每个PMCH调度周期每个CSA的周期（radioframeAllocationPeriod）PMCH的调度周期也可以大于公共周期（commonSF-AllocPeriod-r9）。所有CSA的公共周期肯定=每个CSA的周期因此可能有的帧有PMCH的一些子帧空着没有人用。Indicates the MCH scheduling period i.e. the periodicity used for providing MCH scheduling information at lower layers (MAC) applicable for an MCH. Value rf8 corresponds to 8 radio frames, rf16 corresponds to 16 radio frames and so on. The mch-SchedulingPeriod starts in the radio frames for which: SFN mod mch-SchedulingPeriod = 0.plmn-IndexIndex of the entry in field plmn-IdentityList within SystemInformationBlockType1.sessionIdIndicates the optional MBMS Session Identity, which together with TMGI identifies a transmission or a possible retransmission of a specific MBMS session: see TS 29.061 51, Sections 20.5, 17.7.11, 17.7.15. The field is included whenever upper layers have assigned a session identity i.e. one is available for the MBMS session in E-UTRAN.serviceIdUniquely identifies the identity of an MBMS service within a PLMN. The field contains octet 3- 5 of the IE Temporary Mobile Group Identity (TMGI) as defined in TS 24.008 49. The first octet contains the third octet of the TMGI, the second octet contains the fourth octet of the TMGI and so on.sf-AllocEnd该值十分重要，用于指明每个PMCH在的子帧，字面意思是每个PMCH的结束子帧。那么每个PMCH的子帧从哪里开始呢？首先把公共周期内的所有CSA的子帧统一编号，然后确定每个PMCH的子帧。比如对于第2个PMCH，则从第1个PMCH的sf-AllocEnd的下一个子帧开始（子帧编号是从commonSF中所有子帧统一编号的），到第2个PMCH的配置sf-AllocEnd为止。对于第1个PMCH，如果只有1个PMCH，则从0开始，否则从最后一个PMCH的下一个子帧开始（应该是这么理解吗？在提案中没有找到出处，只能从解释来推）。Indicates the last subframe allocated to this (P)MCH within a period identified by field commonSF-AllocPeriod. The subframes allocated to (P)MCH corresponding with the nth entry in pmch-InfoList are the subsequent subframes starting from either the next subframe after the subframe identified by sf-AllocEnd of the (n-1)th listed (P)MCH or, for n=1, the first subframe defined by field commonSF-Alloc, through the subframe identified by sf-AllocEnd of the nth listed (P)MCH. Value 0 corresponds with the first subframe defined by field commonSF-Alloc. 例子上图中有3个CSA，周期(radioframeAllocationPeriod)都为4，公共周期(commonSF-AllocPeriod-r9)则为4。其中第0个CSA的偏移（radioframeAllocationOffset）为0，第1个为2，第2个为3。图中绿色部分为CSA的子帧号。有了3个CSA配置(MBSFN-SubframeConfig)与公共周期commonSF-AllocPeriod-r9，则可以对所有子帧号同意编号，即第二行。最后是PMCH配置，各个PMCH的sf-AllocEnd分别为0,11,14,16,18，则入上图所示。其中第0个PMCH的起始帧从最后一个PMCH配置的sf-AllocEnd+1得到。可见，PMCH的子帧可以跨越CSA，比如PMCH3和PMCH0。动态调度（DSI）虽然在PMCH配置时有半静态的调度信息，但在可以动态调整。在每个(P)MCH的第一个子帧（PMCH第一个子帧由半静态配置得到或者前一个DSI得到）。如果该MCH的第一个子帧包含MCH Scheduling Information MAC control element，则开始以DSI的信息替换半静态定义的子帧接收多播业务。注意，DSI只有用于一个公共周期，下个公共周期开始无效，要不有新的DSI，如果没有新DSI则用静态配置。格式如下：每个LCID代表一个多播业务（MTCH对应的PMCH），stop MTCH代表该PMCH结束的子帧号，如果为2047则表明没有该PMCH。多播数据接收在MSI或者DSI指定的时间内，用M-RNTI收到多播TB，MAC层用M-RNTI对应的LCID确定那些多播业务。其它流程配置修改SIB13中还配置了有关一个修改周期参数，然后每个MBMSFN Area也有个修改周期与“修改编号”。如果MCCH需要修改，只能在指定的修改周期修改，然后通过PDCCH 1C下发修改的Area bitmap，bitmap对应的值即每个Area配置中的“修改编号”索引。其中修改周期由每个Area的最小修改周期/通知系数得到。如上图所示，先在第一个修改周期发送PDCCH通知哪些Area改变了，然后在下一个修改周期SIB13中用新的MCCH配置。如果UE在PDCCH中发现自己关心的Area没有改变，则在下一个修改周期没必要接收SIB13中的MCCH配置。Counting基站用来确认当前基站下有哪些UE使用了哪些PMCH。该流程只能针对connected 状态UE，不知道有什么用。基站即使知道了有些PMCH没人用，也不能取消，因为还有IDLE的UE可能在使用。MBMS interest indicationSIB15中广播了本小区与邻区的SAI，UE得知后知道自己感兴趣的多播业务在哪些邻区上存在，如果是IDLE状态则可以优先确定重选的小区，如果在连接态则可以告知当前serving cell自己有哪些感兴趣的SAI，以便HO时让网络做切换判决用。