HK1263021B - System and method for communicating security key information - Google Patents

Description

System and method for communicating secure key information

This application is a divisional application. The application number of the original application is 201380066189.8, and the invention name is “System and method for transmitting secure key information”.

Background Art

Wireless mobile communication technologies use various standards and protocols to transmit data between nodes (e.g., transmitting stations) and wireless devices (e.g., mobile devices). Some wireless devices use orthogonal frequency division multiple access (OFDMA) for communication in downlink (DL) transmissions and single-carrier frequency division multiple access (SC-FDMA) for communication in uplink (UL) transmissions. Standards and protocols that use orthogonal frequency division multiplexing (OFDM) for signal transmission include: the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standards (e.g., 802.16e, 802.16m) (commonly referred to in the industry as WiMAX (Worldwide Interoperability for Microwave Access), and the IEEE 802.11 standards (commonly referred to in the industry as WiFi).

In a 3GPP radio access network (RAN) LTE system, a node may be a combination of an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, enhanced Node B, eNodeB, or eNB), which communicates with wireless devices called user equipment (UE). A downlink (DL) transmission may be communication from a node (e.g., an eNodeB) to a wireless device (e.g., a UE), and an uplink (UL) transmission may be communication from a wireless device to a node.

In a homogeneous network, a node (also referred to as a macro node) can provide basic wireless coverage to wireless devices in a cell. A cell can be an area where wireless devices can operate to communicate with a macro node. Heterogeneous networks (HetNets) can be used to handle the increased traffic load on macro nodes due to the increased usage and functionality of wireless devices. A HetNet can include a layer of planned high-power macro nodes (or macro eNBs) overlaid with multiple layers of lower-power nodes (small eNBs, micro eNBs, pico eNBs, femto eNBs, and home eNBs (HeNBs)), which can be deployed within the coverage area (cell) of the macro node in a less planned or even completely uncoordinated manner. Lower-power nodes (LPNs) can generally be referred to as "low-power nodes," small nodes, or small cells.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present disclosure will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which together illustrate features of the present disclosure by way of example, in which:

FIG1 illustrates a deployment scenario for inter-evolved Node B (eNB) carrier aggregation, according to an example;

FIG2 illustrates an operational scheme for inter-evolved Node B (eNB) carrier aggregation, according to an example;

FIG3 illustrates an S1-based protocol for inter-evolved Node B (eNB) carrier aggregation, according to an example;

FIG4 illustrates the transfer of security key information between a macro evolved Node B (eNB) and a small eNB, according to an example;

5 depicts functionality of computer circuitry of a first node operable to communicate security key information to a second node, according to an example;

FIG6 depicts a flow diagram of a method for delivering security key information from a macro eNB, according to an example;

7 depicts functionality of computer circuitry of a first wireless node operable to communicate integrity and encryption information, according to an example;

FIG8 shows a diagram of a wireless device (eg, UE), according to an example.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same, but it will be understood, however, that no limitation of the scope of the invention is intended by this.

DETAILED DESCRIPTION

Before disclosing and describing the present invention, it should be understood that the present invention is not limited to the specific structures, processing steps or materials disclosed herein, but is extended to equivalents thereof, as will be understood by those skilled in the art. It should also be understood that the terminology used herein is for the purpose of describing specific examples only and is not intended to be limiting. The same reference numerals in different figures represent the same elements. The numbers provided in the flow charts and processes are provided for clarity of illustration of the steps and operations and do not necessarily indicate a particular order or sequence.

Example Embodiments

The following provides an initial overview of the technical embodiments, and then describes specific technical embodiments in more detail. This initial overview is intended to help readers understand the technology more quickly, but is not intended to identify the key features or essential features of the technology, nor is it intended to limit the scope of the claimed subject matter.

One technique for providing additional bandwidth capacity to wireless devices is to form a virtual wideband channel at the wireless device (e.g., UE) by aggregating multiple smaller bandwidth carriers. In carrier aggregation (CA), multiple component carriers (CCs) can be aggregated and jointly used for transmission to and from a single terminal. Carrier aggregation provides wireless devices with a wider range of options, enabling them to access more bandwidth. The greater bandwidth can be used for bandwidth-intensive operations, such as streaming video or delivering large data files.

A carrier may be a signal in an allowed frequency domain on which information is placed. The amount of information that can be placed on a carrier may be determined by the bandwidth of the carriers aggregated in the frequency domain. The allowed frequency domain is typically limited in bandwidth. When a large number of users are using the bandwidth in the allowed frequency domain at the same time, the bandwidth limitation becomes more severe. In addition, a downlink CC may include a primary cell and/or up to four secondary cells in a carrier aggregation. Each serving cell (i.e., the primary cell and up to the four secondary cells) may be independently configured by radio resource control (RCC) signaling. In addition, the term "small cell" may refer to a "low-power node."

One technique for providing additional bandwidth capacity to wireless devices may include using Evolved Universal Terrestrial Radio Access (EUTRA) evolved Node B (eNB) inter-carrier aggregation (CA). While in 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) Release 11, all serving cells are served by the same eNB, in EUTRA inter-eNB CA, serving cells can operate in different eNBs. For example, a primary cell (or PCell) can be served by a macro cell, while a secondary cell (SCell) can be served by a pico cell. A macro cell can be associated with a macro eNB, while a pico cell can be associated with a pico eNB.

Figure 1 shows an example deployment scenario for carrier aggregation (CA) between evolved Node Bs (eNBs). In general, EUTRA inter-eNB CA can reduce the number of handovers in heterogeneous networks. As shown in Figure 1, a user equipment (UE) may be traveling in a macro cell. For example, at T1, the UE may be within the coverage of the macro cell. At T2, the UE may add pico cell 1 because the UE is within the coverage of pico cell 1. At T3, the UE may remove pico cell 1 because the UE is not within the coverage of pico cell 1. At T4, the UE may add pico cell 2 because the UE is within the coverage of pico cell 2. At T5, the UE may remove pico cell 2 because the UE is not within the coverage of pico cell 2. Therefore, at T5, the UE may be within the coverage of the macro cell only.

Because the coverage of a macro cell is greater than that of a pico cell, the UE can be handed over to the macro cell, or if the UE is only connected to a pico cell, it can be handed over to another pico cell. On the other hand, if the UE is connected to the macro cell, no handover is required, but offloading to the pico cell is not possible. Therefore, to achieve offloading and avoid frequent handovers, carrier aggregation can be used, that is, the UE is served by both the macro cell and the pico cell. In one example, the primary cell can be associated with the macro cell, and the secondary cell can be associated with the pico cell.

Since the primary cell is responsible for mobility management, the UE does not need to be handed over as long as the UE is moving within the macro cell. As shown in the example in Figure 1, when the UE enters pico cell 1 or enters pico cell 2, handover may not be performed. In addition, the secondary cell associated with the pico cell can be used for data transmission, and the UE can take advantage of the offloading to the pico cell. Therefore, the change from pico cell 1 to pico cell 2 can be supported by adding/removing secondary cells instead of handover (as shown in Figure 1). Although in EUTRA inter-eNB CA, the macro cell and pico cell are served by different eNBs and connected via the X2 interface, in 3GPP LTE version 10 CA, all serving cells are served by the same eNB.

Figure 2 shows an example operational scenario for carrier aggregation (CA) between evolved Node Bs (eNBs). In EUTRA inter-eNB CA, macro cells and small cells (e.g., pico cells) are served by different eNBs. The macro cell can be configured as a primary cell and is responsible for UE mobility management. Therefore, the macro cell can be connected to a mobility management entity (MME), as shown by the solid line in Figure 2, while the small cell can be indirectly connected to the MME.

Radio bearers (RBs) can be used to transmit data between the UE and the E-UTRAN. RBs can include signaling radio bearers (SRBs) and data radio bearers (DRBs). SRBs can be radio bearers that carry radio resource control (RRC) signaling messages. DRBs can be radio bearers that send user data instead of control plane signaling. SRBs in the control plane can be supported between the macro cell and the MME. DRBs in the user plane can be supported in two ways. The first way (shown by the dotted line in Figure 2) uses a new S1 bearer between the small cell and the serving gateway (S-GW). The second way (shown by the dotted line in Figure 2) uses the X2 interface to forward data to the S-GW. In the second way, no new S1 bearer is required between the small cell and the S-GW.

Figure 3 shows an example S1-based protocol for carrier aggregation (CA) between evolved Node Bs (eNBs). The S1-based protocol may include a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a media access control (MAC) layer. DRBs may be configured in a macro cell or in a small cell. As shown in Figure 3, SRBs and DRB 1 are configured in a macro cell, while DRBs 2 and 3 are configured in a small cell. Since the S1 bearer is directly connected from the small cell to the S-GW, the physical layer (PHY), MAC, RLC, and PDCP for DRBs 2 and 3 are located in the small cell.

S1-based protocols may include the PDCP layer, which is the top sublayer of the LTE user plane Layer 2 protocol stack. The PDCP layer handles Radio Resource Control (RRC) messages in the control plane and Internet Protocol (IP) packets in the user plane. Depending on the radio bearer, the main functions of the PDCP layer are header compression, security (integrity protection and ciphering), and support for reordering and retransmission during handover.

S1-based protocols may include the RLC layer, which is located between the PDCP layer and the MAC layer in the LTE user plane protocol stack. The primary function of the RLC layer is to segment and reassemble upper layer packets to adjust them to a size suitable for transmission over the radio interface. Additionally, the RLC layer performs reordering to compensate for out-of-order reception caused by hybrid automatic re-request (HARQ) operations in the MAC layer.

The S1-based protocol may include the MAC layer, which is a protocol layer above the physical layer (PHY) and below the RLC layer in the LTE protocol stack. The MAC layer is connected to the PHY layer via transport channels and to the RLC layer via logical channels. The MAC layer performs data transmission scheduling and multiplexing/demultiplexing between logical channels and transport channels.

In LTE, encryption and integrity are used to protect data received from third parties or to detect changes made by third parties. Generally, integrity refers to the receiver verifying that the received message is the same as the message delivered by the transmitter/sender, while encryption refers to the transmitter/sender encrypting the data using a security key known to the receiver. In the access stratum (AS) layer, encryption and integrity are applied to RRC signaling data (i.e., control plane data), while encryption is only applied to user data (i.e., user plane data or DRB data). The RRC layer is responsible for handling AS security keys and AS security procedures. In addition, the PDCP layer performs integrity and encryption of RRC signaling data, as well as encryption of user plane data.

Different security keys are used for encryption and integrity in the control plane and data user plane. Security keys may include _KUPenc , _KRRCint , and _KRRCenc . _KUPenc is a security key used to protect user plane traffic using a specific encryption algorithm. _KRRCint is a security key used to protect RRC traffic using a specific integrity algorithm. _KRRCenc is a security key used to protect RRC traffic using a specific encryption algorithm.

Typically, the security keys are _KUPenc , _KRRCint , and _KRRCenc . _KUPenc can be generated from the security key _KeNB . For example, _KUPenc and _KRRCenc can be derived at the mobile equipment (ME) and eNB from _KeNB and the identifier of the encryption algorithm. _KRRCint can be derived at the ME and eNB from _KeNB and the identifier of the integrity algorithm. Alternatively, the AS can derive _KeNB from _KASME , _a common secret security key available to both the UE and the network.

In Release 10 CA, the primary cell is responsible for providing the security key (K _eNB ). Since in Release 10 CA, all serving cells are located in the same eNB and the PDCP layer is defined for each radio bearer (RB), regardless of the number of serving cells, a single security key can be used for carrier aggregation. However, in EUTRA inter-eNB CA, each eNB uses a security key to perform data encryption in the PDCP layer. As explained in further detail below, security key management can enable eNBs to share the same security key or, alternatively, enable eNBs to use different security keys when performing data encryption in the PDCP layer.

If the PDCP layer of a radio bearer (RB) is located in different eNBs, security key management can be performed in EUTRA inter-eNB CA. For example, a macro eNB can be associated with a macro cell, and a small eNB (e.g., a pico eNB) can be associated with a small cell (e.g., a pico cell). Since the data radio bearer is configured in the small cell, user plane encryption can be performed with the encryption key _KUPenc . Alternatively, if the signaling radio bearer (SRB) is configured in the small cell, control plane encryption and integrity can be performed with the encryption keys _KRRCint and _KRRCenc .

In one configuration, the small eNB can generate the same security keys used at the macro eNB. Thus, K _eNB is provided to the small eNB for use in generating the same security keys used at the macro eNB. A small cell associated with the small eNB can be added as a secondary cell, and a new dedicated radio bearer can be established for the small cell. As an example, carrier aggregation can be performed using a macro cell and a secondary cell. An additional small cell can be added as an additional secondary cell. Thus, carrier aggregation can be performed using the macro cell and two secondary cells. The same security keys can be shared among the three eNBs associated with the macro cell and the two secondary cells. In other words, the two small eNBs associated with the two secondary cells can generate the same security keys used by the macro eNB. Additionally, a new dedicated radio bearer can be established for the additional secondary cell.

When adding a small cell as a secondary cell and establishing a new dedicated radio bearer for the small cell, at least two methods can be implemented. In the first method, the MME can deliver an S1 Application Protocol (S1AP) message to the small eNB. The S1AP message can configure the S1 bearer between the small eNB and the S-GW. The S1AP message can be delivered directly from the MME to the small eNB. Alternatively, the macro eNB can receive the S1AP message from the MME and forward it to the small eNB. The MME can provide security information ( _KASME ) via the S1AP message during the S1 bearer establishment process. The small eNB can determine the security key K _eNB based on _KASME in the access stratum (AS) layer.

In the second method, the macro eNB transmits an X2 Application Protocol (X2AP) message to the small eNB. The X2AP message contains an instruction to add the small eNB as a secondary cell. The X2AP message can be transmitted via the X2 interface. Therefore, the macro eNB can provide K _eNB (or K _UPenc ) to the small eNB via the X2AP message for configuring the secondary cell. Therefore, the security key K _eNB used at the small eNB is the same as that used at the macro eNB.

Figure 4 illustrates an exemplary transfer of security key information between a macro eNB and a small eNB. Specifically, Figure 4 illustrates the macro eNB providing the security key K _eNB to the small eNB via the X2 interface. The MME may transfer an initial context setup request message to the macro eNB. The macro eNB may transfer an AS security mode command message to the macro eNB. At the UE, security may be enabled in response to receiving the AS security mode command message. The UE may transfer a measurement report to the macro eNB. The macro eNB determines whether to perform carrier aggregation. The macro eNB may transfer a secondary cell add request message to the small eNB. The secondary cell add request message may be an X2AP message transferred via the X2 interface. Additionally, the secondary cell add request message may provide the security key K _eNB (or K _UPenc ) to the small eNB. Thus, the small cell may be configured with the security key K _eNB . The small eNB may transfer a secondary cell add request acknowledgement (ACK) message to the macro eNB. The macro eNB may transfer a radio resource control (RRC) connection reconfiguration message to the user equipment (UE). The RRC connection reconfiguration message instructs the UE to add the secondary cell, so that the UE can receive data from the secondary cell (or small cell) and the macro cell.

In an alternative configuration, a small cell may be added as a secondary cell and an existing dedicated radio bearer may be reconfigured to be handed over to the small cell. The existing dedicated radio bearer may be reconfigured in response to the small eNB generating the same security keys as used at the macro eNB. In other words, a path handover occurs from one small cell to another small cell (i.e., a new small cell). As an example, a macro cell and a first small cell may be used for carrier aggregation. A second small cell (e.g., a small cell different from the first small cell) may be added such that the second small cell is used in conjunction with the first small cell and the macro cell for carrier aggregation. The second small cell may also be referred to as a new small cell. Thus, the eNB associated with the second small cell may generate the same security keys as used at the eNB associated with the first small cell.

When adding a small cell as a secondary cell and reconfiguring an existing dedicated radio bearer to facilitate handover to the small cell, at least two methods can be described. In the first method, the macro eNB can pass an X2AP message to the new small eNB. This X2AP message can include the security key K _eNB (or K _UPenc ). In other words, the new small eNB can generate the same security key used by the macro eNB.

In the second method, the source small eNB (e.g., the old small eNB) can pass an X2AP message to the new small eNB. The X2AP message can include the security key K _eNB (or K _UPenc ). In other words, the interface between the source small eNB and the new small eNB can be used to pass the X2AP message. Therefore, the new small eNB can generate the same security keys used at the source small eNB.

If the same security key is used, even if a new secondary cell is added and a new DRB is established, minimal impact can be generated on the UE that is performing encryption. In addition, the macro eNB (or small eNB) may not report security information updates to the MME.

In one configuration, a macro eNB and a small eNB can use different security keys. For example, a small eNB can generate security keys that are different from the security keys used at the macro eNB. In another example, multiple small eNBs used in conjunction with a macro eNB for carrier aggregation can each generate security keys that are different from the security keys used by other small eNBs and the macro eNB.

In one configuration, the macro eNB can provide the security key K _eNB * to the small eNB. The security key K _eNB * can become the security key K _eNB of the small cell. The macro eNB can generate the security key K _eNB * using the security key K _eNB , the physical cell identity, and the EUTRA Absolute Radio Frequency Channel Number Downlink (EARFCN-DL) of the small cell. Typically, the Absolute Radio Frequency Channel Number (ARFCN) can define a pair of radio frequency (RF) channel frequencies for uplink and downlink use. Alternatively, the macro eNB can generate the security key K _eNB * using the Next Hop (NH) parameter, as used for security key handling during handover. The macro eNB can provide the security key K _eNB * to the small eNB so that the macro eNB and the small eNB use different security keys.

FIG4 illustrates an example of transferring security key information (e.g., K _eNB *) between a macro eNB and a small eNB. The macro eNB may provide the security key K _eNB * to the small eNB via the X2 interface. The macro eNB may determine to perform carrier aggregation. Subsequently, the macro eNB may transfer a secondary cell add request message to the small eNB. The secondary cell add request message may be an X2AP message transferred via the X2 interface. In addition, the secondary cell add request message may provide security information, such as the security key K _eNB *, to the small eNB. Thus, the small eNB may use different security keys than the macro eNB (e.g., the small eNB may use the security key K _eNB *, while the macro eNB may use the security key K _eNB ).

Since the MME can store security key information used by eNBs and UEs, the macro eNB and/or small eNB can notify the MME of updated security information. For example, after receiving a different security key (e.g., K _eNB *) from the macro eNB, the small eNB can notify the MME. Alternatively, after sending a different security key (e.g., K _eNB *) to the small eNB, the macro eNB can notify the MME.

As shown in Figure 4, the macro eNB can transmit a secondary cell add request message to the small eNB. In response, the small eNB can transmit a secondary cell add request acknowledgement (ACK) message to the macro eNB. The secondary cell add ACK message may include one or more security algorithm identifiers for the selected security algorithm. The security algorithm identifier can be used to generate _KUPenc , _KRRCint , etc. using security keys _KeNB . In other words, the secondary cell (e.g., the small eNB) can send the security algorithm identifier to the primary cell (e.g., the macro eNB). The macro eNB can transmit security information (e.g., the security algorithm identifier) to the UE via an RRC connection reconfiguration message. In addition, the RRC connection reconfiguration message may include an instruction to add the small cell as a secondary cell. As a result, the UE can receive user data from the macro eNB together with the small eNB through carrier aggregation.

In one configuration, when multiple security keys are used in EUTRA inter-eNB CA, the UE can store and apply multiple security keys. Depending on the type of radio bearer, the UE can apply different security keys. For example, K _eNB,1 is the security key for the macro eNB, while K _eNB,2 is the security key for the small eNB. _{K eNB,2} is the same security key as K _eNB * provided from the macro eNB to the small eNB. Therefore, K _eNB,1 is used for signaling radio bearer (SRB) and data radio bearer (DRB) 1 configured in the macro eNB. In addition, K _eNB,2 is used for DRB2 and DRB3 configured in the small cell.

In one configuration, a COUNT value may be used in integrity and ciphering at the PDCP layer. The COUNT value may include a hyperframe number (HFN) and a PDCP sequence number (SN). The HFN is a number that increments in relation to the PDCP sequence number. The HFN is included in a PDCP protocol data unit (PDU) counter for ciphering.

In one example, a cipher failure may occur when the COUNT value is out of sync between the UE and the eNB due to data loss. Therefore, the E-UTRAN may use a counter check procedure to minimize data loss, thereby reducing the possibility of cipher failure. The E-UTRAN may request the UE to verify the amount of data sent/received on each DRB. Specifically, the UE may be requested to check whether the most significant bit of the COUNT corresponds to (or matches) the value indicated by the E-UTRAN for each DRB. If the most significant bit of the COUNT value corresponds to the value indicated by the E-UTRAN, the COUNT value is not out of sync (i.e., in sync) between the UE and the eNB due to data loss.

During the counter check procedure, the eNB (e.g., a small eNB or a macro eNB) may deliver a counter check message to the UE. In one example, the counter check message may be included in a radio resource connection (RRC) message delivered to the UE. The counter check message may include a configured COUNT most significant bit (MSB) value. After receiving the counter check message, the UE may compare the configured COUNT MSB value with the actual COUNT MSB value. If the UE determines that the configured COUNT MSB value is the same as the actual COUNT MSB value, the UE may deliver a counter check response message to the eNB (e.g., a small eNB or a macro eNB). The counter check response message may include the COUNT value for the requested DRB in the counter check procedure. In other words, the UE may verify that the amount of data on each DRB corresponds to the amount of data configured for each DRB.

There are two methods for performing the counter check procedure in EUTRAN inter-eNB CA, depending on which eNB triggers the counter check procedure. In the first method, the macro eNB triggers the counter check procedure. The macro eNB may deliver a counter check message to the UE via an RRC message. The macro eNB may receive a counter check response message from the UE. The counter check response message may include the COUNT value for the DRB configured in the small cell. The macro eNB may deliver the COUNT value to the small eNB via an X2AP message. Alternatively, the macro eNB may not request a counter check for DRBs configured in the small eNB.

In the second method, the small eNB triggers a counter check procedure. The small eNB may wish to check the COUNT value for the DRBs configured in the small cell. Therefore, the small eNB may communicate a request for the COUNT value to the macro eNB via an X2AP message. The X2AP message may include the DRB index to be reported and the actual COUNT MSB value. The macro eNB may receive the COUNT value request in the X2AP message from the small eNB. The macro eNB may communicate the counter check message to the UE via an RRC message. The macro eNB may receive a counter check response message from the UE. The counter check response message may include the COUNT value for the DRBs configured in the small cell. The macro eNB may communicate the COUNT value to the small eNB via an X2AP message.

As shown in the flowchart of FIG5 , another example provides functionality 500 of computer circuitry of a first node operable to communicate security key information to a second node. The functionality can be implemented as a method, or the functionality can be executed on a machine as instructions, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The computer circuitry can be configured to determine a first security key associated with the first node, the first security key used to encrypt information communicated at the first node, as shown in block 510. The computer circuitry can also be configured to identify the second node at the first node to receive a second security key, the second security key to be used to encrypt information communicated at the second node, as shown in block 520. The computer circuitry can further be configured to provide the second node with a second security key for use in Evolved Universal Terrestrial Radio Access (EUTRA) inter-eNB carrier aggregation, the second security key being different from the first security key, as shown in block 530.

In one configuration, the computer circuitry may be further configured to provide the second security key to the second node in a secondary cell add message. In one example, the first node may be configured to serve a primary cell, and the second cell may be configured to serve a secondary cell. Additionally, the second security key may be generated at the first node using the first security key, a physical cell identifier, and the EUTRA Absolute Radio Frequency Channel Number (EARFCN) of the secondary cell. Alternatively, the second security key may be generated using a Next Hop (NH) parameter.

In one configuration, the computer circuitry may be further configured to receive, at the first node, security key update information from the second node, wherein the security key update information includes a security algorithm identifier. Additionally, the computer circuitry may be further configured to provide the second security key to a user equipment (UE), wherein the UE communicates with the first node and the second node via EUTRA inter-eNB carrier aggregation using the first security key and the second security key, respectively.

In one example, the UE includes an antenna, a touch-sensitive display, a speaker, a microphone, a graphics processor, an application processor, and an internal memory or a non-volatile memory port. Additionally, the first node and the second node are selected from the group consisting of a macro node, a base station (BS), a node B (NB), an evolved node B (eNB), a home eNB, a micro eNB, a baseband unit (BBU), a remote radio head (RRH), a femto node, a low power node, a remote radio equipment (RRE), or a remote radio unit (RRU).

As shown in the flowchart of FIG6 , another example provides a method 600 for transferring security key information from a macro eNB. The method may be executed as instructions on a machine, wherein the instructions are included in at least one computer-readable medium or a non-transitory machine-readable storage medium. The method includes the following operations: determining security key information associated with a macro evolved Node B (eNB), the security key information used to encrypt information transferred at a first eNB, as shown in block 610. The method may include identifying a small eNB at the macro eNB to generate security key information associated with the macro eNB, used to encrypt information transferred at a second eNB, as shown in block 620. The next operation of the method may include transferring the security key information from the macro eNB to the small eNB for use in Evolved Universal Terrestrial Radio Access (EUTRA) inter-eNB carrier aggregation, as shown in block 630.

In one example, the macro eNB may be configured to serve a primary cell, and the small eNB may be configured to serve a secondary cell. Additionally, the method may include transferring security key information from the macro eNB to the small eNB via an X2 interface.

In one configuration, the method may include delivering security key information to the small eNB in a secondary cell add request X2 application protocol (X2AP) message via an X2 interface. Additionally, the method may include delivering the security key information from the small eNB to a new small eNB associated with the UE for EUTRA inter-eNB carrier aggregation. In one example, the method may include: receiving an S1 application protocol (S1AP) message from a mobility management entity (MME) at a macro eNB, the S1AP including security key information associated with the macro eNB; and delivering the security key information from the macro eNB to the small eNB via the S1AP message, the small eNB using the security key information to encrypt information delivered at the small eNB.

In one configuration, the method includes communicating security key information from a macro eNB to a user equipment (UE), the UE using the security key information to communicate with the macro eNB and a small eNB via EUTRA inter-eNB carrier aggregation using first and second security keys, respectively.

As shown in the flowchart of FIG7 , another example provides functionality 700 of a computer circuit of a first wireless node operable to communicate integrity and encryption information. The functionality may be implemented as a method, or the functionality may be executed on a machine as instructions, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The computer circuit may be configured to communicate a counter check procedure request to a user equipment (UE) to verify the amount of data communicated on each data radio bearer (DRB) at the UE for Evolved Universal Terrestrial Radio Access (EUTRA) inter-eNB carrier aggregation, as shown in block 710. The computer circuit may also be configured to receive a counter check message from the UE, the counter check message including a count value for a first DRB associated with the first wireless node and a second DRB associated with a second wireless node, the count value indicating the amount of data communicated per DRB, as shown in block 720. The computer circuit may further be configured to identify the second wireless node to receive the count value from the first wireless node, as shown in block 730. Additionally, the computer circuitry may be configured to communicate the count value of the second DRB to the second wireless node using an X2 Application Protocol (X2AP) message, as shown in block 740 .

In one example, the count value includes a hyperframe number (HFN) and a packet data convergence protocol (PDCP) sequence number. In one configuration, the computer circuitry may be configured to: receive a request for a count value associated with a second DRB from a second wireless node; transmit a radio resource connection (RRC) message to a UE requesting the UE to transmit the count value to the first wireless node; receive a count check message from the UE, the count check message including the count value; and transmit the count value to the second wireless node using an X2AP message. Additionally, the first wireless node may be a macro node, and the second wireless node may be a small node.

Figure 8 provides an example illustration of a wireless device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a mobile phone, or other type of wireless device. The wireless device may include one or more antennas configured to communicate with a node, a macro node, a low power node (LPN), or a transmitting station, such as a base station (BS), an evolved Node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio device, or other type of wireless wide area network (WWAN) access point. The wireless device may be configured to communicate using at least one wireless communication standard, including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The wireless device may communicate using a separate antenna for each communication standard or a shared antenna for multiple wireless communication standards. The wireless device may communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.

FIG8 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the wireless device. The display screen can be a liquid crystal display (LCD) screen or other type of display screen, such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. The application processor and graphics processor can be coupled to the internal memory to provide processing and display capabilities. The non-volatile memory port can also be used to provide data input/output options to the user. The non-volatile memory port can also be used to expand the storage capacity of the wireless device. A keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.

The various techniques or certain aspects or portions thereof may take the form of program code (i.e., instructions) embodied in a tangible medium, such as a floppy disk, CD-ROM, hard disk, non-transitory computer-readable storage medium, or any other computer-readable storage medium, wherein when the program code is loaded into a machine (e.g., a computer) and executed by the machine, the machine becomes an apparatus for implementing the various techniques. Circuitry may include hardware, firmware, program code, executable code, computer instructions, and/or software. Non-transitory computer-readable storage media may be computer-readable storage media that does not include signals. In the case of program code execution on a programmable computer, the computing device may include a processor, a storage medium readable by the processor (including volatile memory and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile memory and non-volatile memory and/or storage elements may be RAM, EPROM, a flash drive, an optical drive, a magnetic hard drive, a solid-state drive, or other medium for storing electronic data. Nodes and wireless devices may also include a transceiver module, a counter module, a processing module, and/or a clock module or a timer module. One or more programs that can implement or utilize the various techniques described herein can use application programming interfaces (APIs), reusable controls, and the like. Such programs can be implemented in high-level procedural programming languages or object-oriented programming languages to communicate with a computer system. However, if desired, the programs can be implemented in assembly language or machine language. In any case, the language can be a compiled language or an interpreted language and combined with a hardware implementation.

It should be understood that many of the functional units described in this specification have been labeled as modules in order to more particularly emphasize the independence of their implementation. For example, modules can be implemented as hardware circuits (including custom VLSI circuits or gate arrays), off-the-shelf semiconductors (e.g., logic chips, crystal optics), or other discrete components. Modules can also be implemented in programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, etc.

Modules can also be implemented in software so that they can be executed by various types of processors. For example, an identified module of executable code can include one or more physical or logical blocks of computer instructions, which can be organized into objects, procedures, or functions, for example. However, the executable files of the identified modules need not be physically located together, but can include distinct instructions stored in different locations that, when logically combined together, constitute the module and achieve the purpose described for the module.

In fact, the module of executable code can be a single instruction or many instructions, and can even be distributed on several different code segments, distributed between different programs, and distributed on several storage devices. Similarly, operational data can be identified and shown as within the module here, and can be embodied in any suitable form and organized in any suitable type of data structure. Operational data can be collected as a single data set, or can be distributed on different locations (including on different storage devices), and can be at least partially present only as electronic signals on a system or network. Modules can be passive or active, including agents that can be operated to perform desired functions.

References throughout this specification to "(one) example" mean that a particular feature, structure, or characteristic described in connection with that example is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "in (one) example" in various places throughout this specification are not necessarily all referring to the same embodiment.

As used herein, for convenience, multiple projects, structural elements, component elements and/or materials can be presented in a public list. However, these lists should be interpreted as each member in the list is individually identified as a separate and unique member. Therefore, in the absence of contrary instructions, each member of such a list should not be interpreted as the de facto equivalent of any other member in the same list based only on their common representation. In addition, various embodiments of the present invention and examples can be cited together with the alternatives of their various parts at this. It should be understood that these embodiments, examples and alternatives should not be interpreted as de facto equivalents to each other, but should be interpreted as separate and autonomous performance of the present invention.

In addition, described features, structures or characteristics may be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided, such as layout examples, distance examples, network examples, etc., to provide a comprehensive understanding of embodiments of the present invention. However, those skilled in the art will appreciate that the present invention may be implemented without one or more of these specific details, or may be implemented with other methods, parts, layouts, etc. In other cases, known structures, materials, or operations are not shown and described in detail to avoid covering up aspects of the present invention.

Although the foregoing examples illustrate the principles of the present invention in one or more specific applications, it will be apparent to those skilled in the art that many modifications may be made in the form, use, and details of the embodiments without inventive effort and without departing from the principles and concepts of the present invention. Therefore, it is not intended to limit the present invention except as set forth in the claims below.

Claims (16)

1. A lead-in node B, or MeNB, capable of operating to support dual connectivity, the MeNB comprising: One or more processors, and A memory that stores instructions that, when executed by the processor, cause the processor to perform the following operations: At the MeNB, the SeNB counter check request message received from the secondary evolved node B, i.e., the SeNB, is processed; and At the MeNB, in response to a SeNB counter check request message received from the SeNB, a counter check procedure is performed, wherein the counter check procedure causes the MeNB to send one or more Radio Resource Control (RRC) messages to the User Equipment (UE) to verify the COUNT value of the bearer established in the SeNB. 2. The MeNB according to claim 1, further comprising a transceiver configured to receive a SeNB counter check request message from the SeNB. 3. The MeNB of claim 1, wherein, when the instruction is executed by the processor, the processor further performs the following operations: At the MeNB, security key information is processed for transmission to the UE, wherein the security key information is associated with the SeNB. 4. The MeNB according to any one of claims 1 to 3, wherein the SeNB counter check request message is an X2 application protocol message. 5. The MeNB according to any one of claims 1 to 3, wherein the COUNT value is a packet data aggregation protocol COUNT value. 6. The MeNB according to any one of claims 1 to 3, wherein, when the instructions are executed by the processor, the processor further performs the following operations: In response to receiving the SeNB counter check request message from the SeNB, the UE performs an RRC counter check procedure. 7. A non-transitory machine-readable storage medium storing instructions for supporting dual connectivity at a main feeder node B, i.e., a MeNB, wherein the instructions, when executed, perform the following operations: The MeNB uses at least one processor to process the SeNB counter check request message received from the secondary evolved node B, i.e., the SeNB; and In response to a SeNB counter check request message received from the SeNB, a counter check procedure is performed using at least one processor of the MeNB, wherein the counter check procedure causes the MeNB to send one or more Radio Resource Control (RRC) messages to the User Equipment (UE) to verify the COUNT value of the bearer established in the SeNB. 8. The non-transitory machine-readable storage medium of claim 7, further comprising the following instructions, which, when executed, perform the following operations: At the MeNB, security key information is processed for transmission to the UE, wherein the security key information is associated with the SeNB. 9. The non-transitory machine-readable storage medium according to any one of claims 7 to 8, wherein the SeNB counter check request message is an X2 application protocol message. 10. The non-transitory machine-readable storage medium according to any one of claims 7 to 8, wherein the COUNT value is a packet data aggregation protocol COUNT value. 11. The non-transitory machine-readable storage medium according to any one of claims 7 to 8, further comprising the following instructions, which, when executed, perform the following operations: In response to receiving the SeNB counter check request message from the SeNB, the UE performs an RRC counter check procedure. 12. A lead-in node B, or MeNB, capable of operating to support dual connectivity, the MeNB comprising: A module for processing SeNB counter check request messages received from the secondary evolved node B (SeNB) using at least one processor of the MeNB; and A module for performing a counter check procedure using at least one processor of the MeNB in response to a SeNB counter check request message received from the SeNB, wherein the counter check procedure causes the MeNB to send one or more Radio Resource Control (RRC) messages to the User Equipment (UE) to verify the COUNT value of a bearer established in the SeNB. 13. The MeNB according to claim 12, further comprising: A module for processing security key information at the MeNB for transmission to the UE, wherein the security key information is associated with the SeNB. 14. The MeNB according to any one of claims 12 to 13, wherein: The SeNB counter check request message is an X2 application protocol message. 15. The MeNB according to any one of claims 12 to 13, wherein: The COUNT value is the COUNT value of the Packet Data Convergence Protocol. 16. The MeNB according to any one of claims 12 to 13, further comprising: A module for performing an RRC counter check procedure with the UE in response to receiving a SeNB counter check request message from the SeNB.