Techniques for synchronizing data entities and control entities in communication network
By introducing transactional interaction protocol and two-stage locking mechanism into the 6G communication network, the synchronization problem between UPF and SMF is solved, and the consistency between efficient and scalable control planes and data planes is achieved, and multiple SMFs control a single UPF scenario is supported.
Patent Information
- Application Number
- CN202380086890.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-01-02
- Publication Date
- 2025-08-08
AI Technical Summary
In 6G communication networks, it is difficult for the prior art to achieve efficient and scalable control plane and data plane consistency and synchronization between UPF and SMF. Especially in the scenario where multiple SMFs control a single UPF, there are bottlenecks and synchronization problems.
By introducing a transactional interaction protocol, a two-stage locking mechanism and a transaction ID (TID) mechanism are adopted to ensure the state synchronization and consistency between data entities (such as UPF) and control entities (such as SMF), avoid conflict modifications, and realize distributed control.
It realizes efficient and scalable state synchronization and consistency between UPF and SMF, supports the deployment of thousands of SMFs and UPFs, avoids conflicts and bottlenecks, and improves the scalability and fault tolerance of the mobile core network.
Smart Images
Figure CN120457665A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of synchronizing data entities and control entities that process data traffic in communication networks, particularly those standardized according to 5G and 6G and beyond, and controlling user plane function (UPF) entities by session management function (SMF) entities in accordance with 3GPP standards. In particular, the present disclosure relates to consistency and synchronization between control plane and data plane network functions (NFs). Background Art
[0002] 6G standardization will enable operators to use virtual and programmable resources for both the data and control planes. With the prevalence of advanced virtualization technologies, a distributed resource platform (substrate) can be realized that can execute different types of applications and network functions.
[0003] Furthermore, with the current increase in mobile network users, from humans to robots and even household appliances, the network requires more user plane functions (UPFs). The primary purpose of UPFs is to handle user data plane traffic along the path from user equipment (UE) to the data network. Naturally, controlling so many UPFs requires the deployment of more session management functions (SMFs). However, more SMFs mean increased coordination between UPFs and SMFs. This interaction is often difficult to achieve, especially in a scalable and efficient manner. More importantly, UPFs will be hosted and executed like any other control plane network function (NF). Advanced virtualization technologies make it possible to run thousands of UPFs in a network, enabling them to be activated and deactivated in seconds. Therefore, scalable and efficient control of dynamic UPFs is essential. However, current mobile core architectures lack support for consistency and synchronization between the control and data planes, impacting the scalability and fault tolerance of mobile core networks. Summary of the Invention
[0004] The present disclosure provides a solution for scalable and efficient control of dynamic UPFs.
[0005] In particular, a solution for consistency and synchronization between the control plane and the data plane of a mobile core network is provided.
[0006] The above and other objects are achieved by the features of the independent claims. Further implementations are apparent from the dependent claims, the description and the drawings.
[0007] The general scenario of this disclosure revolves around mobile networks, where the goal is to improve quality of service (QoS) to achieve service guarantees for resource-intensive applications (e.g., NPN, mMTC, and V2X). Furthermore, these applications will be handled by a deep edge delivery system within the 3GPP network. This will require the presence of numerous SMFs and UPFs within the network, significantly increasing the number of control messages and events.
[0008] Typically, different interactions with UPFs and SMFs will go beyond the traditional one-to-one interaction and session initiation between a single UPF and a single SMF. This cross-interaction between any UPF and any SMF will occur due to, for example, user mobility, application mobility, low-latency applications, redundancy, failover, etc.
[0009] A major challenge with this cross-interaction is that traditionally, UPF-SMF interactions have been limited to request / response types, meaning one-to-one interactions between a UPF and an SMF. Consequently, when multiple SMFs are deployed to control a single UPF, bottlenecks and synchronization issues arise. This disclosure proposes solutions for scenarios where multiple SMFs control a single UPF. It also provides solutions for scenarios where multiple SMFs control multiple UPFs.
[0010] This disclosure also provides solutions for the following scenarios, as follows:
[0011] (A) Synchronization of individual layers
[0012] (B) Multiple N4 / Sx interfaces
[0013] (C)SDN and Controller Distribution
[0014] The first option for scenario A (synchronization of separate layers) relies on interactions and state synchronization within the control plane, meaning that interactions between SMFs can partially achieve synchronization. The main limitation of this approach is that it cannot synchronize the UPF (or network) state across the SMFs. Furthermore, it is not conducive to scalability or requires some kind of node hierarchy (e.g., a master SMF), which is unreliable.
[0015] The second option for scenario (A) is based on interaction and state synchronization within the data plane. This means that interactions between UPFs can achieve synchronization of UPF states. A major limitation of this is that it does not allow network-level and UPF-local changes to be propagated to the SMF, i.e., in this case, a consistent view cannot be achieved at both the CP and UP levels.
[0016] The solution provided by the present disclosure provides interaction between SMF and UPF for state synchronization to achieve consistency between the control plane layer and the data plane layer.
[0017] In scenario B (multiple N4 / Sx interfaces), multiple N4 interfaces enable a single UPF to establish multiple N4 connections with multiple SMFs. Integrating multiple SMFs with a single UPF can create a multi-controller arrangement (thus causing the well-known "split-brain problem"). This occurs due to elasticity, on-demand UPF creation (virtual resources), and on-demand SMF creation (virtual resources).
[0018] The limitations of scenario B are as follows: UPF configuration updates are handled on a first-come, first-served basis. Known issues with consistency and versioning limit the usability of this approach. There are conflicting configurations, such as write-during-read, read-during-write, and rollbacks.
[0019] The solution provided by the present disclosure provides interaction between SMF and UPF for state synchronization, thereby overcoming the above limitations of scenario B.
[0020] In scenario C (SDN and controller distribution), the main way to achieve scalability and low latency is through the separation (= distribution) of the control path (CP) and the data path (DP).
[0021] (a) To be successful, it must be lightweight: hard-wiring through manual configuration, limiting data partitioning (as in the Raft / PAXOS algorithms), installing predefined hierarchies leading to heavy configuration, highly specialized instances (not just replicas), and therefore complexity, which can lead to errors.
[0022] (b) A distributed controller runs as a set of instances that can be added or removed without disruption.
[0023] (c) Instances collaborate with each other to present a single logical centralized controller for the application.
[0024] For scalable SDN systems, there are two types of controller designs: loosely coupled controllers (such as HyperFlow and SCL), or tightly coupled controllers (such as ONOS and ONYX).
[0025] In loosely coupled controllers (such as HyperFlow and SCL), controller instances implement eventual consistency mechanisms, implement publish / subscribe messaging, and implement gossip protocols. Network events and event reprocessing are distributed across the cluster. This loosely coupled controller has the following limitations: Unhandled conflicts can lead to split-brain (e.g., partial paths) and scalability issues, as each instance locally reprocesses every event received from the network.
[0026] Tightly coupled controllers (e.g., ONOS, Onyx) use strong consistency protocols (e.g., Raft, Paxos) to coordinate the execution of instances in the cluster. A limitation of such tightly coupled controllers is related to their fault tolerance: the consensus leader handles updates, which creates a single point of failure.
[0027] The solution provided by this disclosure provides for state synchronization between the SMF and UPF, thereby overcoming the aforementioned limitations of scenario C. By applying the disclosed solution, good scalability and fault tolerance can be achieved. The disclosed solution is applicable to mobile network SMF / UPF interaction and architectural constraints.
[0028] The disclosed scheme can achieve system consistency instead of just achieving synchronization of a single layer and synchronization of shared data of a single layer.
[0029] For multiple N4 interfaces, simply creating more links to the UPF is not sufficient. The disclosed scheme provides scalable control and consistency in both data storage and command scheduling across controlling and controlled instances (ordering of command packets, atomic execution, etc.).
[0030] For SDN and controller distribution, instead of introducing multiple controller instances (which require a lot of coordination to maintain this state), the disclosed solution keeps the state on the node (UPF) and allows the controller (SMF) to read and write directly. The disclosed solution is based on transaction capabilities, which are described below.
[0031] The disclosed solution provides transactional UPF / SMF interactions for distributed control. The interaction between the control plane (SMF) and the data plane (UPF) is enhanced to enable transactional control. Typically, this supports storing the state of the data plane network in the UPF and enabling the SMF to query it as needed before making changes. These transactional methods enable the deployment of thousands of SMFs and UPFs alongside each other.
[0032] Key points of the disclosed solution include:
[0033] (1) New modules for UPF / SMF transaction interaction: SMF transaction controller and UPF transaction controller.
[0034] (2) New interfaces: SMF / management plane northbound interface, SMF / UPF transaction interface.
[0035] (3) New IDs: transaction ID (TID) and last write transaction ID (LW-TID).
[0036] (4) New process: Implement transaction interaction between SMF and UPF.
[0037] The overall architecture is as follows Figure 1 shown and described below.
[0038] This disclosure proposes a conflict resolution mechanism for a large number of UPFs controlled by multiple SMFs (controllers). This solution enhances the interaction between SMFs and UPFs through a two-phase locking protocol. This ensures atomic ordering of control commands from non-coordinating SMFs and avoids potentially conflicting modifications on the same UPF. This provides technical advantages of scalability and simplicity.
[0039] The design provided in this disclosure is based on a distributed storage and database system. A specific interaction protocol is provided to synchronize state, especially in disconnected environments where state needs to be quickly retrievable. The focus is on SMF UPF-specific interactions.
[0040] This design is further based on "lock before write". This ensures a deadlock-free locking mechanism, where the lock will be released if no transaction is sent. The focus is on SMF UPF-specific interactions.
[0041] The design is further based on universal distributed consensus. The disclosed scheme is SMF / UPF specific and has a direct impact on the new architectural design of 6G systems.
[0042] To describe the present disclosure in detail, the following terms, abbreviations, and symbols will be used:
[0043] MEC Multi-Access Edge Computing
[0044] RAN Radio Access Network
[0045] VR Virtual Reality
[0046] SLA Service Level Agreement
[0047] UPF user plane function; user plane function entity
[0048] UE User Equipment
[0049] SMF Session Management Function; Session Management Function Entity
[0050] 3GPP Third Generation Partnership Project
[0051] AF application function, application function entity
[0052] PCF Policy Control Function, Policy Control Function Entity
[0053] AMF access and mobility management function; access and mobility management function entity
[0054] API application programming interface
[0055] A service-level agreement (SLA) is a contract between a service provider and its customers that documents the services the provider will provide and defines the service standards the provider is obligated to meet. Service providers need SLAs to help manage customer expectations and define the severity levels and circumstances under which they are not responsible for outages or performance issues. Customers also benefit from SLAs because the contract describes the performance characteristics of the service (which can be compared with other providers' SLAs) and outlines how to correct service issues.
[0056] Edge computing, or the provision of on-demand computing services very close to the end user, is enabling next-generation applications, particularly in 6G mobile communication systems. The primary advantage of deep (meaning as close to the user as possible) edge computing is its ability to deliver services with very low latency and high throughput, which is crucial for demanding applications such as video conferencing, virtual reality, and drone control. Because edge nodes are deployed close to the end user, optimal service delivery conditions are possible.
[0057] According to a first aspect, the present disclosure relates to a data entity for routing data traffic of a user equipment in a communications 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 via the communications network, the control messages being associated with transactions for updating the network configuration of the data entity, each transaction being identified by a corresponding transaction identifier; wherein a first control message of the control messages associated with a first transaction comprises a read request for retrieving at least part of the network configuration of the data entity; a data entity transaction controller for determining, after receiving the first control message, a last transaction in which the data entity was last updated, generating a first identifier for the last transaction and sending the first identifier in a response to the control entity; wherein a second control message of the control messages associated with the first transaction comprises a write request for updating the data entity with a new network configuration and a second identifier for the last transaction in which the data entity was last updated; wherein the data entity transaction controller is configured to update the data entity with the new network configuration when the second identifier of the last transaction from the second control message matches the first identifier of the last transaction generated by the data entity transaction controller after receiving the first control message.
[0058] This data entity avoids the need for multiple controller instances, which would require extensive coordination to maintain state. Instead, the data entity retains its network configuration—its state—and allows direct reading and writing by the control entity or controller instance. The data entity is transaction-enabled to avoid conflicts.
[0059] Data entities provide transactional interactions for distributed control. The interaction between control entities (such as SMF entities) and data entities (such as UPF entities) is enhanced to implement transactional control. This enables the storage of network configurations, such as the state of data entities, and enables control entities to query them as needed before changing them. The transactional approach enables the deployment of thousands of control entities (such as SMFs) and data entities (such as UPFs) together.
[0060] A control message sent from a control entity (e.g., SMF) to a data entity (e.g., UPF) includes a transaction identifier (TID) for identifying the corresponding transaction handled by the control message. In particular, a control message is a separate message, wherein other control messages for other transactions may be transmitted between two control messages for a specific transaction.
[0061] The first control message and the second control message belong to the control messages introduced above.
[0062] The network configuration of a data entity may represent the state of the data entity, e.g. Figure 1 The new network configuration of the data entity may represent a new state of the data entity, for example, Figure 1 New UPF status shown.
[0063] The first identifier of the last transaction in which the data entity was last updated (also referred to as "LW-TID" in the figure) is generated by the data entity transaction controller and sent to the controlling entity in a response.
[0064] like Figure 2 As shown, a second identifier of the last transaction in which the data entity was last updated (also referred to as "LW-TID" in the figure) is received from the control entity in a second message.
[0065] In an exemplary implementation of the data entity, each transaction includes a write request transmitted by a corresponding second control message, the write request preceding a read request transmitted by a corresponding first control message.
[0066] This implements a two-phase locking protocol, which is the simplest and most efficient way to achieve conflict-free interaction between one or more data entities and one or more control entities.
[0067] Control messages for multiple different transactions are received. A control message for a specific transaction includes a transaction identifier (TID) for the specific transaction. The control message for the specific transaction includes a corresponding first control message with the specific TID and a corresponding second control message with the specific TID. The second control message with the specific TID is not necessarily received after the first control message with the same TID. Other first or second control messages with other TIDs may be received in between.
[0068] In an exemplary implementation of the data entity, the data entity transaction controller is configured to refuse to update the data entity with the new network configuration if the second identifier of the last transaction from the second control message does not match the first identifier of the last transaction generated by the data entity transaction controller after receiving the first control message.
[0069] This provides the advantage that a two-phase lock is achieved, wherein the first and second identifiers of the last transaction must match before an update of the network configuration is performed.
[0070] 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 update the data entity with the new network configuration after receiving a commit message for the confirmation message from the control entity.
[0071] This provides the advantage of additional security, since the update is only activated after a commit message is received from the controlling entity.
[0072] In an exemplary implementation of the data entity, the data entity transaction controller is configured to set a lock flag after sending the confirmation message to the control entity, the lock flag indicating that an update mechanism for updating the data entity with a new network configuration is locked.
[0073] This provides the advantage that the lock flag implements a locking mechanism to avoid inadvertent updates to the network configuration of the data entity.
[0074] In an exemplary implementation of the data entity, the data entity transaction controller is configured to release the lock flag after receiving the commit message from the control entity so as to enable the update mechanism for updating the data entity with a new network configuration.
[0075] This offers the advantage that the lock can be released safely.
[0076] In an exemplary implementation of the data entity, the data entity is based on a user plane function (UPF) entity standardized according to 3GPP, and the UPF entity is enhanced with the functionality of the control interface and the data entity transaction controller.
[0077] This provides the advantage that the UPF entity is enhanced with transaction capabilities that enable consistency and synchronization between the UPF entity and the SMF entity.
[0078] In an exemplary implementation of a data entity, the data entity includes: multiple control interfaces for receiving messages from multiple control entities, the messages being associated with different transactions, wherein the data entity transaction controller is configured to: after sending a confirmation message for updating the data entity with a new network configuration according to a write request from a first control entity, refuse to update the data entity according to a write request from a second control entity.
[0079] This provides the advantage that, in scenarios where a data entity has multiple control interfaces to multiple control entities, consistency and synchronization between the data entity and the control entity can be supported. Conflicts can be avoided due to the transaction capability.
[0080] In an exemplary implementation of the data entity, the data entity transaction controller is configured to implement a two-phase locking protocol for achieving conflict-free interaction between the data entity and the plurality of control entities.
[0081] As mentioned above, this provides the advantage of conflict-free interaction between the data entity and multiple control entities.
[0082] In addition to two-phase locking, other protocols can also be used to implement different types of concurrency, such as timestamp sorting protocol, multi-version concurrency control, verification concurrency control, etc.
[0083] In an exemplary implementation of a data entity, the data entity transaction controller is configured to pre-commit 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.
[0084] This provides the advantage that both entities, data entity and control entity, must agree before activation can be updated. This achieves a higher level of security.
[0085] According to a second aspect, the present disclosure relates to a control entity for controlling a data entity according to any one of the above claims, the control entity comprising: a management interface for receiving a message from a management entity, the message being associated with a transaction for updating the network configuration of the data entity, each transaction being identified by a corresponding transaction identifier; wherein the first management message associated with the first transaction comprises a read request for retrieving at least part of the network configuration of the data entity; wherein the second management message associated with the first transaction comprises a write request for updating the data entity using a new network configuration; a control entity transaction controller for, after receiving the first management message, sending the first control message to the data entity through the control interface and notifying the management entity of the response of the data entity; wherein the control entity transaction controller is for: after receiving the second management message, sending the second control message to the data entity through the control interface and notifying the management entity of the result of updating the data entity using the new network configuration.
[0086] Control entities implement transactional interactions for distributed control. Enhance the interaction between control entities (e.g., SMF entities) and data entities (e.g., UPF entities) to implement transactional control. This enables the storage of network configurations, such as the state of data entities, and enables control entities to query them as needed before making changes. The transactional approach enables the deployment of thousands of control entities (e.g., SMFs) and data entities (e.g., UPFs) alongside each other.
[0087] In an exemplary implementation of the control entity, the control entity transaction controller is used 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 specific request between two network function entities of the communication network; a slice ID of a specific slice of the communication network; an application ID of an application set by an application function entity of the communication network; or a network function ID of a network function entity of the communication network.
[0088] This provides the advantage that each transaction is uniquely identified by a transaction identifier, thereby increasing the security of transaction interactions.
[0089] In an exemplary implementation of the control entity, the control entity transaction controller is used to determine the identifier of the transaction based on a hash function, which is applied to one or a combination of the request ID, the slice ID, the application ID and the network function ID.
[0090] This provides the advantage that a unique transaction identifier can be provided.
[0091] In an exemplary implementation of the control entity, the control entity transaction controller is configured to notify the management entity of an identifier of the transaction upon receiving a message indicating the start of the transaction.
[0092] This offers the advantage that the same transaction identification can be used in every instance of the communication network.
[0093] In an exemplary implementation of the control entity, the control entity is based on a session management function (SMF) entity standardized according to 3GPP, the SMF entity being enhanced with functionalities of the management interface, the control interface and the control entity transaction controller.
[0094] This provides the advantage that the SMF entity is enhanced with transaction capabilities that enable consistency and synchronization between the UPF entity and the SMF entity. BRIEF DESCRIPTION OF THE DRAWINGS
[0095] Other embodiments of the present disclosure will be described in conjunction with the following drawings, in which:
[0096] Figure 1 shows a schematic diagram of a communication network 100 provided by the present disclosure;
[0097] Figure 2 An exemplary message flow diagram 200 provided by the present disclosure is shown, which illustrates exemplary message delivery between a control entity (e.g., an SMF entity) and a data entity (e.g., a UPF entity);
[0098] Figure 3 A block diagram of a 3GPP system 300 including new functions provided by the present disclosure is shown;
[0099] Figure 4 A block diagram showing a scenario where multiple SMFs control a single UPF;
[0100] Figure 5 An exemplary message flow diagram 500 is shown, which illustrates a scenario where two SMF instances attempt to write to a UPF but with a certain time delay;
[0101] Figure 6 An exemplary message flow diagram 600 is shown, illustrating a scenario where two SMF instances attempt to write to a UPF, and the two writes occur at approximately the same time. DETAILED DESCRIPTION
[0102] In the following detailed description, reference is made to the accompanying drawings, which form a part of this specification, and which illustrate, by way of illustration, specific aspects of the present disclosure that may be practiced. It should be understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be construed in a limiting sense, and the scope of the present disclosure is defined by the appended claims.
[0103] It should be understood that discussions related to describing a method can also apply to a corresponding device or system for performing the method, and vice versa. For example, if a specific method step is described, the corresponding device can include a unit for performing the described method step, even if such a unit is not specifically illustrated or described in the figure. In addition, it should be understood that unless otherwise explicitly stated, the features of the various exemplary aspects described herein can be combined with each other.
[0104] Figure 1 FIG. 1 shows a schematic diagram of a communication network 100 provided by the present disclosure.
[0105] The communication network 100 (or also referred to as the communication system 100) includes a data entity 120 (also referred to as a data plane entity or a user plane function (UPF) entity or a UPF network entity) and a control entity 110 (also referred to as a control plane entity or a session management function (SMF) entity or an SMF network entity).
[0106] The data entity 120 is used to route data traffic 108 of one or more user equipment (UE) 130 in the communication network 200 based on the network configuration 121 of the data entity 120. The network configuration can be the state of the data entity 120. Figure 1The network configuration 121, also referred to as the UPF state, includes routing tables, the state of the input and output interfaces of the data entity 120, and the like. The network configuration 121 or the UPF state can change dynamically. For example, after a certain time instance, based on the processing of the data entity 120 and the receipt of input / output and control messages, a new network configuration 121' or a new UPF state 121' may exist.
[0107] The data entity 120 includes a control interface 125 and a data entity transaction controller 122 .
[0108] The control interface 125 is configured to receive control messages 205, 210 from at least one control entity 110 via a communication network, for example Figure 2 As shown. Although Figure 1 Only one control entity 110 is shown, but there may be multiple such control entities that send corresponding 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 corresponding transaction identifier (TID) 221, e.g. Figure 2 shown.
[0109] The first control message 205 of the control messages 205 , 210 associated with the first transaction comprises a read request for retrieving at least part of the network configuration 121 of the data entity 120 .
[0110] The data entity transaction controller 122 is configured to determine the last transaction (LW-TID) by which the data entity 120 was last updated after receiving the first control message 205. The data entity transaction controller 122 is configured to generate a first identifier 222 (e.g., Figure 2 ), and sends the first identifier 222 (as shown in FIG. Figure 2 details shown).
[0111] The second control message 210 of the control messages 205, 210 associated with the first transaction comprises a write request for updating the data entity 120 with the new network configuration 121' and a second identifier 222' of the last transaction in which the data entity 120 was last updated, such as Figure 2 shown.
[0112] The data entity transaction controller 122 is configured to update (214) the data entity 120 with the new network configuration 121 ′ when the second identifier 222 ′ of the last transaction from the second control message 210 matches the first identifier 222 of the last transaction generated by the data entity transaction controller 122 after receiving the first control message 205 , such as Figure 2 Shown in detail.
[0113] As described above, the control message sent from the control entity 110 (e.g., SMF) to the data entity 120 (e.g., UPF) includes a transaction identifier (TID) 221 for identifying the corresponding transaction handled by the control message. In particular, the control messages 205, 210 are separate messages, wherein other control messages for other transactions may be transmitted between two control messages for a specific transaction.
[0114] The first control message 205 and the second control message 210 belong to the control messages 205 , 210 described above.
[0115] The network configuration of the data entity 120 may represent a state 121 of the data entity 120, e.g. Figure 1 The new network configuration of the data entity 120 may represent a new state 121' of the data entity 120, e.g. Figure 1 The new UPF state 121' is shown.
[0116] The first identifier 222 of the last transaction in which the data entity 120 was last updated (also referred to as “LW-TID” in the figure) is generated by the data entity transaction controller 122 and sent to the control entity 110 in the response 207 .
[0117] like Figure 2 As shown, a second identifier 222 ′ (also referred to as “LW-TID” in the figure) of the last transaction by which the data entity 120 was last updated is received from the control entity 110 in a second message 210 .
[0118] Each transaction may include a write request conveyed by a corresponding second control message 210 , the write request preceding a read request conveyed by a corresponding first control message 205 .
[0119] Control messages for multiple different transactions are received. A control message for a specific transaction includes a transaction identifier (TID) for the specific transaction. The control message for the specific transaction includes a corresponding first control message with the specific TID and a corresponding second control message with the specific TID. The second control message with the specific TID is not necessarily received after the first control message with the same TID. Other first or second control messages with other TIDs may be received in between.
[0120] The data entity transaction controller 122 may be configured to refuse to update (214) the data entity 120 with the new network configuration 121′ if the second identifier 222′ of the last transaction from the second control message 210 does not match the first identifier 222 of the last transaction generated by the data entity transaction controller 122 after receiving the first control message 205.
[0121] The data entity transaction controller 122 may be configured to send a confirmation message 212 to the control entity 110 before updating 214 the data entity 120 with the new network configuration 121', for example Figure 2 The data entity transaction controller 122 may be configured to: upon receiving a commit message 213 for a confirmation message 212 from the control entity 110, update (214) the data entity 120 with the new network configuration 121 ', such as Figure 2 shown.
[0122] The data entity transaction controller 122 may be configured to set a lock flag 223 after sending a confirmation message 212 to the control entity 110, such as Figure 2 The lock symbol 223 indicates that the update mechanism for updating 214 the data entity 120 with the new network configuration 121 ′ is locked.
[0123] The data entity transaction controller 122 may be configured to release the lock flag 223 upon receiving the commit message 213 from the control entity 110 in order to enable an update mechanism for updating 214 the data entity 120 with the new network configuration 121 ′.
[0124] As mentioned above, the data entity 120 may also be referred to as a UPF entity. The data entity 120 or UPF entity may be based on a user plane function (UPF) entity standardized according to 3GPP, and the UPF entity is enhanced by the functions of the control interface 125 and the data entity transaction controller 122, as described above and below. Figures 2 to 6 As stated.
[0125] The data entity 120 may include a plurality of control interfaces 125a, 125b and 125c, such as Figure 4 As shown, it is used to receive messages from multiple control entities 110a, 110b, 110c, which are similar to Figure 1 The control entity 110 is shown and described below. These messages may be associated with different transactions.
[0126] The data entity transaction controller 122 may be configured to, after sending a confirmation message 212 for updating 214 the data entity 120 with the new network configuration 121′ according to the write request 210a of the first control entity 110a, refuse to update 214 the data entity 120 according to the write request 210b of the second control entity 110b, e.g. Figure 2 shown.
[0127] The data entity transaction controller 122 may be configured to implement a two-phase locking protocol for achieving conflict-free interaction between the data entity 120 and the plurality of control entities 110 a , 110 b , 110 c .
[0128] In addition to two-phase locking, other protocols can also be used to implement different types of concurrency, such as timestamp sorting protocol, multi-version concurrency control, verification concurrency control, etc.
[0129] The data entity transaction controller 122 may be configured to: 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, then pre-commit the update 214, e.g. Figure 2 Shown in detail.
[0130] The control entity 110 is used to control a data entity 120 , ie the data entity 120 as described above or any other data entity among a plurality of data entities in the communication network 100 .
[0131] The control entity 110 includes a management interface 115 and a control entity transaction controller 112 that is different from the above-mentioned data entity transaction controller 122 .
[0132] The management interface 115 is used to receive data from the management entity 140 ( Figure 1 For example, the management entity 140 may be Figure 2 These control messages are associated with transactions for updating the network configuration 121 of the data entity 120. Each transaction is identified by a corresponding transaction identifier (TID) 221, such as Figure 2 shown.
[0133] The first management message 204 , which may be associated with the first transaction, includes a read request to retrieve at least part of the network configuration 121 of the data entity 120 .
[0134] The second management message 209 , which may be associated with the first transaction, comprises a write request to update the data entity 120 with the new network configuration 121 ′.
[0135] The control entity transaction controller 112 is configured to: after receiving the first management message 204, send a first control message 205 to the data entity 120 via the control interface 125, for example, Figure 2 As shown, the management entity 140 is notified (208) of the response 207 of the data entity 120.
[0136] The control entity transaction controller 112 is configured to: after receiving the second management message 209, send a second control message 210 to the data entity 120 via the control interface 125, for example, Figure 2 As shown, the management entity 140 is informed (216) of the result of updating (214) the data entity 120 with the new network configuration 121'.
[0137] The control entity transaction controller 112 can be used 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 specific request between two network function entities of a communication network, a slice ID of a specific slice of a 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.
[0138] The controlling entity transaction controller 112 may be configured to determine an identifier for the transaction based on a hash function applied to one or a combination of a request ID, a slice ID, an application ID, and a network function ID.
[0139] The controlling entity transaction controller 112 may be configured to, upon receiving the message 202 indicating the start of a transaction, inform (203) the managing entity 140 of an identifier of the transaction.
[0140] As described above, the control entity 110 may also be referred to as an SMF entity. The control entity 110 may be based on a session management function (SMF) entity standardized according to 3GPP, enhanced by the functions of the management interface 115, the control interface 125, and the control entity transaction controller 112, as described in this disclosure.
[0141] The data entity 120 may be a UPF entity or simply referred to as UPF 120. The control entity 110 may be an SMF entity or simply referred to as SMF 110.
[0142] Figure 1The main points of the disclosed solution are shown, which include: (1) New modules for UPF / SMF transaction interaction: SMF transaction controller 112; and UPF transaction controller 122. (2) New interfaces: SMF / management plane northbound interface 115; SMF / UPF transaction interface 125. (3) New ID: Figure 2 The transaction ID (TID) 221 shown in FIG. Figure 2 The last write transaction ID (LW-TID) 222 and 222' are shown. (4) A new process for implementing transaction interaction between SMF 110 and UPF 120.
[0143] SMF transaction controller 112 is used to control transactions with UPF 120; provide a northbound API (for northbound interface 115); implement a concurrency control mechanism for scheduling concurrent read and write operations with UPF 120; and provide an atomic commit protocol coordinator.
[0144] The UPF transaction controller 122 is used to act as a bookkeeper for the transaction, tracking its progress and communicating with the SMF 110; provide an SMF control API; and provide atomic commit protocol participants.
[0145] The SMF / management plane northbound interface 115 is used to implement control and setting information on the SMF 110.
[0146] The SMF / UPF transaction interface 125 is used to signal the start of a transaction via the startTransaction() command, retrieve part of the network state via the read(...) command, and update the network, ie, change the UPF / SMF to the desired state, via the transactionalUpdate(...) command.
[0147] Transactions between participating functions (management, SMF, UPF) can use a two-phase process to support read and write updates, where in phase 1, the network function (NF) reads from the network state; in phase 2, the NF updates the network state in an atomic manner.
[0148] For the ID in mobile network transaction interactions, a new globally unique identifier is introduced as follows:
[0149] Transaction ID (TID): The SMF transaction controller 112 stamps all commands (read and write) within a transaction with a transaction ID (TID) before sending them to the UPF transaction controller 122.
[0150] Last write transaction ID (LW-TID): The UPF transaction controller 122 identifies the transaction that last updated the UPF (the last write transaction ID (LW-TID)). The UPF transaction controller 122 sends back the last write transaction ID (LW-TID) whenever replying to a read. The SMF transaction controller 112 uses the LW-TID to associate writes from the second phase of the transaction with the correct network status read. The UPF transaction controller 122 rejects writes with outdated LW-TIDs.
[0151] As mentioned above, the transaction ID may be associated with and or include part of an existing ID in the 3GGP network using the following options:
[0152] (1) Request ID of a specific NF-NF request. Each request between any two NFs will have a specific ID. This ID can then be used to influence the transaction ID.
[0153] (2) Slice ID: This is the ID of a specific slice and can be used to generate transaction IDs so that there is isolation between transactions in different slices.
[0154] (3) APP ID: This is the ID of the application in use set by the application function (AF), which then uses it to affect the transaction ID.
[0155] (4) NF ID: In a 5G or 6G system, each NF will have an ID. This NF ID can then be used to generate a transaction ID.
[0156] Additionally, hash functions can be used, as described below. Any of the above IDs can be used to influence the transaction ID through a hash function. A hash function can take any set of information as input and generate a unique ID or output that is sensitive to any changes in the input. This means it is unique to that specific set of IDs, thus generally ensuring that collisions will not occur.
[0157] The generation of transaction IDs can be done by the SMF 110 or any other network function. In one example, these IDs can be generated by the network repository function (NRF). Since the NRF can track all requests for discovering other NFs, it may be important to request the generation of transaction IDs before starting a transaction.
[0158] In addition, a new network function can be created specifically for generating transaction IDs. This network function can be called a transaction repository function (TRF), which is similar to the NRF and is responsible for generating transaction IDs for other network functions.
[0159] Figure 2 An exemplary message flow diagram 200 provided by the present disclosure is shown, which illustrates exemplary message delivery between a control entity (eg, an SMF entity) and a data entity (eg, a UPF entity).
[0160] Messages are exchanged between the application / management layer 140 and the SMF 110 via the northbound interface 115, and between the SMF 110 and the UPF 120 via the SMF / UPF transaction interface 125, as described above in conjunction with Figure 1 As stated.
[0161] Based on trigger event 201, application / management layer 140 sends a startTransaction() message 202 to SMF transaction controller 112, which responds 203 by sending TID 221 to application / management layer 140. Application / management layer 140 then sends a read() message 204 to SMF transaction controller 112 including the configuration and TID.
[0162] SMF transaction controller 112 sends the above-mentioned information to UPF transaction controller 122 Figure 1 The first control message 205 is a UPF read (TID) message 205 including a TID 221. After receiving the first control message 205, the UPF transaction controller 122 generates (206) an LW-TID 222, i.e., the first identifier 222 of the last transaction generated by the UPF transaction controller 122, and sets the lock flag to zero, e.g., as described above in conjunction with Figure 1 The UPF transaction controller 122 responds to the first control message 205 using a UPF read response message 207 including the TID 221 and the LW-TID 222 .
[0163] When the SMF transaction controller 112 receives this UPF read response message 207, the SMF transaction controller 112 sends a UPF read response message 208 including the TID 221 to the application / management layer 140. The application / management layer 140 may then decide to perform an update and send a transaction update message 209 including the updated configuration 209 and the TID 221 to the SMF transaction controller 112. Upon receiving this message 209, the SMF transaction controller 112 sends the UPF transaction controller 122 the transaction update message described above in conjunction with Figure 1 The second control message, ie, the UPF write message 210, includes the updated configuration TID 221 and the second identifier 222' (as described above in conjunction with Figure 1 as described above, which is also named LW-TID).
[0164] When the UPF transaction controller 122 receives this second control message 210, the UPF transaction controller 122 pre-commits 211 the update with the LW-TID and sets the lock flag 223 to the TID. The UPF transaction controller 122 then confirms the update by sending an acknowledgement message 212 to the SMF transaction controller 112, and the SMF transaction controller 112 commits this acknowledgement message 212 by responding with a commit message 213.
[0165] Upon receiving the commit message 213, the UPF transaction controller 122 activates 214 the update, where the LW-TID is set to the TID and the lock flag is reset to zero. The UPF transaction controller 122 then sends a completion message 215 to the SMF transaction controller 112, which sends a completion message 216 to the application / management layer 140.
[0166] The functionality of this messaging 200 as described above is as follows.
[0167] When an application or management layer 140 wishes to change the configuration, a transaction is triggered. First, the SMF 110 assigns a TID 221 to this transaction. The first step is to read the network's state and current configuration. This request is then sent to the SMF 110, which then forwards it to the UPF 120. Both requests set the TID 221, allowing both the read and later write requests to be attributed. The UPF 120 then responds with the LW-TID, allowing the application 140 to identify the last transaction that wrote to the network. This response is then sent to the SMF 110, and thus to the application 140.
[0168] The application 140 is now ready to start the transactional 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, and the LW-TID. If the LW-TID from the request and the LW-TID stored at the UPF 120 match (indicated by LW-TID=X in this case), the configuration is pre-committed and the lock flag is set to the TID (i.e., the transaction for this transaction sequence is started). This is then acknowledged to the SMF 110, which will then issue a final commit request that will activate the configuration at the UPF 120. This is then acknowledged to both the SMF 110 and the application 140, concluding the transactional update.
[0169] As above combined Figure 1 As described above, any write request (here transmitted via the second control message 210) must precede a read request (here transmitted via the first control message 205). The read request will have a specific LW-TID that will prevent writes on other configurations. Only when the LW-TID matches the LW-TID used to read the configuration will the transaction update write the configuration using the UPF 120.
[0170] Figure 3 A block diagram of a 3GPP system 300 including new functions provided by the present disclosure is shown.
[0171] The 3GPP system 300 may be based on 3GPP standardization, such as, but not limited to, TS 23.501. Specifically, the communication system 300 may include the following 5G network functions of the 5G reference point architecture, such as specified in 3GPP TS 38.300 and 3GPP TS 23.501: UPF 120, SMF 110, NF 140, AMF 310, PSA 312.
[0172] UPF 120 represents the user plane function. The functions of the 5G NR UPF node or UPF entity are: the anchor point for intra-system / inter-system mobility (if applicable); the external PDU session point for interconnection with the data network; packet routing and forwarding; packet inspection; the user plane part of policy rule enforcement, such as gating, redirection, and traffic steering; lawful interception (UP collection); traffic usage reporting; user plane QoS processing, such as UL / DL rate control and reflective QoS marking in DL; uplink traffic verification (SDF to QoS flow mapping); transport level packet marking in uplink and downlink; downlink packet buffering and downlink data notification triggering; sending and forwarding one or more "end markers" to the source NG-RAN node.
[0173] SMF 110 represents the Session Management Function. The functions of the 5G NR SMF node or SMF entity are: session management; UE IP address allocation and management; UP function selection and control; configuring traffic steering at the UPF to route traffic to the appropriate destination; policy enforcement and QoS control; and downlink data notification.
[0174] AMF 310 represents the Access and Mobility Management Function. The AMF is part of the 3GPP 5G architecture. Its main tasks include registration management, connection management, reachability management, mobility management, and various functions related to security, access management, and authorization.
[0175] PSA 312 stands for Protocol Data Unit Session Anchor. PSA refers to the UPF of the N6 interface that terminates the PDU session in the 5G core network.
[0176] NF 140 stands for Network Function. A Network Function is a logical node within the network infrastructure with a well-defined external interface and well-defined functional behavior.
[0177] AN 311 stands for Access Network. An access network is the communication network that connects subscribers to their service provider.
[0178] exist Figure 3 In the communication system 300, the above-mentioned Figure 2 The application and NF of the management layer 140 trigger (301) a configuration change. The interface 115 between the NF 140 and the SMF 110 and the interface 125 between the SMF 110 and the UPF 120 can be used to transmit transactions to read / write configuration 302, 303. The UPF transaction controller 122 can be used to lock or activate transactions 304.
[0179] The concepts 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 way. This system is based on a virtual platform that can dynamically create these network functions.
[0180] Therefore, it is important to be able to read the state of the network before writing to it. Storing the network state in a central location affects scalability and efficiency. Therefore, one goal is to resolve conflicts among a large number of UPFs controlled by many SMFs (controllers). This solution enhances the interaction between SMFs 110 and UPFs 120 through a two-phase locking protocol. This enables atomic ordering of control commands from non-coordinating SMFs and avoids potentially conflicting modifications on the same UPF. Technical advantages include its scalability and simplicity.
[0181] In the following, four embodiments of the communication network 100 having the SMF 110 and the UPF 120 are described in more detail, as described above in conjunction with Figure 1 and Figure 2 Generally described.
[0182] In the first embodiment of the 3GPP system 300, Figure 3 Combined with the above Figure 1 and Figure 2 The new functions are shown together.
[0183] Example 1 has a direct impact on 6G / 5G networks, enabling key functions to enhance transaction interaction capabilities beyond the traditional request / interaction response type.
[0184] In Example 1, SMF is enhanced using the SMF transaction controller 112, and UPF is enhanced using the UPF transaction controller 122, and transaction IDs (TID and LW-TID) are used interactively to track active configurations; UPF uses a lock flag with a specific TID to indicate the last locked configuration; and the last write ID is used to indicate the last read or write transaction, and the old ID is ignored.
[0185] Figure 4 A block diagram showing a scenario where multiple SMFs control a single UPF.
[0186] Figure 4 The second embodiment is shown. This embodiment 2 involves combining the above Figures 1 to 3 The aforementioned problem involves connecting multiple SMFs 110a, 110b, and 110c to a single UPF 120. Existing prior art simply assumes that multiple connections will resolve this issue. However, this fails to address multiple conflicting configuration update requests. According to the present disclosure, this issue is addressed by providing multiple N4 interfaces 125a, 125b, and 125c, enabling a single UPF 120 to establish multiple N4 interfaces with multiple SMFs. The integration of multiple SMFs 110a, 110b, and 110c with a single UPF 120 creates a multi-controller deployment.
[0187] The benefits of this second embodiment are as follows: Configuration updates at the UPF are handled as transactional updates, eliminating conflicts and consistency issues. Read commands precede write commands. A global ID is used to track active configurations. Therefore, even if an SMF fails, the UPF can still operate normally.
[0188] In the third embodiment (ie embodiment 3), in addition to the above combination Figures 1 to 3 In addition to the two-phase lock described above, other types of concurrent algorithms can be used to achieve conflict-free interaction between the data plane and the control plane, as described below.
[0189] 1. The two-phase locking protocol as described above is the simplest and most efficient way to achieve concurrency.
[0190] 2. In a timestamp ordering protocol, each transaction is timestamped. In the event of a conflict, the transaction with the latest timestamp takes precedence. Timestamps can be time-based or counter-based.
[0191] 3. In multi-version concurrency control, different versions of the configuration are tracked between different UPFs. In the event of errors or conflicts, the last known good configuration is restored. This facilitates network-wide configuration control. Older versions are retained for use when needed.
[0192] 4. Verify concurrency control. An optimistic approach is implemented, assuming that most transactions will not conflict. This protocol consists of three phases: read, verify, and write. During verification, transactions are ensured to not conflict using a private copy of the configuration file before being submitted to the official configuration file.
[0193] Figure 5 An exemplary message flow diagram 500 is shown illustrating a scenario where two SMF instances attempt to write to a UPF but with a certain time delay.
[0194] In the fourth embodiment (Embodiment 4), two specific situations in which the solution proposed in this disclosure avoids conflicts are introduced in detail. Figure 5 The first case shown relates to the case where two SMF instances 112a, 112b attempt to write to the UPF 122 but with a certain 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) because the lock flags do not match, as shown in Figure 5 As shown in the sequence diagram.
[0195] The following messages are exchanged:
[0196] The first SMF instance 112a sends a UPF write message 210a to the UPF transaction controller 122. The UPF write message 210a includes the updated configuration, the first transaction identifier TID1, and the last write identifier LW-TID=X. Upon receiving this message 210a, the UPF transaction controller 122 pre-commits the update 211 including LW-TID=X, sets the lock flag to TID1, and confirms this to the first SMF instance 112a via a message 212.
[0197] The second SMF instance 112b then sends a UPF write message 210b to the UPF transaction controller 122. The UPF write message 210b includes the updated configuration, the second transaction identifier TID2, and the last write identifier LW-TID=X. Upon receiving this message 210b, the UPF transaction controller 122 rejects (211b) the update and sends a response 212b to the second SMF instance 112b.
[0198] The first SMF instance 112a sends a commit message 213 to the UPF transaction controller 122, which then activates 214 the update with LW-TID=TID and sets the lock flag to zero. The UPF transaction controller 122 finally sends a completion message 215 to the first SMF instance 112a.
[0199] Figure 6 An exemplary message flow diagram 600 is shown, illustrating a scenario where two SMF instances attempt to write to a UPF, and the two writes occur at approximately the same time.
[0200] This scenario is also related to the fourth embodiment, but is related to the second specific case, where the two writes occur almost simultaneously. In this case, the second transaction will be rejected using the atomic commit check at UPF 120, where the single configuration cannot be accessed together, as shown in the message diagram.
[0201] The following messages are exchanged:
[0202] The first SMF instance 112a sends a UPF write message 210a to the UPF transaction controller 122. The UPF write message 210a includes the updated configuration, the first transaction identifier TID1, and the last write identifier LW-TID=X. Almost simultaneously, the second SMF instance 112b sends a UPF write message 210b to the UPF transaction controller 122. The UPF write message 210b includes the updated configuration, the second transaction identifier TID2, and the last write identifier LW-TID=X. Upon receiving this message 210b, the UPF transaction controller 122 performs an atomic commit check 211c and rejects (212b) the update message 210b of the second SMF instance 112b by sending a reject message 212b including the information "cannot write during write time" to the second SMF instance 112b. A confirmation message 212a is sent to the first SMF instance 112a.
[0203] Although specific features or aspects of the present disclosure may have been disclosed in conjunction with only one of several implementations, such features or aspects may be combined with one or more other features or aspects in other implementations, as long as it is necessary or advantageous for any given or specific application. In addition, to the extent that the terms "include," "have," "have," or other variations of these words are used in the specification or claims, such terms are similar to the term "include" and both mean to include. Similarly, the terms "exemplary" and "for example" are merely examples, not best or optimal. The terms "coupled" and "connected," as well as derivatives, may be used. It should be understood that these terms can be used to indicate that two elements cooperate or interact with each other, regardless of whether they are in direct physical or electrical contact, or whether they are not in direct contact with each other.
[0204] Although specific aspects have been illustrated and described herein, it will be appreciated by those skilled in the art that various alternative 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 modifications or variations of the specific aspects discussed herein.
[0205] Although the elements in the following claims are recited in a particular order using corresponding labels, these elements do not have to be limited to being implemented in that particular order unless the claim recitation otherwise implies a particular order for implementing some or all of these elements.
[0206] Based on the above teachings, many substitutions, modifications and variations will be apparent to those skilled in the art. Of course, it will be readily apparent to those skilled in the art that, in addition to the applications described herein, the present disclosure has many applications. Although the present disclosure has been described with reference to one or more specific embodiments, it will be appreciated by those skilled in the art that many changes may be made to the present disclosure without departing from the scope of the present disclosure. Therefore, it will be understood that, within the scope of the appended claims and their equivalents, the present disclosure may be practiced in a manner other than that specifically described herein.
Claims
1. A data entity (120), characterized in that 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) via 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) associated with the first transaction comprises a read request for retrieving at least part of the network configuration (121) of the data entity (120); a data entity transaction controller (122) for determining, after receiving the first control message (205), a last transaction in which the data entity (120) was last updated, generating a first identifier (222) of the last transaction and sending the first identifier (222) to the control entity (110) in a response (207); wherein a second control message (210) of the control messages (205, 210) 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 in which the data entity (120) was last updated; wherein the data entity transaction controller (122) is configured to update (214) the data entity (120) using the new network configuration (121') when the second identifier (222') of the last transaction from the second control message (210) matches the first identifier (222) of the last transaction generated by the data entity transaction controller (122) after receiving the first control message (205).
2. The data entity (120) according to claim 1, characterized in that Each transaction includes a write request conveyed by a corresponding second control message (210) that precedes a read request conveyed by a corresponding first control message (205).
3. The data entity (120) according to claim 1 or 2, characterized in that The data entity transaction controller (122) is configured to refuse to update (214) the data entity (120) with the new network configuration (121') if the second identifier (222') of the last transaction from the second control message (210) does not match the first identifier (222) of the last transaction generated by the data entity transaction controller (122) after receiving the first control message (205).
4. The data entity (120) according to any one of the preceding claims, characterized in that 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 (121'), and to update (214) the data entity (120) with the new network configuration (121') after receiving a commit message (213) in response to the confirmation message (212) from the control entity (110).
5. The data entity (120) according to claim 4, characterized in that The data entity transaction controller (122) is configured to set a lock flag (223) after sending the confirmation message (212) to the control entity (110), wherein the lock flag (223) indicates that an update mechanism for updating (214) the data entity (120) with a new network configuration (121') is locked.
6. The data entity (120) according to claim 5, characterized in that The data entity transaction controller (122) is configured to release the lock flag (223) upon receiving the commit message (213) from the control entity (110) so as to enable the update mechanism for updating (214) the data entity (120) with a new network configuration (121').
7. The data entity (120) according to any one of the preceding claims, characterized in that The data entity (120) is based on a user plane function (UPF) entity standardized according to 3GPP, and the UPF entity is enhanced by the functions of the control interface (125) and the data entity transaction controller (122).
8. The data entity (120) according to any one of the preceding claims, characterized in that include a plurality of control interfaces (125a, 125b, 125c) for receiving messages from a plurality of control entities (110a, 110b, 110c), said messages being associated with different transactions, The data entity transaction controller (122) is configured to, after sending a confirmation message (212) for updating (214) the data entity (120) with a new network configuration (121') according to a write request (210a) from a first control entity (110a), refuse to update (214) the data entity (120) according to a write request (210b) from a second control entity (110b).
9. The data entity (120) according to any one of the preceding claims, characterized in that The data entity transaction controller (122) is used to implement a two-phase locking protocol to achieve conflict-free interaction between the data entity (120) and the plurality of control entities (110a, 110b, 110c).
10. The data entity (120) according to any one of the preceding claims, characterized in that The data entity transaction controller (122) is configured to pre-commit 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 one of the preceding claims, characterized in that The control entity (110) comprises: a management interface (115) for receiving messages from a management entity (140), said messages being associated with transactions for updating said network configuration (121) of said data entity (120), each transaction being identified by a corresponding transaction identifier (221); wherein the first management message (204) associated with the first transaction comprises a read request for retrieving at least part of the network configuration (121) of the data entity (120); wherein the second management message (209) associated with the first transaction comprises a write request for updating the data entity (120) with a new network configuration (121'); a control entity transaction controller (112) configured to, after receiving the first management message (204), send the first control message (205) to the data entity (120) via the control interface (125), and notify (208) the management entity (140) of a response (207) of the data entity (120); The control entity transaction controller (112) is configured to, upon receiving the second management message (209), send the second control message (210) to the data entity (120) via the control interface (125), and notify (216) the management entity (140) of the result of updating (214) the data entity (120) with the new network configuration (121').
12. The control entity (110) according to claim 11, characterized in that The control entity transaction controller (112) is used to determine or obtain a transaction identifier (221) of a transaction based on one or a combination of the following identifiers ID: A request ID of a specific request between two network function entities of the communication network; a slice ID of a specific slice of the communication network; An application ID of the application set by the application function entity of the communication network; A network function ID of a network function entity of the communication network.
13. The control entity (110) according to claim 12, characterized in that The controlling entity transaction controller (112) is configured to determine the identifier of the 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) according to any one of claims 11 to 13, characterized in that The controlling entity transaction controller (112) is configured to, upon receiving a message (202) indicating the start of the transaction, notify (203) the managing entity (140) of an identifier of the transaction.
15. The control entity (110) according to any one of claims 11 to 14, characterized in that The control entity (110) is based on a session management function (SMF) entity standardized according to 3GPP, and the SMF entity is enhanced by the functions of the management interface (115), the control interface (125) and the control entity transaction controller (112).