Selective user plane protection in 5g virtual ran

Abstract

Systems and methods for selective user plane protection in 5G virtual RANs are provided. A method for communicating with a gNB distributed unit (gNB-DU), performed by the gNB central unit (gNB-CU), includes determining whether to selectively encrypt the PDU if it is not originally encrypted. In response to determining selective encryption, the method includes encrypting the PDU to be sent to the gNB-DU. In response to determining non-selective encryption, the method includes transmitting the PDU to the gNB-DU. In this way, additional security is provided while minimizing performance impact. In some embodiments, this provides lower overhead on the gNB-CU-UP side compared to applying general protection to all PDUs. Furthermore, latency overhead is limited because secure session establishment and handshake are limited to the gNB-CU-UP–SEG domain, not from gNB-CU-UP to gNB-DU.

Description

Technical Field

[0001] This disclosure relates to virtual radio access network (RAN) nodes. Background Technology

[0002] The goal is to establish viable solutions that guarantee ubiquitous connectivity between devices from all types of environments. Resource optimization and efficiency, scalability and extensibility, and cost efficiency must be considered. The extensive design components and current trends of fifth-generation (5G) telecommunications networks are virtualizing and cloudifying radio access networks (RAN) and core network components to accommodate the diverse needs of all types of stakeholders, such as mobile operators. Variations of these products are Virtual Network Functions (VNF) packages that provide the same functionality as Physical Network Functions (PNFs). Strategies for operators to reduce operating expenses (OPEX) and / or capital expenditures (CAPEX) include owning their own data centers or leasing cloud resources on which RAN or core network VNFs can be deployed.

[0003] Virtual RAN (vRAN) variants deployable on cloud platforms have seen significant growth. A key feature of any vRAN package is the security component, ensuring a high level of assurance for any mobile operator deploying vRAN on its own or a third-party cloud infrastructure. While the 3rd Generation Partnership Project (3GPP) has established a set of security requirements for 5G telecom networks, additional security solutions are sometimes needed to address new threat models specific to each infrastructure. Therefore, improved systems and approaches for protection in 5G vRAN are required. Summary of the Invention

[0004] Systems and methods for selective user plane protection in fifth-generation (5G) virtual radio access networks (RANs) are provided. In some embodiments, a method performed by a gNB central unit (gNB-CU) for communicating with a gNB distributed unit (gNB-DU) includes: determining whether to selectively encrypt a PDU to be transmitted to the gNB-DU if the protocol data unit (PDU) was originally not encrypted. In response to determining to selectively encrypt the PDU to be transmitted to the gNB-DU, the method includes encrypting the PDU to be transmitted to the gNB-DU. In response to determining not to selectively encrypt the PDU to be transmitted to the gNB-DU, the method includes transmitting the PDU to be transmitted to the gNB-DU. The method also includes transmitting the PDU to be transmitted to the gNB-DU. In this way, additional security is provided while minimizing performance impact. In some embodiments, this provides lower overhead on the gNB-CU-user plane (gNB-CU-UP) side compared to applying general protection to all PDUs. Furthermore, latency overhead is limited because secure session establishment and handshake are restricted to the gNB-CU-U–SEG domain, rather than gNB-CU-UP to gNB-DU.

[0005] In some embodiments, sending a PDU to be sent to a gNB-DU includes sending the PDU to an Internet Protocol Security (IPsec) Security Gateway (SEG) for transmission to the gNB-DU.

[0006] In some embodiments, the gNB-CU includes a first multiplexer (MUX), and sending a PDU to the IPsec SEG includes sending the PDU from the first MUX to a second MUX in the IPsec SEG.

[0007] In some embodiments, determining whether to selectively encrypt a PDU to be sent to the gNB-DU includes: determining to selectively encrypt the PDU if one or more of the following are true: the PDU includes "type=0" and "user data presence flag=0"; and the PDU includes: "type=0"; "user data presence flag=1"; and the PDU is a Packet Data Convergence Protocol (PDCP) control PDU.

[0008] In some embodiments, the method further includes determining whether the PDU received from the gNB-DU is selectively encrypted. In response to determining that the received PDU is selectively encrypted, the received PDU to be sent to the gNB-CU is decrypted.

[0009] In some embodiments, the received PDU is received from the IPsec SEG.

[0010] In some embodiments, receiving a PDU from an IPsec SEG includes receiving a PDU from a second MUX in the IPsec SEG via a first MUX.

[0011] In some embodiments, a secure session is established between the gNB-CU and the IPsec SEG. In some embodiments, a secure session between the gNB-CU and the IPsec SEG is established when one of the following occurs: a first PDCP instance is created in the gNB-CU; on demand; when signaling is sent from the gNB-CU; when interface E1 is established between the gNB-CU user plane (gNB-CU-UP) and the gNB-CU control plane (gNB-CU-CP); when interface F1 is established between the gNB-CU and the gNB-DU; and when gNB-CU-UP is created.

[0012] In some embodiments, encrypting the PDU to be sent to the gNB-DU includes encrypting the PDU using a symmetric encryption key.

[0013] In some embodiments, the PDU is encrypted using a first encryption key, and the received PDU is decrypted using a second encryption key, wherein the first encryption key is different from the second encryption key.

[0014] In some embodiments, the gNB-CU operates in a first container. In some embodiments, the first MUX operates in a first container. In some embodiments, the first MUX operates in a second container, and the first and second containers operate in the same Pod.

[0015] In some embodiments, a method performed by an IPsec SEG for facilitating communication between a gNB-DU and a gNB-CU includes: if the PDU was not originally encrypted, determining whether to selectively encrypt a PDU to be sent from the gNB-DU to the gNB-CU. In response to determining to selectively encrypt the PDU to be sent to the gNB-CU, the method includes encrypting the PDU to be sent to the gNB-CU. In response to determining not to selectively encrypt the PDU to be sent to the gNB-CU, the method includes transmitting the PDU to the gNB-CU. The method also includes transmitting the PDU to the gNB-CU. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several aspects of this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0017] Figure 1 A wireless communication system is shown as a 5G network architecture consisting of core network functions (NFs), where the interaction between any two NFs is represented by a point-to-point reference point / interface;

[0018] Figure 2 This illustrates a 5G network architecture that uses service-based interfaces between NFs in the control plane, rather than... Figure 1 The point-to-point reference point / interface used in the 5G network architecture;

[0019] Figure 3 Flexible schemes for placing various entities constituting the RAN and enabling cooperation among them, according to some embodiments of this disclosure, are illustrated.

[0020] Figure 4 A security architecture for F1 is shown according to some embodiments of this disclosure;

[0021] Figure 5 This illustration shows a gNB-Distributed Unit (gNB-DU) sending downlink (DL) data transmission status to a gNB Central Unit (gNB-CU) according to some embodiments of the present disclosure;

[0022] Figure 6 Methods for communicating with a gNB-DU, performed by a gNB-CU, according to some embodiments of the present disclosure, are illustrated.

[0023] Figure 7 Methods for facilitating communication between gNB-DU and gNB-CU, performed by an Internet Protocol Security (IPsec) Security Gateway (SEG) according to some embodiments of the present disclosure, are illustrated.

[0024] Figure 8 and Figure 9 The F1-U according to some embodiments of the present disclosure is shown and extended to the Packet Data Convergence Protocol (PDCP) entity;

[0025] Figure 10 The F1-U transport layer according to some embodiments of the present disclosure is shown;

[0026] Figure 11 The following is illustrated: a gNB-CU-User Plane (gNB-CU-UP) protocol stack implementing PDCP and F1-U termination according to some embodiments of the present disclosure;

[0027] Figure 12 The PDCP control PDU format according to some embodiments of this disclosure is shown;

[0028] Figure 13 The datagram transport layer security (DTLS) 1.3 ciphertext (including header) structure according to some embodiments of this disclosure is shown;

[0029] Figure 14An example of a cellular communication network according to some embodiments of the present disclosure is shown;

[0030] Figure 15 This is a schematic block diagram of a radio access node according to some embodiments of the present disclosure;

[0031] Figure 16 This illustrates some embodiments according to the present disclosure. Figure 15 A schematic block diagram of a virtualized embodiment of a radio access node;

[0032] Figure 17 It is based on some other embodiments of this disclosure Figure 15 A schematic block diagram of a radio access node;

[0033] Figure 18 This is a schematic block diagram of a user equipment (UE) according to some embodiments of the present disclosure;

[0034] Figure 19 It is based on some other embodiments of this disclosure Figure 18 A schematic block diagram of the UE;

[0035] Figure 20 A telecommunications network connected to a host computer via an intermediate network is illustrated according to some embodiments of the present disclosure;

[0036] Figure 21 This is a general block diagram of a host computer communicating with a UE via a base station through a partial wireless connection according to some embodiments of the present disclosure;

[0037] Figure 22 This is a flowchart illustrating a method implemented in a communication system according to an embodiment of the present disclosure;

[0038] Figure 23 This is a flowchart illustrating a method implemented in a communication system according to an embodiment of the present disclosure;

[0039] Figure 24 This is a flowchart illustrating a method implemented in a communication system according to an embodiment of the present disclosure; and

[0040] Figure 25 This is a flowchart illustrating a method implemented in a communication system according to an embodiment of the present disclosure. Detailed Implementation

[0041] The embodiments described below provide information for those skilled in the art to practice the embodiments and illustrate the best mode for practicing the embodiments. After reading the following description with reference to the accompanying drawings, those skilled in the art will understand the concepts of this disclosure and will recognize the applications of these concepts not specifically given herein. It should be understood that these concepts and applications fall within the scope of this disclosure.

[0042] Radio node: As used in this article, a “radio node” is a radio access node or wireless communication device.

[0043] Radio Access Node: As used herein, a “radio access node,” “radio network node,” or “radio access network node” is any node in the radio access network (RAN) of a cellular communication network that operates to wirelessly transmit and / or receive signals. Some examples of radio access nodes include, but are not limited to: base stations (e.g., new radio (NR) base stations (gNBs) in 3GPP 5G NR networks or enhanced or evolved Node Bs (eNBs) in 3GPP LTE networks), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, home eNBs, etc.), relay nodes, network nodes that implement some of the functions of a base station or a gNB distributed unit (gNB-DU), or network nodes that implement some of the functions of other types of radio access nodes.

[0044] Core Network Node: As used herein, a “core network node” is any type of node in the core network or any node that implements core network functions. Some examples of core network nodes include, for example, a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), etc. Some other examples of core network nodes include nodes that implement Access and Mobility Functions (AMF), UPF, Session Management Functions (SMF), Authentication Server Functions (AUSF), Network Slice Selection Functions (NSSF), Network Exposure Functions (NEF), Network Functions (NF) Repository Functions (NRF), Policy Control Functions (PCF), Unified Data Management (UDM), etc.

[0045] Communication equipment: As used herein, “communication equipment” is any type of device that can access a network. Some examples of communication equipment include, but are not limited to: mobile phones, smartphones, sensor devices, meters, vehicles, home appliances, medical devices, media players, cameras, or any type of consumer electronic device (e.g., but not limited to: televisions, radios, lighting fixtures, tablet computers, laptop computers, or personal computers (PCs)). Communication equipment can be portable, handheld, computer-integrated, or vehicle-mounted mobile devices capable of transmitting voice and / or data via wireless or wired connections.

[0046] Wireless communication equipment: One type of communication equipment is a wireless communication equipment, which can be any type of wireless device that has access to a wireless network (e.g., a cellular network) (i.e., served by a wireless network). Some examples of wireless communication equipment include, but are not limited to: User Equipment (UE) devices, Machine-Type Communication (MTC) devices, and Internet of Things (IoT) devices in 3GPP networks. Such wireless communication equipment can be or can be integrated into mobile phones, smartphones, sensor devices, instruments, vehicles, home appliances, medical devices, media players, cameras, or any type of consumer electronic device (e.g., but not limited to: televisions, radios, lighting fixtures, tablet computers, laptop computers, or PCs). Wireless communication equipment can be portable, handheld, computer-integrated, or vehicle-mounted mobile devices capable of transmitting voice and / or data via a wireless connection.

[0047] Network node: As used in this article, a “network node” is any node that is part of the radio access network or core network of a cellular communication network / system.

[0048] Note that the descriptions presented herein focus on 3GPP cellular communication systems, and therefore frequently use 3GPP terminology or similar terms. However, the concepts disclosed herein are not limited to 3GPP systems.

[0049] Note that the term “cell” may be used in the description in this article; however, in particular for the 5G NR concept, beams can be used instead of cells, so it is important to note that the concepts described in this article apply equally to both cells and beams.

[0050] Virtual RAN (vRAN) variants that can be deployed on cloud platforms have seen significant growth. A key feature of any vRAN package is the security component, ensuring a high level of assurance for any mobile operator deploying vRAN on its own or a third-party cloud infrastructure. While 3GPP has established a set of security requirements for 5G telecom networks, including requirements for newly introduced interfaces in the 5G gNB split architecture, additional security solutions are sometimes needed to address new threat models specific to each infrastructure.

[0051] In fact, the new cloud paradigm is impacting traditional threat models built for PNFs. Besides malicious end-users, threat models for virtualized environments include two new types of threat agents: (1) tenants configured within the same physical infrastructure; and (2) the cloud provider itself, which may differ from the operator (e.g., a public cloud provider). Some operators do not fully trust virtual environments to the point that they expect to protect all communications even within the data center. Therefore, additional security mechanisms are sometimes needed to complement vRAN VNF deployments in the cloud. It is expected that any security solution will have minimal impact on operational-level functionality and performance. Therefore, improved systems and methods for protection in 5G vRAN are needed.

[0052] The description of the vRAN architecture is related to 3GPP (TS 38.401), followed by a high-level view of the public safety architecture in the case of vRAN deployment on a third-party platform (3PP) cloud platform.

[0053] Figure 1 A wireless communication system represented as a 5G network architecture consisting of core network functions (NFs) is shown, where the interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 1 Can be regarded as Figure 14 A specific implementation of System 1400.

[0054] From the access side, Figure 1 The 5G network architecture shown includes multiple user equipment (UEs) connected to the RAN or access network (AN) and access and mobility management functions (AMF). Typically, the (R)AN includes base stations, such as evolved Node B (eNB) or NR base stations (gNB). From the core network side, Figure 1 The 5G core NF shown includes Network Slice Selection Function (NSSF), Authentication Server Function (AUSF), Unified Data Management (UDM), AMF, Session Management Function (SMF), Policy Control Function (PCF), and Application Function (AF).

[0055] In the standardization specifications, reference points for the 5G network architecture are used to form detailed call flows. Reference point N1 is defined as carrying signaling between the UE and the AMF. Reference points for connections between the AN and AMF, and between the AN and the UPF, are defined as N2 and N3, respectively. Reference point N11 exists between the AMF and SMF, meaning the SMF is at least partially controlled by the AMF. The SMF and UPF use N4 so that the UPF can be configured using control signals generated by the SMF, and the UPF can report its status to the SMF. Specifically, N9 is the reference point for connections between different UPFs, and N14 is the reference point for connections between different AMFs. N15 and N7 are defined because the PCF applies policies to the AMF and SMF respectively. The AMF requires N12 to perform UE authentication. N8 and N10 are defined because the AMF and SMF require the UE's subscriber data.

[0056] The 5G core network is designed to separate the user plane and the control plane. In the network, the user plane carries user services, while the control plane carries signaling. Figure 1 In this architecture, the UPF resides in the user plane, while all other NFs—AMF, SMF, PCF, AF, AUSF, and UDM—are in the control plane. Separating the user plane and control plane ensures that resources on each plane can be scaled independently. It also allows the UPF to be deployed separately from control plane functions in a distributed manner. In this architecture, the UPF can be deployed very close to the UE to reduce the round-trip time (RTT) between the UE and the data network for applications requiring low latency.

[0057] The core 5G network architecture is composed of modular functions. For example, AMF and SMF are independent functions in the control plane. Separate AMF and SMF allow for independent evolution and scaling. Other control plane functions (such as PCF and AUSF) can also be separated, such as... Figure 1 As shown. The modular functional design enables the 5G core network to flexibly support a variety of services.

[0058] Each NF interacts directly with every other NF. Intermediate functions can be used to route messages from one NF to another. In the control plane, a set of interactions between two NFs is defined as a service so that it can be reused. This service implementation supports modularity. The user plane supports interactions such as forwarding operations between different UPFs.

[0059] exist Figure 2 The document describes the 5G system architecture defined by 3GPP (TS 23.501). Figure 2 This illustrates a 5G network architecture that uses service-based interfaces between NFs in the control plane, rather than... Figure 1 The point-to-point reference point / interface used in the 5G network architecture. However, the above reference... Figure 1 The NF described corresponds to Figure 2 The NF shown can provide services to other authorized NFs through service-based interfaces. Figure 2 In this context, service-based interfaces are represented by the letter "N" followed by the name of the NF. For example, the service-based interface for AMF is Namf, the service-based interface for SMF is Nsmf, and so on. Figure 2 The Network Exposure Function (NEF) and Network Function (NF) Repository Function (NRF) are not shown in the discussion above. Figure 1 In the middle. However, it should be clarified that, although in Figure 1 It is not explicitly stated in the document. Figure 1 All NFs described in the text can be used with... Figure 2 NEF and NRF interactions.

[0060] It can be described in the following way Figure 1 and 2 The diagram illustrates some properties of the NF. The AMF provides UE-based authentication, authorization, mobility management, etc. Even if a UE uses multiple access technologies, it is essentially connected to a single AMF because the AMF is independent of the access technology. The SMF is responsible for session management and assigns Internet Protocol (IP) addresses to the UE. It also selects and controls the UPF for data transmission. If a UE has multiple sessions, different SMFs can be assigned to each session to manage them individually and potentially provide different functionalities for each session. The AF provides information about packet flows to the PCF, which is responsible for policy control, to support Quality of Service (QoS). Based on this information, the PCF determines policies regarding mobility and session management to ensure the proper functioning of the AMF and SMF. The AUSF supports UE authentication functions, etc., and therefore stores data used for UE authentication, etc., while the UDM stores the UE's subscription data. The Data Network (DN), which is not part of the 5G core network, provides internet access or operator services, etc.

[0061] NF can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualization function instantiated on a suitable platform (e.g., cloud infrastructure).

[0062] exist Figure 2In some embodiments of the RAN domain, the new gNB (TS 38.300) provides vRAN—a product designed to: (1) provide traditional RAN benefits and, additionally, alleviate core network signaling (e.g., keep mobility signaling in the RAN); (2) provide cloud-wide benefits (resource pooling, improved reliability with geographic redundancy) while reducing capital expenditures and operating expenditures (CAPEX / OPEX), enabling multi-tenancy, resilience, deterministic computing performance, and forming the basis for new business models.

[0063] In some embodiments, vRAN conforms Figure 3 The 3GPP advanced architecture, Figure 3 A flexible scheme for placing the various entities that constitute the RAN and enabling their collaboration is illustrated. The parts requiring strict synchronization and strict latency in the protocol stack are closer to the radio environment (closer to the end user); for example, the 3GPP gNB-DU, implementing the PHY / MAC / RLC stack layer (TS38.401). The parts with radio asynchronous functions (Packet Processing Function (PPF) and Radio Control Function (RCF)), corresponding to the 3GPP gNB-CU-User Plane (gNB-CU-UP) and gNB-CU-Control Plane (gNB-CU-CP) respectively, can be virtualized (e.g., in a central office); they implement the Packet Data Convergence Protocol (PDCP) / IP and PDCP / RRC stack layers respectively.

[0064] exist Figure 3 Within this framework, there exists a gNB-DU pool, which can connect to the gNB-CU (gNB-CU-UP and gNB-CU-CP) pool via an IP network. Upon initiation, a persistent connection is established between the gNB-DU and gNB-CU. Different User Equipment (UE) data streams are mapped to Data Radio Bearers (DRBs) within these persistent connections.

[0065] F1 is the logical interface connecting the CU and DU. The 3GPP TS 38.401 document specifies that F1 terminates in both the gNB-CU and gNB-DU. F1 functionality is described in detail in TS 38.470 v.15.5.0, and more specifically, Section 5.2 addresses F1-C (interface management, system information, UE context management, RRC message transmission, paging, etc.), and Section 5.3 addresses F1-U (transmission of user data (i.e., DRB data) and flow control functions). TS 38.472 and TS 38.473 specify the protocol stack and the protocol itself (i.e., F1AP) for F1-C. For F1-U, TS 38.475 specifies the protocol stack (i.e., F1-U in GTP-U). Finally, TS 38.425 specifies the user plane protocol used on the F1-U interface (“NR User Plane Protocol”, clarifying: “NR User Plane Protocol functionality may reside in nodes terminating X2-U (for EN-DC) or Xn-U or F1-U interfaces.”). As used herein, the terms F1-U and NR-U are used interchangeably.

[0066] In TS 38.474v15.2.0: transport bearers are identified by the General Packet Radio Service Tunneling Protocol (GTP-U) Tunnel Endpoint ID (TEID) (TS 29.281) and IP addresses (source TEID, destination TEID, source IP address, destination IP address). Therefore, the distribution of bearers can be plotted by observing these identifiers.

[0067] Based on the nature of the information transmitted through it, specific security requirements have been specified for the F1 interface in TS 33.501. This document reproduces both the security requirements and security mechanisms for F1 (TS33.501 (v15.4.0)).

[0068] 5.3.9 Requirements for the gNB F1 interface

[0069] The requirements given below apply to gNBs with segmented DU-CU implementations using the F1 interface defined in TS 38.470

[31] . Signaling services (i.e., F1-C interface management services as defined in TS 38.470

[31] and F1-C signaling as defined in TS 38.472

[32] carrying both) and user plane data can be transmitted on the F1 interface between a given DU and its CU.

[0070] The F1-C interface should support confidentiality, integrity, and replay protection.

[0071] - All management services carried on the CU-DU link should have integrity, confidentiality and replay protection.

[0072] - The gNB should support confidentiality, integrity and replay protection on the gNB DU-CUF1-U interface

[33] for the user plane.

[0073] Management services carried on the F1-C and CU-DU links should be protected independently of F1-U services.

[0074] Note: The above requirements allow for different protections for F1-U than for all other services on CU-DU (e.g., services on F1-C) (including turning integrity and / or encryption off or on for F1-U).

[0075] Security mechanisms of the 9.8.2F1 interface

[0076] The F1 interface connects the gNB-CU to the gNB-DU. It includes F1-C for the control plane and F1-U for the user plane.

[0077] To protect services on the F1-U interface, it should support IPsec encapsulated secure payload (ESP) and IKEv2 certificate-based authentication as specified in subclause 9.1.2 of this document, with confidentiality, integrity and replay protection.

[0078] To protect services on the F1-C interface, it should support IPsec ESP and IKEv2 certificate-based authentication as specified in subclause 9.1.2 of this document, and have confidentiality, integrity and replay protection.

[0079] IPsec implementation is mandatory on both gNB-DU and gNB-CU. On the gNB-CU side, SEG can be used to terminate IPsec tunnels.

[0080] In addition to IPsec, the F1-C interface should also support Datagram Transport Layer Security (DTLS) as specified in RFC 6083

[58] to provide integrity protection, replay protection, and confidentiality protection. The security configuration files used for DTLS implementation and use should comply with the provisions given in Annex E of TS33.310[5].

[0081] Note 1: Using transport layer security via DTLS does not preclude the use of network layer protection under Network Domain Security (NDS) / IP as specified in TS 33.210[3]. In fact, IPsec has the advantage of providing topology hiding.

[0082] Note 2: Using an encryption solution to protect F1 is the operator's decision. If the gNB is placed in a physically secure environment, then the "secure environment" includes other nodes and links adjacent to the gNB.

[0083] Note 3: RFC 6083

[58] documents the security considerations for DTLS on Stream Control Transport Protocol (SCTP).

[0084] In summary, F1-C can benefit from dual protection (DTLS and IPsec), while F1-U can disable encryption. The reason for the latter is simple: F1-U PDUs carry PDCP PDUs protected by PDCP (TS 38.323) encryption. Nevertheless, IPsec remains a common solution for F1-U, especially considering the network topology hiding provided by IPsec in tunneled mode. Furthermore, IPsec Security Gateway (SEG) services are commonly used at CU sites, i.e., vRAN domains (see [link to relevant documentation]). Figure 3 ).

[0085] In some embodiments, vRAN is developed as a VNF package to be provided and deployed in a multi-tenant environment. More precisely, the vRAN central unit (gNB-CU functions, namely gNB-CU-UP and gNB-CU-CP) is provided as a virtual machine and / or container. In some embodiments, this results in containerized vRAN.

[0086] Figure 4 The following diagram illustrates a security architecture for F1 according to some embodiments of this disclosure. F1 typically relies on the following protections in vRAN deployments:

[0087] For F1-C: In Figure 4In this context, a DTLS session is established for the F1-C interface between CU-CP and DU (e.g., to protect signaling radio bearers, DU management, etc.). Furthermore, all F1-Cs are encapsulated in an IPsec tunnel from the vRAN SEG to the DU site. The benefits of using an IPsec SEG are: (1) the SEG provides network topology hiding; and (2) furthermore, the IPsec tunnels do not multiply as the CU VNF expands outward, thus IPsec management remains relatively simple. Conversely, IPsec tunnels ending in the CU-CP service (e.g., container Pods) will result in the addition of a new IPsec tunnel within the DU site with each new CU-CP service instance. As used herein, a “Pod” refers to a group of containers that can operate as if in the same execution environment. In some embodiments, containers in a Pod can be managed as a single unit. In some embodiments, one or more containers in a Pod are dedicated to acting as a proxy or any other “helper” for the virtual functions encapsulated within the Pod. In some embodiments, containers in a Pod share storage and / or network resources. In some embodiments, containers in a Pod are co-located, co-scheduled, and / or run in a shared context. In some embodiments, containers within a Pod can be treated as if they were running on the same physical machine or virtual machine. An example of container infrastructure management is Kubernetes. TM The disclosure uses the term "Pod," which is the smallest manageable unit of a container. However, this disclosure is not limited thereto.

[0088] For F1-U: F1-U PDUs over GTP-U / UDP / IP are encapsulated in an IPsec tunnel between the SEG and DU. Encryption is disabled on the SEG–gNB-CU-UP network segment. This is because F1-U PDUs are primarily PDCP data PDUs in the Data Radio Bearer (DRB), which are protected by PDCP through encryption.

[0089] Given the numerous advantages of container technology, operators are expected to prefer containerized vRAN deployments. These vRAN deployments will likely occur in many types of environments, including untrusted, semi-trusted, and / or multi-tenant environments. Therefore, the gNB-CU-UP domain is included within a boundary protected by IPsec SEG.

[0090] DRB services can be identified by the GTP-U TEID and the IP address of the GTP-U tunnel (TS38.474). Each NR user plane protocol instance is associated with only one data radio bearer. One NR user plane instance exists for each GTP tunnel. When a GTP tunnel is established, a new NR user plane instance is established (see TS 38.425). According to TS 38.323 (PDCP specification): "Each radio bearer (except SRB0) is associated with one PDCP entity." This is why IPsec SEG is appropriate in multi-tenant environments: hiding the GTP / IP header prevents IPsec packets from providing meaningful information to external observers, who cannot distinguish DRBs or map them to IP packets.

[0091] However, not all F1-U PDUs are protected by PDCP. Several types of F1-U PDUs exist that carry data different from the user's PDCP data PDU in the downlink or uplink. For example, in TS 38.323, section 4.3.2, the PDCP in the CU (gNB-CU-UP) expects the following service from the Radio Link Control (RLC) entity (in the gNB-DU): "Confirmed data transmission service, including an indication of successful transmission of the PDCP PDU." TS 38.322 sections 4.3.1 and 5.2.3.1.1 confirm these RLC-to-PDCP indications, and for DRBs in AM mode (as a result of an RLC state PDU from the UE, the RLC entity should "send an indication of successful transmission of the RLC service data unit to the upper layer"), these RLC-to-PDCP "indications" are not specifically protected.

[0092] As another example, TS 38.425 defines an NR-U protocol with several NR PDU types, an example being from the “corresponding node” (the node that interacts with the node hosting the NR PDCP for flow control) to the “node hosting the NR PDCP entity” (i.e., such as...). Figure 5 As shown, this is the "Downlink Data Delivery Status" [DL DATA DELIVERYSTATUS] from gNB-DU to gNB-CU. Regarding... Figure 5 DL data transmission status can be piggybacked on "Uplink User Data of Related Data Radio Bearer" (TS 38.425 Section 5.4.2.1).

[0093] As another example, other types of non-PDCP protection data are also PDCP control PDUs (TS 38.323) from the UE PDCP entity to the CU (gNB-CU-UP) PDCP entity.

[0094] Furthermore, some insights into UE behavior can be gleaned simply by observing the DL data transmission status F1-U PDU. According to TS 38.425: "Once the corresponding node detects a successful random access channel (RACH) access by the UE for the corresponding data radio bearer, the corresponding node shall send an initial DL data transmission status frame to the node hosting the NR PDCP entity." In other words, the DU that detects successful UE RACH access sends this F1-U PDU.

[0095] Similarly, according to TS 38.425: "When the DL data transmission status frame is the last DL status report, the frame shall also include a final frame indication. Upon receiving such an indication, the node hosting the NR PDCP entity assumes that no more UL or DL ​​data is expected to be transmitted between the corresponding node and the UE." In other words, this F1-U PDU can indicate the termination of data transmission for the UE on that DRB.

[0096] Furthermore, in B. Cheng and S. Moore, “Securing Robust Header Compression (ROHC)”, MILCOM 2013–2013 IEEE Military Communications Conference, San Diego, CA, 2013, pp. 1383–1390, the authors demonstrated a three (3) attack on ROHC using ROHC feedback. In TS 38.323v15.5.0 (PDCP), only ROHC compression is reportedly supported. Therefore, PDCP control PDUs with ROHC feedback can benefit from additional protection.

[0097] To recap, the cloud threat model includes other tenants and / or cloud providers in the threat broker. Therefore, relying solely on... Figure 4 The security architecture will still allow (privileged) observers / attackers / malicious parties to access the SEG–gNB-CU-UP network segment, i.e., access to network data that helps to gain insights into UE behavior or characteristics.

[0098] A more direct solution is to terminate the IPsec tunneling in the gNB-CU-UP service instance. The disadvantages will be: (1) the IPsec tunneling will multiply as gNB-CU-UP expands outward; and (2) the overhead of encrypting / decrypting all F1-U PDUs (including F1-UPDUs protected by PDCP).

[0099] Alternatively, another direct solution is to establish a Transport Layer Security (TLS) session from the DU to the gNB-CU-UP, as in the case of F1-C. The idea of ​​a TLS session for mapping to control plane data (Broadcast Control Channel (BCCH), Physical Control Channel (PCCH), SRB0, and SRB1) has been discussed.

[0100] Besides the actual latency overhead, there's the overhead of encrypting all traffic (including PDUs protected by PDCP) via the Transport Layer Security (TLS) handshake (from CU to DU). Another drawback is that TLS requires a Transport Control Protocol, which is absent in the F1-U (NR-U) transport stack specification. DTLS or TLS sessions (which are separate or unique for all DRBs between gNB-CU-UP and DU) would mean significant modifications to the gNB-CU-UP and DU stacks and implementations, which is unattractive to manufacturers.

[0101] Overall, these solutions will significantly impact performance on the F1-U interface, including gNB-CU-UP. Therefore, improved systems and methods for protection in 5Gv RAN are needed.

[0102] Systems and methods for selective user plane protection in fifth-generation (5G) virtual radio access networks (RANs) are provided. Figure 6 A method for communicating with a gNB distributed unit (gNB-DU) is illustrated, performed by the gNB central unit (gNB-CU). The method includes determining whether to selectively encrypt a Protocol Data Unit (PDU) to be sent to the gNB-DU if the PDU was not originally encrypted (step 600). In response to determining to selectively encrypt the PDU to be sent to the gNB-DU, the method includes encrypting the PDU to be sent to the gNB-DU (step 602). In response to determining not to selectively encrypt the PDU to be sent to the gNB-DU, the method includes transmitting the PDU to be sent to the gNB-DU (step 604). The method also includes transmitting the PDU to be sent to the gNB-DU (step 606). In this way, additional security is provided while minimizing performance impact. In some embodiments, this provides lower overhead on the gNB-CU-UP side compared to applying general protection to all PDUs. Furthermore, latency overhead is limited because secure session establishment and handshake are limited to the gNB-CU-UP–SEG domain, not gNB-CU-UP to gNB-DU. In some embodiments, the gNB-CU may optionally determine whether the PDU received from the gNB-DU is selectively encrypted (step 608). In response to determining that the received PDU is selectively encrypted, the gNB-CU decrypts the received PDU to be sent to the gNB-CU (step 610).

[0103] Figure 7 A method for facilitating communication between a gNB Distributed Unit (gNB-DU) and a gNB Central Unit (gNB-CU), performed by an Internet Protocol Security (IPsec) Security Gateway (SEG), is illustrated. The method includes: determining whether to selectively encrypt a PDU to be transmitted from the gNB-DU to the gNB-CU if the Protocol Data Unit (PDU) was originally not encrypted (step 700). In response to determining to selectively encrypt the PDU to be transmitted to the gNB-CU, the method includes encrypting the PDU to be transmitted to the gNB-CU (step 702). In response to determining not to selectively encrypt the PDU to be transmitted to the gNB-CU, the method includes transmitting the PDU to be transmitted to the gNB-CU (step 704). The method also includes transmitting the PDU to the gNB-CU (step 706). In some embodiments, the IPsec SEG optionally determines whether a PDU received from the gNB-CU is selectively encrypted (step 708). In response to determining that the received PDU was selectively encrypted, the IPsec SEG decrypts the received PDU to be sent to the gNB-DU (step 710).

[0104] about Figure 4 Furthermore, to facilitate understanding of some embodiments of this disclosure, gNB-CU-UP and SEG are considered as services within separate container Pods. Using Datagram Transport Layer Security (DTLS) as an example, combined with... Figure 8 and Figure 9 Further details are discussed. In some embodiments, using DTLS on the illustrated network segment does not replace the protocol stack with DTLS. Instead, these embodiments use a DTLS-like encryption scheme and payload format. In some embodiments, this allows the method to be independent of key exchange. For example, in some embodiments, it is assumed that the cryptographic material has already been shared.

[0105] In some embodiments, a multiplexer (MUX) microservice is instantiated in a gNB-CU-UP Pod to differentiate between PDCP-protected and non-PDCP-protected PDUs. The MUX can be viewed as a proxy for gNB-CU-UP services.

[0106] In some embodiments, in the downlink (DL), the MUX further protects the PDU identified as "to be protected" (i.e., PDUs not protected by PDCP by default) through encryption (e.g., DTLS). In some embodiments, in the uplink (UL), the MUX applies decryption to PDUs protected, for example, by DTLS.

[0107] In some embodiments, the MUX microservice is also instantiated in the SEG Pod to mirror the gNB-CU-UP MUX. In some embodiments, the SEG MUX represents another DTLS endpoint, and in the UL, the MUX applies DTLS protection to PDUs that are not protected by PDCP. In the DL, the MUX decrypts the PDUs encrypted using DTLS by the gNB-CU-UP MUX.

[0108] In some embodiments, F1-U (NR-U) is not terminated in the PDCP entity. F1-U is terminated in gNB-CU-UP and gNB-DU. Figure 8 and Figure 9 The F1-U is shown and extended to PDCP entities because the F1-U PDU (e.g., NR-U PDU) primarily carries PDCP data PDUs. More precisely, there are downlink / uplink NR PDCP PDUs. According to TS 38.425, for example in the downlink, when the "User Data Presence Flag" is set to 1, NR DL user data frames transmit PDCP PDUs (data or control).

[0109] In some embodiments, selectively protecting F1-UPDU payloads that are not protected by PDCP on the SEG–gNB-CU-UP network segment has the following advantages:

[0110] The performance impact of gNB-CU-UP is minimized: Given that most services are represented by PDCP data PDUs, our solution implies lower overhead on the gNB-CU-UP side compared to general protection applied to all PDCP PDUs via IPsec or (D)TLS from gNB-CU-UP to gNB-DU; and

[0111] Latency overhead is limited: secure session establishment and handshake are limited to the gNB-CU-UP–SEG domain, not gNB-CU-UP to gNB-DU.

[0112] Even when a PDU is lost or out of order, decryption can still be achieved using a DTLS scheme or similar system, meaning that the scheme allows for independent decryption of individual records.

[0113] Figure 4 and Figure 8 The image shows a common vRAN deployment. A major drawback of this security setup is that only a subset of NR-UPDUs carry PDCP-protected payloads (i.e., NR-U PDCP data PDUs).

[0114] As a non-limiting example, the following NR-U PDUs will not benefit from PDCP protection on the SEG–gNB-CU-UP network segment:

[0115] 1) NR-U PDU with "Type=0" and "User data presence flag=0" (in any direction);

[0116] 2) An NR-U PDU (in any direction) with "Type = 0" and "User Data Presence Flag = 1" and the PDCP PDU is a PDCP control PDU (i.e., D / C bit = 0 (i.e., PDCP control PDU)); and

[0117] 3) NR-U PDU of “Type=1” or “Type=2” (i.e., NR PDU of DL data transmission status and auxiliary information data type) (from gNB-DU to gNB-CU).

[0118] Figure 10 The F1-U transport layer (TS 38.474) is shown. In summary, on the "radio side," Figure 11 The gNB-CU-UP protocol stack for implementing PDCP and F1-U termination is shown.

[0119] Some embodiments of this disclosure focus on PDCP control of PDU protection. Some embodiments consider adding a protection (encryption) layer between the PDCP and NR-U layers on the gNB-CU-UP side (see [link]). Figure 11 ), which has a counterpart in SEG such that: only PDCP control PDUs are protected; and PDCP data PDUs are pass-through. In some embodiments, in Figure 9 This protection layer is implemented in the so-called Multiplexer (MUX) service. Its functions and operation are described in detail below.

[0120] In some embodiments, the MUX is a VNF and is implemented as an application to be delivered in vRAN packets. The MUX is ultimately instantiated within a container within the gNB-CU-UP and the IPsec SEG Pod (in... Figure 9 In some embodiments, this allows a secure (e.g., DTLS) session to be established between the gNB-CU-UP (client) site and the SEG (server) Pod. In some embodiments, this session establishment can be triggered when the first PDCP instance is created in gNB-CU-UP, on demand, when signaled from gNB-CU-CP, during the E1 or F1 setup process, or directly when a new gNB-CU-UP instance is created (see below for more details). In some embodiments, when gNB-CU-UP ( Figure 9When gNB-CU-CP expands, the entire Pod (i.e., the "ellipse") expands, including the MUX that accompanies it. In these embodiments, the Pod contains at least one of the following: two containers for the application (e.g., PDCP containers) and a container dedicated to communication between the application and the outside (i.e., the MUX). In some embodiments, when gNB-CU-CP expands, only the PDCP container is added without the corresponding MUX.

[0121] In some embodiments, this allows the reuse of the (DTLS) session's exporter value (i.e., similar to https: / / tools.ietf.org / html / rfc8446#section-7.5) to derive a symmetric session key for encryption and decryption, and the use of this key(s) in TRANF-1 and TRANF-2 (described below). In some embodiments, a session key exists for each direction, i.e., separate keys for UL and DL.

[0122] In addition, in some embodiments, the MUX acts as a proxy for traffic between the SEG and gNB-CU-UP.

[0123] Once a DTLS session is established, the MUX enforces the access control policy, which is the Authentication and Encryption (AEAD) of associated data on the PDCP control PDU. Therefore, the MUX acts as a pass-through mechanism for PDCP data PDUs that have already been encrypted by PDCP. The D / C bits of the PDCP data PDU are 1 (see...). Figure 12 ), while the D / C bit controlling the PDU is 0.

[0124] Given Figure 12 The PDCP control PDU format in this document (from Section 6.2.3 of TS 38.323v15.5.0) has D / C bits = 0 for the control PDU, and in some embodiments of this disclosure, the DTLS 1.3 header type is appropriate. Figure 13 The DTLS 1.3 ciphertext (header included) structure according to some embodiments of this disclosure is shown.

[0125] The first bit in the DTLS 1.3 header is also set to 0. MUX's main functions also include the following conversions:

[0126] 1)TRANSF-1: Converts plaintext PDCP control PDUs into ciphertext formatted to match DTLS 1.3 format by encryption.

[0127] TRANSF-2: Converts ciphertext, which is expected to be formatted as DTLS 1.3, into plaintext by decryption; it will be PDCPPDU control PDU.

[0128] In the downlink, the NR-U PDU proxied by the MUX undergoes a conversion (1) and / or a conversion (2) when / only when the NR-U header contains “type=0” and “user data presence flag=1” and the first bit of the payload (i.e., user data as a PDCP PDU) is set to 0.

[0129] The MUX agent is expected to format packets as NR-U PDUs. In some embodiments, the MUX operates on downlink data as follows:

[0130] At the gNB-CU-UP site: If the NR-U PDU has "Type=0" and "User Data Presence Flag=1" and the first bit of the payload (User PDCP PDU) is set to 0 (i.e., the PDCP PDU is a PDCP control PDU with D / C bit=0), then: apply TRANSF-1 and use the formatted as follows Figure 13 The resulting encrypted text replaces the PDCP PDU (corresponding to the "User Data Presence Flag") in the initial NR-U PDU. Then the NR-U PDU is forwarded.

[0131] If the PDU does not meet this requirement, then forward the NR-U PDU (pass-through).

[0132] At the SEG site: If the NR-U PDU has "Type=0" and "User Data Presence Flag=1" and the first bit of the NR-U payload is set to 0, then: apply TRANSF-2 to derive the plaintext of the PDCP PDU representing D / C bit=0, and replace the NR-U payload (corresponding to "User Data Presence Flag") with the obtained plaintext. Then forward the NR-UPDU.

[0133] If the PDU does not meet this requirement, then forward the NR-U PDU (pass-through).

[0134] Uplink operations mirror downlink operations. At the SEG site: If the NR-U PDU has "Type=0" and "User Data Presence Flag=1" and the first bit of the payload (User PDCP PDU) is set to 0 (i.e., the PDCP PDU is a PDCP control PDU with D / C bit=0), then: apply TRANSF-1 and use the formatted as follows Figure 13 The resulting encrypted text replaces the PDCP PDU (corresponding to the "User Data Presence Flag") in the initial NR-U PDU. Then the NR-U PDU is forwarded.

[0135] If the PDU does not meet this requirement, then forward the NR-U PDU (pass-through).

[0136] At the gNB-CU-UP site: If the NR-U PDU has "Type=0" and "User Data Presence Flag=1" and the first bit of the NR-U payload is set to 0, then: apply TRANSF-2 to derive the plaintext of the PDCPPDU representing D / C bit=0, and replace the NR-U payload (corresponding to "User Data Presence Flag") with the obtained plaintext. Then forward the NR-U PDU.

[0137] If the PDU does not meet this requirement, then forward the NR-U PDU (pass-through).

[0138] In some embodiments, as a service related to gNB-CU-UP and SEG operations, MUX instantiation and setup are completed before any F1-U / NR-U PDU carrying user (UE) data. Instantiating the MUX service on a gNB-CU-UP and / or SEG site (e.g., a Pod) means first handshaking with the DTLS session to derive the exporter value. A typical setup for MUX instantiation can be as follows:

[0139] 1) Triggered reception (e.g., gNB-CU-UP instantiation, F1 setup process, E1 setup process, etc.);

[0140] 2) MUX service discovery (between gNB-CU-UP and SEG). This can rely on service registration technologies, dedicated service discovery components, IPv6 mechanisms, etc.

[0141] 3) Perform a DTLS handshake between gNB-CU-UP MUX and SEG MUX to derive the exporter value as input to the symmetric session key required to derive the aforementioned TRANSF-1 and TRANSF-2.

[0142] Some advantages and performance gains resulting from embodiments of this disclosure include one or more of the following: reuse of standard PDU formats; limiting overhead, latency (new operations ultimately occur only between gNB-CU-UP and SEG) and resources (selectively processing only NR-U payloads identified by a simple lookup of the same bits); establishing a unique DTLS 1.3 session with an exporter for all DRBs (instead of a separate one for each bearer); and ease of implementation (we anticipate that our scheme can be readily adopted or implemented in container technologies such as service mesh, where the service mesh broker can be enhanced by first parameterizing the header inspection filter with the role of the MUX).

[0143] Figure 14An example of a cellular communication system 1400 that can implement embodiments of the present disclosure is shown. In the embodiments described herein, the cellular communication system 1400 is a 5G system (5GS) including an NR RAN. In this example, the RAN includes base stations 1402-1 and 1402-2, referred to as gNBs in the 5G NR (e.g., LTE RAN nodes connected to the 5G core (5GC), referred to as gn-eNBs), which control corresponding (macro)cells 1404-1 and 1404-2. Base stations 1402-1 and 1402-2 are generally referred to herein as base station 1402, and are referred to as base station 1402, respectively. Similarly, macro cells 1404-1 and 1404-2 are generally referred to herein as macro cell 1404, and are referred to as macro cell 1404, respectively. The RAN may also include a plurality of low-power nodes 1406-1 to 1406-4 that control corresponding small cells 1408-1 to 1408-4. Low-power nodes 1406-1 to 1406-4 may be small base stations (e.g., pico or femto base stations) or remote radio head ends (RRHs), etc. It is worth noting that, although not shown, one or more small cells 1408-1 to 1408-4 may alternatively be provided by base station 1402. Low-power nodes 1406-1 to 1406-4 are generally referred to herein as low-power node 1406, and are specifically referred to as low-power node 1406. Similarly, small cells 1408-1 to 1408-4 are generally referred to herein as small cell 1408, and are specifically referred to as small cell 1408. Cellular communication system 1400 also includes a core network 1410, which is referred to as the 5G core (5GC) in 5GS. Base station 1402 (and optionally low-power node 1406) is connected to core network 1410.

[0144] Base station 1402 and low-power node 1406 provide services to wireless communication devices 1412-1 to 1412-5 in corresponding cells 1404 and 1408. Wireless communication devices 1412-1 to 1412-5 are generally referred to herein as wireless communication device 1412, and are referred to individually as wireless communication device 1412. In the following description, wireless communication device 1412 is generally referred to as a UE, but this disclosure is not limited thereto.

[0145] Figure 15This is a schematic block diagram of a radio access node 1500 according to some embodiments of the present disclosure. Optional features are indicated by dashed boxes. The radio access node 1500 may be, for example, a base station 1402 or 1406, or a network node implementing all or part of the functions of the base station 1402 or gNB described herein. As shown, the radio access node 1500 includes a control system 1502, which includes one or more processors 1504 (e.g., a central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), etc.), a memory 1506, and a network interface 1508. The one or more processors 1504 are also referred to herein as processing circuitry. Furthermore, the radio access node 1500 may include one or more radio units 1510, each radio unit 1510 including one or more transmitters 1512 and one or more receivers 1514 coupled to one or more antennas 1516. The radio unit 1510 may be referred to as radio interface circuitry or part of radio interface circuitry. In some embodiments, the radio unit 1510 is external to the control system 1502 and connected to the control system 1502 via, for example, a wired connection (e.g., fiber optic cable). However, in some other embodiments, the radio unit 1510 and possibly an antenna 1516 are integrated with the control system 1502. One or more processors 1504 are used to provide one or more functions of the radio access node 1500 as described herein. In some embodiments, these functions are implemented as software, for example, stored in memory 1506 and executed by one or more processors 1504.

[0146] Figure 16 This is a schematic block diagram illustrating a virtualized embodiment of a radio access node 1500 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Furthermore, other types of network nodes may have similar virtualization architectures. Similarly, optional features are indicated by dashed boxes.

[0147] As used herein, a “virtualized” radio access node is an implementation of radio access node 1500 in which at least a portion of the functionality of radio access node 1500 is implemented as a virtual component (e.g., via a virtual machine executed on a physical processing node in a network). As illustrated, in this example, radio access node 1500 may include a control system 1502 and / or one or more radio units 1510, as described above. Control system 1502 may be connected to radio unit 1510 via, for example, fiber optic cable. Radio access node 1500 includes one or more processing nodes 1600, which are coupled to or included in network 1602 as part of network 1602. If present, control system 1502 or radio units are connected to processing node 1600 via network 1602. Each processing node 1600 includes one or more processors 1604 (e.g., CPU, ASIC, FPGA, etc.), memory 1606, and network interface 1608.

[0148] In this example, the functionality 1610 of the radio access node 1500 described herein is implemented at one or more processing nodes 1600, or distributed in any desired manner across one or more processing nodes 1600 and control system 1502 and / or radio unit 1510. In some specific embodiments, some or all of the functionality 1610 of the radio access node 1500 described herein is implemented as virtual components executed by one or more virtual machines implemented in a virtual environment hosted by processing node 1600. As those skilled in the art will recognize, additional signaling or communication between processing node 1600 and control system 1502 is used to perform at least some of the desired functionality 1610. It is noteworthy that in some embodiments, control system 1502 may be omitted, in which case radio unit 1510 communicates directly with processing node 1600 via a suitable network interface.

[0149] In some embodiments, a computer program including instructions is provided that, when executed by at least one processor, causes at least one processor to perform the functions of radio access node 1500 or a node (e.g., processing node 1600) in a virtual environment implementing the functions 1610 of radio access node 1500 according to any embodiment described herein. In some embodiments, a carrier including the above-described computer program product is provided. The carrier is one of electronic signals, optical signals, radio signals, or computer-readable storage media (e.g., a non-transitory computer-readable medium such as a memory).

[0150] Figure 17This is a schematic block diagram of a radio access node 1500 according to some other embodiments of the present disclosure. The radio access node 1500 includes one or more modules 1700, each of which is implemented in software. The one or more modules 1700 provide the functionality of the radio access node 1500 described herein. This discussion also applies to... Figure 16 The processing node 1600, wherein the module 1700 may be implemented at one of the processing nodes 1600 or distributed across multiple processing nodes 1600 and / or distributed across the processing node 1600 and the control system 1502.

[0151] Figure 18 This is a schematic block diagram of a wireless communication device 1800 according to some embodiments of the present disclosure. As shown, the wireless communication device 1800 includes one or more processors 1802 (e.g., CPU, ASIC, FPGA, etc.), a memory 1804, and one or more transceivers 1806. Each transceiver 1806 includes one or more transmitters 1808 and one or more receivers 1810 coupled to one or more antennas 1812. As those skilled in the art will understand, the transceiver 1806 includes radio front-end circuitry connected to the antenna 1812, which is configured to modulate signals transmitted between the antenna 1812 and the processor 1802. The processor 1802 is also referred to herein as processing circuitry. The transceiver 1806 is also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 1800 described above may be implemented entirely or partially in software, for example, stored in the memory 1804 and executed by the processor 1802. Note that the wireless communication device 1800 may include... Figure 18 Additional components not shown, such as one or more user interface components (e.g., input / output interfaces including displays, buttons, touch screens, microphones, speakers, etc., and / or any other components that allow information to be input to and / or output from the wireless communication device 1800), power supplies (e.g., batteries and associated power circuitry), etc.

[0152] In some embodiments, a computer program including instructions is provided that, when executed by at least one processor, causes the at least one processor to perform the functions of a wireless communication device 1800 according to any embodiment described herein. In some embodiments, a carrier including the computer program product described above is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).

[0153] Figure 19This is a schematic block diagram of a wireless communication device 1800 according to some other embodiments of the present disclosure. The wireless communication device 1800 includes one or more modules 1900, each of which is implemented in software. The one or more modules 1900 provide the functionality of the wireless communication device 1800 described herein.

[0154] refer to Figure 20 According to an embodiment, the communication system includes a telecommunications network 2000 (e.g., a 3GPP-type cellular network), which includes an access network 2002 (e.g., a RAN) and a core network 2004. The access network 2002 includes multiple base stations 2006A, 2006B, and 2006C (e.g., Node B, eNB, gNB, or other types of radio access points (APs)), each defining a corresponding coverage area 2008A, 2008B, or 2008C. Each base station 2006A, 2006B, or 2006C can be connected to the core network 2004 via a wired or wireless connection 2010. A first UE 2012 located in coverage area 2008C is configured to wirelessly connect to or be paged by the corresponding base station 2006C. A second UE 2014 located in coverage area 2008A can wirelessly connect to the corresponding base station 2006A. Although multiple UEs 2012 and 2014 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is in the coverage area or a single UE is connected to the corresponding base station 2006.

[0155] Telecommunication network 2000 is connected to host computer 2016, which may be implemented as a standalone server, a cloud-based server, a distributed server, or as a processing resource in a server cluster. Host computer 2016 may be owned or controlled by a service provider, or may be operated by or on behalf of the service provider. Connections 2018 and 2020 between telecommunications network 2000 and host computer 2016 may extend directly from core network 2004 to host computer 2016, or may be made via an optional intermediate network 2022. Intermediate network 2022 may be one or more of public, private, or bearer networks; intermediate network 2022 (if present) may be a backbone network or the Internet; specifically, intermediate network 2022 may include two or more subnetworks (not shown).

[0156] Figure 20The communication system as a whole implements the connection between the connected UEs 2012 and 2014 and the host computer 2016. This connection can be described as an over-the-top (OTT) connection 2024. The host computer 2016 and the connected UEs 2012 and 2014 are configured to transmit data and / or signaling via the OTT connection 2024 using the access network 2002, core network 2004, any intermediate network 2022, and possibly other infrastructure (not shown) as intermediaries. The OTT connection 2024 can be transparent in the sense that the participating communication devices traversing the OTT connection 2024 are unaware of the routing of uplink and downlink communications. For example, it may not be necessary to notify the base station 2006 of the past routes of input downlink communications with data originating from the host computer 2016 to be forwarded (e.g., handed over) to the connected UE 2012. Similarly, base station 2006 does not need to be aware of future routes for uplink communication originating from UE 2012 to host computer 2016.

[0157] Reference Figure 21 This section describes example implementations of the UE, base station, and host computer discussed in the preceding paragraphs according to embodiments. In the communication system 2100, the host computer 2102 includes hardware 2104, which includes a communication interface 2106 configured to establish and maintain wired or wireless connections with interfaces of different communication devices of the communication system 2100. The host computer 2102 also includes processing circuitry 2108, which may have storage and / or processing capabilities. Specifically, the processing circuitry 2108 may include one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) suitable for executing instructions. The host computer 2102 also includes software 2110, which is stored in or accessible by the host computer 2102 and executable by the processing circuitry 2108. The software 2110 includes a host application 2112. Host application 2112 is operable to provide services to a remote user (e.g., UE 2114), which is connected via an OTT connection 2116 terminated at UE 2114 and host computer 2102. When providing services to the remote user, host application 2112 can provide user data sent using OTT connection 2116.

[0158] The communication system 2100 also includes a base station 2118 provided in the telecommunications system. The base station 2118 includes hardware 2120 enabling it to communicate with the host computer 2102 and the UE 2114. Hardware 2120 may include: a communication interface 2122 for establishing and maintaining wired or wireless connections with different communication devices of the communication system 2100; and a radio interface 2124 for establishing and maintaining connections with at least the coverage area served by the base station 2118. Figure 21 The wireless connection 2126 of UE2114 (not shown in the image) is used. Communication interface 2122 can be configured to facilitate connection 2128 to host computer 2102. Connection 2128 can be direct, or it can pass through the core network of the telecommunications system (…). Figure 21 (not shown) and / or via one or more intermediate networks outside the telecommunications system. In the illustrated embodiment, the hardware 2120 of base station 2118 also includes processing circuitry 2130, which may include one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) suitable for executing instructions. Base station 2118 also has software 2132 stored internally or accessible via an external connection.

[0159] The communication system 2100 also includes the previously mentioned UE 2114. The hardware 2134 of UE 2114 may include a radio interface 2136 configured to establish and maintain a wireless connection 2126 with a base station serving the coverage area currently occupied by UE 2114. The hardware 2134 of UE 2114 also includes processing circuitry 2138, which may include one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) suitable for executing instructions. UE 2114 also includes software 2140, which is stored in or accessible by UE 2114 and executable by processing circuitry 2138. Software 2140 includes a client application 2142. Client application 2142 is operable to provide services to human or non-human users via UE 2114 with the support of host computer 2102. In host computer 2102, the executing host application 2112 can communicate with the executing client application 2142 via an OTT connection 2116 terminated at UE 2114 and host computer 2102. When providing services to a user, client application 2142 can receive request data from host application 2112 and provide user data in response to the request data. OTT connection 2116 can transmit both request data and user data. Client application 2142 can interact with the user to generate the user data it provides.

[0160] Notice, Figure 21 The host computer 2102, base station 2118, and UE 2114 shown can be respectively connected to Figure 20 The host computer 2016, base station 2006A, 2006B, 2006C, and UE 2012, 2014 are similar or identical. That is to say, the internal workings of these entities can be as follows: Figure 21 As shown, and independently, the surrounding network topology can be Figure 20 The network topology.

[0161] exist Figure 21 The OTT connection 2116 has been abstractly depicted to illustrate communication between host computer 2102 and UE 2114 via base station 2118, without explicitly mentioning any intermediate devices or the precise routing of messages via these devices. The network infrastructure can determine this route, which can be configured to be hidden from UE 2114, from the service provider operating host computer 2102, or from both. While OTT connection 2116 is active, the network infrastructure can also make decisions to dynamically change the route (e.g., based on load balancing considerations or network reconfiguration).

[0162] The wireless connection 2126 between UE 2114 and base station 2118 is based on the teachings of the embodiments described throughout this disclosure. One or more embodiments in the various embodiments improve the performance of OTT services provided to UE 2114 using OTT connection 2116, wherein wireless connection 2126 forms the final segment of OTT connection 2116. More precisely, the teachings of these embodiments can improve, for example, security, and thus provide benefits such as reduced user wait time, more lenient file size limits, better responsiveness, extended battery life, etc.

[0163] For the purpose of monitoring data rates, latency, and other factors improved in one or more embodiments, a measurement process may be provided. Optional network functions may also be available for reconfiguring the OTT connection 2116 between the host computer 2102 and the UE 2114 in response to changes in measurement results. The measurement process and / or network functions for reconfiguring the OTT connection 2116 may be implemented using software 2110 and hardware 2104 of the host computer 2102, or software 2140 and hardware 2134 of the UE 2114, or both. In some embodiments, a sensor (not shown) may be deployed in or associated with a communication device through which the OTT connection 2116 passes; the sensor may participate in the measurement process by providing values ​​of the monitored quantities illustrated above or by providing values ​​of other physical quantities that the software 2110, 2140 may use to calculate or estimate the monitored quantities. Reconfiguration of OTT connection 2116 may include message formatting, retransmission settings, preferred routing, etc.; this reconfiguration does not need to affect base station 2118, and it may be unknown or imperceptible to base station 2118. Such processes and functions may be known and practiced in the art. In a particular embodiment, measurement may involve proprietary UE signaling that facilitates host computer 2102 in measuring throughput, propagation time, latency, etc. This measurement may be implemented as follows: software 2110 and 2140 enable the use of OTT connection 2116 to send messages (specifically, empty messages or "fake" messages) while monitoring propagation time, errors, etc.

[0164] Figure 22 This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be a reference... Figure 20 and Figure 21 The host computer, base station, and UE are described. For the sake of brevity, this section will only include descriptions of... Figure 22 The diagram is referenced. In step 2200, the host computer provides user data. In sub-step 2202 of step 2200 (which may be optional), the host computer provides user data by executing a host application. In step 2204, the host computer initiates a transmission carrying user data to the UE. In step 2206 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station sends the user data carried in the transmission initiated by the host computer to the UE. In step 2208 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0165] Figure 23This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be a reference... Figure 20 and Figure 21 The host computer, base station, and UE are described. For the sake of brevity, this section will only include descriptions of... Figure 23 The diagram is referenced. In step 2300 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides user data by executing a host application. In step 2302, the host computer initiates a transmission carrying user data to the UE. According to the teachings of the embodiments described throughout this disclosure, this transmission may be via a base station. In step 2304 (which may be optional), the UE receives the user data carried in the transmission.

[0166] Figure 24 This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be a reference... Figure 20 and Figure 21 The host computer, base station, and UE are described. For the sake of brevity, this section will only include descriptions of... Figure 24 The diagram is referenced. In step 2400 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 2402 (which may be optional), the UE provides user data. In sub-step 2404 of step 2400 (which may be optional), the UE provides user data by executing a client application. In sub-step 2406 of step 2402 (which may be optional), the UE executes a client application that provides user data in response to the received input data provided by the host computer. When providing user data, the executed client application may also consider user input received from the user. Regardless of the specific manner in which user data is provided, the UE initiates the transmission of user data to the host computer in sub-step 2408 (which may be optional). In step 2410 of the method, the host computer receives user data sent from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

[0167] Figure 25 This is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be a reference... Figure 20 and Figure 21 The host computer, base station, and UE are described. For the sake of brevity, this section will only include descriptions of... Figure 25The diagram is referenced. In step 2500 (which may be optional), the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout this disclosure. In step 2502 (which may be optional), the base station initiates a transmission of the received user data to the host computer. In step 2504 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0168] Any suitable steps, methods, features, functions, or benefits disclosed herein can be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include multiple such functional units. These functional units may be implemented by processing circuitry, which may include one or more microprocessors or microcontrollers and other digital hardware (including DSPs, application-specific digital logic, etc.). The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as ROM, RAM, cache memory, flash memory, optical storage devices, etc. The program code stored in memory includes program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more techniques described herein. In some implementations, the processing circuitry may be used to cause corresponding functional units to perform corresponding functions according to one or an embodiment of this disclosure.

[0169] While the processes in the accompanying drawings illustrate a particular sequence of operations performed in certain embodiments of this disclosure, it should be understood that such sequence is exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.).

[0170] At least some of the following abbreviations may be used in this disclosure. In the event of inconsistencies between abbreviations, the usage above shall prevail. If listed multiple times below, the first listing shall take precedence over any subsequent listing.

[0171] ·3GPP Third Generation Partnership Program

[0172] ·3PP Third-Party Platform

[0173] 5G (Fifth Generation)

[0174] ·5GC fifth-generation core

[0175] ·5GS Fifth Generation System

[0176] • Authentication and encryption of AEAD-related data

[0177] ·AF Application Functions

[0178] • AMF Access and Mobility Functions

[0179] ·AN Access Network

[0180] AP access point

[0181] Application-Specific Integrated Circuits (ASICs)

[0182] • AUSF Authentication Server Functionality

[0183] ·BCCH Broadcast Control Channel

[0184] BSC (Base Station Controller)

[0185] BTS base station transceiver station

[0186] ·CAPEX (Capital Expenditure)

[0187] CPU (Central Processing Unit)

[0188] DL downlink

[0189] DN Data Network

[0190] ·DRB Data Radio Bearer

[0191] DSP (Digital Signal Processor)

[0192] • DTLS (Datagram Transport Layer Security)

[0193] • eNB Enhanced or Evolved Node B

[0194] • ESP encapsulates safe payload

[0195] FPGA (Field Programmable Gate Array)

[0196] ·Ghz

[0197] gNB New Radio Base Station

[0198] gNB-CU New Radio Base Station Central Unit

[0199] gNB-CU-CP New Radio Base Station Central Unit Control Plane

[0200] gNB-CU-UP New Radio Base Station Central Unit User Plane

[0201] gNB-DU New Radio Base Station Distributed Unit

[0202] GPRS (General Packet Radio Service)

[0203] GSM Global System for Mobile Communications

[0204] GTP-U GPRS Tunneling Protocol

[0205] HSS Home Subscriber Service

[0206] IoT (Internet of Things)

[0207] IP Internet Protocol

[0208] • IPsec Internet Protocol Security

[0209] LTE Long Term Evolution

[0210] • MME (Mobility Management Entity)

[0211] • MTC Machine Type Communication

[0212] MUX multiplexer

[0213] NDS Network Domain Security

[0214] • NEF Network Exposure Function

[0215] NF Network Functions

[0216] NR New Radio

[0217] • NRF Network Functions Repository Functionality

[0218] NSSF Network Slice Selection Function

[0219] ·OPEX operating expenses

[0220] • OTT over-the-top

[0221] PC (Personal Computer)

[0222] PCCH (Physical Control Channel)

[0223] PCF policy control function

[0224] PDCP (Packet Data Convergence Protocol)

[0225] PDU (Protocol Data Unit)

[0226] P-GW Packet Data Network Gateway

[0227] • PNF (Physical Network Function)

[0228] QoS (Quality of Service)

[0229] RAM (Random Access Memory)

[0230] RAN (Radio Access Network)

[0231] • RAT Radio Access Technology

[0232] RF (Radio Frequency)

[0233] • RLC Radio Link Control

[0234] • RNC Radio Network Controller

[0235] ROHC Robust Header Compression

[0236] ROM (Read-Only Memory)

[0237] • RRC Radio Resource Control

[0238] ·RRH Remote Radio Header Terminal

[0239] • RRU (Remote Radio Unit)

[0240] ·RTT Round Trip Time

[0241] • SCEF service capability exposure function

[0242] •SCTP Stream Control Transmission Protocol

[0243] SEG Security Gateway

[0244] • SMF Session Management Function

[0245] TEID (Tunnel Endpoint ID)

[0246] TLS transport layer security

[0247] UDM (Unified Data Management)

[0248] UE (User Equipment)

[0249] USB Universal Serial Bus

[0250] • VNF (Virtual Network Function)

[0251] vRAN (Virtual Radio Access Network)

[0252] VoIP (Voice over Internet Protocol)

[0253] WCDMA (Wideband Code Division Multiple Access)

[0254] WiMAX Global Microwave Access Interoperability

[0255] Those skilled in the art will recognize improvements and modifications to the embodiments of this disclosure. All such improvements and modifications are considered to fall within the scope of the concept disclosed herein.

Claims

1. A method for communicating with a gNB distributed unit (gNB-DU) executed by a gNB central unit (gNB-CU), the method comprising: If the protocol data unit (PDU) to be sent to the gNB-DU was not originally encrypted, then determine whether to selectively encrypt the PDU; In response to determining that the PDU to be sent to the gNB-DU is to be selectively encrypted, the PDU to be sent to the gNB-DU is encrypted; In response to determining that the PDU to be sent to the gNB-DU is to be encrypted non-selectively, the PDU to be sent to the gNB-DU is transmitted. Send the PDU to be sent to the gNB-DU. Sending the PDU to be sent to the gNB-DU includes: The PDU is sent to the Internet Protocol Security (IPsec) Security Gateway (SEG) for transmission to the gNB-DU, and The secure session is established between the gNB-CU and the Internet Protocol Security (IPsec) Security Gateway (SEG).

2. The method according to claim 1, wherein: The gNB-CU includes a first multiplexer MUX, and; Sending the PDU to the Internet Protocol Security (IPsec) gateway SEG includes sending the PDU from the first multiplexer (MUX) to a second MUX in the IPsec gateway SEG.

3. The method according to claim 1, wherein: Determining whether to selectively encrypt the PDU to be sent to the gNB-DU includes: determining to selectively encrypt the PDU if one or more of the following groups are true: - The PDU includes "Type=0" and "User data presence flag=0"; and - The PDU includes: "Type=0", "User data presence flag=1", and the PDU is a Packet Data Convergence Protocol (PDCP) control PDU.

4. The method according to claim 2, wherein: Determine whether the PDU received from the gNB-DU is selectively encrypted; In response to determining that the received PDU is selectively encrypted, the received PDU to be sent to the gNB-CU is decrypted.

5. The method according to claim 4, wherein, The received PDU is received from the Internet Protocol Security (IPsec) Security Gateway (SEG).

6. The method according to claim 5, wherein: Receiving PDUs from the Internet Protocol Security (IPsec) Security Gateway (SEG) includes receiving PDUs from the second MUX in the SEG by the first multiplexer MUX.

7. The method according to claim 1, wherein, The security session between the gNB-CU and the Internet Protocol Security (IPsec) Security Gateway (SEG) is established when one of the following occurs: The first PDCP instance created in the gNB-CU; When a signal is sent from the gNB-CU; When establishing interface E1 between the gNB-CU user plane gNB-CU-UP and the gNB-CU control plane gNB-CU-CP; When establishing interface F1 between the gNB-CU and the gNB-DU; and When creating the gNB-CU-UP.

8. The method according to claim 1, wherein, Encrypting the PDU to be sent to the gNB-DU includes encrypting the PDU using a symmetric encryption key.

9. The method according to claim 4, wherein, The PDU is encrypted using a first encryption key, and the received PDU is decrypted using a second encryption key, wherein the first encryption key is different from the second encryption key.

10. The method according to claim 2, wherein, The gNB-CU operates in the first container.

11. The method according to claim 10, wherein, The first multiplexer MUX operates within the first container.

12. The method according to claim 11, wherein: The first multiplexer MUX operates in the second container; and The first container and the second container operate within the same pod.

13. A method for facilitating communication between a gNB-DU (gNB Distributed Unit) and a gNB-CU (gNB Central Unit), performed by an Internet Protocol Security (IPsec) Security Gateway (SEG), the method comprising: If the protocol data unit (PDU) to be sent from the gNB-DU to the gNB-CU was not originally encrypted, then determine whether to selectively encrypt the PDU; In response to determining that the PDU to be sent to the gNB-CU is to be selectively encrypted, the PDU to be sent to the gNB-CU is encrypted; In response to determining that the PDU to be sent to the gNB-CU is to be encrypted non-selectively, the PDU to be sent to the gNB-CU is transmitted. as well as Send the PDU to the gNB-CU The secure session is established between the gNB-CU and the Internet Protocol Security (IPsec) Security Gateway (SEG).

14. The method of claim 13, wherein: The Internet Protocol Security (IPsec) Security Gateway (SEG) includes a first multiplexer (MUX), and; Sending the PDU to the gNB-CU includes: sending the PDU from the first multiplexer MUX to the second MUX in the gNB-CU.

15. The method according to claim 13, wherein: Determining whether to selectively encrypt the PDU to be sent to the gNB-CU includes: determining to selectively encrypt the PDU if one or more of the following groups are true: - The PDU is a Radio Link Control (RLC) to Packet Data Convergence Protocol (PDCP) Indicator; - The PDU includes "Type=0" and "User data presence flag=0"; The PDU includes: "Type=0", "User data presence flag=1", and the PDU is a PDCP control PDU; - The PDU is a PDCP control PDU; - The PDU is a downlink DL data transmission status indicator; and - The PDU is an auxiliary information data indicator.

16. The method of claim 14, wherein: Determine whether the PDU received from the gNB-CU is selectively encrypted; In response to determining that the received PDU is selectively encrypted, the received PDU to be sent to the gNB-DU is decrypted.

17. The method of claim 16, wherein: Receiving a received PDU from the gNB-CU includes: receiving the received PDU from the second MUX in the gNB-CU by the first multiplexer MUX.

18. The method according to claim 13, wherein, The security session between the gNB-CU and the Internet Protocol Security (IPsec) Security Gateway (SEG) is established when one of the following occurs: The first PDCP instance created in the gNB-CU; When a signal is sent from the gNB-CU; When establishing interface E1 between the gNB-CU user plane gNB-CU-UP and the gNB-CU control plane gNB-CU-CP; When establishing interface F1 between the gNB-CU and the gNB-DU; and When creating the gNB-CU-UP.

19. The method according to claim 13, wherein, Encrypting the PDU to be sent to the gNB-CU includes encrypting the PDU using a symmetric encryption key.

20. The method of claim 16, wherein, The PDU is encrypted using a first encryption key, and the received PDU is decrypted using a second encryption key, wherein the first encryption key is different from the second encryption key.

21. The method according to claim 14, wherein, The Internet Protocol Security (IPsec) Security Gateway (SEG) operates within the first container.

22. The method according to claim 21, wherein, The first multiplexer MUX operates within the first container.

23. The method according to claim 21, wherein: The first multiplexer MUX operates in the second container; and The first container and the second container operate within the same pod.

24. A processing node (1600) for implementing a gNB central unit (gNB-CU) for communication with a gNB distributed unit (gNB-DU), the processing node (1600) comprising: One or more processors (1604); as well as Memory (1606), including instructions that cause the processing node (1600): If the protocol data unit (PDU) to be sent to the gNB-DU was not originally encrypted, then determine whether to selectively encrypt the PDU; In response to determining that the PDU to be sent to the gNB-DU is to be selectively encrypted, the PDU to be sent to the gNB-DU is encrypted; In response to determining that the PDU to be sent to the gNB-DU is to be encrypted non-selectively, the PDU to be sent to the gNB-DU is transmitted. Send the PDU to be sent to the gNB-DU. Sending the PDU to be sent to the gNB-DU includes: The PDU is sent to the Internet Protocol Security (IPsec) Security Gateway (SEG) for transmission to the gNB-DU, and The secure session is established between the gNB-CU and the Internet Protocol Security (IPsec) Security Gateway (SEG).

25. The processing node (1600) according to claim 24, wherein, The instructions also cause the processing node (1600) to perform the method according to any one of claims 2 to 12.

26. A processing node (1600) for implementing an Internet Protocol Security (IPsec) Security Gateway (SEG) to facilitate communication between a gNB Distributed Unit (gNB-DU) and a gNB Central Unit (gNB-CU), the processing node (1600) comprising: One or more processors (1604); and Memory (1606), including instructions that cause the processing node (1600): If the protocol data unit (PDU) to be sent from the gNB-DU to the gNB-CU was not originally encrypted, then determine whether to selectively encrypt the PDU; In response to determining that the PDU to be sent to the gNB-CU is to be selectively encrypted, the PDU to be sent to the gNB-CU is encrypted; In response to determining that the PDU to be sent to the gNB-CU is to be encrypted non-selectively, the PDU to be sent to the gNB-CU is transmitted. as well as Send the PDU to the gNB-CU The secure session is established between the gNB-CU and the Internet Protocol Security (IPsec) Security Gateway (SEG).

27. The processing node (1600) according to claim 26, wherein, The instructions also cause the processing node (1600) to perform the method according to any one of claims 14 to 23.

Images