Techniques for synchronizing data and control entities in a communication network
Patent Information
- Application Number
- EP2023700052
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-01-02
- Publication Date
- 2025-10-29
AI Technical Summary
Current mobile core architecture lacks consistency and synchronization between control and data planes, leading to scalability and fault tolerance issues, especially with the increased deployment of User Plane Functions (UPFs) and Session Management Functions (SMFs) in communication networks, particularly in 5G and 6G standardization.
The solution involves transactional interaction between SMFs and UPFs using a 2-phase lock protocol, transactional IDs, and last write transaction IDs to ensure atomic execution of commands and conflict-free modifications, enhancing scalability and fault tolerance by maintaining state at UPFs and allowing SMFs to read and write directly, thus overcoming limitations in traditional request/response interactions and multi-controller setups.
This approach achieves systemic consistency and scalability by ensuring conflict-free interactions and efficient control across multiple SMFs and UPFs, enabling the deployment of thousands of dynamic network functions while maintaining high reliability and low latency.
Smart Images
Figure 1.1
Abstract
Description
[0001] TECHNIQUES FOR SYNCHRONIZING DATA AND CONTROL ENTITIES IN A COMMUNICATION NETWORK
[0002] TECHNICAL FIELD
[0003] The present disclosure relates to the field of synchronizing data and control entities that handle data traffic in communication networks, in particular communication networks according to 5G and 6G standardization and beyond, and control of a User Plane Function (UPF) entity by a Session Management Function (SMF) entity according to 3GPP standardization. In particular, the disclosure relates to consistency and synchronization between control and data plane Network Functions (NFs).
[0004] BACKGROUND
[0005] 6G standardization will enable operators to use virtual and programmable resources for the data and control planes. With the proliferation of advanced virtualization techniques, it is possible to enable a distributed resource substrate that can execute different types of applications and network functions.
[0006] Further, with the current increase in mobile network subscribers from humans to robots and even home appliances, more User Plane Function (UPFs) are needed in the networks. The UPF has the main purpose of handling the user data plane traffic along the path from the User Equipment (UE) towards the data networks. Of course, to control those many UPFs, more Session Management Functions (SMF) need to be deployed. However, more SMFs means that there will be an increased coordination effort between UPF and SMFs. In general, such an interaction (especially in a scalable and efficient way) is difficult to achieve. What makes this more critical is the fact that UPFs will be hosted and executed just like any other control plane Network Function (NF). Thanks to advanced virtualization techniques, it is possible to run thousands of UPFs in the network while it is possible to launch and decommission UPFs within seconds. Therefore, a scalable and efficient control of dynamic UPFs is needed. However, current mobile core architecture does not allow for consistency and synchronization between control and data planes impacting scalability and fault tolerance of the mobile core network.
[0007] SUMMARY
[0008] This disclosure provides a solution for a scalable and efficient control of dynamic UPFs. In particular, a solution is provided for consistency and synchronization between control and data planes of the mobile core network.
[0009] The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.
[0010] The general scenario of this disclosure revolves around a mobile network with a target to improve the service quality to enable service guarantees of resource intensives applications, such as NPN, mMTC, V2X, etc. Further, such application will be handled by a deep edge delivery system inside the 3GPP networks. Based on this, many SMFs, and UPFs will exist in the network which will cause a massive increase of the number of control messages and events.
[0011] In general, different interactions with UPFs and SMF will happen beyond the classical 1-to-1 interaction and session initiation between a single UPF and a single SMF. This cross interaction between any UPF and any SMF will happen due to e.g.: user mobility, application mobility, low latency applications, redundancy, failover, etc.
[0012] One major challenge for such a cross interaction is that traditionally the UPF-SMF interaction is limited to the request / response type, i.e., a 1-to-1 interaction between the UPF and the SMF. So, when multiple SMFs are deployed to control a single UPF, bottleneck and synchronization issues will occur. The disclosure presents a solution for this scenario of multiple SMFs controlling a single UPF. A solution to the scenario of multiple SMFs controlling multiple UPFs is given as well.
[0013] The disclosure further provides a solution for the following scenarios, as detailed in the following:
[0014] A) synchronization at the individual layer
[0015] B) multiple N4 / Sx interfaces
[0016] C) SDN and controller distribution
[0017] A first option in scenario A (synchronization at the individual layer) is based on an interaction and state synchronization within the control plane, this means interaction between SMFs can partially realize synchronization. The major limitation of this approach is that it does not realize synchronization of the UPF (or network) state at the SMF. Further, it is not good for scaling or requires some node hierarchy (e.g., master SMF), which would not be reliable. The second option in scenario A) is based on an interaction and state synchronization within the data plane. This means an interaction between UPFs can achieve synchronization of UPF state. One major limitation of this is that it does not allow to propagate network-level and UPF- local changes to the SMF, i.e., does not achieve consistent views at the situation at both CP and UP levels.
[0018] The solution presented in this disclosure provides interaction between SMF and UPF for state synchronization in order to realize consistency between control and data plane layers.
[0019] In scenario B (multiple N4 / Sx interfaces), multiple N4 interfaces can enable a single UPF to establish multiple N4 connections with multiple SMFs. Integration of multiple SMFs with a single UPF can create a multi-controller setup (leading to the well-known “split brain problem”). This situation will happen due to: Resilience, On demand UPF creation (virtual resource), and On demand SMF creation (virtual resource).
[0020] Limitations of scenario B are the following: Configuration updates at the UPF are handled based on first-come-first-served approach. Known problems of consistency and version control limit the usability of such a solution. Conflicting configurations exist, e.g., write during read, read during write, rollback, etc.
[0021] The solution presented in this disclosure provides interaction between SMF and UPF for state synchronization and hence overcomes the above limitations of scenario B.
[0022] In scenario C (SDN and controller distribution), the main approach to realize scalability and low latency is through disaggregation (=distribution) of both CP (control path) and DP (data path). a) For this to be successful, it must be lightweight: hardwiring by manual configuration, limiting to data partitions (like in RAFT / PAXOS algorithms), installing predefined hierarchies result in heavy configurations, highly specialized instances (and not just replica) and, hence, result in complexity, which leads to errors. b) Distributed controller runs as a set of instances that can be added or removed without disruptions. c) The instances cooperate to create what appears to the applications as a single, logically centralized controller. There exist two types of controller design for scalable SDN systems, these are: Loosely coupled controllers such as HyperFlow and SCL, or tightly coupled controllers (such as ONOS and ONYX).
[0023] In Loosely Coupled Controllers (e.g., HyperFlow, SCL), controller instances run mechanisms for “eventual consistency”; perform publish / subscribe messaging, gossip protocol. There are distributed network events across the cluster and event reprocessing. Such loosely coupled controllers have the following limitations: Unhandled conflicts facing split brain (e.g. partial path); and scalability issues, i.e., each instance locally reprocesses every event from the network.
[0024] Tightly Coupled Controllers (e.g., ONOS, Onyx) use strong consistency protocols (e.g., Raft, Paxos) to coordinate the operation of the instances in the cluster. Limitation of such Tightly Coupled Controllers is related to their fault tolerance: Consensus leaders handle updates, which create a single point of failure.
[0025] The solution presented in this disclosure provides interaction between SMF and UPF for state synchronization and hence overcomes the above limitations of scenario C. By applying the disclosed solution, a good scalability and fault tolerance characteristics can be achieved. The disclosed solution is suitable for a mobile network SMF / UPF interaction and architectural constraints.
[0026] The disclosed solution can realize systemic consistency instead of only synchronization at individual layer and individual layer’s shared data synchronization.
[0027] For multiple N4 Interfaces, it is not enough to simply create more links to the UPF. The disclosed solution provides here scalable control and consistency in both data storage and in command schedules across controlling and controlled instances (ordering, atomic execution of command bundles, etc.).
[0028] For SDN and Controller Distribution, instead of introducing multiple controller instances, which need a lot of coordination to maintain this state, the disclosed solution keeps the state at the nodes (UPFs) and let the controllers (SMFs) read and write directly. The disclosed solution is based on TRANSACTIONAL capabilities, which will be described in the following.
[0029] The disclosed solution provides transactional UPF / SMF interaction for distributed control. The interaction between the control plane (SMF) and data plane (UPF) is enhanced to realize transaction control. This in general will enable storing the state of the data plane network in the UPF and allowing the SMF to query it as needed before changing it. The transaction methods enable the ability to deploy thousands of SMF and UPFs along each other.
[0030] Main points of the disclosed solution include:
[0031] 1) New modules for the UPF / SMF transactional interaction: SMF transaction controller; and UPF transaction controller.
[0032] 2) New interfaces: SMF / management plane northbound interface; and SMF / UPF transactional interface.
[0033] 3) New IDs: Transaction ID (TID) and Last Write Transaction ID (LW-TID).
[0034] 4) New Procedures: To enable transactional interaction between the SMF and UPF.
[0035] The overall architecture is shown in Figure 1 and described below.
[0036] The disclosure presents a mechanism for conflict resolution of a large number of UPFs under the control of many SMFs (controllers). The solution enhances the interaction procedure between a SMF and UPF by utilizing a 2-phase lock protocol. It makes the control commands from uncoordinated SMFs atomically ordered, and potential conflicting modification on a same UPF can be avoided. This provides the technical advantages of scalability and simplicity.
[0037] The design presented in this disclosure is based on distributed storage and database systems. A specific interaction protocol is provided to synchronize the state especially if there was a disconnect and requiring fast retrievable of the state. The focus is on SMF UPF specific interaction.
[0038] The design is further based on “lock before write”. This guarantees a deadlock free lock mechanism in which a lock is released in case no transaction is sent. The focus is on SMF UPF specific interaction.
[0039] The design is further based on generic distributed consensus. The disclosed solution is SMF / UPF specific and has direct impact on new architectural designs of 6G system.
[0040] In order to describe the disclosure in detail, the following terms, abbreviations and notations will be used:
[0041] MEC Multi Access Edge Computing
[0042] RAN Radio Access Network
[0043] VR virtual reality SLA service level agreement
[0044] UPF user plane function; user plane function entity
[0045] UE user equipment
[0046] SMF session management function; session management function entity 3GPP third generation partnership project
[0047] AF application function, application function entity
[0048] PCF policy control function, policy control function entity
[0049] AMF access and mobility management function; access and mobility management function entity
[0050] API application programming interface
[0051] A service-level agreement (SLA) is a contract between a service provider and its customers that documents what services the provider will furnish and defines the service standards the provider is obligated to meet. Service providers need SLAs to help them manage customer expectations and define the severity levels and circumstances under which they are not liable for outages or performance issues. Customers can also benefit from SLAs because the contract describes the performance characteristics of the service - which can be compared with other vendors' SLAs -- and sets forth the means for redressing service issues.
[0052] Edge computing, or on demand provisioning of compute services very close to end-users, enables next generation applications especially in 6G mobile communication systems. The main advantage of deep (meaning as close to the user as possible) edge computing is its ability to offer services with very low latencies and high throughput which is important for applications with stringent requirements such as: video conferencing, virtual reality, and drone control. Since the edge nodes are deployed close to end users it is possible to realize the best service delivery conditions.
[0053] According to a first aspect, the disclosure relates to a data entity for routing data traffic of a User Equipment in a communication network based on a network configuration of the data entity, the data entity comprising: a control interface for receiving control messages from at least one control entity over the communication network, the control messages being associated with transactions for updating the network configuration of the data entity, each transaction being identified by a respective transaction identifier; wherein a first control message of the control messages which is associated with a first transaction comprises a read request for retrieving at least parts of the network configuration of the data entity; and a data entity transaction controller, configured to determine, upon reception of the first control message, a last transaction upon which the data entity was last updated, to generate a first identifier of the last transaction and to send the first identifier in a response to the control entity; wherein a second control message of the control messages which is associated with the first transaction comprises a write request for updating the data entity with a new network configuration, and a second identifier of a last transaction upon which the data entity was last updated; and wherein the data entity transaction controller is configured to update the data entity with the new network configuration upon a match of the second identifier of the last transaction from the second control message with the first identifier of the last transaction generated by the data entity transaction controller upon reception of the first control message.
[0054] Such data entity avoids introducing multiple controller instances, which need a lot of coordination to maintain this state. Instead, the data entity keeps its network configuration, i.e., its state and lets the control entities or controller instances read and write directly. The data entity is based on transactional capabilities in order to avoid conflicts.
[0055] The data entity provides transactional interaction for distributed control. The interaction between the control entity (e.g., a SMF entity) and the data entity (e.g., a UPF entity) is enhanced to realize transaction control. This enables storing the network configuration such as for example the state of the data entity and allows the control entity to query it as needed before changing it. The transaction methods enable the ability to deploy thousands of control entities such as SMFs and data entities such as UPFs along each other.
[0056] The control messages transmitted from control entity, e.g., SMF, to data entity, e.g., UPF, comprise a transaction identifier (TID) for identifying a respective transaction processed by the control messages. In particular, the control messages are separate messages, where it can happen that other control messages for other transactions may be transmitted in between two control messages for a specific transaction.
[0057] The first control message and the second control message belong to the control messages introduced above.
[0058] The network configuration of the data entity may represent the state of the data entity, e.g., the UPF state as shown in Figure 1. The new network configuration of the data entity may represent the new state of the data entity, e.g., the new UPF state as shown in Figure 1.
[0059] The first identifier of a last transaction upon which the data entity was last updated, also referred to as “LW-TID” in the Figures, is generated by the data entity transaction controller and sent in the response to the control entity. The second identifier of a last transaction upon which the data entity was last updated, also referred to as “LW-TID” in the Figures, is received from the control entity in the second message as shown in Figure 2.
[0060] In an exemplary implementation of the data entity, each transaction comprises a write request transported by a respective second control message which is preceded by a read request transported by a respective first control message.
[0061] This implements a two-phase locking protocol which is a simple and most efficient method to realize conflict free interaction between one or multiple data entities and one or multiple control entities.
[0062] The control messages are received for a plurality of different transactions. A control message for a specific transaction includes the transaction identifier (TID) of the specific transaction. The control messages for a specific transaction comprise a respective first control message with the specific TID and a respective second control message with the specific TID. The second control message with specific TID is not necessarily received after the first control message with the same TID. Other first or second control messages for other TIDs may be received in between.
[0063] In an exemplary implementation of the data entity, the data entity transaction controller is configured to reject updating the data entity with the new network configuration if the second identifier of the last transaction from the second control message is not matching the first identifier of the last transaction generated by the data entity transaction controller upon reception of the first control message.
[0064] This provides the advantage that a two-phase locking is implemented wherein the first and second identifiers of a last transaction has to match before performing an update of the network configuration.
[0065] In an exemplary implementation of the data entity, the data entity transaction controller is configured to send a confirmation message to the control entity before updating the data entity with the new network configuration, and to update the data entity with the new network configuration upon reception of a commit message to the confirmation message from the control entity. This provides the advantage of additional security since the update is only activated upon receiving the commit message from the control entity.
[0066] In an exemplary implementation of the data entity, the data entity transaction controller is configured to set, upon sending the confirmation message to the control entity, a lock-flag, the lock-flag indicating a locking of an update mechanism for updating the data entity with a new network configuration.
[0067] This provides the advantage that the lock flag implements a locking mechanism in order to avoid unintentional updating a network configuration of the data entity.
[0068] In an exemplary implementation of the data entity, the data entity transaction controller is configured to release, upon reception of the commit message from the control entity, the lockflag, in order to enable the update mechanism for updating the data entity with a new network configuration.
[0069] This provides the advantage that the locking can be safely released.
[0070] In an exemplary implementation of the data entity, the data entity is based on a user plane function, UPF, entity according to 3GPP standardization which is enhanced by functionalities of the control interface and the data entity transaction controller.
[0071] This provides the advantage that the UPF entity is enhanced by transactional capabilities which enables consistency and synchronization between UPF entity and SMF entities.
[0072] In an exemplary implementation of the data entity, the data entity comprises a plurality of control interfaces for receiving messages from a plurality of control entities, the messages being associated with different transactions, wherein the data entity transaction controller is configured to reject an updating of the data entity according to a write request of a second control entity upon sending of a confirmation message for updating the data entity with a new network configuration according to a write request of a first control entity.
[0073] This provides the advantage that consistency and synchronization between data entity and control entity can be supported in the scenario where the data entity has multiple control interfaces to multiple control entities. Due to the transactional capabilities conflicts can be avoided. In an exemplary implementation of the data entity, the data entity transaction controller is configured to implement a two-phase locking protocol for realizing conflict-free interaction between the data entity and the plurality of control entities.
[0074] As said above, this provides the advantage of conflict-free interaction between the data entity and the plurality of control entities.
[0075] Other protocols can be used as well to implement different types of concurrency beyond a two- phase lock, such as Time stamp ordering protocol, multi version concurrency control, validation concurrency control, etc.
[0076] In an exemplary implementation of the data entity, the data entity transaction controller is configured to precommit the update if the second identifier of the last transaction in the second control message corresponds to the first identifier of the last transaction in the response to the first control message.
[0077] This provides the advantage that both entities, data entity and control entity must agree before an update is activated. This results in a higher level of security.
[0078] According to a second aspect, the disclosure relates to a control entity for controlling a data entity according to any of the preceding claims, the control entity comprising: a management interface for receiving messages from a management entity, the messages being associated with transactions for updating the network configuration of the data entity, each transaction being identified by a respective transaction identifier; wherein a first management message associated with a first transaction comprises a read request for retrieving at least parts of the network configuration of the data entity; and wherein a second management message associated with the first transaction comprises a write request for updating the data entity with a new network configuration; and a control entity transaction controller, configured to transmit, upon reception of the first management message, the first control message via the control interface to the data entity and to inform the management entity about the response of the data entity; wherein the control entity transaction controller is configured to transmit, upon reception of the second management message, the second control message, via the control interface to the data entity and to inform the management entity about a result of updating the data entity with the new network configuration.
[0079] The control entity implements transactional interaction for distributed control. The interaction between the control entity (e.g., a SMF entity) and the data entity (e.g., a UPF entity) is enhanced to realize transaction control. This enables storing the network configuration such as for example the state of the data entity and allows the control entity to query it as needed before changing it. The transaction methods enable the ability to deploy thousands of control entities such as SMFs and data entities such as UPFs along each other.
[0080] In an exemplary implementation of the control entity, the control entity transaction controller is configured to determine or obtain a transaction identifier of a transaction based on one or a combination of the following identifiers, IDs: a request ID of a certain request between two network function entities of the communication network, a slice ID of a certain slice of the communication network, an application ID of an application set by an application function entity of the communication network, and a network function ID of a network function entity of the communication network.
[0081] This provides the advantage that each transaction is uniquely identified the transaction identifier which improves safety of the transactional interaction.
[0082] In an exemplary implementation of the control entity, the control entity transaction controller is configured to determine the identifier of a transaction based on a hash function applied to one or a combination of the request ID, the slice ID, the application ID and the network function ID.
[0083] This provides the advantage that a unique transaction identifier can be provided.
[0084] In an exemplary implementation of the control entity, the control entity transaction controller is configured to inform the management entity about an identifier of a transaction upon receiving a message indicating a start of the transaction.
[0085] This provides the advantage that the same identification of transaction can be applied in each instance of the communication network.
[0086] In an exemplary implementation of the control entity, the control entity is based on a session management function, SMF, entity according to 3GPP standardization which is enhanced by functionalities of the management interface, the control interface and the control entity transaction controller.
[0087] This provides the advantage that the SMF entity is enhanced by transactional capabilities which enables consistency and synchronization between UPF entities and SMF entity. BRIEF DESCRIPTION OF THE DRAWINGS
[0088] Further embodiments of the disclosure will be described with respect to the following figures, in which:
[0089] Figure 1 shows a schematic diagram illustrating a communication network 100 according to the disclosure;
[0090] Figure 2 shows an exemplary message flow chart 200 illustrating an exemplary messaging between a control entity, e.g., SMF entity and a data entity, e.g., UPF entity according to the disclosure;
[0091] Figure 3 shows a block diagram of a 3GPP system 300 including new functionality according to the disclosure;
[0092] Figure 4 shows a block diagram of the scenario of multiple SMFs controlling a single UPF;
[0093] Figure 5 shows an exemplary message flow chart 500 illustrating the scenario where two SMF instances try to write to the UPF but with a specific time delay; and
[0094] Figure 6 shows an exemplary message flow chart 600 illustrating the scenario where two SMF instances try to write to the UPF and the two writes come at almost the same time.
[0095] DETAILED DESCRIPTION OF EMBODIMENTS
[0096] In the following detailed description, reference is made to the accompanying drawings, which form a part thereof, and in which is shown by way of illustration specific aspects in which the disclosure may be practiced. It is understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.
[0097] It is understood that comments made in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if a specific method step is described, a corresponding device may include a unit to perform the described method step, even if such unit is not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary aspects described herein may be combined with each other, unless specifically noted otherwise.
[0098] Figure 1 shows a schematic diagram illustrating a communication network 100 according to the disclosure.
[0099] The communication network 100 or also referred to as communication system 100 comprises a data entity 120, also referred to as data plane entity or User Plane Function (UPF) entity or UPF network entity, and a control entity 110, also referred to as control plane entity or Session Management Function (SMF) entity or SMF network entity.
[0100] The data entity 120 is used for routing data traffic 108 of one or more User Equipments (UEs) 130 in the communication network 200 based on a network configuration 121 of the data entity 120. The network configuration can be a state of the data entity 120, also referred to as UPF State in Figure 1 , including for example a state of routing tables, input and output interfaces of the data entity 120. The network configuration 121 or UPF state can dynamically change. For example, after some time instance, depending on the processing of the data entity 120 and reception of input / outputs and control messages, a new network configuration 12T or new UPF state 12T may exist.
[0101] The data entity 120 comprises a control interface 125 and a data entity transaction controller 122.
[0102] The control interface 125 is for receiving control messages 205, 210, e.g., as illustrated in Figure 2, from at least one control entity 110 over the communication network. While Figure 1 shows just one control entity 110, multiple of such control entities may exist transmitting respective control messages to the data entity 120. The control messages are associated with transactions for updating the network configuration 121 of the data entity 120. Each transaction is identified by a respective transaction identifier (TID) 221 , e.g., as shown in Figure 2.
[0103] A first control message 205 of the control messages 205, 210 which is associated with a first transaction comprises a read request for retrieving at least parts of the network configuration 121 of the data entity 120.
[0104] The data entity transaction controller 122 is configured to determine, upon reception of the first control message 205, a last transaction (LW-TID) upon which the data entity 120 was last updated. The data entity transaction controller 122 is configured to generate a first identifier 222, as shown in Figure 2, of the last transaction and to send the first identifier 222 in a response 207 to the control entity 110, as shown in detail in Figure 2.
[0105] A second control message 210 of the control messages 205, 210 which is associated with the first transaction comprises a write request for updating the data entity 120 with a new network configuration 12T, and a second identifier 222’ of a last transaction upon which the data entity 120 was last updated, as shown in Figure 2. The data entity transaction controller 122 is configured to update 214 the data entity 120 with the new network configuration 12T upon a match of the second identifier 222’ of the last transaction from the second control message 210 with the first identifier 222 of the last transaction generated by the data entity transaction controller 122 upon reception of the first control message 205, as illustrated in detail in Figure 2.
[0106] As already mentioned above, the control messages transmitted from control entity 110, e.g., SMF, to data entity 120, e.g., UPF, comprise a transaction identifier (TID) 221 for identifying a respective transaction processed by the control messages. In particular, the control messages 205, 210 are separate messages, where it can happen that other control messages for other transactions may be transmitted in between two control messages for a specific transaction.
[0107] The first control message 205 and the second control message 210 belong to the control messages 205, 210 introduced above.
[0108] The network configuration of the data entity 120 may represent the state 121 of the data entity 120, e.g., the UPF state 121 as shown in Figure 1. The new network configuration of the data entity 120 may represent the new state 12T of the data entity 120, e.g., the new UPF state 12T as shown in Figure 1.
[0109] The first identifier 222 of a last transaction upon which the data entity 120 was last updated, also referred to as “LW-TID” in the Figures, is generated by the data entity transaction controller 122 and sent in the response 207 to the control entity 110.
[0110] The second identifier 222’ of a last transaction upon which the data entity 120 was last updated, also referred to as “LW-TID” in the Figures, is received from the control entity 110 in the second message 210 as shown in Figure 2.
[0111] Each transaction may comprise a write request transported by a respective second control message 210 which is preceded by a read request transported by a respective first control message 205.
[0112] The control messages are received for a plurality of different transactions. A control message for a specific transaction includes the transaction identifier (TID) of the specific transaction. The control messages for a specific transaction comprise a respective first control message with the specific TID and a respective second control message with the specific TID. The second control message with specific TID is not necessarily received after the first control message with the same TID. Other first or second control messages for other TIDs may be received in between.
[0113] The data entity transaction controller 122 may be configured to reject updating 214 the data entity 120 with the new network configuration 12T if the second identifier 222’ of the last transaction from the second control message 210 is not matching the first identifier 222 of the last transaction generated by the data entity transaction controller 122 upon reception of the first control message 205.
[0114] The data entity transaction controller 122 may be configured to send a confirmation message 212, e.g., as shown in Figure 2, to the control entity 110 before updating 214 the data entity 120 with the new network configuration 12T. The data entity transaction controller 122 may be configured to update 214 the data entity 120 with the new network configuration 12T upon reception of a commit message 213, as shown in Figure 2, to the confirmation message 212 from the control entity 110.
[0115] The data entity transaction controller 122 may be configured to set, upon sending the confirmation message 212 to the control entity 110, a lock-flag 223, as shown in Figure 2. This lock-flag 223 indicates a locking of an update mechanism for updating 214 the data entity 120 with a new network configuration 12T.
[0116] The data entity transaction controller 122 may be configured to release, upon reception of the commit message 213 from the control entity 110, the lock-flag 223, in order to enable the update mechanism for updating 214 the data entity 120 with a new network configuration 12T.
[0117] As mentioned above, the data entity 120 may also be referred to as UPF entity. The data entity 120 or UPF entity may be based on a user plane function, UPF, entity according to 3GPP standardization which is enhanced by functionalities of the control interface 125 and the data entity transaction controller 122 as described above and below with respect to Figures 2 to 6.
[0118] The data entity 120 may comprise a plurality of control interfaces 125a, 125b and 125c, e.g., as shown in Figure 4, for receiving messages from a plurality of control entities 110a, 110b, 110c which are similar to the control entity 110 shown in Figure 1 and described below. These messages may be associated with different transactions.
[0119] The data entity transaction controller 122 may be configured to reject an updating 214 of the data entity 120 according to a write request 210b of a second control entity 110b upon sending of a confirmation message 212 for updating 214 the data entity 120 with a new network configuration 12T according to a write request 210a of a first control entity 110a, e.g., as shown in Figure 2.
[0120] The data entity transaction controller 122 may be configured to implement a two-phase locking protocol for realizing conflict-free interaction between the data entity 120 and the plurality of control entities 110a, 110b, 110c.
[0121] Other protocols can be used as well to implement different types of concurrency beyond a two- phase lock, such as Time stamp ordering protocol, multi version concurrency control, validation concurrency control, etc.
[0122] The data entity transaction controller 122 may be configured to precommit the update 214 if the second identifier 222’ of the last transaction in the second control message 210 corresponds to the first identifier 222 of the last transaction in the response 207 to the first control message 205, e.g., as shown in detail in Figure 2.
[0123] The control entity 110 is used for controlling a data entity 120, i.e., the data entity 120 as described above or any other data entity of multiple data entities in the communication network 100.
[0124] The control entity 110 comprises a management interface 115 and a control entity transaction controller 112 that is different from the above-described data entity transaction controller 122.
[0125] The management interface 115 is for receiving messages from a management entity 140 (not shown in Figure 1). The management entity 140 can be some entity at application layer or management layer as shown in Figure 2, for example. These messages are associated with transactions for updating the network configuration 121 of the data entity 120. Each transaction is identified by a respective transaction identifier (TID) 221 , as shown in Figure 2.
[0126] A first management message 204, that may be associated with a first transaction, comprises a read request for retrieving at least parts of the network configuration 121 of the data entity 120.
[0127] A second management message 209, that may be associated with the first transaction, comprises a write request for updating the data entity 120 with a new network configuration 12T. The control entity transaction controller 112 is configured to transmit, upon reception of the first management message 204, the first control message 205 via the control interface 125 to the data entity 120, e.g., as shown in Figure 2, and to inform 208 the management entity 140 about the response 207 of the data entity 120.
[0128] The control entity transaction controller 112 is configured to transmit, upon reception of the second management message 209, the second control message 210, via the control interface 125 to the data entity 120, e.g., as shown in Figure 2, and to inform 216 the management entity 140 about a result of updating 214 the data entity 120 with the new network configuration 12T.
[0129] The control entity transaction controller 112 may be configured to determine or obtain a transaction identifier (TID) 221 of a transaction based on one or a combination of the following identifiers, IDs: a request ID of a certain request between two network function entities of the communication network, a slice ID of a certain slice of the communication network, an application ID of an application set by an application function entity of the communication network, and a network function ID of a network function entity of the communication network.
[0130] The control entity transaction controller 112 may be configured to determine the identifier of a transaction based on a hash function applied to one or a combination of the request ID, the slice ID, the application ID and the network function ID.
[0131] The control entity transaction controller 112 may be configured to inform 203 the management entity 140 about an identifier of a transaction upon receiving a message 202 indicating a start of the transaction.
[0132] As mentioned above, the control entity 110 may also be referred to as SMF entity. The control entity 110 may be based on a session management function, SMF, entity according to 3GPP standardization which is enhanced by functionalities of the management interface 115, the control interface 125 and the control entity transaction controller 112 as described in this disclosure.
[0133] The data entity 120 can be a II PF entity or simply referred to as UPF 120. The control entity 110 can be a SMF entity or simply referred to as SMF 110.
[0134] Figure 1 shows the main points of the disclosed solution which are: 1) New modules for the UPF / SMF transactional interaction: SMF transaction controller 112; and UPF transaction controller 122. 2) New interfaces: SMF / management plane northbound interface 115; and SMF / UPF transactional interface 125. 3) New IDs: Transaction ID (TID) 221 as shown in Figure 2 and Last Write Transaction ID (LW-TID) 222 and 222' as shown in Figure 2. 4) New Procedures to enable transactional interaction between the SMF 110 and UPF 120.
[0135] The SMF transaction controller 112 is configured to control the transactions with the UPF 120; provide north bound APIs (for the northbound interface 115); implement concurrency control mechanism that schedules concurrent read and write operations with the UPF 120; and provide an Atomic Commit Protocol coordinator.
[0136] The UPF transaction controller 122 is configured to be Bookkeeper for transactions, tracking their progress and communicates with the SMF 110; provide SMF control APIs; and provide an Atomic Commit Protocol participant.
[0137] The SMF / management plane northbound interface 115 is configured to enable controlling and setting information over the SMF 110.
[0138] The SMF / UPF transactional interface 125 is configured to signal the beginning of a transaction by startTransaction() command, retrieve parts of the network state by read(...) command, update the network by transactionalUpdate(...) command, i.e. to bring UPFs / SMFs to the desired state.
[0139] Transactions between participating functions (management, SMF, UPF) may use a 2 phase processing to support read-write updates, wherein in Phase 1 , Network function (NF) reads from the network state; and in Phase 2, NF updates the network state in an atomic execution.
[0140] For the IDs in mobile network transactional interaction new globally unique identifiers are introduced as follows:
[0141] Transaction ID (TID): The SMF transaction controller 112 stamps all commands (reads and writes) within a transaction with the transaction ID (TID) before sending them to the UPF transaction controller 122.
[0142] Last Write Transaction ID (LW-TID): The UPF transaction controller 122 identifies the transaction that last updated the UPF (Last Write Transaction ID (LW-TID) ). Whenever replying to a read, the UPF transaction controller 122 sends back the last write transaction ID (LW-TID). The SMF transaction controller 112 uses the LW-TID to associate the writes from the second phase of the transaction with the correct network state reads. The UPF transaction controller 122 rejects writes that carry obsolete LW-TID.
[0143] As already described above, the transaction IDs can be linked and or include partially existing IDs in the 3GGP network using the following options:
[0144] 1) Request ID of a certain NF-NF request. Each request between any two NFs will have a certain ID. This ID can then be used to impact the transaction ID.
[0145] 2) Slice ID: this is the ID of a certain slice and can be used to generate the transaction ID so that that to have a separation between transactions of different slices.
[0146] 3) APP ID: this is the ID of the application that is being used as set by the application function (AF), this is then used to influence the transaction ID.
[0147] 4) NF ID: each NF in the 5G or 6G system will have an ID. This can then be used to generate the transaction ID.
[0148] Besides, hash functions can be used as described in the following. Any of the above IDs can be used to impact the transaction ID by using a hash function. A hash function can use as input any set of information and generates a unique ID or output that is sensitive to any changes in the input. This mean it is unique for this specific set of IDs and therefore in general guarantees no conflicts.
[0149] The generation of the transaction ID can be done by the SMF 110 or at any another network function. In one example, those IDs can be generated by the NRF (Network Repository Function). Since NRF can track all the requests for discovering other NFs, it can be an important place to ask for generating a transaction ID before starting a transaction.
[0150] Further, a new network function can be created specifically for generating transaction IDs. This network function can be called the Transaction Repository Function (TRF) which, similar to the NRF, is responsible to generate the transaction ID for other network functions.
[0151] Figure 2 shows an exemplary message flow chart 200 illustrating an exemplary messaging between a control entity, e.g., SMF entity and a data entity, e.g., UPF entity according to the disclosure.
[0152] Messages are interchanged between the application / management layer 140 via the northbound interface 115 with the SMF 110, and between the SMF 110 and the UPF 120 via the SMF / UPF transactional interface 125 as described above with respect to Figure 1. Based on a trigger event 201 , the application / management layer 140 transmits a startTransaction() message 202 to the SMF transactional controller 112 which responds 203 by transmitting the TID 221 to the application / management layer 140. Then, application / management layer 140 transmits read() message 204 including configuration and TID to the SMF transactional controller 112.
[0153] The SMF transactional controller 112 transmits first control message 205 as described above with respect to Figure 1 , which is UPF read(TID) message 205 including the TID 221 to UPF transactional controller 122. Upon receiving this first control message 205, UPF transactional controller 122 generates 206 LW-TID 222, i.e., the first identifier 222 of a last transaction generated by the UPF transactional controller 122 and sets lock flag to zero, e.g., as described above with respect to Figure 1. The UPF transactional controller 122 responds to the first control message 205 with UPF read response message 207 including TID 221 and LW-TID 222.
[0154] When receiving this UPF read response message 207 by SMF transactional controller 112, SMF transactional controller 112 transmits UPF read response message 208 including TID 221 to the application / management layer 140. The application / management layer 140 may then decide to perform an update and transmit transactional Update message 209 including an updated configuration 209 and TID 221 to the SMF transactional controller 112. When receiving this message 209, the SMF transactional controller 112 transmits the second control message as described above with respect to Figure 1 , i.e., UPF write message 210 including the updated configuration, TID 221 and a second identifier 222’, as described above with respect to Figure 1 , which is also named as LW-TID, to the UPF transactional controller 122.
[0155] When UPF transactional controller 122 receives this second control message 210, UPF transactional controller 122 precommits 211 the update with LW-TID and sets the lock flag 223 to TID. Then, UPF transactional controller 122 confirms the update by transmitting a confirm message 212 to SMF transactional controller 112 which commits this confirm message 212 by responding with a commit message 213.
[0156] When receiving the commit message 213, UPF transactional controller 122 activates 214 the update with LW-TID being set to TID and lock flag being reset to zero. UPF transactional controller 122 then transmits a Done message 215 to SMF transactional controller 112 which transmits a Done message 216 to the application / management layer 140. The functionality of this messaging 200 as described above is as follows.
[0157] When the application or management layer 140 wants to change a configuration, a transaction is triggered. First the SMF 110 will assign a TID 221 to this transaction. The first step now is to read the state of the network and current configurations. This request is then sent to the SMF 110 which is then forwarded to the UPF 120. Both requests will have the TID 221 set so that the read and the later write requests are property identified. The UPF 120 then responds with the LW-TID so that the application 140 is aware of the last transaction that wrote to the network. This response is then sent to the SMF 110 and consequently to the application 140.
[0158] Now the application 140 is ready to start the transaction update of the configuration. This is sent to the SMF 110 which forwards it to the UPF 120. This step must include the updated configuration, the TID 221 , as well as the LW-TID. If the LW-TID from the request and the one stored at the UPF 120 match (in this case it is indicated by LW-TID = X), the configuration is pre-committed and the lock flag is set to TID (i.e. the transaction that started this sequence of transactions). This is then confirmed to the SMF 110 which will then issue a final commit request that will activate the configuration at the UPF 120. This is then confirmed to both the SMF 110 and the Application 140 ending the transactional update.
[0159] As already described above with respect to Figure 1 , any write request (here transmitted by the second control message 210) has to be preceded by a read request (here transmitted by the first control message 205). The read request will have a certain LW-TID which will then prevent writing on top of other configurations. The transaction update will write the configuration with the UPF 120 only if the LW-TID matches with the one which read through the configuration.
[0160] Figure 3 shows a block diagram of a 3GPP system 300 including new functionality according to the disclosure.
[0161] The 3GPP system 300 may be based on 3GPP standardization, e.g., according to TS 23.501 specification, but is not restricted to that. In particular, the communication system 300 may comprise the following 5G network functions of the 5G reference point architecture, e.g., as specified in 3GPP TS 38.300 and 3GPP TS 23.501 specifications: UPF 120, SMF 110, NF 140, AMF 310, PSA 312.
[0162] UPF 120 stands for User plane function. The functions of 5G NR UPF node or UPF entity are: Anchor point for lntra- / lnter-RAT mobility (when applicable); External PDU Session point of interconnect to Data Network; Packet routing & forwarding; Packet inspection; User Plane part of policy rule enforcement, e.g. Gating, Redirection, Traffic steering; Lawful intercept (UP collection); Traffic usage reporting; QoS handling for user plane, e.g. UL / DL rate enforcement, Reflective QoS marking in DL; Uplink Traffic verification (SDF to QoS Flow mapping); Transport level packet marking in the uplink and downlink; Downlink packet buffering and downlink data notification triggering; Sending and forwarding of one or more "end marker" to the source NG-RAN node.
[0163] SMF 110 stands for Session Management Function. The functions of 5G NR SMF node or SMF entity are: Session Management; UE IP address allocation and management; Selection and control of UP function; Configures traffic steering at UPF to route traffic to proper destination; Control part of policy enforcement and QoS; Downlink Data Notification.
[0164] AMF 310 stands for Access and Mobility Management Function. AMF is part of the 3GPP 5G Architecture. Its primary tasks includes: Registration Management, Connection Management, Reachability Management, Mobility Management and various function relating to security and access management and authorization.
[0165] PSA 312 stands for protocol data unit session anchor. PSA is the term given to the UPF which terminates the N6 interface of a PDU session within a 5G core network.
[0166] NF 140 stands for network function. A Network Function is a logical node within a network infrastructure that has well-defined external interfaces and well-defined functional behavior.
[0167] AN 311 stands for access network. The access network is a communication network which connects subscribers to their service provider.
[0168] In the communication system 300 of Figure 3, NF that may correspond to the application and management layer 140 described above with respect to Figure 2, trigger 301 a configuration change. The interface 115 between NF 140 and SMF 110 as well as the interface 125 between SMF 110 and UPF 120 can be used to transmit a transactional read / write configuration 302, 303. The UPF transaction controller 122 can be used to lock or activate the transaction 304.
[0169] The ideas in this invention relate to the scenario of a large-scale mobile network with thousands of SMFs 110 and UPFs 120 that need to interact in a scalable and efficient manner. This system is based on a virtual platform that can create those network functions dynamically. Therefore, it is important to be able to read the state of the network before writing. Storing it in a central location would impact scalability and efficiency. Therefore, one target is conflict resolution on a large number of UPFs under the control of many SMFs (controllers). The solution enhances the interaction procedure between a SMF 110 and UPF 120 by utilizing a 2-phase lock protocol. It makes the control commands from uncoordinated SMFs atomically ordered, and potential conflicting modification on a same UPF can be avoided. Technical advantages include its scalability and simplicity.
[0170] In the following, four embodiments of the communication network 100 with SMF 110 and UPF 120 as generally described above with respect to Figures 1 and 2 are described in more detail.
[0171] Embodiment 1 of the 3GPP system 300 is shown in Figure 3 together with the new functionality as described above with respect to Figures 1 and 2.
[0172] Embodiment 1 has direct impact on the 6G / 5G network so that the key functions can be enhanced with transaction interaction capabilities beyond classical request / response type of interaction.
[0173] In embodiment 1 , SMF is enhanced with the SMF transaction controller 112, UPF is enhanced with the UPF transaction controller 122, interactions use the transaction IDs (TID and LW-TID) to keep track of active configurations; and UPF uses the Lockflag with specific TID to indicate last locked configuration; and Last Write IDs are used to indicate last read orwritten transaction with older ID ignored.
[0174] Figure 4 shows a block diagram of the scenario of multiple SMFs controlling a single UPF.
[0175] Figure 4 shows a second embodiment. This Embodiment 2 is related to the problem of connecting multiple SMFs 110a, 110b, 110c as described above with respect to Figures 1 to 3 with a single UPF 120. Existing prior art simply assumes that multiple connections will solve the problem. However, it does not solve the multiple update requests of conflicting configurations. This is solved according to the disclosure by having: Multiple N4 Interfaces 125a, 125b, 125c to enable a single UPF 120 to establish multiple N4 interfaces with multiple SMFs. Integration of multiple SMFs 110a, 110b, 110c with a single UPF 120 can create a multi controller setup.
[0176] The benefits of this Embodiment 2 are as follows: Configuration updates at the UPF are handled based on transaction update that eliminates conflicts and consistency issues. A read command is used before a write command. Global IDs are used to track on active configuration. Thus, UPF can function even if one SMF fails.
[0177] In a third embodiment, Embodiment 3, beyond the two-phase lock as described above with respect to Figures 1 to 3 other types of concurrency algorithms can be used to realize conflict free interaction between the data and control planes as described in the following.
[0178] 1 . The two-phase locking protocol as described above is the simplest and most effective method to realize concurrency.
[0179] 2. In the time stamp ordering protocol, each transaction is time-stamped. Upon a conflict, the transaction with the newest timestamp has priority. Timestamp is either time-based, or counter-based.
[0180] 3. In the multi version concurrency control, different versions of configurations across different UPFs are tracked. In case of error or conflicts, a revert to the last known good configuration is performed. This is good for a network wide configuration control. Old versions are kept in case they are needed.
[0181] 4. Validation concurrency control performs an optimistic approach that assumes most transactions will not generate a conflict. This protocol consists of three phases: read, validation and write. During validation period, it is made sure that the transaction does not generate a conflict using a private copy of the configuration file before it is committed to the normal one.
[0182] Figure 5 shows an exemplary message flow chart 500 illustrating the scenario where two SMF instances try to write to the UPF but with a specific time delay.
[0183] In this fourth embodiment, Embodiment 4, two specific cases are highlighted in which the solution presented in this disclosure avoids conflict. The first one shown in Figure 5 is related to the case when two SMF instances 112a, 112b try to write to the UPF 122 but with a specific time delay (see messages 210a, 210b). Since the lock flag will be set to TID1 (see message 211) the second transaction will be rejected (see message 211b) since the lock flag does not match as shown in the sequence diagram of Figure 5.
[0184] The following messages are exchanged: First SMF instance 112a transmits UPF write message 210a to II PF transaction controller 122 including an updated configuration, first transaction identifier TID1 and last write identifier LW- TID=X. When receiving this message 210a, UPF transaction controller 122 precommits the update 211 including LW-TID=X and sets lock flag to TID1 and confirms this by message 212 to first SMF instance 112a.
[0185] Then, second SMF instance 112b transmits UPF write message 210b to UPF transaction controller 122 including an updated configuration, second transaction identifier TID2 and last write identifier LW-TID=X. When receiving this message 210b, UPF transaction controller 122 rejects 211b the update and transmits response 212b to second SMF instance 112b.
[0186] First SMF instance 112a transmits commit message 213 to UPF transaction controller 122 which then activates 214 the update with LW-TID=TID and sets lock flag to zero. UPF transaction controller 122 finally transmits Done message 215 to first SMF instance 112a.
[0187] Figure 6 shows an exemplary message flow chart 600 illustrating the scenario where two SMF instances try to write to the UPF and the two writes come at almost the same time.
[0188] This scenario is also related to the fourth embodiment, but to second specific case, where the two writes come at almost the same time. In this case the second transaction will be rejected using the atomic commit check at the UPF 120 in which a single configuration cannot be accessed at once as shown in the message chart.
[0189] The following messages are exchanged:
[0190] First SMF instance 112a transmits UPF write message 210a to UPF transaction controller 122 including an updated configuration, first transaction identifier TID1 and last write identifier LW- TID=X. At almost the same time, second SMF instance 112b transmits UPF write message 210b to UPF transaction controller 122 including an updated configuration, second transaction identifier TID2 and last write identifier LW-TID=X. When receiving this message 210b, UPF transaction controller 122 performs atomic commit check 211c and rejects 212b the update message 210b of second SMF instance 112b by transmitting reject message 212b to second SMF instance 112b including the information “cannot write during write”. A confirm message 212a is transmitted to first SMF instance 112a.
[0191] While a particular feature or aspect of the disclosure may have been disclosed with respect to only one of several implementations, such feature or aspect may be combined with one or more other features or aspects of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms "include", "have", "with", or other variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprise". Also, the terms "exemplary", "for example" and "e.g." are merely meant as an example, rather than the best or optimal. The terms “coupled” and “connected”, along with derivatives may have been used. It should be understood that these terms may have been used to indicate that two elements cooperate or interact with each other, regardless whether they are in direct physical or electrical contact, or they are not in direct contact with each other.
[0192] Although specific aspects have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and / or equivalent implementations may be substituted for the specific aspects shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the specific aspects discussed herein.
[0193] Although the elements in the following claims are recited in a particular sequence with corresponding labeling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence.
[0194] Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art readily recognize that there are numerous applications of the disclosure beyond those described herein. While the present disclosure has been described with reference to one or more particular embodiments, those skilled in the art recognize that many changes may be made thereto without departing from the scope of the present disclosure. It is therefore to be understood that within the scope of the appended claims and their equivalents, the disclosure may be practiced otherwise than as specifically described herein.
Claims
CLAIMS:
1. A data entity (120) for routing data traffic (108) of a User Equipment (130) in a communication network based on a network configuration (121) of the data entity (120), the data entity (120) comprising: a control interface (125) for receiving control messages (205, 210) from at least one control entity (110) over the communication network, the control messages being associated with transactions for updating the network configuration (121) of the data entity (120), each transaction being identified by a respective transaction identifier (221); wherein a first control message (205) of the control messages (205, 210) which is associated with a first transaction comprises a read request for retrieving at least parts of the network configuration (121) of the data entity (120); and a data entity transaction controller (122), configured to determine, upon reception of the first control message (205), a last transaction upon which the data entity (120) was last updated, to generate a first identifier (222) of the last transaction and to send the first identifier (222) in a response (207) to the control entity (110); wherein a second control message (210) of the control messages (205, 210) which is associated with the first transaction comprises a write request for updating the data entity (120) with a new network configuration (121’), and a second identifier (222’) of a last transaction upon which the data entity (120) was last updated; wherein the data entity transaction controller (122) is configured to update (214) the data entity (120) with the new network configuration (121’) upon a match of the second identifier (222’) of the last transaction from the second control message (210) with the first identifier (222) of the last transaction generated by the data entity transaction controller (122) upon reception of the first control message (205).
2. The data entity (120) of claim 1, wherein each transaction comprises a write request transported by a respective second control message (210) which is preceded by a read request transported by a respective first control message (205).
3. The data entity (120) of claim 1 or 2, wherein the data entity transaction controller (122) is configured to reject updating (214) the data entity (120) with the new network configuration (12T) if the second identifier (222’) of the last transaction from the second control message (210) is not matching the first identifier (222) of the last transaction generated by the data entity transaction controller (122) upon reception of the first control message (205).
4. The data entity (120) of any of the preceding claims, wherein the data entity transaction controller (122) is configured to send a confirmation message (212) to the control entity (110) before updating (214) the data entity (120) with the new network configuration (12T), and to update (214) the data entity (120) with the new network configuration (12T) upon reception of a commit message (213) to the confirmation message (212) from the control entity (110).
5. The data entity (120) of claim 4, wherein the data entity transaction controller (122) is configured to set, upon sending the confirmation message (212) to the control entity (110), a lock-flag (223), the lock-flag (223) indicating a locking of an update mechanism for updating (214) the data entity (120) with a new network configuration (12T).
6. The data entity (120) of claim 5, wherein the data entity transaction controller (122) is configured to release, upon reception of the commit message (213) from the control entity (110), the lock-flag (223), in order to enable the update mechanism for updating (214) the data entity (120) with a new network configuration (12T).
7. The data entity (120) of any of the preceding claims, wherein the data entity (120) is based on a user plane function, UPF, entity according to 3GPP standardization which is enhanced by functionalities of the control interface (125) and the data entity transaction controller (122).
8. The data entity (120) of any of the preceding claims, comprising a plurality of control interfaces (125a, 125b, 125c) for receiving messages from a plurality of control entities (110a, 110b, 110c), the messages being associated with different transactions, wherein the data entity transaction controller (122) is configured to reject an updating (214) of the data entity (120) according to a write request (210b) of a second control entity (110b) upon sending of a confirmation message (212) for updating (214) the data entity (120) with a new network configuration (12T) according to a write request (210a) of a first control entity (110a).
9. The data entity (120) of any of the preceding claims, wherein the data entity transaction controller (122) is configured to implement a two- phase locking protocol for realizing conflict-free interaction between the data entity (120) and the plurality of control entities (110a, 110b, 110c).
10. The data entity (120) of any of the preceding claims, wherein the data entity transaction controller (122) is configured to precommit the update (214) if the second identifier (222’) of the last transaction in the second control message (210) corresponds to the first identifier (222) of the last transaction in the response (207) to the first control message (205).
11. A control entity (110) for controlling a data entity (120) according to any of the preceding claims, the control entity (110) comprising: a management interface (115) for receiving messages from a management entity (140), the messages being associated with transactions for updating the network configuration (121) of the data entity (120), each transaction being identified by a respective transaction identifier (221); wherein a first management message (204) associated with a first transaction comprises a read request for retrieving at least parts of the network configuration (121) of the data entity (120); and wherein a second management message (209) associated with the first transaction comprises a write request for updating the data entity (120) with a new network configuration (12T); and a control entity transaction controller (112), configured to transmit, upon reception of the first management message (204), the first control message (205) via the control interface (125) to the data entity (120) and to inform (208) the management entity (140) about the response (207) of the data entity (120); wherein the control entity transaction controller (112) is configured to transmit, upon reception of the second management message (209), the second control message (210), via the control interface (125) to the data entity (120) and to inform (216) the management entity (140) about a result of updating (214) the data entity (120) with the new network configuration (12T).
12. The control entity (110) of claim 11, wherein the control entity transaction controller (112) is configured to determine or obtain a transaction identifier (221) of a transaction based on one or a combination of the following identifiers, IDs:a request ID of a certain request between two network function entities of the communication network, a slice ID of a certain slice of the communication network, an application ID of an application set by an application function entity of the communication network, and a network function ID of a network function entity of the communication network.
13. The control entity (110) of claim 12, wherein the control entity transaction controller (112) is configured to determine the identifier of a transaction based on a hash function applied to one or a combination of the request ID, the slice ID, the application ID and the network function ID.
14. The control entity (110) of any of claims 11 to 13, wherein the control entity transaction controller (112) is configured to inform (203) the management entity (140) about an identifier of a transaction upon receiving a message (202) indicating a start of the transaction.
15. The control entity (110) of any of claims 11 to 14, wherein the control entity (110) is based on a session management function, SMF, entity according to 3GPP standardization which is enhanced by functionalities of the management interface (115), the control interface (125) and the control entity transaction controller (112).