Method for Enhancing Privacy in Access Networks

Abstract

A method for enhancing privacy in an access network is provided. The method for enhancing privacy in an access network (AN) includes an AN component and an AN intelligent controller (AN-IC), the AN component including an interface node, the AN-IC including an AN-IC application configured to request and subscribe to AN parameters from the interface node, a matching request or a policy element including a behavior to be applied to the associated AN parameters, the AN-IC and the interface node, the AN-IC configured to match the policy element to the matching request, the method including the steps of sending a request for the AN parameters to the interface node, receiving an interface node message from the interface node, receiving a further request for the AN parameters from the AN-IC application, and matching the further request to the policy element.

Description

[Technical Field]

[0001] The present invention relates to a method for enhancing privacy in an access network and an access network therefor. [Background technology]

[0002] The current 5G system model is shown in Figure 1. As shown in Figure 1, the current model divides a mobile network into two main parts: an access network (AN) and a core network (CN). The purpose of the model is to provide a UE with connectivity to a data network (DN). More specifically, a UE communicates with the AN via an interface used to carry both signaling information and data traffic. For example, the AN may be a radio access network (RAN) with an air interface.

[0003] Currently, 3GPP standards define the RAN as consisting of a set of gNBs, which can be considered as either a single monolithic entity or a set of functional entities. Figure 2 shows the overall RAN architecture according to 3GPP TS38.401. Further divisions are also defined by 3GPP, such as separation between the control plane and the user plane for the control unit (CU) and / or distributed unit (DU).

[0004] The current state of the art for open RAN systems is based on the O-RAN Alliance specifications, which specify a top-level construction of the 3GPP architecture and interfaces and aim to further define interfaces and functional entities. The disaggregated RAN architecture based on CU / DU separation from 3GPP is the basis for the RAN architecture from the O-RAN Alliance specifications.

[0005] In addition to the interfaces defined by 3GPP, the O-RAN specifications define additional interfaces, the most well-known of which is the Open Fronthaul (Open FH), which allows interoperability between different DU and Radio Unit (RU) vendors.

[0006] One of the key aspects of the O-RAN architecture is the availability of a new function named non-real-time and near-real-time RAN Intelligent Controller (RIC). In particular, the O-RAN architecture supports additional control loops that can be plugged into the logic tasked with steering RAN functions. Non-RT (non-real-time) control loop: via the O1 interface between the SMO and O-RAN components. The SMO hosts the non-RT RIC. Quasi-RT (near real-time) control loop: via the E2 interface between the Quasi-RT RIC and O-RAN components.

[0007] The real-time (RT) control loop does not include an open interface according to the current O-RAN specification. In both the quasi-RT and non-RT RIC cases, additional logic is plugged into the system by "Apps." In particular, the term "xApps" is used in the quasi-RT case and "rApps" in the non-RT case.

[0008] Figure 3 shows an example of an O-RAN architecture. As shown in Figure 3, solid lines indicate O-RAN interfaces and dashed lines indicate 3GPP interfaces. Furthermore, circle "1" indicates a non-real-time control loop, circle "2" indicates a quasi-real-time control loop, and circle "3" indicates a real-time control loop. Typical scope of these loops is as follows: Non-RT control loop ≥ 1s 10ms≦Quasi-RT control loop<1s RT control loop <10ms

[0009] The goal of the non-RT RIC is to support intelligent RAN optimization by providing policy-based guidance, machine learning (ML) model management, and enhancement information to the quasi-RT RIC function so that the RAN can, for example, optimize RRM under certain conditions. It can also perform intelligent radio resource management functions in non-real-time intervals (i.e., longer than 1 second, such as turning off cells for energy savings). The non-RT RIC includes two sub-functions: Non-RT RIC Framework: A facility within the SMO framework that logically terminates the A1 interface and exposes the required services to rApps through that R1 interface. Non-RT RIC Application (rApp): A modular application that leverages the functionality exposed by the non-RT RIC framework to perform RAN optimization and other functions. Services exposed to the rApp through the R1 interface allow the rApp to obtain information and trigger actions (e.g., policy, reconfiguration) through A1, O1, O2 and open FH M plane related services.

[0010] A common application of rApps is in the field of self-organizing networks (SONs), where networks can detect configuration conflicts and resolve them, e.g., avoiding Physical Cell Identification (PCI) conflicts when deploying wireless networks.

[0011] The quasi-RT RIC is a logical function that enables near real-time control and optimization of E2 node functions and resources through fine-grained data collection and action over the E2 interface with control loops on the order of 10 ms-1 s. The E2 node comprises the logical endpoint of the E2 interface on the RAN component; for example, an O-DU may contain an E2 node that enables the quasi-RT RIC to steer specific functions within the O-DU, such as access control to the cell. Similar to a non-RT RIC, the quasi-RT RIC functions include: · Quasi-RT RIC framework The quasi-RT RIC uses the E2 interface to collect near-real-time information (e.g., UE-based or cell-based) and hosts one or more xApps that provide value-added services. The quasi-RT RIC control over the E2 node is steered via policy and enforcement data provided by the non-RT RIC via A1.

[0012] Some examples of functions that may be implemented by an xApp are: steering a particular user to a particular cell and / or frequency, adjusting QoS / QoE for a particular user, MIMO beamforming, influencing Radio Resource Management (RRM) functions for a particular user, e.g., access control, and collecting mobility data from users that can be used in AI / ML models for user prediction.

[0013] The quasi-RT RIC hosts xApp-based functions. The E2 node is the termination point of the E2 interface. In the current version of this specification, the O-RAN nodes that terminate the E2 interface are: NR Access: O-CU-CP, O-CU-UP, O-DU, or any combination; E-UTRA access: O-eNB

[0014] The functions supported by the E2 interface are currently based exclusively on control plane protocols. The E2 functions are grouped into the following categories: ·Semi-RT RIC services (REPORT, INSERT, CONTROL and POLICY). Quasi-RT RIC support functions including, for example, E2 interface management (E2 setup, E2 reset, generic error condition reporting, etc.) and quasi-RT RIC service updates (capability exchange related to the list of E2 node capabilities exposed via E2, etc.).

[0015] xApp accesses information from the E2 node via the Shared Data Layer (SDL), which is accessed via subscription management. In summary, xApp subscription management (as defined in O-RAN WG3 RIC Architecture, section 6.2.2). Manages the joining of xApp to E2 nodes. Enforce policy permissions that control xApp access to messages. Allows merging of identical subscriptions from different xApps into a single subscription going to the E2 node.

[0016] The O-RAN RIC API describes the Subscribe Information and Information Push procedures. Additionally, as an alternative to parameter subscription, information can also be fetched explicitly.

[0017] Regarding the information exchanged, regardless of the direction of the request and / or push procedure (e.g., xApp towards quasi-RT RIC platform, quasi-RT RIC platform towards xApp, xApp towards quasi-RT RIC platform, quasi-RT RIC platform towards xApp), the following parameters (from the current O-RAN specification) are relevant for retrieval (via subscription or fetch) of E2 node parameters: Message Type, xApp Request ID, Information Type, Delivery Method, Subscribe Filter List, Filter Definition, Information Block, Modification Type, Information Unit, Fetch Filter List, Filter Definition.

[0018] The xApp Request ID IE uniquely identifies each request made by an xApp. In case of an SDL subscription, the xApp Request ID is also used as the "Subscription Identifier" and is used in all related Information Push and Information Update Notification messages.

[0019] The filter and / or information type refers to one of the following identifiers: E2 node ID, E2 node component type, RAN capability OID list.

[0020] From the perspective of an E2 node, the operation is similar. Information exchanged through this protocol stack over the E2 interface is defined by an E2 Service Model (E2SM), e.g., the KPM E2SM defined in the O-RAN WG3 E2SM-KPM specification. An E2SM can be considered a data model that defines the information that can be provided by an E2 node as well as the format of data in messages exchanged with the E2 node (e.g., lists, enumerations, number formats, strings). Each E2SM definition is accompanied by an ASN file containing the OIDs for a given RAN function ID, and the ASN file describes the data types supported by the E2SM. An E2 node may support multiple E2SMs (e.g., KPI monitoring and RAN control). E2 nodes that support the same set of E2SMs can be considered to be of the same type.

[0021] The same or similar concepts (e.g., based on open API descriptions for interface descriptions) can be used in O-RAN interfaces other than E2 (e.g., A1, O1, O2, open FH). Similarly, the O-RAN interface can be extended to cover not only RAN but also other access network (AN) cases, such as wired ANs, where nodes may further include DSLAMs, broadband remote access servers (BRASs), and / or other AN nodes not limited to wireless.

[0022] Thus, the term Access Network Intelligent Controller (AN-IC) is used to refer generically to a RIC or similar intelligent controller applied to a wireless-based or non-wireless-based access network. Similarly, applications (e.g., xApps, rApps) running on an AN-IC are called AN-IC applications, and nodes terminating an AN-IC interface (e.g., E2 interface) are called interface nodes (e.g., E2 nodes).

[0023] The O-RAN Alliance specification defines a set of E2SMs, but for any E2SMs that are not specified (e.g., proprietary data models), the E2SM must be known to the near-RT RIC and the xApps that use it. Therefore, it does not need to be known to other xApps that do not use the given E2SM. Collectively, in the following description, E2SMs are referred to as Interface Node Service Models (INSMs).

[0024] From the common E2SM parameters defined in the O-RAN WG3 E2SM specification, the following parameters are examples of identifiers that may result in the identification and / or tracking within 5GS of a given user: 1) UE NGAP ID 2)RAN UE ID 3) Cell ID (e.g., PCI) 4) Tracking Area

[0025] Additional parameters that can be used in the future and are relevant to privacy are subscriber-related identifiers such as SUPI, SUCI, 5G-GUTI, S-NSSAI, etc. Summary of the Invention [Problem to be solved by the invention]

[0026] In light of the above, it is clear that the functionality expansion and modularity offered by deploying near real-time (near-RT) RAN Intelligent Controllers (RICs) or non-RT RICs is extremely powerful. Furthermore, information collected by an xApp / rApp or group of xApps / rApps can potentially be used to track and / or monitor user behavior.

[0027] In the current specification, the RIC provides data to RIC applications (eg, xApps, rApps), and the RIC applications are trusted to handle the information appropriately.

[0028] However, it is still not possible to modify the values ​​required by the RIC application to remove sensitive data, nor is it possible to obfuscate, e.g., anonymize, such data, or otherwise generate data that resembles the original data before it was received by the RIC application.

[0029] In view of the above, it is an object of the present invention to add additional functionality for the RIC to enable transparent interception and modification of parameters routed towards the RIC application. The purpose of such modification (e.g., obfuscation, anonymization) is that if information collected by a RIC application is misused by and / or through the application, the information cannot be mapped back to the original data, and in particular cannot be mapped back to a specific user of the AN.

[0030] This object is achieved by the features of the claims.

[0031] The present invention allows operators to achieve the ability to deploy features such as: (1) Modify the values ​​requested by the RIC application to remove sensitive data (i.e., not all requested information is available) (2) Alternatively, such data may be obfuscated / anonymized before being received by the RIC application (i.e., the requested information is available, albeit in a transformed form).

[0032] In approach (1), the functionality of some RIC applications may be constrained, but in approach (2), RIC application functionality should be able to be maintained while not explicitly sharing sensitive data.

[0033] According to one aspect of the present invention, there is provided a method for enhancing privacy in an access network (AN) comprising one or more AN components and an AN intelligent controller (AN-IC), wherein at least one AN component comprises an interface node, in particular an E2 node, wherein the AN-IC comprises at least an AN-IC application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC, one or more policy elements, each policy element including a behavior to be applied to a matching request or related AN parameters, the behavior being to allow / deny the request, modify the AN parameter, and / or generate further AN parameters similar to the AN parameter, and one or more logical connections between the AN-IC and the interface node, in particular an E2 interface, wherein the AN-IC is configured to match the policy elements to the matching request, and the method comprises: receiving an interface node message by the AN-IC from the interface node containing the requested AN parameters; receiving a further request for AN parameters from the AN-IC application by the AN-IC; and matching the further request to a policy element by the AN-IC based on information contained in the further message request or interface node message, in particular an interface node and / or interface node type, in particular an interface node identifier or object identifier, an OID identifying a type of interface node, in particular an E2 node and / or E2 service model (E2SM), the requested AN parameters, in particular an object identifier, an OID identifying a variable in the interface node or in the E2 service model, and the requester AN-IC application, in particular an xApp application identifier or rApp application identifier.

[0034] Preferably, the method further includes a step of sending a message by the AN-IC to the AN-IC application, the message including a further AN parameter similar to the AN parameter if the matching behavior indicates a behavior of generating a further AN parameter similar to the AN parameter, a modified AN parameter derived from the AN parameter if the matching behavior indicates a behavior of modifying the AN parameter, and a message rejecting the application request if the matching behavior indicates a behavior of rejecting the request.

[0035] Preferably, the AN is a Radio Access Network (RAN), and the AN component is one of a Radio Unit (RU), a Central Unit (CU), or a Distributed Unit (DU).

[0036] Preferably, modifying an AN parameter refers to replacing, removing, remapping, hashing, encrypting, obfuscating or otherwise changing an AN parameter or part of an AN parameter, particularly in the case of AN parameters that refer to one or more identifiers related to a subscriber, an area, an AN component, a time, a network identifier and / or a network area.

[0037] Preferably, the method includes the step of applying, by the AN-IC, behavior from the matching policy element to the received AN parameters.

[0038] Preferably, the AN-IC further comprises a shared data layer (SDL) configured to store the AN parameters, and the method further includes, after the receiving step, a step of storing the received AN parameters in the SDL by the AN-IC.

[0039] Preferably, after the storing step, the method further includes a step of retrieving AN parameters from the SDL by the AN-IC, and a step of applying behavior from the matching policy element to the retrieved AN parameters by the AN-IC.

[0040] Preferably, the method further includes, before the storing step, a step of applying behavior from the matching policy element to the AN parameters by the AN-IC, and after the storing step, a step of retrieving the AN parameters from the SDL by the AN-IC.

[0041] According to another aspect of the present invention, there is provided a method for enhancing privacy in an access network (AN), comprising: one or more AN components; and an AN intelligent controller (AN-IC), each AN component comprising an interface node, in particular an E2 node; the AN-IC comprising: an application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC application; an AN-IC application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC; one or more policy elements, each policy element including a behavior to be applied to a matching request or an associated AN parameter, the behavior indicating a behavior to allow / deny the request, a behavior to modify the AN parameter, and / or a behavior to generate further AN parameters similar to the AN parameter; and one or more logical connections between the AN-IC and the interface node, in particular an E2 interface, wherein the AN-IC application applies the policy elements to the matching request. the method is configured to: send a request by the AN-IC to an interface node for AN parameters associated with the interface node; receive an interface node message by the AN-IC from the interface node including the requested AN parameters; send an application request by the application to the AN-IC application for second AN parameters associated with the AN parameters; receive a further request by the AN-IC from the AN-IC application for the second AN parameters associated with the AN parameters; receive a message by the AN-IC application from the AN-IC including the AN parameters requested in the further request; and match the further request to a policy element based on information included in the application request for the second AN parameters by the AN-IC application, in particular the interface node and / or interface node type, in particular the interface node identifier or object identifier, an OID identifying the type of interface node,and matching at least one of the requested AN parameters, in particular an object identifier, an OID identifying a variable in an interface node or in an E2 service model, and the requester AN-IC application, in particular an xApp application identifier or an rApp application identifier, in particular an E2 node and / or an E2 service model (E2SM).

[0042] Preferably, the method includes a step of sending a message by the AN-IC application to the application, the message including: a second further AN parameter similar to the second AN parameter if the matching behavior indicates a behavior of generating a further AN parameter similar to the AN parameter; a modified second AN parameter derived from the second AN parameter if the matching behavior indicates a behavior of modifying the AN parameter; and a message rejecting the application request if the matching behavior indicates a behavior of rejecting the request.

[0043] According to another aspect of the present invention, there is provided an access network (AN) including one or more AN components and an AN intelligent controller (AN-IC), wherein at least one AN component includes an interface node, in particular an E2 node, and the AN-IC includes an AN-IC application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC, one or more policy elements, each policy element including a behavior to be applied to the matching request or the associated AN parameters, the behavior indicating a behavior to allow / deny the request, a behavior to modify the AN parameter, and / or a behavior to generate further AN parameters similar to the AN parameter, and one or more logical connections between the AN-IC and the interface node, in particular an E2 interface, wherein the AN-IC matches the policy elements to the matching request and transmits to the interface node an A parameter associated with the interface node (70). The policy element is configured to send a request for N parameters, receive from the interface node an interface node message including the requested AN parameters, receive from the AN-IC application a further request for the requested AN parameters, and match the further request to a policy element based on information contained in the further message request or interface node message, in particular to match at least one of an E2 service model (E2SM), an interface node, in particular an interface node identifier or object identifier, an OID identifying a type of interface node, in particular an E2 node and / or an E2 service model (E2SM), the requested AN parameters, in particular an object identifier, an OID identifying a variable in the interface node or in the E2 service model, a requester AN-IC application, in particular an xApp application identifier or an rApp application identifier, such as one or more parameters belonging to an E2 service model.

[0044] Preferably, the AN is a Radio Access Network (RAN), and the AN component is one of a Radio Unit (RU), a Central Unit (CU), or a Distributed Unit (DU).

[0045] Preferably, the AN-IC is configured to send a message to the AN-IC application, the message including, if the matching behavior indicates a behavior of generating a further AN parameter similar to the AN parameter, a modified AN parameter derived from the AN parameter if the matching behavior indicates a behavior of modifying the AN parameter, and a message rejecting the application request if the matching behavior indicates a behavior of rejecting the request.

[0046] Preferably, the behavior of modifying an AN parameter refers to the behavior of replacing, removing, remapping, hashing, encrypting, obfuscating or otherwise changing an AN parameter or part of an AN parameter, particularly in the case of AN parameters that refer to one or more identifiers related to a subscriber, an area, an AN component, a time, a network identifier and / or a network area.

[0047] Preferably, the AN-IC is further configured to apply behavior from the matching policy element to the AN parameters received from the interface node.

[0048] Preferably, the AN-IC further comprises a shared data layer (SDL) configured to store the AN parameters, and after receiving a further request for the requested AN parameters, the AN-IC is configured to store the received AN parameters in the SDL, retrieve the AN parameters from the SDL, and apply behavior from the matching policy element to the retrieved AN parameters.

[0049] Preferably, the AN-IC further comprises a shared data layer (SDL) configured to store the AN parameters, and the AN-IC is further configured to apply behavior from the matching policy element to the AN parameters, and after receiving a further request for the requested AN parameters, store the received AN parameters in the SDL, and retrieve the AN parameters from the SDL by the AN-IC.

[0050] According to another aspect of the present invention, there is provided an access network (AN) comprising one or more AN components and an AN intelligent controller (AN-IC), each AN component including an interface node, in particular an E2 node, the AN-IC including: an application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC application; an AN-IC application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC; one or more policy elements, each policy element including a behavior to be applied to a matching request or related AN parameters, the behavior being to allow / deny the request, modify the AN parameter, and / or generate further AN parameters similar to the AN parameter; and one or more logical connections between the AN-IC and the interface node, in particular an E2 interface, the AN-IC application configured to match the policy elements to the matching request, and the AN-IC includes one or more logical connections between the AN-IC and the interface node, in particular an E2 interface, the AN-IC including: an application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC; the IC is configured to send to the interface node a request for AN parameters associated with the interface node, the AN-IC is configured to receive from the interface node an interface node message including the requested AN parameters, the application is configured to send to the AN-IC application an application request for second AN parameters, the second AN parameters associated with the AN parameters, the AN-IC is configured to receive from the AN-IC application a message including the requested AN parameters in the further request, the AN-IC application matches the further request to a policy element based on information included in the application request for the second AN parameters, in particular the interface node and / or interface node type, in particular the interface node identifier or object identifier, an OID identifying the type of interface node;In particular, it is configured to match at least one of the E2 node and / or E2 service model (E2SM), the requested AN parameters, in particular an object identifier, an OID identifying a variable in the interface node or in the E2 service model, the requester AN-IC application, in particular an xApp application identifier or an rApp application identifier.

[0051] Other aspects, features, and advantages will become apparent from the above summary and from the following description, including the figures and claims. [Brief explanation of the drawings]

[0052] [Figure 1] This shows the concept of the current 5G system model. [Figure 2] This shows the overall concept of RAN. [Figure 3] An example of an O-RAN architecture is shown, which also covers interfaces standardized by 3GPP. [Figure 4] 10 illustrates an example of parameters considered for AN-IC security / privacy policy, according to an embodiment of the present invention. [Figure 5] 1 illustrates an exemplary method of applying a security / privacy policy to data received from an interface node, according to one embodiment of the present invention. [Figure 6] 1 illustrates an exemplary method in which the generation of synthetic data is not received from an interface node, according to one embodiment of the present invention. [Figure 7] 10 illustrates an exemplary method by which modified data is written to the AN-IC shared data layer or DB, according to an embodiment of the present invention. [Figure 8] 1 illustrates an exemplary method in which data is modified before being sent to an application, according to one embodiment of the present invention. [Figure 9] 1 illustrates an exemplary method for enhancing privacy in an access network, according to one embodiment of the present invention. [Figure 10]1 illustrates another exemplary method for enhancing privacy in an access network, according to another embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0053] The present invention aims to enable security / privacy policy enforcement based on information requested by the AN-IC application regarding the identity of the requester and / or the target (e.g., E2 node) to which the request is targeted.

[0054] The parameters associated with the security / privacy policy relate to the data request, the requestor, and the subject of the request and are based on a combination of: The INSM to which the request points (e.g., E2 Service Model (E2SM)), including the OID of the E2 Service Model and / or parameters belonging to the E2 Service Model Requester AN-IC application (e.g., xApp ID) · The request target, i.e., the AN component that is queried (e.g., based on the E2 node ID) and maps it to the specific component (e.g., RU, CU, DU) that provides the data.

[0055] 4 illustrates an example of parameters considered for a RIC security policy, according to an embodiment of the present invention. The security / privacy policy 62 contains information about what the security policy action should be with respect to information 20 flowing toward the AN-IC and is mapped to an interface node 70 and / or application 50 (e.g., xApp). The action can be one of the following: allow the requested data, deny the requested data, or modify the data so that it cannot be mapped 1:1 to the original data.

[0056] In particular, according to embodiments of the present invention, data modification can be performed, for example, by one or a combination of the following actions: ak data suppression or generalization to achieve anonymity, i.e., replacing segments of the subscriber identifier with the same sequence of numbers, and / or b. Adding noise to the data to achieve differential privacy, i.e. modifying the actual values ​​of KPIs etc. returned by the interface nodes, and / or c. Generating synthetic data (i.e., "adding noise data points") to add additional data points to the dataset.

[0057] Modifying the data in any of the above options is particularly preferred as it has the advantage of preserving xApp functionality whilst still providing protection for data being accessed by the xApp.

[0058] Regarding the operation modes for RIC security / privacy policy, two operation modes are proposed according to an embodiment of the present invention.

[0059] In the first mode, security / privacy policies are applied to the data before it is stored in the AN-IC's database, i.e., the data flow between the interface node and the AN-IC. In this mode, in the event of data modification, the original data is not available in the AN-IC, only the modified data is available.

[0060] In the second mode, security / privacy policies are applied to data as required by the AN-IC application, i.e., data flows between the AN-IC application and the AN-IC, where in the second mode, if the data is modified, the original data is available at the AN-IC.

[0061] A further mode of operation is contemplated in which a second AN-IC application implements security / privacy functions and AN-IC application requests are directed to the second AN-IC application, i.e., the second AN-IC application acts as a middleman for AN-IC application requests and applies security / privacy policies.

[0062] 5 illustrates an exemplary method of applying security / privacy policies to data received from an interface node, according to one embodiment of the present invention. In particular, FIG. 5 illustrates the interaction between an AN-IC application 50, an AN-IC 60, and an interface node 70. The method includes the following steps:

[0063] In step S1, the AN-IC application 50 sends a request for data to the AN-IC 60 (eg, an explicit data request, a subscription to some type of data).

[0064] In step S2, security / privacy policies are applied to allow the request, deny the request, or modify the data. If the request is denied, steps S2, S3, and S4 are skipped.

[0065] If the information is not available at the AN-IC 60, the information is requested from the interface node 70 in step S3A and received by the AN-IC 60 in step S3B.

[0066] In step S4, the information is modified based on security / privacy policies either before the information is stored in the shared data layer of the AN-IC or after the information is stored in the shared data layer.

[0067] In step S5, if the security / privacy policy indicates denial in step S2, the application receives a message indicating denial of the request in step S1. If the security / privacy policy indicates modification in step S2, the application receives the modified information from RIC 60.

[0068] FIG. 6 illustrates an exemplary method in which the generation of synthetic data is not received from an interface node, according to one embodiment of the present invention.

[0069] In the case of generated or artificial data (i.e., "statistical noise"), the procedure is similar to that shown in Figure 5, except that the information is not retrieved from the interface node, but rather is generated by the AN-IC itself. In this case, the information returned by the AN-IC is generated by the AN-IC rather than information originating from the interface node. In particular, the method of Figure 6 has the following steps:

[0070] In step S10, the AN-IC application 50 sends a request / subscription for data (eg, AN-IC parameters such as KPIs from the CU) to the AN-IC 60.

[0071] In step S11, the RIC 60 generates generated or artificial data (eg, KPI values ​​within a range based on the INSM).

[0072] In step S12, the AN-IC 60 sends a message containing the generated or artificial data to the application 50.

[0073] FIG. 7 illustrates an exemplary manner in which modified data is written to the shared data layer (SDL) or database (DB) 61 of the AN-IC 60, according to one embodiment of the present invention.

[0074] In step S20, interface node 70 sends a message containing the data to interface termination point 70-1 (e.g., E2 termination point) within AN-IC 60. Interface termination point 70-1 then forwards the message to security / privacy policy element 62 in step S21.

[0075] In step S22, the security / privacy policy component 62 applies the security / privacy policy before the data is written to the DB or SDL 61.

[0076] In step S23, the modified data is stored in a database or shared data layer 61.

[0077] In step S24, the application 50 transmits a data request to the application API 51 (for example, the xApp API of the quasi-RT RIC). Then, the application API 51 transfers the data request to the DB or SDL 61 in step S25.

[0078] In step S26, the DB or SDL 61 sends a response message including the modified data to the application API 51.

[0079] Finally, in step S27, the application API 51 forwards the message containing the modified data to the application 50.

[0080] This mode has the advantage of computational simplicity and the fact that the original (i.e., unmodified) data is not stored in the AN-IC. On the other hand, if pseudo-anonymized information is provided, it is possible to track a given (anonymized) user across applications (e.g., across different xApps), since each AN-IC application 50 receives hidden information with the same mapping.

[0081] FIG. 8 illustrates an exemplary method for a local mode in which data is modified before being sent to an application, according to an embodiment of the present invention.

[0082] In step S30, the interface node 70 sends a message containing the data to the interface termination point 70-1, which then forwards the message to the database or shared data layer 61 in step S31.

[0083] In step S32, the AN-IC application 50 sends a data request to the application API 51 (e.g., the xApp API), which then forwards the data request to the security / privacy policy component 62 in step S33.

[0084] In step S34, the security / privacy policy component 62 sends a request to retrieve data to the DB or SDL 61. In step S35, the security / privacy policy component 62 receives the retrieved data from the DB or SDL 61.

[0085] In step S36, security / privacy policy component 62 applies security / privacy policies before the data is sent to AN-IC application 50.

[0086] In step S37, the security / privacy policy component 62 sends a response message containing the modified data to the application API 51.

[0087] Finally, in step S38, the application API 51 forwards the message containing the modified data to the AN-IC application 50.

[0088] This mode has the advantage that each AN-IC application 50 (i.e., xApp) can be provided with a potentially differently modified data set, at the cost of higher complexity and the need to store the original data on the AN-IC 60. Although at the cost of complexity, using different identifier remapping, obfuscation and / or pseudo-anonymization algorithms for different AN-IC applications 50 has the advantage of making it impossible to track a user across different AN-IC applications 50.

[0089] FIG. 9 illustrates an exemplary method for enhancing privacy in an access network, according to one embodiment of the present invention.

[0090] 9, the AN is composed of several AN components and an AN intelligent controller 60 (AN-IC). In particular, at least one of the AN components includes an interface node 70, particularly an E2 node.

[0091] According to an embodiment, the AN-IC is composed of at least an AN-IC application 50, one or more policy elements (not shown in FIG. 9), and one or more logical connection elements between the AN-IC 60 and an interface node 70 (e.g., an E2 interface).

[0092] The AN-IC application 50 can request and / or subscribe to one or more AN parameters from the interface node 70 via the AN-IC 60.

[0093] Additionally, each policy element includes a behavior or associated AN parameter that is applied to a matching request. In this regard, "behavior" refers to a behavior that allows / denies a request, modifies an AN parameter, and / or generates additional AN parameters similar to an AN parameter.

[0094] More particularly, the meaning of the expression "behavior that modifies an AN parameter" refers to, but is not limited to, behavior that replaces, removes, remaps, hashes, encrypts, obfuscates, or otherwise alters an AN parameter or part of an AN parameter, in the case of an AN parameter that refers to one or more identifiers associated with a subscriber, an area, an AN component, a time, a network identifier, and / or a network area.

[0095] In this embodiment, the AN-IC 60 matches the policy elements to the matching request. More specifically, the method includes the following steps.

[0096] In step S100, the AN-IC 60 sends to the interface node 70 a request for AN parameters for the interface node 70.

[0097] In step S200, the AN-IC 60 receives an interface node message from the interface node 70 containing the AN parameters requested in step S100.

[0098] In step S300, the AN-IC 60 receives a further request from the AN-IC application 50 for the AN parameters requested in step S100.

[0099] In step S400, the AN-IC 60 matches the further request to a policy element based on information contained in the further message request or interface node message. For example, matching the further request to a policy element may refer to at least one of the following: Interface nodes and / or interface node types, in particular interface node identifiers or object identifiers (OIDs) identifying the type of interface node, in particular E2 nodes and / or E2 service models (E2SMs). · An object identifier (OID) that identifies the requested AN parameter, specifically a variable within an interface node or E2 service model. The requester AN-IC application 50, in particular the xApp application identifier or the rApp application identifier.

[0100] The method described above with reference to FIG. 9 may further include several additional elements and optional steps (shown in dotted lines in FIG. 9), as described below.

[0101] In a preferred embodiment, the AN may be a Radio Access Network (RAN). Further, the AN component may be one of a Radio Unit (RU), a Central Unit (CU), or a Distributed Unit (DU).

[0102] In a preferred embodiment, the method may further include a step S500 in which the AN-IC 60 sends which content depends on the indication by the matching behavior to the AN-IC application 50. For example, the message may comprise: Further AN parameters similar to the AN parameter if the matching behavior indicates that further AN parameters similar to the AN parameter are generated. · Modified AN parameters derived from AN parameters if the matching behavior indicates modification of the AN parameters. If the matching behavior indicates that the request should be denied, the message denies the application request.

[0103] In a preferred embodiment, the method may further include a step S210 in which the AN-IC applies behavior from the matching policy element to the AN parameters received in the receiving step S200.

[0104] In a preferred embodiment, the AN-IC may further include a shared data layer (SDL) 61 for storing AN parameters. In that case, step S210 is not performed, and the method may further include the following preferred alternative.

[0105] In a preferred alternative, the method may further include, after receiving step S200, step S310, of storing the received AN parameters by the AN-IC in SDL 61. Once stored in SDL 61, the AN-IC may retrieve the AN parameters from SDL 61 in step S320 and apply behavior from the matching policy element to the retrieved AN parameters in step S325.

[0106] The above alternative has the advantage that each AN-IC application 50 (e.g., xApps / rApps) can be provided with a potentially differently modified data set, at the cost of greater complexity and the need to store the original data on the AN-IC 60. While more or less complex, using different identifier remappings for different AN-IC applications 50 has the advantage that it makes it impossible to track a user across different AN-IC applications 50.

[0107] In a further preferred alternative, the method may further include a step S305 of applying behavior from the matching policy element to the AN parameters by the AN-IC before the storing step S310. Step S310 is the same as described in the above preferred alternative. The AN-IC can then already retrieve the AN parameters from the SDL 61 in step S320.

[0108] The above alternative has the advantage of being computationally simple and the fact that the original (i.e., unmodified) data is not stored in the AN-IC. On the other hand, even if pseudo-anonymized information is provided, it is possible to track a given (anonymized) user across applications (e.g., xApps / rApps).

[0109] In an alternative implementation, Figure 10 illustrates another exemplary method for enhancing privacy in an access network according to another embodiment of the present invention. The embodiment illustrated in Figure 10 differs from the embodiment of Figure 9 in that the innovative functionality described above (which in the embodiment of Figure 9 is primarily performed by the AN-IC) is performed by a second AN-IC application 50-B instead of the AN-IC. Thus, although the implementations are different, the embodiments of Figures 9 and 10 are alternative solutions to the technical problem described above.

[0110] In particular, FIG. 10 illustrates a method for enhancing privacy in an access network.

[0111] 10, the AN is composed of several AN components and an AN intelligent controller 60 (AN-IC). In particular, at least one of the AN components includes an interface node 70, particularly an E2 node.

[0112] According to an embodiment, the AN-IC is composed of at least an application 50-A, an AN-IC application 50-B, one or more policy elements, and one or more logical connections (e.g., E2 interfaces) between the AN-IC 60 and an interface node 70.

[0113] In this embodiment, application 50-A can request and / or subscribe to one or more AN parameters from interface node 70 via AN-IC application 50-B. Additionally, AN-IC application 50-B can request and / or subscribe to one or more AN parameters from interface node 70 via the AN-IC.

[0114] Additionally, each policy element includes a behavior or associated AN parameter that is applied to a matching request. In this regard, a "behavior" may refer to a behavior that allows / denies a request, a behavior that modifies an AN parameter, and / or a behavior that generates additional AN parameters similar to an AN parameter.

[0115] More particularly, the meaning of the expression "behavior that modifies an AN parameter" may refer, but is not limited to, to behavior that replaces, removes, remaps, hashes, encrypts, obfuscates, or otherwise alters an AN parameter or part of an AN parameter, especially when referring to one or more identifiers associated with a subscriber, an area, an AN component, a time, a network identifier, and / or a network area.

[0116] In this embodiment, unlike the embodiment of Figure 9, it is the AN-IC application 50-B that matches policy elements to matching requests instead of the AN-IC 60 of Figure 9. More specifically, the method of Figure 10 includes the following steps:

[0117] In step S1000, the AN-IC sends to the interface node 70 a request for AN parameters for the interface node 70.

[0118] In step S2000, the AN-IC receives an interface node message from interface node 70 containing the AN parameters requested in step S1000.

[0119] In step S3000, application 50-A sends an application request for second AN parameters to AN-IC application 50-B, where the second AN parameters relate to AN parameters.

[0120] More specifically, information about the second AN parameter is explicitly or implicitly contained within the AN parameter, for example, the second AN parameter is an AN parameter, the AN parameter is a parameter list, the second AN parameter contains itself, the second AN parameter is obtained by processing the AN parameter (e.g., by applying a bit mask and / or by arithmetic means).

[0121] In step S4000, the AN-IC receives a further request for AN parameters from AN-IC application 50-B, where the AN parameters relate to a second AN parameter.

[0122] In step S4500, the AN-IC application 50-B receives a message from the AN-IC containing the AN parameters requested in the further request of step S4000.

[0123] In step S5000, the AN-IC application 50-B matches the further request to policy elements based on the information contained in the application request of the second AN parameter in step S3000.

[0124] For example, matching of a further request to a policy element may refer to at least one of the following: Interface nodes and / or interface node types, in particular interface node identifiers or object identifiers (OIDs) identifying the type of interface node, in particular E2 nodes and / or E2 service models (E2SMs). · An object identifier (OID) that identifies the requested AN parameter, specifically a variable within an interface node or E2 service model. The requester AN-IC application, in particular the xApp application identifier or rApp application identifier.

[0125] The method described above with reference to FIG. 10 may further include several additional elements and optional steps (shown in dotted lines in FIG. 10) as described below.

[0126] In a preferred embodiment, the method may further include step S6000, in which the AN-IC application 50-B sends the application which content depends on the indication by the matching behavior. For example, the message may comprise: If the matching behavior indicates generating a further AN parameter similar to the AN parameter, a second further AN parameter similar to the second AN parameter in step S3000. · If the matching behavior indicates modification of the AN parameters, modified second AN parameters derived from the second AN parameters in step S3000. A message rejecting the application request if the matching behavior indicates that the request should be rejected.

[0127] Although the present invention has been shown and described in detail with reference to a "RIC / RIC application" or an "Access Node Intelligent Controller (AN-IC) / AN-IC application," it should be noted that the expressions "RIC / RIC application" and "Access Node Intelligent Controller (AN-IC) / AN-IC application" are fully interchangeable in the context of an access network.

[0128] While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered exemplary or illustrative and not restrictive. It will be understood that changes and modifications may be made by those skilled in the art within the scope of the following claims. In particular, the invention encompasses further embodiments having any combination of features from the different embodiments described above and below.

[0129] Furthermore, in the claims, the term "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. A single unit may fulfill the functions of several features recited in a claim. The terms "essentially," "about," "approximately," etc. in connection with an attribute or a value also specifically define the attribute or value, respectively. Any reference signs in the claims should not be construed as limiting the scope.

Claims

1. 1. A method for enhancing privacy in an access network (AN), the method comprising one or more AN components and an AN intelligent controller (AN-IC), wherein at least one of the AN components comprises an interface node, in particular an E2 node, and the AN-IC comprises: an AN-IC application configured to request and / or subscribe to one or more AN parameters from the interface node via the AN-IC; one or more policy elements, each including a behavior that is applied to a matching request or associated AN parameters, the behavior indicating allowing / denying the request, modifying the AN parameters, and / or generating further AN parameters similar to the AN parameters; one or more logical connections between the AN-IC and the interface node, in particular an E2 interface; The AN-IC is configured to match the policy element to the matching request, and the method comprises: sending a request for AN parameters associated with the interface node by the AN-IC to the interface node (S100); receiving an interface node message including the requested AN parameters from the interface node by the AN-IC (S200); receiving, by the AN-IC, from the AN-IC application, a further request for the AN parameters (S300); a step (S400) of matching, by the AN-IC, the further request with a policy element based on the information contained in the further message request or the interface node message, comprising in particular: an interface node and / or interface node type, in particular an interface node identifier or an object identifier (OID) identifying the type of said interface node, in particular an E2 node and / or E2 service model (E2SM), the object identifier (OID) that identifies the requested AN parameter, in particular a variable within an interface node or within an E2 service model; and (S400) matching at least one of the requester AN-IC applications, in particular an xApp application identifier or an rApp application identifier.

2. The method further includes a step of sending a message to the AN-IC application by the AN-IC (S500), the message including: If the matching behavior indicates a behavior of generating a further AN parameter similar to the AN parameter, the further AN parameter similar to the AN parameter; if the matching behavior indicates a behavior of modifying an AN parameter, a modified AN parameter derived from the AN parameter; 2. The method of claim 1, further comprising: if the matching behavior indicates a behavior that denies the request, a message that denies the application request.

3. The AN is a Radio Access Network (RAN), and the AN component is one of a Radio Unit (RU), a Central Unit (CU), or a Distributed Unit (DU); and / or 2. The method of claim 1, wherein modifying the AN parameter refers to replacing, removing, remapping, hashing, encrypting, obfuscating, or otherwise altering the AN parameter or a portion of the AN parameter, particularly for the AN parameter referring to one or more identifiers related to a subscriber, an area, an AN component, a time, a network identifier, and / or a network area.

4. 2. The method of claim 1, further comprising applying (S210) by the AN-IC the behavior from the matching policy element to the received AN parameters.

5. the AN-IC further comprises a Shared Data Layer (SDL) configured to store the AN parameters; The method according to any one of claims 1 to 4, further comprising, after the receiving step (S300), a step (S310) of storing the received AN parameters in the SDL by the AN-IC.

6. After the storing step (S310), the AN-IC extracts the AN parameters from the SDL (S320); The method of claim 5, further comprising applying (S325), by the AN-IC, the behavior from the matching policy element to the retrieved AN parameters.

7. applying, by the AN-IC, the behavior from the matching policy element to the AN parameters (S305) before the storing step (S310); 6. The method of claim 5, further comprising, after the storing step (S310), retrieving the AN parameters from the SDL by the AN-IC (S320).

8. 1. A method for enhancing privacy in an access network (AN), the method comprising one or more AN components and an AN intelligent controller (AN-IC), each of the AN components comprising an interface node, in particular an E2 node, the AN-IC comprising: an application configured to request and / or subscribe to one or more AN parameters from the interface node via an AN-IC application; an AN-IC application configured to request and / or subscribe to the one or more AN parameters from the interface node via the AN-IC; one or more policy elements, each including a behavior that is applied to a matching request or associated AN parameters, the behavior indicating allowing / denying the request, modifying the AN parameters, and / or generating further AN parameters similar to the AN parameters; one or more logical connections between the AN-IC and the interface node, in particular an E2 interface; The AN-IC application is configured to match the policy element to the matching request, and the method includes: sending, by the AN-IC to the interface node, a request for the AN parameters associated with the interface node (S1000); receiving an interface node message including the requested AN parameters from the interface node by the AN-IC (S2000); sending, by the application to the AN-IC application, an application request for second AN parameters related to the AN parameters (S3000); receiving, by the AN-IC from the AN-IC application, a further request for the AN parameters related to the second AN parameters (S4000); receiving (S4500) a message from the AN-IC by the AN-IC application, the message including the AN parameters requested in the further request; a step (S5000) of matching, by the AN-IC application, the further request with a policy element based on the information contained in the application request of the second AN parameter, in particular an interface node and / or interface node type, in particular an interface node identifier or an object identifier (OID) identifying the type of said interface node, in particular an E2 node and / or E2 service model (E2SM), the object identifier (OID) that identifies the requested AN parameter, in particular a variable within an interface node or within an E2 service model; and (S5000) matching the requester AN-IC application, in particular at least one of an xAPP application identifier or an rAPP application identifier.

9. A step (S6000) of sending a message to the application by the AN-IC application, wherein the message includes: If the matching behavior indicates a behavior of generating a further AN parameter similar to the AN parameter, a second further AN parameter similar to the second AN parameter; a modified second AN parameter derived from the second AN parameter if the matching behavior indicates a behavior of modifying the AN parameter; 9. The method of claim 8, further comprising: if the matching behavior indicates a behavior that denies the request, a message that denies the application request.

10. An access network (AN) including one or more AN components and an AN intelligent controller (AN-IC) (60), wherein the at least one AN component includes an interface node (70), in particular an E2 node, and the AN-IC (60) an AN-IC application (50) configured to request and / or subscribe to one or more AN parameters from the interface node (70) via the AN-IC (60); one or more policy elements, each including a behavior that is applied to a matching request or associated AN parameters, the behavior indicating allowing / denying the request, modifying the AN parameters, and / or generating further AN parameters similar to the AN parameters; one or more logical connections between said AN-IC (60) and said interface node (70), in particular an E2 interface; The AN-IC (60) is Matching the policy element to the matching request; sending to said interface node (70) a request for AN parameters associated with said interface node (70); receiving an interface node message from the interface node (70) containing the requested AN parameters; receiving a further request for the requested AN parameters from the AN-IC application (50); matching said further request to said policy element based on said information contained in said further message request or said interface node message, in particular said E2 Service Model (E2SM), such as one or more parameters belonging to said E2 Service Model; an interface node, in particular an interface node identifier or an object identifier (OID) identifying a type of said interface node, in particular an E2 node and / or an E2 service model (E2SM), the object identifier (OID) that identifies the requested AN parameter, in particular a variable within an interface node or within an E2 service model; An access network configured to match at least one of a requester AN-IC application (50), in particular an xApp application identifier or an rApp application identifier.

11. the access network (AN) is a radio access network (RAN), and the AN component is one of a radio unit (RU), a central unit (CU), or a distributed unit (DU); and / or The AN-IC (60) is configured to send a message to the AN-IC application (50), the message comprising: If the matching behavior indicates a behavior of generating a further AN parameter similar to the AN parameter, the further AN parameter similar to the AN parameter; if the matching behavior indicates a behavior that modifies the AN parameter, modified AN parameters derived from the AN parameter; 11. The access network of claim 10, further comprising: a message denying the application request if the matching behavior indicates a behavior of denying the request.

12. A behavior that modifies the AN parameter refers to a behavior that replaces, removes, remaps, hashes, encrypts, obfuscates, or otherwise changes the AN parameter or a portion of the AN parameter, especially in the case of an AN parameter that refers to one or more identifiers related to a subscriber, an area, an AN component, a time, a network identifier, and / or a network area; and / or 11. The access network of claim 10, wherein the AN-IC (60) is further configured to apply the behavior from the matching policy element to the AN parameters received from the interface node (70).

13. The AN-IC (60) further comprises a Shared Data Layer (SDL) (61) configured to store the AN parameters, and the AN-IC (60) further comprises: storing the received AN parameters in the SDL (61) after receiving the further request for the requested AN parameters; Extracting the AN parameters from the SDL (61); 13. An access network according to any one of claims 10 to 12, configured to apply a behavior from the matching policy element to the retrieved AN parameters.

14. The AN-IC (60) further comprises a Shared Data Layer (SDL) (61) configured to store the AN parameters, and the AN-IC (60) further comprises: applying the behavior from the matching policy element to the AN parameters; storing the received AN parameters in the SDL (61) after receiving the further request for the requested AN parameters; An access network according to any one of claims 10 to 12, characterized in that it is arranged by the AN-IC (60) to retrieve the AN parameters from the SDL (61).

15. An access network (AN) including one or more AN components and an AN intelligent controller (AN-IC) (60), each of said AN components including an interface node (70), in particular an E2 node, said AN-IC (60): an application (50-A) configured to request and / or subscribe to one or more AN parameters from said interface node (70) via an AN-IC application (50-B); the AN-IC application (50-B) configured to request and / or subscribe to the one or more AN parameters from the interface node (70) via the AN-IC (60); one or more policy elements, each including a behavior that is applied to a matching request or associated AN parameters, the behavior indicating allowing / denying the request, modifying the AN parameters, and / or generating further AN parameters similar to the AN parameters; one or more logical connections between said AN-IC (60) and said interface node (70), in particular an E2 interface; The AN-IC application (50-B) is configured to match policy elements to the matching request; the AN-IC (60) is configured to send to the interface node (70) a request for the AN parameters associated with the interface node (70); the AN-IC (60) is configured to receive an interface node message from the interface node (70) that includes the requested AN parameters; The application (50-A) is configured to send an application request for second AN parameters related to the AN parameters to the AN-IC application (50-B); the AN-IC (60) is configured to receive from the AN-IC application (50-B) a further request for the AN parameters related to the second AN parameters; the AN-IC application (50-B) is configured to receive from the AN-IC (60) a message including the AN parameters requested in the further request; The AN-IC application (50-B) matches the further request to a policy element based on the information contained in the application request of the second AN parameter, in particular an interface node and / or interface node type, in particular an interface node identifier or an object identifier (OID) identifying the type of said interface node, in particular an E2 node and / or an E2 service model (E2SM), the object identifier (OID) that identifies the requested AN parameter, in particular a variable within an interface node or within an E2 service model; An access network configured to match at least one of a requester AN-IC application (50-B), in particular an xApp application identifier or an rApp application identifier.

Images