一种 HSPA 的上下行联合调度方法 技术领域 本发明涉及通信系统中的用户调度技术， 特别涉及一种高速分组接入 (HSPA) 的 上下行联合调度方法。
背景技术 在传统 HSPA 调度中， 上行和下行方向相互独立地进行调度， 分别计算用户的优先 级顺序， 根据优先级确定每个 TTI 调度的用户， 调度算法在上下行没有直接的关联关系。
当用户在 HSUPA 的上行业务信道被调度后， 该调度用户通过调度的上行业务信道 向 NodeB 发送业务数据， NodeB 接收该业务数据后， 利用 HSUPA 的下行控制信道在 RLC 层上 向 UE 反馈确认信息， UE 接收确认信息后继续进行后续数据发送 ； 当用户在 HSDPA 的下行业 务信道被调度后， NodeB 通过调度的下行业务信道向 UE 发送业务数据， UE 接收该业务数据 后， 利用 HSDPA 的上行控制信道在 RLC 层上向 NodeB 反馈确认信息， NodeB 接收确认信息后 继续进行后续数据发送。
但是， 目前的网络环境中， HSUPA 的上行业务信道和 HSDPA 的下行业务信道可能会 因干扰水平不同导致 HSUPA 和 HSDPA 覆盖不平衡， 容易出现单方向可以正常调度， 但反方向 一直得不到调度机会的情况。在这种不平衡的调度环境下， 正常调度方向的 RLC 层因为始 终得不到确认数据， 而需要始终重复发送之前的数据， 因此很快累积出超过发送窗长的数 据， 称为 RLC 层出窗， 从而进入异常处理导致数据丢失 ； 同时， 仅单向正常调度的用户在其 正常调度方向上始终被调度， 也减少了双向正常调度用户的调度机会， 影响小区吞吐量。
针对上述调度不平衡而造成的 RLC 出窗问题， 目前通过 TCP 流控机制可以得到部 分解决。若 TCP 的接收方向一直得不到调度机会， 则 TCP 一直收不到反馈， 因此， 会逐步降 低 TCP 发送方向数据的发送速度直到为零 ； 但是该 TCP 流控处理过程缓慢， 对于信道的变化 反应不够及时， 等到 TCP 速率调整到位时已经发送了过多的数据， 依然会造成 RLC 发送出窗 等问题， 而且在单向调度过程中占用了过多的调度资源， 影响上下行吞吐量。
发明内容 有鉴于此， 本发明提供一种 HSPA 的上下行联合调度方法， 能够及早避免 RLC 出窗 导致的数据丢失。
为实现上述目的， 本发明采用如下的技术方案 ：
一种 HSPA 的上下行联合调度方法， 包括 ：
在 NodeB 为 UE 进行上下行传输调度的过程中， 若所述 UE 在任一方向上存在待发 送数据、 且预设时间内在该任一方向上允许被调度但始终未得到调度， 禁止在所述任一方 向的反方向业务信道上调度所述 UE， 直到 UE 在所述任一方向上得到调度、 并成功传输数 据， 允许在所述任一方向的反方向业务信道上调度所述 UE。
较佳地， 预先设置 UE 的调度状态种类包括 ： 上行调度允许状态、 上行调度禁止状 态、 下行调度允许状态和下行调度禁止状态 ； 其中， 上行调度允许状态表示允许为所述 UE
进行 HSDPA 的下行业务信道调度， 上行调度禁止状态表示禁止为所述 UE 进行 HSDPA 的下行 业务信道调度， 下行调度允许状态表示允许为所述 UE 进行 HSUPA 的上行业务信道调度， 下 行调度禁止状态表示禁止为所述 UE 进行 HSUPA 的上行业务信道调度 ；
当所述任一方向为下行方向时 ：
所述 UE 在任一方向上有数据发送、 且预设时间内在该任一方向上允许被调度但 始终未得到调度， 禁止在所述任一方向的反方向业务信道上调度所述 UE 为 ： 当所述 UE 处于 上行调度允许状态、 在下行方向存在待发送数据、 且连续 N 个传输时间间隔 TTI 未被调度， 则将所述 UE 转入下行调度禁止状态 ； 所述 N 为系统预设的正整数 ；
所述直到 UE 在所述任一方向上得到调度、 并成功传输数据， 允许在所述任一方向 的反方向业务信道上调度所述 UE 为 ： 直到该 UE 在下行方向上被调度， 且所述 NodeB 确定 UE 成功收到下行数据时， 将所述 UE 转入下行调度允许状态 ；
当所述任一方向为上行方向时 ：
所述 UE 在任一方向上有数据发送、 且预设时间内在该任一方向上允许被调度但 始终未得到调度， 禁止在所述任一方向的反方向业务信道上调度所述 UE 为 ： 当所述 UE 处 于下行调度允许状态、 在上行方向存在待发送数据、 且连续 N 个传输时间间隔 TTI 未被调度 时， 将所述 UE 转入上行调度禁止状态 ； 所述直到 UE 在所述任一方向上得到调度、 并成功传输数据， 允许在所述任一方向 的反方向业务信道上调度所述 UE 为 ： 直到所述 UE 在上行方向上被调度， 且所述 NodeB 正确 接收 UE 发送的上行数据时， 将所述 UE 转入上行调度允许状态。
较佳地， 在所述 UE 的 HSPA 业务建立时， 设置允许进行所述 UE 的上下行业务信道 调度。
较佳地， 预先根据正常传输数据的调度间隔要求和系统对 RLC 层出窗处理的反应 速度要求， 设置所述预设时间。
较佳地， 当采用 PF 调度算法时， 所述预设时间大于 PF 调度算法中的最大间隔。
较佳地， 当所述 UE 进入上行调度禁止状态或下行调度禁止状态后启动预设的定 时器， 若定时器超时所述 UE 仍处于上行调度禁止状态或下行调度禁止状态， 则强制进行一 次上行调度或下行调度。
由上述技术方案可见， 本发明中， 在 NodeB 为 UE 进行上下行传输调度的过程中， 若 UE 在任一方向上存在待发送数据、 且预设时间内在该方向上允许被调度但始终未得到调 度， 禁止在该方向的反方向业务信道上调度 UE， 直到 UE 在该方向上得到调度、 并成功传输 数据， 允许在该方向的反方向业务信道上调度 UE。经过上述处理， 当 UE 出现单方向长时间 无法得到调度时， 能够及早停止单方向调度的情况， 避免由于 RLC 层出窗而导致的数据丢 失； 当在 UE 得不到调度的方向上恢复对 UE 的调度后， 再继续进行上下行的正常调度。
附图说明
图 1 为 UE 的调度状态转移图。 图 2 为本发明例一的示意图。 图 3 为本发明例二的示意图。具体实施方式
为使本发明的目的、 技术手段和优点更加清楚明白， 以下结合附图对本发明做进 一步详细说明。
本发明中， 在 NodeB 为 UE 进行上下行传输调度的过程中， 若 UE 在任一方向上存在 待发送数据、 且预设时间内在该任一方向上允许被调度但始终未得到调度， 禁止在所述任 一方向的反方向业务信道上调度 UE， 直到 UE 在该任一方向上得到调度、 并成功传输数据， 允许在该任一方向的反方向业务信道上调度 UE。
其中， 在进行某方向上调度的限制时， 仅对该方向上的业务信道的调度进行限制， 对该方向上控制信道不进行限制。
具体地， 若 UE 下行调度正常， 但存在上行数据 ( 该上行数据可以是业务数据， 也可 以是信令数据 ) 却一直得不到调度时， 禁止为 UE 进行 HSDPA 的下行业务信道调度， 使其在 下行方向上不再发送业务数据， 从而避免 RLC 层出窗造成的数据丢失和调度资源浪费 ； 但 是对于 HSUPA 的下行控制信道， 仍然可以正常调度， 从而保证 HSUPA 的上行业务信道调度一 旦恢复正常， 可以通过 HSUPA 的下行控制信道正常反馈确认信息， 保证数据传输通畅进行。
同理， 若 UE 上行调度正常， 但存在下行数据 ( 该下行数据可以是业务数据， 也可以 是信令数据 ) 却一直得不到调度时， 禁止为 UE 进行 HSUPA 的上行业务信道调度， 使其在上 行方向上不再发送业务数据， 从而避免 RLC 层出窗造成的数据丢失和调度资源浪费 ； 但是 对于 HSDPA 的上行控制信道， 仍然可以正常调度， 从而保证 HSDPA 的下行业务信道调度一旦 恢复正常， 可以通过 HSDPA 的下行控制信道正常反馈确认信息， 保证数据传输顺畅进行。
在具体实现上下行业务信道是否允许调度时， 可以通过标志位或状态标识等形式 进行标记， 从而根据标记控制对 UE 的调度。
接下来， 本发明以为 UE 设置多种调度状态的方式为例， 通过具体实施例说明本发 明的具体实现。
实施例 ：
预先设置 UE 的多种调度状态， 为每个 HSPA 用户上下行分别定义调度允许状态和 调度禁止状态， 具体包括 ：
1) 上行调度允许状态， 表示允许为 UE 进行 HSDPA 下行业务信道调度 ；
2) 上行调度禁止状态， 表示禁止为 UE 进行 HSDPA 下行业务信道调度 ；
3) 下行调度允许状态， 表示允许为 UE 进行 HSUPA 上行业务信道调度 ；
4) 下行调度禁止状态， 表示禁止为 UE 进行 HSUPA 上行业务信道调度。
为控制上下行方向调度不平衡的问题， 当满足一定条件时， 在各种状态之间进行 转移， 从而控制是否允许业务信道的调度。具体地， 各种状态下的转移条件为 ：
A、 进入下行调度允许状态条件， 满足其中一条即可 ：
1)HSPA 业务建立
2) 在下行方向上被调度， 且 NodeB 确定 UE 成功收到下行数据 ；
其中， NodeB 确定 UE 成功收到下行数据， 即 UE 成功收到下行数据后， 向 NodeB 反 馈确认信息， 且 NodeB 接收到该确认信息， 这里， 由于在满足本条件前， UE 一定处于下行调 度禁止状态， 也就是禁止为 UE 进行 HSUPA 的上行业务信道调度， 但是 HSDPA 的上行控制信 道调度仍然是被允许的， 因此 UE 能够通过 HSDPA 的上行控制信道， 正常向 NodeB 反馈确认信息。 B、 进入下行调度禁止状态条件 ：
UE 处于上行调度允许状态， 且 UE 在下行方向有数据要发送的情况下连续 N 个 TTI 没有被调度， 其中 N 为预先配置的正整数 ；
这里， UE 处于上行调度允许状态， 则意味着允许为 UE 进行 HSDPA 的下行调度， 也 就是说， 在允许为 UE 进行下行业务信道调度时， UE 有下行数据 ( 可能是业务数据也可能是 信令数据 ) 要发送， 但却一直没有得到调度， 说明该下行方向的调度存在问题， 需要进行调 度状态转移， 从而控制上行方向也禁止业务信道的调度， 以避免由 RLC 层出窗而导致的数 据丢失， 并为其他双向正常调度的用户提供更多的调度机会， 提高小区吞吐量 ；
其中， 关于 N 的取值配置， 一方面不能过低， 如果低于正常传输的调度间隔， 则可 能造成误操作， 即还未到 UE 的下一次调度时间， 因此 UE 来得到调度， 而并非该方向对 UE 的 调度出现问题 ； 另一方面也不能过高， 否则对于 RLC 层出窗处理的反应过慢， 造成过多数据 的累积而造成数据丢失， 即出现与现有 TCP 流控相同的问题。基于上述分析， 本发明中， 根 据正常数据传输的调度间隔要求和系统对 RLC 层出窗处理的反应速度要求， 设置 N 的取值。
例如， 当采用 PF 调度算法时， 可以将 N 设置为大于 PF 调度算法中的最大间隔， 并 取大于最大间隔的最小值， 以及早进行反方向的调度控制。 C、 进入上行调度允许状态条件， 满足其中一条即可 ：
1)HSPA 业务建立
2) 在上行方向上被调度， 且 NodeB 成功收到 UE 发送的上行数据。
D、 进入上行调度禁止状态条件 ：
UE 处于下行调度允许状态， 且 UE 在上行方向有数据要发送的情况下连续 N 个 TTI 没有被调度， 其中 N 为预先配置的正整数 ；
这里， UE 处于下行调度允许状态， 则意味着允许为 UE 进行 HSUPA 的上行调度， 也 就是说， 在允许为 UE 进行上行业务信道调度时， UE 有上行数据 ( 可能是业务数据也可能是 信令数据 ) 要发送， 但却一直没有得到调度， 说明该上行方向的调度存在问题， 需要进行调 度状态转移， 从而控制下行方向禁止业务信道的调度， 以避免由 RLC 层出窗而导致的数据 丢失， 并为其他双向正常调度的用户提供更多的调度机会， 提高小区吞吐量。
其中， N 的取值配置与前述相同， 这里就不再赘述。
经过上述设置后， 在为 UE 进行上下行传输调度的过程中， 就可以依据 UE 当前的状 态， 进行上下行调度的控制。当 UE 处于上行调度禁止状态时， 禁止为该 UE 进行 HSDPA 的下 行业务信道调度， 直到 UE 转入上行调度允许状态后， 才允许为该 UE 进行 HSDPA 的下行业务 信道调度 ； 当 UE 处于下行调度禁止状态时， 禁止为该 UE 进行 HSUPA 的上行业务信道调度， 直到 UE 进入下行调度允许状态后， 才允许为该 UE 进行 HSUPA 的上行业务信道调度。
由上述各个状态间的转移条件可见， 经过上述设置后， UE 的状态组合共有三种可 能： 上行调度允许 / 下行调度允许状态、 上行调度禁止 / 下行调度允许状态、 上行调度允许 / 下行调度禁止状态， 不会存在上下行调度同时禁止的状态。由上述状态间的转移条件可 见， 当 HSPA 业务建立时， UE 的初始组合状态为上行调度允许 / 下行调度允许状态， 自此之 后， 一直对上下行调度进行监测， 在满足特定条件后， 在三种组合状态间进行转换。具体通 过图 1 中的状态转移图说明三种组合状态间的转换关系， 图 1 中的条件 A、 B、 C、 D 即为前述
文中的几个相应条件。
下面通过两个具体的例子说明本发明实施例的处理及其达到的效果。
图 2 为例一的示意图。其中， 在 HSPA 覆盖区内， 上行出现方向性的强干扰， UE2 在 上行受到较强干扰， 导致上行长时间无法满足调度条件， 进入上行调度禁止状态， 停止下行 调度， UE1 由于没有受到干扰， 上行处于调度允许状态， 由于 UE2 停止下行调度， UE1 的下行 调度次数增加， 速率快速升高， 小区吞吐量也会有所提高。
图 3 为例二的示意图。其中， 由于 HSUPA 干扰控制比较严格， 因此 HSUPA 的覆盖范 围小于 HSDPA 的覆盖范围。UE2 离开 HSUPA 的覆盖区后仍然处于 HSDPA 的覆盖区， 下行依 然进行正常的调度， 但上行不满足调度条件， 很快进入上行调度禁止状态， 停止下行数据的 调度。UE1 处于 HSDPA 和 HSUPA 的覆盖区， 上下行都处于调度允许状态， 能够进行正常的调 度， 而且会因为 UE1 的停止下行调度会获得更多的下行调度机会， 得到更高的吞吐量， 小区 吞吐量也会有所提高。
由上述可见， 通过本发明， 可以避免 RLC 出窗导致的数据丢失， 部分解决由于干扰 原因导致的上下行覆盖不平衡问题， 减少单方向调度禁止用户的反方向调度次数， 将调度 机会让给其他正常用户， 从而增大小区吞吐量。 另外， 可能出现如下情况 ： 单方向 ( 以下称为方向 A) 上调度出现异常， 从而禁止 UE 反方向的业务信道调度 ； 当由干扰消失等情况使得出现异常的调度方向 A 上已经恢复对 UE 的调度功能后， 该 UE 在方向 A 上没有数据发送， NodeB 仍然不会在方向 A 上调度 UE， 这 时， 由于在方向 A 上没有调度发生和数据发送， 因此 NodeB 不会改变 UE 的调度状态， 仍然会 禁止方向 A 的反方向上业务信道的调度， 影响 UE 的正常通信。
例如， UE 的上行调度异常， NodeB 禁止对该 UE 的下行业务信道调度， 假定该 UE 正 在进行下载操作， 则下载业务停止 ； 当 NodeB 对 UE 的上行调度功能恢复后， 由于 UE 没有上 行业务进行， 因此 NodeB 不会对其进行上行调度， 因此下载业务一直处于停止状态。
显然， 上述情况是用户不希望的， 考虑到这种情况， 本发明中进一步地， 在 UE 进入 上行调度禁止状态后， 会立即启动一个预设的定时器， 若定时器超时， 该 UE 仍然处于上行 调度禁止状态， 则强制进行一次上行调度 ； 类似地， 在 UE 进入下行调度禁止状态后， 会立即 启动一个预设的定时器， 若定时器超时时， 该 UE 仍然处于下行调度禁止状态， 则强制进行 一次下行调度。
经过上述处理后， 通过强制进行的一次方向 A 上的调度， 使得用户进入方向 A 的调 度允许状态， 从而能够进行方向 A 相反方向的调度， 避免由于方向 A 上无数据发送而导致的 前述问题 ； 若在此之后， 始终能够正常调度， 则一直维持在方向 A 的调度允许状态， 若方向 A 上仍然有数据发送但却未被调度， 会再次进入方向 A 的调度禁止状态。
以上仅为本发明的较佳实施例而已， 并非用于限定本发明的保护范围。凡在本发 明的精神和原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围 之内。