ALIGNING RADIO RESOURCE CONTROL PARAMETERS IN SMALL CELL DEPLOYMENTS
Disclosed in some examples are methods, systems, eNodeBs, UEs, and machine readable mediums which coordinate one or more wireless protocol properties between an anchor base station and an assisting base station.
This application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 61/841,230, filed Jun. 28, 2013, which is incorporated herein by reference in its entirety.
TECHNICAL FIELDEmbodiments pertain to operations and communications performed by electronic devices in wireless networks. Some embodiments relate to operations for management of radio resource control (RRC) parameters in wide area wireless networks.
BACKGROUNDStandards for next generation mobile networks, such as 3GPP Long Term Evolution (LTE)/Long Term Evolution-Advanced (LTE-A) cellular phone network standards (hereinafter collectively referred to as “LTE”), have begun the design and implementation of small cell (e.g., micro, femto, or pico cell) deployments. Small cell deployments may operate in licensed or unlicensed spectrum, and typically provide an operation range from tens of meters to a kilometer; whereas macro cell deployments typically have a much wider operation range in the tens of kilometers.
3GPP TR 36.842 discusses multiple LTE network deployment scenarios including a deployment scenario where macro and small cells on different carrier frequencies (inter-frequency) are connected via non-ideal backhaul. As a result, the network equipment such as evolved NodeB (eNodeB or “eNB”) equipment must define which control plane functions will be performed by the macro “Anchor” eNB and which functions will be performed by the micro or “Assisting” eNB.
The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.
The following techniques and system configurations describe deployment scenarios that are used to assist the management and coordination of operating parameters of macro and small cells. Specifically, the following describes deployment scenarios where macro and small cells on different carrier frequencies are connected via non-ideal backhaul. The following techniques and configurations are designed to more efficiently operate small cell deployments, through the exchange, alignment, and coordination of RRC parameters in the small cell deployments.
In deployment scenarios where macro and small cells on different carrier frequencies (inter-frequency) are connected via non-ideal backhaul, the control plane architecture of the deployment is at the very initial standards development stages. One of the problems associated with these scenarios is determining which control plane functions will be performed by the Anchor eNB and which functions will be performed by the Assisting eNB, and how both eNBs will co-ordinate between each other. For example, the following techniques describe a coordination scenario for Idle mode and DRX operations in a LTE network, through the management and deployment of Idle mode and DRX parameter configurations.
For the case where both the macro cell eNB and the small cell eNB have a separate 51 interface to a serving gateway (S-GW), it will be difficult without coordination for either eNB to know when a particular UE on the network is inactive. Without knowledge whether a UE is inactive, the eNB may not be able to properly release the connection or trigger DRX mode. The following techniques describe the use of an RRC Inactivity Timer control and DRX parameter exchange between the Anchor eNB and Assisting eNB, to enable the eNBs to coordinate operations so that connected UEs can be power optimized, for example.
The following discusses mechanisms to ensure that various protocol parameters are properly synchronized between the anchor eNB and the assisting eNB. For example, idle mode and DRX mode operations may depend on one or more parameters such as inactivity timers, a UE's indication for power preference information (PPI), and discontinuous reception (DRX) parameters. If one or more of these parameters are not synchronized, the UE may waste power staying in an active state for longer than necessary. For example, the anchor eNB may not release the RRC connection until after the assisting eNB, thus causing the UE to stay in RRC connected mode longer than necessary. The parameters for these operations may be utilized in particular for cases when the Assisting eNB and the Anchor eNB each has a separate S1 interface to the MME (e.g., as shown in
In the following configurations, the functions of triggering Idle mode, DRX mode, and PPI operations during Connected state and PPI are divided between the respective Anchor eNB and Assisting eNB to ensure simplicity and consistency of UE behavior. In existing network deployments, there is generally no coordination between Anchor eNB and Assisting eNB for deciding RRC parameters or launching Idle and DRX modes.
In Some Examples:
(1) The UE may inform one or both the Anchor eNB and the Assisting eNB about each other so they can exchange information between each other.
(2) An RRC Inactivity Timer for a specific UE may be exchanged between the Anchor eNB and the Assisting eNB over an Xx (e.g., X1, X2, X3) interface between the eNBs.
(3) Only one RRC inactivity timer may be used for each UE, as negotiated between the Anchor eNB and the Assisting eNB.
(4) DRX parameters for a specific UE may be exchanged between the Anchor eNB and the Assisting eNB over the Xx (e.g., X1, X2, X3) interface between the eNBs.
(5) Selection of the DRX parameters may depend on factors such as the traffic Quality of Service (QoS) levels occurring in the Anchor eNB and the Assisting eNB.
(6) The UE may send the PPI to both the Anchor eNB and the Assisting eNB.
(7) Only one eNB, either the Assisting eNB or the Anchor eNB, may respond with a new RRC parameter set configuration message in response to the PPI message.
The following provides additional detail on the operations conducted for transitioning the devices between connected and idle states, and the selection and exchange of DRX parameters.
Coordinating RRC Inactivity Timers for the Anchor eNB and the Assisting eNB
An RRC ConnectionRelease operation may be coordinated to transition a device from Connected to Idle state, based on the RRC inactivity timers maintained by the Anchor eNB and the Assisting eNB. When a UE is connected to both an Anchor eNB and Assisting eNB, it can move to Idle mode only when the UE's RRC connection is released by both eNBs. To accomplish this, the Anchor and Assisting eNBs need to coordinate the value of the RRC Inactivity Timer value between each other. There are several ways in which this may be implemented.
In one example, the RRC Inactivity Timer value is exchanged between the Anchor eNB and the Assisting eNB. This is demonstrated in more detail in
As depicted in the flow 300, the Anchor eNB 302 and the Assisting eNB 304 are configured to establish a single set of RRC parameters used for Idle mode. First, the UE may share information about the Anchor eNB and the Assisting eNB with each other. This is commenced in some examples by a UE 306 communicating information about the Assisting eNB 304 to the Anchor eNB 302 (operation 312). In other examples, the UE may communicate information about the Anchor eNB to the Assisting eNB. With this information, the Anchor eNB and the Assisting eNB 304 are able to locate the other and communicate using an eNB-to-eNB interface. For example, the negotiation of common RRC Timer can be done over the Xx (e.g., X1, X2, X3) interface between the Anchor eNB and the Assisting eNB.
Next, the Anchor eNB and Assisting eNB coordinate with each other to decide on a value of the RRC Inactivity Timer. This may include the provision of an idle mode parameter request being sent from the Anchor eNB 302 to the Assisting eNB 304 (operation 314) and the receipt of preferred RRC parameters from the Assisting eNB 304 in response to the parameter request (operation 316). From this information, the Anchor eNB 302 communicates a single RRC parameter set for use at the Anchor eNB 302 and the Assisting eNB 304 (operation 318), with this single RRC parameter set being communicated on the eNB-to-eNB interface. Other techniques for coordinating and communicating a single parameter set or individual values may also be used.
Finally, the Anchor eNB 302 communicates the single RRC parameter set to the UE 306 (operation 320). It can be decided among the network equipment that only the Anchor eNB sends the RRC Connection Release message, but the inactivity timer value is shared between the Assisting and Anchor eNBs, or vice versa. In any case, however, one eNB can transmit the RRC Connection Release message to the UE 306 using the parameter values.
The value of the RRC inactivity timer can be based on negotiation between the two eNBs, which can select the minimum of the RRC Inactivity timers at these eNBs. Based on the alignment and coordination operations, UE will move to complete Idle mode (e.g., Idle mode for both eNBs) faster in order to save UE power.
Selection and Exchange of DRX parameters between the Anchor eNB and the Assisting eNB
Maintaining separate RRC Connected DRX states for the Anchor eNB and the Assisting eNB may result in UE being in an active state (with either the Anchor eNB or the Assisting eNB) for a longer period of time, and thus results in higher device power consumption at the UE. Here, a single DRX configuration may be selected for deployment on both eNBs to reduce this occurrence.
The selected DRX configuration may be dependent on QoS requirements of traffic flows between the UE and the Anchor eNB and between the UE and the Assisting eNB. Negotiation and selection of DRX parameters may be performed over the Xx (e.g., X1, X2, X3) interface between the Anchor eNB and the Assisting eNB. Again, experiencing different device RRC Connected DRX states may occur if the UE is connected with different RRC entities as depicted in the user plane architecture 200 of
The procedures for setting the idle mode timer and the DRX parameters are substantially the same. Thus, the procedures for implementing the DRX parameter synchronization will be discussed in reference to
As depicted in the flow 300, the Anchor eNB 302 and the Assisting eNB 304 are configured to establish a single set of RRC parameters used for DRX operations. First, the UE may share information about the Anchor eNB and the Assisting eNB with each other. This is commenced in some examples by an UE 306 communicating information about the Assisting eNB 304 to the Anchor eNB 302 (operation 312). In other examples, the UE may communicate information about the Anchor eNB to the Assisting eNB. With this information, the Anchor eNB and the Assisting eNB 304 are able to locate the other and communicate using an eNB-to-eNB interface. For example, the negotiation of common RRC Timer can be done over the Xx (e.g., X1, X2, X3) interface between the Anchor eNB and the Assisting eNB.
Next, the Anchor eNB and Assisting eNB coordinate with each other to decide on a value of the DRX parameters. This may include the provision of a DRX parameter request being sent from the Anchor eNB 302 to the Assisting eNB 304 (operation 314) and the receipt of preferred RRC parameters from the Assisting eNB 304 in response to the parameter request (operation 316). From this information, the Anchor eNB 302 communicates a single RRC parameter set for use at the Anchor eNB 302 and the Assisting eNB 304 (operation 318), with this single RRC parameter set being communicated on the eNB-to-eNB interface. Other techniques for coordinating and communicating a single parameter set or individual values may also be used.
Finally, the Anchor eNB 302 communicates the single RRC parameter set to the UE 306 (operation 320).
Providing PPI to the Anchor eNB and the Assisting eNB
Sending the power preference information (PPI) from the UE to only one of the Anchor and Assisting eNBs will not assist the UE with obtaining a power-optimized RRC configuration. The UE can save power only if it is in the low power state for both eNBs simultaneously. Therefore, in some examples, the UE may send the PPI to both eNBs. Alternately, whenever, the UE sends the PPI to a particular eNB, the eNB may inform other eNBs about the UE's PPI. Again, experiencing different RRC power configurations may occur if there are different RRC entities that operate independently of each other as shown in the user plane architecture 200 of
In some examples, the control messages between anchor eNB and the assisting eNB in
In any of the examples of
Although the preceding examples of wireless network connections were provided with specific reference to 3GPP LTE/LTE-A, it will be understood that the techniques described herein may be applied to or used in conjunction with a variety of other WWAN, WLAN, and WPAN protocols and standards. These standards include, but are not limited to, other standards from 3GPP (e.g., HSPA+, UMTS), IEEE 802.11 (e.g., 802.11a/b/g/n/ac), IEEE 802.16 (e.g., 802.16p), or Bluetooth (e.g., Bluetooth 4.0, or like standards defined by the Bluetooth Special Interest Group) standards families. Other applicable network configurations may be included within the scope of the presently described communication networks. It will be understood that communications on such communication networks may be facilitated using any number of personal area networks, LANs, and WANs, using any combination of wired or wireless transmission mediums.
The embodiments described above may be implemented in one or a combination of hardware, firmware, and software. Various methods or techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as flash memory, hard drives, portable storage devices, read-only memory (ROM), random-access memory (RAM), semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)), magnetic disk storage media, optical storage media, and any other machine-readable storage medium or storage device wherein, when the program code is loaded into and executed by a machine, such as a computer or networking device, the machine becomes an apparatus for practicing the various techniques.
A machine-readable storage medium or other storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). In the case of program code executing on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
Example computer system machine 1000 includes a processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 1004 and a static memory 1006, which communicate with each other via an interconnect 1008 (e.g., a link, a bus, etc.). The computer system machine 1000 may further include a video display unit 1010, an alphanumeric input device 1012 (e.g., a keyboard), and a user interface (UI) navigation device 1014 (e.g., a mouse). In one embodiment, the video display unit 1010, input device 1012 and UI navigation device 1014 are a touch screen display. The computer system machine 1000 may additionally include a storage device 1016 (e.g., a drive unit), a signal generation device 1018 (e.g., a speaker), an output controller 1032, a power management controller 1034, and a network interface device 1020 (which may include or operably communicate with one or more antennas 1030, transceivers, or other wireless communications hardware), and one or more sensors 1028, such as a Global Positioning Sensor (GPS) sensor, compass, location sensor, accelerometer, or other sensor.
The storage device 1016 includes a machine-readable medium 1022 on which is stored one or more sets of data structures and instructions 1024 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 1024 may also reside, completely or at least partially, within the main memory 1004, static memory 1006, and/or within the processor 1002 during execution thereof by the computer system machine 1000, with the main memory 1004, static memory 1006, and the processor 1002 also constituting machine-readable media.
While the machine-readable medium 1022 is illustrated in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 1024. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions.
The instructions 1024 may further be transmitted or received over a communications network 1026 using a transmission medium via the network interface device 1020 utilizing any one of a number of well-known transfer protocols (e.g., HTTP). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules, in order to more particularly emphasize their implementation independence. For example, a component or module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.
Indeed, a component or module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within components or modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components or modules may be passive or active, including agents operable to perform desired functions.
Additional examples of the presently described method, system, and device embodiments include the following, non-limiting configurations. Each of the following non-limiting examples may stand on its own, or may be combined in any permutation or combination with any one or more of the other examples provided below or throughout the present disclosure.
The Abstract is provided to allow the reader to ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to limit or interpret the scope or meaning of the claims. The following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.
Other Notes and ExamplesExample 1 includes subject matter (such as a method, means for performing acts, machine readable medium including instructions) performed by an anchor evolved Node B (eNodeB) for coordinating at least one radio resource control (RRC) parameter in a multi-eNodeB environment, the method comprising: determining an RRC parameter for use at the anchor eNodeB and an assisting eNodeB, wherein the anchor eNodeB provides communications with a particular UE in a macro cell and the assisting eNodeB is used for providing communications with the particular UE in a small cell; and communicating the RRC parameter to the UE, the RRC parameter implemented at both the anchor eNodeB and the assisting eNodeB.
In Example 2, the subject matter of Example 1 may optionally include receiving, at the anchor eNodeB from the UE, information about the assisting eNodeB.
In Example 3, the subject matter of any one or more of examples 1-2 may optionally include wherein the RRC parameter is a RRC inactivity timer value.
In Example 4, the subject matter of any one or more of examples 1-3 may optionally include wherein the RRC parameter is a parameter related to a discontinuous reception (DRX) mode.
In Example 5, the subject matter of any one or more of examples 1-4 may optionally include wherein determining the RRC parameter for the UE comprises determining the RRC parameter based in part on traffic quality of service levels occurring at the anchor eNodeB and the assisting eNodeB.
In Example 6, the subject matter of any one or more of examples 1-5 may optionally include receiving, from the UE, a power preference indication; wherein determining the RRC parameter for the UE comprises determining the RRC parameter based upon the power preference indication.
In Example 7, the subject matter of any one or more of examples 1-6 may optionally include wherein the power preference indication is directly communicated from the UE to the anchor eNodeB.
In Example 8, the subject matter of any one or more of examples 1-7 may optionally include wherein the power preference indication is communicated from the UE to the anchor eNodeB via the assisting eNodeB, and wherein the anchor eNodeB communicates the common set of RRC parameters to the UE.
In Example 9, the subject matter of any one or more of examples 1-8 may optionally include wherein communicating the common set of RRC parameters to the UE comprises communicating the common set of RRC parameters to the UE via the Assisting eNodeB.
Example 10 may optionally be combined with the subject matter of any one of Examples 1-9 to include subject matter (such as a device, apparatus, or machine such as an eNodeB) comprising comprising circuitry arranged to coordinate radio resource control (RRC) parameters in a multi-eNodeB environment, with operations to: determine an RRC parameter for use at the eNodeB and an assisting eNodeB, wherein the eNodeB provides communications with a particular UE in a macro cell and the assisting eNodeB provides communications with the particular UE in a small cell; communicate the RRC parameter to the UE; implement the RRC parameter at the eNodeB.
In Example 11, the subject matter of any one or more of examples 1-10 may optionally include wherein the eNodeB comprises circuitry arranged to: receive, at the anchor eNodeB from the UE, information about the assisting eNodeB.
In Example 12, the subject matter of any one or more of examples 1-11 may optionally include wherein the RRC parameter is a RRC inactivity timer value.
In Example 13, the subject matter of any one or more of examples 1-12 may optionally include wherein the RRC parameter is a parameter related to a discontinuous reception (DRX) mode.
In Example 14, the subject matter of any one or more of examples 1-13 may optionally include wherein the circuitry is arranged to determine the RRC parameter for the UE comprises determining the RRC parameter based in part on traffic quality of service levels occurring at the anchor eNodeB and the assisting eNodeB.
Example 15 includes or may optionally be combined with the subject matter of any one of examples 1-14 to include subject matter (such as a device, apparatus, or machine such as a UE) comprising: a transceiver configured to: communicate with an anchor evolved Node B (eNodeB) and an assisting eNodeB, the anchor eNodeB providing communications to the UE with a macro cell and the assisting eNodeB providing communications to the UE with a cell smaller than the macro cell; send information on the assisting eNodeB to the anchor eNodeB; receive a radio resource control parameter (RRC) from the anchor eNodeB; processing circuitry arranged to: utilize the same RRC parameter in communications with the anchor eNodeB and the assisting eNodeB.
In Example 16, the subject matter of any one or more of examples 1-15 may optionally include wherein the RRC parameter is a discontinuous reception (DRX) parameter.
In Example 17, the subject matter of any one or more of examples 1-16 may optionally include wherein the RRC parameter is an RRC inactivity timer value.
In Example 18, the subject matter of any one or more of examples 1-17 may optionally include wherein the information on the assisting eNodeB to the anchor eNodeB is information that enables the anchor eNodeB to contact the assisting eNodeB.
Example 19 includes or may optionally be combined with the subject matter of any one of Examples 1-18 to include subject matter (such as a method, means for performing acts, machine readable medium including instructions) comprising: communicate with an anchor evolved Node B (eNodeB) and an assisting eNodeB, the anchor eNodeB providing communications to the UE with a macro cell and the assisting eNodeB providing communications to the UE with a cell smaller than the macro cell; send information on the assisting eNodeB to the anchor eNodeB; receive an radio resource control parameter (RRC) from the anchor eNodeB; processing circuitry arranged to: utilize the same RRC parameter in communications with the anchor eNodeB and the assisting eNodeB.
Claims
1. A method performed by an anchor evolved Node B (eNodeB) for coordinating at least one radio resource control (RRC) parameter in a multi-eNodeB environment, the method comprising:
- determining an RRC parameter for use at the anchor eNodeB and an assisting eNodeB, wherein the anchor eNodeB provides communications with a particular UE in a macro cell and the assisting eNodeB is used for providing communications with the particular UE in a small cell; and
- communicating the RRC parameter to the UE, the RRC parameter implemented at both the anchor eNodeB and the assisting eNodeB.
2. The method of claim 1, further comprising:
- receiving, at the anchor eNodeB from the UE, information about the assisting eNodeB.
3. The method of claim 1, wherein the RRC parameter is a RRC inactivity timer value.
4. The method of claim 1, wherein the RRC parameter is a parameter related to a discontinuous reception (DRX) mode.
5. The method of claim 4, wherein determining the RRC parameter for the UE comprises determining the RRC parameter based in part on traffic quality of service levels occurring at the anchor eNodeB and the assisting eNodeB.
6. The method of claim 1, further comprising:
- receiving, from the UE, a power preference indication;
- wherein determining the RRC parameter for the UE comprises determining the RRC parameter based upon the power preference indication.
7. The method of claim 6, wherein the power preference indication is directly communicated from the UE to the anchor eNodeB.
8. The method of claim 6, wherein the power preference indication is communicated from the UE to the anchor eNodeB via the assisting eNodeB, and wherein the anchor eNodeB communicates the common set of RRC parameters to the UE.
9. The method of claim 1, wherein communicating the common set of RRC parameters to the UE comprises communicating the common set of RRC parameters to the UE via the Assisting eNodeB.
10. An evolved NodeB (eNodeB), comprising circuitry arranged to coordinate radio resource control (RRC) parameters in a multi-eNodeB environment, with operations to:
- determine an RRC parameter for use at the eNodeB and an assisting eNodeB, wherein the eNodeB provides communications with a particular UE in a macro cell and the assisting eNodeB provides communications with the particular UE in a small cell;
- communicate the RRC parameter to the UE;
- implement the RRC parameter at the eNodeB.
11. The eNodeB of claim 10, wherein the eNodeB comprises circuitry arranged to:
- receive, at the anchor eNodeB from the UE, information about the assisting eNodeB.
12. The eNodeB of claim 10, wherein the RRC parameter is a RRC inactivity timer value.
13. The eNodeB of claim 10, wherein the RRC parameter is a parameter related to a discontinuous reception (DRX) mode.
14. The eNodeB of claim 13, wherein the circuitry is arranged to determine the RRC parameter for the UE comprises determining the RRC parameter based in part on traffic quality of service levels occurring at the anchor eNodeB and the assisting eNodeB.
15. A user equipment (UE), comprising:
- a transceiver configured to:
- communicate with an anchor evolved Node B (eNodeB) and an assisting eNodeB, the anchor eNodeB providing communications to the UE with a macro cell and the assisting eNodeB providing communications to the UE with a cell smaller than the macro cell;
- send information on the assisting eNodeB to the anchor eNodeB;
- receive a radio resource control parameter (RRC) from the anchor eNodeB;
- processing circuitry arranged to:
- utilize the same RRC parameter in communications with the anchor eNodeB and the assisting eNodeB.
16. The UE of claim 15, wherein the RRC parameter is a discontinuous reception (DRX) parameter.
17. The UE of claim 15, wherein the RRC parameter is an RRC inactivity timer value.
18. The UE of claim 15, wherein the information on the assisting eNodeB to the anchor eNodeB is information that enables the anchor eNodeB to contact the assisting eNodeB.
19. A machine readable medium that stores instructions which when performed by a machine, cause the machine to perform operations comprising:
- communicate with an anchor evolved Node B (eNodeB) and an assisting eNodeB, the anchor eNodeB providing communications to the UE with a macro cell and the assisting eNodeB providing communications to the UE with a cell smaller than the macro cell;
- send information on the assisting eNodeB to the anchor eNodeB;
- receive an radio resource control parameter (RRC) from the anchor eNodeB;
- processing circuitry arranged to:
- utilize the same RRC parameter in communications with the anchor eNodeB and the assisting eNodeB.
Type: Application
Filed: Dec 26, 2013
Publication Date: Jan 1, 2015
Inventors: Ali Koc (Hillsboro, OR), Satish Chandra Jha (Hillsboro, OR), Maruti Gupta (Portland, OR), Rath Vannithamby (Portland, OR)
Application Number: 14/141,223
International Classification: H04W 16/14 (20060101); H04W 88/02 (20060101); H04W 72/04 (20060101);