CN101883402A - 一种协同传输数据的方法及*** - Google Patents
一种协同传输数据的方法及*** Download PDFInfo
- Publication number
- CN101883402A CN101883402A CN2009101070725A CN200910107072A CN101883402A CN 101883402 A CN101883402 A CN 101883402A CN 2009101070725 A CN2009101070725 A CN 2009101070725A CN 200910107072 A CN200910107072 A CN 200910107072A CN 101883402 A CN101883402 A CN 101883402A
- Authority
- CN
- China
- Prior art keywords
- collaborative
- user
- cooperative
- serving
- base station
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B17/00—Monitoring; Testing
- H04B17/30—Monitoring; Testing of propagation channels
- H04B17/309—Measuring or estimating channel quality parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B17/00—Monitoring; Testing
- H04B17/20—Monitoring; Testing of receivers
- H04B17/24—Monitoring; Testing of receivers with feedback of measurements to the transmitter
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Electromagnetism (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种协同传输数据的方法及***。本发明方案中,服务基站根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,若有,则服务基站组建协同组,业务网关根据服务基站上传的信息,将下行业务数据通过S1接口下发给所述协同组成员,协同组成员将获得的下行业务数据通过X2接口下发给所述协同用户;解决了协同传输中的下行业务数据问题,使服务基站以及各协同基站能获得协同用户的下行业务数据,从而能对协同用户进行协同传输,同时,满足联合处理方式的下行数据分配要求,对接入网侧增加额外处理,或者,增强网关能力,而且不会对非协同用户的业务分配造成任何影响。
Description
技术领域
本发明涉及通信领域,具体地,涉及一种协同传输数据的方法及***。
背景技术
随着LTE-A(Long-Term Evolution Advanced,简称为LTE-A)需求的提出,人们对小区平均频谱效率和小区边缘频谱效率越来越重视,相比较而言,小区边缘的频谱效率最受人们关注,这主要是因为LTE-A***的上下行都是以OFDM(Orthogonal Frequency Division Multiplexing,简称为OFDM)(或者以OFDM的某种变形)为基本多址复用方式的频分***,与传统的以CDMA(Code-Division Multiple Access,简称为CDMA)为基本多址复用方式的无线通信***不同,LTE-A***没有处理增益,小区内部因为完全频分正交,所以几乎没有干扰问题,但在小区边缘处的干扰处理相对棘手。小区边缘用户距离多个相邻小区的天线距离相差不大,最易受到干扰而影响性能。若能够利用多个小区的不同天线为小区边缘的用户同时提供服务,则不但避免了小区间的干扰,还能充分发挥多天线增加空间维的信息,使得***的容量和性能得到大幅提升。
协同多点传输正是在这个背景下所提出的。协同多点传输使用多个小区的不同天线为小区边缘的用户同时提供服务,这样不但避免了小区间的干扰,同时由于采用多天线技术,能充分发挥多天线增加空间维的信息,使得***的容量和性能得到大幅度的提升。当然协同多点传输也不局限于小区间,在小区内同样可以使用,由于用户信息的发射在空间上分散为多个传输点,这些传输点又互相配合,即能实现对功率,频率和空间资源的最佳配置,从而既能实现对干扰的抑制,又能实现可靠和高容量的链路性能。
协同多点传输中,通常由若干个节点构成一个协同组,共同为小区边缘用户提供协作传输。协同组中,用户的服务节点通常为主节点,决定了是否对用户进行协同传输,协同组成员的选择,协同资源的调度,协同方式的抉择等。协同组中的其他节点为协同节点,以从节点的身份参与调度。
就协同方式而言,当前已达成共识,协同方式可以分成两大类:
第一类为联合处理,由参与协同的多个节点联合对协同用户发送下行数据,以及联合接收协同用户的上行数据,即协同组内各成员均参与数据传输。
第二类为协同调度,各节点协作进行资源调度,根据服务节点以及各协作节点的信道信息来进行综合资源调度,减小用户受到的干扰,但实际发送、接收数据的节点只有一个,这种模式可以看成是一种增强的干扰协调方法,仅由协同组内的服务节点对用户进行传输,协同组内的协同节点参与调度,通过服务节点、协同节点的联合调度,实现干扰协调。
从以上两种协同方式可看出,联合处理方式中服务节点、以及各协同节点都需要得到协同用户的下行数据,而当前LTE中业务网关仅向用户的服务节点下发用户下行数据,因此没有考虑如何满足联合处理方式的下行数据分配要求。
发明内容
有鉴于此,本发明的主要目的在于提供一种多点协作传输的方法和***,以解决现有技术中如何满足联合处理方式的下行数据分配要求。
为达到上述目的,本发明的技术方案是这样实现的:
一种多点协作传输的方法,该的方法,包括:服务基站根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,若有,则服务基站组建协同组,业务网关根据所述服务基站上传的信息,将下行业务数据下发给所述协同组,所述协同组将获得的下行业务数据下发给所述协同用户;
其中,所述判断是否具有需要协同传输的用户具体指:所述服务基站根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,则对所述用户进行协同传输,所述用户成为所述协同传输的用户;
其中,所述服务基站组建协同组具体指:服务基站从相邻基站中选择出的候选协同基站,并向该候选协同基站发送协同请求,所述候选协同基站接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求的确认信息给所述服务基站,所述服务基站根据接收到的确认信息,确定所述协同用户的协同组。
优选的,所述协同组包括所述服务基站和至少一个协同基站;
优选的,所述服务基站上传的信息包括协同组信息和控制信令;
进一步,所述业务网关给服务基站和协同基站下发用户下行业务数据,所述服务基站和协同基站将所述下行业务数据下发给所述协同用户;
进一步,所述业务网关给协同基站下发用户下行业务数据,所述协同基站将所述下行业务数据下发给所述协同用户;
优选的,所述服务基站上传的信息包括控制信令。
进一步的,所述业务网关给所述服务基站下发协同用户下行业务数据,所述服务基站将下行业务数据传给协同基站,协同组将所述下行业务数据下发给所述协同用户;
优选的,所述服务基站确定所述协同组后,所述协同组进行联合资源调度,服务基站为主,协同基站为辅,由所述服务基站决定具体调度,确定分给协同用户的下行资源以及调制编码方式,同时通知协同基站;
上述对所述协同用户进行下行业务数据传输具体指,把子帧n的重传数据或新数据通过天线空口传给协同用户。
一种协同传输数据的***,包括,收发模块,服务模块,协同模块,协同用户;
所述服务模块,根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,若有,则服务模块组建协同组,将信息上传收发模块,所述协同组成员将接收到所述收发模块下发的下行业务数据下发给所述协同用户;
所述收发模块,根据所述服务模块上传的信息,将下行业务数据下发给所述协同组成员,所述协同组成员将获得的下行业务数据下发给所述协同用户;
所述协同模块,接收所述服务模块或所述收发模块下发的协同用户下行业务数据;
所述协同用户,将信道质量信息上传给所述服务模块,接收所述服务模块或所述协同模块下发的协同用户下行业务数据;
其中,所述服务模块还包含判断单元,用于判断是否具有需要协同传输的用户,根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,则对所述用户进行协同传输,所述用户成为所述协同传输的用户;
其中,所述服务模块还包含选择单元,用于向从相邻基站中选择出的候选协同模块,并向该候选协同模块发送协同请求,所述候选协同模块接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求确认信息给所述选择单元,所述选择单元根据接收到的协同确认信息,确定所述协同用户的协同组;
其中,所述服务模块还包含控制单元,用于向协同组所有协同模块发送协同请求,所述协同组所有协同模块确认后反馈所述控制模块;以服务模块为主,协同单元为辅,由所述控制单元决定具体调度,确定分给协同单元的下行资源以及调制编码方式,同时通知协同单元;
其中,所述服务模块还包含业务数据收发单元,用于将所述用户协同组信息通过S1接口上传给收发模块;将所述收发模块下发的下行业务数据通过X2接口在相同的时频资源上对协同用户进行下行业务数据传输;
上述对协同用户进行下行业务数据传输具体指,把子帧n的重传数据或新数据通过天线空口传给协同用户。
有益效果
本发明中提出了一种协同传输数据的方法及***,解决了协同多点传输中的下行业务数据存在的问题,使服务基站以及各协同基站能获得协同用户的下行业务数据,从而能对协同用户进行协同传输,同时,满足联合处理方式的下行数据分配要求,对接入网侧增加额外处理,或者,增强网关能力,而且不会对非协同用户的业务分配造成任何影响。
附图说明
图1:协同传输数据的方法中方案1示意图
图2:协同传输数据的方法中方案2示意图
图3:协同传输数据的方法流程图
图4:实例1协同传输数据的方法处理流程图
图5:实例2、3、4协同传输数据的方法处理流程图
图6:实例5协同传输的***方案1结构示意图
图7:实例6协同传输的***方案2结构示意图
具体实施方式
针对协同多点传输中下行业务数据的分配方式,本发明提出两种方案:
方案1为:服务基站根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,从相邻基站中选择出的候选协同基站,并向该候选协同基站发送协同请求,所述候选协同基站接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求的确认信息给所述服务基站,所述服务基站根据接收到的确认信息,确定所述协同用户的协同组,服务基站上传控制信令,无需给业务网关上传协同组信息,业务网关对协同组透明,仅给所述服务基站下发所述协同用户的下行业务数据,服务基站把所述协同用户的下行业务数据传给协同基站,所述协同组成员对协同用户进行下行业务数据传输,延续当前LTE中的下行业务数据分配方案,对接入网侧增加额外处理。
方案2为:服务基站根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,从相邻基站中选择出的候选协同基站,并向该候选协同基站发送协同请求,所述候选协同基站接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求的确认信息给所述服务基站,所述服务基站根据接收到的确认信息,确定所述协同用户的协同组,服务基站将用户的协同组信息和控制信令上传给业务网关,业务网关给所述协同组所有成员下发用户下行业务数据,所述协同组成员将获得的下行业务数据下发给所述协同用户,改变当前LTE中的下行业务数据分配方案,增强网关能力。
上述两种方案可以综合概括为如图3所示的一种协同传输数据的方法,其步骤如下:
步骤301,服务基站根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,若有,则从相邻基站中选择协同基站组建协同组;
判断是否具有需要协同传输的用户具体指:所述服务基站根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,则对所述用户进行协同传输,所述用户成为所述协同传输的用户;
从相邻基站中选择协同基站组建协同组具体指:所述服务基站从相邻基站中选择出的候选协同基站,并向该候选协同基站发送协同请求,所述候选协同基站接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求的确认信息给所述服务基站,所述服务基站根据接收到的确认信息,确定所述协同用户的协同组;
其中,协同组包括包括所述服务基站和至少一个协同基站。
步骤302,业务网关根据所述服务基站上传的信息,将下行业务数据下发给所述协同组成员;
其中,服务基站上传的信息包括协同组信息和控制信令,或,服务基站上传的信息包括控制信令;
服务基站确定所述协同组后,进行联合资源调度,由所述服务基站决定具体调度,确定分给协同用户的下行资源以及调制编码方式,同时通知协同基站;
步骤303,所述协同组成员将获得的下行业务数据下发给所述协同用户,
所述业务网关给服务基站和协同基站下发用户下行业务数据,所述服务基站和协同基站将所述下行业务数据下发给所述协同用户;
或者,所述业务网关给协同基站下发用户下行业务数据,所述协同基站将所述下行业务数据下发给所述协同用户;
或者,所述业务网关给服务基站下发用户下行业务数据,所述服务基站传给协同基站,协同组成员将所述下行业务数据下发给所述协同用户;
所述对协同用户进行下行业务数据传输具体指,把子帧n的重传数据或新数据通过天线空口传给协同用户。
根据上述方法应用实例如下:
实例1:
图1所示,为方案1的数据下发示意图,方案1的方法为,业务网关对于协同用户数据与非协同用户数据相同对待,不做特别处理;业务网关根据用户所属服务基站,将用户数据通过S1接口下发给该用户的服务基站,从而服务基站收到其服务范围内的协同用户数据与非协同用户数据;对于非协同用户数据,服务基站进行空口处理后通过发射天线传输给非协同用户。
对于协同用户数据,服务基站首先根据该用户的协同组信息,将用户数据通过X2接口传给协同组内其他协同基站,服务基站组建协同组时,由服务基站向从相邻基站中选择出的候选协同基站发送协同请求,候选协同基站接收到请求后,根据自身资源分配情况确定是否反馈协同请求的协同确认信息给服务基站,服务基站根据接收到的协同确认信息,确定所述协同用户的协同组,服务基站上传控制信令,业务网关给所述服务基站下发所述协同用户的下行业务数据,服务基站把所述协同用户的下行业务数据传给协同基站,在所有协同基站均收到协同用户数据并且控制面协作控制信令交互完成后,协同组成员在相同的时频资源上对协同用户进行下行业务数据传输。
根据图4所示,业务网关按照当前LTE中规定的方式把用户数据通过S1接口传给用户的服务基站,假设,设定服务基站收到的用户数据中包括用户a的数据和用户b的数据。
服务基站根据用户a、b反馈的信道质量信息,与***事先设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,判定服务基站自身已经无法为用户提供高质量的传输,需要对用户进行协同传输,据此判断出用户a为协同用户,需要由多个基站协同为其提供传输;用户b仍然仅由服务基站提供传输,为非协同用户。
服务基站根据用户a上报的测量结果,选择由相邻的基站1、基站2以及服务基站自身构成协同组共同为用户a进行协同传输。在服务基站确定协同组成员后,向协同组成员基站1、基站2发送协同请求,在等待时延内服务基站收到协同组成员基站1、基站2的协同确认,从而服务基站确定由服务基站自身、基站1以及基站2构成服务协同用户a的协同组,并且该协同组中服务基站为主,基站1、基站2为辅,联合进行资源调度。
具体调度过程中,服务基站根据基站1、基站2上报的资源分配情况,并结合自己的资源分配情况确定有5个时频资源块在这三个基站上均空闲,再根据用户a上报的测量结果,判断使用时频资源块1、2时用户a的信道条件最好,满足判断条件;因此服务基站确定把时频资源块1、2调度给用户a,同时确定用户a在时频资源块1、2上使用QPSK(Quadrature Phase Shift Keying,简称QPSK,四进制相移键控)、1/3编码速率最佳,从而服务基站把下行资源以及调制编码方式通知基站1、基站2。在此同时,服务基站把业务网关下发的用户a的下行数据通过X2接口也传给基站1、基站2。
从而服务基站、基站1、基站2根据分给协同用户a的下行资源以及调制编码方式,在相应时频资源块上把子帧n的重传数据或新数据通过空口传给协同用户a。
而对于非协同用户b,因服务基站确定不对其进行协同传输,因此服务基站无需向其他基站分发用户b的下行数据,由服务基站对用户b独立调度、传输。
该应用实例中,初始阶段用户a、b均为非协同用户,随信道时变,一段时间后用户a变成协同用户,因本实例为方案1,用户a、b是否为协同用户对业务网关透明,业务网关仅把用户a、b的下行业务数据分发给它们的服务基站,由服务基站根据用户的身份以及协同组信息来决定是否需要把业务网关传来的下行数据传给其他协同组成员,延续当前LTE中的下行业务数据分配方案,对接入网侧增加额外处理。
上述实施例中,服务基站组建协同组时,协同组成员还包括服务基站和协同基站2,或者,协同基站1和协同基站2,或者至少一个协同基站,都还可以同样的方法实现。
实例2:
图2所示,为方案2的数据下发示意图,方案2的方法为,对于非协同用户数据,业务网关通过S1接口下发给该用户的服务基站。而对于协同用户数据,服务基站判断协同用户,组建协同组的方法与实施例1相同,业务网关通过S1接口下发给协同组内所有成员,包括服务基站以及各协同基站,这样,协同组内所有基站都直接从业务网关收到了协同用户数据,从而服务基站与协同基站间不再需要传输协同用户下行数据,控制面只要交互协作控制信令即可。在完成协作控制信令交互后,服务基站和各协同基站,或者各协同基站在相同的时频资源上对协同用户进行下行传输。
本方案2中因业务网关不仅要把协同用户数据传给其服务基站,还要传给其协同基站,因此需要协同用户的服务基站把协同组信息告知业务网关。
如图5流程图所示,业务网关按照当前LTE中规定的方式把用户数据通过S1接口传给用户的服务基站;为清晰起见,设定服务基站收到的用户数据中包括用户a的数据以及用户b的数据。
服务基站根据用户a、b反馈的信道质量信息,判定因信道时变,服务基站自身已经无法为用户a提供高质量的传输,需要对用户a进行协同传输,从而用户a变为协同用户;用户b仍然仅由服务基站提供传输,仍为非协同用户。
服务基站根据用户a上报的测量结果,选择由相邻的基站1、基站2以及服务基站自身构成协同组共同为用户a进行协同传输。在服务基站确定协同组成员后,向协同组成员基站1、基站2发送协同请求,在等待时延内服务基站收到协同组成员基站1、基站2的协同确认,从而服务基站确定由服务基站自身、基站1以及基站2构成服务协同用户a的协同组。
服务基站把用户a的协同组信息通过S1接口传给业务网关,从而业务网关知道服务基站、基站1、基站2为用户a的协同组信息,则在收到该协同组不再服务用户a的信令之前,业务网关把用户a的下行数据业务分发给用户a协同组内的各个成员基站,具体可以采用多播方式实现,保证协同组各成员同时收到业务网关下发的协同用户下行数据。
从而由服务基站为主,基站1、基站2为辅,联合进行资源调度,具体调度过程中,服务基站根据基站1、基站2上报的资源分配情况,并结合自己的资源分配情况确定有5个时频资源块在这三个基站上均空闲,根据信道频率选择特性,在时频资源块1、2、3上用户a到服务基站的信道条件最好,在时频资源块1、2、4上用户a到基站1、基站2的信道条件最好,服务基站确定把时频资源块1、2调度给用户a,同时确定用户a在时频资源块1、2上使用16QAM、(Quadrature Amplitude Modulation,简称QAM,正交振幅调制)1/2编码速率最佳,从而服务基站把下行资源以及调制编码方式通知基站1、基站2。最终在相应时、频资源上把子帧n的重传数据或新数据通过空口传给协同用户a。
而对于非协同用户b,因服务基站确定不对其进行协同传输,因此服务基站无需通知业务网关有关用户b的协同组信息,业务网关对用户b的下行业务数据仍然传给服务基站,由服务基站对用户b独立调度、传输。
该应用实例中,初始阶段用户a、b均为非协同用户,随信道时变用户a变成协同用户,因本实例采用方案2,需要通知业务网关协同用户的协同组信息,从而业务网关把协同用户的后续下行业务数据同时传给协同组内各成员,之后协同组以服务基站为主、协同基站为辅进行资源调度,共同为协同用户传输下行数据,因网关直接多点下发,服务基站与协同基站之间无需交互协同用户的下行数据,改变当前LTE中的下行业务数据分配方案,增强网关能力。
实例3:
也采用方案2,数据下发示意图如图2,其中业务网关、服务基站、协同基站及协同用户功能同实例1。
流程图如图5所示,业务网关按照当前LTE中规定的方式把用户数据通过S1接口传给用户的服务基站,为清晰起见,设定服务基站收到的用户数据中包括用户a的数据以及用户b的数据。
服务基站根据用户a、b反馈的信道质量信息,判定因信道时变,服务基站自身已经无法为用户a提供高质量的传输,需要对用户a进行协同传输,从而用户a变为协同用户;用户b仍然仅由服务基站提供传输,仍为非协同用户。
服务基站根据用户a上报的测量结果,选择由相邻的基站1、基站2以及服务基站自身构成协同组共同为用户a进行协同传输。在服务基站确定协同组成员后,需要向协同组成员基站1、基站2发送协同请求,在等待时延内服务基站收到了基站1的协同确认,没有收到基站2的协同确认。因此服务基站确定由服务基站自身和基站1构成协同组来为用户a服务。
服务基站把用户a的协同组信息通过S1接口传给业务网关,从而业务网关知道服务基站、基站1为用户a的协同组,则在收到该协同组不再服务用户a的信令之前,业务网关将用户a的下行数据业务下发给用户a协同组内的各个成员,即发给服务基站以及基站1;具体可以采用多播方式发送,能保证协同组各成员同时收到业务网关下发的协同用户下行数据。
由服务基站为主,基站1为辅,联合进行资源调度,具体调度过程中,服务基站根据基站1、基站2上报的资源分配情况,并结合自己的资源分配情况确定有5个时频资源块在这三个基站上均空闲,根据信道频率选择特性,在时频资源块1、2、3上用户a到服务基站的信道条件最好,在时频资源块1、2、4上用户a到基站1、基站2的信道条件最好,服务基站确定把时频资源块1、2调度给用户a,同时确定用户a在时频资源块1、2上使用16QAM、1/2编码速率最佳,从而服务基站把下行资源以及调制编码方式通知基站1;在相应时、频资源上把子帧n的重传数据或新数据通过空口传给协同用户a。
而对于非协同用户b,因服务基站确定不对其进行协同传输,因此服务基站无需通知业务网关有关用户b的协同组信息,业务网关对用户b的下行业务数据仍然传给服务基站,由服务基站对用户b独立调度、传输。
该应用实例中,初始阶段用户a、b均为非协同用户,随信道时变用户a变成协同用户,因本实例采用方案2,需要通知业务网关协同用户的协同组信息,从而业务网关把协同用户的下行业务数据同时下发给协同组内各成员,之后协同组以服务基站为主、协同基站为辅进行资源调度,共同为协同用户传输下行业务数据,因网关直接多点下发,服务基站与协同基站之间无需交互协同用户的下行数据,改变当前LTE中的下行业务数据分配方案,增强网关能力;
实例4:
也采用方案2,数据下发示意图如图2,其中业务网关、服务基站、协同基站及协同用户功能同实例1。
流程图如图5所示,业务网关按照当前LTE中规定的方式把用户数据通过S1接口传给用户的服务基站,为清晰起见,设定服务基站收到的用户数据中包括用户a的数据以及用户b的数据。
服务基站根据用户a、b反馈的信道质量信息,判定因信道时变,服务基站自身已经无法为用户a提供高质量的传输,需要对用户a进行协同传输,从而用户a变为协同用户;用户b仍然仅由服务基站提供传输,仍为非协同用户。
服务基站根据用户a上报的测量结果,选择由相邻的基站1、基站2以及服务基站自身构成协同组共同为用户a进行协同传输。在服务基站确定协同组成员后,需要向协同组成员基站1、基站2发送协同请求,在等待时延内服务基站收到了基站1的协同确认、基站2的协同请求的确认信息。因此服务基站确定由服务基站自身和基站1及基站2构成协同组来为用户a服务。
服务基站把用户a的协同组信息通过S1接口传给业务网关,从而业务网关知道服务基站、基站1、基站2为用户a的协同组,则在收到该协同组不再服务用户a的信令之前,业务网关把用户a的下行数据业务分发给用户a协同组内的各个成员,即发给服务基站以及基站1。具体可以采用多播方式发送,能保证协同组各成员同时收到业务网关下发的协同用户下行数据。
由服务基站为主,基站1、基站2为辅,联合进行资源调度,具体调度过程中,服务基站没有能够给用户a分配的资源,而基站1、基站2有5个时频资源块空闲,其中时频资源块1、2到用户a的信道条件最好,因此服务基站确定把时频资源块1、2调度给用户a,同时确定用户a在时频资源块1、2上使用16QAM、1/2编码速率最佳,从而服务基站把下行资源以及调制编码方式通知基站1、基站2。最终在相应时、频资源上由基站1、基站2把子帧n的重传数据或新数据通过天线空口传给协同用户a。服务基站作为协同组的主控基站,只进行调度以及控制信令的收发,不参与业务数据传输。
而对于非协同用户b,因服务基站确定不对其进行协同传输,因此服务基站无需通知业务网关有关用户b的协同组信息,业务网关对用户b的下行业务数据仍然传给服务基站,由服务基站对用户b独立调度、传输。
该应用实例中,初始阶段用户a、b均为非协同用户,随信道时变用户a变成协同用户,因本实例采用方案2,需要通知业务网关协同用户的协同组信息,从而业务网关把协同用户的下行业务数据同时下发给协同组内各成员,之后协同组以服务基站为主、协同基站为辅进行资源调度,共同为协同用户传输下行数据。因网关直接多点下发,服务基站与协同基站之间无需交互协同用户的下行数据,改变当前LTE中的下行业务数据分配方案,增强网关能力;
实施例5
一种协同传输数据的***,如图6所示,包括,收发模块10、服务模块20、协同模块30、协同用户40;
服务模块20,根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,若有,则服务模块组建协同组,将信息上传收发模块10,所述协同组成员将接收到所述收发模块下发的下行业务数据下发给所述协同用户40;
收发模块10,根据服务模块上传的信息,将下行业务数据下发给所述协同组成员,协同组将获得的下行业务数据下发给所述协同用户;
协同模块30,接收所述服务模块或所述收发模块下发的协同用户的下行业务数据;
协同用户40,将反馈的信道质量信息上传给服务模块20,接收所述服务模块20或所协同模块30下发的协同用户的下行业务数据;
所述服务模块20还包含判断单元201,用于判断是否具有需要协同传输的用户,根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,则对所述用户进行协同传输,所述用户成为所述协同传输的用户;
所述服务模块20还包含选择单元202,用于向从相邻基站中选择出的候选协同模块,并向该候选协同模块发送协同请求,所述候选协同模块接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求的确认信息给选择单元202,所述选择单元202根据接收到的协同请求的确认信息,确定所述协同用户模块的协同组;
所述服务模块20还包含控制单元203,用于向协同组所有协同模块30发送协同请求,所述协同组所有协同模块30确认后反馈所述控制单元;以服务模块为主,协同单元为辅,由所述控制单元决定具体调度,确定分给协同单元的下行资源以及调制编码方式,同时通知协同单元;
所述服务模块20还包含业务数据收发单元204,用于将所述用户协同组信息通过S1接口上传给收发模块10;将所述收发模块10下发的下行业务数据通过X2接口在相同的时频资源上对协同用户进行下行业务数据传输。
如图6所示:实施方案1的***为:接收模块10,将用户a、b下行业务数据下发给所述用户的服务模块20,并根据所述服务模块20反馈的协同组信息,将协同用户的下行业务数据下发给协同组内的服务模块20;
服务模块20,将所述接收模块下发的用户a、b的下行业务数据传给相邻基站,判断需要协同传输的用户,判断单元201判断需要协同传输的用户,判断单元201根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,为需要对所述用户a进行协同传输,所述用户a变为所述协同传输的用户,用户b为非协同用户;
服务模块20还包含选择单元,该模块主要的任务为组建协同组,服务模块为主,协同单元301和协同单元302为辅;
服务模块20还包含控制单元203,所述控制信令模块203向协同组所有协同模块30发送协同请求,所述协同组所有协同模块确认后反馈所述控制单元203,所述协作组联合进行资源调度,并由所述选择单元决定具体调度,确定分给协同用户的下行资源以及调制编码方式,并通知协同模块30;
所述服务模块20还包含业务数据收发单元204,所述业务数据收发单元204向收发模块10上传所述用户协同组信息,所述用户协同组信息通过S1接口上传给收发模块10;所述业务数据收发收发204将所述收发模块下发的下行业务数据通过X2接口在相同的时频资源上对协同用户进行下行业务数据传输。
假设,组建协同组共同为协同用户a进行协同传输,确定把时频资源块1、2调度给协同用户a,同时确定协同用户a在时频资源块1、2上使用QPSK、1/3编码速率最佳,服务模块把下行资源以及调制编码方式通知协同模块,在此同时,服务模块20把收发模块10下发的用户a的下行数据通过X2接口也传给协同模块30。从而服务模块20、协同模块30根据分给协同用户a的下行资源以及调制编码方式,在相应时频资源块上把子帧n的重传数据或新数据通过空口传给协同用户a,在相同的时频资源上对协同用户a进行下行业务数据传输,延续当前LTE中的下行业务数据分配方案,对接入网侧增加额外处理。
上述实施例中,服务模块组建协同组时,协同组成员还有以下情况组成,包括服务模块和协同单元302,或者,协同单元301和协同单元302,或者至少一个协同单元,都可以用上述的方法实现。
实施例6
还提供一种协同传输的***,如图7所示,包括,接收模块10、服务模块20、协同模块30、协同用户模块40
实施方案2的***为:收发模块10,将用户a、b下行业务数据下发给所述用户的服务模块20,并根据所述服务模块20反馈的协同组信息,将协同用户的下行业务数据下发给协同组内的所有成员,将协同用户的下行业务数据下发给协同组内的服务模块20和协同模块30;或着,将协同用户的下行业务数据下发给协同组内的至少一个协同模块30;
服务模块20,将所述收发模块下发的用户a、b的下行业务数据传给相邻基站,判断需要协同传输的用户,判断单元201,判断需要协同传输的用户,判断单元201根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,为需要对所述用户a进行协同传输,所述用户a变为所述协同传输的用户,用户b为非协同用户;
所述服务模块20还包含选择单元,组建所述协同组,服务模块20为主,协同模块301和协同模块302为辅;
所述服务模块20还包含控制信令单元203,所述控制信令单元203向协同组所有协同模块30发送协同请求,所述协同组所有协同模块确认后反馈所述控制单元203,所述协作组联合进行资源调度,并由所述选择单元决定具体调度,确定分给协同用户的下行资源以及调制编码方式,并通知协同模块30;
所述服务模块20还包含业务数据收发单元204,用于向接收模块上传所述用户协同组信息,所述用户协同组信息通过S1接口上传给收发模块10;所述业务数据收发模块204将所述接收模块下发的下行业务数据通过X2接口在相同的时频资源上对协同用户进行下行业务数据传输。
假设,服务模块20把用户a的协同组信息通过S1接口传给接收模块,从而收发模块知道服务模块、协同单元301、协同单元302为用户a的协同组信息,则在收到该协同组不再服务用户a的信令之前,收发模块把用户a的下行数据业务下发给用户a协同组内的各个成员,具体可以采用多播方式实现,能保证协同组各成员同时收到接收模块下发的协同用户下行数据。
从而由服务模块20为主,协同模块301、协同模块302为辅,联合进行资源调度,具体调度过程中,服务模块20根据协同单元301、协同单元302上报的资源分配情况,并结合自己的资源分配情况确定有5个时频资源块在这三个模块上均空闲,根据信道频率选择特性,在时频资源块1、2、3上用户a到服务模块的信道条件最好,在时频资源块1、2、4上用户a到协同模块301、协同模块302的信道条件最好,服务模块确定把时频资源块1、2调度给用户a,同时确定用户a在时频资源块1、2上使用16QAM、1/2编码速率最佳,从而服务模块把下行资源以及调制编码方式通知协同单元301、协同单元302。在相应时、频资源上把子帧n的重传数据或新数据通过空口传给协同用户a;延续当前LTE中的下行业务数据分配方案,对接入网侧增加额外处理。
上述实施例中,服务模块组建协同组时,协同组成员还有以下情况组成,包括服务模块和协同单元302,或者,协同单元301和协同单元302,或者至少一个协同单元,都可以用上述的方法实现。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (14)
1.一种协同传输数据的方法,其特征在于,包括:服务基站根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,若有,则服务基站组建协同组,业务网关根据所述服务基站上传的信息,将下行业务数据下发给所述协同组成员,所述协同组成员将获得的下行业务数据下发给所述协同用户。
2.根据权利要求1所述的协同传输数据的方法,其特征在于,所述判断是否具有需要协同传输的用户具体指:所述服务基站根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,则对所述用户进行协同传输,所述用户成为所述协同传输的用户。
3.根据权利要求1所述的协同传输数据的方法,其特征在于,所述服务基站组建协同组具体指:所述服务基站从相邻基站中选择出的候选协同基站,并向该候选协同基站发送协同请求,所述候选协同基站接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求的确认信息给所述服务基站,所述服务基站根据接收到的确认信息,确定所述协同用户的协同组。
4.根据权利要求1所述的协同传输数据的方法,其特征在于,所述协同组包括所述服务基站和至少一个所述协同基站。
5.根据权利要求4所述的协同传输数据的方法,其特征在于,所述服务基站上传的信息包括协同组信息和控制信令。
6.根据权利要求4所述的协同传输数据的方法,其特征在于,所述服务基站上传的信息包括控制信令。
7.根据权利要求5所述的协同传输数据的方法,其特征在于,所述业务网关给所述服务基站和所述协同基站下发协同用户下行业务数据,所述服务基站和所述协同基站将所述下行业务数据下发给所述协同用户。
8.根据权利要求5所述的协同传输数据的方法,其特征在于,所述业务网关给协同基站下发所述协同用户下行业务数据,所述协同基站将所述下行业务数据下发给所述协同用户。
9.根据权利要求6所述的协同传输数据的方法,其特征在于,所述业务网关给所述服务基站下发协同用户下行业务数据,所述服务基站将所述下行业务数据传给协同基站,协同组成员将所述下行业务数据下发给所述协同用户。
10.根据权利要求3所述的协同传输数据的方法,其特征在于,所述服务基站确定所述协同组后,所述协同组进行联合资源调度,所述服务基站为主,所述协同基站为辅,由所述服务基站决定具体调度,确定分给协同用户的下行资源以及调制编码方式,同时通知所述协同基站。
11.根据权利要求1至9任一项所述的协同传输数据的方法,其特征在于,对所述协同用户进行下行业务数据传输具体指,把子帧n的重传数据或新数据通过天线空口传给所述协同用户。
12.一种协同传输数据的***,其特征在于,包括,收发模块,服务模块,协同模块,协同用户;
所述服务模块,根据用户反馈的信道质量信息,判断是否具有需要协同传输的用户,若有,则服务模块组建协同组,将信息上传收发模块,所述协同组成员将接收到所述收发模块下发的下行业务数据下发给所述协同用户;
所述收发模块,根据所述服务模块上传的信息,将下行业务数据下发给所述协同组成员,所述协同组成员将获得的下行业务数据下发给所述协同用户;
所述协同模块,接收所述服务模块或所述收发模块下发的协同用户下行业务数据;
所述协同用户,将信道质量信息上传给所述服务模块,接收所述服务模块或所述协同模块下发的协同用户下行业务数据;
13.根据权利要求12所述的协同传输数据的***,其特征在于所述服务模块还包含判断单元,用于判断是否具有需要协同传输的用户,根据用户反馈的信道质量信息与设置的协同门限比较,当反馈的信道质量信息低于或等于协同门限时,则对所述用户进行协同传输,所述用户成为所述协同传输的用户;
所述服务模块还包含选择单元,用于从相邻基站中选择出的候选协同模块,并向该候选协同模块发送协同请求,所述候选协同模块接收到协同请求后,根据自身资源分配情况确定是否反馈协同请求的确认信息给所述选择单元,所述选择单元根据接收到的协同确认信息,确定所述协同用户的协同组;
所述服务模块还包含控制单元,用于向协同组所有协同单元发送协同请求,所述协同组所有协同单元确认协同确认信息后反馈所述控制单元;以所述服务模块为主,所述协同模块为辅,由所述控制单元决定具体调度,确定分给协同单元的下行资源以及调制编码方式,同时通知所述协同单元;
所述服务模块还包含业务数据收发单元,用于将所述用户协同组信息通过S1接口上传给收发模块;将所述收发模块下发的下行业务数据通过X2接口在相同的时频资源上对所述协同用户进行下行业务数据传输。
14.根据权利要求12或13所述的协同传输数据的***,其特征在于,对所述协同用户进行下行业务数据传输具体指,把子帧n的重传数据或新数据通过天线空口传给所述协同用户。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009101070725A CN101883402A (zh) | 2009-05-07 | 2009-05-07 | 一种协同传输数据的方法及*** |
PCT/CN2010/072540 WO2010127638A1 (zh) | 2009-05-07 | 2010-05-07 | 一种协同传输数据的方法、***及基站设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009101070725A CN101883402A (zh) | 2009-05-07 | 2009-05-07 | 一种协同传输数据的方法及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101883402A true CN101883402A (zh) | 2010-11-10 |
Family
ID=43049995
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009101070725A Pending CN101883402A (zh) | 2009-05-07 | 2009-05-07 | 一种协同传输数据的方法及*** |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101883402A (zh) |
WO (1) | WO2010127638A1 (zh) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012019476A1 (zh) * | 2010-08-10 | 2012-02-16 | 中兴通讯股份有限公司 | 一种协作多点通信技术中数据交互的方法及*** |
CN102638898A (zh) * | 2011-02-11 | 2012-08-15 | 中兴通讯股份有限公司 | 一种基于多点协作的集中式有线口数据传输方法及*** |
CN102651916A (zh) * | 2011-02-24 | 2012-08-29 | 中兴通讯股份有限公司 | 一种基于多点协作的分布式有线接口数据传输方法及*** |
CN103685373A (zh) * | 2012-09-10 | 2014-03-26 | 联想(北京)有限公司 | 数据上传装置和数据上传方法 |
CN103856300A (zh) * | 2012-11-28 | 2014-06-11 | 电信科学技术研究院 | 一种用户反馈信息的传输方法和设备 |
CN104168595A (zh) * | 2014-08-27 | 2014-11-26 | 中国联合网络通信集团有限公司 | 一种多点协作传输方法、装置及*** |
WO2014205650A1 (zh) * | 2013-06-25 | 2014-12-31 | 华为技术有限公司 | 一种数据调度的方法、装置、基站及*** |
WO2015176557A1 (zh) * | 2014-05-23 | 2015-11-26 | 华为技术有限公司 | 多用户协作通信场景下的数据传输方法、装置及*** |
CN105282860A (zh) * | 2014-07-25 | 2016-01-27 | 中兴通讯股份有限公司 | 双连接拆建方法和装置 |
WO2016082453A1 (zh) * | 2014-11-24 | 2016-06-02 | 中兴通讯股份有限公司 | 虚拟小区资源分配方法、装置和*** |
CN106993322A (zh) * | 2016-01-21 | 2017-07-28 | 索尼公司 | 电子设备和通信方法 |
WO2020042712A1 (zh) * | 2018-08-31 | 2020-03-05 | 华为技术有限公司 | 一种通信方法及装置 |
CN117155705A (zh) * | 2023-10-27 | 2023-12-01 | 三峡高科信息技术有限责任公司 | 基于物联网网闸的数据传输***、方法、设备及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1949918A (zh) * | 2005-10-11 | 2007-04-18 | 华为技术有限公司 | 一种两层节点网络架构下的双播切换方法和设备 |
CN101373998A (zh) * | 2007-08-20 | 2009-02-25 | 上海贝尔阿尔卡特股份有限公司 | 低信息交互的多基站协作mimo及其调度方法和装置 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100965694B1 (ko) * | 2004-06-15 | 2010-06-24 | 삼성전자주식회사 | 광대역 무선 접속 통신 시스템에서 소프트 핸드오버 지원을 위한 시스템 및 방법 |
-
2009
- 2009-05-07 CN CN2009101070725A patent/CN101883402A/zh active Pending
-
2010
- 2010-05-07 WO PCT/CN2010/072540 patent/WO2010127638A1/zh active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1949918A (zh) * | 2005-10-11 | 2007-04-18 | 华为技术有限公司 | 一种两层节点网络架构下的双播切换方法和设备 |
CN101373998A (zh) * | 2007-08-20 | 2009-02-25 | 上海贝尔阿尔卡特股份有限公司 | 低信息交互的多基站协作mimo及其调度方法和装置 |
Non-Patent Citations (1)
Title |
---|
3GPP: "《3GPP》", 22 August 2008 * |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012019476A1 (zh) * | 2010-08-10 | 2012-02-16 | 中兴通讯股份有限公司 | 一种协作多点通信技术中数据交互的方法及*** |
CN102638898A (zh) * | 2011-02-11 | 2012-08-15 | 中兴通讯股份有限公司 | 一种基于多点协作的集中式有线口数据传输方法及*** |
WO2012106966A1 (zh) * | 2011-02-11 | 2012-08-16 | 中兴通讯股份有限公司 | 一种基于多点协作的集中式有线口数据传输方法及*** |
CN102651916A (zh) * | 2011-02-24 | 2012-08-29 | 中兴通讯股份有限公司 | 一种基于多点协作的分布式有线接口数据传输方法及*** |
CN103685373A (zh) * | 2012-09-10 | 2014-03-26 | 联想(北京)有限公司 | 数据上传装置和数据上传方法 |
CN103685373B (zh) * | 2012-09-10 | 2016-12-28 | 联想(北京)有限公司 | 数据上传装置和数据上传方法 |
CN103856300A (zh) * | 2012-11-28 | 2014-06-11 | 电信科学技术研究院 | 一种用户反馈信息的传输方法和设备 |
WO2014205650A1 (zh) * | 2013-06-25 | 2014-12-31 | 华为技术有限公司 | 一种数据调度的方法、装置、基站及*** |
WO2015176557A1 (zh) * | 2014-05-23 | 2015-11-26 | 华为技术有限公司 | 多用户协作通信场景下的数据传输方法、装置及*** |
CN105282860A (zh) * | 2014-07-25 | 2016-01-27 | 中兴通讯股份有限公司 | 双连接拆建方法和装置 |
CN104168595B (zh) * | 2014-08-27 | 2017-10-10 | 中国联合网络通信集团有限公司 | 一种多点协作传输方法、装置及*** |
CN104168595A (zh) * | 2014-08-27 | 2014-11-26 | 中国联合网络通信集团有限公司 | 一种多点协作传输方法、装置及*** |
WO2016082453A1 (zh) * | 2014-11-24 | 2016-06-02 | 中兴通讯股份有限公司 | 虚拟小区资源分配方法、装置和*** |
CN106993322A (zh) * | 2016-01-21 | 2017-07-28 | 索尼公司 | 电子设备和通信方法 |
CN106993322B (zh) * | 2016-01-21 | 2022-07-01 | 索尼公司 | 电子设备和通信方法 |
WO2020042712A1 (zh) * | 2018-08-31 | 2020-03-05 | 华为技术有限公司 | 一种通信方法及装置 |
CN110875760A (zh) * | 2018-08-31 | 2020-03-10 | 上海华为技术有限公司 | 一种通信方法及装置 |
CN110875760B (zh) * | 2018-08-31 | 2023-05-12 | 上海华为技术有限公司 | 一种通信方法及装置 |
CN117155705A (zh) * | 2023-10-27 | 2023-12-01 | 三峡高科信息技术有限责任公司 | 基于物联网网闸的数据传输***、方法、设备及存储介质 |
CN117155705B (zh) * | 2023-10-27 | 2024-02-02 | 三峡高科信息技术有限责任公司 | 基于物联网网闸的数据传输***、方法、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
WO2010127638A1 (zh) | 2010-11-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101883402A (zh) | 一种协同传输数据的方法及*** | |
CN101651880B (zh) | 多小区协作发送方法 | |
CN102098737B (zh) | 一种基于小区优先级的协作调度方法及*** | |
CN101978757B (zh) | 多载波***中的快速载波分配 | |
CN102823314B (zh) | 无线通信*** | |
CN101621835B (zh) | 一种基于空中接口的CoMP分布式下行多用户调度方法 | |
CN104081853A (zh) | 在通信***中选择工作参数的***和方法 | |
CN102655677A (zh) | 移动通信***及其远端射频单元分簇方法 | |
CN104796918A (zh) | 无线通信组网的方法 | |
CN102123525A (zh) | 下行多天线多基站干扰协调方法和基站 | |
CN102035579A (zh) | 信息反馈方法和用户设备 | |
CN101925183A (zh) | 一种基于协作多点传输的数据传输方法及装置 | |
CN104350693A (zh) | 蜂窝移动通信***中用于协作通信的信道估计方法和装置 | |
CN102916732A (zh) | 一种实现超级小区数据传输的方法、***及控制站 | |
CN106656217A (zh) | 一种多射频单元基站***的全双工传输方法 | |
CN101789815A (zh) | 下行数据传输方法及基站 | |
CN101400066A (zh) | 一种在中继链路上进行数据传输的方法、中继和基站 | |
CN102647727A (zh) | 一种混合协作簇的选择方法 | |
CN104811916A (zh) | 一种用于传输网络辅助信息的方法 | |
CN103078714A (zh) | 一种基于协作决策和自适应功率分配的下行协作多点传输方法 | |
CN101990220A (zh) | 下行多天线多基站合作方法、基站和用户设备 | |
CN101965060A (zh) | 一种多点协作发送和接收的方法及相应基站 | |
CN102111840B (zh) | 一种无线通信中多点协作下的基站分簇方法 | |
CN104717756A (zh) | 一种基于基带池的CoMP实现方法和*** | |
CN102202413A (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 | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20101110 |