用于基于业务流的主方向来控制异构蜂窝网络中的小区选择的系统和方法

摘要

公开用于控制蜂窝网络中的高功率基站与相邻低功率基站之间的小区选择的系统和方法。在一个实施例中，将位于高功率基站的高功率基站小区与低功率基站的低功率基站小区之间的过渡区内的用户设备的业务流的主方向确定为上行链路方向或下行链路方向。用户设备的小区选择则基于用户设备的业务流的主方向来控制，使得如果业务流的主方向是下行链路方向，则高功率基站小区的选择得到偏好，而如果业务流的主方向是上行链路方向，则低功率基站小区的选择得到偏好。

说明书

技术领域

本公开涉及异构蜂窝网络中的小区选择。

背景技术

由于对高数据速率的不断增加需求，要求能够满足这种需求的蜂窝网络。蜂窝网络运营商的一个主要问题是找到演进其现有蜂窝网络以提供更高数据速率的方式。在这方面，提出了下列方式以提供现有蜂窝网络中的更高数据速率：(i) 增加现有宏基站的密度，(ii) 增加现有宏基站的协作，或者(iii) 在宏基站网格内需要高数据速率的区域中部署微微基站。方式(i)和(ii)是有问题的，因为它常常难以查找特别是城市环境中的宏基站的新位置，并且均引起显著成本和延迟。另外，增加宏基站的密度因高速移动的用户的频繁切换，而会导致信令的显著增加。

在方式(iii)中，包括微微基站的蜂窝网络在本文中称作“异构蜂窝网络”或者“异构部署”。微微基站还可称作微基站或者低功率节点(LPN)。微微基站是有利的，因为更易于并且更节省成本地查找微微基站的站点。另外，预计微微基站比宏基站更节省成本，并且预计其部署时间更短。通过异构蜂窝网络，宏基站(即，宏层网格)能够主要服务于高速移动的用户或者对高数据速率的需求较低的更宽区域。微微基站(即，微微层网格)则能够迎合具有期望高数据速率但是具有较低移动性的许多用户的区域(即，“热点”)。

图1示出常规异构蜂窝网络10。如所示，异构蜂窝网络10包括具有对应覆盖区域的宏基站12-1至12-4(在本文中一般统称为宏基站12并且单独称作宏基站12)，其中覆盖区域在本文中称作宏基站小区14-1至14-4(在本文中一般统称为宏基站小区14并且单独称作宏基站小区14)。异构蜂窝网络10还包括具有对应覆盖区域的微微基站16-1至16-4(在本文中一般统称为微微基站16并且单独称作微微基站16)，其中覆盖区域在本文中称作微微基站小区18-1至18-4(在本文中一般统称为微微基站小区18并且单独称作微微基站小区18)。微微基站16的传输功率比宏基站12的传输功率要小许多，这使微微基站小区18比宏基站小区14要小许多。

在这个示例中，微微基站小区18的每个处于宏基站小区14的对应宏基站小区中。但是，异构蜂窝网络10并不局限于此。宏基站小区14的一部分可能不包括微微基站小区18，而其它宏基站小区14可包括一个或多个微微基站小区18。此外，应当注意，微微基站16-1在本文中称作“邻近”宏基站12-1。同样，微微基站16-2、16-3和16-4分别是宏基站12-2、12-3和12-4的相邻微微基站。因此，其微微基站小区与宏基站(例如宏基站12之一)的宏基站小区接连的微微基站(例如微微基站16之一)在本文中称作宏基站的相邻微微基站。

在常规异构蜂窝网络10中，执行小区选择，使得用户设备(UE)(例如移动装置)连接到提供那些UE的最佳下行链路的宏基站12或者微微基站16。换言之，UE测量来自最近宏基站12的下行链路的接收信号强度以及来自最近微微基站16的下行链路的接收信号强度。如果宏基站12提供UE的最佳下行链路(即，在UE具有最高接收信号强度)，则将宏基站小区14选择作为UE的服务小区。否则，如果微微基站16提供UE的最佳下行链路，则将微微基站小区18选择作为UE的服务小区。对于长期演进(LTE)网络，接收信号强度通常通过参考信号接收功率(RSRP)测量来测量。

在使用常规小区选择方案时出现的一个问题在于，UE连接到提供UE的最佳下行链路、但是不一定提供UE的最佳上行链路的宏或微微基站12或16。这个问题在图2中示出。更具体来说，图2示出按照常规小区选择方案、基于下行链路接收信号强度所确定的、宏基站小区14与微微基站小区18之间的第一小区边缘或边界20。图2还示出基于上行链路路径损耗所确定的、宏基站小区14与微微基站小区18之间的第二小区边缘或边界22。因此，如图2所示，执行小区选择以提供最佳下行链路的常规小区选择方案不一定提供最佳上行链路。具体来说，使用提供最佳下行链路的常规小区选择方案，UE 24会连接到宏基站12。因此，UE 24被提供有最佳下行链路，但是没有最佳上行链路。因此，使用常规小区选择方案，特别是在上行链路方向的数据速率不是最佳的。具体来说，UE 24没有连接到提供UE 24的最佳上行链路的微微基站16。另外，连接到微微基站16的其它UE的链路受到UE 24所生成的较高上行链路干扰不利地影响。

因此，需要用于控制异构蜂窝网络中的小区选择以提供增加数据速率的系统和方法。

发明内容

公开用于控制蜂窝网络中的高功率基站与相邻低功率基站之间的小区选择的系统和方法。高功率基站为对应高功率基站小区提供服务，而低功率基站为对应低功率基站小区提供服务。在一个实施例中，将位于高功率基站小区与低功率基站小区之间的过渡区内的用户设备的业务流的主方向确定为上行链路方向或下行链路方向。用户设备的小区选择则基于用户设备的业务流的主方向来控制，使得如果用户设备的业务流的主方向是下行链路方向，则高功率基站小区的选择得到偏好（favor），而如果用户设备的业务流的主方向是上行链路方向，则低功率基站小区的选择得到偏好。在一个实施例中，高功率或低功率基站小区通过调整低功率基站小区的边界(即，扩展或缩小低功率基站小区的边界)来偏好。在一个优选实施例中，低功率基站小区的边界经由用户设备的用户设备小区选择偏移值来调整。

在一个实施例中，蜂窝网络是异构蜂窝网络，其中高功率基站是宏基站，以及相邻低功率基站是微微基站。宏基站为对应宏基站小区提供服务，而微微基站为对应微微基站小区提供服务。在一个实施例中，将位于宏基站小区与微微基站小区之间的过渡区内的用户设备的业务流的主方向确定为上行链路方向或下行链路方向。用户设备的小区选择则基于用户设备的业务流的主方向来控制，使得如果用户设备的业务流的主方向是下行链路方向，则宏基站小区的选择得到偏好，而如果用户设备的业务流的主方向是上行链路方向，则微微基站小区的选择得到偏好。在一个实施例中，宏或微微基站小区通过调整微微基站小区的边界来偏好。在一个优选实施例中，微微基站小区的边界经由用户设备的用户设备小区选择偏移值来调整。

通过阅读以下结合附图对优选实施例的详细描述之后，本领域的技术人员将会理解本公开的范围以及认识其附加方面。

附图说明

结合在本说明书中并构成其组成部分的附图示出本公开的若干方面，并且连同描述一起用于说明本公开的原理。

图1示出包括宏基站和微微基站的常规异构蜂窝网络；

图2以图形方式示出图1的异构蜂窝网络的常规小区选择方案提供最佳下行链路但是不一定始终提供最佳上行链路；

图3示出按照本公开的一个实施例、异构蜂窝网络中的宏基站和微微基站，其中小区选择基于业务流的主方向、以每个用户设备为基础来控制；

图4示出按照本公开的一个实施例、用于基于用户设备的业务流的主方向来控制宏基站的宏基站小区与相邻微微基站的微微基站小区之间、用户设备的小区选择的过程；

图5是按照本公开的一个实施例、图4的过程的更详细图示；

图6示出按照本公开的一个实施例、宏基站、微微基站和用户设备之间基于用户设备的业务流的主方向的用户设备的小区选择的通信；

图7是按照本公开的一个实施例的宏基站的框图；以及

图8是按照本公开的一个实施例的微微基站的框图。

具体实施方式

下面提出的实施例代表使本领域的技术人员能够实施这些实施例的必要资料，并且示出实施这些实施例的最佳模式。通过根据附图阅读以下描述，本领域的技术人员将会理解本公开的概念，并且将会知道本文中没有具体针对的这些概念的应用。应该理解，这些概念和应用落入本公开和所附权利要求书的范围之内。

公开用于基于业务流的主方向来控制蜂窝网络中的高功率基站与相邻低功率基站之间的小区选择的系统和方法。本文所述的实施例集中于异构蜂窝网络，其中高功率基站具体来说是宏基站，以及低功率基站是微微基站。但是，本公开并不局限于此。高功率基站和低功率基站可以是在传输功率方面具有相当大的差异的蜂窝网络中的任何两个基站。例如，本公开也可适用于其中高功率基站是典型基站以及低功率基站是中继器的实施例。

图3示出异构蜂窝网络26的一个示范实施例，其中小区选择基于业务流的主方向来控制。如所示，异构蜂窝网络26包括具有对应宏基站小区30的宏基站28以及具有对应微微基站小区34的微微基站32。微微基站32在本文中称作宏基站28的相邻微微基站，因为微微基站32的微微基站小区34与宏基站28的宏基站小区30接连。具体来说，如本文所使用，当宏基站小区完全包含微微基站小区时，当宏基站小区覆盖微微基站小区时，或者当宏基站小区以其它方式与微微基站小区接连时，微微基站邻近宏基站。要注意，虽然图3仅示出一个宏基站28和一个微微基站32，但是异构蜂窝网络26通常包括多个宏基站28，其中宏基站28的至少一部分具有一个或多个相邻微微基站32。

宏和微微基站28和32向位于其对应小区30和34中的用户设备(UE)36至42提供蜂窝通信服务。更具体来说，宏基站28服务于例如UE 36的位于宏基站小区30中的UE。微微基站32服务于例如UE 38的位于微微基站小区34中的UE。微微基站小区34具有主边界44，其基于业务流的主方向、以每个UE为基础、对主要上行链路业务调整到边界48或者对主要下行链路业务调整到边界50。例如，在一个具体实施例中，异构蜂窝网络26是异构长期演进(LTE)蜂窝网络，以及主边界44对应于0分贝(dB)的参考信号接收功率(RSRP)偏移，边界48对应于下式(1)中的负RSRP偏移，以及边界50对应于下式(1)中的正RSRP偏移。要注意，虽然在这个示例中，主要下行链路业务的边界50相对主边界44缩小，但是本公开并不局限于此。例如，主要下行链路业务的边界50可在主边界44之外或者相对主边界44扩大，但是在主要上行链路业务的边界48之内。

按照本公开，位于宏基站小区30与微微基站小区34之间的过渡区46中的UE、例如UE 40和42由宏基站28或微微基站32根据那些UE的业务流的主方向来提供服务。更具体来说，小区选择通过调整微微基站32的边界、基于业务流的主方向、以每个UE为基础来控制。为了便于UE 40的小区选择，如果UE 40的业务流的主方向是下行链路方向，则微微基站小区34的边界对主要下行链路业务流来调整到边界50或分界线。相比之下，如果UE 40的业务流的主方向是上行链路方向，则UE 40的微微基站小区34的边界对主要上行链路业务流来调整到边界48或扩展分界线。因此，在这个示例中，如果UE 40的业务流的主方向是下行链路方向，则UE 40处于宏基站小区30中(即，由宏基站28所服务)，或者如果UE 40的业务流的主方向是上行链路方向，则处于微微基站小区34中(即，由微微基站32所服务)。相同情况对UE 42成立。相比之下，UE 36由宏基站28提供服务，而不管其业务流的主方向，以及UE 38由微微基站32提供服务，而不管其业务流的主方向。

通过基于业务流的主方向调整微微基站小区34的边界，小区选择以每个UE为基础来执行，使得对于位于过渡区46中的UE，宏基站小区30对其业务流的主方向是下行链路方向的UE得到偏好，以及微微基站小区34对其业务流的主方向是上行链路方向的UE得到偏好。这样，UE、例如UE 40和42连接到提供其业务流的主方向的最佳链路的基站28或32。更具体来说，因为宏基站28的传输功率比微微基站32的传输功率明显要高，所以偏好具有业务流的主要下行链路方向的UE的宏基站28对那些UE产生更好下行链路并且因而产生更高的数据速率。同样，因为UE 40和42具有较低传输功率，所以偏好具有业务流的主要上行链路方向的UE的微微基站32(其比宏基站28更为接近UE 40和42)对那些UE产生最佳上行链路并且因而产生更高数据速率。

图4是示出按照本公开的一个实施例、基于业务流的主方向的小区选择过程的流程图。在这个实施例中，这个过程由宏基站28来执行。但是，本公开并不局限于此。这个过程备选地可由异构蜂窝网络26中的另一个节点来执行。此外，这个过程优选地用于UE、例如位于过渡区46中UE40和42的小区选择。但是，这个过程可用于位于宏和微微基站小区30和34中的所有UE的小区选择。

首先，宏基站28确定UE的业务流的主方向(步骤100)。在这个示例中，UE是UE 40。任何适当的过程可用来确定UE 40的业务流的主方向。在一个实施例中，宏基站28得到UE 40的上行链路缓冲器大小，并且然后基于上行链路缓冲器大小来确定UE 40的业务流的主方向。上行链路缓冲器大小是在UE 40的上行链路缓冲器中等待的、将要经由UE 40的上行链路所传送的数据量。例如，如果UE 40的上行链路缓冲器大小大于或等于预定义上行链路缓冲器大小阈值，则宏基站28可确定UE 40的业务流的主方向是上行链路方向。否则，业务流的主方向可确定为下行链路方向。类似地，宏基站28可得到UE 40的下行链路缓冲器大小，并且然后基于下行链路缓冲器大小来确定业务流的主方向。下行链路缓冲器大小是在下行链路缓冲器中等待的、将要经由到UE 40的下行链路传送给UE 40的数据量。例如，如果UE 40的下行链路缓冲器大小大于或等于预定义下行链路缓冲器大小阈值，则宏基站28可确定UE 40的业务流的主方向是下行链路方向。否则，业务流的主方向可确定为上行链路方向。

在另一个实施例中，宏基站28得到UE 40的上行链路缓冲器大小和下行链路缓冲器大小，并且然后基于UE 40的上行链路和下行链路缓冲器大小来确定UE 40的业务流的主方向。作为一个示例，如果上行链路缓冲器大小大于下行链路缓冲器大小，则宏基站28可确定UE 40的业务流的主方向是上行链路方向。否则，业务流的主方向是下行链路方向。作为另一个示例，如果上行链路缓冲器大小大于或等于下行链路缓冲器大小和预定义阈值之和，则宏基站28可确定UE 40的业务流的主方向是上行链路方向。否则，业务流的主方向是下行链路方向。作为又一个示例，如果上行链路缓冲器大小大于或等于预定义上行链路缓冲器阈值并且上行链路缓冲器大小大于或等于下行链路缓冲器大小和预定义阈值之和，则宏基站28可确定UE 40的业务流的主方向是上行链路方向。否则，业务流的主方向是下行链路方向。

类似地，作为一个示例，如果下行链路缓冲器大小大于上行链路缓冲器大小，则宏基站28可确定UE 40的业务流的主方向是下行链路方向。否则，业务流的主方向是上行链路方向。作为另一个示例，如果下行链路缓冲器大小大于或等于上行链路缓冲器大小和预定义阈值之和，则宏基站28可确定UE 40的业务流的主方向是下行链路方向。否则，业务流的主方向是上行链路方向。作为又一个示例，如果下行链路缓冲器大小大于或等于预定义下行链路缓冲器阈值并且下行链路缓冲器大小大于或等于上行链路缓冲器大小和预定义阈值之和，则宏基站28可确定UE 40的业务流的主方向是下行链路方向。否则，业务流的主方向是上行链路方向。

一旦确定UE 40的业务流的主方向，则宏基站28基于UE 40的业务流的主方向来控制UE 40的小区选择，以便在UE 40的业务流的主方向是下行链路方向时偏好宏基站小区30的选择，以及在UE 40的业务流的主方向是上行链路方向时偏好微微基站小区34的选择(步骤102)。更具体来说，如果UE 40的业务流的主方向是下行链路方向，则宏基站28为了UE 40的小区选择而将微微基站小区34的边界设置到主要下行链路业务的边界50，由此偏好UE 40的宏基站小区30的选择，而使微微基站小区34的选择更加困难。相反，如果UE 40的业务流的主方向是上行链路方向，则宏基站28为了UE 40的小区选择而将微微基站小区34的边界设置到主要上行链路业务的边界48，由此偏好UE 40的微微基站小区34的选择，而使宏基站小区30的选择更加困难。这样，UE 40连接到提供UE 40的业务流的主方向的最佳链路的基站28或32。

图5是更详细地示出按照本公开的一个实施例、图4的过程的流程图。UE 40再次用于这个示例，以及在起始点，它连接到宏基站小区30。但是，这个过程可用于其它UE 36、38和42或者至少过渡区46中的另一UE 42的小区选择。首先，宏基站28从UE 40得到来自宏基站28和相邻微微基站32的下行链路的接收信号强度值(步骤200)。在一个实施例中，异构蜂窝网络26是LTE蜂窝网络，以及接收信号强度值包括由UE 40对于来自宏基站28的下行链路所测量的RSRP值以及由UE 40对于来自微微基站32的下行链路所测量的RSRP值。注意，本文所公开的概念与LTE Release 8兼容。但是，它们并不局限于LTE Release 8。它们能够应用于采用小区选择的相同原理的任何类型的无线通信系统。另外，宏基站28从UE 40得到上行链路缓冲器大小(步骤202)。

然后，宏基站28确定UE 40的业务流的主方向是否为上行链路方向(步骤204)。更具体来说，在这个实施例中，如果UE 40的上行链路缓冲器大小大于或等于预定义上行链路缓冲器大小阈值并且上行链路缓冲器大小大于或等于UE 40的下行链路缓冲器大小和预定义阈值之和，则宏基站28确定UE 40的业务流的主方向是上行链路方向。否则，业务流的主方向是下行链路方向。

如果UE 40的业务流的主方向是上行链路方向，则宏基站28将UE 40的UE小区选择偏移设置成偏好微微基站小区34的选择的值(步骤206)。相反，如果UE 40的业务流的主方向不是上行链路方向(即，是下行链路方向)，则宏基站28将UE 40的UE小区选择偏移设置成偏好宏基站小区30的选择的值(步骤208)。更具体来说，在本优选实施例中，微微基站小区34的边界使用UE小区选择偏移、以每个UE为基础来调整。如果UE 40的业务流的主方向是上行链路方向，则UE 40的UE小区选择偏移设置成某个值(M)，其将微微基站小区34的边界设置到主要上行链路业务的边界48。相反，如果UE 40的业务流的主方向是下行链路方向，则UE 40的UE小区选择偏移设置成某个值(K)，其将微微基站小区34的边界设置到主要下行链路业务的边界50。

随后，无论从步骤206还是208继续进行，宏基站28都确定是否将对UE 40执行切换(步骤210)。在这个示范实施例中，UE 40当前位于宏基站小区30中(即，由宏基站28所服务)，以及宏基站28基于从宏和微微基站28和32到UE 40的下行链路的接收信号强度值来确定是否将要执行从宏基站28到微微基站32的切换。但是，应当注意，在UE 40最初位于微微基站小区34中的情况下，相似过程可用来确定是否将要执行从微微基站32到宏基站28的切换。

更具体来说，在一个实施例中，异构蜂窝网络26是LTE网络，以及如果UE 40当前位于宏基站小区30中(即，由宏基站28所服务)，则宏基站28确定将要对UE 40执行从宏基站28到微微基站32的切换，并且：

其中，RSRP_PICO是由UE 40对于从微微基站32到UE 40的下行链路所测量的RSRP值，RSRP_MACRO是由UE 40对于从宏基站28到UE 40的下行链路所测量的RSRP值，HO_Hysteresis是防止UE在宏与微微基站28和32之间过于频繁切换的滞后值，以及UE_Cell_Selection_Offset是UE 40的UE小区选择偏移，其在步骤206或者步骤208中设置。具体来说，当使用等式(1)时，如果业务流的主方向是上行链路方向，则在步骤206，UE 40的UE小区选择偏移设置成作为负值的值(M)。在一个实施例中，这个负值处于0与宏和微微基站28和32的传输功率间的差（单位，dB）之间。在LTE中，宏与微微基站28和32的传输功率之间的差通常是16 dB或者接近16 dB的值。相反，如果业务流的主方向是下行链路方向，则在步骤208，UE 40的UE小区选择偏移设置成值(K)，其中K根据特定实现可以是正值、0或负值。如果K是正值，则K大于或等于0，并限制到接近0的小值。正值引起微微基站小区34的边界从主边界44缩小到主要下行链路业务的边界50。如果K是负值，则K是负值但限制到|K|<|M|。在这种情况下，与图3所示相反，主要下行链路业务的边界50相对主边界44来扩大，但是在主边界44与主要上行链路业务的边界48之间。

在继续进行之前，应当注意，在UE 40最初位于微微基站小区34中的情况下，相似过程可用来确定是否将要对UE 40执行从微微基站32到宏基站28的切换。具体来说，对于这种确定，等式(1)修改成：

但是要注意，与确定是否执行从宏基站28到微微基站32的切换时所使用的对应值相比，UE小区选择偏移值(M和K)可以相同或不同。

如果宏基站28确定将不执行切换，则该过程结束。否则，如果将要执行切换，则宏基站28为UE 40分配上行链路和下行链路资源(步骤212)。特定的所分配资源可根据用于异构蜂窝网络26的特定协议而改变。例如，如果异构蜂窝网络26是LTE网络，则为UE 40所分配的上行链路和下行链路资源可包括为上行链路所分配的一个或多个资源块以及为UE 40的下行链路所分配的一个或多个资源块。作为补充或替代，所分配资源可包括所分配的下行链路控制信道资源。例如，如果异构蜂窝网络26是LTE网络，则所分配资源优选地包括物理下行链路控制信道(PDCCH)资源(例如控制信道元素(CCE))以及为UE 40所分配的时隙。由于UE 40的PDCCH资源的预先分配—具有或者没有宏基站28与微微基站32之间的先前协商，宏基站28知道UE 40的所分配PDCCH资源，并且能够采取适当动作，以便不干扰在切换之后从微微基站32传送到UE 40的下行链路控制信令。

关于PDCCH分配，应当注意，PDCCH资源分配能够是使得在切换到微微基站32之后对UE 40的PDCCH传输的数量减少(若不是最小化的话)。作为一个示例，可对UE 40应用持续调度。因此，通过仅使用给定PDCCH一次，在上行链路中向UE 40分配资源，并且这种分配是有效的，直到异构蜂窝网络26决定停止该分配的时刻。初始上行链路分配能够对商定的PDCCH资源进行。如果存在等待经由上行链路所传送的大量数据，则可预期持续调度。在这种情况下，上行链路调度仅执行两次，在开始时一次以及在会话结束时一次。

作为另一个示例，在切换到微微基站32之后可使用UE 40的半持续调度。半持续调度暗示上行链路调度在会话开始时进行，以及UE 40在预定义周期进行周期传送。通过这种调度策略，调度准予仅传送两次，在开始时一次以及在传输结束时一次。半持续调度可用于例如基于因特网协议的语音(VoIP)等的服务或者用于大量业务。

作为另一个示例，宏基站28为UE 40分配PDCCH资源。微微基站32可按其意愿来调度UE 40，但是将要使用的PDCCH资源保持固定在由宏基站28为UE 40所分配的PDCCH资源。在更一般上下文中，宏基站28能够对微微基站32指定用于微微基站小区34的扩展边界中的每一个UE（包括UE 40的）PDCCH资源。最后，应当注意，在切换之后，UE 40可使用传送时间间隔(TTI)捆绑方式来调度。

在上行链路和下行链路资源的分配之后，宏基站28则实行UE 40从宏基站28到微微基站32的切换(步骤214)。更具体来说，在一个实施例中，宏基站28向微微基站32发送切换请求以及定义为UE 40所分配的上行链路和下行链路资源的信息。作为响应，微微基站32返回切换确认或者UE 40的经修改上行链路和/或下行链路资源。然后，宏基站28采用来自步骤212的上行链路和下行链路资源或者来自微微基站32的经修改的上行链路和下行链路资源来完成切换。使用图5的过程，使上行链路小区吞吐量和用户吞吐量为最大，因为使可能获益于由微微基站32所提供的更好上行链路的最大数量的用户切换到微微基站32。

图6示出按照本公开的一个实施例、宏基站28、微微基站32和UE 40基于UE 40的业务流的主方向来控制小区选择以及以其为基础来执行UE 40的切换的操作。本论述再次集中于从宏基站28到微微基站32的切换，但是类似过程可用于从微微基站32到宏基站28的切换。首先，宏基站28向UE 40发送(一个或多个)RSRP阈值(步骤300)。(一个或多个)RSRP阈值是由UE 40用来确定UE 40是否位于过渡区46中的(一个或多个)值。在一个实施例中，RSRP阈值是宏基站28的RSRP和微微基站32的RSRP的比率，其可称作g_threshold。例如，g_threshold可以是宏基站28的传输功率与微微基站32的传输功率之间的差。在这里要注意，当UE 40(或者任何UE)正测量来自服务宏基站小区30以及来自相邻微微基站小区34或者来自任何相邻小区的RSRP时，UE 40不知道所测量相邻小区是否是微微基站小区、宏基站小区还是任何类型的小区。通过从各个相邻小区向服务宏基站28报告测量，宏基站28能够检测所报告RSRP值是源自宏基站小区还是源自微微基站小区，或者一般来说，宏基站28能够从所报告RSRP值及关联小区ID来识别相邻小区的类型。除了(一个或多个)RSRP阈值之外，宏基站28还向UE 40发送对UE 40的上行链路缓冲器大小的请求(步骤302)。

UE 40得到从宏基站28和微微基站32到UE 40的下行链路的RSRP值(步骤304)。然后，基于RSRP值和(一个或多个)RSRP阈值，UE 40确定RSRP报告将发送给宏基站28(步骤306)。更具体来说，在一个示范实施例中，RSRP阈值是g_threshold，以及如果下式成立，则UE 40确定将要发送RSRP报告：

            (2)

在确定RSRP报告将要发送给宏基站28之后，UE 40确定UE 40的上行链路缓冲器大小(步骤308)，并且向宏基站28发送RSRP报告和UE 40的上行链路缓冲器大小(步骤310)。上行链路缓冲器大小是在UE 40的上行链路缓冲器中存储的、等待经由UE 40的上行链路的传输的数据量。RSRP报告包括下列任一个：(1) 来自宏基站28的下行链路的RSRP值以及来自微微基站32的下行链路的RSRP值，或者(2) 来自宏基站28的下行链路的RSRP值与来自微微基站32的下行链路的RSRP值的比率。

随后，宏基站28基于UE 40的上行链路缓冲器大小来确定UE 40的业务流的主方向(步骤312)。更具体来说，在这个实施例中，如果UE 40的上行链路缓冲器大小大于或等于预定义上行链路缓冲器大小阈值并且上行链路缓冲器大小大于或等于UE 40的下行链路缓冲器大小和预定义阈值之和，则宏基站28确定UE 40的业务流的主方向是上行链路方向。否则，业务流的主方向是下行链路方向。下行链路缓冲器大小是下行链路缓冲器中存储的、等待经由从宏基站28到UE 40的下行链路传送给UE 40的数据量(假定UE 40当前由宏基站28所服务)。

然后，宏基站28基于UE 40的业务流的主方向来设置UE 40的UE小区选择偏移(步骤314)。更具体来说，在这个实施例中，如果业务流的主方向是上行链路方向，则宏基站28将UE 40的UE小区选择偏移设置成作为负值的值(M)。在一个实施例中，这个负值处于0与宏和微微基站28和32的传输功率间的差之间。在LTE中，宏与微微基站28和32的传输功率之间的差通常是16 dB。相反，如果业务流的主方向是下行链路方向，则宏基站28将UE 40的UE小区选择偏移设置成作为正值、0或负值的值(K)，这取决于特定实现，如上所述。

在这个示例中，宏基站28则确定将要基于UE 40的UE小区选择偏移、对UE 40来执行从宏基站28到微微基站32的切换(步骤316)。注意，在UE 40当前位于微微基站32中的情况下，可执行相似过程，以确定是否将要对UE 40执行从微微基站32到宏基站28的切换。在这个实施例中，如果UE 40当前处于宏基站单元30中(即，由宏基站28所服务)并且下式成立，则宏基站28确定将要执行UE 40从宏基站28到微微基站32的切换：

其中，RSRP_PICO是由UE 40对于从微微基站32到UE 40的下行链路所测量的RSRP值，RSRP_MACRO是由UE 40对于从宏基站28到UE 40的下行链路所测量的RSRP，HO_Hysteresis是防止UE在宏与微微基站28和32之间过于频繁切换的滞后值，以及UE_Cell_Selection_Offset是在步骤314所设置的、UE 40的UE小区选择偏移。

随后，宏基站28为UE 40分配上行链路和下行链路资源(步骤318)。在上行链路和下行链路资源的分配之后，宏基站28向微微基站32发送切换请求以及定义为UE 40所分配的上行链路和下行链路资源的信息(步骤320)。作为响应，微微基站32向宏基站28返回切换确认(步骤322)。备选地，微微基站32可返回定义UE 40的经修改的上行链路和/或经修改的下行链路资源的信息。然后，宏基站28通过向UE 40发送切换命令来完成切换(步骤324)。响应切换命令，UE 40使用所分配资源来建立与微微基站32的上行链路和下行链路。使用图6的过程，使上行链路小区吞吐量和用户吞吐量为最大，因为使可能获益于由微微基站32所提供的更好上行链路的最大数量的用户切换到微微基站32。

图7和图8分别是按照本公开的一个实施例的宏和微微基站28和32的框图。如图7所示，宏基站28包括收发器子系统52和处理子系统54。收发器子系统52一般包括模拟组件、以及在一些实施例中包括数字组件，以用于向/从宏基站小区30中的UE发送和接收数据。从无线通信协议观点来看，收发器子系统52实现第1层(即，物理或“PHY”层)的至少一部分。处理子系统54一般实现第1层的任何其余部分以及无线通信协议中的更高层(例如，第2层(数据链路层)、第3层(网络层)等)的功能。当然，每个功能协议层并且因此收发器子系统52和处理子系统54的详细操作将根据特定实现以及由宏基站28所支持的标准或多个标准而改变。

类似地，如图8所示，微微基站32包括收发器子系统56和处理子系统58。收发器子系统56一般包括模拟组件、以及在一些实施例中包括数字组件，以用于向/从微微基站小区34中的UE发送和接收数据。从无线通信协议观点来看，收发器子系统56实现第1层(即，物理或“PHY”层)的至少一部分。处理子系统58一般实现第1层的任何其余部分以及无线通信协议中的更高层(例如，第2层(数据链路层)、第3层(网络层)等)的功能。当然，每个功能协议层并且因此收发器子系统56和处理子系统58的详细操作将根据特定实现以及由微微基站32所支持的标准或多个标准而改变。

本领域的技术人员将会理解，图7和图8中的宏和微微基站28和32的框图必要地省略不是完全了解本公开所必需的许多特征。例如，虽然未示出处理子系统54和58的全部细节，但是本领域的技术人员将会知道，处理子系统54和58包括一个或数个通用或专用微处理器或者编程有适当软件和/或固件的其它微控制器，以执行本文所述的宏和微微基站28和32的部分或全部功能性。作为补充或替代，处理子系统54和56可包括各种数字硬件块(例如，一个或多个专用集成电路(ASIC)、一个或多个现货供应数字和模拟硬件组件或者它们的组合)，其配置成执行本文所述宏和微微基站28和32的功能性的部分或全部。

在本公开中通篇使用下列首字母缩写词。

- ASIC  专用集成电路

- CCE   控制信道元素

- dB 分贝

- LTE   长期演进

- PDCCH 物理下行链路控制信道

- RSRP  参考信号接收功率

- TTI   传送时间间隔

- UE 用户设备

- VoIP  基于因特网协议的语音

本领域的技术人员将会知道对本公开的优选实施例的改进和修改。所有这类改进和修改均被认为属于本文所公开的概念和以下权利要求书的范围之内。