具体实施方式
目前,通信业务的一个发展趋势为低时延高可靠业务(Ultra-Reliable and LowLatency Communications,URLLC),该业务对时延要求较高。需要说明的是,URLLC业务并非一项具体业务的名称,而是一种类型的业务,该种业务要求通信过程时延较小。因此,只要是对时延性有要求的通信业务,均在本申请的保护范围内。为了便于说明,以下以URLLC业务为例对本申请的技术方案进行说明。
LTE调度流程可以实现基站与终端之间的通信业务,在具体实现URLLC这一通信业务的场景中,LTE调度流程不能满足该业务的低时延要求。这是由于,现有LTE调度流程中,在终端上传业务数据之前,需要多次在终端与基站之间交互控制信令,以为业务数据的上传进行通信资源的配置。
见图1,其示出了现有LTE调度流程的一个流程示意。如图1所示,该流程具体包括五个步骤。
步骤1:终端在有通信业务需求时,向基站发送调度请求(Scheduling Request,SR)。调度请求SR中只有一个比特位,用来告知基站此UE需要上行授权(Uplink Grant,ULGrant)。
步骤2:基站向终端返回UL Grant,该UL Grant以供终端发送缓存状态报告(Buffer State Report,BSR)。
步骤3:终端使用UL Grant发送BSR,BSR用于上报终端即要发送的业务数据的数据量。
步骤4:基站根据终端上报的BSR及调度算法,为终端分配UL Grant,该UL Grant以供终端发送业务数据(业务数据也可以称为上行数据)。
步骤5:终端使用UL Grant发送业务数据(Data)。
其中,以上流程中涉及到两个上行授权UL Grant,为了便于区分,可以将步骤2中返回的用于发送BSR的上行授权UL Grant称为第一上行授权(UL Grant_1),将步骤4中返回的用于发送业务数据的上行授权UL Grant为第二上行授权(UL Grant_2)。另外,上行授权也可以称为上行授权资源。
在图1所示的调度中,基站需要根据终端待上传业务数据的数据量,来确定第二上行授权资源的大小,但终端并未直接告知基站待发送数据的数据量,而是首先通过步骤1告诉基站其要发送业务数据这个需求,等待步骤2中基站返回第一上行授权资源后,再在步骤3中使用第一上行授权资源上传待发送数据的数据量。另外,基站在步骤4中根据该数据量及调度算法,临时确定出终端需要的第二上行授权,再将第二上行授权下发给终端。
可见,终端在向基站发送业务数据之前,需要进行多次的信令交互(至少包括步骤1~4的交互)。见表1,其示出了LTE调度流程中的时延数据,从表1中可以看出,每次信令交互中终端及基站均需要耗费一定的处理时间,信令交互次数越多,则导致的时延越长。
表1
结合图1及表1可以看出,终端向基站发送业务数据之前的调度流程时延较长。为了解决此问题,本申请提供了一种调度方法,以缩短调度流程导致的时延,进而在终端发送低时延高可靠通信URLLC业务的场景中,满足该业务对时延性的要求。
本申请技术方案通过简化调度流程步骤的方式来缩短现有调度流程的时延。基于该构思,本申请提供以下几种具体的实施例。
实施例一
本实施例是终端发送的SR中携带更多的信息,这些信息原来携带在BSR中以供基站生成用于上传业务数据的上行授权(即第二上行授权)。这样,便可以减少返回第一上行授权的步骤2以及发送BSR的步骤3,进而缩短调度流程的时延。
需要说明的是,终端可以在SR中携带更多的信息,终端具有该项功能可以是基于调度流程之前的连接过程中基站的配置。
具体地,在调度流程之前,终端与基站之间会执行连接过程。如图2所示,在连接过程中,基站会给终端发送无线资源控制(Radio Resource Control,RRC)连接重配消息。RRC连接重配消息中包含对逻辑信道的配置消息,不同的业务使用不同的逻辑信道,基站可以对URLLC业务所使用的逻辑信道进行配置,即在URLLC业务所使用逻辑信道的配置消息中新增一配置标识,该配置标识用于指示终端在该逻辑信道中可以采用增强方式发送SR。这样,终端在执行调度流程时,便根据该配置标识的指示,在发送给基站的SR中封装更多的信息。当然,若终端并未在RRC连接重配消息中检测到配置标识,则终端可以按照现有方式发送SR。
有关上述流程,需指出一些技术细节。在逻辑信道的配置消息中新增的配置标识可以是信息单元(Information Element,IE)这种形式,信息单元IE的具体名称可为logicalChannel-SR-Enhancement-mask-r15。
需要说明的是,基站向终端发送的配置指示并非局限于RRC连接重配消息中的添加的配置标识这一种形式,还可以是其他形式,如配置标识可携带在物理下行控制信道(Physical Downlink Control Channel,PDCCH)资源或者MAC CE中。其中,媒体接入控制(Medium Access Control,MAC)控制元素(Control Element,CE)可以称为媒体接入控制单元。
进一步地,基站对终端发送配置指示的方式可以并非局限于连接过程,也可以是调度流程之前的其他过程或者在调度流程中。
更进一步地,终端可以实现此功能,可以如上所述是基于基站的配置,但也可以是终端自身的配置,即终端对URLLC业务所在的逻辑信道生成配置指示,以指示在该逻辑信道中采用增强方式发送SR。
终端经过上述配置后,便可以采用增强方式发送SR。见图3,其示出了本申请提供的调度方法实施例一的流程,具体包括步骤S301~S303。
S301:终端在需要发送URLLC业务数据时,向基站发送增强SR,该增强SR中携带有BSR内的缓存状态信息。
其中,终端确定是否需要发送URLLC业务的业务数据,若需要发送URLLC业务的业务数据,则终端会生成向基站上报的SR。URLLC业务的业务数据可能是在基站指定的逻辑信道上发送,也可能并未在基站指定的逻辑信道上发送。
终端生成的SR与图1所示的现有SR相比包含更多的信息,因此,为了便于区分,可以将本实施例生成的SR称为增强SR。现有的SR中仅包含1个比特位,该比特位用于告知基站终端具有要发送的业务数据。若想要在SR中新增缓存状态信息,则可以在SR中增加比特位,使用增加的比特位来表示新增的缓存状态信息。
可选的,增强SR内除了携带此终端具有待发送的业务数据的指示信息之外,还携带有原来携带在BSR内的缓存状态信息。原来携带在BSR内的缓存状态信息即增强SR内新增的缓存状态信息,包括但不限定于以下任意一种或两种的组合:待发送业务数据的数据量、逻辑信道(或逻辑信道组)的标识。
其中,待发送业务数据的数据量以供基站计算上行授权资源(即第二上行授权资源)的大小。逻辑信道组的标识,以供基站确定上行授权资源是分配给哪个逻辑信道组的,这些逻辑信道组中包含发送业务数据的逻辑信道。
可选的,增强SR中增加的缓存状态信息包含待发送业务数据的数据量指示信息,数据量指示信息用于表示业务数据的数据量。具体地,数据量指示信息可以是以下形式中的任意一种:
1、数据量一级索引index。
基站中存储有数据量一级索引与数据量一级范围的对应表,基站接收到数据量一级索引index后,在对应表中查找该数据量一级索引index所对应的数据量一级范围,从而确定出终端中待发送业务数据的大概数据量。
例如,增强SR中携带的index的值为3,对应表中index 3对应的数据量为300-400,则基站便可以确定出终端中待发送业务数据的数据量在300与400之间。
可见,增强SR中携带的该种方式的数据量,为基站提供的信息并不精确,基站只能大致确定待发送业务数据的数据量。
2、数据量一级索引index及数据量二级索引sub-index。
基站中不仅存储有上述对应表,还存储有数据量二级索引sub-index与数据量二级范围的对应表。为了便于区分,可以将第一个对应表称为第一对应表,将第二个对应表称为第二对应表。增强SR中除了包含数据量一级索引index外,还进一步包括数据量二级索引sub-index。数据量二级索引sub-index的作用是提供更详细的数据量范围信息。
例如,增强SR中携带的index的值为3,sub-index的值为6,则基站根据index 3在一级对应表中查找到的数据量一级范围为300-400,根据sub-index 6在二级对应表中查找到的数据量二级范围为60-70,进而确定出待发送业务数据的数据量在360-370之间。
可见,增强SR中携带该种形式的数据量,可以为基站提供更详细的数据量范围查找依据,从而使得基站可以更加精确地确定出待发送业务数据的数据量。
以上两种方式的索引可以概括为数据量的索引,数据量的索引用于指示数据量的范围。数据量的索引可以包括若干级别的索引,每一下级索引指示的数据量范围均比上一级索引指示的数据量范围更精细。以上述的一级索引及二级索引为例,一级索引指示的是百位上的数据量范围,二级索引指示的十位上的数据量范围。或者,还可以进一步包括三级索引,三级索引可以指示个位上的数据量范围。当然,一级索引、二级索引及三级索引所指示的数据量范围并非局限于百位、十位及个位,还可以是其他单位上数值范围。
3、数据量具体值。
终端将待发送的业务数据存储在缓存Buffer中,并且记录缓存Buffer中的数据量,该数据量即待发送业务数据的数据量。增强SR中并不携带上述形式的索引,而是携带缓存Buffer中数据量具体值例如365。
可见,增强SR中携带该种形式的数据量可以为基站提供最为详细的依据,基站根据该数据量,可以生成资源量大小最精确的上行资源。相比以上两种形式,该种形式最为精确,但比特位的开销最大,在实际应用中可以根据实际需求选择相应的数据形式。
需要说明的是,本申请提供了增强SR中携带的数据量的三种具体形式,但并非局限于此,只要是能为基站提供较为详细的数据量信息的形式均可。另外,终端可以自身决定发送何种形式的数据量,或者,可以是由基站决定的,即基站在向终端返回RRC连接重配消息中携带使用哪种形式数据量的指示,以使终端根据该指示决定发送何种形式的数据量。
终端生成增强SR后,便可以将该增强SR发送给基站。
S302:基站根据增强SR携带的缓存状态信息,为终端分配UL Grant。
其中,基站根据增强SR内携带的缓存状态信息,为终端分配上行授权资源ULGrant,该上行授权资源即以上所述的第二上行授权资源,以供终端上传业务数据。基站并将该上行授权资源UL Grant下发给终端。
S303:终端使用UL Grant上传业务数据。
其中,终端使用基站分配的上行授权资源UL Grant,向基站上传待发送的URLLC业务数据。
由以上的技术方案可知,本实施例需要在SR内增加比特位,来携带更多的信息。然而,终端需要使用物理上行控制信道(Physical Uplink Control Channel,PUCCH)资源发送SR,SR中包含的比特位越多,则需要使用的PUCCH资源也就越多。因此,本实施例适合应用在PUCCH资源可扩展的场景中。
本实施中终端生成的增强SR内携带有调度所需信息,此些信息原来包含在BSR内发送,本实施例中将此些调度所需信息包含在增强SR内发送,从而可以省略图1所示现有调度流程中返回UL Grant的步骤2及发送BSR的步骤3(图3所示画叉线的虚线步骤即省略步骤),进而缩短现有调度流程的时延。
以上实施例一中,终端生成的增强SR中包含有原BSR中的缓存状态信息,目的是为了减少现有调度流程中的步骤2及3。但是,要实现简化现有调度流程,除了可以省略图1中步骤2及3,还可以简化一些步骤的处理过程,这样也可以缩短现有调度流程的时延。基于此,本申请提供了以下实施例二及实施例三。
实施例二
终端生成的增强SR可以携带待发送URLLC业务数据的高优先级调度指示(可简称为优先级调度指示或调度指示),以使基站基于高优先级调度指示为URLLC业务数据快速分配第一上行授权资源,从而简化图1中步骤2和/或3的处理过程。
见图4,其示出了本申请提供的调度方法实施例二的流程,具体包括步骤S401~S405。
S401:终端在需要发送URLLC业务数据时,向基站发送增强SR,该增强SR携带有为URLLC业务数据设置的高优先级调度指示。
其中,基站可以同时处理多种业务数据,若某种业务数据的优先级较高,则基站可以为该业务数据执行相比现有技术较为快速的上行授权资源分配方式。因此,终端可以将URLLC业务数据的调度优先级设置为高优先级,且在需要发送URLLC业务数据时,在增强SR中携带高优先级调度指示,以使基站为URLLC业务数据快速分配第二上行授权资源,具体的快速分配方法参见步骤S402的说明。
在实际应用中,SR携带高优先级调度指示可以通过以下显式或隐式方式实现。
第一种,增强SR显式携带待发送业务数据的高优先级调度指示,即增强SR使用比特位携带所述调度指示。
具体地,增强SR中新增表示优先级的比特位,该比特位的值设置为高。优先级的指示可以仅包含高低两种,若URLLC业务数据的优先级指示为高,则其他业务数据的优先级指示为低。更进一步地,比特位的值可以设置为优先级别值。例如,使用自然数表示优先级别值,且数值越低表示优先级别越高。因此,若想要将URLLC业务数据的优先级别设置为最高,则可以将URLLC业务数据的优先级指示设置为0。
第二种,增强SR隐式携带待发送业务数据的高优先级调度指示。
具体地,终端与基站建立有多个逻辑信道,不同的逻辑信道用于发送不同的业务数据。终端的每个逻辑信道会按照一定的发送周期不断发送SR,发送周期可以称为SR发送周期(即调度请求发送周期)。
现有的每个逻辑信道的发送周期相同,本实施例可以预先将URLLC业务数据所使用的逻辑信道的发送周期缩短,以使URLLC业务数据的SR发送周期比其他业务数据的SR发送周期更短,以体现出URLLC业务数据的处理急迫性。其中,缩短后的SR发送周期可以称为预设的调度请求发送周期,预设的调度请求发送周期小于URLLC业务之外的其他业务对应的调度请求发送周期。基站可以与终端通过协议约定,SR的发送周期越短,则该SR对应的待发送业务数据的优先级越高。
缩短SR发送周期后,终端不仅可以通过发送SR隐含地向基站指示该SR对应的待发送业务数据的高优先级,而且,还可以缩短待发送业务数据对上行授权资源的等待时间,减少资源等待造成的时延。
SR发送周期的长短可以是终端自己设置的,也可以是基站设置的。若由基站设置,则基站可以在调度流程之前的连接过程中配置SR发送周期,例如,基站将SR发送周期包含在RRC连接重配消息中发送给终端,该SR发送周期是指示待发送业务数据优先级较高的发送周期。
第一种方式中,终端发送的增强SR内新增有比特位,用于明确告知基站待发送业务数据的优先级较高。第二种方式中,终端并未直接告知基站上述信息,而是通过较短的SR发送周期来隐含表明待发送业务数据的高优先级。在实际应用中,可以选择以上任意一种方式向基站上报待发送业务数据的高优先级调度指示。
终端生成增强SR后,便将增强SR发送至基站,且增强SR是按照一定的发送周期发送的。若增强SR以上述第二种方式即隐式方式携带待发送业务数据的高优先级调度指示,则增强SR的发送周期必然比其他业务数据的发送周期要短。
S402:基站根据增强SR携带的高优先级调度指示,使用快速分配方式为终端分配UL Grant。其中,该UL Grant以供终端上传BSR。
其中,若增强SR使用显式方式携带高优先级调度指示,则基站在接收到SR后,可以检测该SR中是否包含优先级指示且该优先级指示为高的比特位。若检测到,则表示该SR为携带高优先级调度指示的增强SR。若终端使用隐式方式携带高优先级调度指示,则基站在接收到SR后,确定该SR的发送周期,若发送周期为相较于其他SR的发送周期较短,则可以确定该SR为携带高优先级调度指示的增强SR。
确定接收到增强SR后,使用预设的加快分配方式为终端分配第一上行授权资源。快速分配方式是基于高优先级调度指示实现的,可以包括以下四种方式中的任意一种或者任意多种的组合。需要说明的是,进行组合的多种方式之间并不存在冲突,因此可以组合使用。
1、第一种快速分配方式为单独分配,即为具有高优先级调度指示的业务数据单独分配上行授权资源。
具体地,现有的上行授权资源分配方式,终端向基站上报多个逻辑信道的待发送业务数据的数据量总和,基站根据数据量总和生成上行授权资源并将其下发给终端。终端接收到该上行授权资源后,按照每个逻辑信道的需求,将该上行授权资源再分配给各个逻辑信道使用。
然而,本实施例的基站可以为URLLC业务数据所在的逻辑信道单独分配上行授权资源,即为URLLC业务数据生成上行授权资源后,便指示出该上行授权资源的分配对象为URLLC业务数据所在的逻辑信道。这样,终端接收到上行授权资源后,便可以根据该上行授权资源对应的分配对象,直接将该上行授权资源分配给URLLC业务数据所在的逻辑信道。其中,指示分配对象的具体方式可以是添加分配对象标识等各种形式。
单独分配方式可以省略终端对接收到的上行授权资源的再分配过程(再分配过程包含在原调度流程中,具体包含在原调度流程的步骤3中),从而简化了原调度流程步骤3的处理过程,进而减少了调度流程的时延。
2、第二种快速分配方式为缩短上下行数据发送间隔,即基站在接收到终端发送的增强SR后,缩短向终端返回上行授权资源的时间间隔。
具体地,基站接收到终端上传的增强SR后,会在预设的时间间隔后,向终端返回该增强SR所对应的上行授权资源。例如,基站在时刻n接收到增强SR,预设的时间间隔为4,则基站会在时刻n+4向终端返回上行授权资源。本实施例是将该时间间隔缩短,例如将时间间隔由4缩短为2。这样,基站便可以更为快速地将上行授权资源返回终端,也即表示终端可以快速地获得该上行授权资源。为了便于说明,该时间间隔可以称为预设的短时间间隔表示URLLC业务获得上行授权资源的时间间隔比其他业务的时间间隔短。
结合图1所示的现有调度流程,本快速分配方式可以缩短该调度流程的步骤2下发UL Grant的处理过程。
3、第三种快速分配方式为优先分配,即优先为具有高优先级调度指示的业务数据分配上行授权资源。
具体地,多个终端可以向同一基站发送SR,即使是同一终端,其有多种业务数据要发送时,不同业务数据所在的逻辑信道也可以向基站发送多种SR,因此,基站可能同时接收到多种SR。
本实施例中,若终端发送URLLC业务数据时将SR设置为增强SR,增强SR携带有高优先级调度指示,基站接收到包含高优先级调度指示的增强SR后,便可以确定该SR对应的业务数据的优先级较高,优先为该增强SR分配上行授权资源,从而缩短调度流程的等待时延。结合图1所示的现有调度流程,本快速分配方式可以缩短该调度流程的步骤2下发UL Grant的处理过程。
4、第四种快速分配方式为预分配,即为具有高优先级调度指示的业务数据预分配上行授权资源。
前已述及,终端按照一定发送周期不断向基站发送增强SR,基站在接收到增强SR后,若增强SR携带有高优先级调度指示,则在为该增强SR分配相应大小的上行授权资源基础上,还预分配一些量的上行授权资源。这样,基站接收到终端发送的下一个增强SR后,可以将预分配的上行授权资源直接返回给终端,从而节省生成上行授权资源的时间,缩短调度流程的时延。结合图1所示的现有调度流程,本快速分配方式可以缩短该调度流程的步骤2下发UL Grant的处理过程。或者,基站可以在返回增强SR对应的上行授权资源时,将预分配的上行授权资源一并返回终端。这样,终端可以不必发送SR请求上行授权资源,而是直接使用预分配的上行授权资源发送BSR。结合图1所示的现有调度流程,这样可以省略该调度流程的步骤1发送SR及步骤2下发UL Grant的处理过程
更具体地,业务数据的业务源可以是各种不同类型,业务源指的是业务数据的具体类型,不同类型的业务源,其生成的业务数据的数据量可能存在差别,因此,增强SR中还可以进一步携带业务数据的业务源类型,以为基站预分配数据量提供更准确的依据。
在实际应用中,基站可以选择以上四种快速分配方式中的任意一种或多种的组合。每种快速分配方式均可以在一定程度上缩短时延,选择的快速分配方式个数越多,则可以越大程度地缩短时延。
S403:终端使用UL Grant,向基站上传BSR。
需要说明的是,若基站选择的快速调度方式为第一种,即为具有高优先级调度指示的业务数据单独分配上行授权资源,则终端在接收到具有分配对象指示的上行授权资源后,便直接将该上行授权资源分配给分配对象指示对应的逻辑信道。分配对象指示,是指示上行授权资源分配给URLLC业务数据,则终端根据该分配对象指示,将上行授权资源分配给URLLC业务数据所在的逻辑信道,以供URLLC业务数据使用该上行授权资源上传BSR。
S404:基站向终端返回UL Grant。其中,该UL Grant以供终端上传业务数据。
S405:终端使用UL Grant上传业务数据。
其中,终端接收到基站下发的上行授权资源UL Grant后,使用该上行授权资源ULGrant上传URLLC业务数据。
由以上技术方案可以看出,本实施例若在SR内增加比特位来携带高优先级调度指示,则适合应用在PUCCH资源可扩展的场景中。若SR通过隐式方式携带高优先级调度指示,则适合应用在PUCCH资源比较受限,但待发送的业务数据对时延性要求较高的场景中。
本实施例中终端发送的增强SR携带有待发送业务数据的高优先级调度指示,基站根据该高优先级的指示,快速地为URLLC业务数据分配上行授权资源,该快速分配方式可以简化图1所示现有调度流程中的步骤2和/或步骤3的处理过程(如图4中的横线加粗步骤),从而缩短了现有调度流程的时延。
以上实施例二中,URLLC业务数据对应的高优先级调度指示通过显式或隐式方式携带在增强SR中,但高优先级调度指示可以并非携带在增强SR中,而是携带在BSR中。因此,本申请提供了以下通过BSR发送高优先级调度指示的实施例三。
实施例三
见图5,其示出了本申请提供的调度方法实施例三的流程,具体包括以下步骤S501~S505。
S501:终端在需要发送URLLC业务数据时,向基站发送SR。
其中,该SR可以如现有调度流程中的SR,只包含一个比特位,用于通知基站该终端有发送业务数据的需求。
S502:基站向终端返回UL Grant。
其中,该上行授权资源UL Grant以供终端上传BSR。
S503:终端向基站发送增强BSR,该增强BSR携带URLLC业务数据对应的高优先级调度指示。
其中,终端在确定发送URLLC业务数据时,为URLLC业务数据设置高优先级调度指示,并使用BSR携带该高优先级调度指示。具体地,增强BSR携带高优先级调度指示的方式可以是显式方式,如在BSR中增加比特位用于表示高优先级调度指示。其中,增强BSR是相比现有BSR,显式或隐式携带了更多的信息,增强BSR本质上还是一种BSR。
或者,增强BSR携带高优先级调度指示的方式也可以是隐式方式。具体地,BSR是通过物理上行共享信道(PhysicalUplink Shared Channel,PUSCH)发送到基站的,且发送BSR时BSR在PUSCH资源上具有位置信息。终端与基站可以预先约定高优先级的业务数据所对应的位置,终端在发送URLLC业务数据时,便可以在PUSCH资源的预先设定的位置上发送BSR,这样,基站接收到BSR后,根据BSR在PUSCH资源上的位置信息便可以确定该BSR携带高优先级调度指示。有关高优先级调度指示的说明可以参见上述实施例二的说明,此处并不再赘述。
S504:基站根据增强BSR携带的高优先级调度指示,使用快速分配方式为终端分配UL Grant。
其中,若增强BSR使用显式方式携带高优先级调度指示,则基站在接收到增强BSR后,可以检测增强BSR中是否包含优先级指示且该优先级指示为高的比特位。若检测到,则使用预设的快速分配方式为终端分配上行资源。有关快速分配方式的说明可以参见上述实施例二的说明,此处并不再赘述。
需要说明的是,基站可以根据高优先级调度指示快速地为终端分配上行授权资源,与实施例二不同的是,快速分配的上行授权资源为第二上行授权资源。在本实施例中,若使用实施例二中的第一种快速分配方式,可以简化现有调度流程中的步骤5的处理过程,若使用后三种快速分配方式中的任意一种,可以简化现有调度流程中的步骤4的处理过程。
S505:终端使用UL Grant上传待发送的业务数据。
其中,该业务数据为URLLC业务数据。
由以上技术方案可知,本实施例并无需在SR中新增信息,因此本实施例可以应用在PUCCH资源受限但对待发送业务数据的时延要求较高的场景中。
与实施例二相同的是,本实施例同样发送有待发送业务数据的高优先级调度指示,因此可以简化现有调度流程中的步骤4和/或5的处理过程(如图中的横线加粗步骤)。与实施例二不同的是,本实施例中的高优先级调度指示携带在BSR中,并非携带在SR中。
以上实施例一是在SR中携带BSR内的缓存状态信息,以节省步骤2及3;实施例二是通过SR发送高优先级调度指示,以指示基站快速下发第一上行授权资源,以简化步骤2和/或3的流程;实施例三是通过BSR发送高优先级调度指示,以指示基站快速下发第一上行授权资源,以简化步骤4和/或5的流程。这几个实施例的实现并不冲突,因此可以任意两种或三种结合实现,从而更大程度地缩短现有调度流程的时延。
实施例四
以上各个实施例是对现有调度流程中的步骤3~5进行改进,发明人研究后发现,还可以考虑对步骤1(发送SR)及步骤2(返回UL Grant)进行优化处理,基于该发明思想,本申请提供了以下实施例四。
见图6,其示出了本申请提供的调度方法实施例四的流程,具体包括以下步骤S601~S603。
S601:终端在需要发送URLLC业务数据时,使用预先配置的上行资源,向基站发送BSR。
其中,基站可以预先为URLLC业务数据分配一些上行授权资源,例如,基站在调度流程之前,为终端预先分配有上行授权资源,该些上行授权资源专供URLLC业务数据使用,因此,可以称为上行授权资源。在实施中,终端上还可能预先配置有上行共享资源,上行共享资源是供多种业务数据使用的,而非专供URLLC业务数据使用。终端可以竞争这些上行共享资源,竞争得到这些上行共享资源后,便可以使用上行共享资源发送BSR。
不论是预先配置的上行授权资源还是预先配置的上行共享资源,均可以称为预配上行资源(或预存上行资源)。
终端在需要发送URLLC业务数据时,在预配上行资源中选择一个,用来发送BSR即可。该种使用预配上行资源发送BSR的方式可以称为BSR增强方式。
终端能够实现上述功能,可以是基于基站的配置实现的。该配置方式可以参见基站对增强SR的配置过程,以下仅进行简单说明。
基站可以在调度流程之前的连接过程中,向终端发送RRC连接重配消息。RRC连接重新消息中可以包含增强指示信息,用于指示终端采用BSR增强方式发送BSR。
S602:基站根据BSR携带的缓存状态信息,为终端分配UL Grant。
其中,该UL Grant即用于发送业务数据的上行授权资源。
S603:终端使用UL Grant向基站发送业务数据。
其中,终端使用上行授权资源UL Grant,向基站发送URLLC业务数据。
由以上技术方案可知,现有的调度流程中,终端需要通过SR向基站申请UL Grant,本实施例中终端预存有上行资源,可直接从这些资源中随机选择一个来发送BSR,从而节省步骤1发送SR及步骤2返回UL Grant的步骤(图6所示画叉线的虚线步骤即省略步骤),缩短了调度流程的时延。
并且,相比在SR中增加比特位的增强方式,本实施例无需占用更多的PUCCH资源。具体来说,终端需要使用PUCCH资源发送SR,SR中包含的比特位越多,则需要使用的PUCCH资源也就越多。然而,在调度流程中,与基站通信的PUCCH资源是有限的,且可供多个终端使用。若单个终端占用的PUCCH资源越多,则与基站通信的终端个数越少。
需要说明的是,以上实施例四中,终端可以通过竞争使用上行资源的方式发送BSR,即若多个终端都需要发送BSR,则该多个终端竞争上行资源,这样若某终端发送URLLC业务数据,可能导致该终端的该BSR与其他终端发生竞争碰撞,URLLC业务数据对应的BSR发送成功率较低。因此,为了达到URLLC业务对数据可靠性的要求,可以使用预先配置的BSR重复发送模式进行发送,如图7所示,预置BSR重复发送模式是多次重复发送同一BSR的模式。
需要说明的是,重复发送同一BSR的模式可以并非仅结合实施例四使用,只要有BSR发送的实施例中均可以使用该模式,以减小信道衰落带来的影响,进而提高竞争发送方式中BSR的接收成功率。
具体的BSR发送模式可以包括但不限定于以下几种,在实际应用中,使用哪种发送模式可以由终端自身决定,也可以是由基站决定的,即基站在RRC连接重配消息中设置发送模式,终端接收到RRC连接重配消息中,根据其中包含的发送模式重复发送BSR。
1、双连接(Dual Connectivity,DC)模式。
其中,该模式类似频域资源的复用,是在终端与基站之间的多个连接中发送同一BSR,具体的连接个数可以包含在RRC连接重配消息中。
2、载波聚合(Carrier Aggregation,CA)模式。
其中,该模式类似频域资源的复用,是在多个载波中发送同一BSR,具体的载波个数可以包含在RRC连接重配消息中。
3、传输时间间隔-束(Transmission Time Interval-bundling,TTI-bundling)模式。
其中,该模式类似时域的复用,是在多个TTI-bundling上发送同一BSR,具体的TTI-bundling个数可以包含在RRC连接重配消息中。
4、多波束(Multi-beam)模式。
其中,该模式类似空域的复用,是在多个波束beam上发送同一BSR,具体的波束个数可以包含在RRC连接重配消息中。
需要说明的是,以上重复发送BSR的方式可以提高BSR的发送成功率,从而提高业务数据传输过程的可靠性。但是,发送次数越多,则终端及基站需要更多的时间来处理BSR,这样会导致调度流程时延的延长。因此,若想要实现时延与可靠性的平衡,需要根据实际应用需求选择合适的重复发送次数。合适的重复发送次数,可由终端或基站来选择,本申请并不做具体限定。
实施例五
以上实施例有些是对SR进行改进,有些是对BSR进行改进。例如,实施例一可以在SR中携带原BSR内的缓存状态信息,实施例二可以在SR中新增待发送业务的高优先级调度指示,实施例三可以在BSR中新增待发送业务的高优先级调度指示,实施例四是使用预先配置的上行资源发送BSR。
需要说明的是,SR的发送需要使用PUCCH资源,但该资源是专用资源且数量有限,即基站为每个终端分配各自的PUCCH资源,且分配的PUCCH资源是有限的。若某终端发送的SR中携带更多的信息,则会需要耗费更多的PUCCH资源,因此可能会因为PUCCH资源的有限性导致发送失败且时延较长。另一方面,基站为终端分配PUCCH资源与分配其他资源如上行授权之间存在矛盾,若始终为终端分配PUCCH资源,则可能会影响为终端分配其他资源,导致其他通信过程受影响。
发明人研究后发现,BSR的发送并不需要使用PUCCH资源,因此,可以在SR增强模式(第一调度模式)与BSR增强模式(第二调度模式)之间切换,以缓解SR对PUCCH资源的紧张需求。具体切换方式如下述实施例五所述。
在执行实施例五的调度流程之前,可以对终端进行功能设置,以使终端在执行调度流程时,可以在两种发送模式之间进行切换。
具体地,终端可以自身生成切换功能开启指令,并根据该指令开启切换功能。或者,终端的切换功能是由基站设置的,即基站在调度流程之前的连接过程中,可以向终端发送RRC连接重配消息,RRC连接重配消息中可以携带切换功能开启指令,该指令用于使终端开启切换功能。开启切换功能的终端可以实现以下实施例五中的发送模式切换。
见图8,其示出了本申请提供的增强调度方法实施例五的流程,具体包括以下步骤S801~805。
S801:终端开启切换功能后,持续检测终端是否需要发送URLLC业务数据。
其中,终端开启切换功能的时间点可以是在调度流程的之前、同时或之后。例如,终端在调度流程之前可以接收到RRC连接重配消息,接收到该RRC连接重配消息便开启切换功能;又如,终端检测到调度流程开始便同时开启切换功能;再如,终端在调度流程开始之后的某个时间点开启切换功能。其中,该时间点可以是由终端自身决定的,也可以是由基站决定的,如基站发送的RRC连接重配消息除了包括切换功能开启指令,还包括切换功能开启指令对应的时间点,从而终端在该时间点到达时,执行该切换功能开启指令,以使自身开启切换功能。
终端开启切换功能后,便可以生成检测指令。终端根据该检测指令,便可以执行以下调度流程。
在具有发送业务数据的需求时,首先判断该业务数据是否属于预设的低时延高可靠通信业务数据,若属于,则说明终端当前需要发送URLLC业务数据,若不属于,则说明终端当前并没有URLLC业务数据需要发送。
S802:若需要发送URLLC业务数据,则终端启用SR增强模式,以按照SR增强模式执行调度流程。其中,SR增强模式中终端向基站发送的SR为增强SR。
若业务数据为URLLC业务数据,则终端需要生成增强SR,并向基站发送增强SR。增强SR相较于现有SR而言,除了包含发送业务数据的指示信息外,还包含更多的信息。更多的信息可以称为新增信息,可以包括但不局限于以下任意一种或多种的组合:原BSR内携带的缓存状态信息、高优先级调度指示、业务数据的类型(即上述业务源)。
需要说明的是,终端启用SR增强模式,便表示终端可以按照SR增强模式执行调度流程。具体地,增强SR内包含的信息不同,SR增强模式的具体执行过程也不同。若终端发送的增强SR包含原BSR中的缓存状态信息,则执行实施例一的调度流程。若终端发送的增强SR包含高优先级调度指示或业务数据的类型(即上述业务源),则执行实施例二的调度流程。
终端使用PUCCH资源将增强SR发送至基站,且使用的PUCCH资源比现有发送SR使用的要多,因此适合应用在PUCCH资源充分的场景中。
S803:终端统计SR增强模式的持续时长,若持续时长达到预设时长,则终端切换为BSR增强模式,以按照BSR增强模式执行调度流程。其中,BSR增强模式中终端并未向基站发送SR。
上述步骤S802切换为SR增强模式后,终端需要统计SR增强模式的持续时长。需要说明的是,本实施例在实际应用中,可能多次在BSR增强模式与SR增强模式之间进行切换,本步骤中统计的持续时长并非SR增强模式的总时长,而是统计每次进入SR增强模式后的时长。也就是说,每次步骤S802切换为SR增强模式后,便将统计的持续时长清零。
统计SR增强模式持续时长的具体实现方式可以是,通过计时器计时或统计SR发送周期。例如,基站向终端发送的RRC连接重配消息中包含计时器(如SR增强周期定时器,SREnhancementCycleTimer)及SR发送周期,终端是按照该SR发送周期不断地发送增强SR。终端切换为SR增强模式后,启动计时器计时或者统计SR发送周期的个数,从而实现计时。
若统计的SR增强模式持续时长达到预设时长(第一预设时长),则终端切换为BSR增强模式。终端可以按照BSR增强模式执行调度流程,重要的是,该发送模式中终端并未向基站发送SR,从而节省PUCCH资源的使用,BSR增强模式可以为上述实施例四过程。
S804:启用SR增强模式的情况下,若不需要发送URLLC业务数据,则统计不需要发送URLLC业务数据的持续时长,且在持续时长达到预设时长后,终端禁用SR增强模式。
其中,为了便于区分,可以将步骤S803中统计的持续时长称为第一持续时长,用来比较的预设时长称为第一预设时长,本步骤中统计的持续时长称为第二持续时长,用来比较的预设时长称为第二预设时长。第一预设时长及第二预设时长的值可以相同,也可以不同,本申请并不做具体限定。
统计第二持续时长的方式可以同统计第一持续时长的方式相同,如通过计时器计时或统计SR发送周期。具体说明可以参见第一持续时长的说明,此处并不赘述。
终端在SR增强模式的情况下,若终端长时间不需要发送URLLC业务数据,则可以禁用该SR增强模式,以节省PUCCH资源的使用。
S805:终端在禁用SR增强模式的情况下,若检测到需要发送URLLC业务数据,则启用SR增强模式,以按照SR增强模式执行调度流程。
若在禁用SR增强模式的情况下,终端检测到需要发送URLLC业务数据时,可以临时执行BSR增强模式,BSR增强模式如上所述,并未向基站发送SR,从而节省PUCCH资源的使用。在禁用SR增强模式的情况下,终端检测到需要发送URLLC业务数据时,还可以重新启动SR增强模式,以按照SR增强模式执行调度流程。
由以上技术方案可以看出,终端在SR增强模式持续一定时长后切换为BSR增强模式,以减少对PUCCH资源的使用;终端在一段时长内无URLLC业务数据发送时,可以禁用SR增强模式,且在有URLLC业务数据发送时,重启SR增强模式。SR增强模式需要使用较多的PUCCH资源,切换为BSR增强模式或关闭SR增强模式,从而节省PUCCH资源。
需要说明的是,以上各个实施例中,是从业务数据的角度来说明增强调度流程,例如,确定执行增强调度流程的条件是具有待发送的URLLC业务的业务数据。这样,可以保证在发送某一种业务数据如URLLC业务的业务数据时,可以执行增强调度流程,以缩短该种业务数据对应的调度时延。
但是,本申请还可以从逻辑信道的角度来执行增强调度流程,例如,确定执行增强调度流程的条件是某个逻辑信道上具有待发送的业务数据,以使该逻辑信道可以区别于其他逻辑信道,执行增强调度流程,以缩短该逻辑信道对应的调度时延。在以逻辑信道的角度说明本申请的技术方案时,所有与URLLC业务对应的设定,均转换为与目标逻辑信道对应的设定。例如,高优先级调度指示并不是与URLLC业务的业务数据对应的指示,而是与目标逻辑信道对应的指示等等。
为了便于描述,该逻辑信道可以称为目标逻辑信道。目标逻辑信道上可以发送URLLC业务的业务数据,当然,也可以发送其他类型的业务数据。另外,本申请并不限定终端上的目标逻辑信道为哪个逻辑信道,目标逻辑信道可以是由基站指定的逻辑信道。
需要说明的是,基站除了可以为终端指定目标逻辑信道,还可以为终端指定使用哪种增强调度方法。对此,本申请提供了一种调度配置方法。如图9所示,该调度配置方法可以包括步骤S901~S903。
S901:基站确定使用预设调度模式的逻辑信道。其中,预设调度模式为以下三种中的任意一种:第一调度模式、第二调度模式、在第一调度模式与第二调度模式之间进行转换的模式。
第一调度模式为终端向基站发送增强调度请求的调度模式,也即基站接收终端发送的调度请求的调度模式,所述增强调度请求携带以下几项中的任意一项或多项:高优先级调度指示、缓存状态信息、所述业务数据的类型。在第一调度模式包含缓存状态信息的情况下为实施例一的增强调度方法,在第一调度模式包含高优先级调度指示或业务数据的类型的情况下,第一调度模式为实施例二的增强调度方法。
第二调度模式为终端使用预先存储的上行资源向基站发送缓存状态报告的调度模式,即上述实施例四的增强调度方法,也即基站接收终端使用预先存储的上行资源发送缓存状态报告的调度模式。
在第一调度模式与第二调度模式之间进行转换的模式即上述实施例五的增强调度方法。
S902:基站将预设调度模式的标识及逻辑信道的标识向终端发送。
其中,基站可以将预设调度模式的标识及逻辑信道的标识包含在逻辑信道连接重配消息、物理下行控制信道资源或媒体接入控制单元中,并向终端发送。当然,基站还可以将预设调度模式的标识及逻辑信道的标识包含在现有的其他消息或资源中发送给终端,或者,基站可以直接将预设调度模式的标识及逻辑信道的标识给终端。
S903:终端将逻辑信道的标识对应的逻辑信道确定为目标逻辑信道,并将预设调度模式的标识对应的调度模式确定为目标调度模式。
其中,终端可以根据基站发送预设调度模式的标识及逻辑信道的标识的方式,获取到该两个标识。进而,终端将逻辑信道的标识所指示的逻辑信道确定为目标逻辑信道,并将预设调度模式的标识对应的调度模式确定为目标调度模式,以执行目标调度模式对应的增强调度方法。
本申请提供的调度配置方法中,基站可以对终端进行配置,以使终端可以实现按照确定出的调度模式对应的调度方法。
另外,本申请还提供的一种终端,包括:处理模块、发送模块及接收模块。
处理模块,用于确定目标逻辑信道上是否具有待发送的业务数据;
发送模块,用于若所述处理模块确定所述目标逻辑信道上具有待发送的业务数据,则向基站发送调度指示;其中,所述目标逻辑信道是由基站指定的逻辑信道,所述调度指示用于指示所述基站按照预设的分配方式为所述目标逻辑信道分配上行授权资源;
接收模块,用于接收所述基站返回的上行授权资源。
在一种实现方式中,在执行向基站发送调度指示的步骤时,所述发送模块具体用于:向基站发送调度请求,其中所述调度请求使用比特位携带所述调度指示。
在一种实现方式中,在执行向基站发送调度指示的步骤时,所述发送模块具体用于:按照预设的调度请求发送周期,向基站发送调度请求;其中所述预设的调度请求发送周期小于所述目标逻辑信道之外的其他逻辑信道的调度请求发送周期。
在一种实现方式中,在执行向基站发送调度指示的步骤时,所述发送模块具体用于:向基站发送缓存状态报告,其中所述缓存状态报告使用比特位携带调度指示。
在一种实现方式中,在执行向基站发送调度指示的步骤时,所述发送模块具体用于:在物理上行共享信道的预设位置上,向基站发送缓存状态报告。
本申请还提供了一种终端,包括:处理模块、发送模块及接收模块。
处理模块,用于若目标逻辑信道上具有待发送的业务数据,则生成调度请求,其中所述目标逻辑信道是由基站指定的逻辑信道,所述调度请求包含缓存状态信息;
发送模块,用于向基站发送所述调度请求,其中所述调度请求中的所述缓存状态信息用于基站分配上行授权资源;
接收模块,用于接收所述基站返回的上行授权资源。
在一种实现方式中,缓存状态信息包括数据量指示信息,所述数据量指示信息包括:
所述业务数据的数据量数值,或所述业务数据的数据量索引;其中所述数据量索引用于指示业务数据的数据量范围。
本申请还提供了一种终端,包括:处理模块、发送模块及接收模块。
处理模块,用于确定目标逻辑信道上是否具有待发送的业务数据;
发送模块,用于若所述处理模块确定所述目标逻辑信道上具有待发送的业务数据,则使用预先配置的上行资源向基站发送缓存状态报告;其中,所述目标逻辑信道为基站指定的逻辑信道,所述缓存状态报告用于所述基站为所述目标逻辑信道分配上行授权资源;
接收模块,用于接收所述基站返回的上行授权资源。
在一种实现方式中,执行使用预先配置的上行资源向基站发送缓存状态报告的步骤时,所述发送模块具体用于:使用预先配置的上行资源多次向基站发送同一缓存状态报告。
本申请还提供了一种终端,包括:接收模块及处理模块。
接收模块,用于接收检测指令;
处理模块,用于在所述接收模块接收到所述检测指令后,持续检测所述终端的目标逻辑信道上是否具有待发送的业务数据;其中,所述目标逻辑信道为基站指定的逻辑信道;
所述处理模块还用于若所述目标逻辑信道上具有待发送的业务数据,则启用预设的第一调度模式;其中,所述第一调度模式为发送调度请求的调度模式,所述调度请求携带以下几项中的任意一项或多项:调度指示、缓存状态信息、所述业务数据的类型;
所述处理模块还用于若所述第一调度模式的启用时长达到第一预设时长,则将所述第一调度模式切换为预设的第二调度模式;其中,所述第二调度模式为使用预先存储的上行资源向基站发送缓存状态报告的调度模式。
在一种实现方式中,上述处理模块还用于在启用所述第一调度模式后,若所述目标逻辑信道上不再具有待发送的业务数据、且不具有所述业务数据的持续时长达到第二预设时长,则禁用所述第一调度模式。
在一种实现方式中,上述处理模块还用于在禁用所述第一调度模式后,若检测到所述目标逻辑信道上具有待发送的业务数据,则启用所述第一调度模式。
本申请还提供了一种基站,包括:接收模块、处理模块及发送模块。
接收模块,用于接收终端发送的调度指示;其中所述调度指示是所述终端的目标逻辑信道上具有待发送的业务数据时发送的,所述目标逻辑信道为所述基站指定的逻辑信道;
处理模块,用于按照预设的分配方式为所述目标逻辑信道分配上行授权资源;
发送模块,用于向所述终端发送所述上行授权资源。
在一种实现方式中,执行按照预设的分配方式为所述目标逻辑信道分配上行授权资源的步骤时,所述处理模块具体用于:为所述目标逻辑信道单独分配上行授权资源。
在一种实现方式中,执行按照预设的分配方式为所述目标逻辑信道分配上行授权资源的步骤时,所述处理模块具体用于:在预设的短时间间隔后,为所述目标逻辑信道分配上行授权资源;其中,所述短时间间隔表示所述目标逻辑信道获得上行授权资源的时间间隔比其他逻辑信道的时间间隔短。
在一种实现方式中,执行按照预设的分配方式为所述目标逻辑信道分配上行授权资源的步骤时,所述处理模块具体用于:在接收到多个逻辑信道对应的上行授权资源分配请求下,优先为所述目标逻辑信道分配上行授权资源。
在一种实现方式中,执行按照预设的分配方式为所述目标逻辑信道分配上行授权资源的步骤时,所述处理模块具体用于:依据所述目标逻辑信道上的业务数据的数据量,为所述目标逻辑信道分配比所述数据量更多的上行授权资源。
本申请还提供了一种基站,包括:处理模块及发送模块。
处理模块,用于确定使用预设调度模式的逻辑信道;
发送模块,用于向终端发送所述预设调度模式的标识及所述逻辑信道的标识;
其中,所述预设调度模式为以下三种中的任意一种:第一调度模式、第二调度模式、在第一调度模式与第二调度模式之间进行转换的模式;所述第一调度模式为基站接收终端发送的调度请求的调度模式,所述调度请求携带以下几项中的任意一项或多项:调度指示、缓存状态信息、所述业务数据的类型;所述第二调度模式为接站接收终端使用预先存储的上行资源发送缓存状态报告的调度模式。
在一种实现方式中,执行向终端发送所述预设调度模式的标识及所述逻辑信道的标识的步骤时,所述发送模块具体用于:向终端发送逻辑信道连接重配消息,其中,所述逻辑信道连接重配消息包含所述预设调度模式的标识及所述逻辑信道的标识。
在一种实现方式中,执行向终端发送所述预设调度模式的标识及所述逻辑信道的标识的步骤时,所述发送模块具体用于:向终端发送物理下行控制信道资源,其中,所述物理下行控制信道资源包含所述预设调度模式的标识及所述逻辑信道的标识。
在一种实现方式中,执行向终端发送所述预设调度模式的标识及所述逻辑信道的标识的步骤时,所述发送模块具体用于:向终端发送媒体接入控制单元,其中,所述媒体接入控制单元包含所述预设调度模式的标识及所述逻辑信道的标识。
本申请还提供了一种终端,包括:接收模块及处理模块。
接收模块,用于接收基站发送的预设调度模式的标识及逻辑信道的标识;其中,所述预设调度模式为以下三种中的任意一种:第一调度模式、第二调度模式、在第一调度模式与第二调度模式之间进行转换的模式;所述第一调度模式为终端向基站发送调度请求的调度模式,所述调度请求携带以下几项中的任意一项或多项:调度指示、缓存状态信息、所述业务数据的类型;所述第二调度模式为终端使用预先存储的上行资源向基站发送缓存状态报告的调度模式;
处理模块,用于将所述逻辑信道的标识对应的逻辑信道确定为目标逻辑信道,并将所述预设调度模式的标识对应的调度模式确定为所述终端使用的调度模式。
见图10,其示出了终端的一种可能的结构示意,包括:
控制器/处理器1001、存储器1002、通信接口1003、输入设备1004和输出设备1005。处理器1001、存储器1002、通信接口1003、输入设备1004和输出设备1005相互连接。
控制器/处理器1001可以是通用处理器,例如通用中央处理器(CPU)、网络处理器(Network Processor,NP)、微处理器等,也可以是特定应用集成电路(application-specific integrated circuit,ASIC),或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。控制器/处理器1101也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。具体地:
终端的控制器/处理器1001可以实现上述终端中处理模块的功能,用于执行上述应用在终端上的调度方法和/或用于本申请所描述的技术的其他过程。
存储器1002中保存有执行本申请技术方案的程序,还可以保存有操作系统和其他应用程序。具体地,程序可以包括程序代码,程序代码包括计算机操作指令。更具体的,存储器1002可以是只读存储器(read-only memory,ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory,RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器等等。
通信接口1003可以实现上述终端中发送模块和接收模块的功能。所述通信接口1003包括使用任何收发器一类的装置,以便与其他设备或通信网络通信,如以太网,无线接入网(RAN),无线局域网(WLAN)等。
终端的通信接口1003可以向基站发送的调度指示、调度请求、缓存状态报告等信息,并将接收到的信息发送给控制器/处理器,由控制器/处理器执行上述应用在终端上的调度方法。或者,终端的通信接口1003可以接收基站返回的上行授权资源等。
输入设备1004可包括接收用户输入的数据和信息的装置,例如键盘、光笔、语音输入装置、触摸屏等。
输出设备1005可包括允许输出信息给用户的装置,例如显示屏、扬声器等。
见图11,其示出了基站的一种可能的结构示意,包括:
控制器/处理器1101、存储器1102及通信接口1103。处理器1101、存储器1102、及通信接口1103相互连接。
控制器/处理器1101可以是通用处理器,例如通用中央处理器(CPU)、网络处理器(Network Processor,NP)、微处理器等,也可以是特定应用集成电路(application-specific integrated circuit,ASIC),或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。控制器/处理器1101也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。具体地:
基站的控制器/处理器1101可以实现上述基站中处理模块的功能,用于执行上述应用在基站上的调度方法和/或用于本申请所描述的技术的其他过程。
存储器1102中保存有执行本申请技术方案的程序,还可以保存有操作系统和其他应用程序。具体地,程序可以包括程序代码,程序代码包括计算机操作指令。更具体的,存储器1102可以是只读存储器(read-only memory,ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory,RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器等等。
通信接口1103可以实现上述基站中发送模块和接收模块的功能。所述通信接口1103包括使用任何收发器一类的装置,以便与其他设备或通信网络通信,如以太网,无线接入网(RAN),无线局域网(WLAN)等。
基站的通信接口1103可以接收终端发送的调度指示、调度请求、缓存状态报告等信息,并将接收到的信息发送给控制器/处理器,由控制器/处理器执行上述应用在基站上的调度方法。基站的通信接口1103还可以向终端发送上行授权资源等。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括上述要素的过程、方法、物品或者设备中还存在另外的相同要素。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。