The present disclosure relates to managing sessions in a mobile communication network, for instance, in the 5th generation wireless mobile network5G network). In particular, the disclosure proposes a first entity and a method for a decentralized session management.
The 5G network has been commercialized and is being rolled out by operators world-wide. The 5G network is expected to support many new types of connections between various devices such as cars, wearables, sensors and actuators from both private and industrial sectors. The new types of connections usually imply very distinct requirements of service requests, and thereby pose challenges to the management and control layer of the 5G network.
In particular, supporting various new types of services implies a deeper impact on the core network architecture. In 5G, the core network cannot anymore apply the same treatment rules to various types of data flows such as human voice and data, massive Internet of thingsIoT) connections and ultra-low latency communications, which are from different entities. Instead, for 5G a service-based architecture (SBA) is proposed, wherein network functions (NFs) are modularized and interact with each other over a message bus called service-based interfaces (SBIs). In this way, a network service can be composed by different sets of NFs, and different services can share a same set of NF components, which largely improves the flexibility and scalability of the core network.
Additionally, the 5G network utilizes a control plane (CP) and user plane (UP) decoupling strategy, which separately defines the behaviors of CP and UP NFs. This not only provides a distributed and flexible deployment option, but also enables a local control possibility, so that a data flow request can be handled promptly. With network function virtualization (NFV) and software-defined network (SDN) technologies, a core network does not have to locate at one place as a single system. Instead, multiple core network systems can co-exist and operate the entire mobile network together.
One of the main tasks of a wireless mobile network is “session management”. The core network receives a connection request from a user, e.g., via a user equipment (UE), and then establishes a connection between a source node and a destination node. This task is collectively handled by the access and mobility management function (AMF) and the SMF that controls a set of user plane function (UPF) resources. Specifically, according to the packet data unit (PDU) session request, which is transmitted from the AMF, a SMF will first of all identify available UPF resources that can accommodate such a PDU session, and will then configure the identified UPF entities with corresponding parameters. The result of this UPF configuration deployment will be provided back to the UE along the AMF. After that the UE knows where and how its data packets should be sent so that the requested PDU session is established.
It may seem that session management is trivial and straightforward, if the following two conditions are satisfied: 1) CP NFs (mainly the SMF entities) can have timely global information about the UP NFs (mainly the UPF entities); 2) the decision making of the SMF entities are completely conflict-free.
Unfortunately, however, any of the two conditions usually do not hold easily in reality. Specifically, the first condition has not always been satisfied in the current 5G deployment. One reason, for example, is the UPF entities are now deployed closer to the edge of the mobile network while being far from the SMF entities, which are deployed in a centralized telecom cloud. This results in delays and asynchrony when updating UPF states. The second condition may also be broken due to the inefficiency of a conflict resolution mechanism employed among the SMF entities, and/or possibly because of the asynchronous UPF states. The situation will become much more challenging beyond 5G, especially if the SMF entities or even the whole core network) goes distributed while no centralized controlling SMF exists to aggregate all UPF states and resolve conflicts.
The present disclosure and its embodiments are based further on the following considerations.
When there are multiple NF entities existing, such as multiple SMFs and UPFs, a coordination among those NFs is inevitable in a distributed system. A typical way is to employ a hierarchical structure where logically there will be a master node at a higher layer) to coordinate other peer nodes at one or more lower layer(s)). This includes both the cases of the master node being a separate node or system, and of the master being just one of the peer nodes. Also, the master node does not have to be static, but can be dynamically assigned as needed.
In the current 5G system, the core network part usually locates at a dedicated telecom cloud data center, a central office), wherein CP NFs run at the same place and even some UPFs also locate together. When multiple SMF entities are instantiated in the core network for the purposes of reliability, resilience and load balance), an operator can specify a master SMF entity among them, so that a final judgement can be made whenever there is any conflict occurring on synchronizing UPF states and PDU session deployments.
Specifically, if there is a set of SMF entities that are assigned to manage different UPF entities in distinct regions, respectively, considering a PDU session request from one region A to another region B, this involves at least two SMF entities from both regions A and B) to conclude a decision of how such a PDU session request can be accommodated. Since every SMF entity can only observe and control the UPF entities in its own region, it is not trivial that each SMF can simply apply the prescribed UPF configurations directly. In other words, a higher layer coordination is necessary, and the combination of the prescribed UPF configurations will be validated by a master SMF entity.
In view of the above, conventional mechanisms have some key disadvantages, which are discussed in the following.
Firstly, scalability is an issue. A hierarchical scheme may show a bottleneck issue in the system when the reconciliation requests increase. In future mobile networks, with the increasing density of cells, the number of CP NFs will increase accordingly. Naturally, the number of tiers will increase as well. As a result, potential conflicts will be aggregated layer by layer, and the entities at the higher layer will suffer overloading issues when the conflict resolution requests increase. In particular, SMF entities could experience even worse because in future mobile networks there will be much more UPF entities deployed at the edge of the network, i.e., closer to the users. This certainly accompanies the corresponding number of SMF entities increased in the network, which eventually concerns the master SMF entities in the network. In addition, higher hierarchies also suffer longer delays when considering the UPF state synchronization. Consequently, it could end up with a situation where a conflict cannot be handled, or only falsely, based on non-synchronized UPF states.
Secondly, flexibility is an issue. In particular, determining master (SMF) node(s) is not a trivial task job. It is very likely that such a selection has to depend on the exact dynamic situation of the current network, on-going services and so on, which may influence the loads to the current determined master (SMF) node(s). As a result, load balancing among the master (SMF) nodes has to be considered, or even more complicated, the set of master SMF) nodes has to be updated from time to time. This may further influence the underlying services, which may cause interruptions. Therefore, pre-planning a master node, or several master nodes, is very difficult and such a hierarchical scheme restricts the flexibility of the core network.
Thirdly, reliability is an issue. In particular, due to the existence of the master (SMF) node(s) in the system, single-point-of-failure issue is obvious. Failures could be system failures such as overloading, outages, and incorrect decision making. Failures could also be caused by malicious attacks. As a public and nationwide critical infrastructure, a second of out of service may easily affect many users including both human beings and machinery type entities), especially, mobile network in future may run critical services, such a failure may cause serious consequences.
In view of the above-mentioned limitations and disadvantages, embodiments of this disclosure aim to provide a decentralized session management scheme in a mobile network. An objective is, in particular, to provide a way to fully decentralize the session management without relying on any centralized entity, while asynchronous PDU sessions can still be handled conflict-free.
The objective is achieved by the embodiments of the invention as described in the enclosed independent claims. Advantageous implementations of the embodiments of the invention are further defined in the dependent claims.
In particular, the embodiments of this disclosure base on obtaining a distributed consensus between decentralized entities.
A first aspect of this disclosure provides a first entity for decentralized session management, the first entity being configured to: receive a first transaction indicating information of a first session-management-related message; send the first transaction to one or more other first entities; receive one or more second transactions from the one or more other first entities, wherein each second transaction indicates information of a second session-management-related message; compose a first transaction set, wherein the first transaction set includes the first transaction and/or one or more second transactions; and perform a distributed consensus protocol, together with the one or more other first entities, to obtain a consensus result indicating whether the first entity is entitled to propose the first transaction set or whether one of the other first entities is entitled to propose a second transaction set.
A session-management-related message is a message, which is related to the decentralized session management the first entity is configured to perform or support, i.e., is a message related to establishing or maintaining the session. For example, the session-management-related message may be a session request message, or a state reply message, or a SMF deployment message, as described in more detail later in this disclosure.
The distributed consensus protocol allows the first network entity and the other first network entities to implement a fully decentralized session management, for instance, of a PDU session. Neither the first entity nor any of the other first entities needs to be a master node or master entity or the like, in particular, a master node can be completely omitted. Thus, the decentralized session management does not have to rely on any centralized entity, which improves significantly the scalability, flexibility, and reliability, as the above-described key disadvantages of the conventional mechanisms may be overcome. Nevertheless, asynchronous sessions, in particular PDU sessions, can still be handled conflict-free, due to the consensus result that is achieved among the first entities.
In an implementation form of the first aspect, if the consensus result indicates that the first entity is not entitled to propose the first transaction set and/or that one of the other first entities is entitled to propose the second transaction set, the first entity is configured to discard the first transaction set and receive the second transaction set as an accepted transaction set from the other first entity.
In this case, one of the other first entities is determined winner entity of the consensus protocol and is accordingly allowed to propose its second transaction set. The second transaction set may still comprise the first transaction provided by the first entity. The accepted transactions set may determine how and when different transactions provided by the various first entities may be considered.
In an implementation form of the first aspect, if the consensus result indicates that the first entity is entitled to propose the first transaction set, the first entity is configured to send the first transaction set together with a verifiable evidence of the consensus result as an accepted transaction set to the one or more other first entities.
The verifiable evidence allows the other first entities to verify that the first entity is the winner entity of the consensus protocol. Notably, the verifiable evidence may be “positive evidence” certifying the first entity is the entity entitled to propose the first transaction set, or may be “negative evidence” certifying that no other first entity, or no specific other first entity, is the entity entitled to propose its transaction set.
In an implementation form of the first aspect, performing the distributed consensus protocol comprises determining a winner first entity among the first entity and the one or more other first entities, wherein the winner first entity is entitled to propose its first transaction set or second transaction set, respectively.
The distributed consensus protocol may be performed among all, or only some first entities in the mobile network, to determine the winner entity wherein the protocol is based on some rules and/or competitions). Eventually, the winner entity may propose its transaction set. That is, indirectly, the consensus result determines which transaction set is proposed.
In an implementation form of the first aspect, the first transaction is a first session transaction indicating information of a first session request message, and each second transaction is a second session transaction indicating information of a second session request message.
That is, the first entity and other first entities in this case perform the distributed consensus protocol for determining which session transactions—and accordingly session request messages, e.g., for a PDU session—are accepted and will be processed, and also, for example, in which order.
In an implementation form of the first aspect, the information indicated by the first session transaction and/or by any one of the second session transactions comprises at least one of: an identification (ID) of a UE, which is the source of the first session request message or respectively of the second session request message; an ID of an AMF, which is the source of the first session transaction or respectively of the second session transaction; a data network number (DNN) to which the first session request message or respectively the second session request message relates; a QoS requested by the first session request message or respectively by the second session request message; authentication information.
The authentication information may be used for authentication and verification. For instance, the authentication information may comprise a signature, a cyclic redundancy check (CRC) code or the like. The authentication information may also comprise cryptographical information, which may be related to encryption and decryption of the respective session transaction and may allow another entity to encrypt or decrypt it respectively.
In an implementation form of the first aspect, the first entity is further configured to validate the first session transaction before sending it to the one or more other first entities, and/or validate the one more second session transactions after receiving them from the one or more other first entities, based on the authentication information.
Thus, it can be ensured that all session transactions are properly validated, which increases the security of the system.
In an implementation form of the first aspect, the first entity is further configured to determine, based on every session transaction included in the accepted transaction set, one or more second entities from which state information is to be requested.
These second entities may be relevant to establish the respective sessions corresponding to the session transactions.
In an implementation form of the first aspect, the first entity is further configured to, before determining the one or more second entities from which state information is to be requested, validate the accepted transaction set based on verifiable evidence of the consensus result received from the other first entity.
Thus, the first entity can determine that the other first entity, which sends its second transaction set, is indeed the winner entity of the consensus protocol.
In an implementation form of the first aspect, the first entity is further configured to send a state retrieval message to one or more second entities; and receive a state reply message from each of the one or more second entities in response to the respective state retrieval message.
In this way, the first entity can receive state information regarding the states of the second entities, which may be necessary to further configure the second entities for establishing the session. The second entities may be UPFs, and the session may be a PDU session carried over the UPFs.
In an implementation form of the first aspect, the first transaction is a first state transaction indicating state information of a first state reply message from a second entity, and each second transaction is a second state transaction indicating state information of a second state reply message from a further second entity.
That is, the first entity and other first entities in this case perform the distributed consensus protocol for determining which state transactions—and accordingly state information, e.g., based on which the second entities can be configured for establishing a PDU session—are accepted and will be processed, and also, for example, in which order.
In an implementation form of the first aspect, the state information indicated by the first state reply message and/or by any one of the second reply messages comprises at least one of: an available bandwidth; a latency; a priority queue.
This information may be relevant for configuring the second entities with session configurations to establish a session.
In an implementation form of the first aspect, the first entity is further configured to: validate the accepted transaction set based on verifiable evidence of the consensus result received from the other first entity; determine, based on every state transaction included in the accepted transaction set, whether the state information indicated by the accepted transaction set is sufficient to calculate a session configuration for each corresponding second entity; if the state information is sufficient, calculate the session configurations for the corresponding second entities; and if the state information is not sufficient, wait for receiving further state information indicated by other accepted transaction sets, until all the state information is sufficient to calculate the session configurations for the corresponding second entities.
Thus, it is ensured that the session configurations are only calculated if all relevant information is available.
In an implementation form of the first aspect, each state transaction corresponds to a session transaction indicating information of a session request message; and/or each session configuration corresponds to a session request message.
That is, each state transaction includes state information that may be used for establishing a session according to a certain session request message. The session may be established using the corresponding session configuration.
In an implementation form of the first aspect, the first entity is further configured to send the session configurations to the corresponding second entities.
Thus, the first entity can configure the relevant second entities for the session. The other first entities may do the same, e.g. with other relevant second entities, and the session can thus be completely established using the second entities.
In an implementation form of the first aspect, the first entity is a network resource node and/or is configured with a SMF.
In an implementation form of the first aspect, the first transaction is a first SMF deployment transaction indicating information of a first SMF deployment message, and each second transaction is a second SMF deployment transaction indicating information of a second SMF deployment message.
That is, the first entity and other first entities in this case perform the distributed consensus protocol for determining which SMF to deploy.
In an implementation form of the first aspect, the first entity is further configured to configure, based on every SMF deployment transaction included in the accepted transaction set, each of the first entity and the one or more other first entities with a SMF.
A second aspect of this disclosure provides a method for decentralized session management, the method comprising: receiving a first transaction indicating information of a first session-management-related message; sending the first transaction to one or more other first entities; receiving one or more second transactions from the one or more other first entities, wherein each second transaction indicates information of a second session-management-related message; composing a first transaction set, wherein the first transaction set includes the first transaction and/or one or more second transactions; and performing a distributed consensus protocol, together with the one or more other first entities, to obtain a consensus result indicating whether the first entity is entitled to propose the first transaction set or whether one of the other first entities is entitled to propose a second transaction set.
The method may be performed by the first entity of the first aspect or any implementation form thereof.
In an implementation form of the second aspect, if the consensus result indicates that the first entity is not entitled to propose the first transaction set and/or that one of the other first entities is entitled to propose the second transaction set, the method comprises discarding the first transaction set and receive the second transaction set as an accepted transaction set from the other first entity.
In an implementation form of the second aspect, if the consensus result indicates that the first entity is entitled to propose the first transaction set, the method comprises sending the first transaction set together with verifiable evidence of the consensus result as an accepted transaction set to the one or more other first entities.
In an implementation form of the second aspect, performing the distributed consensus protocol comprises determining a winner first entity, wherein the winner first entity is entitled to propose its first transaction set or second transaction set, respectively.
In an implementation form of the second aspect, the first transaction is a first session transaction indicating information of a first session request message, and each second transaction is a second session transaction indicating information of a second session request message.
In an implementation form of the second aspect, the information indicated by the first session transaction and/or by any one of the second session transactions comprises at least one of: an identification (ID) of a UE, which is the source of the first session request message or respectively of the second session request message; an ID of an AMF, which is the source of the first session transaction or respectively of the second session transaction; a data network number (DNN) to which the first session request message or respectively the second session request message relates; a QoS requested by the first session request message or respectively by the second session request message; authentication information.
In an implementation form of the second aspect, the method further comprises validating the first session transaction before sending it to the one or more other first entities, and/or validating the one more second session transactions after receiving them from the one or more other first entities, based on the authentication information.
In an implementation form of the second aspect, the method further comprises determining, based on every session transaction included in the accepted transaction set, one or more second entities from which state information is to be requested.
In an implementation form of the second aspect, the method further comprises, before determining the one or more second entities from which state information is to be requested, validating the accepted transaction set based on verifiable evidence of the consensus result received from the other first entity.
In an implementation form of the second aspect, the method further comprises sending a state retrieval message to one or more second entities; and receiving a state reply message from each of the one or more second entities in response to the respective state retrieval message.
In an implementation form of the second aspect, the first transaction is a first state transaction indicating state information of a first state reply message from a second entity, and each second transaction is a second state transaction indicating state information of a second state reply message from a further second entity.
In an implementation form of the second aspect, the state information indicated by the first state reply message and/or by any one of the second reply messages comprises at least one of: an available bandwidth; a latency; a priority queue.
In an implementation form of the second aspect, the method further comprises: validating the accepted transaction set based on verifiable evidence of the consensus result received from the other first entity; determining, based on every state transaction included in the accepted transaction set, whether the state information indicated by the accepted transaction set is sufficient to calculate a session configuration for each corresponding second entity; if the state information is sufficient, calculating the session configurations for the corresponding second entities; and if the state information is not sufficient, waiting for receiving further state information indicated by other accepted transaction sets, until all the state information is sufficient to calculate the session configurations for the corresponding second entities.
In an implementation form of the second aspect, each state transaction corresponds to a session transaction indicating information of a session request message; and/or each session configuration corresponds to a session request message.
In an implementation form of the second aspect, the method further comprises sending the session configurations to the corresponding second entities.
In an implementation form of the second aspect, the method is performed by a network resource node and/or a SMF.
In an implementation form of the second aspect, the first transaction is a first SMF deployment transaction indicating information of a first SMF deployment message, and each second transaction is a second SMF deployment transaction indicating information of a second SMF deployment message.
In an implementation form of the second aspect, the method further comprises configuring, based on every SMF deployment transaction included in the accepted transaction set, each other first entity with a SMF.
The method of the second aspect and its implementation forms achieve the advantages described above for the device of the first aspect and its respective implementation forms.
A third aspect of this disclosure provides a computer program comprising a program code for performing the method according to the second aspect or any of its implementation forms, when executed on a computer.
A fourth aspect of the present disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the second aspect or any of its implementation forms to be performed.
It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.
The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which
The first entity 100 is configured to receive a first transaction 101, which indicates information of a first session-management-related message. The first session-related message may be any message that is related to the establishing and/or managing of the session, e.g., of the PDU session. The first session-related message may be or comprise, for example, aPDU) session request message, a state reply message issued during the (PDU) session establishment, or a SMF deployment message. Details thereof will be explained later.
The first entity 100 is further configured to send the first transaction 101 to the one or more other first entities 100′. The first entity 100 may thereby send the first transaction 101 directly or indirectly to the other first entities 100′. For instance, it may send the first transaction 101 directly to all other first entities 100′ it is connected to, and those other first entities 100′ may forward it to yet other first entities 100′. The first entity 100 may also receive and send more than one first transaction 101. Each of these one or more other first entities 100′ may be configured to function like the first entity 100 is configured to function in this disclosure. That is, the first entity 100 could also be one of the other first entities 100′ at a different time or in a different scenario) and vice versa. The first entity 100 and the one or more other first entities 100′ may form a distributed system of first entities 100, 100′. If they are configured with SMFs, they may form a distributed system consisting of SMF entities 100, 100′.
The first entity 100 is further configured to receive one or more second transactions 102 from the one or more other first entities 100′. Thereby, each second transaction 102 indicates information of a second session-management-related message. Each second transaction 102 may have been received by one of the other first entities 100′, like the first transaction 101 is received by the first entity 100. Further, like the first entity 100 sending the first transaction 101 to the one or more other first entities 100′, each of the other first entities 100′ may send one or more second transactions 102 to the first entity 100 and in addition to each of the one or more first entities 100′. Again, each other first entity 100′ may send its one or more second transactions 102 indirectly or directly to the other first entities 100, 100′.
The first entity 100 is further configured to compose a first transaction set 110, wherein the first transaction set 110 includes at least one of the first transaction 101 which it sent to the other first entities 100′) and one or more of the second transactions 102 which it received from the other first entities 100′). In a similar manner, each of the one or more other first entities 100′ may compose a second transaction set 120, i.e., one or more second transaction sets 120 may be formed wherein the second transaction sets 120 are typically not identical to each other, but differ from each other, while it is not excluded that two or more of the second transaction sets 120 are identical). Each of the second transaction sets 120 may include at least one of the first transaction 101 and one or more of the second transactions 102.
Then, the first entity 100 is configured to perform a distributed consensus protocol 103, together with the one or more other first entities 100′, to obtain a consensus result. That is, the first entity 100 and the other first entities 100′ may perform the distributed consensus protocol 103 with each other, i.e., as a group or distributed system. The consensus result is reached by performing the consensus protocol 103. The consensus result indicates whether the first entity 100 is entitled to propose the first transaction set 110 in the next step, or whether (and which) one of the other first entities 100′ is entitled to propose its second transaction set 120 in the next step. In particular, the distributed consensus protocol 103 determines a winner first entity among the first entity 100 and the one or more other first entities 100′, i.e., among the distributed group of first entities 100, 100′. The winner first entity is the one entitled to propose its transaction set (i.e., either the first transaction set 110 if the first entity 100 is the winner entity, or one of the second transaction sets 120 if one of the other first entities 100′ is the winner entity) in the next step. The winner entity may in particular propose its transaction set 110, 120, by broadcasting the transaction set 110, 120 as a so-called accepted transaction set to all first entities 100, 100′, which are not determined to be the winner entity.
Any one or each of the first entity 100 and the one or more other first entities 100′ may comprise a processor or processing circuitry (not shown in
Any one or each of the first entity 100 and/or the one or more other first entities 100′ may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the respective first entity 100, 100′ to be performed.
In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the respective first entity 100, 100′ to perform, conduct or initiate the operations or methods described herein.
As mentioned above, the first entity 100 may be configured as a SMF entity 100. Likewise, any one or each of the other first entities 100′ may be configured as an (other) SMF entity 100′. Thus, the first entity 100 and the one or more other first entities 100′ may form a group of distributed SMF entities 100, 100′. These SMF entities 100, 100′ may together perform the distributed session management, in particular, the distributed management of a PDU session. Thereby, the SMF entities 100, 100′ may also interact with other network entities, for instance, with one or more second entities. In particular, one or more second entities configured with a UPF, i.e., one or more UPF entities. Moreover, the (first and second) session-related-messages may comprise PDU session request messages that are respectively received by the SMF entities 100, 100′ from AMF entities, or state reply messages that are respectively received by the SMF entities 100, 100′ from the UPF entities, or SMF deployment messages that are respectively received by the first entities 100, 100′ (not yet configured with SMFs, e.g., the network resource nodes) with the purpose of deploying SMFs on these network resource nodes to configure and obtain the SMF entities 100, 100′.
In the following, further and more detailed embodiments of this disclosure are described, wherein the first entities 100, 100′ are exemplarily SMF entities 100, 100′ or network resource nodes that will be configured with SMFs. Further, the second entities are exemplarily UPF entities. However, before introducing these embodiments of the disclosure, some desirable requirements are first introduced. In particular, if a hierarchical organization of the SMF entities has to be removed, a distributed model (also referred to as peer-to-peer (P2P) model) may be utilized to organize the multiple SMF entities (as peers). Some technical aspects, which are beneficial to realize in this respect, are listed as follows.
The first aspect is that the SMF entities 100, 100′ can establish a synchronized view of the UPF entities, so that when a PDU session request is received, every SMF entity 100, 100′ can make a decision based on the latest UPF information. Without a master SMF entity (master node), this is a challenging work for a distributed SMF system.
The second aspect is that if two PDU session requests are received, planning and deploying these two PDU session requests should preferably be conflict free among the different SMF entities 100, 100′. In other words, without coordination with a third-party SMF node, the deployment configurations of the two PDU session requests shall preferably form a distributed consensus. Specifically, the deploying order, the QoS considerations and the specific configurations on overlapped UPF entities should preferably be agreed by all SMF entities 100, 100′ in a distributed manner without having a master SMF node.
The third aspect is that a verified execution feedback may be needed for every SMF entity 100, 100′ sending a PDU session deployment configuration to the UPF entities. This is preferable in a distributed SMF system, because there is no centralized monitoring node that can verify and provide an endorsement for the execution. This means that a desirable solution should preferably provide an execution guarantee mechanism.
The fourth aspect is that the management and maintenance of the distributed SMF system is preferably convenient. In particular, with respect to the problem this disclosure is concerned with, every SMF entity 100, 100′ should preferably be in the same version that runs the same protocol. Whenever an operator needs to update the SMF version, all the SMF entities 100, 100′ in the system may be updated all together efficiently. This is also challenging to a distributed system in general, because the distributed entities may be instantiated at different locations, while either on-site updating or a fully centralized management may be costly.
Given the above aspects, embodiments of this disclosure introduce a set of new behaviors between the (peer) SMF entities 100, 100′, as well as between the SMF entities 100, 100′ and the UPF entities. These newly introduced behaviors may establish a new procedure for handling a (PDU) session request from its arrival to its deployment, if possible. The details thereof are now introduced with respect to
It is assumed that there are K≥2 equivalent SMF entities 100, 100′, which are deployed in a set of network resource nodes called network resource elements (RE) nodes (first entities 100, 100′). That is, each of the first entities 100, 100′ may be one of the RE nodes configured with a SMF as a SMF entity 100, 100′. The RE nodes may be distributed nodes, which may be respectively located at different places in a mobile network, e.g., close to one or more base stations or in some edge clouds across geographical areas.
It is further assumed that every RE node can provide sufficient resources to run its SMF as a SMF entity 100, 100′, such as on-board compute resource, local storage capability and network connectivity to one or more other RE nodes.
It is further assumed that there is another set of RE nodes (second entities 200) that are used to deploy M≥2 UPF entities. That is, each second entity 200 is configured with a UPF to be an UPF entity 200. These other RE nodes provide sufficient resources (compute, storage and networking) to run their UPF as UPF entities 200. The difference is that an RE node configured as an UPF entity 200 could be a gateway node that interfaces to other domains outside.
It is also considered that the different RE nodes can have mutual connectivity so that the SMF entities 100, 100′ and the UPF entities 200 can exchange information among each other, by either a direct connection or a multi-hop connection. The two different sets of RE nodes (i.e., the first entities 100, 100′ and second entities 200, respectively) could also have overlaps, which means that any RE node could run both a SMF and a UPF to be both a SMF entity 100, 100′ and UPF entity 200.
It is further considered that there is also a set of AMF entities 201 in the network. AMF entities 201 may be associated with radio access network (RAN) 203 part of the mobile network, from which PDU session requests of one or more UEs 202 may be received (e.g., as non-access stratum (NAS) message). Every AMF entity 201 may be connected to a SMF entity 100, 100′, to which the received PDU session request will be forwarded by the AMF entity 201. Accordingly, the response to the PDU session request will be sent back to that AMF entity 201.
Based on the above assumptions and settings,
Intf_amf2smf (Intf1) is an interface between an AMF entity 201 and a SMF entity 100, 100′. This interface is standardized in 3GPP SA2 as a reference point N11.
Intf_smf2smf (Intf2) is an interface between a SMF entity 100 and another SMF entity 100′ of the distributed SMF system proposed in this disclosure. This interface is similar to the NF entity in one NF set, which represents a collection of the same type of NF instances in 3GPP SA2. However, an explicit reference point is not defined in 3GPP, because the current 3GPP release does not consider a distributed deployment standardization yet.
Intf_smf2upf (Intf3) is an interface between a SMF entity 100, 100′ and a UPF entity 200. This interface is standardized in 3GPP SA2 as a reference point N4.
Based on the above-described interfaces, and the various entities and the architecture shown in
Firstly, a PDU session request submission procedure is considered. This interaction occurs over the Intf1. Thereby, an AMF entity 201 receives a PDU session request from a UE 202 via the RAN 203. The AMF entity 201 composes the first transaction (“Tx”) 101 based on the PDU session request. Thus, the first transaction 101 is in this case a session transaction 301. The session transaction 301 comprises the information contained in the PDU session request. The AMF entity 201 submits the session transaction 301 to a SMF entity (in
Next, a PDU session proposal and feedback procedure is considered. This interaction occurs over the Intf2. The received session transaction 301, including the information contained in the PDU session request, may be first of all locally validated by the receiving first SMF entity 100. This local validation may include (but is not limited to) verifying the authentication information contained in the session transaction 301 (e.g. the signature of the submitting AMF entity 201), the permission of the UE 202 to access the DN 204, and so on. After the local validation is finished and passes, the first SMF entity 100 sends the validated session transaction 301 to one or more other (peer) SMF entities 100′ (“SMF2” . . . “SMF m”). In particular, it sends it to the directly connected other SMF entities 100′. Likewise, the first SMF entity 100 may receive second session transactions 102 from the other SMF entities 100′, and may then form the first transactions set 110. The first transaction set 110 may then be provided as proposal to the whole distributed SMF system. The distributed SMF entities 100, 100′ may consider the proposal by performing the distributed consensus protocol 103, and a final result will be returned back to the proposer (i.e., in this case the first SMF entity 100 that triggered the proposal of the first transaction set 110). Notably, the distributed consensus protocol 103 may be performed during a formation period, wherein all proposed session transaction sets 110, 120 (including the second transaction sets 120 composed by the other SMF entities 100′, which also include the second session transactions 102) will compete each other to win the priority to be processed in the next stage. This competition can happen in either an interactive or a non-interactive way. More details on this aspect will be provided below. The final result to the proposed session transaction set will be the consensus result indicating either an ACCEPT or a REJECT. That is, indicating whether the first SMF entity 100 is entitled to propose the first transaction set 110 or whether one of the other SMF entities 100′ is entitled to propose a second transaction set 120. For a rejected session transaction set 110, 120, the proposer proceeds to an abortion stage. For an accepted transaction set 110, 120, the proposer enters the next stage for execution. The distributed consensus formation period fundamentally differs from the existing hierarchical SMF architecture. In this stage, there is no centralized entity that makes the final decision.
Next, a PDU session request execution procedure is considered. As an outcome of the previous step, a transaction set 110, 120 of session transactions each including information of a PDU session requests are selected and ready for further execution. The accepted transactions set 110, 120 (i.e. with the information of accepted PDU session requests) may then be sequentially processed by every SMF entity 100, 100′ in the distributed SMF system. Recall that when the first session transaction 301 was submitted by the AMF entity 201 to the first SMF entity 100, an API was specified, pointing to the processing function of the SMF entity (this processing function may be a piece of program code identically replicated on every SMF entity 100, 100′). The associated function may be executed, taking the parameters contained in the session transaction 301 and triggering, for instance, the follow actions:
The callback function execution may require multiple state replies from the UPF entities 200 to handle a PDU session request properly. When every SMF entity 100, 100′ processes a UPF reply state transaction (triggering the callback function), the callback function may check whether all UPF state replies are received. If not, the callback function may store the received UPF states, while it may skip a UPF session configuration calculation. If so, it will execute UPF session configuration calculation part, which enters the following stage.
Next, a UPF session configuration calculation and deployment procedure is considered. The callback function may be triggered until an UPF reply state transaction is accepted and executed on every SMF entity 100, 100′. Whenever the prerequisite conditions are satisfied (e.g. required UPF states are gathered), the UPF session configuration calculation logic of the callback function may be executed and prescribe for every involved UPF entities 200. Similar to the event emission described above, the calculated session configuration 300 (“UPF1_Cfgs” . . . “UPFn_Cfgs”) for each UPF entity 200 may be also emitted as an event. Every UPF entity 200 may consume the prescribed session configuration 300, and thus the session path may be fully configured for a PDU session request. After that, an acknowledgement may be also provided back to the SMF entities 100, 100′, which may then send a final response back containing the access information that is required for an UE 202 to access the deployed session via the original AMF entity 201 submitting the session transaction 301. Notably, a detailed description of unchanged procedures/interactions between the AMF entity 201 with other NFs are omitted here. For example, an authentication procedure between AMF 201 and AUSF/UDM, or the pricing check with the PCPF. These omitted procedures shall proceed as usual (standard). Moreover, a fundamental distinction to conventional solutions here is that a SMF entity 100, 100′ neither makes the decision alone nor queries any master endpoint that delegates to make the final decision. Rather it is a collective and trustworthy procedure (depending on incorporated consensus protocols).
According to the above-described, instead of using a hierarchical architecture to organize distributed SMF entities, the distributed SMF entities 100, 100′ in the present disclosure are organized as a distributed system featuring a distributed consensus mechanism, i.e., are capable of performing the distributed consensus protocol 103. Specifically, the following new behaviors can be summarized:
In addition, several new components may also be introduced into the distributed SMF system, in particular an immutable SMF processing logic. In the distributed SMF system, the processing logic on every SMF entity 100, 100′ may be immutable and transparent. In other words, every SMF entity 100, 100′ may be required to behave identically as a single entity. In other words, the processing logic may be publicly shared among all SMF entities 100, 100′ and whenever the logic is modified, the modification itself has to go through the same distributed consensus procedure 103 (as the interactions for PDU_Rqs), so that every other SMF entity 100, 100′ either moves in the same way or does not move at all.
In the following, a full procedure starting from deploying the SMF entities 100, 100′ across a set of distributed RE nodes, wherein the deployed processing logic of SMF entities 100, 100′ is immutably decentralized, is highlighted. Given the decentralized SMF entities 100, 100′, a decentralized session management will be described in detail thereafter.
First, the SMF deployment procedure is described with respect to the
Each RE node, on which the SMF entity source code is deployed, becomes a SMF entity 100, 100′. It is noted that from now the description refers indifferently to a SMF entity 100, 100 #, as the RE node that hosts a SMF entity.
Next, a PDU session request submission procedure is described with respect to the
Next, a session request distributed consensus procedure is described in detail with respect to the
Next, a UPF state retrieval and reply procedure is described in detail with respect to
Next, a session request acknowledgement is described in detail with respect to the
The acknowledgement Tx(s) (Tx5 and Tx6 from UPF1 and UPF2 respectively) follows the same way of any Tx in the previous steps being handled. The interactions can be seen in
The method 1400 comprises a step 1401 of receiving a first transaction 101 indicating information of a first session-management-related message, e.g., 402, or 601, or 1003. Further, the method 1400 comprises a step 1402 of sending the first transaction 101 to one or more other first entities 100′. Then, it comprises a step 1403 of receiving one or more second transactions 102 from the one or more other first entities 100′, wherein each second transaction 102 indicates information of a second session-management-related message 1004. The method next comprises a step 1404 of composing a first transaction set 110, wherein the first transaction set 110 includes the first transaction 101 and/or one or more second transactions 102. Then, the method 1400 comprises a step 1405 of performing a distributed consensus protocol 103, together with the one or more other first entities 100′, to obtain a consensus result indicating whether the first entity 100 is entitled to propose the first transaction set 110 or whether one of the other first entities 100′ is entitled to propose a second transaction set 120.
The present disclosure and its embodiments aim to eliminate a centralized entity that may impose limitations discussed above. With the proposed embodiments, distributed SMF entities 100, 100′ are purely equal peers and collectively form a distributed SMF system where any decision on processing e.g. a PDU session request is made based on distributed consensus protocol 103 and result. The architecture of the distributed SMF system is fully compatible with existing 3GPP architectures, where some new interactions and parameters may be introduced over existing interfaces.
The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed subject matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.
This application is a continuation of International Application No. PCT/EP2021/057260, filed on Mar. 22, 2021, the disclosure of which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
Parent | PCT/EP2021/057260 | Mar 2021 | US |
Child | 18472196 | US |