User plane integrity protection configuration in EN-DC

Abstract

Systems and methods provide Packet Data Convergence Protocol (PDCP) User Plane (UP) integrity protection (IP) for user equipment (UE) and radio access network (RAN) nodes operating in Evolved Universal Terrestrial Radio Access-New Air Dual Connectivity (EN-DC). During an attach procedure, a UE may indicate UE security capabilities for supporting relay node (RN) PDCP UP IP used in LTE. Based on the UE security capabilities, primary e Node B (MeNB) security capabilities, and secondary g Node B (SgNB) security capabilities, the MeNB may determine whether to use UP IP in a split bearer between the UE and the MeNB, between the UE and the SgNB, and / or between the MeNB and the SgNB.

Description

Technical Field

[0001] This patent application generally relates to wireless communication systems, including integrity protection of user plane communication traffic. Background Art

[0002] Wireless mobile communication technologies use various standards and protocols to transfer data between a base station and a wireless mobile device. Wireless communication system standards and protocols may include the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly referred to by industry organizations as Worldwide Interoperability for Microwave Access (WiMAX); and the IEEE 802.11 standard for Wireless Local Area Networks (WLAN), which is commonly referred to by industry organizations as Wi-Fi. In the 3GPP Radio Access Network (RAN) of an LTE system, a base station may include RAN nodes such as evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) and / or a Radio Network Controller (RNC) in the E-UTRAN, which communicates with a wireless communication device known as User Equipment (UE). In a fifth-generation (5G) wireless RAN, the RAN nodes may include 5G nodes, NR nodes (also referred to as next-generation Node B or g Node B (gNB)).

[0003] The RAN uses Radio Access Technology (RAT) to communicate between RAN nodes and the UE. The RAN may include Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and / or E-UTRAN, which provides access to communication services through a core network. Each RAN in the RAN operates according to a specific 3GPP RAT. For example, GERAN implements GSM and / or EDGE RAT, UTRAN implements Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RAT, E-UTRAN implements LTE RAT, and NG-RAN implements 5G RAT. In some deployments, the E-UTRAN may also implement 5G RAT.

[0004] The various embodiments are described in terms of the UE. However, the reference to the UE is provided for illustrative purposes only. The exemplary embodiments may be used with any electronic component that can establish a connection with a network and is configured with hardware, software, and / or firmware for exchanging information and data with the network. Thus, the UE as described herein is used to represent any suitable electronic component. Brief Description of the Drawings

[0005] To easily identify the discussion of any particular element or action, one or more of the most significant digits in the reference numerals refer to the figure number in which the element was first introduced.

[0006] Figure 1A and Figure 1B is a block diagram showing the EN-DC architecture used in some embodiments.

[0007] Figure 2 is a block diagram of the radio protocol architecture of the user plane of EN-DC used in some embodiments.

[0008] Figure 3 is a block diagram of the radio protocol architecture of the MCG, SCG, and split bearers in the user plane of EN-DC from the perspective of the secondary UE in some embodiments.

[0009] Figure 4 is a signaling diagram showing a simplified attachment process of the RN that can be modified according to some embodiments.

[0010] Figure 5 is a signaling diagram showing the attachment process of the RN with security established in LTE and modified herein to configure LTE PDCP IP to the UE.

[0011] Figure 6A and Figure 6B is a block diagram showing a simplified EN-DC architecture according to some embodiments.

[0012] Figure 7 is a signaling diagram showing the RN PDCP UP IP configuration process, where the attachment process shown is modified according to one embodiment Figure 5 as shown.

[0013] Figure 8 is a signaling diagram of the SgNB addition process that can be used with some embodiments herein to configure the UP IP for EN-DC operation.

[0014] Figure 9 is a signaling diagram of the UP IP activation process according to some embodiments.

[0015] Figure 10 is a block diagram showing the potential UPIP decision for the Figure 6A and Figure 6B simplified EN-DC architecture shown according to one embodiment.

[0016] Figure 11 is a flowchart of a method for configuring the MeNB to configure the UP IP for a UE supporting EN-DC according to some embodiments.

[0017] Figure 12 is a flowchart of a method for a UE according to certain embodiments.

[0018] Figure 13 is a flowchart of a method for an MME according to certain embodiments.

[0019] Figure 14 illustrates an infrastructure equipment according to one embodiment.

[0020] Figure 15 illustrates a platform according to one embodiment.

[0021] Figure 16 illustrates a component according to one embodiment. Detailed Description

[0022] LTE and NR networks can be implemented in many combinations. For example, see 3GPP TR 38.801 (clause 7.2). The first option may include evolved Universal Terrestrial Radio Access (eUTRA) with an Evolved Packet Core (EPC), the second option may include stand-alone NR with a 5G Core, the third option may include an EPC-based dual connection of eUTRA and NR RAT (also known as eUTRA-NR dual connection or EN-DC), the fourth option may include a dual connection based on a 5G Core (NR primary - eUTRA secondary), the fifth option may include a 5G Core with eUTRA, and the sixth option may include a dual connection based on a 5G Core (eUTRA primary - NR secondary). Certain embodiments herein relate to EPC-based options, such as the first option (eUTRA with EPC) and the third option (EN-DC). While option 1 is pure LTE (i.e., does not use NR), the EN-DC in option 3 is a combination of LTE and NR, which may initially be widely deployed as a 4G to 5G interworking solution giving a migration path to a stand-alone 5G network.

[0023] User Plane (UP) integrity protection is an enhancement in 5G, which is valuable for, for example, desired Internet of Things (IoT) services. The Packet Data Convergence Protocol (PDCP) layer is in the radio protocol stack in the UMTS / LTE / 5G air interface on top of the Radio Link Control (RLC) layer. PDCP provides its services to the Radio Resource Control (RRC) and the upper layers of the user plane. One of the services provided by PDCP is integrity protection (IP). However, as discussed below, UP IP is not currently used in EN-DC.

[0024] EN-DC uses the existing LTE and EPC infrastructure, enabling new 5G-based radio technologies to be available without network replacement. EN-DC uses LTE as the primary radio access technology, while the new radio access technology is used as the secondary radio access technology, where the UE is connected to two radio components. In addition to capability negotiation, the security process for EN-DC basically follows the specifications of 4G dual-connectivity security. The master eNB (MeNB) checks whether the UE has the 5G NR capability to access the secondary gNB (SgNB) and the access permission to the SgNB. The capability and access permission checks are to verify that the standard is forward-compatible, as UEs with different capabilities (including security capabilities) can join the network. The MeNB derives and sends the key that will be used by the SgNB for secure communication via NR. The UE also derives the same key. Different from dual-connectivity in the 4G network, RRC messages can be exchanged between the UE and the SgNB. Therefore, keys for the integrity and confidentiality protection of RRC messages and UP data are derived.

[0025] Although integrity protection for UP data is supported in the 5G network, since it is not required to support UPIP in LTE PDCP, this integrity protection is not currently used in the case of EN-DC. From 3GPP Release 15 (R15) forward, the UE can support both NR PDCP and LTE PDCP, as well as NR PDCP UP IP. However, there is currently no requirement for the UE to support LTE PDCP UP IP. For RAN nodes, the gNB will support NR PDCP UP IP from R15 forward, and the eNB can support LTE PDCP UP IP with relay nodes for LTE. However, there is currently no requirement for LTE PDCP UP IP between the eNB and the UE. In addition, in EN-DC, the eNB can support NR PDCP, but currently does not support UP IP for NR PDCP.

[0026] Therefore, some embodiments of this document provide PDCP UP IP for UEs and RAN nodes operating in EN-DC. During the attachment process, the UE can indicate the UE security capability for supporting RN PDCP UP IP used in LTE. Based on the indication, for the purpose of using RN PDCP between the UE and the MeNB, the MeNB can act as the donor eNB (DeNB) and the UE can act as the RN. Therefore, based on the UE security capability, the MeNB security capability, and the SgNB security capability, the MeNB can determine whether to use UP IP in the split bearers between the UE and the MeNB, between the UE and the SgNB, and / or between the MeNB and the SgNB.

[0027] As an example, Figure 1A andFigure 1B is a block diagram showing the EN-DC architecture used in some embodiments herein. At a high level, the EN-DC architecture includes an EPC 102, an LTE eNB 104, and a gNB 106. The LTE eNB 104 is connected to the EPC via a control plane (CP) S1 interface (S1-C interface) and a user plane (UP) S1 interface (S1-U interface). The LTE eNB 104 is connected to the EPC 102 via a non-standalone NR connection.

[0028] In Figure 1A , the NR UP connection 108 and the NR CP connection 110 are passed from the gNB 106 through the LTE eNB 104 to the EPC 102.

[0029] In Figure 1B , the NR CP connection 110 from the gNB 106 is passed through the LTE eNB 104 to the EPC 102. However, the UP connection from the gNB 106 goes directly from the gNB 106 to the EPC 102 via the S1-U interface.

[0030] As an example, Figure 2 is a block diagram of a radio protocol architecture 200 of a user plane of EN-DC used in some embodiments herein. In a dual connection (DC), the shown LTE eNB 104 can be referred to as the MeNB of a master cell group (MCG), and the shown gNB 106 can be referred to as the SgNB of a secondary cell group (SCG). There are two configurations for DC that can be performed in the LTE eNB 104 (as the MeNB) and the gNB 106 (as the SeNB): a configuration using MCG bearers and SCG bearers, and a configuration using split bearers.

[0031] An MCG bearer is a communication bearer established between the LTE eNB 104 and the EPC (e.g., connected to a serving gateway (S-GW) in the EPC). The MCG bearer corresponds one-to-one to a radio bearer established between the UE and the LTE eNB 104. An SCG bearer is a communication bearer established between the gNB 106 and the EPC (e.g., the same or a different S-GW connected to the LTE eNB 104). When DC is implemented by using MCG bearers and SCG bearers, the SCG bearer corresponds one-to-one to a radio bearer established between the UE and the gNB 106.

[0032] A split bearer is a communication bearer established between an LTE eNB 104 and the EPC (e.g., S-GW). The split bearer can be associated with a radio bearer directly established between the UE and the LTE eNB 104. Additionally, the split bearer can be associated with a radio bearer established between the UE and the LTE eNB 104 via the gNB 106. In other words, via the split bearer, the LTE eNB 104 transmits data transmitted via a radio bearer directly established between the UE and the LTE eNB 104 and data transmitted via a radio bearer established between the UE and the LTE eNB 104 via the gNB 106 to the EPC. The LTE eNB 104 receives data transmitted from the UE to the gNB 106 via Xx (referred to as Xx-U or X2 in some examples), which is a reference point between the LTE eNB 104 and the gNB 106. Communication using the split bearer can be referred to as aggregated communication.

[0033] The LTE eNB 104 includes a protocol stack for the MCG bearer, which includes a PDCP layer (PDCP 202), a radio link control (RLC) layer (RLC 204), and a media access control (MAC) layer (MAC 206). The LTE eNB 104 also includes a protocol stack for the split bearer, which includes PDCP 208, RLC 210, and MAC 206. The gNB 106 also includes a protocol stack for the split bearer, which includes an NR RLC 212 that communicates with the PDCP 208 of the LTE eNB 104 via Xx, and an NR MAC 214. The gNB 106 also includes a protocol stack for the SCG bearer, which includes an NR PDCP 216, an NR RLC 218, and an NR MAC 214. The NR PDCP 216 is one of the NR sub-layers that is used to process the SDU of the S1-U interface into different dedicated radio bearers (DRBs) according to the quality of service (QoS) information associated with the service data unit (SDU).

[0034] As an example, Figure 3FIG. 300 is a block diagram of a radio protocol architecture of MCG, SCG, and split bearers in the user plane from the perspective of the secondary UE 302 in EN-DC used in certain embodiments of the present disclosure. The protocol stack for the MCG bearer includes E-UTRA / NR PDCP 304, E-UTRA RLC 306, and E-UTRA MAC 308. The protocol stack for the split bearer includes NR PDCP 310, E-UTRA RLC 312, and E-UTRA MAC 308. The split bearer protocol stack further includes NR RLC 314 and NR MAC 316. The protocol stack for the SCG bearer includes NR PDCP 318, NR RLC 320, and NR MAC 316. In E-UTRA connected to the EPC, if the UE 302 supports EN-DC, the network may configure the E-UTRA PDCP or NR PDCP for the MCG bearer terminated by the master node (MN) regardless of whether EN-DC is configured, while NR PDCP is used for other bearers. The change from E-UTRA to NR PDCP or vice versa may be performed via a reconfiguration procedure (with or without handover), using the release and addition of DRBs or using the full configuration option.

[0035] As discussed above, since support for UP IP in LTE PDCP is not required, UP IP is currently not supported in stand-alone LTE and / or EN-DC scenarios. To enable IP in EN-DC, the following conditions may be supported in certain embodiments: the UE supports LTE PDCP UP IP; the eNB supports LTE PDCP UP IP; and the UP IP configuration procedure is ready to enable UP IP. However, currently, UP IP is only authorized on the PDCP layer between the relay node (RN) and the eNB, which can be reused between the UE and the eNB. To support EN-DC, according to certain embodiments of the present disclosure, the UE and the eNB may be updated to support the protocol. In certain embodiments of the present disclosure, it is assumed that the UE and the eNB are updated to support the RN PDCP UP IP used in LTE. Such embodiments provide for the configuration of UP IP in EN-DC.

[0036] Figure 4It is a signaling diagram showing a simplified attachment process 400 of RN 402 that can be modified according to certain embodiments. For example, refer to 3GPP TS 36.300. The attachment process 400 may include RRC connection establishment 410, processes 412a and 412b (non-access stratum (NAS) attachment, authentication, security, etc.) between RN 402 and a mobility management entity (MME) (shown as MME 406) and / or between MME 406 and a home subscriber server (shown as HSS 408), GTP-C create session process 414, RRC connection reconfiguration processes 416a and S1 context establishment process 416b (including NAS attachment acceptance message).

[0037] The attachment process 400 may be the same as a normal UE attachment process (e.g., refer to 3GPP TS 23.401), except that the DeNB 404 already knows which MMEs support the RN function via an S1 establishment response message received earlier from the MME; RN 402 sends an RN indication to DeNB 404 during RRC connection establishment; after receiving the RN indication from RN 402, DeNB 404 sends an RN indicator and the Internet protocol address of the SGW / P-GW function embedded in DeNB 404 to the MME 406 that supports the RN function in the initial UE message; MME 406 selects an S-GW / P-GW for RN402 based on the Internet protocol address included in the initial UE message; and during the attachment process, the EPC checks whether RN 402 is authorized for relay operation. If RN402 is authorized, the EPC accepts the attachment and establishes a context with DeNB 404; otherwise, the EPC rejects the attachment. RN 402 is pre-configured with information about which cells (DeNBs) it is allowed to access.

[0038] As described above, LTE PDCP UP IP can be supported between RN 402 and DeNB 404. For example, 3GPP TS33.401, clause 5.1.4.1 indicates that user plane packets carrying S1 and X2 messages between RN 402 and DeNB 404 may be integrity protected. Integrity protection for other user plane packets between RN 402 and DeNB 404 can be supported. According to 3GPP TS 33.401, MME 406 configures integrity security for RN 402 via an S1 initial context establishment message. MME 406 and RN 402 may establish NAS security. When receiving the S1 initial context establishment message, DeNB 404 and RN402 may establish access stratum (AS) security.

[0039] For example, Figure 5It is a signaling diagram showing the attachment process 500 of RN 402 with security established in LTE that can be modified herein to configure LTE PDCP IP to the UE. If needed, after activating the Universal Subscriber Identity Module (USIM-RN) of RN 402 at 502, the attachment process 500 includes an RRC connection establishment process 504, and processes 506a and 506b. Process 506a may include NAS attachment, authentication (Evolved Packet System (EPS) authentication and key agreement (AKA)), and a security process during which "indicate RN" indicates that RN 402 is a relay node. Process 506b may include authentication (checking RN subscription data in HSS 408) and a security process. The attachment process 500 also includes a GTP-C create session process 508. At box 510, NAS security is established. UP IP is established in an RRC connection reconfiguration process 512a and an S1 context establishment process 512b (including a NAS attachment accept message). Then, process 514 in which AS security is established is executed.

[0040] 3GPP TS 33.401, clause D.2.2 provides details of the attachment procedure 500 with security establishment for RN 402. In such an implementation, RN 402 uses USIM-RN to perform the RN attachment procedure for EPS. In addition, the following security-related steps are performed. If the USIM-RN is not yet active, RN 402 activates 502 the USIM-RN and establishes a new security channel respectively based on certificates according to Ec5, Ec6 and based on pre-shared keys according to Ep2. RN 402 uses the international mobile subscriber identity (IMSI) (or related globally unique temporary identity (GUTI)) belonging to the USIM-RN during the RN attachment procedure. In procedure 506a, the S1 initial UE message indicates attachment for the relay node. Upon receiving this message, the MME 406 (MME-RN) runs EPS AKA with RN 402 and USIM-RN. RN 402 only accepts the authentication response and keys received from the USIM-RN via the secure channel during the RN attachment procedure. In procedure 506b, the MME 406 (MME-RN) checks whether the USIM-RN is allowed for the RN attachment procedure according to the RN-specific subscription data received from the HSS 408. When this is not the case, but the S1 initial UE message indicates attachment for the RN, the MME 406 (MME-RN) rejects the attachment request and indicates to the DeNB 404 that the establishment has failed. At box 510, the MME 406 (MME-RN) and RN 402 establish NAS security. When the S1INITIAL CONTEXT SETUP message is received during the S1 context establishment procedure 512b (where the UP IP is established in this step), the DeNB 404 and RN402 establish AS security via Un. RN 402 may establish a secure connection to the operation, administration and maintenance (OAM) server at this stage to complete the configuration.

[0041] Figure 6A and Figure 6B is a block diagram showing a simplified EN-DC architecture according to some embodiments. As discussed above, the UE 602 may be connected to the MeNB 604, which has an MCG bearer connection (UP#1 connection) to the S-GW 606 via the S1-U interface. The UE 602 may also be connected to the en-gNB 608 (which may be referred to herein as the SgNB), which has an SCG bearer connection (UP#2 connection) to the S-GW 606 via the S1-U interface. The MeNB 604 has a split bearer connection (UP#3 connection) to the en-gNB 608 via the X2-U interface. As Figure 6AAs shown, UE 602 supports NR PDCP for communication with en-gNB 608 and may also support NR PDCP with UP IP. However, UE 602 may not support LTE PDCP for communication with MeNB 604. Therefore, UP IP is not currently used in EN-DC scenarios.

[0042] However, in certain embodiments, the RN PDCP is reused in the MeNB 604. In such embodiments, as Figure 6B As shown in FIG. 1 , UE 602 is configured to act as a RN and MeNB 604 is configured to act as a DeNB. Therefore, RN PDCP is supported for communication between UE 602 and MeNB 604, for example, using Figure 5 Attachment process 500 is shown.

[0043] For example, Figure 7 is a signaling diagram illustrating the RN PDCP UP IP configuration process 700, wherein is modified according to one embodiment Figure 5 The attachment process 500 shown. Specifically, Figure 5 RN 402 is shown replaced with UE 702 and Figure 5 The DeNB 404 shown is replaced with the MeNB 704. Therefore, the RN PDCP UP IP configuration process 700 includes an RRC connection establishment process 706 and a process 708a for NAS attachment, authentication and security (but does not indicate that the attachment is for a relay node). Process 708b may include authentication (checking subscription data associated with the UE 702 in the HSS 408) and security procedures. The RN PDCP UP IP configuration process 700 also includes a GTP-C create session process 710. At box 712, NAS security is established. UP IP is established in the RRC connection reconfiguration process 714a and the S1 context establishment process 714b (including the NAS attachment accept message). Then, process 716 is performed in which AS security is established.

[0044] In certain embodiments, the RN PDCP UP IP configuration process includes adding an SgNB for EN-DC operation. For example, Figure 8 is a signaling diagram of an SgNB addition procedure 800 that can be used with certain embodiments herein to configure a UP IP for EN-DC operation. For example, see 3GPP TS 33.401. As discussed above, in current systems, UP IP is not allowed in SgNB 802 because the EPC does not support UPIP. However, as disclosed herein (e.g., see Figure 9 ), UP IP can be configured in SgNB 802 for EN-DC operation.​​

[0045] As shown Figure 8 , UE 702 and MeNB 704 establish an 804 RRC connection. Before MeNB 704 decides to use dual connectivity for a certain (some) DRB and / or signaling radio bearer (SRB) with SgNB 802, MeNB 704 checks whether UE 702 has NR capabilities and is authorized to access NR. MeNB 704 sends an SgNB addition request 806 to SgNB 802 (e.g., via the X2-C interface) to negotiate the available resources, configurations, and algorithms at SgNB 802. When connected to the EPC, in some embodiments herein, MeNB 704 indicates to SgNB 802 that UP integrity protection can be activated. If a new key is needed, MeNB 704 calculates the key (S-K gNB ) and delivers it to SgNB 802. The UE NR security capabilities can also be sent to SgNB 802.

[0046] In block 808, if an SRB that has the highest priority in its configuration list and also exists in the UE NR security capabilities is to be established, SgNB 802 allocates resources and selects the encryption algorithm and integrity algorithm for the DRB and SRB. If the new key (S-KgNB) is delivered to SgNB 802, in the case where an SRB is to be established, SgNB 802 calculates K SgNB-UP-enc as well as K SgNB-RRC-int and K SgNB-RRC-enc . Then, SgNB 802 sends an SgNB addition request confirmation 810 to MeNB 704, which indicates the availability of the requested resources and the identifiers of the selected algorithms to serve the requested DRB and / or SRB for UE 702.

[0047] MeNB 704 sends an RRC connection reconfiguration request 812 to UE 702, which indicates that the UE is configured with new DRBs and / or SRBs for SgNB 802. If a new key is needed, MeNB 704 may include an SCG counter parameter to indicate to UE 702 that it can calculate S-K gNB for SgNB 802. MeNB 704 forwards the UE configuration parameters (which include the algorithm identifiers received from SgNB 802) to UE 702. Since the message is sent over the RRC connection between MeNB 704 and UE 702, it is integrity protected using the K RRCint of MeNB 704. Therefore, the SCG counter cannot be tampered with, and UE 702 can assume that it is new.

[0048] If the SCG counter parameter is included, the UE 702 may accept the RRC connection reconfiguration request 812 and calculate S-K for the SgNB 802 gNB The UE 702 may also calculate K for the associated allocated DRB and / or SRB SgNB-UP-enc and K SgNB-RRC-int and K SgNB-RRC-enc The UE 702 sends an RRC connection reconfiguration response 814 to the MeNB 704. At block 818, the UE 702 activates the selected encryption / decryption and integrity protection.

[0049] The MeNB 704 sends an SgNB reconfiguration complete 816 to the SgNB 802 (e.g., via the X2-C interface) to notify the SgNB 802 of the configuration result. Upon receiving this message, at block 820, the SgNB 802 may activate the selected encryption / decryption and integrity protection for the UE. If the SgNB 802 does not activate the encryption / decryption and integrity protection for the UE 702 at this stage, the SgNB 802 may activate the encryption / decryption and integrity protection when receiving a random access request from the UE 702 in the random access procedure 822.

[0050] Figure 9 is a signaling diagram of the UP IP activation process 900 according to some embodiments. In this example, the UE 702 and the MeNB 704 are configured to support RN PDCP UP IP in LTE. Figure 9 Illustrates the UP IP configuration in EN-DC when reusing RN PDCP UP IP between the UE 702 and the MeNB 704. The UP IP activation process 900 includes an RRC connection establishment process 706 and a process 708a for NAS attachment, authentication (e.g., EPS AKA), and security. The process 708a may include a series of messages for the NAS registration process, the primary authentication process, and the NAS security mode command (SMC) process. As shown, the UE 702 is configured to provide a UE security capability indication (e.g., in a protocol data unit (PDU) in the protocol session establishment request) to indicate to the MME 406 whether the UE supports LTE PDCP UP IP. Based on the information of whether the UE 702 supports LTE PDCP UP IP and whether the MeNB 704 supports LTE PDCP UP IP, the MME 406 decides whether to activate UP IP in the MeNB 704. The process 708b may include authentication (checking the subscription data associated with the UE 702 in the HSS 408) and security processes.

[0051] After procedures 708a and 708b, NAS security is established. Since MeNB 704 supports RN PDCP UPIP, MME 406 can configure the UP security policy for MeNB 704 in the S1 INITIAL CONTEXT SETUP message.

[0052] The UP IP activation procedure 900 also includes the GTP-C create session procedure 710. At block 712, NAS security is established.

[0053] MeNB 704 then performs the MeNB-initiated SgNB addition procedure, as discussed herein with respect to Figure 8 as discussed. In Figure 9 a portion of the SgNB addition procedure is shown. For example, MeNB 704 checks whether UE 702 has NR capabilities and is authorized to access NR. MeNB 704 sends an SgNB addition request 806 to SgNB 802 (e.g., via the X2-C interface) to negotiate the available resources, configurations, and algorithms at the SgNB. When connected to the EPC, MeNB 704 indicates to SgNB 802 that UP integrity protection can be activated. If a new key is required, MeNB 704 calculates S-K gNB and delivers it to SgNB 802. The UE NR security capabilities can also be sent to SgNB 802.

[0054] If DRBs and SRBs that have the highest priority in its configuration list and also exist in the UE NR security capabilities are to be established, SgNB 802 allocates resources and selects the encryption algorithms and integrity algorithms for the DRBs and SRBs. If the new S-KgNB is delivered to SgNB 802, then in the case where an SRB is to be established, SgNB 802 calculates K SgNB-UP-enc as well as K SgNB-RRC-int and K SgNB-RRC-enc . SgNB 802 sends an SgNB addition request confirmation 810 to MeNB 704, which indicates the availability of the requested resources and the identifiers of the selected algorithms to serve the requested DRBs and / or SRBs for UE 702.

[0055] As discussed herein (e.g., see Table 1 and Figure 10),The MeNB 704 makes a decision on the UP path selection based on the UE capabilities (e.g., UE security capabilities indicating support for LTE PDCP UP IP), MeNB capabilities, and SgNB capabilities. In the RRC connection reconfiguration 902, the MeNB 704 sends a RRC connection reconfiguration request to the UE 702, which indicates that the UE is configured with new DRBs and / or SRBs for the SgNB 802. The MeNB 704 forwards the UE configuration parameters (which include the algorithm identifier received from the SgNB 802) to the UE 702. The UE 702 sends a RRC reconfiguration complete to the MeNB 704. Then, the UE 702 can activate the selected encryption / decryption and integrity protection at this time.

[0056] The MeNB 704 sends a SgNB reconfiguration complete 816 message to the SgNB 802 (e.g., via the X2-C interface) to notify the SgNB 802 of the configuration result. Upon receiving this message, the SgNB 802 can activate the selected encryption / decryption and integrity protection for the UE. If the SgNB 802 does not activate the encryption / decryption and integrity protection for the UE 702 at this stage, the SgNB 802 can activate the encryption / decryption and integrity protection when receiving a random access request from the UE 702. Then, the process 716 in which the AS security is established can be executed.

[0057] As described above, the MeNB can make a UP IP decision or determine the UP path based on the UE capabilities (e.g., UE security capabilities indicating support for LTE PDCP UP IP), MeNB capabilities, and SgNB capabilities. In 3GPP R15 and R16, the NR PDCP in EN-DC does not support UP IP. Therefore, there can be two different implementations in the MeNB: M1: Support for RNPDCP UP IP used in LTE + NR PDCP without UP IP; and M2: Do not support RNPDCP UP IP used in LTE + NR PDCP without UPIP.

[0058] For 3GPP R15 and above, the UE supports NR PDCP UP IP. Therefore, there can be two different implementations for the UE: U1: Support for RNPDCP UP IP used in LTE + NR PDCP with UP IP; and U2: Do not support RNPDCP UP IP used in LTE + NR PDCP with UP IP.

[0059] Thus, in some embodiments, the MeNB may select among four policy decisions based on UE capabilities (U1 or U2) with UP IP, MeNB capabilities (M1 or M2), and SgNB capabilities NR PDCP as shown in Table 1.

[0060]

[0061] Table 1

[0062] Figure 10 is a block diagram showing potential UP IP decisions for the simplified EN-DC architecture shown for Figure 6A and Figure 6B according to one embodiment. Referring to Table 1 and Figure 10 , for Policy #1, Policy #2, or Policy #4, the MeNB may select a UP path with UP IP on the SCG (between UE 602 and en-gNB 608) and / or split bearer (between MeNB 604 and en-gNB 608). For Policy #3, the MeNB may select a UP path with UP IP on the MCG (between UE 602 and MeNB 604), SCG (between UE 602 and en-gNB 608), and / or split bearer (between MeNB 604 and en-gNB 608).

[0063] Figure 11 is a flowchart of method 1100 for enabling a MeNB to configure UP IP for a UE supporting EN-DC according to some embodiments. In block 1102, method 1100 includes performing an attachment procedure with the UE, wherein the MeNB forwards a PDU session establishment request from the UE to the MME. The PDU session establishment request includes UE security capabilities indicating whether the UE supports PDCP UP IP. In block 1104, method 1100 includes performing a secondary node addition procedure for operating a dual connection with the MeNB and the SgNB. In block 1106, method 1100 includes determining a UP path based on UE security capabilities, MeNB security capabilities, and SgNB security capabilities.

[0064] In some embodiments of method 1100, support for PDCP UP IP includes support for Relay Node (RN) PDCP UP IP used in LTE, and the SgNB security capabilities correspond to the SgNB supporting NR PDCP with UP IP. The UE security capabilities may also indicate whether the UE supports NR PDCP with UP IP. The MeNB security capabilities may indicate whether the MeNB supports RN PDCP UP IP used in LTE and NR PDCP without UP IP.

[0065] In one embodiment of method 1100, determining the UP path includes selecting to use UP IP on at least one of a secondary cell group (SCG) bearer and a split bearer based on: determining that the UE does not support RN PDCP UP IP used in LTE and the UE supports NR PDCP with UP IP; and determining that the MeNB supports RN PDCP UP IP used in LTE and the MeNB supports NR PDCP without UP IP.

[0066] In one embodiment of method 1100, determining the UP path includes selecting to use UP IP on at least one of a secondary cell group (SCG) bearer and a split bearer based on: determining that the UE does not support RN PDCP UP IP used in LTE and the UE supports NR PDCP with UP IP; and determining that the MeNB does not support RN PDCP UP IP used in LTE and the MeNB supports NR PDCP without UP IP.

[0067] In one embodiment of method 1100, determining the UP path includes selecting to use UP IP on at least one of a master cell group (MCG) bearer, a secondary cell group (SCG) bearer, and a split bearer based on: determining that the UE supports RN PDCP UP IP used in LTE and the UE supports NR PDCP with UP IP; and determining that the MeNB supports RN PDCP UP IP used in LTE and the MeNB supports NR PDCP without UP IP.

[0068] In one embodiment of method 1100, determining the UP path includes selecting to use UP IP on at least one of a secondary cell group (SCG) bearer and a split bearer based on: determining that the UE supports RN PDCP UP IP used in LTE and the UE supports NR PDCP with UP IP; and determining that the MeNB does not support RN PDCP UP IP used in LTE and the MeNB supports NR PDCP without UP IP.

[0069] In one embodiment of method 1100, performing an attachment procedure includes receiving, from the MME, an S1 initial context setup message from the MME to configure a UP security policy for the MeNB.

[0070] In one embodiment of method 1100, performing a secondary node addition procedure includes providing, by the MeNB to the SgNB, an indication of an activatable UP IP.

[0071] Figure 12It is a flowchart of method 1200 for a UE according to certain embodiments. In block 1202, method 1200 includes performing an RRC connection establishment procedure with the MeNB. In block 1204, method 1200 includes sending a PDU session establishment request to the MME via the MeNB, the PDU session establishment request including UE security capabilities to indicate to the MME whether the UE supports PDCP UP IP. In block 1206, method 1200 includes receiving from the MeNB an RRC connection reconfiguration message for establishing a UP IP for EN-DC operation with the MeNB and the SgNB.

[0072] In one embodiment of method 1200, the UE security capabilities indicate that the UE supports relay node PDCP UP IP used in LTE and the UE supports NR PDCP with UP IP. Additionally, or in other embodiments, the RRC connection reconfiguration message establishes that the UP IP will be used for at least one of MCG bearers, SCG bearers, and split bearers.

[0073] In one embodiment of method 1200, the UE security capabilities indicate that the UE does not support relay node PDCP UP IP used in LTE and the UE supports NR PDCP with UP IP. Additionally, or in other embodiments, the RRC connection reconfiguration message establishes that the UP IP will be used for at least one of SCG bearers and split bearers.

[0074] Figure 13 It is a flowchart of method 1300 for an MME according to certain embodiments. In block 1302, method 1300 includes receiving from the UE via the MeNB a PDU session establishment request, the PDU session establishment request including UE security capabilities to indicate whether the UE supports PDCP UP IP. In block 1304, method 1300 includes determining whether the MeNB supports PDCP UP IP. In block 1306, method 1300 includes determining whether to activate UP IP in the MeNB for EN-DC based on whether both the UE and the MeNB support PDCP UP IP.

[0075] In one embodiment of method 1300, the PDCP UP IP includes relay node (RN) PDCP UP IP used in LTE.

[0076] In one embodiment, 1300 further includes generating an S1 initial context setup message to configure a UP security policy for the MeNB.

[0077] Figure 14Shows an example of infrastructure equipment 1400 according to various embodiments. Infrastructure equipment 1400 may be implemented as a base station, radio head, RAN node, AN, application server, and / or any other element / device discussed herein. In other examples, infrastructure equipment 1400 may be implemented in or by a UE.

[0078] Infrastructure equipment 1400 includes application circuitry 1402, baseband circuitry 1404, one or more radio frequency front-end modules 1406 (RFEMs), memory circuitry 1408, a power management integrated circuit (shown as PMIC 1410), a power splitter circuit 1412, a network controller circuit 1414, a network interface connector 1420, a satellite positioning circuit 1416, and a user interface circuit 1418. In some embodiments, the device infrastructure equipment 1400 may include additional elements, such as, for example, memory / storage, a display, a camera, a sensor, or an input / output (I / O) interface. In other embodiments, these components may be included in more than one device. For example, the circuitry may be separately included in more than one device for CRAN, vBBU, or other similar implementations. Application circuitry 1402 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: a low-dropout regulator (LDO), an interrupt controller, a serial interface such as SPI, 2 I2C or a general-purpose programmable serial interface module, a real-time clock (RTC), timer-counters (including interval timers and watchdog timers), general-purpose input / output (I / O or IO), a memory card controller (such as a Secure Digital (SD) multimedia card (MMC) or similar product), a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Action Group (JTAG) test access port. The processor (or core) of application circuitry 1402 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on infrastructure equipment 1400. In some implementations, the memory / storage elements may be on-chip memory circuitry that may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0079] The processor of application circuit 1402 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC machines (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more digital signal processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, application circuit 1402 may include or may be a dedicated processor / controller for operating in accordance with the various embodiments herein. As an example, the processor of application circuit 1402 may include one or more Intel or processors; Advanced Micro Devices (AMD) processors, accelerated processing units (APUs), or processors; ARM-based processors licensed by ARM Holdings, Ltd., such as the ARM Cortex-A series processors provided by Cavium (TM), Inc., and ; MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior P-class processors; and so on. In some embodiments, infrastructure equipment 1400 may not utilize application circuit 1402 and, instead, may include a dedicated processor / controller to process, for example, IP data received from the EPC or 5GC.

[0080] In some specific implementations, the application circuit 1402 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, etc. The one or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. For example, the programmable processing device may be one or more field programmable devices (FPDs), such as field programmable gate arrays (FPGAs), etc.; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), etc.; ASICs, such as structured ASICs, etc.; programmable system-on-chips (PSoCs); and so on. In such specific implementations, the circuit of the application circuit 1402 may include logic blocks or logic architectures, as well as other interconnected resources that can be programmed to perform various functions such as the processes, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuit of the application circuit 1402 may include memory units (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.)) for storing logic blocks, logic architectures, data, etc. in look-up tables (LUTs), etc. The baseband circuit 1404 may be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits, a single packaged integrated circuit soldered to the main circuit board, or a multi-chip module that includes two or more integrated circuits.

[0081] The user interface circuit 1418 may include one or more user interfaces designed to enable a user to interact with the infrastructure equipment 1400 or a peripheral component interface designed to enable a peripheral component to interact with the infrastructure equipment 1400. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., reset buttons), one or more indicators (e.g., light-emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touch screen, a speaker or other audio emitting device, a microphone, a printer, a scanner, headphones, a display screen or display device, etc. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power interface, etc.

[0082] The radio front end module 1406 may include a millimeter wave (mmWave) radio front end module (RFEM) and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter wave and sub-millimeter wave radio functions may be implemented in the same physical radio front end module 1406 that combines both millimeter wave antennas and sub-millimeter waves.

[0083] The memory circuit 1408 may include one or more of the following: volatile memory, including dynamic random access memory (DRAM) and / or synchronous dynamic random access memory (SDRAM); and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as "flash memory"), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may be combined with and Three-dimensional (3D) cross-point (XPOINT) memory. Memory circuit 1408 can be implemented as one or more of the following: a solder-in package integrated circuit, a socket memory module, and a plug-in memory card.

[0084] PMIC 1410 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources, such as a battery or capacitor. The power alarm detection circuit may detect one or more of a brownout (undervoltage) and a surge (overvoltage) condition. Power tee circuit 1412 may provide electrical power extracted from a network cable to provide both power and data connections for infrastructure equipment 1400 using a single cable.

[0085] The network controller circuit 1414 may provide connectivity to a network using a standard network interface protocol such as Ethernet, Ethernet based on a GRE tunnel, Ethernet based on Multi-Protocol Label Switching (MPLS), or some other suitable protocol. Network connectivity may be provided to / from the infrastructure equipment 1400 via a network interface connector 1420 using a physical connection, which may be an electrical connection (commonly referred to as a "copper interconnect"), an optical connection, or a wireless connection. The network controller circuit 1414 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the network controller circuit 1414 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0086] The positioning circuit 1416 includes circuitry for receiving and decoding signals transmitted / broadcast by a positioning network of a Global Navigation Satellite System (GNSS). Examples of navigation satellite constellations (or GNSS) include the Global Positioning System (GPS) of the United States, the Global Navigation System (GLONASS) of Russia, the Galileo system of the European Union, the Beidou Navigation Satellite System of China, regional navigation systems, or GNSS augmentation systems (e.g., for navigation using the Indian Constellation (NAVIC), the Quasi-Zenith Satellite System (QZSS) of Japan, the Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS) of France, etc.). The positioning circuit 1416 includes various hardware components (e.g., including hardware devices for facilitating OTA communication such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some embodiments, the positioning circuit 1416 may include a Microtechnology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a primary timing clock to perform position tracking / estimation in the absence of GNSS assistance. The positioning circuit 1416 may also be part of or interact with the baseband circuit 1404 and / or the radio front-end module 1406 to communicate with nodes and components of the positioning network. The positioning circuit 1416 may also provide position data and / or time data to the application circuit 1402, which may use this data to synchronize operations with various infrastructure, etc. Figure 14 The components shown may communicate with each other using an interface circuit, which may include any number of bus and / or interconnect (IX) technologies such as Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCix), PCI Express (PCie), or any number of other technologies. The bus / IX may be a proprietary bus, e.g., used in an SoC-based system. Other bus / IX systems may be included, such as 2 I2C interface, SPI interface, point-to-point interface, and power bus, etc.

[0087] Figure 15 An example of a platform 1500 according to various embodiments is shown. In an embodiment, the computer platform 1500 may be adapted to be used as a UE, an application server, and / or any other element / device discussed herein. The platform 1500 may include any combination of the components shown in the example. The components of the platform 1500 may be implemented as an integrated circuit (IC), a portion of an IC, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted within the computer platform 1500, or as components otherwise incorporated within the chassis of a larger system. Figure 15The block diagram is intended to show a high-level view of the components of computer platform 1500. However, some of the components shown may be omitted, additional components may exist, and different arrangements of the components shown may occur in other specific implementations.

[0088] Application circuit 1502 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: LDO, interrupt controller, serial interface (such as SPI), 2 I2C or general programmable serial interface module, RTC, timer-counter (including interval timer and watchdog timer), general-purpose IO, memory card controller (such as SD MMC or similar), USB interface, MIPI interface, and JTAG test access port. The processor (or core) of application circuit 1502 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on platform 1500. In some specific implementations, the memory / storage elements may be on-chip memory circuitry that may include any suitable volatile and / or non-volatile memory such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology such as those discussed herein.

[0089] The processor of application circuit 1502 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, multi-threaded processors, ultra-low voltage processors, embedded processors, some other known processing elements, or any suitable combination thereof. In some embodiments, application circuit 1502 may include or may be a dedicated processor / controller for operating according to the various embodiments herein.

[0090] For example, the processor of application circuit 1502 may include a processor based on Architecture Core TM such as Quark TM , Atom TM , i3, i5, i7, or MCU-class processor, or another such processor available from Corporation. The processor of application circuit 1502 may also be one or more of the following: Advanced Micro Devices (AMD) A processor or an accelerated processing unit (APU); from the AS-A9 processor from Inc., from the Snapdragon from Technologies, Inc. TM processor, Texas Instruments, OpenMultimedia Applications Platform (OMAP) TM processors; MIPS-based designs from MIPS Technologies, Inc., such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, Ltd., such as ARM Cortex-A, Cortex-R, and Cortex-M series processors; etc. In some specific embodiments, the application circuitry 1502 can be part of a system-on-chip (SoC), where the application circuitry 1502 and other components are formed as a single integrated circuit or a single package, such as the Edison from the company ( Corporation) or Galileo TM SoC board. TM

[0091] In addition or alternatively, the application circuitry 1502 can include circuitry such as, but not limited to, one or more of the following: field programmable devices (FPDs), such as FPGAs, etc.; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), etc.; ASICs, such as structured ASICs, etc.; programmable SoCs (PSoCs); etc. In such embodiments, the circuitry of the application circuitry 1502 can include logic blocks or logic architectures, and other interconnect resources that can be programmed to perform various functions such as the processes, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuitry of the application circuitry 1502 can include memory units (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.)) for storing logic blocks, logic architectures, data, etc. in look-up tables (LUTs), etc.

[0092] The baseband circuitry 1504 can be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits, a single-package integrated circuit soldered to the main circuit board, or a multi-chip module that includes two or more integrated circuits. ​

[0093] The radio front-end module 1506 may include a millimeter-wave (mmWave) radio front-end module (RFEM) and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some embodiments, the one or more sub-millimeter-wave RFICs may be physically separated from the mmWave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In an alternative embodiment, the radio functions of both millimeter-wave and sub-millimeter-wave may be implemented in the same physical radio front-end module 1506 that combines millimeter-wave antennas and sub-millimeter-waves.

[0094] The memory circuit 1508 may include any number and type of memory devices for providing a given amount of system memory. For example, the memory circuit 1508 may include one or more of the following: volatile memory, which includes random access memory (RAM), dynamic RAM (DRAM), and / or synchronous dynamic RAM (SDRAM); and non-volatile memory (NVM), which includes high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc. The memory circuit 1508 may be developed according to Joint Electron Device Engineering Council (JEDEC) low-power double data rate (LPDDR)-based designs such as LPDDR2, LPDDR3, LPDDR4, etc. The memory circuit 1508 may be implemented as one or more of the following: a soldered-in package integrated circuit, a single-die package (SDP), a dual-die package (DDP), or a quad-die package (Q17P), a socketed memory module, a dual in-line memory module (DIMM) including a micro DIMM or a mini DIMM, and / or soldered to a motherboard via a ball grid array (BGA). In low-power embodiments, the memory circuit 1508 may be on-chip memory or registers associated with the application circuit 1502. To provide persistent storage of information such as data, applications, operating systems, etc., the memory circuit 1508 may include one or more mass storage devices, which may particularly include solid-state disk drives (SSDDs), hard disk drives (HDDs), micro HDDs, resistive change memories, phase change memories, holographic memories, or chemical memories, etc. For example, the computer platform 1500 may incorporate 3D cross-point (XPOINT) memory obtained from and ...

[0095] The removable memory 1526 may include devices, circuits, housings / casings, ports, or sockets, etc. for coupling a portable data storage device to the platform 1500. These portable data storage devices can be used for mass storage and may include, for example, flash memory cards (such as Secure Digital (SD) cards, micro SD cards, xD Picture Cards, etc.), as well as USB flash drives, optical discs, external HDDs, etc.

[0096] The platform 1500 may also include interface circuitry (not shown) for connecting external devices to the platform 1500. External devices connected to the platform 1500 via this interface circuitry include the sensor 1522 and the electromechanical component (shown as EMC 1524), as well as a removable memory device coupled to the removable memory 1526.

[0097] The sensor 1522 includes devices, modules, or subsystems aimed at detecting events or changes in its environment and sending information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors particularly include: inertial measurement units (IMUs) including accelerometers, gyroscopes, and / or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including three-axis accelerometers, three-axis gyroscopes, and / or magnetometers; level sensors; flow sensors; temperature sensors (such as thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (such as cameras or lensless apertures); light detection and ranging (LiDAR) sensors; proximity sensors (such as infrared radiation detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers; microphones or other similar audio capture devices; etc.

[0098] The EMC 1524 includes devices, modules, or subsystems aimed at enabling the platform 1500 to change its state, position, and / or orientation, or to move or control mechanisms or (sub)systems. Additionally, the EMC 1524 can be configured to generate messages / signaling and send messages / signaling to other components of the platform 1500 to indicate the current state of the EMC 1524. Examples of the EMC 1524 include one or more power switches, relays (including electromechanical relays (EMR) and / or solid-state relays (SSR)), actuators (e.g., valve actuators, etc.), audible sound generators, visual warning devices, motors (e.g., DC motors, stepper motors, etc.), wheels, thrusters, propellers, claws, clamps, hooks, and / or other similar electromechanical components. In an embodiment, the platform 1500 is configured to operate one or more EMC 1524s based on one or more capture events and / or instructions or control signals received from a service provider and / or various clients. In some specific implementations, the interface circuit can connect the platform 1500 to the positioning circuit 1516. The positioning circuit 1516 includes circuitry for receiving and decoding signals transmitted / broadcast by the positioning network of GNSS. Examples of navigation satellite constellations (or GNSS) can include GPS in the United States, GLONASS in Russia, the Galileo system in the European Union, the Beidou Navigation Satellite System in China, regional navigation systems, or GNSS augmentation systems (e.g., NAVIC, QZSS in Japan, DORIS in France, etc.). The positioning circuit 1516 includes various hardware elements (e.g., including hardware devices for facilitating OTA communication such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some embodiments, the positioning circuit 1516 can include a micro PNT IC that uses a primary timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit 1516 can also be part of or interact with the baseband circuit 1504 and / or the radio front-end module 1506 to communicate with the nodes and components of the positioning network. The positioning circuit 1516 can also provide position data and / or time data to the application circuit 1502, which can use this data to synchronize operations with various infrastructures (e.g., radio base stations) for turn-by-turn navigation applications, etc.

[0099] In some embodiments, the interface circuit may couple platform 1500 to a near field communication circuit (shown as NFC circuit 1512). NFC circuit 1512 is configured to provide contactless short-range communication based on radio frequency identification (RFID) standards, where magnetic field sensing is used to enable communication between NFC circuit 1512 and an NFC-enabled device external to platform 1500 (e.g., an "NFC contact point"). NFC circuit 1512 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller may be a chip / IC that provides NFC functionality to NFC circuit 1512 by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to transmit short-range RF signals. The RF signals may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transmit stored data to NFC circuit 1512, or initiate data transfer between NFC circuit 1512 and another active NFC device (e.g., a smart phone or an NFC-enabled POS terminal) near platform 1500.

[0100] The drive circuit 1518 may include software elements and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to platform 1500. The drive circuit 1518 may include various drivers, thereby allowing other components of platform 1500 to interact with or control various input / output (I / O) devices that may be present within or connected to the platform. For example, the drive circuit 1518 may include: a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to the touchscreen interface of platform 1500, a sensor driver for obtaining sensor readings from sensor 1522 and controlling and allowing access to sensor 1522, an EMC driver for obtaining the actuator position of EMC 1524 and / or controlling and allowing access to EMC 1524, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0101] A power management integrated circuit (shown as PMIC 1510) (also referred to as a "power management circuit") may manage the power provided to various components of platform 1500. Specifically, relative to the baseband circuit 1504, PMIC 1510 may control power selection, voltage scaling, battery charging, or DC-DC conversion. When platform 1500 is capable of being powered by a battery 1514, e.g., when the device is included in a UE, PMIC 1510 is typically included.

[0102] In some embodiments, the PMIC 1510 may control or otherwise be part of various power saving mechanisms of the platform 1500. For example, if the platform 1500 is in the RRC_Connected state, in which the platform remains connected to the RAN node because it expects to receive traffic soon, then after a period of inactivity, the platform may enter a state called Discontinuous Reception mode (DRX). During this state, the platform 1500 can power down for short intervals, thereby saving power. If there is no data traffic activity over an extended period, the platform 1500 can transition to the RRC_Idle state, in which the platform is disconnected from the network and does not perform operations such as channel quality feedback, handovers, etc. The platform 1500 enters a very low power state and performs paging, in which the platform wakes up periodically to listen for the network and then powers down again. The platform 1500 may not receive data while in this state; to receive data, the platform transitions back to the RRC_Connected state. Additional power saving modes can make the device unavailable to the network for longer than the paging interval (ranging from seconds to hours). During this time, the device is completely disconnected from the network and can be powered off completely. Any data sent during this time will incur a significant delay, and it is assumed that the delay is acceptable.

[0103] The battery 1514 may power the platform 1500, but in some examples, the platform 1500 may be installed in a fixed location and may have a power source coupled to the electrical grid. The battery 1514 can be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in V2X applications, the battery 1514 can be a typical lead-acid automotive battery.

[0104] In some specific implementations, the battery 1514 can be a "smart battery" that includes or is coupled to a battery management system (BMS) or a battery monitoring integrated circuit. The BMS can be included in the platform 1500 to track the state of charge (SoC) of the battery 1514. The BMS can be used to monitor other parameters of the battery 1514, such as the state of health (SoH) and state of function (SoF) of the battery 1514 to provide fault prediction. The BMS can communicate information about the battery 1514 to the application circuit 1502 or other components of the platform 1500. The BMS may also include an analog-to-digital (ADC) converter that allows the application circuit 1502 to directly monitor the voltage of the battery 1514 or the current from the battery 1514. Battery parameters can be used to determine actions that the platform 1500 can perform, such as transmission frequency, network operation, sensing frequency, etc.

[0105] A power block or other power source coupled to the power grid can be coupled to the BMS to charge the battery 1514. In some examples, the power block can be replaced with a wireless power receiver to wirelessly obtain power, for example, through a loop antenna in the computer platform 1500. In these examples, the wireless battery charging circuit can be included in the BMS. The specific charging circuit selected can depend on the size of the battery 1514 and thus on the current required. Charging can be performed using the aviation fuel standards published by the Aviation Fuel Alliance, the Qi wireless charging standards published by the Wireless Power Consortium, or the Rezence charging standards published by the Wireless Power Consortium.

[0106] The user interface circuit 1520 includes various input / output (I / O) devices present within or connected to the platform 1500 and includes one or more user interfaces designed to enable interaction with the user of the platform 1500 and / or a peripheral component interface designed to enable interaction with peripheral components of the platform 1500. The user interface circuit 1520 includes input device circuitry and output device circuitry. The input device circuitry includes any physical or virtual means for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. The output device circuitry includes any physical or virtual means for displaying information or otherwise communicating information (such as sensor readings, actuator positions, or other similar information). The output device circuitry can include any number and / or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (such as binary state indicators (e.g., light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as a display device or a touchscreen (e.g., a liquid crystal display (LCD), an LED display, a quantum dot display, a projector, etc.), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the platform 1500. The output device circuitry can also include speakers or other audio emitting devices, printers, etc. In some embodiments, the sensor 1522 can be used as input device circuitry (e.g., an image capture device, a motion capture device, etc.) and one or more EMCs can be used as output device circuitry (e.g., an actuator for providing haptic feedback, etc.). In another example, an NFC circuit can be included to read an electronic tag and / or connect to another NFC-enabled device, the NFC circuit including an NFC controller and a processing device coupled to an antenna element. The peripheral component interface can include, but is not limited to, a non-volatile memory port, a USB port, an audio jack, a power interface, etc.

[0107] Although not shown, components of platform 1500 may communicate with each other using suitable bus or interconnect (IX) technology, which may include any number of technologies, including ISA, EISA, PCI, PCix, PCie, Time-Triggered Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus / IX may be a proprietary bus / IX, for example, used in an SoC-based system. Other bus / IX systems may be included, such as 2 I2C interfaces, SPI interfaces, point-to-point interfaces, and power buses, among others.

[0108] Figure 16 is a block diagram showing components 1600 capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of performing any one or more of the methods discussed herein. Specifically, Figure 16 shows a schematic diagram of hardware resources 1602, which include one or more processors 1606 (or processor cores), one or more memory / storage devices 1614, and one or more communication resources 1624, each of which may be communicatively coupled via a bus 1616. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1622 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1602.

[0109] The processor 1606 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) (such as a baseband processor), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processors 1608 and 1610.

[0110] The memory / storage device 1614 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 1614 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage devices, etc.

[0111] The communication resource 1624 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 1604 or one or more databases 1620 via a network 1618. For example, the communication resource 1624 may include a wired communication component (e.g., for coupling via a Universal Serial Bus (USB)), a cellular communication component, an NFC component, a component (e.g., low power consumption), a Wi- component, and other communication components.

[0112] The instructions 1612 may include software, programs, applications, applets, applications, or other executable code for causing at least any one of the processors 1606 to execute any one or more of the methods discussed herein. The instructions 1612 may reside entirely or partially within at least one of the processors 1606 (e.g., within the cache memory of the processor), the memory / storage device 1614, or any suitable combination thereof. Additionally, any portion of the instructions 1612 may be transferred from any combination of the peripheral devices 1604 or the database 1620 to the hardware resources 1602. Thus, the memory of the processor 1606, the memory / storage device 1614, the peripheral devices 1604, and the database 1620 are examples of computer-readable and machine-readable media.

[0113] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more of the operations, techniques, processes, and / or methods described in the following example section. For example, the baseband circuit described above in connection with one or more of the foregoing figures may be configured to operate in accordance with one or more of the following examples. As another example, the circuitry associated with the UE, base station, network element, etc. described above in connection with one or more of the foregoing figures may be configured to operate in accordance with one or more of the examples shown in the following example section.

[0114] Example section

[0115] The following examples relate to additional embodiments.

[0116] Embodiment 1 is a method for a master evolved Node B (MeNB) to configure user plane (UP) integrity protection (IP) for a user equipment (UE) that supports evolved universal terrestrial radio access - new radio dual connectivity (EN-DC). The method includes: performing an attachment process with the UE, where the MeNB forwards a protocol data unit (PDU) session establishment request from the UE to a mobility management entity (MME), and the PDU session establishment request includes UE security capabilities indicating whether the UE supports packet data convergence protocol (PDCP) UP IP; performing a secondary node addition process for operating the dual connectivity of the MeNB and a secondary g Node B (SgNB); and determining a UP path based on the UE security capabilities, MeNB security capabilities, and SgNB security capabilities.

[0117] Embodiment 2 includes the method according to Embodiment 1, where the support for the PDCP UP IP includes support for relay node (RN) PDCP UP IP used in Long Term Evolution (LTE), and where the SgNB security capabilities correspond to the SgNB supporting new radio (NR) PDCP with UP IP.

[0118] Embodiment 3 includes the method according to Embodiment 2, where the UE security capabilities further indicate whether the UE supports the RN PDCP UP IP used in LTE and the NR PDCP with UP IP.

[0119] Embodiment 4 includes the method according to Embodiment 3, where the MeNB security capabilities indicate whether the MeNB supports the RN PDCP UP IP used in LTE and NR PDCP without UP IP.

[0120] Embodiment 5 includes the method according to Embodiment 4, where determining the UP path includes selecting to use UP IP on at least one of a secondary cell group (SCG) bearer and a split bearer based on: determining that the UE does not support the RN PDCP UP IP used in LTE and the UE supports the NR PDCP with UP IP; and determining that the MeNB supports the RN PDCP UP IP used in LTE and the MeNB supports the NR PDCP without UP IP.

[0121] Embodiment 6 includes the method according to Embodiment 4, wherein determining the UP path includes selecting to use UPIP on at least one of a secondary cell group (SCG) bearer and a split bearer based on: determining that the UE does not support the RN PDCP UP IP used in LTE and the UE supports the NR PDCP with UP IP; and determining that the MeNB does not support the RN PDCP UP IP used in LTE and the MeNB supports the NR PDCP without UP IP.

[0122] Embodiment 7 includes the method according to Embodiment 4, wherein determining the UP path includes: selecting to use UP IP on at least one of a master cell group (MCG) bearer, a secondary cell group (SCG) bearer, and a split bearer based on: determining that the UE supports the RN PDCP UP IP used in LTE and the UE supports the NR PDCP with UP IP; and determining that the MeNB supports the RN PDCP UP IP used in LTE and the MeNB supports the NR PDCP without UP IP.

[0123] Embodiment 8 includes the method according to Embodiment 4, wherein determining the UP path includes selecting to use UPIP on at least one of a secondary cell group (SCG) bearer and a split bearer based on: determining that the UE supports the RNPDCP UP IP used in LTE and the UE supports the NR PDCP with UP IP; and determining that the MeNB does not support the RN PDCP UP IP used in LTE and the MeNB supports the NR PDCP without UP IP.

[0124] Embodiment 9 includes the method according to Embodiment 1, wherein performing the attachment procedure includes receiving, from the MME, an S1 initial context setup message from the MME to configure a UP security policy for the MeNB.

[0125] Embodiment 10 includes the method according to Embodiment 1, wherein performing the secondary node addition procedure includes providing an indication of an activatable UP IP from the MeNB to the SgNB.

[0126] Embodiment 11 is a method for a User Equipment (UE). The method includes: performing a Radio Resource Control (RRC) connection establishment procedure with a Master eNodeB (MeNB); sending a Protocol Data Unit (PDU) session establishment request to a Mobility Management Entity (MME) through the MeNB, the PDU session establishment request including UE security capabilities to indicate to the MME whether the UE supports Packet Data Convergence Protocol (PDCP) User Plane (UP) Integrity Protection (IP); and receiving an RRC connection reconfiguration message from the MeNB, the RRC connection reconfiguration message establishing UP IP for an Evolved Universal Terrestrial Radio Access - New Radio Dual Connectivity (EN-DC) operation with the MeNB and a Secondary g NodeB (SgNB).

[0127] Embodiment 12 includes the method according to Embodiment 11, wherein the UE security capabilities indicate that the UE supports Relay Node PDCP UP IP used in Long Term Evolution (LTE) and the UE supports New Radio (NR) PDCP with UP IP.

[0128] Embodiment 13 includes the method according to Embodiment 12, wherein the RRC connection reconfiguration message establishes that UP IP will be used for at least one of a Master Cell Group (MCG) bearer, a Secondary Cell Group (SCG) bearer, and a split bearer.

[0129] Embodiment 14 includes the method according to Embodiment 11, wherein the UE security capabilities indicate that the UE does not support Relay Node PDCP UP IP used in Long Term Evolution (LTE) and the UE supports New Radio (NR) PDCP with UP IP.

[0130] Embodiment 15 includes the method according to Embodiment 14, wherein the RRC connection reconfiguration message establishes that UP IP will be used for at least one of a Secondary Cell Group (SCG) bearer and a split bearer.

[0131] Embodiment 16 is a method for a Mobility Management Entity (MME). The method includes: receiving, from a User Equipment (UE) through a Master eNodeB (MeNB), a Protocol Data Unit (PDU) session establishment request, the PDU session establishment request including UE security capabilities to indicate whether the UE supports Packet Data Convergence Protocol (PDCP) User Plane (UP) Integrity Protection (IP); determining whether the MeNB supports the PDCP UP IP; and determining whether to activate the UP IP in the MeNB for an Evolved Universal Terrestrial Radio Access - New Radio Dual Connectivity (EN-DC) based on whether both the UE and the MeNB support the PDCP UP IP.

[0132] Example 17 includes the method according to Example 16, wherein the PDCP UP IP includes the relay node (RN) PDCP UP IP used in Long Term Evolution (LTE).

[0133] Example 18 includes the method according to Example 16, further including generating an S1 initial context setup message to configure the UP security policy for the MeNB.

[0134] Example 19 may include an apparatus including components for performing one or more elements of the methods described in any of the above embodiments or related thereto or any other method or process described herein.

[0135] Example 20 may include one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the methods described in any of the above embodiments or related thereto or any other method or process described herein.

[0136] Example 21 may include an apparatus including logic components, modules, or circuits for performing one or more elements of the methods described in any of the above embodiments or related thereto or any other method or process described herein.

[0137] Example 22 may include a method, technique, or process described in any of the above embodiments or related thereto, or a part or component thereof.

[0138] Example 23 may include an apparatus including: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process described in any of the above embodiments or related thereto or a part thereof.

[0139] Example 24 may include a signal described in any of the above embodiments or related thereto, or a part or component thereof.

[0140] Example 25 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message described in any of the above embodiments or related thereto, or a part or component thereof, or other content described in the present disclosure.

[0141] Example 26 may include a signal encoded with data described in any of the above embodiments or related thereto, or a part or component thereof, or other content described in the present disclosure.

[0142] Embodiment 27 may include a signal or a portion or component thereof that encodes a datagram, packet, frame, segment, PDU, or message as described in or related to any of the foregoing embodiments, or as otherwise described in the present disclosure.

[0143] Embodiment 28 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process or a portion thereof as described in or related to any of the foregoing embodiments.

[0144] Embodiment 29 may include a computer program that includes instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process or a portion thereof as described in or related to any of the foregoing embodiments.

[0145] Embodiment 30 may include a signal in a wireless network as shown and described herein.

[0146] Embodiment 31 may include a method of communicating in a wireless network as shown and described herein.

[0147] Embodiment 32 may include a system for providing wireless communication as shown and described herein.

[0148] Embodiment 33 may include a device for providing wireless communication as shown and described herein.

[0149] Unless otherwise expressly stated, any one of the foregoing embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings, or may be acquired from practice of various embodiments.

[0150] Embodiments and specific implementations of the systems and methods described herein may include various operations, which may be embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that include specific logic components for performing the operations, or may include a combination of hardware, software, and / or firmware.

[0151] It should be recognized that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into a single system, partially incorporated into other systems, divided into multiple systems, or otherwise partitioned or combined. Additionally, it is contemplated that the parameters, attributes, aspects, etc. of one embodiment can be used in another embodiment. For clarity, these parameters, attributes, aspects, etc. are described in only one or more embodiments, and it should be recognized that unless specifically stated herein, these parameters, attributes, aspects, etc. can be combined with or substituted for the parameters, attributes, aspects, etc. of another embodiment.

[0152] It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of the authorized use should be clearly explained to the user.

[0153] Although the foregoing has been described in considerable detail for purposes of clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that there are many alternative ways of implementing both the processes and apparatus described herein. Accordingly, the embodiments of the invention should be regarded as illustrative rather than restrictive, and the specification is not limited to the details given herein, but may be modified within the scope of the appended claims and equivalents thereof.

Claims

1. A method for a main evolved node MeNB to configure a user plane UP integrity protection IP for a user equipment UE supporting Evolved Universal Terrestrial Radio Access-New Air Interface Dual Connectivity EN-DC, the method comprising: performing an attach procedure with the UE, wherein the MeNB forwards a protocol data unit (PDU) session establishment request from the UE to a mobility management entity (MME), wherein the PDU session establishment request includes a UE security capability indicating whether the UE supports a packet data convergence protocol (PDCP) user plane integrity protection (PDCP) UP IP, wherein the PDCP UP IP includes a relay node packet data convergence protocol (RN) user plane integrity protection (RN PDCP) UP IP used in long term evolution (LTE); Performing a secondary node adding procedure for operating a dual connection with the MeNB and a secondary next generation node SgNB; as well as The UP path is determined based on the UE security capabilities, MeNB security capabilities and SgNB security capabilities.

2. The method according to claim 1, wherein the SgNB security capability corresponds to the SgNB supporting the New Air Interface Packet Data Convergence Protocol NR PDCP with UP IP.

3. The method according to claim 2, wherein the UE security capabilities further indicate whether the UE supports the RN PDCP UP IP and the NR PDCP with UP IP used in LTE.

4. The method of claim 3, wherein the MeNB security capability indicates whether the MeNB supports the RN PDCP UP IP and NR PDCP without UP IP used in LTE.

5. The method of claim 4, wherein determining the UP path comprises: The UP IP is used on at least one of the secondary cell group SCG bearer and the split bearer based on the following selections: determining that the UE does not support the RN PDCP UP IP used in LTE and determining that the UE supports the NR PDCP with UP IP; and Determining that the MeNB supports the RN PDCP UP IP used in LTE and determining that the MeNB supports the NR PDCP without UPIP.

6. The method of claim 4, wherein determining the UP path comprises: The UP IP is used on at least one of the secondary cell group SCG bearer and the split bearer based on the following selections: determining that the UE does not support the RN PDCP UP IP used in LTE and determining that the UE supports the NR PDCP with UP IP; and Determining that the MeNB does not support the RN PDCP UP IP used in LTE and determining that the MeNB supports the NR PDCP without UP IP.

7. The method of claim 4, wherein determining the UP path comprises: The UP IP is used on at least one of the primary cell group MCG bearer, the secondary cell group SCG bearer, and the split bearer based on the following selections: determining that the UE supports the RN PDCP UP IP used in LTE and determining that the UE supports the NR PDCP with UP IP; and Determining that the MeNB supports the RN PDCP UP IP used in LTE and determining that the MeNB supports the NR PDCP without UPIP.

8. The method of claim 4, wherein determining the UP path comprises: The UP IP is used on at least one of the secondary cell group SCG bearer and the split bearer based on the following selections: determining that the UE supports the RN PDCP UP IP used in LTE and determining that the UE supports the NR PDCP with UP IP; and Determining that the MeNB does not support the RN PDCP UP IP used in LTE and determining that the MeNB supports the NR PDCP without UP IP.

9. The method of claim 1, wherein performing the attach procedure comprises receiving an S1 Initial Context Setup message from the MME to configure a UP security policy to the MeNB.

10. The method of claim 1, wherein performing the secondary node adding procedure comprises providing an indication from the MeNB to the SgNB that a UP IP can be activated.

11. A method for user equipment UE, the method comprising: Performing a radio resource control (RRC) connection establishment procedure with the primary evolving node MeNB; Sending a protocol data unit PDU session establishment request to a mobility management entity MME through the MeNB, wherein the PDU session establishment request includes UE security capabilities to indicate to the MME whether the UE supports a packet data convergence protocol PDCP user plane UP integrity protection IP, wherein the PDCP UP IP includes a relay node packet data convergence protocol user plane integrity protection RN PDCP UPIP used in long term evolution LTE; and An RRC connection reconfiguration message is received from the MeNB, wherein the RRC connection reconfiguration message establishes a UP IP for Evolved Universal Terrestrial Radio Access-New Air Interface dual connectivity EN-DC operation with the MeNB and a secondary next generation node SgNB.

12. The method of claim 11, wherein the UE security capabilities indicate that the UE supports the RN PDCP UP IP used in LTE and indicates that the UE supports New Radio Packet Data Convergence Protocol NR PDCP with UP IP.

13. The method according to claim 12, wherein the RRC connection reconfiguration message establishes a UP IP to be used for at least one of a primary cell group (MCG) bearer, a secondary cell group (SCG) bearer, and a split bearer.

14. The method of claim 11, wherein the UE security capabilities indicate that the UE does not support the RN PDCP UP IP used in LTE and indicates that the UE supports New Radio Interface Packet Data Convergence Protocol NRPDCP with UP IP.

15. The method according to claim 14, wherein the RRC connection reconfiguration message establishes a UP IP to be used for at least one of a secondary cell group (SCG) bearer and a split bearer.

16. A method for a mobility management entity (MME), the method comprising: receiving a protocol data unit (PDU) session establishment request from a user equipment (UE) through a main evolution node (MeNB), wherein the PDU session establishment request includes a UE security capability to indicate whether the UE supports a packet data convergence protocol (PDCP) user plane (UP) integrity protection IP, wherein the PDCP UP IP includes a relay node packet data convergence protocol (RN) user plane integrity protection (RN PDCP) UP IP used in long term evolution (LTE); Determining whether the MeNB supports the PDCP UP IP; as well as Based on whether both the UE and the MeNB support the PDCP UP IP, it is determined whether to activate the UP IP in the MeNB for Evolved Universal Terrestrial Radio Access-New Air Interface Dual Connectivity EN-DC.

17. The method of claim 16, further comprising generating an S1 Initial Context Setup message to configure a UP security policy to the MeNB.

18. A base station configured as a main evolution node (MeNB), comprising means for processing each of the methods according to any one of claims 1 to 10.

19. User equipment comprising means for processing each of the methods according to any one of claims 11 to 15.

20. A node in a wireless network configured as a Mobility Management Entity (MME), comprising means for processing each of the methods according to any one of claims 16 to 17.

Images