CN102056084B - 多媒体广播组播业务系统及其同步方法 - Google Patents
多媒体广播组播业务系统及其同步方法 Download PDFInfo
- Publication number
- CN102056084B CN102056084B CN200910212090.XA CN200910212090A CN102056084B CN 102056084 B CN102056084 B CN 102056084B CN 200910212090 A CN200910212090 A CN 200910212090A CN 102056084 B CN102056084 B CN 102056084B
- Authority
- CN
- China
- Prior art keywords
- service
- network element
- type0
- sync frame
- end information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 51
- 230000001360 synchronised effect Effects 0.000 title claims abstract description 44
- 230000008569 process Effects 0.000 abstract description 7
- 101100368149 Mus musculus Sync gene Proteins 0.000 description 26
- 238000010586 diagram Methods 0.000 description 17
- 230000005540 biological transmission Effects 0.000 description 15
- 230000006835 compression Effects 0.000 description 6
- 238000007906 compression Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 230000003111 delayed effect Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 125000004122 cyclic group Chemical group 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 238000013468 resource allocation Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种多媒体广播组播业务系统的同步方法包括:当业务结束时,上层网元在用户面发送业务结束信息;下层网元根据接收到的业务结束信息,获知业务结束,并进行相应地处理。本发明还公开了一种多媒体广播组播业务系统。本发明能够使得下层网元及时获知某一业务具体的结束时间,从而判定数据是丢失了还是已经结束,能够准确地对资源进行调度;能够使得不同下层网元对同一业务的资源分配保持一致,对同一情况采取一致的处理,从而使用户终端能够正常地接收业务数据。
Description
技术领域
本发明涉及通信领域,具体而言,涉及一种多媒体广播组播业务系统及其同步方法。
背景技术
为了有效地利用移动网络资源,3GPP(3rdGenerationPartnershipProject,第三代合作伙伴计划)提出了多媒体广播多播业务(MultimediaBroadcastMulticastService,MBMS),该MBMS业务是一种从一个数据源向多个目标传送数据的技术,实现了网络(包括核心网和接入网)资源的共享,提高了网络资源(尤其是空中接口资源)的利用率。
在现有的LTE(LongTermEvolution,长期演进)技术中,复用在同一个传输信道上的多个MBMS业务可以采用如下的方式动态地共享信道的资源,这种方式称为动态复用(dynamicmultiplexing)。下面对动态复用方式进行详细说明。
在LTEMBMS中,首先定义了调度周期的概念。一个调度周期在时域上定义为一个时间段长度,例如320或640ms,在该时间段内,一条传输信道占用分配若干MBSFN子帧(subframe)资源。在一个调度周期内,一个MBMS逻辑信道的数据连续占用其映射的传输信道的资源,也就是连续地占用MCH信道的MBSFN子帧资源,直到该业务在该调度周期内需要发送的业务数据全部发送完毕。不同业务的数据可以在同一个MBSFN子帧内发送。也就是来自不同的逻辑信道的数据通过媒体接入控制(MAC)层串接在同一个MACPDU(媒体接入控制层协议数据单元)中发送。
一个动态复用的例子如图1所示,多个业务在一个调度周期内动态复用信道资源,在一个调度周期内复用有业务S1和业务S2的数据。
为实现MBMS业务在多个网元实体(基站网元)的小区间实现同步的发送,现有公开技术提供了一种同步协议(SYNC)的处理方式,该方法对应的网络系统包括上层网元和下层网元(1~N),如图2所示。该SYNC协议的同步发送过程包括以下处理步骤:
步骤S1,上层网元发送MBMS业务数据包到各下层网元(1~N),该业务数据包承载了业务数据(payload),并携带时间戳信息、数据包序列号信息、累计业务数据长度信息等。其中:
上层网元对一个或多个连续业务数据包中标识相同的时间戳信息,这些标记了相同时间戳的数据包组成一个数据突发(databurst)或者称为同步序列(synchronizationSequence);相邻两个同步序列的时间戳差为同步序列长度;
上述的业务数据包在SYNC协议中又称为SYNC数据帧(dataframe)。所述的业务数据是真实的业务数据,将要在无线接口发送的数据部分。所述的数据包序列号是指在一个同步序列内,或从某个约定的起点开始数据帧的序列号。所述累计业务数据包长度信息是指一个同步序列内,或从某个约定的起点开始,到所述业务数据包之前的业务数据累计长度。该数据包长度可以是数据帧的长度,也可以是数据帧携带的业务数据的长度。这二者是等价的,因为数据帧的长度减去数据帧的帧头的长度就等于业务数据的长度。而数据帧的帧头长度可以根据协议定义获知。
在每个同步序列的最后,上层网元还发送一种SYNC控制帧,该控制帧携带信息指示其对应的同步序列的数据帧的总个数、业务数据总长度信息。图3示出了上层网元向下层网元发送的同步序列数据帧和控制帧的一个例子。
步骤S2,下层网元接收到上层网元所发送的上述同步序列,并通过检测业务数据包的序列号,检测是否存在业务数据包的丢失,以及已经丢失的业务数据包的总长度。其中:
下层网元通过检测接收到的一个同步序列的数据包的序列号,可以检测出是否存在业务数据包的丢失,例如下层网元接收到了同步序列X的业务数据包的序列号为N-1,N,N+3,N+4...,则下层网元可以检测出数据包N+1,N+2丢失。下层网元进一步通过检测序列号为N和N+3的数据包携带的累计数据长度的差,可以知道所丢失的业务数据N+1,N+2的业务数据长度的和。例如数据包N携带的累积数据长度为L1,N+3携带的累积数据长度为L2,则数据包N+1和N+2携带的业务数据的总长度为L2-L1-数据包N1的数据长度。下层网元还可以通过读取上述的SYNC控制帧,获取其对应的同步序列的数据包总个数和业务数据总长度。该控制帧也是一个同步序列结束的标记。
步骤S3,每个下层网元对同一个同步序列中的业务数据包所携带的业务数据在其时间戳对应的调度周期开始在无线接口依次发送业务数据包。
在上述的描述中,上层网元和下层网元可以是下列网元的组合方式,但是不限于下列的组合:
①在UMTS(UniversalMobileTelecommunicationsSystem,通用移动通信系统)系统的MBMS业务同步组网中,上层网元为核心网网元,下层网元为RNC(无线网络控制器)。
②在LTE系统的MBMS业务同步组网中,上层网元为BMSC(广播多播业务中心)或其它核心网网元,下层网元为节点B(E-NB,E-UTRANNodeB)。
图2示出了上层网元-下层网元的逻辑结构图。其中下层网元间的接口为逻辑接口或者物理接口。
在上述MBMS业务复用和同步方法中,考虑到数据从上层网元传输到下层网元的过程中,存在丢失的可能性,并且可能出现连续的数据包丢失,根据现有同步协议SYNC的技术,下层网元可以检测到丢失的数据包的个数和丢失的数据包的总长度,并根据这些信息构造虚拟的丢失数据包,并将这些虚拟的数据包进行用户面协议层处理,就像这些数据包没有丢失一样。但是上述的方法存在一个严重的问题:即,考虑到RLC处理的特殊性,一个业务数据包,或称为RLCSDU(RLC业务数据单元),在进行RLC处理时,其占用的RLCPDU(RLC协议数据单元)的空间的大小取决于其具体的位置。具体的,一个RLCSDU在RLC处理中,其占用的RLC协议LI(长度指示)的个数是不确定的,取决于其在RLCPDU中的具体情况,其个数可以是0,或1,或2个。因而,具体处理时:
如果丢失的业务数据包个数为1个,则下层网元可以根据其长度计算得到确定的占用RLCPDU的空间;如果出现连续数据丢失,根据现有SYNC协议的技术,下层网元没有办法得到丢失的多个数据包的每一个数据包的长度,而只能获得这些丢失的业务数据包的总长度,因为造成这些丢失的数据包真实的占用RLCPDU的负荷空间的大小是没有办法正确计算的。
现有的解决丢包的方法,可以是通过发送多个TYPE0的SYNC帧,使得eNB能够更可靠地接收。也就是当某一段时间内没有数据的情况下,通过发送TYPE0的SYNC帧通知基站当前确实没有数据发送,而不是发送的数据丢失了。
不过,在数据发送的末尾,现有技术仍然还无法及时地指示用户面数据何时结束,即,用户的数据包什么时候结束。MBMS-GW(MBMS网关)在发送完最后的一个数据包之后将会拆掉相应的承载,并且发送该业务的MBMS会话结束消息给MCE,再由MCE转发给基站。但是,基站在接收到最后一个数据包之后就会再陷入一片“寂静”,没有收到任何响应的后续数据包。此时,控制面的MBMS会话结束消息可能不能及时地发送给基站,如基站延时收到,或者由于其他原因不能及时收到该消息。在这种情况下,由于基站不能从控制面得知具体的业务结束时间,而用户面已经没有数据发送,无法判知到底是数据丢失了,还是不发送数据了。由此而导致的问题是对于同时处理多个业务,并进行动态调度的基站来讲,基站无法对其他业务进行调度,到底是空闲一部分资源还是应该放掉相应的资源,处理上没有办法决定,导致基站的处理不一致。
针对相关技术中当下层网元延时收到或未收到控制面的MBMS会话结束消息时,下层网元无法准确调度资源,且不同下层网元之间的处理不一致的问题,目前尚未提出有效的解决方案。
发明内容
针对相关技术中当下层网元延时收到或未收到控制面的MBMS会话结束消息时,下层网元无法准确调度资源,且不同的下层网元之间的处理不一致的问题而提出本发明,为此,本发明的主要目的在于提供一种多媒体广播组播业务系统及其同步方法,以解决上述问题至少之一。
为了实现上述目的,根据本发明的一个方面,提供了一种多媒体广播组播业务系统的同步方法。
根据本发明的多媒体广播组播业务系统的同步方法包括:当业务结束时,上层网元在用户面发送业务结束信息;下层网元根据接收到的业务结束信息,获知业务结束,并进行相应地处理。
优选地,自定义的协议数据单元类型为TYPE3的同步(SYNC)帧携带业务结束信息,
上层网元在用户面发送业务结束信息采用以下方式之一:上层网元在业务的最后一个数据包所在的同步序列的末尾发送一个或多个TYPE3的SYNC帧;上层网元在业务的最后一个数据包所在的同步序列的下一个同步序列中发送一个或多个TYPE3的SYNC帧;上层网元在业务的最后一个数据包所在的同步序列的之后的一个或多个同步序列中发送一个或多个TYPE3的SYNC帧;
下层网元根据接收到的业务结束信息,获知业务结束,并进行相应地处理包括:下层网元接收到TYPE3的SYNC帧后,获知业务已结束;下层网元释放为业务分配的资源。
优选地,上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE0的SYNC帧中携带业务结束信息,
其中,业务结束信息占用TYPE0的SYNC帧中的空闲比特位中的一位或者多位,当占用空闲比特位中的一位且比特位的值为1时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的二位且比特位的值为11时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的三位且比特位的值为111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的四位且比特位的值为1111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息。
优选地,下层网元根据接收到的业务结束信息,获知业务结束,并进行相应地处理包括:下层网元接收到TYPE0的SYNC帧,且TYPE0的SYNC帧的空闲比特位中表示业务结束信息的比特位的值为1或11或111或1111时,下层网元获知接收到的TYPE0的SYNC帧所在的同步序列为业务的最后一个同步序列;下层网元释放为业务分配的资源。
优选地,业务结束信息占用TYPE0的SYNC帧中的补丁比特位中的一位或者多位,当占用补丁比特位中的一位且比特位的值为1时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用补丁比特位中的二位且比特位的值为11时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息。
优选地,上层网元在用户面发送业务结束信息的方式还包括:业务的最后一个数据包所在的同步序列中的所有TYPE0的SYNC帧格式均为采用携带有业务结束信息的TYPE0的SYNC帧格式,指示同步序列为业务的最后一个同步序列。
优选地,上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE1的SYNC帧中携带业务结束信息,
其中,业务结束信息占用TYPE1的SYNC帧中的空闲比特位中的一位或者多位;或者
业务结束信息占用TYPE1的SYNC帧中的空闲位扩展比特位中的一位或者多位;或者
业务结束信息占用TYPE1的SYNC帧中的补丁比特位中的一位或者多位。
优选地,上层网元在用户面发送业务结束信息的方式还包括:业务的最后一个数据包所在的同步序列中的所有TYPE1的SYNC帧格式均为采用携带有业务结束信息的TYPE1的SYNC帧格式,指示同步序列为业务的最后一个同步序列。
优选地,上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE2的SYNC帧中携带业务结束信息,
其中,业务结束信息占用TYPE2的SYNC帧中的空闲比特位中的一位或者多位;或者
业务结束信息占用TYPE2的SYNC帧中的补丁比特位中的一位或者多位;或者
业务结束信息占用TYPE2的SYNC帧中的空闲位扩展比特位中的一位或者多位。
优选地,上层网元在用户面发送业务结束信息的方式还包括:业务的最后一个数据包所在的同步序列中的所有TYPE2的SYNC帧格式均为采用携带有业务结束信息的TYPE2的SYNC帧格式,指示同步序列为业务的最后一个同步序列。
优选地,在当业务结束时,上层网元在用户面发送业务结束信息之后还包括:多媒体广播多播业务网关接收到业务结束信息后释放业务的承载。
为了实现上述目的,根据本发明的另一方面,提供了一种多媒体广播组播业务系统。
根据本发明的多媒体广播组播业务系统,包括:上层网元,用于当业务结束时,在用户面发送业务结束信息;下层网元,用于根据接收到的业务结束信息,获知业务结束,并进行相应地处理。
优选地,自定义的协议数据单元类型为TYPE3的SYNC帧携带业务结束信息,
上层网元还用于在业务的最后一个数据包所在的同步序列的末尾发送一个或多个TYPE3的SYNC帧;或者还用于在业务的最后一个数据包所在的同步序列的下一个同步序列中发送一个或多个TYPE3的SYNC帧;或者还用于在业务的最后一个数据包所在的同步序列的之后的一个或多个同步序列中发送一个或多个TYPE3的SYNC帧;
下层网元还用于接收到TYPE3的SYNC帧后,获知业务已结束;还用于释放为业务分配的资源。
由于定义了一个业务结束信息,当某一业务结束时,将该业务结束信息添加到用户面数据中一起发送给下层网元,指示下层网元该业务已经结束,该业务不会再有其他数据包到来,解决了相关技术中的当下层网元延时收到或未收到控制面的MBMS会话结束消息时,下层网元无法准确调度资源,且不同的下层网元之间的处理不一致的问题,从而能够使得下层网元及时获知某一业务具体的结束时间,从而判定数据是丢失了还是已经结束,能够准确地对资源进行调度。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据相关技术的动态复用的示例图;
图2是根据相关技术的上层网元-下层网元的逻辑结构图;
图3是根据相关技术的上层网元向下层网元发送的同步序列数据帧和控制帧的示例图;
图4是根据本发明实施例的多媒体广播组播业务系统的同步方法的流程图;
图5是根据本发明优选实施例的多媒体广播组播业务系统的同步方法的流程示意图;
图6是根据本发明优选实施例一的SYNCPDUType3格式的示意图;
图7是根据本发明优选实施例二的SYNCPDUType3格式的示意图;
图8是根据本发明优选实施例三的SYNCPDUType3格式的示意图;
图9是根据本发明优选实施例四的SYNCPDUType0格式(包括增加数据结束指示)的示意图;
图10是根据本发明优选实施例五的SYNCPDUType1格式(包括增加数据结束指示)的示意图;
图11是根据本发明优选实施例六的SYNCPDUType2格式(包括增加数据结束指示)的示意图;
图12是根据本发明优选实施例七的SYNCPDUType0格式(包括增加数据结束指示)的示意图;
图13是根据本发明优选实施例八的SYNCPDUType1格式(包括增加数据结束指示)的示意图;
图14是根据本发明优选实施例九的SYNCPDUType2格式(包括增加数据结束指示)的示意图;
图15是根据本发明优选实施例十的SYNCPDUType1格式(包括增加数据结束指示)的示意图;
图16是根据本发明优选实施例十一的SYNCPDUType2格式(包括增加数据结束指示)的示意图;
图17是根据本发明实施例的多媒体广播组播业务系统的示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
图4是根据本发明实施例的多媒体广播组播业务系统的同步方法的流程图,包括:
步骤S401,当业务结束时,上层网元在用户面发送业务结束信息;
步骤S402,下层网元根据接收到的业务结束信息,获知该业务结束,并进行相应地处理。
该实施例由于定义了一个业务结束信息,当某一业务结束时,将该业务结束信息添加到用户面数据中一起发送给下层网元,指示下层网元该业务已经结束,该业务不会再有其他数据包到来,解决了相关技术中的当下层网元延时收到或未收到控制面的MBMS会话结束消息时,下层网元无法准确调度资源,且不同的下层网元之间的处理不一致的问题。使用该实施例能够使得下层网元及时获知某一业务具体的结束时间,从而判定数据是丢失了还是已经结束,能够准确地对资源进行调度。
使用该实施例能够使得不同下层网元对同一业务的资源分配保持一致,对同一情况采取一致的处理,从而使用户终端能够正常地接收业务数据。
优选地,自定义的协议数据单元类型为TYPE3的SYNC帧携带业务结束信息(其格式如图6、图7和图8所示),
步骤S401中上层网元在用户面发送业务结束信息采用以下方式之一:
上层网元在业务的最后一个数据包所在的同步序列的末尾发送一个或多个TYPE3的SYNC帧;
上层网元在业务的最后一个数据包所在的同步序列的下一个同步序列中发送一个或多个TYPE3的SYNC帧;
上层网元在业务的最后一个数据包所在的同步序列的之后的一个或多个同步序列中发送一个或多个TYPE3的SYNC帧;
步骤S401包括:下层网元接收到TYPE3的SYNC帧后,获知业务已结束;下层网元释放为业务分配的资源。
上述优选实施例提供了采用TYPE3的SYNC帧表示业务结束信息时,本发明的多媒体广播组播业务系统的同步方法的具体实施方案。
优选地,步骤S401中上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE0的SYNC帧中携带业务结束信息(TYPE0的SYNC帧的格式如图9、图12所示),
其中,业务结束信息占用TYPE0的SYNC帧中的spare比特位中的一位或者多位,当占用spare比特位中的一位且比特位的值为1时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用spare比特位中的二位且比特位的值为11时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用spare比特位中的三位且比特位的值为111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用spare比特位中的四位且比特位的值为1111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息。
步骤S402包括:下层网元接收到TYPE0的SYNC帧,且TYPE0的SYNC帧的spare比特位中表示业务结束信息的比特位的值为1或11或111或1111时,下层网元获知接收到的TYPE0的SYNC帧所在的同步序列为该业务的最后一个同步序列;下层网元释放为该业务分配的资源。
上述优选实施例提供了在现有的SYNCPDU的格式-TYPE0格式的基础上,在TYPE0的SYNC帧中携带业务结束信息时,本发明的多媒体广播组播业务系统的同步方法的具体实施方案。
优选地,业务结束信息占用TYPE0的SYNC帧中的padding比特位中的一位或者多位,当占用padding比特位中的一位且比特位的值为1时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用padding比特位中的二位且比特位的值为11时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息。
优选地,步骤S401中上层网元在用户面发送业务结束信息的方式还包括:
该业务的最后一个数据包所在的同步序列中的所有TYPE0的SYNC帧格式均为采用携带有业务结束信息的TYPE0的SYNC帧格式,指示该同步序列为该业务的最后一个同步序列。
上述优选实施例提供了在TYPE0的SYNC帧中携带业务结束信息的另外两种方案。
优选地,步骤S401中上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE1的SYNC帧中携带业务结束信息(TYPE1的SYNC帧的格式如图10、图13、图15所示),
其中,业务结束信息占用TYPE1的SYNC帧中的spare比特位中的一位或者多位;或者
业务结束信息占用TYPE1的SYNC帧中的spareextension比特位中的一位或者多位;或者
业务结束信息占用TYPE1的SYNC帧中的padding比特位中的一位或者多位。
或者该业务的最后一个数据包所在的同步序列中的所有TYPE1的SYNC帧格式均为采用携带有业务结束信息的TYPE1的SYNC帧格式,指示该同步序列为该业务的最后一个同步序列。
上述优选实施例提供了在现有的SYNCPDU的格式-TYPE1格式的基础上,在TYPE1的SYNC帧中携带业务结束信息的四种方案。
优选地,步骤S401中上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE2的SYNC帧中携带业务结束信息,
其中,业务结束信息占用TYPE2的SYNC帧中的spare比特位中的一位或者多位;或者
业务结束信息占用TYPE2的SYNC帧中的padding比特位中的一位或者多位;或者
业务结束信息占用TYPE2的SYNC帧中的spareextension比特位中的一位或者多位。
或者该业务的最后一个数据包所在的同步序列中的所有TYPE2的SYNC帧格式均为采用携带有业务结束信息的TYPE2的SYNC帧格式,指示该同步序列为该业务的最后一个同步序列。
上述优选实施例提供了在现有的SYNCPDU的格式-TYPE2格式的基础上,在TYPE2的SYNC帧中携带业务结束信息的四种方案。
可选地,在步骤S401之后还包括:MBMS网关接收到业务结束信息后释放业务的承载。
优选实施例一(新的TYPE格式,与TYPE0相似)
如图6所示,定义一种新的SYNCPDU的格式,命名为TYPE3。该格式主要用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
在该类型的数据帧中,各参数的含义如下:
协议数据单元类型(ProtocolDataUnitType,PDUType):该参数指示SYNC帧的结构。该参数位于帧中第一个字节的第4至第7比特。
值范围:{0=无静荷同步帧,1=无压缩头的用户数据同步帧,2=有压缩头的用户数据同步帧,3=指示尾部的同步帧,4-15=保留}。
域长度:4bits(比特)。
时间戳(TimeStamp):一个同步周期中,同步序列的开始时间的相对时间值。
值范围:{0...60000-1},单位:10ms的基准。
域长度:2octets(字节)。
包号(PacketNumber):指示在同步序列中SYNCPDU的个数。辅助无线接入网节点检测SYNCPDU的丢包。另外,该参数也用于在无线接入网节点内重新排列PDU。Packetnumber需要在每个同步序列的末端复位,这个参数对于TYPE3的SYNCPDU不计数。
值范围:{0..216-1}。
域长度:2octets。
累积发送的字节数(ElapsedOctetNumber):该参数指示一个同步序列内的,累计的已发字节数。该参数在每个同步序列末端复位。这个参数对于TYPE3的SYNCPDU不计数。
值范围:{0..232-1}。
域长度:4octets。
已发送的总包数(TotalNumberofPacket):该参数指示一个同步周期内,MBMS业务累积数据包个数。这个参数对于TYPE3的SYNCPDU不计数。
值范围:{0..224-1}。
域长度:3octets。
已发送的总字节数(TotalNumberofOctet):该参数指示一个同步周期内,MBMS业务累积字节数。这个参数对于TYPE3的SYNCPDU不计数。
值范围:{0..240-1}。
域长度:5octets。
此外,还有参数空闲(spare)、头循环冗余校验(HeaderCyclicRedundancyCheck,HeaderCRC)和补丁(Padding)。
如图5所示,此时,在LTE系统中,MBMS的同步方法如下:
步骤1,在BM-SC(广播多播业务中心)获知某数据包为该业务的最后一个数据包时,在该数据包所在的同步序列的末尾发送一个或多个TYPE3帧。同时,BM-SC发送MBMS会话结束消息。
为防止TYPE3帧在传输过程中丢失,可以发送多个TYPE3帧。
也可以,在最后一个数据包所在的同步序列的下一个同步序列中发送一个或多个TYPE3帧。
步骤2,当MBMS-GW(MBMSgateway,MBMS网关)接收到TYPE3帧后,释放相应的业务承载。并且,MBMS-GW转发接收到的MBMS会话结束消息给相应的MME(mobilitymanagemententity,移动管理实体)。
步骤3,当eNB接收到此格式的数据包时,认为该业务已经结束,可选的,为该业务所分配的资源可以释放。
其中,如果TYPE3帧在最后一个数据包所在同步序列中发送,则根据Timestamp,可以获知该TYPE3帧与最后一个数据包属于相同的同步序列。如果前面的数据包有丢失,可以根据PacketNumber获知丢包的个数,根据ElapsedOctetNumber获知丢失的Octet数。而TotalNumberofPacket和TotalNumberofOctet则可以做统计计算只用。
如果TYPE3帧在最后一个数据包所在同步序列之后的一个或者多个同步序列中发送,则根据Timestamp,可以获知该TYPE3帧所处的同步序列。此时,PacketNumber和ElapsedOctetNumber没有实际意义。而TotalNumberofPacket和TotalNumberofOctet则可以做统计计算只用。
优选实施例二(新的TYPE格式,TYPE0的极简化版)
如图7所示,定义一种新的SYNCPDU的格式,命名为TYPE3。该格式主要用于指示最后一个数据包(即上述的业务结束信息)。即,在基站接收到这种格式的数据包时,可以获知哪一个数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
PDUType:该参数指示SYNC帧的结构,该参数位于帧中第一个字节的,第4至第7比特。
值范围:{0=无静荷同步帧,1=无压缩头的用户数据同步帧,2=有压缩头的用户数据同步帧,3=指示尾部的同步帧,4-15=保留}。
域长度:4bits。
TimeStamp:一个同步周期中,同步序列的开始时间的相对时间值。
值范围:{0...60000-1},单位:10ms的基准。
域长度:2octets。
如图5所示,此时,在LTE系统中,MBMS的同步方法如下:
步骤1,在BM-SC获知某数据包为该业务的最后一个数据包时,在该数据包所在的同步序列的下一个同步序列,或者之后的多个同步序列发送一个或者多个TYPE3帧。同时,BM-SC发送MBMS会话结束消息。
步骤2,当MBMS-GW接收到TYPE3帧后,释放相应的业务承载。并且,MBMS-GW转发接收到的MBMS会话结束消息给相应的MME。
步骤3,当eNB接收到此格式的数据包时,认为该业务已经结束,为该业务所分配的资源可以释放。
其中,当TYPE3帧在最后一个数据包所在同步序列之后的一个或者多个同步序列中发送时,根据Timestamp,可以获知该TYPE3帧所处的同步序列。
优选实施例三(新的TYPE格式,TYPE0简化版)
如图8所示,定义一种新的SYNCPDU的格式,命名为TYPE3。该格式主要用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
PDUType:该参数指示SYNC帧的结构。该参数位于帧中第一个字节的,第4至第7比特。
值范围:{0=无静荷同步帧,1=无压缩头的用户数据同步帧,2=有压缩头的用户数据同步帧,3=指示尾部的同步帧,4-15=保留}。
域长度:4bits。
TimeStamp:一个同步周期中,同步序列的开始时间的相对时间值。
值范围:{0...60000-1},单位:10ms的基准。
域长度:2octets。
TotalNumberofPacket:该参数指示一个同步周期内,MBMS业务累积数据包个数。这个参数对于TYPE3的SYNCPDU不计数。
值范围:{0..224-1}。
域长度:3octets。
TotalNumberofOctet:该参数指示一个同步周期内,MBMS业务累积字节数。这个参数对于TYPE3的SYNCPDU不计数。
值范围:{0..240-1}。
域长度:5octets。
如图5所示,此时,在LTE系统中,MBMS的同步方法如下:
步骤1,在BM-SC获知某数据包为该业务的最后一个数据包时,在该数据包所在的同步序列的下一个同步序列,或者之后的多个同步序列发送一个或者多个TYPE3帧。同时,BM-SC发送MBMS会话结束消息。
步骤2,当MBMS-GW接收到TYPE3帧后,释放相应的业务承载。并且,MBMS-GW转发接收到的MBMS会话结束消息给相应的MME。
步骤3,当eNB接收到此格式的数据包时,认为该业务已经结束,为该业务所分配的资源可以释放。
其中,当TYPE3帧在最后一个数据包所在同步序列之后的一个或者多个同步序列中发送时,根据Timestamp,可以获知该TYPE3帧所处的同步序列。而TotalNumberofPacket和TotalNumberofOctet则可以做统计计算之用。
优选实施例四(在现有的TYPE0结构上加以修改)
如图9所示,重新使用现有的SYNCPDU的格式-TYPE0。使用该格式中的spare比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
1、只使用一个比特位的方法:例如,
①用第三比特指示该TYPE0是否携带数据结束信息。如果该比特位值为“0”,则表示非数据传输结束;如果该比特位值为“1”,则表示该TYPE0帧携带数据结束指示,当收到该指示时,eNB认为该TYPE0所在同步序列为相应的MBMS业务数据传输的最后一个同步序列。
②用第二比特指示该TYPE0是否携带数据结束信息。
③用第一比特指示该TYPE0是否携带数据结束信息。
④用第零比特指示该TYPE0是否携带数据结束信息。
2、使用两个比特位的方法:例如,
①用第三比特和第二比特指示该TYPE0是否携带数据结束信息。如果该比特位值为“00”,则表示非数据传输结束;如果该比特位值为“11”,则表示该TYPE0帧携带数据结束指示,当收到该指示时,eNB认为该TYPE0所在同步序列为相应的MBMS业务数据传输的最后一个同步序列。
②用第一比特和第零比特指示该TYPE0是否携带数据结束信息。
③其他组合方式可以根据具体情况定义,或者保留不用
3、使用三个比特位的方法:例如,
①用第三比特和第二比特和第一比特指示该TYPE0是否携带数据结束信息。如果该比特位值为“000”,则表示非数据传输结束;如果该比特位值为“111”,则表示该TYPE0帧携带数据结束指示,当收到该指示时,eNB认为该TYPE0所在同步序列为相应的MBMS业务数据传输的最后一个同步序列。
②用第二比特和第一比特和第零比特指示该TYPE0是否携带数据结束信息。如果该比特位值为“000”,则表示非数据传输结束;如果该比特位值为“111”,则表示该TYPE0帧携带数据结束指示,当收到该指示时,eNB认为该TYPE0所在同步序列为相应的MBMS业务数据传输的最后一个同步序列。
③其他组合方式可以根据具体情况定义,或者保留不用
4、使用四个比特位的方法:例如,
①用第三比特和第二比特和第一比特和第零比特指示该TYPE0是否携带数据结束信息。如果该比特位值为“0000”,则表示非数据传输结束;如果该比特位值为“1111”,则表示该TYPE0帧携带数据结束指示,当收到该指示时,eNB认为该TYPE0所在同步序列为相应的MBMS业务数据传输的最后一个同步序列。
②其他组合方式可以根据具体情况定义,或者保留不用
优选实施例五
如图10所示,重新使用现有的SYNCPDU的格式-TYPE1。使用该格式中的spare比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
或,在最后一个数据包所在的同步序列的所有数据包均采用本实施例的格式,指示该同步序列为业务的最后一个同步序列。
图10中的TYPE1帧格式中的参数:净荷循环冗余校验:PayloadCRC、空闲位扩展:Spareextention、净荷域:Payloadfields。
具体同步方法可以参考优选实施例四。
优选实施例六
如图11所示,重新使用现有的SYNCPDU的格式-TYPE2。使用该格式中的spare比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
或,在最后一个数据包所在的同步序列的所有数据包均采用本实施例的格式,指示该同步序列为业务的最后一个同步序列。
图11中的TYPE2帧格式中的参数:数据包收敛协议信息:PDCPinformation(PacketDataConvergenceProtocolinformation)、未压缩的净荷IP头:UncompressedpayloadIPheader、Ipv6indic:Ipv6指示。
具体同步方法可以参考优选实施例四。
优选实施例七
如图12所示,重新使用现有的SYNCPDU的格式-TYPE0。使用该格式中的padding比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
或,在最后一个数据包所在的同步序列的所有数据包均采用本实施例的格式,指示该同步序列为业务的最后一个同步序列。
具体同步方法可以参考优选实施例四。
优选实施例八
如图13所示,重新使用现有的SYNCPDU的格式-TYPE1。使用该格式中的padding比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
具体同步方法可以参考优选实施例四。
优选实施例九
如图14所示,重新使用现有的SYNCPDU的格式-TYPE2。使用该格式中的padding比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
具体同步方法可以参考优选实施例四。
优选实施例十
如图15所示,重新使用现有的SYNCPDU的格式-TYPE1。使用该格式中的Spareextension比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
具体同步方法可以参考优选实施例四。
实施例十一
如图16所示,重新使用现有的SYNCPDU的格式-TYPE2。使用该格式中的Spareextension比特位中的一位或者多位,用于指示最后一个数据包的信息。即,在基站接收到这种格式的数据包时,可以认为该数据包是所属业务的最后一个数据包,该业务不会再有其他数据包到来。
具体同步方法可以参考优选实施例四。
图17是根据本发明实施例的多媒体广播组播业务系统的示意图,包括:上层网元10,用于当业务结束时,在用户面发送业务结束信息;下层网元20,用于根据接收到的业务结束信息,获知业务结束,并进行相应地处理。
优选地,自定义的协议数据单元类型为TYPE3的SYNC帧携带业务结束信息,
上层网元10还用于在业务的最后一个数据包所在的同步序列的末尾发送一个或多个TYPE3的SYNC帧;或者还用于在业务的最后一个数据包所在的同步序列的下一个同步序列中发送一个或多个TYPE3的SYNC帧;或者还用于在业务的最后一个数据包所在的同步序列的之后的一个或多个同步序列中发送一个或多个TYPE3的SYNC帧;
下层网元20还用于接收到TYPE3的SYNC帧后,获知业务已结束;还用于释放为业务分配的资源。
从以上的描述中,可以看出,本发明实现了如下技术效果:
(1)能够使得下层网元及时获知某一业务具体的结束时间,从而判定数据是丢失了还是已经结束,能够准确地对资源进行调度。
(2)能够使得不同下层网元对同一业务的资源分配保持一致,对同一情况采取一致的处理,从而使用户终端能够正常地接收业务数据。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (4)
1.一种多媒体广播组播业务系统的同步方法,其特征在于,包括:
当业务结束时,上层网元在用户面发送业务结束信息;
下层网元根据接收到的业务结束信息,获知所述业务结束,并进行相应地处理;
其中,在当业务结束时,上层网元在用户面发送业务结束信息之后还包括:
多媒体广播多播业务网关接收到所述业务结束信息后释放所述业务的承载;
其中,自定义的协议数据单元类型为TYPE3的同步(SYNC)帧携带所述业务结束信息,
上层网元在用户面发送业务结束信息采用以下方式之一:
所述上层网元在所述业务的最后一个数据包所在的同步序列的末尾发送一个或多个TYPE3的SYNC帧;
所述上层网元在所述业务的最后一个数据包所在的同步序列的下一个同步序列中发送一个或多个TYPE3的SYNC帧;
所述上层网元在所述业务的最后一个数据包所在的同步序列的之后的一个或多个同步序列中发送一个或多个TYPE3的SYNC帧;
下层网元根据接收到的业务结束信息,获知所述业务结束,并进行相应地处理包括:
所述下层网元接收到所述TYPE3的SYNC帧后,获知所述业务已结束;
所述下层网元释放为所述业务分配的资源;
或者,
上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE0的SYNC帧中携带所述业务结束信息,
其中,所述业务结束信息占用所述TYPE0的SYNC帧中的空闲比特位中的一位或者多位,当占用空闲比特位中的一位且比特位的值为1时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的二位且比特位的值为11时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的三位且比特位的值为111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的四位且比特位的值为1111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;
其中,下层网元根据接收到的业务结束信息,获知所述业务结束,并进行相应地处理包括:
所述下层网元接收到TYPE0的SYNC帧,且所述TYPE0的SYNC帧的空闲比特位中表示业务结束信息的比特位的值为1或11或111或1111时,所述下层网元获知接收到的所述TYPE0的SYNC帧所在的同步序列为所述业务的最后一个同步序列;
所述下层网元释放为所述业务分配的资源。
2.根据权利要求1所述的方法,其特征在于,所述业务结束信息占用所述TYPE0的SYNC帧中的补丁比特位中的一位或者多位,当占用补丁比特位中的一位且比特位的值为1时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用补丁比特位中的二位且比特位的值为11时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息。
3.根据权利要求1或2所述的方法,其特征在于,上层网元在用户面发送业务结束信息的方式还包括:
所述业务的最后一个数据包所在的同步序列中的所有TYPE0的SYNC帧格式均为采用所述携带有业务结束信息的TYPE0的SYNC帧格式,指示所述同步序列为所述业务的最后一个同步序列。
4.一种多媒体广播组播业务系统,其特征在于,包括:
上层网元,用于当业务结束时,在用户面发送业务结束信息;
下层网元,用于根据接收到的业务结束信息,获知所述业务结束,并进行相应地处理;
其中,所述多媒体广播组播业务系统还包括:
多媒体广播多播业务网关,用于在接收到所述业务结束信息后释放所述业务的承载;
其中,自定义的协议数据单元类型为TYPE3的SYNC帧携带所述业务结束信息,
所述上层网元还用于在所述业务的最后一个数据包所在的同步序列的末尾发送一个或多个TYPE3的SYNC帧;或者还用于在所述业务的最后一个数据包所在的同步序列的下一个同步序列中发送一个或多个TYPE3的SYNC帧;或者还用于在所述业务的最后一个数据包所在的同步序列的之后的一个或多个同步序列中发送一个或多个TYPE3的SYNC帧;
所述下层网元还用于接收到所述TYPE3的SYNC帧后,获知所述业务已结束;还用于释放为所述业务分配的资源;
或者,
上层网元在用户面发送业务结束信息的方式包括:在协议数据单元类型为TYPE0的SYNC帧中携带所述业务结束信息,
其中,所述业务结束信息占用所述TYPE0的SYNC帧中的空闲比特位中的一位或者多位,当占用空闲比特位中的一位且比特位的值为1时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的二位且比特位的值为11时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的三位且比特位的值为111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;当占用空闲比特位中的四位且比特位的值为1111时,表示TYPE0的SYNC帧中携带有指示业务数据结束的业务结束信息;
其中,下层网元根据接收到的业务结束信息,获知所述业务结束,并进行相应地处理包括:
所述下层网元接收到TYPE0的SYNC帧,且所述TYPE0的SYNC帧的空闲比特位中表示业务结束信息的比特位的值为1或11或111或1111时,所述下层网元获知接收到的所述TYPE0的SYNC帧所在的同步序列为所述业务的最后一个同步序列;
所述下层网元释放为所述业务分配的资源。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910212090.XA CN102056084B (zh) | 2009-11-04 | 2009-11-04 | 多媒体广播组播业务系统及其同步方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910212090.XA CN102056084B (zh) | 2009-11-04 | 2009-11-04 | 多媒体广播组播业务系统及其同步方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102056084A CN102056084A (zh) | 2011-05-11 |
CN102056084B true CN102056084B (zh) | 2016-02-10 |
Family
ID=43959919
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200910212090.XA Expired - Fee Related CN102056084B (zh) | 2009-11-04 | 2009-11-04 | 多媒体广播组播业务系统及其同步方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102056084B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105893323A (zh) * | 2016-05-23 | 2016-08-24 | 华为技术有限公司 | 一种读数据的方法及设备 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101175003A (zh) * | 2006-11-03 | 2008-05-07 | 中兴通讯股份有限公司 | 从无线网络控制器接入组播业务的装置 |
CN101370156A (zh) * | 2007-08-15 | 2009-02-18 | 上海华为技术有限公司 | 多播组播业务传输的方法和网络系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006025654A1 (en) * | 2004-07-29 | 2006-03-09 | Samsung Electronics Co., Ltd. | Method for providing notifications for multi-media broadcast/multicast service |
CN100571140C (zh) * | 2004-09-15 | 2009-12-16 | 华为技术有限公司 | 一种通知用户多媒体广播/组播业务会话结束的方法 |
CN101247315B (zh) * | 2007-02-12 | 2011-06-01 | 上海贝尔阿尔卡特股份有限公司 | 用于单频网传输的内容同步方法和装置 |
CN102035794A (zh) * | 2009-09-29 | 2011-04-27 | 中兴通讯股份有限公司 | 多媒体广播组播业务的同步序列发送和接收方法及系统 |
-
2009
- 2009-11-04 CN CN200910212090.XA patent/CN102056084B/zh not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101175003A (zh) * | 2006-11-03 | 2008-05-07 | 中兴通讯股份有限公司 | 从无线网络控制器接入组播业务的装置 |
CN101370156A (zh) * | 2007-08-15 | 2009-02-18 | 上海华为技术有限公司 | 多播组播业务传输的方法和网络系统 |
Also Published As
Publication number | Publication date |
---|---|
CN102056084A (zh) | 2011-05-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2348778B1 (en) | Method and device of synchronization scheduling | |
JP4755675B2 (ja) | 無線移動通信システムにおけるマルチメディアサービス方法 | |
EP1532754B1 (en) | Method for scheduling transmission of mbms data in umts | |
US8228947B2 (en) | Method and apparatus for communicating protocol data unit in a radio access network | |
KR101030678B1 (ko) | 단일 주파수 모바일 통신 네트워크에서 브로드캐스트 데이터의 전달을 동기화하기 위한 방법 | |
KR101445115B1 (ko) | 게이트웨이 및 기지국들 사이를 동기화하는 방법 및 대응하는 게이트웨이와 기지국 | |
RU2460230C1 (ru) | Способ синхронного планирования | |
US8345611B2 (en) | Method of transmitting a data block in a wireless communication system | |
US20150009884A1 (en) | Method For Content Synchronization When Broadcasting Data In A Wireless Network | |
JP2005535268A (ja) | 無線移動通信システムのマルチキャストサービス方法 | |
CN101772966A (zh) | 用于提供多个服务的方法 | |
US20150103728A1 (en) | Method and apparatus for transmitting multimedia broadcast data in wireless communication system | |
CN114946158A (zh) | 用于多播/广播业务数据的系统和方法 | |
CN101741499B (zh) | 同步调度方法 | |
US9386598B2 (en) | Method and apparatus for synchronization processing | |
EP2180651A1 (en) | A method for the synchronization of the multimedia broadcast/multicast | |
US20130258933A1 (en) | Synchronization method and apparatus for broadcast multicast service | |
CN102056084B (zh) | 多媒体广播组播业务系统及其同步方法 | |
CN102036176A (zh) | 一种多媒体广播组播业务的同步恢复的方法及网络系统 | |
CN101998242A (zh) | 多媒体广播组播业务中多调度周期联合调度的方法及装置 | |
CN115150758A (zh) | 用户设备、基站和通信系统以及通信方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20160210 Termination date: 20171104 |
|
CF01 | Termination of patent right due to non-payment of annual fee |