Dual connectivity mode of operation of a user equipment in a wireless communication network

A system and method provide a security aspect for a UE in dual connectivity mode of operation in wireless communication networks. The system and method provide secure simultaneous transmission and reception in a secure manner between a User Equipment (UE) and one or more eNodeBs (eNBs) configured in an inter-eNB carrier aggregation scenario. The system establishes of a security context between the UE and the Secondary eNB (SeNB) using the RRC signaling between the UE and the Master eNB (MeNB), when a plurality of SCells within SeNB are added simultaneously. The system also detects the intruder in the user data radio bearers, while a UE is operating in dual connectivity mode of operation.

The present application is related to and claims priority from an Indian Application Number 202/CHE/2014 filed on 17 Jan. 2014 and Indian Application Number 1540/CHE/2014 filed on 24 Mar. 2014, the disclosure of which is hereby incorporated by reference herein.

TECHNICAL FIELD

The present application relates to the field of wireless communication and more particularly to security aspect for a User Equipment (UE) in dual connectivity mode of operation in wireless communication networks.

BACKGROUND

With rise in deployment of Long term Evolution (LTE) and LTE advanced (LTE-A), small cells using low power nodes such as a Pico cell and a Femto cell are considered promising to cope with mobile traffic explosion. A small cell using a low power node, which has transmission power (Tx) lower than macro node and Base Station (BS) classes, is preferred for hotspot deployments in indoor and outdoor scenarios resulting in enhanced performance.

The small cell enhancement for Evolved Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (E-UTRAN) and E-UTRA focuses on additional functionalities for enhanced performance in hotspot areas for indoor and outdoor using the low power nodes.

The 3rdGeneration Partnership Project (3GPP) is considering use of potential higher layer technologies for enhanced support of small cell deployments in Evolved (Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (E-UTRA) and E-Evolved UMTS Terrestrial Radio Access Network (UTRAN) to fulfill the deployment scenarios and the requirements specified in TR 36.932.

3GPP is considering a deployment scenario, in which different frequency bands are separately assigned to macro layer and small cell layer, respectively. Small cell enhancement is expected to support significantly increased user throughput for both downlink and uplink with main focus on typical user throughput, considering a reasonable system complexity. Small cell enhancement is expected to target the capacity per unit area (such as in bps/km2) to be as high as possible, for a given user and small cell distribution, typical traffic types and considering a reasonable system complexity. The small cell enhancements are also expected to consider the impact of the actual backhaul delays and provide solutions with the aim of improved system performance. Other aspects, for example service quality of Voice over Long Term Evolution (LTE) (VoLTE), such as Mean Opinion Score (MOS) and delay or jitter impacts on services, such as video streaming, video calls and so forth, could also be addressed later.

In LTE Release-10 carrier aggregation, all the component carriers involved in carrier aggregation is handled at the same evolved NodeB (eNB) (co-located) and the component carriers are from the same frequency band i.e. intra-band carrier aggregation. In LTE Release-11 specification supports inter-band carrier aggregation where the component carriers are from different frequency bands. In the inter-band carrier aggregation scenario the component carrier (F1) from a lower frequency band can provide coverage and mobility whereas the other component carrier (F2) from a higher frequency band can provide high throughput to the User Equipment (UE). The inter-band carrier aggregation could be non-co-located, where the UE is carrier aggregated with at least one first serving frequency by a Master eNB (MeNB) and at least one second serving frequency served by a Secondary eNB (SeNB). When carrier aggregation between at least one cell controlled by two geographically separated eNBs is envisioned then it is called as inter-eNB carrier aggregation and the UE is said to be configured with dual connectivity mode of operation. In such a scenario, dual connectivity is envisioned such that the UE maintains physical links with at least one cell controlled by two geographically separated eNBs. The UE maintains dual connectivity both in downlink and uplink or only downlink. In uplink the dual connectivity towards the MeNB and the SeNB could be simultaneous or could be time multiplexed.

In the so-called dual connectivity mode of operation, the UE consumes radio resources provided by two different network nodes, namely MeNB associated with at least one first serving frequency and SeNB associated with at least one second serving frequency, connected via a non-ideal backhaul interface, such as X2 interface. The MeNB is the eNB that hosts the Radio Resource Control (RRC) layer and a single S1-MME termination point exists for a UE configured with dual connectivity mode of operation between the Mobile Management Entity (MME) and the E-UTRAN. The MeNB, therefore, acts as a mobility anchor towards the core network (CN). The E-UTRAN architecture and related functions to support Dual Connectivity for E-UTRAN is further described in TS 36.300.

In existing security mechanisms for single connectivity or UE supporting Release-10 or Release-11 carrier aggregation, authentication and authorization are performed using the authentication and key agreement procedure (AKA) defined for the evolved Universal Terrestrial Radio Access Network (E-UTRAN) in the LTE Networks. An initial security key is derived by the Mobility Management Entity (MME) in the core network and sent to a serving or source eNB of the UE. During an inter-eNB (S1 or X2-intiated) handover, the serving eNB derives the security key for a target eNB, using a base security key (if an interface such as an X2 interface exists between the serving eNB and the target eNB), to which the UE is handed over due to mobility. The security key provided by the serving eNB is used for deriving further keys in the target eNB, which are used for user plane data protection (same like serving eNB, UE derives the security key and further keys like target eNB).

During a handover (HO), using vertical key derivation, that is, the unused next hop (NH) parameters can be used for deriving the base security key at the source eNB (when S1 interface is involved in HO procedure). For dual connectivity, the existing procedure using vertical key derivation, a new security key associated with the secondary eNB (SeNB) for the UE can be derived at the Master eNB (MeNB) using unused Next Hop (NH) parameters. However, the unused NH parameters may not be always available at the MeNB to derive the security key associated with SeNB using vertical key derivation. In existing security mechanism during HO an existing security key associated with the source eNB can be used for deriving the base security key. For dual connectivity, this principle can be extended such that the existing security key of the MeNB can be used as for deriving the security key for the SeNB. The use of the MeNB security key for deriving the security key of SeNB for securing the communication between the SeNB and the UE may not provide adequate key separation and also possible key stream repetition issue, resulting in security compromise.

Further, if the MeNB derives security key for the SeNB using an existing security key, then the key repetition will occur. For example, if each time the same SeNB is removed and added again for supporting dual connectivity, the security key generated may be repeated. Further key repetition may also occur if the first SeNB is removed and another different second SeNB is added, but the first SeNB and second SeNB operate on the same frequency and have the same physical cell identity (PCI). Another scenario for key repetition occurrence is when the user plane data handled by the data radio bearer (DRB) established on the SeNB experience PDCP COUNT wrap around (that is, when same PDCP Count value with same DRB-ID and security key are used again (more than once), it is possible to derive the key stream or message details). Therefore, key stream repetition is highly possible when the existing security mechanism defined in TS 33.401 is used for dual connectivity and leads to exposing the user plane to security attacks, which needs to be avoided.

In addition to key repetition, the security capabilities and/or local configuration of the SeNB may be different from the MeNB. Hence, the UE configured with dual connectivity may need to use different cryptographic algorithms for communicating with the SeNB. The establishment of security context between the SeNB and the UE requires knowledge of the security algorithms supported and selected by the MeNB.

When there is no restriction to add only one SCell in the SeNB at a time, that is, it is allowed to add more than one SCell in the SeNB at initial configuration of the SeNB, then using the existing HO security mechanism for Dual connectivity, the MeNB should know the PCI and operating downlink frequency (EARFCN-DL) of one of the SCell within the SeNB to be used to derive the security key for the SeNB.

When the PDCP count of any PDCP entity handling the DRB in MeNB is about to wrap around then the MeNB could initiate intra-cell handover (i.e., handover to the same MeNB cell) to refresh the MeNB key, then the MeNB would have to release all the SCells in the SeNB at the same time in order to ensure that security key of SeNB is also updated (based on refreshed MeNB key). When the security key of the MeNB is updated while the SeNB continues to use existing security key that was derived from previous security key of the MeNB, then this may result in security compromise and, hence, it is not a good security practice (to use secondary keys derived from primary key which is invalidated). When the PDCP count of any PDCP entity handling the DRB in the SeNB is about to wrap around, then key repetition occurrence is possible when the user plane data handled by the data radio bearer (DRB) established on the SeNB experience PDCP COUNT wrap around (that is same PDCP Count value with same DRB-ID and security key are used again (more than once)).

Limitations and disadvantages exist in the operation and management of security mechanism such as countercheck procedure execution for DRB established in the SeNB for a UE configured with dual connectivity mode of operation that can lead to a potential compromise in security. Existing countercheck procedure does not address the issue of intruder detection in dual connectivity, as the SeNB does not have direct RRC signaling connection with the UE. There needs to be a method to check the PDCP counter associated with the SeNB, for whether an packet injection attack is mounted and also possibly flag the DRB-IDs with the indication indicating which node is responsible for handling the DRB and providing the UE the means to identity the correct DRB context used in the MeNB or SeNB.

In legacy LTE systems (namely, Release 8 to Release 11), the countercheck procedure is specified in 3GPP specification TS 36.331 (section 5.3.6) for detecting packet injection attack, where the RRC procedure is kind of audit where eNB checks if the PDCP COUNT provided by the UE for the established DRBs match with the values sent by the eNB in the request message of the procedure. If such an intruder attack is detected, then the network can decide to release the RRC connection immediately and can initiate other procedure like informing network node about the attack. For Release-10 carrier aggregation (CA), the primary cell (PCell) of the UE initiates the countercheck procedure for the DRB established on the SCell(s). This principle cannot be applied for dual connectivity where the RRC layer sits in the MeNB and there is no context or information about the PDCP entity in the SeNB available with the MeNB.

Compared to Release-10 CA, the extension of countercheck procedure for dual connectivity requires new signaling support on the X2 interface and also in the RRC signaling between the UE and the MeNB.

SUMMARY

The aspect of the embodiments herein is to provide secure simultaneous transmission and reception in a secure manner between a User Equipment (UE) and one or more eNodeBs (eNBs) configured in an inter-eNB carrier aggregation scenario.

Another aspect of the disclosure is to propose methods and systems for establishment of a security context between the UE and the SeNB using the RRC signaling between the UE and the MeNB, when a plurality of SCells within SeNB are added simultaneously.

Another aspect of the disclosure is to propose methods and systems for establishment or updating of a security context between the UE and the SeNB using the X2 signaling between the MeNB and SeNB and RRC signaling between the UE and the MeNB, when the PDCP COUNT of at least one DRB established on at least one second serving frequency served by the SeNB is about to wrap around.

Another aspect of the disclosure is to propose methods and systems for establishment or updating of a security context between the UE and the SeNB using the X2 signaling between the MeNB and SeNB and RRC signaling between the UE and the MeNB, when the SCell configured for the UE with PUCCH resources on at most one second serving frequency served by the SeNB is changed.

Another aspect of the disclosure is to propose methods and systems for establishment or updating of a security context between the UE and the SeNB using the X2 signaling between the MeNB and SeNB and RRC signaling between the UE and the MeNB, when the cryptographic algorithms used by the UE and the SeNB to be changed.

Another aspect of the disclosure is to propose a mechanism to detect the intruder (packet injection) in the data radio bearers using the X2 signaling between the MeNB and SeNB and RRC signaling between the UE and the MeNB, when the UE is operating in dual connectivity mode of operation.

In accordance with an aspect of the present disclosure, a method is provided for performing a change of a serving cell group (SCG) in a wireless communication system supporting a dual connectivity of a user equipment, the method comprises transmitting, by a secondary base station for the dual connectivity, a message including information indicating the change of the SCG to a master base station for the dual connectivity, to perform the change of the SCG, and receiving, by the secondary base station, a security key associated with the secondary base station, the security key being refreshed by the change of the SCG.

In accordance with another aspect of the present disclosure, a secondary base station is provided for performing a change of a serving cell group (SCG) in a wireless communication system supporting a dual connectivity of a user equipment, the secondary base station comprises a communication interface configured to communicate with other network entity, and a controller configured to control transmitting a message including information indicating the change of the SCG to a master base station for the dual connectivity, to perform the change of the SCG, and receiving a security key associated with the secondary base station, the security key being refreshed by the change of the SCG.

In accordance with further aspect of the present disclosure, a method is provided for performing packet data convergence protocol (PDCP) counter check of a serving cell group (SCG) in a wireless communication system supporting a dual connectivity of a user equipment, the method comprises receiving, by a master base station for the dual connectivity, a request message including information for checking a PDCP count from a secondary base station for the dual connectivity, the PDCP count being associated with a SCG radio bearer of the secondary base station, and performing, by the master base station in response to the request message, a PDCP counter check procedure to verify a value of the PDCP count, based on the received information.

In accordance with further aspect of the present disclosure, a master base station is provided for performing packet data convergence protocol (PDCP) counter check of a serving cell group (SCG) in a wireless communication system supporting a dual connectivity of a user equipment, the base station comprises a communication interface configured to communicate with other network entity, and a controller configured to control receiving a request message including information for checking a PDCP count from a secondary base station for the dual connectivity, the PDCP count being associated with a SCG radio bearer of the secondary base station, and performing, in response to the request message, a PDCP counter check procedure to verify a value of the PDCP count, based on the received information.

Also, provided herein is a method for creating a secure connection for a User Equipment (UE) in a wireless communication network operating in a dual connectivity mode, the wireless communication network comprising of a first evolved NodeB (eNB) connected to a second eNB by an X2 interface, wherein the UE is carrier aggregated with at least one first serving frequency served by the first eNB and at least one second serving frequency served by the second eNB. The method includes sending a first Radio Resource Control (RRC) message to the UE by the first eNB. The method also includes, by the first eNB, receiving an indication from the second eNB, wherein the RRC message comprises one of instructions to the UE to update security base key associated with the second eNB and to check a PDCP count associated with at least one Data Radio Bearer (DRB) established on at least one of the first eNB and the second eNB.

Also, provided herein is a wireless communication network including at least one first evolved NodeB (eNB) connected to at least one second eNB by an X2 interface and at least one User Equipment (UE) operating in a dual connectivity mode. The UE is carrier aggregated with at least one first serving frequency served by the first eNB and at least one second serving frequency served by the second eNB. The first eNB is configured for sending a Radio Resource Control (RRC) message to the UE. The first eNB receives an indication from the second eNB, wherein the RRC message comprises one of instructions to the UE to update security base key associated with the second eNB and to check a PDCP count associated with at least one Data Radio Bearer (DRB) established on at least one of the first eNB and the second eNB.

Provided herein is a first evolved NodeB (eNB) in a wireless communication network. The first eNB is connected to at least one second eNB by an X2 interface and at least one User Equipment (UE) operating in a dual connectivity mode. The UE is carrier aggregated with at least one first serving frequency served by the first eNB and at least one second serving frequency served by the second eNB. The first eNB is configured to send a first Radio Resource Control (RRC) message to the UE. The first eNB receives an indication from the second eNB, wherein the RRC message comprises one of instructions to the UE to update security base key associated with the second eNB and to check a PDCP count associated with at least one Data Radio Bearer (DRB) established on at least one of the first eNB and the second eNB.

Provided herein is a second evolved NodeB (eNB) connected to a wireless communication network, wherein the second eNB is connected to at least one first evolved NodeB (eNB) by an X2 interface and at least one User Equipment (UE) operating in a dual connectivity mode. The UE is carrier aggregated with at least one first serving frequency served by the first eNB and at least one second serving frequency served by the second eNB. The second eNB is configured to provide Data Radio Bearer (DRB) identity of at least one DRB established on at least one the second serving frequency served by the second eNB and associated PDCP count values in a X2 message. The first eNB executes countercheck procedure towards the UE for at least one DRB associated with the second eNB upon receiving a second indication by the first eNB from the second eNB over the X2 interface. The second indication indicates execution of countercheck procedure for at least one DRB established on at least one the second serving frequency served by the second eNB.

DETAILED DESCRIPTION

FIGS. 1 through 12, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged wireless communications system. The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

Throughout the document, the terms “first evolved Node B” (first eNB), “Master eNB (MeNB)”, “primary eNB”, and “anchor eNB” are used interchangeably and may refer to a single eNB that connects a User Equipment (UE) to the core network, which terminates at least S1-MME interface. Throughout the document, the terms “second eNB”, “Secondary eNB (SeNB)”, “small eNB”, and “Drift eNB” are used interchangeably and may refer to an eNB that serves the UE to enhance data throughput at the UE (but not the MeNB). Throughout the document, the terms “Second eNB Change Counter (SCC)”, “S-Count Counter (SCC)”, “Secondary Cell Counter”, “Secondary Cell Group (SCG) Counter”, and SCG counter are used interchangeably and refer to a freshness parameter maintained at the first eNB for deriving SeNB base key. Throughout the document, the terms “refresh”, “rekeying” and “update” have been used interchangeably and may refer to the derivation of a fresh security base key associated with the SeNB. Throughout the document, the term “KeNB_m” or “KeNB_M” refer to the key KeNB specified in 3GPP Technical Specification (TS) 33.401, which is used by the MeNB and the UE to derive further keys to protect the communication between them and may also for derivation of SeNB base key. Throughout the document, the term “KeNB_s”, “KeNB_S”, “KeNB_S*” and “KeNB_s*” refer to the key S-KeNB, which is used by the SeNB and the UE to derive further keys to protect the communication between them. Throughout the document, the term “serving cell configured with PUCCH resources”, “Special SCell”, “PSCell” and “pSCell” have been used interchangeably and may refer to at most one serving cell on at least one second serving frequency served by the SeNB. Throughout this document, the term “counter”, “PDCP COUNT”, “PDCP Sequence number” and most significant parts of the PDCP COUNT values are used interchangeably.

Embodiments of the present disclosure achieve security in dual connectivity mode of a User Equipment in, a wireless communication network. Certain embodiments provided a method and system for creating a secure connection for the UE in a wireless network including the first eNB connected to the second eNB. The UE is carrier aggregated with at least one first serving frequency served by the first eNB and at least one second serving frequency served by the second eNB. At the first eNB, a security base key associated with the second eNB is derived using a freshness parameter during at least for one of the following: addition of plurality of SCells within a second eNB, update of the security base key of first eNB, update of the security base key of second eNB, change of cryptographic algorithms and change of serving cell configured with PUCCH resources on, at most, one second serving frequency served by the SeNB. The security base key associated with second eNB is generated based on a security base key associated with the first eNB and a freshness parameter associated with the security context of the first eNB. At the second eNB, a user plane encryption key is derived based on the security base key associated with the second eNB received from the first eNB for encrypting data transfer over at least one data radio bearer established on at least one serving cell associated with the second eNB. The freshness parameter is informed to the UE for deriving the security base key associated with the second eNB and further deriving a user plane encryption key for securing data transfer between the UE and the SeNB. Further, the SeNB provides to the first eNB the DRB identity and PDCP COUNT corresponding to at least one DRB established on at least one serving cell associated with second eNB to execute the counter check procedure towards the UE.

Referring now to the drawings, and more particularly toFIGS. 1 through 12, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

FIG. 1illustrates an inter-evolved node B (eNB) carrier aggregation in a wireless communication network system100such as that of 3GPP's Long Term Evolution (LTE), according to embodiments of the present disclosure. The embodiment of the wireless communication network system100is for illustration only. Other embodiments could be used without departing from the scope of the present disclosure.

The wireless communication network system100includes a Mobility Management Entity (MME)102, a first eNB (MeNB)104, a second eNB (SeNB)106, and a User Equipment (UE)108with inter-eNB carrier aggregation. The MME102manages session states, authentication, paging, mobility with 3GPP, 2G and 3G nodes, roaming, and other bearer management functions. The UE108can be a mobile phone, a tablet, a wearable computing device, a communication dongle or any other device capable of connecting and communicating over a wireless communication network system100. In certain embodiments, the UE108is capable of operating in a dual connectivity mode of operation simultaneously connected to the MeNB104and the SeNB106.

The MeNB104can be a macro eNB, a primary eNB, a first eNB, a anchor eNB or any other eNB capable of being a part of a wireless communication network system100and serving at least one cell served on a first carrier frequency (F1) to the UE108. The SeNB106can be a secondary eNB, a small eNB, a drift eNB or any other eNB capable of being a part of a wireless communication network system100and serving at least one cell served on a second carrier frequency (F2) to the UE108. In certain embodiments, the MeNB and SeNB are parts of the same wireless communication network system100and can be connected to each other at the backend through a non-ideal backhaul such as X2 interface110and communicate using the X2 application protocol (X2-AP). The UE108is configured to be connected to at least one of the MeNB104and SeNB106using an air interface. There can be plurality of SeNBs and MeNBs present in the wireless communication network system100. The wireless communication network system100is only one example of a suitable environment and is not intended to suggest any limitation as to the scope of use or functionality of the disclosure

In certain embodiments, the MeNB104is connected to the SeNB106with an interface characterized by one of a non-ideal backhaul link and an ideal backhaul link. The UE108is carrier aggregated with at least one first serving frequency (F1) served by the MeNB104and at least one second serving frequency (F2) served by the SeNB106and configured to operate in dual connectivity mode of operation in at least one of a downlink direction and an uplink direction with the MeNB104and SeNB106. In certain embodiments, the wireless communication network system100uses a set of data radio bearers (DRBs) for the UE108that is transmitted over the MeNB104, while another set of data radio bearers (DRBs) for the UE108is transmitted over the SeNB106. When the MeNB104and the SeNB106serve the UE108, the MeNB104handles the control plane of the UE108while the user plane handling of the UE108gets either distributed or split between the MeNB104and the SeNB106.

FIGS. 2A and 2Billustrate protocol architectures for dual connectivity under consideration in 3GPP specification TR 36.842, according to embodiments of the present disclosure. The embodiments of the protocol architectures shown inFIGS. 2A and 2Bare for illustration only. Other embodiments could be used without departing from the scope of the present disclosure.

FIG. 2Aillustrates a core network (CN) split architecture from eNB perspective, according to embodiments of the present disclosure. The S1-U terminates at the MeNB104and the SeNB106. This architecture is referred as core network (CN) split where a set of Evolved Packet System (EPS) bearers of the UE108are split in the core network at the Service-Gateway (S-GW) and the EPS bearers are mapped on the respective S1-U interfaces towards the MeNB104and the SeNB106. The respective EPS bearers are mapped on to corresponding data radio bearers (DRBs) of the MeNB104and the SeNB106.

FIG. 2Billustrates Radio Access Network (RAN) split architecture from eNB perspective, according to embodiments of the present disclosure. The S1-U terminates only at the MeNB104. This architecture is referred as radio access network (RAN) split where the EPS bearer #2 of the UE108is split in the MeNB104and the offloaded bearer is mapped on the X2 interface towards the SeNB106. The layer 2 protocol stack for the data radio bearer associated with the MeNB104(EPS Bearer #1 and Split EPS Bearer #2) and the SeNB106(Offloaded EPS Bearer #2) includes an independent PDCP entity per bearer at the MeNB, an independent Radio Link Control (RLC entity) per bearer at the MeNB104and SeNB106, and a common Medium Access Control (MAC) entity at the MeNB104and an independent MAC entity at the SeNB106. The split/offloaded data radio bearer associated with the MeNB104(EPS Bearer #2) and also associated with the SeNB106can be handled by the PDCP entity associated with MeNB104called the common PDCP entity. Further, the MeNB104includes an RRC protocol for control signaling. The layer 2 protocol stack associated with the MeNB104and SeNB106for handling the data radio bearers associated with the MeNB104and SeNB106, which includes the MAC entity, the RLC entity. The PDCP entity as shown inFIG. 2AandFIG. 2Bis also duplicated at the UE108from the UE perspective and, hence, is not shown explicitly for simplicity.

FIG. 3illustrates an eNodeB (which can be at least one of a MeNB or a SeNB), according to embodiments of the present disclosure. The embodiment of the eNB300shown inFIG. 3is for illustration only. Other embodiments could be used without departing from the scope of the present disclosure. The eNB300shown inFIG. 3can be either the MeNB104or the SeNB106. In certain embodiments, both the MeNB104and the SeNB106are configured the same as, or similar to, the eNB300

The primary blocks present in an eNB300for communication in dual connectivity of the UE108comprise a communication module302, a bearer path management module304, a processor module306, a memory module308, and a key management module310. In certain embodiments, the communication module302is configured to communicate security information with the UE108and other eNBs for establishing a security context. For example, the wireless communication module302in a MeNB104can be configured to communicate the security base keys with one or more UEs108.

The bearer path management module304determines the bearer to be transmitted over within respective cells in the eNBs. The bearer described herein can either be a Data Radio Bearer (DRB) or a Signaling Radio Bearer (SRB). The selection of a bearer can be based on a plurality of variables, which include, but are not limited to, Quality of Service requirements (QoS), traffic characteristics of the bearer, load and coverage area of a selected secondary cell and so forth.

The key management module310is configured to derive or receive keys, or both, from a plurality of entities. In certain embodiments, the key management module310is configured to generate further security keys based on a received key. The MeNB104receives a base security key from the MME102and derives a security base key for SeNB106. Similarly, the SeNB106uses the security key received from the MeNB104to derive new security key to be used for secure communication with the UE108. The derived security base key for the SeNB106can be sent from the MeNB104through the X2 interface using an X2 message.

Further, in certain embodiments, the memory module308is configured to store data related to operation of the eNBs, such as operations of one or both of MeNB104and SeNB106, and the UE108. The memory module308can be configured to store various security keys generated for communication with different entities.

FIG. 4illustrates a UE configured to operate in dual connectivity mode, according to embodiments of the present disclosure. However, UEs come in a wide variety of configurations, andFIG. 4does not limit the scope of this disclosure to any particular implementation of a UE.

The primary blocks present in the UE108for communication in dual connectivity include a communication module402, a bearer path management module404, a processor module406, a memory module408, and a key management module410. In certain embodiments, the communication module402is configured to communicate security information with the eNBs, such as MeNB104, a SeNB106, or both, for establishing a security context. For example, the wireless communication module402in a UE108can be configured to communicate protected user plane packets with one or more eNBs. In certain embodiments, the wireless communication module402in a UE108is able to communicate simultaneously with one or more eNBs.

The bearer path management module404determines the bearer to be transmitted over within respective cells in the eNBs. The bearer described herein can either be a Data Radio Bearer (DRB) or a Signaling Radio Bearer (SRB). The selection of a bearer can be based on a plurality of variables, which include, but are not limited to, Quality of Service requirements (QoS), traffic characteristics of the bearer, load and coverage area of a selected secondary cell and so on.

The key management module410is configured to derive keys for a plurality of entities such as the eNBs and MME.

Further, the memory module408is configured to store data related to operation of the eNBs, such as MeNB104and SeNB106, and the UE108. The memory module408can be configured to store various security keys generated for communication with different entities, as received by the key management module410.

Embodiments of the present disclosure provide a system and method to establish security context for inter-eNB carrier aggregation. Specifically, certain embodiments provide a system and method for key separation and security handling between MeNB and SeNBs. The SeNB106can include a key refresh flag in the SeNB release request message towards the MeNB. In certain embodiments, the SeNB106initiates a key refresh request message towards MeNB for refreshing KeNB_s key (based on events such as PDCP wrap around, cryptographic algorithm to be changes, primary secondary Cell (pSCell) to be changed and like so). Also, in certain embodiments, the UE108initiates a key refresh request message towards MeNB for refreshing KeNB_s key. Consequently, the MeNB can indicate to the UE108the cell specific physical cell identity (PCI) and downlink frequency (EARFCN-DL) to be used as input parameter in key derivation function (KDF) when more than one SCell is added during SeNB addition procedure and PCI and EARFCN-DL is used as the input parameters. In certain embodiments herein, a security context establishment is enabled between the SeNB106and the UE108using the RRC signaling between the UE108and the MeNB104. In certain embodiments, assistance information is provided over the X2 interface in the form of cell list and the associated RRM measurement (RSRP/RSRQ measurements) meets the threshold criteria for qualifying to be potential pSCell within the SCG; and assistance information is provided over the X2 interface in the form of cell list and the associated physical resource availability meets the criteria for qualifying to be potential pSCell within the SCG.

Certain embodiments of the present disclosure provide a system and method for intruder detection in dual connectivity mode of operation of user equipment. Certain embodiments of the present disclosure provide a mechanism for intruder detection for user plane traffic bearer of a User Equipment (UE) in an inter-eNB carrier aggregation scenario. The method includes providing assistance information over the X2 interface related to DRB-ID and PDCP COUNT associated with DRB handled by the SeNB106for both uplink and downlink DRBs, can include flagging DRB-IDs in countercheck request message either by MCG or SCG indication depending on node handling the corresponding DRB.

Certain embodiments of the present disclosure disclose the MeNB initiating the countercheck procedure for the DRB established in the MeNB and further; it can also include the DRBs established in the SeNB106.

Countercheck procedure can be supported for dual connectivity (for both RAN Split architecture and CN Split) with the MeNB initiating the procedure and verifying the result, the SeNB106initiating the procedure and verifying the result, or the SeNB106initiating the procedure and the MeNB verifying the result. From the above, the SeNB106initiating the procedure and the MeNB verifying the result can be a preferred procedure, since SeNB is handling the PDCP entity and the MeNB needs to be the decision making entity.

For initial SeNB addition procedure, the SeNB key derivation is based on current MeNB key in use (KeNB_m). The process, as depicted herein uses a SeNB Counter Count (S-Count or SCC) to ensure that SeNB key repetition does not occur. The specific parameters of the reference cell (pSCell) from the group of SCell (SCG cells) handled by the SeNB106also can be used in the SeNB key derivation.

The UE108sends the measurement report to the MeNB104. The SeNB106also sends the resource status update to the MeNB104using the X2 interface. The resource status update includes the load information, radio problem and so forth. Based on information received from the UE108and the SeNB106, the MeNB104selects the reference cell (pSCell). The MeNB104sends a SCellCommand to the SeNB106, wherein the SCellCommand includes the ID of the selected pSCell to add or release, restrictions (if any) associated with the pSCell and so forth. The SeNB106sends a SCellConfig message to the MeNB104upon receiving the SCellCommand, wherein the SCellConfig includes an ScellToAddModList, security algorithm and so forth. The MeNB104sends an RRCConnectionReconfiguration message to the UE108, wherein the RRCConnectionReconfiguration message includes a security configuration for the selected pSCell. In response to the RRCConnectionReconfiguration message, the UE108sends a response to the MeNB104in the form of an RRCConnectionReconfigurationComplete message. The MeNB104also sends a RACH (Random Access Channel) message to both the UE108and the SeNB106. The MeNB104and the UE108generate a fresh SeNB key-chain (S-Count) thatincrements the S-Count. The MeNB104further sends a SCellConfigACK message to the SeNB106, wherein the SCellConfigACK message includes an SeNB-Kenb (KeNB_S). In response, the SeNB106sends a SCellCommandAck response to the MeNB104.

The counter as disclosed herein is a special case of a nonce. A Nonce and Counter (S-Count or SCC) have been used interchangeably herein. The counter is incremented for every SeNB addition and in case of nonce, a new nonce is pseudo randomly generated for every SeNB addition.

The key derived for the SeNB106is applicable for all user plane traffic handled by all the SCells added in the SeNB106. The terms MeNB key and MCG key and the terms SeNB key and SCG key have been used interchangeably herein.

Embodiments herein disclose a mechanism to retain old key in the SeNB106or refresh the new key in the SeNB106, when KeNB_m is refreshed either due to change in the MeNB104or PDCP count of any PDCP entity in the MeNB104is about to wrap around.

Embodiments herein disclose a mechanism to avoid KeNB_s key change when multiple SCells are configured for the UE108and the special SCell for a particular UE108is changed.

FIG. 5illustrates an exemplary process of deriving KeNB_s* using pSCell parameters that are decided by the SeNB106according to embodiments of the present disclosure.

When multiple SCells are added simultaneously, the pSCell is the one on which the UE108performs random access. Upon deciding the pSCell, the SeNB106sends a SeNB Key request message to the MeNB104on the X2 interface providing the pSCell or the cell specific parameters. The MeNB104generates the KeNB_s* based on the indicated pSCell or cell specific parameters. The KeNB_s* is provided to the SeNB106in SeNB key response message.

Upon the MeNB104deciding to add a SeNB106502, the MeNB104sends a SeNB add request504to SeNB106, wherein multiple SCells can be added based on the add request. The SeNB106sends a SeNB Add Response508message indicating the decided pSCell506from the plurality of added SCells, in response to the add request504. Upon receiving the response message508, the MeNB104stops LCH_s510. The LCH_S or LCH_s is associated with the logical channel between the UE108and the SeNB106. The LCH_S or LCH_s corresponds to the SCG bearers. The MeNB104sends a SeNB Add Acknowledgement511to SeNB106. The MeNB104then sends a RRCConnectionReconfiguration message512to the UE, wherein the RRCConnectionReconfiguration message indicates that a new SeNB106has been added, multiple SCells have been added, the necessary parameters required for the key derivation (SCC), the pSCell and so on. Upon receiving the RRCConnectionReconfiguration message512, the UE108stops the LCH_s514and sends a RRCConnectionReconfigurationComplete message516to the MeNB104. In parallel, the MeNB104sends a SN Status message518to the SeNB106. The MeNB104also starts forwarding data520to the SeNB106. The UE108generates KeNB_s522, based on parameters related to the PSCell, as communicated by the MeNB104. The UE108performs random access524on one of the SCells from the plurality of added SCells, wherein the Scell on which the UE performs the random access procedure524is the PSCell indicated in the RRCConnectionReconfiguration message512from the MeNB104. The UE108further starts LCH_s526for the added SCells. The MeNB104generates KeNB_s*, based on parameters related to the pSCell. The MeNB104then sends a SeNB Key (KeNB_s*) to the SeNB106in the SCG Add Acknowledgement message. Using KeNB_s* as KeNB_s528, the SeNB106starts LCH_s530. Also, the UE108and the MeNB104consider KeNB_M as k1 and k1 is applied for LCH_M532. The LCH_M or LCH_m can be associated with the logical channel between the UE and the MeNB. The LCH_M or LCH_m corresponds to the MCG bearers. Also, the UE108and the SeNB106consider KeNB_S as k2 and k2 is applied for LCH_S534. The MeNB104shares the PDCP (Packet Data Convergence Protocol) status report536with the SeNB106and the UE108. The UE108and the SeNB106start using the new KeNB_s540to derive further keys, which can be used for protecting the user plane traffic of all SCells.

In certain embodiments, a method deriving the KeNB_s key independent of cell specific parameters is disclosed. According to this embodiment, the key derivation function independent of the cell specific parameters comprises: KeNB_s*=KDF{KeNB_m (in use), Random Seed, KeNB_s, <other possible parameters>} where the random seed could be a Nonce or/and a counter or/and PDCP COUNT of the PDCP entity handling the signaling bearer (SRB0 or SRB1) in the MeNB104, which initiates the Key change in the UE108. Here the KeNB_s* is derived not using any cell specific parameter. In the above key derivation function, other than Random seed and KeNB_m, all other parameters are optional.

If the Key derivation function (KDF) does not include PCI and EAFRCN-DL, which are cell specific parameters (but a random parameter like “Nonce or Counter or PDCP COUNT, or a combination thereof,” and so on), even then if more than one SCell is added simultaneously, there would be no security issue in deriving cryptographically separate keys.

In certain embodiments, one of the <other possible parameters> mentioned in the key derivation function can be eNB ID of the SeNB106broadcasted in the SIB1 signaling message for KeNB_S* derivation. The eNB ID is already included in SIB1. The general understanding is that the 20 MSB of this 28 bit field identify the eNB.

In LTE up to Rel-11, upon every handover (HO) and re-establishment, the UE108derives new access stratum (AS) keys, such as KeNB, K_RRCint, K_RRCenc and K_UPenc. It is reasonable to assume the SeNB keys need to be updated whenever the MeNB key changes. Therefore the SeNB keys need to be updated upon MeNB key change, but whether this would result in SCG release and addition need to be considered. Given that MeNB104handover (HO) may be time critical, it may actually be preferable to release the SCG upon MeNB HO and re-establish it after HO completion. In certain embodiments, the release of SCG and subsequent addition would be similar to the user plane procedures during HO but restricted to SCG bearers, namely MAC entity handling the SCG is reset, PDCP entity is re-established and RLC entity is re-established.

In certain embodiments of the present disclosure, the SCG release and subsequent addition is a simple approach applicable for both SCG key refresh and MeNB key change due to MeNB handover (HO) or due to wrap around of the PDCP count of any PDCP entity handling the DRB in the MeNB104or in SeNB106.

FIG. 6illustrates an exemplary process of deriving KeNB_s* using pSCell parameters, wherein the MeNB decides the PSCell, according to embodiments of the present disclosure.

When multiple SCells are added simultaneously, the pSCell is the one on which the UE108performs random access. The MeNB104generates the KeNB_s* based on the decided pSCell or cell specific parameters.

When the MeNB104decides602to add a SeNB106, the MeNB104decides the PSCell and derives the KeNB_s*. The MeNB104sends a SeNB add request604to SeNB106, wherein the add request can comprise of multiple SCells to be added, the decided PSCell and the derived KeNB_s*. The SeNB106sends a SeNB Add Response message606, in response to the add request. Upon receiving the response message606, the MeNB104stops LCH_s608. The MeNB104then sends a RRCConnectionReconfiguration message612to the UE, wherein the RRCConnectionReconfiguration message612indicates that a new SeNB106has been added, multiple SCells have been added and so forth. upon receiving the RRCConnectionReconfiguration message612, the UE108stops the LCH_s614. The UE108generates KeNB_s616, based on parameters related to the pSCell, as communicated by the MeNB104and sends a RRCConnectionReconfigurationComplete message618to the MeNB104. In parallel, the MeNB104sends a SN Status message620to the SeNB106, wherein the SeNB106includes the count. The MeNB104also starts forwarding data622to the SeNB106. The UE108performs random access624on one of the SCell from the plurality of added SCells, wherein the Scell on which the UE performs the random access procedure is the pSCell indicated in the RRCConnectionReconfiguration message618from the MeNB104. The UE108further starts LCH_s625for the added SCells. Using KeNB_s* as KeNB_s626, the SeNB106starts LCH_S628. Also, the UE108and the MeNB104consider KeNB_M as k1 and k1 is applied630for LCH_M. Also, the UE108and the SeNB106consider KeNB_S as k2 and k2 is applied632for LCH_S. The MeNB104shares the PDCP (Packet Data Convergence Protocol) status report634with the SeNB106and the UE108. The UE108and the SeNB106start using the new KeNB_s636for the user plane traffic of all SCells.

FIG. 7illustrates an exemplary process of MeNB initiated SCG release and subsequent addition of the SCG for SeNB key refresh due to wrap around of PDCP count of any PDCP entity handling the DRB in the SeNB, according to embodiments of the present disclosure.

The SCG release and subsequent addition of the same SCG, namely SCG release and addition procedure, means, the user plane protocol stack associated with the SeNB106is reset and reestablished702in the UE108and in the SeNB106. The SeNB106sends a Resource Status Update (X2-AP status update) message704to the MeNB104, wherein the Resource Status Update comprises of PDCP SN wrap-around status. In an embodiment, the X2-AP status update message704is a SeNB106modification required message with SCG Change Indication having a cause value as PDCP Count Wrap Around. Upon receiving the SeNB modification required message, the MeNB104derives a new KeNB_s*706. The MeNB104sends a SCell Command message (X2-AP message708, for example, SeNB modification request) comprising of the new KeNB_s* to the SeNB106. The MeNB104further sends the RRCConnectionReconfiguration message710to the UE108. The MeNB104includes the necessary parameters (SCC) in the RRCConnectionReconfiguration for the UE108to update the KeNB_s. Upon receiving this message, the UE108updates (derives) the key KeNB_s and sends the RRCConnectionReconfigurationComplete message712to the MeNB104. The UE108releases714the active key KeNB_s and re-establishes a layer 2 protocol stack. To re-establish a layer 2 protocol stack means, the UE108resets the MAC layer associated with the SeNB106and re-establishes the PDCP and the RLC entities associated with the SeNB106for each DRB established between the UE108and the SeNB106. The SeNB106also releases716the old KeNB_s key. MeNB104then sends the SCellConfigAck718to the SeNB106and receives a SCellCommandAck719from the SeNB106. Then the UE108performs random access720on one of the SCell from the plurality of added SCells, wherein the Scell on which the UE performs the random access720procedure is the pSCell indicated in the RRCConnectionReconfiguration message710from the MeNB. The SeNB106further uses the KeNB_s*722, as received from the MeNB104as the KeNB_s. The UE108and the SeNB106start using724the new key derived from the updated (new) KeNB_s for the user plane traffic protection of all SCells.

If there is a requirement, trigger, or event to change the SCG security algorithm to the existing DRB between the UE108and the SeNB106, then it would be reasonable to support it only by means of SCG release and addition procedure. In certain embodiments, the SeNB106sends a SeNB modification required message to the MeNB104and with SCG Change Indication having a cause value as security algorithm change (or the cause value can be as “others”). In certain embodiments, the SeNB modification required message carry the selected security algorithm. It should be noted that, based on the cause, indication, or information from the SeNB (for example, in the SeNB modification required message), the MeNB does not initiate the user plane path switch procedure with the EPC, but initiates the key change procedure with algorithm change by means of SCG release and addition procedure.

FIG. 8illustrates an exemplary process of SeNB key refresh on the SeNB deciding to change the PSCell, according to embodiments of the present disclosure.

The user plane protocol stack associated with the SeNB106is reset and reestablished802in the UE108and in the SeNB106. The UE108sends measurement report804to the MeNB104, for different frequencies, which have been configured on the UE108. The MeNB104sends a SeNB modification request message (X2-AP)806to the SeNB106, wherein the SeNB modification message806can include RRM measurements. Based upon the SeNB modification request message806, the SeNB106decides to change the PSCell810and decides on an appropriate PSCell. Upon deciding to change the PSCell, the SeNB106sends a SeNB modification response message812to the MeNB104, wherein the SeNB modification response message includes the new PSCell or cause, indication, or information, or a combination thereof, that it is for pSCell change, as determined by the SeNB106. The MeNB104derives814a new KeNB_s* and sends a SeNB modification acknowledge message816, including the derived KeNB_s*, to the SeNB106. The MeNB104further sends the RRCConnectionReconfiguration message818to the UE108. Upon receiving this message, the UE108sends the RRCConnectionReconfigurationComplete message820to the MeNB104. The MeNB includes the necessary parameters (SCC) in the RRCConnectionReconfiguration required for the UE to update the KeNB_s. The UE108derives the new KeNB_s and releases821the old key and re-establishes a layer 2 protocol stack. The SeNB106also releases822the old key. The MeNB104then sends the SCellConfigAck824to the SeNB106and receives a SCellCommandAck826from the SeNB106. Then the UE108performs random access828on one of the SCell from the plurality of added SCells, wherein the Scell on which the UE performs the random access828procedure is the pSCell indicated in the RRCConnectionReconfiguration message from the MeNB. The SeNB106further uses the KeNB_s*830, as received from the MeNB104as the KeNB_s to derive further keys. The UE108and the SeNB106start using832the newly derived key from the updated KeNB_s for securing the user plane traffic of all SCells.

FIG. 9illustrates an exemplary process of SCG release and addition procedure, when MeNB key is changed, according to embodiments of the present disclosure.

The user plane protocol stack associated with the SeNB106is reset and reestablished902in the UE108and in the SeNB106. When the MeNB104decides to refresh904the KeNB, the MeNB104updates906the KeNB_m and derives the new KeNB_s*. The MeNB104sends a SeNB modify message908(comprising of the derived KeNB_s*) to the SeNB106. The MeNB104further sends the RRCConnectionReconfiguration message910to the UE108. The MeNB includes the necessary parameters (SCC) in the RRCConnectionReconfiguration message910for the UE to update the KeNB_s. Upon receiving RRCConnectionReconfiguration message910, the UE108sends the RRCConnectionReconfigurationComplete message912to the MeNB104. The UE108performs the key refresh procedure (updates the KeNB_M) and then the UE108derives the new KeNB_s and releases914the old key and re-establishes a layer 2 protocol stack. The SeNB106also releases915the old key. MeNB104then sends the SCellConfigAck916to the SeNB106and receives a SCellCommandAck917from the SeNB106. Then the UE108performs random access918on one of the SCell from the plurality of added SCells, wherein the Scell on which the UE performs the random access918procedure is the pSCell indicated in the RRCConnectionReconfiguration message910from the MeNB. The SeNB106further uses the KeNB_s*920, as received from the MeNB104as the KeNB_s to derive further keys. The UE108and the SeNB106start using922the newly derived key from the updated KeNB_s for securing the user plane traffic of all SCells.

FIG. 10illustrates process of SeNB initiating the countercheck procedure for SCG bearer and MeNB verifying the result, according to embodiments of the present disclosure.

Data bearer1001handled by MeNB104in dual connectivity is established between UE108and MeNB104. Data bearer1002handled by SeNB106in dual connectivity is established between UE108and SeNB106. The SeNB106initiates countercheck1003towards the UE108for SCG bearers over the X2 interface. The trigger for the SeNB106to initiate the countercheck1003procedure can be periodical, wherein a periodical countercheck1003procedure occurs at regular time intervals. The trigger for the SeNB106to initiate the countercheck1003procedure can be event based, such as if there is sudden surge in volume of data. The trigger for the SeNB106to initiate the countercheck1003procedure can be when considered necessary (similar to other SCG bearers). The trigger for the SeNB106to initiate the countercheck1003procedure can be to check volume of data transfer. If the countercheck procedure is triggered, the SeNB106sends the contents (like PDCP count values and/or DRB IDs) in a counter check message1004to the MeNB104over the X2 interface. The SeNB106can also indicate to the MeNB104the current UL/DL PDCP COUNT status of the DRB and the associated DRB-ID (outside the RRC container). The SeNB106can also indicate an expected (PDCP sequence number) SN rate in coming seconds (again outside the RRC container) and so on. The MeNB104executes1006the RRC procedure towards the UE108and stores the information received from the SeNB106for verification. The UE108may verify the result based on the information received. The UE108compares the PDCP COUNT values received in the Countercheck message with the values of its radio bearers. The UE108may include different UE PDCP COUNT values for all the established DRBs (MCG DRB as well as SCG DRB) within the Countercheck Response message, if the value received and its current PDCP values are not matching (may be within acceptable window size). When the MeNB104receives the response1008from the UE108, the MeNB104performs the countercheck1010based on the information provided by the SeNB106. If the MeNB104receives a response message1008from the UE108that does not contain any PDCP COUNT values, then the MeNB104considers the countercheck as passed. If the countercheck is passed, then there is no intrusion detected1011. That is, if the MeNB104determines1012that the count is not in range, an intruder attack is detected on the MCG bearer1014or an intruder attack is detected on the SCB bearer1016. If the MeNB104receives a response that contains one or several PDCP COUNT values from the UE, then the MeNB104considers the countercheck as not passed (the UE can include the PDCP COUNT which are different compared to the values received from the MeNB). If the countercheck is not passed, then there is an intrusion detected. Then, the MeNB104alerts the SeNB106and takes appropriate action like initiating request for releasing the SCG1018, releasing the UE1020and so forth.

FIG. 11illustrates process of MeNB104initiating the countercheck procedure for SCG bearer and verifying the result, according to embodiments of the present disclosure.

Data bearer1101handled by MeNB104in dual connectivity is established between UE108and MeNB104. Data bearer1102handled by SeNB106in dual connectivity is established between UE108and SeNB106. The MeNB104initiates the countercheck procedure1103towards the UE108for SCG bearers. The trigger for the MeNB104to initiate the countercheck procedure can be periodically, wherein a periodical check procedure occurs at regular time intervals. The trigger for the MeNB104to initiate the countercheck procedure can be event based such as if there is sudden surge in volume of data. The trigger for the MeNB104to initiate the countercheck procedure can be when considered necessary similar to other MCG bearers. The trigger for the MeNB104to initiate the countercheck procedure can be to check volume of data transfer. If the countercheck procedure is triggered, the MeNB104requests1106the SeNB106for counter information for SCG bearer and the associated DRB-ID over the X2 interface of that UE108. The SeNB106provides1108the current UL/DL sequence number (SN) status and the DRB-ID of the DRBs of that UE108in X2 message sent in response. Further, the MeNB104executes countercheck procedure1110towards the UE108and may be flagging the DRB-ID with MCG or SCG indication. The indication can be at least one of the following: a bit indication for the corresponding DRB-ID, a distinguished list of DRB-IDs of the MCG and SCG, PCI indication for the corresponding DRB-ID, PCI and EARFCN-DL for the corresponding DRB-ID, Global cell ID, Cell Global identifier and so on. The UE108compares the PDCP COUNT values received in the Countercheck message with the values of its radio bearers. The UE108may include different UE PDCP COUNT values for all the established DRBs (MCG DRB as well as SCG DRB) and may be flagging the DRB-ID with MCG or SCG indication within the Countercheck Response message1112. When the MeNB104receives the Countercheck Response message1112from the UE108, the MeNB104performs the countercheck1113based on the information provided by the SeNB106. If the MeNB104receives a countercheck response message1112that does not contain any PDCP COUNT values, then the countercheck is passed1115. That is, if the MeNB104determines1114that the count is not in range, an intruder attack is detected on the MCG bearer1116or an intruder attack is detected on the SCB bearer1118. If the countercheck is passed, then there is no intrusion detected. If the MeNB104receives a countercheck response that contains one or several PDCP COUNT values, then the countercheck is not passed (the UE include the PDCP COUNT which are different compared to the values received from the MeNB). If the countercheck is not passed, then there is an intrusion detected. The MeNB104alerts1120the SeNB106, if the mismatched PDCP COUNT of the DRB belongs to SCG and MeNB104takes appropriate action such as releasing the SCG, reporting to the Core Network entities to take appropriate action, releasing the UE1122, and so forth.

Here, the MeNB104is in full control of handling the countercheck procedure since initiation and termination of the procedure is under MeNB104control. For Split bearers (RAN Split architecture as depicted inFIG. 2B) it can be assumed that the SeNB106applies the same DRB identity (DRB-ID) for split bearers as used by the MeNB104i.e. the MeNB104decides the identity for Split bearer. This can be applicable to SCG DRBs also where the MeNB104controls the entire procedure.

In certain embodiments, the UE108verifies and provides its counter values to the MeNB104over the RRC signaling for the MeNB or SeNB to verify and act.

In certain embodiments, the UE108verifies the count values received in countercheck request message and if the countercheck fails (the UE108itself detects intrusion attack), then the UE108sends the modified countercheck response message to the MeNB104that it has detected intrusion attack for SCG bearer. The MeNB104decides the release of the SCG and/or SCG bearer for which intrusion is detected.

In another embodiment, upon detecting intrusion attack, the UE108sends the modified countercheck response message to the MeNB104that it has detected intrusion attack for the SCG bearer and informs the MeNB104that the UE108is releasing the SCG bearer. After sending the countercheck response message, the UE108autonomously takes the decision to release the SCG bearer.

FIG. 12illustrates process of SeNB initiating the countercheck procedure for SCG bearer and verifying the result, according to embodiments of the present disclosure.

Data bearer1201handled by MeNB104in dual connectivity is established between UE108and MeNB104. Data bearer1202handled by SeNB106in dual connectivity is established between UE108and SeNB106. The SeNB106initiates the countercheck1204towards the UE108for SCG bearers over the X2 interface. The trigger for the SeNB106to initiate the countercheck procedure can be at periodical, wherein a periodical check procedure occurs at regular time intervals. The trigger for the SeNB106to initiate the countercheck procedure can be event based such as if there is sudden surge in volume of data. The trigger for the SeNB106to initiate the countercheck procedure can be when considered necessary similar to other SCG bearers. The trigger for the SeNB106to initiate the countercheck procedure can be to check volume of data transfer. If the countercheck procedure is triggered, the SeNB106sends the contents (PDCP Count) in a countercheck message1206to the MeNB104over the X2 interface. The MeNB104transparently executes1208an RRC procedure to the UE108by forwarding the countercheck message received from the SeNB106to the UE108. The UE108verifies the result based on the information received. The UE108compares the PDCP COUNT values received in the Countercheck message with the values of its radio bearers. The UE108may include different UE PDCP COUNT values for all the established DRBs (MCG DRB as well as SCG DRB) within the Countercheck Response message1210. MeNB verifies1211a result based on the Countercheck Response message1210for the MCG bearers. When the MeNB104receives the Countercheck Response message1210from the UE, the MeNB104forwards1212the response message on X2 interface to the SeNB106in a transparent manner. The SeNB106verifies1214the result based on the information forwarded by the MeNB104. If the SeNB106receives a countercheck response message that does not contain any PDCP COUNT values, then the SeNB106considers the countercheck as passed. If the countercheck is passed, then there is no intrusion detected1216. If the SeNB106receives a countercheck response that contains one or several PDCP COUNT values, then the SeNB106considers the countercheck as not passed (the UE include the PDCP COUNT which are different compared to the values received from the MeNB). If the countercheck is not passed, then there is an intrusion detected1218. Then, if the mismatched PDCP COUNT of the DRB belongs to SCG, the SeNB106takes appropriate action like initiating request for releasing the SCG1220, report to the Core Network entities via the MeNB to take appropriate action and so on.

The countercheck procedures can be used interchangeably, two or more countercheck procedures can be merged, or a combination of merging and interchanging of procedures can be used as required.