基带资源池中的上行信道数据处理方法

文档序号:7820828阅读:339来源:国知局
基带资源池中的上行信道数据处理方法
【专利摘要】本申请公开了一种基带资源池中的上行信道数据处理方法,包括:a、预先在基带处理入口前设置入口缓冲区;b、将经过前端处理后的上行信道接收数据顺序存入所述入口缓冲区,待入口缓冲区存满后,按照当前入口缓冲区中数据存入的先后顺序,将新数据依次覆盖当前入口缓冲区中的数据;基带资源池按照各数据存入所述入口缓冲区的先后顺序,依次提取入口缓冲区中保存的数据进行基带处理。应用本申请,能够在基带资源池架构中出现上行信道超时拥塞时保证上行信道数据传输的实时性要求。
【专利说明】基带资源池中的上行信道数据处理方法

【技术领域】
[0001]本申请涉及无线通信技术,特别涉及基带资源池中的上行信道数据处理方法。

【背景技术】
[0002]传统的接入网络架构中基带信号处理通常在满足实时性需求的前提下,在专用处理器上采用固定的算法方案实现,所消耗的资源固定,方案的实时性能也是确定的。然而基站资源池平台架构通常采用通用处理器,由操作系统对多项处理任务进行调度,其中物理层处理的实时性较传统平台难以得到保障,不确定性也会增加,因而不可避免地会遇到超时拥塞问题:处理器调度其他任务导致物理层基带处理的计算任务停滞时间过长,超过了实时性所能容许的时限,使得后续业务数据处理发生拥塞。传统基带处理过程中几乎不存在这一问题,所以缺乏这一问题的应对方案。
[0003]具体地,传统的通信设备往往是一家厂商提供一整套解决方案,系统维护或者升级依赖性高。而随着近几年能源资源紧张,全球移动通信网络运营商面临日渐严重的成本压力。大多数主流运营商通常拥有多个不同通信制式的网络,为保证网络的服务质量,需要部署大量的基站以解决网络覆盖的问题。但站址和机房资源的相对稀缺,与大量基站部署的需求形成难以协调的矛盾。而由于移动通信市场的激烈竞争,单用户平均收入增长缓慢甚至下降,运营商的“盈利”能力并不随之提高,这将导致建网和设备采购投资的压缩。出于行业持续盈利和长期发展考虑,移动通信产业界提出通过改变接入网络架构解决这个问题。
[0004]新型基站系统架构如图1所示,所有基带处理单元¢£186)32111(1 1)1111:,8811)和远端无线射频单元0611101:6 1)1111:,册!!)通过高带宽、低延迟的光传输网络连接起来。基带处理单元集中在一个物理站点构成基带池。基带池中多个基带处理单元之间通过高带宽、低延迟、灵活拓扑、低成本交叉连接。基带资源池需要应用基站虚拟化技术,在基带池中多基站共享计算资源,而计算资源的分配由系统根据业务量统一动态调度。而无线信号处理算法构成了无线通信系统物理层核心处理,具有计算密集的特点,并且面临严苛的实时性要求。为保证基站集中处理的实时性、减少系统能耗,使虚拟化技术能够最大限度发挥硬件系统性能,以支撑高速运行的通信系统基带数据处理,需要对基带信号处理的计算任务进行划分并封装起来,将封装后的计算任务进行集中处理。封装方案可根据基站资源池的资源使用情况进行调整,以适应多核通用处理器上动态任务分配并满足系统实时要求。
[0005]不同于传统基站,基站资源池聚集了大量的计算资源可容纳多小区多用户数据同时处理,无线通信系统物理层信号处理的实时性要求较高,以口2系统为例,下行信道每11118向用户发送一个子帧的数据,上行信道每11118接收一个子帧的数据。由于资源池平台架构通常采用通用处理器,由操作系统同时对多个处理任务进行调度,因此资源池中物理层处理会不可避免地遇到下述问题:处理器调度导致物理层基带处理的计算任务停滞时间过长,超过了规定时限,使得后续业务数据发生拥塞,如图2所示。本申请中将该问题称为“超时拥塞”。
[0006]图2中,处理器在处理信道八计算任务的过程中调度了其他的处理计算任务导致信道八计算任务发生停滞,如果该信道为上行信道,由于接收前端处理的实时性强,可能使到达的数据无法得到及时处理发生堵塞,如果该信道为下行信道,由于发送前端处理的实时性要求高,可能导致数据无法及时输送到前端。
[0007]这一问题在传统的基带处理单元(8冊)所采用的专用处理器上几乎不会出现,但在通用平台上操作系统介入对实时处理任务进行调度处理,处理超时拥塞导致实时性难以保障的问题就会凸显。而目前许多处理拥塞的技术,往往针对网络分组拥塞问题,相应的解决方案并不能直接应用于本申请中来解决超时拥塞的问题。


【发明内容】

[0008]本申请提供了基带资源池中的上行信道数据处理方法,能够在基带资源池架构中出现超时拥塞时保证数据传输的实时性要求。
[0009]为解决上述问题,本申请采用如下的技术方案:
[0010]一种基带资源池中的上行信道数据处理方法,包括:
[0011]1预先在基带处理入口前设置入口缓冲区;
[0012]以将经过前端处理后的上行信道接收数据顺序存入所述入口缓冲区,待入口缓冲区存满后,按照当前入口缓冲区中数据存入的先后顺序,将新数据依次覆盖当前入口缓冲区中的数据;基带资源池按照各数据存入所述入口缓冲区的先后顺序,读取入口缓冲区中保存的数据进行基带处理。
[0013]较佳地,所述入口缓冲区为一循环缓冲区,数据从缓冲区的初始位置输入,每输入一个新数据,输入位置向后移动一位;当前输入位置上已保存有数据时,利用输入的新数据覆盖当前保存的数据。
[0014]较佳地,所述基带资源池按照设定的时间间隔读取入口缓冲区中保存的数据;
[0015]在发生超时拥塞后,停止读取所述入口缓冲区中保存的数据,并在所述超时拥塞结束后,丢弃所述入口缓冲区中从停止位置开始的~个数据,并继续读取所述入口缓冲区中的剩余数据;
[0016]其中,~为上行超时拥塞度,^的取值为发生超时拥塞后按照所述时间间隔未从所述入口缓冲区中读取的数据块数。
[0017]较佳地,根据所述上行信道接收数据的到达速率和基带处理时间确定所述入口缓冲区的大小。
[0018]由上述技术方案可见,本申请中给出一种上行信道数据处理方法,在基带处理入口处设置入口缓冲区,入口缓冲区满后,利用新数据依次覆盖已存数据,从而保障上行数据接收的实时性要求。

【专利附图】

【附图说明】
[0019]图1为新型基站系统架构的不意图;
[0020]图2为超时拥塞的示意图;
[0021]图3为针对上行信道的数据处理方法流程示意图;
[0022]图4为上行信道接收数据和入口缓冲区位置的示意图;
[0023]图5为上行信道超时拥塞过程中入口缓冲区的读取示例;
[0024]图6为循环缓冲区的形式示意图。

【具体实施方式】
[0025]为了使本申请的目的、技术手段和优点更加清楚明白,以下结合附图对本申请做进一步详细说明。
[0026]本申请旨在设计基站资源池中的数据处理方法,以应对物理层的超时拥塞,保障物理层基带信号处理过程的实时性。基站资源池物理层信号处理由多个信道组成,包括上行和下行信道。上行信道从空中接口接收用户终端的信号经过一定的处理后传送至基带处理,这一上行传输过程在接收端可能有较为严格的实时性要求;而下行信道将基站信号经基带处理后进行一定的处理、通过空中接口发送至用户终端,这一传输过程在发送端可能有较为严格的实时性要求。如果在下行信道处理过程中发生超时拥塞,可能导致基站作为发送端的数据无法及时发送,如果在上行信道处理过程中发生超时拥塞,可能导致基站作为接收端的数据无法得到及时处理,两种情况都会影响基带资源池物理层处理的实时性。
[0027]针对上述在上行信道发生超时拥塞后可能影响实时性的情况,本申请给出相应的数据处理方法,以避免对物理层处理的实时性影响。
[0028]具体地,对应于基站作为上行信道接收端的情况,本申请给出图3所示的上行信道数据处理方法。其中,当上行信道的接收实时性要求较高时(例如,上行信道的接收实时性要求大于设定的阈值时),采用本处理方法,具体可以在线下预先确定实时性要求,从而确定在基带处理时是否需要采用本处理方法,在基带处理的入口处进行超时拥塞控制的处理。如图3所示,该流程包括:
[0029]步骤301,预先在基带处理入口前设置入口缓冲区。
[0030]对于上行信道,由于从空中接口接收用户终端数据,如图4所示,在基带处理入口需要进行实时性保障操作。基于此,本处理方法中,在基带处理的入口处进行超时拥塞处理,首先,需要在基带处理入口前设置入口缓冲区,对前端处理后的数据进行缓冲。入口缓冲区可划分为I个缓冲块,每个缓冲块存储一个进入基带处理的数据块。入口缓冲区大小的设置应考虑数据到达速率、基带处理时间、超时拥塞等因素。如果缓冲区设置过大,会浪费存储空间,且发生长时的超时拥塞时,累积过多的过期未处理数据。如果缓冲区设置过小,缓冲余地小,发生超时拥塞时,覆盖过多的未处理数据。
[0031〕 步骤302,将经过前端处理后的上行信道接收数据顺序存入所述入口缓冲区,待入口缓冲区存满后,按照当前入口缓冲区中数据存入的先后顺序,将新数据依次覆盖当前入口缓冲区中的数据。
[0032]本步骤进行入口缓冲区的写操作。经前端处理的数据首先进入缓冲区等待基带处理,并且将进入缓冲区的数据顺序存储,当入口缓冲区存满后,后续的数据仍然需要依次写入入口缓冲区,覆盖已经保存的数据,在覆盖原有数据时,按照原有数据存入缓冲区的先后顺序,进行依次覆盖。通过上述处理,在发生超时拥塞时,入口缓冲区中保存的没有及时进行基带处理的数据会被新数据覆盖,这样,能够保证经过前端处理的数据及时进入入口缓冲区,以准备进行基带处理,保证接收实时性要求。
[0033]步骤303,基带资源池按照各数据存入入口缓冲区的先后顺序,提取入口缓冲区中保存的数据进行基带处理。优选地,当超时拥塞发生后,可以根据上行超时拥塞度调整读取位置,抛弃过期数据。
[0034]本步骤进行入口缓冲区的读操作。具体地,在读取入口缓冲区中的数据时,可以采用阻塞模式进行处理,按照数据存入的先后顺序依次读取,只有前面的数据读出并被处理之后才能进行下一块存储块数据的读取。若前面的数据发生超时拥塞,缓冲区的数据不会被读取,但此时为保证接收端实时性要求,通过步骤302的操作,仍然将从空中接口收到的数据写入入口缓冲区,如果超时拥塞时间过长,可能导致前面已经存储在入口缓冲区但是未进入基带处理的数据被覆盖。
[0035]另外,优选地,为保证超时拥塞导致的过期数据不被上行信道处理,还可以估计上行超时拥塞度以调整缓冲区的读取位置,丢弃过期数据。其中,上行超时拥塞度可以由超时拥塞导致的过期数据量来进行衡量。具体地,入口缓冲区中数据的读取应按某时间间隔进行(具体该时间间隔的设定可以根据实际系统需要选择),当读取位置在某数据块上停留的时间超过该时间间隔,则判定为上行信道发生了超时拥塞,这时,设置虚拟读取指针仍按该时间间隔指向该读取的数据,但并不将该数据从入口缓冲区中读出;当超时拥塞结束后,将实际读取指针的位置调整至虚拟读取指针位置,从入口缓冲区中读取实际读取指针指向的数据继续输出,中间跨越的数据块数目即为上行超时拥塞度,这些数据块均为过期数据,应予抛弃。这种丢弃过期数据的处理,虽然没有严格地将入口缓冲区中的所有数据读取出来进行基带处理,但是就读取出的进行基带处理的数据而言,其读取顺序依然是按照存入入口缓冲区的顺序进行的,只是将其中已经过期的数据丢弃不再读取。
[0036]图5给出了上行信道超时拥塞过程中入口缓冲区的读取示例。写指针将到达的数据块写入缓冲区,实际读取指针读取第1块数据,即将读取第2块。实际读取指针应以I为时间间隔移动,此时发生超时拥塞,实际读取指针停留在第2块开头。设置虚拟读取指针仍以丁为时间间隔移动。假定超时拥塞结束时,虚拟读取指针移动到第4块开头,则将实际读取指针位置调整到虚拟读取指针的位置进行数据块读取,抛弃第2、3块过期数据。
[0037]至此,图3所示的流程结束。在上述流程中,步骤302和303中对于入口缓冲区的读写操作分别独立进行,在处理时间上也可能相互穿插,没有固定的先后执行顺序。
[0038]另外,针对上述入口缓冲区的读写特点,在实际应用中,可以采用循环缓冲区的形式(例如循环队列)设计缓冲区,如图6所示,图中数字表示位置序号,1为队头位置,I为缓冲区尾部,也代表缓冲区最大容量。将前端处理的数据从初始位置写入入口缓冲区,每有一个新的数据要输入缓冲区,写入位置向后移动一位;当数据从缓冲区初始位置放置到尾部时,后续数据则重新回到初始位置放置以循环使用缓冲区。在写入新的数据时,若当前写入位置有已存数据,说明缓冲区已满,利用新数据覆盖当前写入位置上的已存数据。在从入口缓冲区读取数据时,读取当前缓冲区中最早存入的数据,然后,依次读取其后缓冲块上的数据。
[0039]通过上述图3所示的数据处理方法,在基带处理前进行入口缓冲的处理,从而能够保证在上行信道数据接收的实时性要求,当出现超时拥塞时,能够及时删除未处理的数据,及时对超时拥塞后到达的数据进行基带处理。
[0040]以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。
【权利要求】
1.一种基带资源池中的上行信道数据处理方法,其特征在于,包括: a、预先在基带处理入口前设置入口缓冲区; b、将经过前端处理后的上行信道接收数据顺序存入所述入口缓冲区,待入口缓冲区存满后,按照当前入口缓冲区中数据存入的先后顺序,将新数据依次覆盖当前入口缓冲区中的数据;基带资源池按照各数据存入所述入口缓冲区的先后顺序,读取入口缓冲区中保存的数据进行基带处理。
2.根据权利要求1所述的方法,其特征在于,所述入口缓冲区为一循环缓冲区,数据从缓冲区的初始位置输入,每输入一个新数据,输入位置向后移动一位;当前输入位置上已保存有数据时,利用输入的新数据覆盖当前保存的数据。
3.根据权利要求1所述的方法,其特征在于,所述基带资源池按照设定的时间间隔读取入口缓冲区中保存的数据; 在发生超时拥塞后,停止读取所述入口缓冲区中保存的数据,并在所述超时拥塞结束后,丢弃所述入口缓冲区中从停止位置开始的N个数据,并继续读取所述入口缓冲区中的剩余数据; 其中,N为上行超时拥塞度,N的取值为发生超时拥塞后按照所述时间间隔未从所述入口缓冲区中读取的数据块数。
4.根据权利要求1、2或3所述的方法,其特征在于,根据所述上行信道接收数据的到达速率和基带处理时间确定所述入口缓冲区的大小。
【文档编号】H04L12/861GK104410583SQ201410691190
【公开日】2015年3月11日 申请日期:2014年11月26日 优先权日:2014年11月26日
【发明者】漆渊, 钱荣荣, 彭涛, 王文博 申请人:北京邮电大学
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1