DD，同时微微小区层可以使用TDD或FDD。在一些这种情况下，由于传播特性，宏小区可以工作在相对于微微小区的较低载波频率上。为了更好地使用可用带宽以及为了业务流适配，可以在微微小区处使用TDD。例如，如图15的示例所示，宏小区可以在FDD下工作在{fD1，fm} 土 Afm/2上，且微微小区可以在TDD下工作在{fe2}±Afs/2上，其中，fD1、fm和Af m分别是宏小区使用的下行链路载波频率、上行链路载波频率以及带宽，且匕和Λ f s是使用TDD的微微小区所使用的载波频率和信道带宽。12可以优选地高于€1)1和€111。备选地，如图16的示例所示，微微小区可以在FDD下工作在{fD2，fU2} 土 Afs/2上，其中，fD2、fU2和Af s分别是微微小区使用的下行链路载波频率、上行链路载波频率以及带宽。LTE FDD载波频率可以从以下各项中选择:由3GPP TS 36.101中表5.5-1定义的演进通用陆地无线接入(E-UTRA)工作频带I?14或17?28，反之可以选择E-UTRA工作频带33?44用于微微小区的TDD操作。在一些情况下,UE可以具有通向宏小区和微微小区的双重连接性。在这种情况下多服务小区场景可以实现为载波聚合，且PCell使用宏FDD以及一个或多个SCell使用微微小区TDD/FDD。
[0091]如果经由RRH来部署较高频率上的微微小区，则可以将多服务小区场景视为具有多个定时提前(TA)的eNB内载波聚合，除了载波聚合可以具有不同双工模式FDD和TDD。当前在3GPP版本11中讨论的CA方案假定了载波聚合具有相同双工模式，要么FDD要么TDD0如果重复使用现有的CA设计，则微微小区和宏小区可以紧密工作。然而，如果宏小区和微微小区要更独立地工作，则在各种实施例中可以引入至少7个新的设计方案。这些新的设计方案也可以适用于部署为独立eNB的微微小区和宏小区的情况。
[0092]首先，由于微微小区中良好的信道状况，在一些实施例中，可以禁用跨载波调度，且针对微微小区和宏小区上的数据发送的UL/DL授权可以来自相应小区。备选地，可以在微微小区上发送宏小区和微微小区的UL/DL授权。S卩，针对PCell和SCell的UL/DL授权可以来自于SCell。在当前LTE CA中，针对PCell的UL/DL授权尽可以来自于PCelI。在微微小区环境中，由于PAPR和UE功率可以不是主要顾虑，可以向微微小区(即，SCell)发送UL PUCCH控制信号，例如与微微小区相对应的ACK/NACK/CSI。为了实现这点，可以在RRCConnect1nReconfigurat1n消息中添加比特，使得当添加SCell时，UE 了解将向SCell发回与SCell相对应的UL控制信号。这在图17a和17b中示出，且所公开的修改由下划线来表示。备选地，宏小区和微微小区的UL控制信号(例如，ACK/NACK/CSI)可以去往微微小区，以节约UE功率。
[0093]第二，在一些实施例中，宏PCell和微微小区SCell可以具有分别的调度器，如图18和图19的示例所示。可以在宏小区和微微小区之间交换信息(例如在UE将与宏小区通信时的子帧)，使得两个调度器可以协调数据发送。
[0094]第三，在一些实施例中，如果UE将针对宏PCell和微微小区SCell的业务加以分离，则UE可以报告分别的BSR/SR，以反映与微微小区和宏小区相对应的缓冲数据。可以向对应宏小区和微微小区发送BSR/SR。还可以将BSR/SR —起向宏小区或微微小区发送。
[0095]第四，在一些实施例中，例如在微微小区上具有快速适配的动态TDD的情况下，可以在IE Rad1ResourceConfigCommonSCelI中添加比特，使得UE 了解在微微小区中使用了具有快速适配的动态TDD。这在图20中示出，且所公开的修改由下划线来表示。UE 了解到:对于添加的SCell，UE可以忽略在tdd-Config-rlO中规定的TDD UL/DL配置，且代之以使用预配置的信息来假定某些子帧为静态DL/UL子帧且其余子帧为灵活子帧。例如，如果仅UL/DL配置0、1、2和6被允许在SCell中(g卩，具有5ms DL至UL切换点周期的配置)，则UE可以假定子帧0、1、5和6是包括特殊子帧在内的静态DL子帧，子帧2和7是静态UL子帧，且其余子帧是灵活子帧。可以向UE预配置静态UL/DL子帧，或者可以向UE发信号通知静态UL/DL子帧。
[0096]第五，在一些实施例中，UE在PCell和SCell中可以具有不同的C-RNTI。例如，为了便于宏小区在添加一个或多个微微小区作为SCell时向UE指派微微C-RNTI，每个微微小区可以为能够具有与宏小区和微微小区的双重连接性的UE预留某些C-RNTI。微微小区可以向宏小区通知所预留的C-RNTI。当宏小区添加微微小区作为UE的SCell时，宏小区可以从预留池中挑取微微小区C-RNTI，并向UE指派该微微小区C-RNTI。备选地，取代微微小区预留C-RNTI，只要宏小区需要微微小区C-RNTI时，宏小区就可以发信号通知微微小区以请求 C-RNTL.
[0097]第六，在一些实施例中，微微小区可以向宏eNB发送其系统信息，例如TDD配置。当宏eNB添加微微小区作为SCell时，宏eNB可以向UE传递微微小区的系统信息。如果在微微小区中使用具有慢速适配的动态TDD配置，则微微小区可以向宏小区通知实际的TDD配置。如果在微微小区中使用具有快速适配的动态TDD配置，则微微小区可以向宏小区通知在微微小区中使用具有快速适配的动态TDD。如果静态UL/DL子帧未被预配置，则微微小区可以向宏小区通知静态UL/DL子帧。
[0098]第七，在一些实施例中，宏PCell使用FDD且微微SCell使用TDD。如果需要向宏PCell发送PCell和SCell的ACK/NACK，为了支持聚合FDD和TDD的ACK/NACK，可以使用PUCCH格式3 (其可以携带高到20个比特的ACK/NACK)从FDD和TDD载波传输ACK/NAC比特。在TDD配置5的最差情况中，其中，子帧2需要反馈九个DL子帧中的I3DSCH发送的ACK/NACK，与FDD载波的ACK/NACK结合，这20个比特可以是充足的，因为每个I3DSCH发送支持最多2个码字。在宏PCell使用TDD且微微SCell使用FDD的情况下，如果需要向宏PCell发送PCell和SCell的ACK/NACK，则可以在多个子帧上和/或码字上对SCell的ACK/NACK加以复用或捆绑，并在PCell的TDD UL子帧上发送。
[0099]如果将微微小区部署为具有其自己的回程的独立eNB，则eNB间载波聚合可以不同于当前CA，当前CA家就顶eNB内载波聚合。与上述RRH概况的差异是:在宏小区和微微小区之间的任何通信可以涉及X2消息和回程延迟。可以公开与这种场景相关的至少五个方案。
[0100]首先，由于X2上的巨大延迟，宏小区和微微小区可以比经由RRH来部署微微小区的情况更独立地工作。因此，在一些实施例中，可以不适用跨载波调度。微微小区的UL控制信号(例如与微微小区中的发送相对应的ACK/NACK/CSI)可以去往微微小区，且RRCConnect1nReconfigurat1n消息中的比特可以用于实现这点，如图17a和17b所示。
[0101]第二，在一些情况下，例如在独立微微小区eNB的情况下，宏小区和微微小区均可以具有其自己的调度器，如图18和图19的示例所示。在实施例中，可以在宏小区和微微小区之间经由X2来交换信息(例如，在UE将与宏小区通信时的子帧)，使得两个调度器可以协调数据发送，以在UE最大功率约束下可靠地维持两个通信链路。在一些实施例中，UE可以报告分别的BSR/SR，以反映微微小区和宏小区上的缓冲数据。
[0102]第三，在一些实施例中，例如微微小区中具有快速适配的动态TDD的情况，可以在IE Rad1ResourceConf igCommonSCel I中添加比特，以向UE通知在微微小区中使用具有快速适配的动态TDD。这在图20中示出。可以向UE预配置静态UL/DL子帧，或者可以向UE发信号通知静态UL/DL子帧。
[0103]第四，在一些实施例中，可以在宏PCell和微微小区SCell中使用不同的C-RNTI。类似于RRH情况，这可以通过例如微微小区预留一些C-RNTI供宏小区使用来实现。备选地，宏小区可以在需要时经由X2向微微小区显式请求C-RNTI。
[0104]第五，在一些实施例中，微微小区可以经由X2向宏eNB发送其系统信息，例如TDD配置。当宏eNB添加微微小区作为SCell时，eNB可以向UE传输微微小区的系统信息。如果在微微小区中使用具有慢速适配的动态TDD配置，微微小区可以经由X2向宏小区通知实际TDD配置。如果在微微小区中使用具有快速适配的动态TDD配置，微微小区可以经由X2向宏小区通知在微微小区中使用具有快速适配的的动态TDD。如果未预配置静态UL/DL子帧，微微小区可以经由X2向宏eNB通知静态UL/DL子帧。
[0105]在实施例中，如果针对宏小区和微微小区的同时UE发送超过了 UE最大功率，则UE可以首先按比例缩小针对微微小区的发送功率，并将针对宏小区的发送加以优先化。备选地，为了避免超过UE最大功率，网络可以通过令UE向微微小区发送所有数据来避免针对宏小区和微微小区的同时发送。例如，在宏小区和微微小区部署为eNB内CA且宏小区和微微小区紧密工作(例如，一个调度器用于这二者)的情况下，网络可以通过调度UE在SCell上发送所有数据向微微小区路由宏小区数据。
[0106]在示例场景中，可以将微微小区处的辅分量载波部署为非单独载波。S卩，UE可以不通过微微小区连接到LTE网络。取而代之地，UE可以首先经由宏小区连接到LTE演进分组核心(EPC)，且随后可以切换到微微小区。聚合系统信息可以由宏小区来广播。微微小区可以向宏小区通知相关系统信息，例如，TDD配置。在更新系统信息的事件中，微微小区或宏小区可以寻呼连接到微微小区的UE，和/或可以由微微小区在专用RRC信令中向这些UE发送差分系统信息。为了减少系统信息开销，可以较不频繁地发送包含微微小区SI在内的SIBo在实施例中，新的SIB消息可以包括该信息。在一些实施例中，CA中的现有方案可以用于处理微微小区的SIB改变。例如，可以首先释放SCell，然后可以添加相同的SCell，且这可以使用单一 RRC重配置消息来完成。由于网络进入操作(network entry operat1n)是通过宏小区的，该改变可以不影响网络进入时间(network entry time)。微微小区的一些RRC功能(优选地，对延迟不敏感的那些功能)可以在宏小区处执行。例如可以在宏小区处进行HO判定执行。
[0107]上述方案可以由网络单元来实现。关于图21示出了简化的网络单元。在附图中，网络单元3110包括处理器3120和通信子系统3130，其中，处理器3120和通信子系统3130协作以执行上述方法。
[0108]此外，上述方案可以由UE来实现。下面关于图22描述了一个示例设备。UE 3200通常是具有语音和数据通信能力的双向无线通信设备。UE 3200 —般具有与互联网上其他计算机系统通信的能力。取决于所提供的具体功能，UE可以被称为例如:数据消息收发设备、双向寻呼机、无线电子邮件设备、具有数据消息收发能力的蜂窝电话、无线互联网电器、无线设备、移动设备、或数据通信设备。
[0109]在UE 3200支持双向通信的情况下，其可以并入通信子系统3211，通信子系统3211包括接收机3212和发射机3214以及关联组件，例如一个或多个天线单元3216和3218、本地振荡器(LO) 3213、以及处理模块(例如，数字信号处理器(DSP) 3220)。如对于通信领域技术人员显而易见的:通信子系统3211的具体设计将取决于该设备预期工作所在的通信网络。
[0110]网络接入要求还将根据网络3219的类型而变化。在一些网络中，网络接入与UE3200的订户或用户相关联。UE可以要求可拆卸式用户身份模块(RUIM)或订户身份模块(SIM)卡，以在网络上工作。SM/RUM接口 3244 —般类似于可以插入和弹出SM/RUM卡的卡槽。SM/RUM卡可以具有存储器，且保持很多关键配置3251，、以及其他信息3253 (例如，标识和订户相关信息)。
[0111]当已完成了所要求的网络注册或激活过程时，UE 3200可以通过网络3219来发送和接收通信信号。如附图所示，网络3219可以包含与UE通信的多个基站。
[0112]向接收机3212输入由天线3216通过通信网络3219接收到的信号，接收机3212可以执行常见接收机功能，如信号放大、下变频、滤波、信道选择等。对接收信号的模数(A/D)转换允许更复杂的通信功能(例如要在DSP 3220中执行的解调和解码)。以类似方式，由DSP 3220处理要发送的信号(包括例如调制和编码)并且输入发射机3214用于数模(D/A)转换、上变频、滤波、放大以及经由天线3218通过通信网络3219发送。DSP 3220不仅处理通信信号，还提供接收机和发射机控制。例如，可以通过在DSP 3220中实现的自动增益控制算法来自适应地控制在接收机3212和发射机3214中对通信信号应用的增益。
[0113]UE 3200—般包括对设备的整体操作进行控制的处理器3238。由通信子系统3211执行包括数据和语音通信在内的通信功能。处理器3238还与其他设备子系统交互，例如，显示器3222、闪存3224、随机存取存储器(RAM) 3226、辅助输入/输出(I/O)子系统3228、串口 3230、一个或多个键盘或键区3232、扬声器3234、麦克风3236、其他通信子系统3240 (例如，短距通信子系统和一般表示为3242的任何其他设备子系统)。串口 3230可以包括USB端口或本领域技术人员已知的其他端口。
[0114]图中示出的一些子系统执行与通信有关的功能，而