Security key refresh for dual connectivity

Embodiments have a master eNB with a control plane and optional data plane to user equipment and a secondary eNB with a data plane to the user equipment. The user equipment thus uses both the master eNB and the secondary eNB for data communications while receiving control information from only the master eNB. The master eNB and secondary eNB are connected with an X2 interface. When the secondary eNB desires to refresh its security key, it informs the master eNB using the X2 interface. The master eNB then uses its control plane with the user equipment to initiate a security key refresh for the secondary eNB.

TECHNICAL FIELD

Embodiments pertain to wireless communications. More particularly, some embodiments relate to User Equipment (UE) that have dual connectivity through two enhanced Node Bs (eNB), a Master eNB (MeNB) and a Secondary eNB (SeNB).

BACKGROUND

Global mobile traffic is growing at an ever-expanding pace. As the demand for wireless capacity increases, numerous technologies are being explored to increase a carrier's capacity. Some UE may be connected to two eNBs, that service an overlapping area where the UE is located. This allows dual connectivity for the UE to the two eNBs and allows for Carrier Aggregation (CA) to use the bandwidth of both eNBs. The multiple eNBs can reduce the frequency of handovers and its associated overhead.

DETAILED DESCRIPTION

Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the scope of the disclosure. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that embodiments of the disclosure may be practiced without the use of these specific details. In other instances, well-known structures and processes are not shown in block diagram form in order to not obscure the description of the embodiments with extraneous detail. Thus, the present disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Dual connectivity, or Inter-enhanced NodeB (eNB) carrier aggregation (CA) has been proposed for the future enhancement of carrier aggregation. In dual connectivity, the serving cells are operated by different eNBs. For example, a primary cell (PCell) is served from the Master eNB (MeNB) and a secondary (SCell) is served from the Secondary eNB (SeNB). One motivation of dual connectivity is to avoid frequent handovers in heterogeneous deployment. As used herein, the MeNB is the eNB that terminates at least the S1 interface to the Mobility Management Entity (MME) (e.g., has a control plane to the UE). The SeNB is the eNB that provides additional radio resources for the UE but is not the MeNB.

FIG. 1illustrates an example architecture100with UE102being served by both a MeNB108and a SeNB104. Both eNBs can be connected to a serving gateway (SGW)112. If the UE102were only connected to one or the other of the MeNB108or SeNB104(as opposed to both), handovers would be more frequent. This can be illustrated by considering the activities of the UE102as it moves within the MeNB cell coverage114.

In some, although not all, embodiments, the coverage area114of the MeNB108is larger than the SeNB104coverage area116. When the coverage of the SeNB116is smaller than that of the MeNB coverage114, the UE102needs to handover to the MeNB108or a different SeNB (not shown) if the UE102is only connected to the SeNB104. On the other hand, if the UE102is connected to both the MeNB108and the SeNB104, handover is not required when the UE102moves beyond the coverage116, but offloading to the SeNB104cannot be provided, since the UE102is only connected to the MeNB108. Therefore, to achieve offloading and avoid the frequent handover, carrier aggregation (CA) can be supported.

In dual connectivity, the UE is served by both the MeNB108and the SeNB104. If the MeNB108is responsible for the mobility management, the UE102does not need to handover as long as the UE102is moving within the cell coverage114provided by MeNB108. Furthermore, the UE102can use the SeNB104for data transmission to take advantage of offloading to the SeNB104. The change from one small cell coverage area (e.g.,116) to another small coverage area (not shown) is supported with small cell addition/removal instead of handover.

This disclosure uses the terms MeNB and SeNB. However, other terms may be used in place of these chosen terms. For example, MeNB can be denoted as anchor eNB or primary eNB, while SeNB can be denoted as assisting eNB or small cell eNB.

In current LTE systems, in order to protect the data from being received by a third party or to detect the change made by a third party, ciphering and integrity protection are supported. In the access stratum (AS) level, both ciphering and integrity protection are applied for the Radio Resource Control (RRC) signaling (e.g., control plane) while only ciphering is applied for the user data (e.g., user plane).

The RRC layer is responsible for AS security key handling and the AS security procedure. The Packet Data Convergence Protocol (PDCP) layer performs integrity protection and ciphering of RRC signaling as well as ciphering of user plane data. The integrity protection and ciphering uses a hierarchical set of keys, illustrated inFIG. 2. One key, KRRCint208is used for RRC signaling integrity protection, while other keys, KUPenc206and KRRCenc210, are used for ciphering of user plane and control plane information, respectively. All three keys are generated from a single key, KeNB204, and the AS derives a KeNB204from KASME202, which is a common secret key available in both the UE and the network (e.g., Mobility Management Entity (MME)).

During handover, the source eNB derives a key, KeNB*, which is used in the target eNB. For example, in X2 handover, the source eNB performs a vertical key derivation in case it has an unused Next Hop (NH) and Next Hop Chaining Counter (NCC) pair. The source eNB first computes KeNB*from the target cell Physical Cell Identifier (PCI), its frequency Radio Frequency Channel Number on Download (EARFCN-DL), and either the currently active KeNB(in case of horizontal key derivation) or the NH (in case of vertical key derivation).

FIG. 3illustrates an example architecture300with UE302being served by both a MeNB304and a SeNB306. UE302has both a user plane as well as a control plane (e.g., RRC) with the MeNB304as indicated by arrow316. However, UE302only has a user plane with the SeNB306as indicated by arrow314. The MeNB304and the SeNB306have an X2 interface320that provides a data plane318between them. Both the MeNB304and the SeNB306are connected over an S1 interface312to a SGW308as illustrated by arrows322and324, respectively. The SGW308used by the MeNB and the SeNB can be the same SGW or the eNBs can use different SGWs. The SGW308can provide a data connection326/328to the internet or other Internet Protocol (IP) network330. The connections from UE302back to the internet330are called Evolved Packet System (EPS) Bearers and represent a virtual connection between the two endpoints. More generally, an EPS bearer is a virtual connection between any two endpoints, not just a data connection to the internet. Thus, bearers can be of different types, such as a signaling bearer, a data bearer, and so forth. Such bearers provide a transport service with specific Quality of Service (QoS) attributes.

FIG. 4illustrates an example diagram400illustrating Radio Resource Control (RRC) layer436, Packet Data Convergence Protocol (PDCP) layer406, Radio Link Control (RLC) layer416, and Machine Access Control (MAC) layer422for a MeNB402and a SeNB404. The MeNB402may comprise a plurality of incoming connections such as a connection440to the Radio Resource Control (RRC) layer436and a data connection442, which connects through a serving gateway (not shown) to a data network438such as the internet. The RRC layer436is responsible for AS security key handling and AS security procedure, as previously described. Connection to this layer is what allows the MeNB402to have a control plane connection to the UE (not shown). The control plane connection to the UE allows the MeNB to perform such functions as security key refresh with the UE.

Incoming IP packets arrive over the data connection442. The PDCP layer406processes these packets. The PDCP layer406comprises Robust Header Compression (ROHC) block408and security block412that operate according to known methods. As discussed above, the PDCP layer406performs integrity protection and ciphering of RRC signaling and ciphering of user plane data.

The RLC layer416performs such tasks as segmentation, Automatic Repeat Request (ARQ), and so forth222. The Machine Access Control (MAC) layer422includes such functions as unicast scheduling/priority handling424, multiplexing for various UE426, Hybrid Automatic Repeat Request (HARQ)428.

The SeNB404is configured similarly with a PDCP layer406comprising ROHC410and security414, a RLC layer416with segmentation, ARQ, and so forth420, and a MAC layer with unicast scheduling, priority handling430, UE multiplexing432and HARQ434. However, the SeNB404has two data connections444/446and no RRC connection. Thus, the SeNB404has no control plane to the UE. Thus while ciphering is performed in the SeNB404, there is no way for the SeNB to do a security key refresh with the UE since no control plane exists between them. In general, security key refresh is performed when PDCP COUNTs (e.g., a count value included in the packets handled by the PDCP layer) are about to wrap around.

Since the MeNB402does have a control plane with the UE and since the SeNB404has a data connection (e.g., the X2 connection ofFIG. 3) with the MeNB402, the SeNB404can exchange appropriate information about a security key refresh with the MeNB402and the MeNB402can send RRC signaling to the UE in order to effectuate the security key refresh for the corresponding SeNB404. Embodiments for example procedures are discussed inFIGS. 5 and 6.

FIG. 5illustrates an example embodiment500for key refresh of a SeNB506. In this embodiment, a secondary cell release/addition procedure is used to generate a new security key at the SeNB506and at the UE502. The message exchanges ofFIG. 5are representative of the removal/addition procedures.

When the SeNB506desires to refresh its security key, it sends a security key refresh request message508to the MeNB504. The term “security key refresh request” is an example message. Other messages and message names can be used, as long as the message is used to initiate the security key refresh. The security key refresh may be triggered by various factors. In one embodiment, the SeNB506initiates the security key refresh when its PDCP counts in the EPS bearers (e.g., data connection444/446ofFIG. 4) configured at the SeNB506are about to wrap around. Since there can be multiple data connections/EPS bearers for the SeNB506, the security key refresh may be triggered when any of the PDCP counts are about to wrap. The security key refresh request message508contains the information needed for the MeNB504to initiate the refresh using the release/addition procedures. In one embodiment, the message may contain a field indicating the time estimate of when a PDCP count is expected to wrap so that a time from which the new key should be used can be set. Note that this time can be set by the SeNB506, in which case the security key refresh message can contain a time from which the new key should be used rather than, or in addition to, the time estimate of when a PDCP count is expected to wrap.

The MeNB504initiates the release procedure in response to receiving the security key refresh request message508. The secondary cell release procedure is shown collectively as510inFIG. 5. During the release procedure, the SeNB506is removed from the UE502secondary cell list. When the SeNB506is removed from handling the UE502, if pending packets or other information transfer is in process, the MeNB might need to handle the EPS bearers originally processed by the SeNB506while the SeNB506is unable to handle its EPS bearers (since it has been removed from the UE502). The MeNB504can handle the SeNB506EPS bearers itself or delegate handling to an appropriate SeNB that has connection to UE502. Exchanges to handle EPS bearers are not specifically shown, but information allowing the MeNB504to handle the SeNB506EPS bearers can be included in the security key refresh request message508or sent in a different message(s).

In the representative embodiment ofFIG. 5, the secondary cell release procedure510comprises MeNB504sending a release request message512to SeNB506. This triggers the procedures on SeNB506to remove UE502. Thus, resources dedicated to supporting UE502can be removed from SeNB. Assuming the information to handle its EPS bearers have not previously been sent to the MeNB504, this release request512may trigger such an exchange of information.

The MeNB504can also send a secondary cell remove request message514to UE502to initiate the procedures on UE502to remove the SeNB506from its cell list. Any additional exchanges to accomplish the removal of SeNB are illustrated by arrow516. These can include, depending on the embodiment, such exchanges as acknowledgments, handover exchanges (e.g., to let another eNB handle SeNB's506EPS bearers), and so forth.

Once the SeNB506has been removed, the MeNB504initiates the secondary cell addition procedure, shown collectively inFIG. 5as518. As part of this procedure, the MeNB504can provide configuration information including configuration information for the MeNB for UE capability coordination that can be used as the basis for the reconfiguration/addition of the SeNB506. This information can be provided separately or as part of a Secondary Cell Addition/Modification message as shown in message520. This information can also ask the SeNB506to handle EPS bearer(s).

The MeNB504can also initiate any addition procedures on the UE502by sending secondary cell addition request message522to UE502. Secondary cell addition request message522can contain information that allows UE502to derive the appropriate refreshed security key.

The addition procedure518may also include other exchanges524between any or all of the UE502, the MeNB504and/or the SeNB506. Such additional exchanges524can include, for example, exchanges between the UE502and the SeNB506to complete the addition procedure. Additional exchanges524may also include any other exchanges between the MeNB504and the SeNB506to handle appropriate EPS bearers.

While the secondary cell release and addition procedures (e.g.,510and518, respectively) have been shown as being triggered by different exchanges, in one embodiment the MeNB504can trigger the release and addition procedure with the same RRC message. In this embodiment, there may be no need for other eNBs to handle EPS bearers from the SeNB506. In this, or in other embodiments, the MeNB504can also provide the SeNB506with new security key information before the release procedure510begins so that there is no need to communicate that information at a later exchange. This also shortens the time between the release and addition procedures and allows the UE502and/or the SeNB506to immediately initiate the addition procedure at the end of the release procedure without waiting for the MeNB504to trigger the addition procedure.

Once the addition procedure518is complete, the security key for the SeNB will have been refreshed.

FIG. 6illustrates an example embodiment600for key refresh of a SeNB606. In this embodiment, the security key is refreshed without removal and addition of the SeNB606. When the SeNB606desires to refresh its security key, it sends a security key refresh request message608to the MeNB604. The security key refresh may be triggered by various factors. In one embodiment, the SeNB606initiates the security key refresh when its PDCP counts in the EPS bearers (e.g., data connection444/446ofFIG. 4) configured at the SeNB606are about to wrap around. Since there can be multiple data connections/EPS bearers for the SeNB606, the security key refresh may be triggered when any of the PDCP counts are about to wrap. The security key refresh request message608contains the information needed for the MeNB604to initiate the refresh using the release/addition procedures. In one embodiment, the message may contain a field indicating the time estimate of when a PDCP count is expected to wrap so that a time from which the new key should be used can be set. Note that this time can be set by the SeNB606, in which case the security key refresh message can contain a time from which the new key should be used rather than, or in addition to, the time estimate of when a PDCP count is expected to wrap.

The MeNB604sends RRC signaling to the UE602to refresh the security key for bearers served by the SeNB606. In a representative embodiment, the MeNB604can use the RRC connection reconfiguration message610. The RRCConnectionReconfiguration message as specified in 3GPP TS 36.331 version 8.2.0 Release 8 (November of 2008). As currently specified, the RRCConnectionReconfiguration message is used to perform various functions such as to establish/modify/release radio bearers, to perform handover, to setup/modify/release measurements, to add/modify/release secondary cells, and/or transfer NAS information from an eNB to a UE. With appropriate extensions, the RRC Connection Reconfiguration message610can also be used to initiate a security key refresh for SeNB606.

The RRC Connection Reconfiguration message610optionally includes a timing reference indicating a start timing reference (e.g., in frame or sub-frame granularity) that the UE602should begin using the new security key. As discussed above, the timing reference may be provided by the MeNB604, such as being derived from information sent by the SeNB606or otherwise determined by the MeNB604, or the timing reference may be provided by the SeNB606, depending on the embodiment.

In response to receiving RRC Connection Reconfiguration message610, the UE602can derive a new KeNBkey, which is used for communications between the UE602and SeNB606.

The MeNB604sends a security key refresh acknowledgment message612to the SeNB606. This message may contain a timing reference (e.g., in frame or sub-frame granularity) indicating when the SeNB606should begin using the new key. The message may contain any other desired information, such as information the MeNB604should use in deriving the new security key.

The timing of messages610and612can happen in any order and ordering for these two messages is not significant in some embodiments.

The UE602can send a reconfiguration complete message to the MeNB604in some embodiments. In a representative example, an RRC Connection Reconfiguration Complete message614is used. Although not shown, in some embodiments, the SeNB606informs the MeNB604that its reconfiguration is complete, to the extent such is not apparent from RRC

Connection Reconfiguration Complete message614.

Example Device Architecture and Machine-Readable Medium

FIG. 7illustrates a system block diagram of a wireless device700, according to some embodiments. Such a wireless device700can represent, for example, a MeNB, a SeNB and/or a UE as described in conjunction withFIGS. 1-6above. The procedures, message exchanges, and so forth described above are suitable for implementation on the illustrated device700.

The device700may include a processor704, a memory706, a transceiver708, antennas710, instructions712,714, and possibly other components (not shown).

The processor704comprises one or more central processing units (CPUs), graphics processing units (GPUs), accelerated processing units (APUs), signal processors, or various combinations thereof. The processor704provides processing and control functionalities for the device700and may implement the flow diagrams and logic described above for the eNBs and UEs ofFIGS. 1-6.

The memory706comprises one or more transient and/or static memory units configured to store instructions712,714and data for the device700. The transceiver708comprises one or more transceivers including, for an appropriate station or responder, a multiple-input and multiple-output (MIMO) antenna to support MIMO communications. For the device700, the transceiver708receives transmissions and transmits transmissions. The transceiver708may be coupled to the antennas710, which represent an antenna or multiple antennas, as appropriate to the device700. As described in the figures above, the UE and eNB may operate in a primary band and a secondary bands and may be adapted to tune to any secondary band to which license is granted.

The instructions712,714comprise one or more sets of instructions or firmware/software executed on a computing device (or machine) to cause such a computing device (or machine) to perform any of the methodologies discussed herein. The instructions712,714(also referred to as computer- or machine-executable instructions) may reside, completely or at least partially, within the processor704and/or the memory706during execution thereof by the device700. While the instructions712and714are illustrated as separate, they can be part of the same whole. The processor704and the memory706also comprise machine-readable storage media. The instructions712and714may implement, for example, all or part of the flow associated withFIGS. 5-6attributed to the eNBs and/or the UE. Additionally, or alternatively, the instructions712and714may implement other processing and functionality discussed in conjunction with the other embodiments above.

Processing Circuitry

InFIG. 7, processing and control functionalities are illustrated as being provided by the processor704along with the associated instructions712and714. However, these are only examples of processing circuitry that comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor804or other programmable processor) that is temporarily configured by software or firmware to perform certain operations. In various embodiments, processing circuitry may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor, application specific integrated circuit (ASIC), or array) to perform certain operations. It will be appreciated that a decision to implement processing circuitry mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost, time, energy-usage, package size, or other considerations.

Accordingly, the term “processing circuitry” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein.

Transmission Medium

The instructions712/714may further be transmitted or received such as by transceiver circuitry708and/or antennas710using a transmission medium. The instructions712/714may be transmitted using any one of a number of well-known transfer protocols. Transmission medium encompasses mechanisms by which the instructions712/714are transmitted, such as communication networks. 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 media to facilitate communication of such software.

The following represent various example embodiments.

1. A method performed by a first enhanced Node B (eNB) comprising:

receiving, from a second eNB, a request to refresh a security key used by the second eNB;

sending a release request to the second eNB that causes the second eNB to release resources dedicated to a User Equipment (UE);

sending a remove request to the UE that causes the UE to remove the second eNB from its eNB list;

sending a Secondary Cell Addition/Modification message to the second eNB, the Secondary Cell Addition/Modification message comprising configuration information for the second eNB;

sending an eNB addition request to the UE that causes the UE to add the second eNB to its eNB list.

2. The method of example 1, wherein the release request and the configuration information are sent in the same message to the second eNB.

3. The method of example 1 or 2, wherein sending the release request and sending the remove request are part of a cell release procedure.

4. The method of example 1 or 2, wherein sending the Secondary Cell Addition/Modification message and sending the eNB addition request are part of a cell addition procedure.

5. The method of example 1 or 2, wherein the second eNB is a secondary cell eNB.

6. A wireless device comprising:

at least one antenna;

transceiver circuitry coupled to the at least one antenna;

a processor coupled to the memory and transceiver circuitry; and

instructions, stored in the memory, which when executed cause the processor to:

receive, from a second eNB, a request to refresh a security key used by the second eNB;

send a release request to the second eNB that causes the second eNB to release resources dedicated to a User Equipment (UE);

send a remove request to the UE that causes the UE to remove the second eNB from its eNB list;

send a Secondary Cell Addition/Modification message to the second eNB, the Secondary Cell Addition/Modification message comprising configuration information for the second eNB;

send an eNB addition request to the UE that causes the UE to add the second eNB to its eNB list.

7. The device of example 6, wherein the release request and the configuration information are sent in the same message to the second eNB.

8. The device of example 6 or 7, wherein sending the release request and sending the remove request are part of a cell release procedure.

9. The device of example 6 or 7, wherein sending Secondary Cell Addition/Modification message and sending the eNB addition request are part of a cell addition procedure.

10. The device of example 6 or 7, wherein sending the second eNB is a secondary cell eNB.

11. A machine readable medium having executable instructions embodied thereon that, when executed, configure a device to:

receive, from a second eNB, a request to refresh a security key used by the second eNB;

send a release request to the second eNB that causes the second eNB to release resources dedicated to a User Equipment (UE);

send a remove request to the UE that causes the UE to remove the second eNB from its eNB list;

send a Secondary Cell Addition/Modification message to the second eNB, the Secondary Cell Addition/Modification message comprising configuration information for the second eNB;

send an eNB addition request to the UE that causes the UE to add the second eNB to its eNB list.

12. The machine readable medium of example 11, wherein the release request and the configuration information are sent in the same message to the second eNB.

13. The machine readable medium of example 11 or 12, wherein sending the release request and sending the remove request are part of a cell release procedure.

14. The machine readable medium of example 11 or 12, wherein sending the Secondary Cell Addition/Modification message and sending the eNB addition request are part of a cell addition procedure.

15. The machine readable medium of example 11 or 12, wherein sending the second eNB is a secondary cell eNB.

16. A method performed by a first enhanced Node B (eNB) comprising:

receiving, from a second eNB, a request to refresh a security key used by the second eNB;

sending, to a User Equipment (UE), an RRC signaling request causing the UE to refresh a security key for radio bearers served by the second eNB;

receiving, from the UE, a message indicating that the refresh for the security key has been completed.

17. The method of example 16, wherein the RRC signaling request uses an RRCConnectionReconfiguration message.

18. The method of example 16, RRC signaling request further comprises a timing reference indicating a timing reference from which the UE should begin using the refreshed security key.

19. The method of example 16 or 18, further comprising sending, to the second eNB, a security key refresh acknowledgment message.

20. The method of example 19, wherein the security key refresh acknowledgment message comprises a timing reference from which the second eNB should begin using the refreshed security key.

21. The method of example 16, 17 or 18, wherein the message indicating that the refresh for the security key has been completed uses an RRCConnectionReconfigurationComplete message.

22. A wireless device comprising:

at least one antenna;

transceiver circuitry coupled to the at least one antenna;

a processor coupled to the memory and transceiver circuitry; and

instructions, stored in the memory, which when executed cause the processor to:

receive, from a second eNB, a request to refresh a security key used by the second eNB;

send, to a User Equipment (UE), an RRC signaling request causing the UE to refresh a security key for radio bearers served by the second eNB;

receive, from the UE, a message indicating that the refresh for the security key has been completed.

23. The device of example 22, wherein the RRC signaling request uses an RRCConnectionReconfiguration message.

24. The device of example 22, RRC signaling request further comprises a timing reference indicating a timing reference from which the UE should begin using the refreshed security key.

25. The device of example 22 or 24, further comprising sending, to the second eNB, a security key refresh acknowledgment message.

26. The device of example 25, wherein the security key refresh acknowledgment message comprises a timing reference from which the second eNB should begin using the refreshed security key.

27. The device of example 22, 23 or 24, wherein the message indicating that the refresh for the security key has been completed uses an RRCConnectionReconfigurationComplete message.

28. A machine readable medium having executable instructions embodied thereon that, when executed, configure a device to:

receive, from a second eNB, a request to refresh a security key used by the second eNB;

send, to a User Equipment (UE), an RRC signaling request causing the UE to refresh a security key for radio bearers served by the second eNB;

receive, from the UE, a message indicating that the refresh for the security key has been completed.

29. The machine readable medium of example 28, wherein the RRC signaling request uses an RRCConnectionReconfiguration message.

30. The machine readable medium of example 28, RRC signaling request further comprises a timing reference indicating a timing reference from which the UE should begin using the refreshed security key.

31. The machine readable medium of example 28 or 30, further comprising sending, to the second eNB, a security key refresh acknowledgment message.

32. The machine readable medium of example 31, wherein the security key refresh acknowledgment message comprises a timing reference from which the second eNB should begin using the refreshed security key.

33. The machine readable medium of example 28, 29 or 30, wherein the message indicating that the refresh for the security key has been completed uses an RRCConnectionReconfigurationComplete message.

34. A method performed by a secondary enhanced Node B (eNB) comprising:

sending, to a master eNB, a request to refresh a security key used by the secondary eNB;

receiving a release request from the master eNB that causes the secondary eNB to release resources dedicated to a User Equipment (UE);

receiving a Secondary Cell Addition/Modification message from the master eNB, the Secondary Cell Addition/Modification message comprising configuration information for the secondary eNB;

refreshing the security key according to the received RRC configuration information.

35. The method of example 34, wherein the release request and the configuration information are received in the same message.

36. The method of example 34 or 35, wherein the release request is part of a cell release procedure.

37. The method of example 34 or 35, wherein the Secondary Cell Addition/Modification message is part of a cell addition procedure.

38. The method of example 34 or 35, wherein refreshing the security key comprises deriving a new KeNB.

39. A secondary eNB comprising:

at least one antenna;

transceiver circuitry coupled to the at least one antenna;

a processor coupled to the memory and transceiver circuitry; and

instructions, stored in the memory, which when executed cause the processor to:

send, to a master eNB, a request to refresh a security key used by the secondary eNB;

receive a release request from the master eNB that causes the secondary eNB to release resources dedicated to a User Equipment (UE);

receive a Secondary Cell Addition/Modification message from the master eNB, the Secondary Cell Addition/Modification message comprising configuration information for the secondary eNB;

refresh the security key according to the received configuration information.

40. The secondary eNB of example 39, wherein the release request and the configuration information are sent in the same message.

41. The secondary eNB of example 39 or 40, wherein the release request is part of a cell release procedure.

42. The secondary eNB of example 39 or 40, wherein the Secondary Cell Addition/Modification message is part of a cell addition procedure.

43. The secondary eNB of example 39 or 40, wherein refreshing the security key comprises deriving a new KeNB.

44. A machine readable medium having executable instructions embodied thereon that, when executed, configure a device to:

send, to a master eNB, a request to refresh a security key used by the secondary eNB;

receive a release request from the master eNB that causes the secondary eNB to release resources dedicated to a User Equipment (UE);

receive a Secondary Cell Addition/Modification message from the master eNB, the Secondary Cell Addition/Modification message comprising configuration information for the secondary eNB;

refresh the security key according to the received configuration information.

45. The machine readable medium of example 44, wherein the release request and the configuration information are sent in the same message.

46. The machine readable medium of example 44 or 45, wherein the release request is part of a cell release procedure.

47. The machine readable medium of example 44 or 45, wherein the Secondary Cell Addition/Modification message is part of a cell addition procedure.

48. The machine readable medium of example 44 or 45, wherein refreshing the security key comprises deriving a new KeNB.

49. A method performed by a first enhanced Node B (eNB) comprising:

sending, to a second eNB, a request to refresh a security key used by the first eNB, the request causing the second eNB to communicate security key refresh information to a User Equipment (UE);

receiving, from the second eNB, a security key refresh acknowledgment message;

wherein either the request to refresh the security key or the security key refresh acknowledgement message or both include a timing reference indicating when a new security key should be used by the first eNB.

50. The method of example 49, wherein the security key refresh acknowledgment message comprises information used by the first eNB to derive the new security key.

51. The method of example 49, wherein the request to refresh the security key comprises the timing reference.

52. The method of example 49, wherein the security key refresh acknowledgment message comprises the timing reference.

53. The method of example 49, 50, 51 or 52, wherein the security key refresh information communicated to the UE comprises the timing reference.

54. The method of example 49, 50, 51 or 52, wherein the security key refresh information communicated to the UE causes the UE to derive a new KeNB used to communicate with the first eNB.

55. The method of example 54, further comprising communicating with the UE using the new KeNB.

56. A secondary eNB comprising:

at least one antenna;

transceiver circuitry coupled to the at least one antenna;

a processor coupled to the memory and transceiver circuitry; and

instructions, stored in the memory, which when executed cause the processor to:

send, to a master eNB, a request to refresh a security key used by the secondary eNB, the request causing the master eNB to communicate security key refresh information to a User Equipment (UE);

receive, from the master eNB, a security key refresh acknowledgment message;

wherein either the request to refresh the security key or the security key refresh acknowledgement message or both include a timing reference indicating when a new security key should be used by the secondary eNB.

57. The secondary eNB of example 56, wherein the security key refresh acknowledgment message comprises information used by the secondary eNB to derive the new security key.

58. The secondary eNB of example 56, wherein the request to refresh the security key comprises the timing reference.

59. The secondary eNB of example 56, wherein the security key refresh acknowledgment message comprises the timing reference.

60. The secondary eNB of example 56, 57, 58 or 59, wherein the security key refresh information communicated to the UE comprises the timing reference.

61. The secondary eNB of example 56, 57, 58 or 59, wherein the security key refresh information communicated to the UE causes the UE to derive a new KeNB used to communicate with the first eNB.

62. The secondary eNB of example 61, further comprising communicating with the UE using the new KeNB.

63. A machine readable medium having executable instructions embodied thereon that, when executed, configure a device to:

send, to a master eNB, a request to refresh a security key used by the secondary eNB, the request causing the master eNB to communicate security key refresh information to a User Equipment (UE);

receive, from the master eNB, a security key refresh acknowledgment message;

wherein either the request to refresh the security key or the security key refresh acknowledgement message or both include a timing reference indicating when a new security key should be used by the secondary eNB.

64. The machine readable medium of example 63, wherein the security key refresh acknowledgment message comprises information used by the secondary eNB to derive the new security key.

65. The machine readable medium of example 63, wherein the request to refresh the security key comprises the timing reference.

66. The machine readable medium of example 63, wherein the security key refresh acknowledgment message comprises the timing reference.

67. The machine readable medium of example 63, 64, 65 or 66, wherein the security key refresh information communicated to the UE comprises the timing reference.

68. The machine readable medium of example 63, 64, 65 or 66, wherein the security key refresh information communicated to the UE causes the UE to derive a new KeNB used to communicate with the first eNB.

69. The machine readable medium of example 68, further comprising communicating with the UE using the new KeNB.

at least one antenna;

transceiver circuitry coupled to the at least one antenna;

a processor coupled to the memory and transceiver circuitry; and

instructions, stored in the memory, which when executed cause the processor to:

receive, via the at least one antenna and transceiver circuitry, a control message from an enhanced Node B (eNB) requesting refresh of a security key used to communicate with a second eNB;

derive a new KeNB used by the UE to communicate with the second eNB.

71. The UE of example 70 wherein the control message is a Radio Resource Control (RRC) Connection Reconfiguration message.

72. The UE of example 70 wherein the control message further comprises a timing reference indicating the time at which the new KeNB should be used to communicate with the second eNB.

73. The UE of example 70 wherein the eNB is a master eNB and the second eNB is a secondary eNB.

74. The UE of example 70, 71, 72 or 73 wherein the instructions further cause the processor to send, via the transceiver circuitry, a RRC Reconfiguration Complete message.