Patent Description:
The <NUM> network has been commercialized and is being rolled out by operators world-wide. The <NUM> 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 environment. 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 <NUM> network.

In particular, supporting various new types of services implies a deeper impact on the core network architecture. In <NUM>, 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 things (IoT) connections and ultra-low latency communications, which are from different entities. Instead, for <NUM> 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 <NUM> network engages 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: <NUM>) CP NFs (mainly the SMF entities) can have timely global information about the UP NFs (mainly the UPF entities); <NUM>) 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 already been broken in the current <NUM> deployment, wherein 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 <NUM>, 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.

<CIT> discloses Application Function (AF) influenced routing for peer-to-peer (P2P) communications.

Preferred embodiments are covered by the appended dependent claims.

When there are multiple NF entities existing (e.g., 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 <NUM> system, the core network part usually locates at a dedicated telecom cloud data center (i.e., 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 (e.g., 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, the invention aims 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.

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, insofar each of the above-mentioned combinations is encompassed within the scope of the invention as defined by the appended claims.

<FIG> shows a first entity <NUM> according to an embodiment of this disclosure. The first entity <NUM> is configured to perform a decentralized session management (together with one or more other first entities <NUM>'). The first entity <NUM> may be a network resource node and/or may be configured with a SMF. That is, the first entity <NUM> may be a SMF entity. The first entity <NUM> may be referred to as SMF entity <NUM> in this disclosure. In this case, the first entity <NUM> is configured with a SMF. Likewise the one or more other first entities <NUM>' may be referred to as SMF entities <NUM>' in this disclosure. In this case, each of the one or more other first entities <NUM>' is configured with a SMF. The session that may be managed in a decentralized manner by the first entities <NUM>, <NUM>' may be a PDU session.

The first entity <NUM> is configured to receive a first transaction <NUM>, 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, a (PDU) 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 <NUM> is further configured to send the first transaction <NUM> to the one or more other first entities <NUM>'. The first entity <NUM> may thereby send the first transaction <NUM> directly or indirectly to the other first entities <NUM>'. For instance, it may send the first transaction <NUM> directly to all other first entities <NUM>' it is connected to, and those other first entities <NUM>' may forward it to yet other first entities <NUM>'. The first entity <NUM> may also receive and send more than one first transaction <NUM>. Each of these one or more other first entities <NUM>' may be configured to function like the first entity <NUM> is configured to function in this disclosure. That is, the first entity <NUM> could also be one of the other first entities <NUM>' (at a different time or in a different scenario) and vice versa. The first entity <NUM> and the one or more other first entities <NUM>' may form a distributed system of first entities <NUM>, <NUM>'. If they are configured with SMFs, they may form a distributed system consisting of SMF entities <NUM>, <NUM>'.

The first entity <NUM> is further configured to receive one or more second transactions <NUM> from the one or more other first entities <NUM>'. Thereby, each second transaction <NUM> indicates information of a second session-management-related message. Each second transaction <NUM> may have been received by one of the other first entities <NUM>', like the first transaction <NUM> is received by the first entity <NUM>. Further, like the first entity <NUM> sending the first transaction <NUM> to the one or more other first entities <NUM>', each of the other first entities <NUM>' may send one or more second transactions <NUM> to the first entity <NUM> and in addition to each of the one or more first entities <NUM>'. Again, each other first entity <NUM>' may send its one or more second transactions <NUM> indirectly or directly to the other first entities <NUM>, <NUM>'.

The first entity <NUM> is further configured to compose a first transaction set <NUM>, wherein the first transaction set <NUM> includes at least one of the first transaction <NUM> (which it sent to the other first entities <NUM>') and one or more of the second transactions <NUM> (which it received from the other first entities <NUM>'). In a similar manner, each of the one or more other first entities <NUM>' may compose a second transaction set <NUM>, i.e., one or more second transaction sets <NUM> may be formed (wherein the second transaction sets <NUM> 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 <NUM> are identical). Each of the second transaction sets <NUM> may include at least one of the first transaction <NUM> and one or more of the second transactions <NUM>.

Then, the first entity <NUM> is configured to perform a distributed consensus protocol <NUM>, together with the one or more other first entities <NUM>', to obtain a consensus result. That is, the first entity <NUM> and the other first entities <NUM>' may perform the distributed consensus protocol <NUM> with each other, i.e., as a group or distributed system. The consensus result is reached by performing the consensus protocol <NUM>. The consensus result indicates whether the first entity <NUM> is entitled to propose the first transaction set <NUM> in the next step, or whether (and which) one of the other first entities <NUM>' is entitled to propose its second transaction set <NUM> in the next step. The distributed consensus protocol <NUM> determines a winner first entity among the first entity <NUM> and the one or more other first entities <NUM>', i.e., among the distributed group of first entities <NUM>, <NUM>'. The winner first entity is the one entitled to propose its transaction set (i.e., either the first transaction set <NUM> if the first entity <NUM> is the winner entity, or one of the second transaction sets <NUM> if one of the other first entities <NUM>' is the winner entity) in the next step. The winner entity proposes its transaction set <NUM>, <NUM>, by broadcasting the transaction set <NUM>, <NUM> as a so-called accepted transaction set to all first entities <NUM>, <NUM>', which are not determined to be the winner entity. 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, wherein, 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.

Any one or each of the first entity <NUM> and the one or more other first entities <NUM>' may comprise a processor or processing circuitry (not shown in <FIG>) configured to perform, conduct or initiate the various operations of the respective first entity <NUM>, <NUM>' described herein. The processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors.

Any one or each of the first entity <NUM> and/or the one or more other first entities <NUM>' 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 <NUM>, <NUM>' 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 <NUM>, <NUM>' to perform, conduct or initiate the operations or methods described herein.

As mentioned above, the first entity <NUM> may be configured as a SMF entity <NUM>. Likewise, any one or each of the other first entities <NUM>' may be configured as an (other) SMF entity <NUM>'. Thus, the first entity <NUM> and the one or more other first entities <NUM>' may form a group of distributed SMF entities <NUM>, <NUM>'. These SMF entities <NUM>, <NUM>' may together perform the distributed session management, in particular, the distributed management of a PDU session. Thereby, the SMF entities <NUM>, <NUM>' 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 <NUM>, <NUM>' from AMF entities, or state reply messages that are respectively received by the SMF entities <NUM>, <NUM>' from the UPF entities, or SMF deployment messages that are respectively received by the first entities <NUM>, <NUM>' (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 <NUM>, <NUM>'.

In the following, further and more detailed embodiments of this disclosure are described, wherein the first entities <NUM>, <NUM>' are exemplarily SMF entities <NUM>, <NUM>' 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 <NUM>, <NUM>' can establish a synchronized view of the UPF entities, so that when a PDU session request is received, every SMF entity <NUM>, <NUM>' 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 <NUM>, <NUM>'. 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 <NUM>, <NUM>' 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 <NUM>, <NUM>' 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 <NUM>, <NUM>' 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 <NUM>, <NUM>' 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 <NUM>, <NUM>', as well as between the SMF entities <NUM>, <NUM>' 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 <FIG>.

It is assumed that there are K ≥ <NUM> equivalent SMF entities <NUM>, <NUM>', which are deployed in a set of network resource nodes called network resource elements (RE) nodes (first entities <NUM>, <NUM>'). That is, each of the first entities <NUM>, <NUM>' may be one of the RE nodes configured with a SMF as a SMF entity <NUM>, <NUM>'. 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 <NUM>, <NUM>', 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 <NUM>) that are used to deploy M ≥ <NUM> UPF entities. That is, each second entity <NUM> is configured with a UPF to be an UPF entity <NUM>. These other RE nodes provide sufficient resources (compute, storage and networking) to run their UPF as UPF entities <NUM>. The difference is that an RE node configured as an UPF entity <NUM> 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 <NUM>, <NUM>' and the UPF entities <NUM> 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 <NUM>, <NUM>' and second entities <NUM>, 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 <NUM>, <NUM>' and UPF entity <NUM>.

It is further considered that there is also a set of AMF entities <NUM> in the network. AMF entities <NUM> may be associated with radio access network (RAN) <NUM> part of the mobile network, from which PDU session requests of one or more UEs <NUM> may be received (e.g., as non-access stratum (NAS) message). Every AMF entity <NUM> may be connected to a SMF entity <NUM>, <NUM>', to which the received PDU session request will be forwarded by the AMF entity <NUM>. Accordingly, the response to the PDU session request will be sent back to that AMF entity <NUM>.

Based on the above assumptions and settings, <FIG> in particular illustrates a general architecture of a variety of entities in a mobile network. In order to facilitate the further discussion thereof, the names of some interfaces are defined first, wherein the interfaces are shown in <FIG>.

Intf_amf2smf (Intf1) is an interface between an AMF entity <NUM> and a SMF entity <NUM>, <NUM>'. This interface is standardized in 3GPP SA2 as a reference point N11.

Intf_smf2smf (Intf2) is an interface between a SMF entity <NUM> and another SMF entity <NUM>' 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 <NUM>, <NUM>' and a UPF entity <NUM>. 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 <FIG>, which includes the distributed SMF entities <NUM>, <NUM>', the AMF entities <NUM>, the UPF entities <NUM>, a DN <NUM> to which a request for a session relates, and the UE <NUM> in the RAN <NUM>, a concept of embodiments of this disclosure is further illustrated in <FIG>. Relevant procedures shown in <FIG> are described below.

Firstly, a PDU session request submission procedure is considered. This interaction occurs over the Intf1. Thereby, an AMF entity <NUM> receives a PDU session request from a UE <NUM> via the RAN <NUM>. The AMF entity <NUM> composes the first transaction ("Tx") <NUM> based on the PDU session request. Thus, the first transaction <NUM> is in this case a session transaction <NUM>. The session transaction <NUM> comprises the information contained in the PDU session request. The AMF entity <NUM> submits the session transaction <NUM> to a SMF entity (in <FIG> the first SMF entity <NUM>, "SMF1")), which is associated with the AMF entity <NUM>. The information could contain (but is not limited to): the ID of the UE <NUM> ("UE_ID"), the ID of the AMF identity <NUM> ("AMF_ID"), the data network number (DNN) of the DN <NUM> ("DNN"), one or more required QoS metrics ("QoS"), and necessary authentication information (such as a signature of the submitting AMF <NUM>). More importantly, the submission of the session transaction <NUM> may also point to an application interface (API) provided by the SMF entity <NUM>.

Next, a PDU session proposal and feedback procedure is considered. This interaction occurs over the Intf2. The received session transaction <NUM>, including the information contained in the PDU session request, may be first of all locally validated by the receiving first SMF entity <NUM>. This local validation may include (but is not limited to) verifying the authentication information contained in the session transaction <NUM> (e.g. the signature of the submitting AMF entity <NUM>), the permission of the UE <NUM> to access the DN <NUM>, and so on. After the local validation is finished and passes, the first SMF entity <NUM> sends the validated session transaction <NUM> to one or more other (peer) SMF entities <NUM>' ("SMF2". In particular, it sends it to the directly connected other SMF entities <NUM>'. Likewise, the first SMF entity <NUM> may receive second session transactions <NUM> from the other SMF entities <NUM>', and may then form the first transactions set <NUM>. The first transaction set <NUM> may then be provided as proposal to the whole distributed SMF system. The distributed SMF entities <NUM>, <NUM>' may consider the proposal by performing the distributed consensus protocol <NUM>, and a final result will be returned back to the proposer (i.e., in this case the first SMF entity <NUM> that triggered the proposal of the first transaction set <NUM>). Notably, the distributed consensus protocol <NUM> may be performed during a formation period, wherein all proposed session transaction sets <NUM>, <NUM> (including the second transaction sets <NUM> composed by the other SMF entities <NUM>', which also include the second session transactions <NUM>) 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 <NUM> is entitled to propose the first transaction set <NUM> or whether one of the other SMF entities <NUM>' is entitled to propose a second transaction set <NUM>. For a rejected session transaction set <NUM>, <NUM>, the proposer proceeds to an abortion stage. For an accepted transaction set <NUM>, <NUM>, 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 <NUM>, <NUM> of session transactions each including information of a PDU session requests are selected and ready for further execution. The accepted transactions set <NUM>, <NUM> (i.e. with the information of accepted PDU session requests) may then be sequentially processed by every SMF entity <NUM>, <NUM>' in the distributed SMF system. Recall that when the first session transaction <NUM> was submitted by the AMF entity <NUM> to the first SMF entity <NUM>, 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 <NUM>, <NUM>'). The associated function may be executed, taking the parameters contained in the session transaction <NUM> and triggering, for instance, the follow actions:.

The callback function execution may require multiple state replies from the UPF entities <NUM> to handle a PDU session request properly. When every SMF entity <NUM>, <NUM>' 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 <NUM>, <NUM>'. 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 <NUM>. Similar to the event emission described above, the calculated session configuration <NUM> ("UPF1_Cfgs". "UPFn_Cfgs") for each UPF entity <NUM> may be also emitted as an event. Every UPF entity <NUM> may consume the prescribed session configuration <NUM>, 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 <NUM>, <NUM>', which may then send a final response back containing the access information that is required for an UE <NUM> to access the deployed session via the original AMF entity <NUM> submitting the session transaction <NUM>. Notably, a detailed description of unchanged procedures/interactions between the AMF entity <NUM> with other NFs are omitted here. For example, an authentication procedure between AMF <NUM> 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 <NUM>, <NUM>' 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 <NUM>, <NUM>' 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 <NUM>. 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 <NUM>, <NUM>' may be immutable and transparent. In other words, every SMF entity <NUM>, <NUM>' may be required to behave identically as a single entity. In other words, the processing logic may be publicly shared among all SMF entities <NUM>, <NUM>' and whenever the logic is modified, the modification itself has to go through the same distributed consensus procedure <NUM> (as the interactions for PDU _Rqs), so that every other SMF entity <NUM>, <NUM>' either moves in the same way or does not move at all.

In the following, a full procedure starting from deploying the SMF entities <NUM>, <NUM>' across a set of distributed RE nodes, wherein the deployed processing logic of SMF entities <NUM>, <NUM>' is immutably decentralized, is highlighted. Given the decentralized SMF entities <NUM>, <NUM>', a decentralized session management will be described in detail thereafter.

First, the SMF deployment procedure is described with respect to the <FIG> and <FIG>. This procedure finishes with deploying the SMF entities <NUM>, <NUM>' based on a set of distributed RE nodes with the same copy of the processing logic of a SMF entity. "SMF entity" and "the processing logic of the SMF entity" may be used interchangeably to simplify the discussion. The whole procedure is depicted in <FIG>.

Each RE node, on which the SMF entity source code is deployed, becomes a SMF entity <NUM>, <NUM>'. It is noted that from now the description refers indifferently to a SMF entity <NUM>, <NUM>#, as the RE node that hosts a SMF entity.

Next, a PDU session request submission procedure is described with respect to the <FIG> and <FIG>. A PDU session request (PDU_Rq) is a communication request that requires a communication channel from a UE <NUM> to a destination point, which is usually a gateway in a mobile network. In general, a PDU_Rq is created by a UE <NUM>, sent to an AMF <NUM> by the UE <NUM>, and then the AMF <NUM> submits the PDU_Rq to a SMF <NUM>, <NUM>'. The detailed interaction is shown in <FIG>.

Next, a session request distributed consensus procedure is described in detail with respect to the <FIG> and <FIG>. This procedure is similar to the SMF entity deployment procedure described with respect to <FIG> and <FIG>, and follows up on <FIG> and <FIG>.

Next, a UPF state retrieval and reply procedure is described in detail with respect to <FIG> and <FIG>. State retrieval events will be sent from SMF entities <NUM>, <NUM>' to UPF entities <NUM>. The events will be handled by the UPF entity <NUM> whose identity matches the UPF_ID field contained in the event, otherwise, the UPF entity <NUM> will drop those events whose UPF_ID field specified does not match. For the event whose UPF_ID matches the identity of the UPF entity, the detailed procedure is depicted in FGI.

Next, a session request acknowledgement is described in detail with respect to the <FIG> and <FIG>. This procedure only considers the successful case where the session configurations <NUM> for deploying a PDU_Rq (i.e. PDU_Rq1) are applied on UPF entities <NUM>. For the abortion case where the PDU_Rq is not successfully deployed, it follows as described above.

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 <FIG>.

The following embodiment is not encompassed by the wording of the claims but is considered as useful for understanding the invention.

<FIG> shows a method <NUM> according to an embodiment of this disclosure. The method <NUM> may be performed by the first entity <NUM>, particularly SMF entity <NUM>, shown in the previous figures. However, it may also be performed by any one of the other first entities <NUM>', i.e. other SMF entities <NUM>'. The method <NUM> is for decentralized session management.

The method <NUM> comprises a step <NUM> of receiving a first transaction <NUM> indicating information of a first session-management-related message, e.g., <NUM>, or <NUM>, or <NUM>. Further, the method <NUM> comprises a step <NUM> of sending the first transaction <NUM> to one or more other first entities <NUM>'. Then, it comprises a step <NUM> of receiving one or more second transactions <NUM> from the one or more other first entities <NUM>', wherein each second transaction <NUM> indicates information of a second session-management-related message <NUM>. The method next comprises a step <NUM> of composing a first transaction set <NUM>, wherein the first transaction set <NUM> includes the first transaction <NUM> and/or one or more second transactions <NUM>. Then, the method <NUM> comprises a step <NUM> of performing a distributed consensus protocol <NUM>, together with the one or more other first entities <NUM>', to obtain a consensus result indicating whether the first entity <NUM> is entitled to propose the first transaction set <NUM> or whether one of the other first entities <NUM>' is entitled to propose a second transaction set <NUM>.

Claim 1:
A first entity (<NUM>) for decentralized session management, the first entity (<NUM>) being configured to:
receive a first transaction (<NUM>) indicating information of a first session-management-related message (<NUM>, <NUM>, <NUM>);
send the first transaction (<NUM>) to one or more other first entities (<NUM>');
receive one or more second transactions (<NUM>) from the one or more other first entities (<NUM>'), wherein each second transaction (<NUM>) indicates information of a second session-management-related message (<NUM>); and
compose a first transaction set (<NUM>), wherein the first transaction set (<NUM>) includes the first transaction (<NUM>) and/or one or more second transactions (<NUM>);
wherein the first entity (<NUM>) is characterized by being further configured to:
perform a distributed consensus protocol (<NUM>), together with the one or more other first entities (<NUM>'), to obtain a consensus result indicating whether the first entity (<NUM>) is entitled to propose the first transaction set (<NUM>) or whether one of the other first entities (<NUM>') is entitled to propose a second transaction set (<NUM>),
wherein performing the distributed consensus protocol (<NUM>) comprises determining a winner first entity among the first entity (<NUM>) and the one or more other first entities (<NUM>'), wherein the winner first entity is entitled to propose its first transaction set (<NUM>) or second transaction set (<NUM>), respectively,
wherein, if the consensus result indicates that the first entity (<NUM>) is entitled to propose the first transaction set (<NUM>), the first entity (<NUM>) is configured to:
send the first transaction set (<NUM>) together with a verifiable evidence of the consensus result as an accepted transaction set (<NUM>) to the one or more other first entities (<NUM>'),
wherein, if the consensus result indicates that the first entity (<NUM>) is not entitled to propose the first transaction set (<NUM>) and/or that one of the other first entities (<NUM>') is entitled to propose the second transaction set (<NUM>), the first entity (<NUM>) is configured to:
discard the first transaction set (<NUM>) and receive the second transaction set (<NUM>) as an accepted transaction set (<NUM>) from the other first entity (<NUM>').