WO2023061575A1

WO2023061575A1 - Mobility database in sba access network

Info

Publication number: WO2023061575A1
Application number: PCT/EP2021/078313
Authority: WO
Inventors: Thomas Belling; Bruno Landais
Original assignee: Nokia Technologies Oy
Priority date: 2021-10-13
Filing date: 2021-10-13
Publication date: 2023-04-20

Abstract

Method comprising: receiving a registration informing that one or more instances of a network function serve a terminal, wherein the one or more instances are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the terminal is identified by a first terminal identifier; storing the one or more identifiers of the one or more instances along with said first terminal identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second terminal identifier; checking whether the first terminal identifier is identical to the second terminal identifier if the discovery request is received; retrieving the one or more identifiers from the mapping relationship if the first terminal identifier is identical to the second terminal identifier; providing the retrieved one or more identifiers in response to the discovery request.

Description

Mobility database in SBA access network

Field of the invention

The present disclosure relates to a service-based architecture of an access network such as a radio access network.

Abbreviations

3GPP 3^rd Generation Partnership Project

5G / 6G / 7G 5^th 16^th 17^th Generation

5GC 5G Core

5GS 5G System

AAA Authentication, Authorisation, Accounting

AF Application Function

AN Access Network

AMF Access and Mobility Management Function

API Application Programming Interface

ALISF Authentication Server Function

CM Connection Management

CN Core Network

DN Data Network gNB next Generation NodeB

GlITI Globally Unique Temporary Identifier

HTTP Hypertext T ransfer Protocol

ID Identifier

IE Information Element

LD Location Directory

LMF Location Management Function

MH Mobile Host

NAS Non-Access Stratum

NEF Network Exposure Function

NF Network Function

NG Next Generation

NGAP Next Generation Application Protocol NRF Network Repository Function

NSSF Network Slice Selection Function

PCF Policy Control Function

PDU Protocol Data Unit

PSA PDU Session Anchor

RAN Radio Access Network

SB Service Based

SBA Service Based Architecture

SBI Service Based Interface

SCP Service Communication Proxy

SM Session Management

SMF Session Management Function

SMSF Short Message Service Function

SUPI Subscription Permanent Identifier

TS Technical Specification

UDM Unified Data Management

UDR Unified Data Repository

UDSF Unstructured Data Storage Function

UE User Equipment

UPF User Plane Function

URI Uniform Resource Identifier

Background

In the 5GC architecture, as specified in 3GPP TS 23.501 , the AMF is located between the 5GC and the RAN. Towards the 5GC, it exhibits granular service-based HTTP based interfaces and can also use services offered by other core network functions.

However, towards the RAN, the AMF uses traditional non-service-based interfaces (N1 , N2), as shown in Fig. 1.

All communication between RAN and 5GC needs to traverse the AMF. The AMF shields mobility of the UE and related handovers between RAN nodes from the 5GC.

For security reasons, the AMF also hides the permanent UE identifier (SUPI) used in the 5GC from RAN nodes and instead assigns a temporary and changeable “AMF UE NGAP ID” for the purpose of identifying a UE in communication with RAN nodes. The AMF also sets up or releases N2 associations with RAN nodes when the UE transitions from CM-IDLE to CM-CONNECTED and vice versa. A UE is considered as idle (CM-IDLE) if it does not have a signaling connection with the access network.

Figs. 2 to 6 (taken from 3GPP TS 23.502) show related existing procedures:

Fig. 2 shows PDU Session establishment. The AMF I NAS handler is aware of PDU sessions and SMFs serving them. Basically, the procedure shown in Fig. 2 works as follows:

The procedure assumes that the UE has already registered on the AMF.

1 . In order to establish a new PDU Session, the UE generates a new PDU Session ID. The UE initiates the UE Requested PDU Session Establishment procedure by the transmission of a NAS message containing a PDU Session Establishment Request.

2. The AMF determines that the message corresponds to a request for a new PDU Session and selects a SMF.

3. AMF sends Nsmf_PDUSession_CreateSMContext Request to the selected SMF.

4. If Session Management Subscription data for corresponding SUPI, DNN and S- NSSAI of the HPLMN is not available, then SMF retrieves the Session Management Subscription data from UDM.

5. The SMF creates an SM context and responds to the AMF by providing an SM Context ID.

6. If the SMF needs to perform secondary authentication/authorization during the establishment of the PDU Session by a DN-AAA server, secondary authentication/authorization is performed.

7a. The SMF selects a PCF

7b. The SMF may perform an SM Policy Association Establishment procedure to establish an SM Policy Association with the PCF and get the default PCC Rules for the PDU Session.

8. The SMF selects one or more UPFs

9. SMF may perform an SMF initiated SM Policy Association Modification procedure to provide information on the Policy Control Request Trigger condition(s) that have been met.

10 (a+b). The SMF initiates an N4 Session Establishment or Modification procedure with the selected UPF(s) 11. SMF sends Namf_Communication_N1 N2MessageTransfer including N2 SM information to AMF.

The N2 SM information carries information that the AMF shall forward to the (R)AN which includes inter alia:

The CN Tunnel Info corresponds to the Core Network address(es) of the N3 tunnel corresponding to the PDU Session.

One or multiple QoS profiles

The PDU Session ID may be used by AN signalling with the UE to indicate to the UE the association between (R)AN resources and a PDU Session for the UE.

A PDU Session is associated to an S-NSSAI of the HPLMN and, if applicable, to a S-NSSAI of the VPLMN, and a DNN.

12. The AMF sends the NAS message containing PDU Session ID and PDU Session Establishment Accept targeted to the UE and the N2 SM information received from the SMF within the N2 PDU Session Request to the (R)AN.

13. (R)AN to UE: The (R)AN may issue AN specific signalling exchange with the UE that is related with the information received from SMF.

14. (R)AN to AMF: N2 PDU Session Response

15. AMF to SMF: Nsmf_PDUSession_UpdateSMContext Request (SM Context ID, N2 SM information, Request Type). The AMF forwards the N2 SM information received from (R)AN to the SMF.

16a. The SMF initiates an N4 Session Modification procedure with the UPF.

16b. The UPF provides an N4 Session Modification Response to the SMF.

16c. If necessary, the SMF registers with the UDM using Nudm_UECM_Registration

17. The SMF may subscribe to the UE mobility event notification from the AMF (e.g. location reporting, UE moving into or out of Area Of Interest).

18. If during the procedure, any time after step 5, the PDU Session establishment is not successful, the SMF informs the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (Release). The SMF also releases any N4 session(s) created, any PDU Session address if allocated (e.g. IP address) and releases the association with PCF, if any. In this case, step 19 is skipped.

19. SMF to UE: In the case of PDU Session Type IPv6 or IPv4v6, the SMF generates an IPv6 Router Advertisement and sends it to the UE.

20. If the UE has indicated support of transferring Port Management Information Containers, then SMF informs PCF that a 5GS Bridge information is available. 21. If the PDU Session establishment failed after step 4, the SMF unsubscribes to the modifications of Session Management Subscription data.

In Xn based handover, as shown in Fig. 3, only N2 signaling could bypass NAS handler at AMF. Basically, the procedure shown in Fig. 3 works as follows at and after handover execution from Source gNB to Target gNB including forwarding of data: la. The source NG-RAN node during the handover execution phase may provide RAN usage data Report to the AMF. l b. The Target NG-RAN sends an N2 Path Switch Request message to an AMF to inform that the UE has moved to a new target cell and provides a List of PDU Sessions To Be Switched. AN Tunnel Info for each PDU Session to be switched is included in the N2 SM Information.

2. The AMF sends N2 SM information by invoking the Nsmf_PDUSession_UpdateSMContext request service operation for each PDU Session in the lists of PDU Sessions received in the N2 Path Switch Request.

3. For PDU Sessions that are modified by the Target NG-RAN, the SMF sends an N4 Session Modification Request message to the UPF.

4. For the PDU Sessions that are switched, the UPF returns an N4 Session Modification Response message to the SMF after requested PDU Sessions are switched.

5. In order to assist the reordering function in the Target NG-RAN, the UPF sends one or more "end marker" packets for each N3 tunnel on the old path immediately after switching the path.

6. The SMF sends an Nsmf_PDUSession_UpdateSMContext response (N2 SM Information to the AMF for PDU Sessions which have been switched successfully. The CN Tunnel Info of UPF send to AMF is used to setup N3 tunnel.

7. Once the Nsmf_PDUSession_UpdateSMContext response is received from all the SMFs, the AMF aggregates received CN Tunnel Info and sends this aggregated information as a part of N2 SM Information along with the Failed PDU Sessions in N2 Path Switch Request Ack to the Target NG-RAN.

8. By sending a Release Resources message to the Source NG-RAN, the Target NG-RAN confirms success of the handover. It then triggers the release of resources with the Source NG-RAN.

9. The UE may initiate Mobility Registration Update procedure. In N2 based handover, as shown in Figs. 4 and 5, NAS is not involved. It may entirely bypass NAS handler. Basically, the handover preparation procedure shown in Fig. 4 works as follows

1. Source RAN (S-RAN) indicates to Source AMF (S-AMF) that a handover is required.

2. S-AMF selects the target AMF (T-AMF)

3. S-AMF may send to T-AMF: Namf_Communication_Createll EContext Request (N2 Information (Target ID, Source to Target transparent container, SM N2 information list, PDU Session IDs), UE context information (SlIPI, Service area restriction, Allowed NSSAI for each Access Type if available, Tracing Requirements, LTE M Indication, the list of PDU Session IDs along with the corresponding SMF information and the corresponding S-NSSAI(s), PCF ID(s), DNN, UE Radio Capability ID and UE Radio Capability Information).

4. For each PDU Session indicated by S-RAN, the T-AMF may invoke the Nsmf_PDUSession_UpdateSMContext Request to the associated SMF.

5. Based on the Target ID, SMF may check if N2 Handover for the indicated PDU Session can be accepted. The SMF may also select the UPF.

6a. [Conditional] SMF to UPF (PSA): N4 Session Modification Request.

6b. [Conditional] UPF (PSA) to SMF: N4 Session Modification Response.

6c. [Conditional] SMF to T-UPF (intermediate): N4 Session Establishment Request. 6d. T-UPF (intermediate) to SMF: N4 Session Establishment Response.

7. If N2 handover for the PDU Session is accepted, the SMF includes in the Nsmf_PDUSession_UpdateSMContext response the N2 SM Information containing the N3 UP address and the UL CN Tunnel ID of the UPF, the QoS parameters and TSCAI for the Target NG-RAN.

8. AMF supervises the Nsmf_PDUSession_UpdateSMContext Response messages from the involved SMFs.

9. T-AMF to T-RAN: Handover T-AMF determines T-RAN based on Target ID. T- AMF may allocate a 5G-GUTI valid for the UE in the AMF and target TAI.

10. T-RAN to T-AMF: Handover Request Acknowledge

11a. For each N2 SM response received from the T-RAN (N2 SM information included in Handover Request Acknowledge), AMF sends the received N2 SM response to the SMF indicated by the respective PDU Session ID. l lb. If the SMF selected a T-LIPF in step 6a, the SMF updates the T-LIPF by providing the T-RAN SM N3 forwarding information list by sending a N4 Session Modification Request to the T-LIPF. l lc. The T-LIPF allocates Tunnel Info and returns an N4 Session Modification Response message to the SMF. l ld. [Conditional] SMF to S-LIPF: N4 Session Modification Request (T-RAN SM N3 forwarding Information list or T-LIPF SM N3 forwarding Information list, indication to allocate DL forwarding tunnel(s) for indirect forwarding). l le. The S-LIPF may allocate Tunnel Info and returns an N4 Session establishment Response message to the SMF. l lf. The SMF sends an Nsmf_PDUSession_UpdateSMContext Response message per PDU Session to T-AMF.

12. T-AMF sends the Namf_Communication_CreateUEContext Response to the S- AMF.

Basically, the handover execution phase shown in Fig. 5 works as follows:

1. S-AMF sends to S-RAN the Handover Command.

2. S-RAN sends to UE the Handover Command.

2a. - 2c. The S-RAN may send the Uplink RAN Status Transfer message to the S- AMF.

3. Uplink packets are sent from T-RAN to T-UPF and UPF (PSA). Downlink packets are sent from UPF (PSA) to S-RAN via S-UPF. The S-RAN should start forwarding of downlink data from the S-RAN towards the T-RAN for QoS Flows or DRBs subject to data forwarding. This may be either direct (step 3a) or indirect forwarding (step 3b).

4. After the UE has successfully synchronized to the target cell, it sends a Handover Confirm message to the T-RAN.

5. T-RAN to T-AMF: Handover Notify.

Handover is by this message considered as successful in T-RAN.

6a. The T-AMF notifies to the S-AMF about the N2 handover notify received from the T-RAN by invoking the Namf_Communication_N2lnfoNotify.

6b. The S-AMF acknowledges by sending the Namf_Communication_N2lnfoNotify ACK to the T-AMF. 6c. If the PDU Session(s) is not accepted by the T-AMF (e.g. S-NSSAI associated with the PDU Session is not available in the T-AMF), S-AMF triggers PDU Session Release procedure.

7. Handover Complete indication is sent per each PDU Session to the corresponding SMF to indicate the success of the N2 Handover.

8a. If new T-UPF is inserted or an existing intermediate S-UPF is re-allocated, the SMF shall send N4 Session Modification Request indicating DL AN Tunnel Info of T-RAN to the T-UPF.

8b. The T-UPF acknowledges by sending N4 Session Modification Response message to SMF.

9a. If UPF is not re-allocated, the SMF shall send N4 Session Modification Request indicating DL AN Tunnel Info of T-RAN to the S-UPF.

9b. The S-UPF acknowledges by sending N4 Session Modification Response message to SMF.

10a. For non-roaming or local breakout roaming scenario, the SMF sends N4 Session Modification Request message to PDU Session Anchor UPF.

10b. The UPF (PSA) sends N4 Session Modification Response message to SMF.

11 . SMF confirms reception of Handover Complete.

12. The UE initiates Mobility Registration Update procedure.

13a. If there is a source intermediate UPF, the SMF initiates resource release.

13b. The S-UPF acknowledges with an N4 Session Release Response message to confirm the release of resources.

14a. The AMF may send UE Context Release Command.

14b. The source NG-RAN releases its resources related to the UE and responds with a UE Context Release Complete () message.

15a. If indirect forwarding applies and UPF is re-allocated, the SMF may send N4 Session Modification Request to T-UPF to release the indirect data forwarding resource. 15b. The T-UPF acknowledges with an N4 Session Modification Response message to confirm the release of indirect data forwarding resources.

In a Service Request procedure, as shown in Fig. 6, the AMF I NAS handler is aware of PDU sessions and SMFs serving them. Basically, the service request procedure shown in Fig. 6 works as follows: 1. UE sends to (R)AN a service request (AN message (AN parameters, Service Request (List Of PDU Sessions To Be Activated, List Of Allowed PDU Sessions, security parameters, PDU Session status, 5G-S-TMSI, [NAS message container], Exempt Indication))).

2. (R)AN forwards the service request to AMF by a N2 Message

3. A security context is established if needed.

4. AMF to SMF: The Nsmf_PDUSession_UpdateSMContext Request is invoked. 5a. If the AMF notified the SMF that the access type of the PDU session can be changed in step 4, and if PCC is deployed, the SMF perform an SMF initiated SM Policy Association Modification procedure.

5b. SMF may select a UPF.

6a. SMF may send N4 Session Modification Request message to UPF (PSA) and requests ON Tunnel Info providing the target Network Instance.

6b. The UPF (PSA) sends an N4 Session Establishment Response message to the SMF.

6c. If the SMF selects a new UPF to act as intermediate UPF for the PDU Session, or if the SMF selects to insert an intermediate UPF for a PDU Session which did not have an intermediate UPF, an N4 Session Establishment Request message is sent to the new UPF

6d. The new intermediate UPF sends an N4 Session Establishment Response message to the SMF.

7a. If the SMF selects a new UPF to act as intermediate UPF for the PDU Session, the SMF sends N4 Session Modification Request message to PDU Session Anchor UPF, providing DL Tunnel Info from new intermediate UPF.

7b. The UPF (PSA) sends N4 Session Modification Response message to SMF.

8b. old UPF (intermediate) to SMF: N4 Session Modification Response

The old (intermediate) UPF sends N4 Session Modification Response message to SMF.

9. The SMF initiates N4 Session Modification procedure to indicate the new l-UPF to send the buffered downlink packet(s) received from the UPF (PSA).

10. The old (intermediate) UPF forwards its buffered data to the UPF (PSA) acting as N3 Terminating Point.

11. The SMF generates only N2 SM information and sends Nsmf_PDUSession_UpdateSMContext Response to the AMF to establish the User Plane(s). 12. AMF to (R)AN: N2 Request (N2 SM information received from SMF, security context, Mobility Restriction List, UE-AMBR, MM NAS Service Accept, list of recommended cells / TAs I NG-RAN node identifiers, UE Radio Capability, Core Network Assistance Information, Tracing Requirements, UE Radio Capability ID).

13. The NG-RAN performs RRC Connection Reconfiguration with the UE depending on the QoS Information for all the QoS Flows of the PDU Sessions whose UP connections are activated and Data Radio Bearers.

14. (R)AN to AMF: N2 Request Ack (List of PDU Sessions To Be Established with N2 SM information (AN Tunnel Info, List of accepted QoS Flows for the PDU Sessions whose UP connections are activated, List of rejected QoS Flows for the PDU Sessions whose UP connections are activated), List of PDU Sessions that failed to be established with the failure cause given in the N2 SM information element).

15. The AMF determines Access Type and RAT Type. If the AMF received N2 SM information (one or multiple) in step 14, then the AMF shall forward the N2 SM information to the relevant SMF per PDU Session ID.

16. [Optional] SMF to PCF: If dynamic PCC is deployed, SMF may initiate notification about new location information to the PCF (if subscribed) by performing an SMF initiated SM Policy Modification procedure as defined in clause 4.16.5.1. The PCF may provide updated policies.

17a. If the SMF selected a new UPF to act as intermediate UPF for the PDU Session in step 5b, the SMF initiates a N4 Session Modification procedure to the new l-UPF and provides AN Tunnel Info. The Downlink Data from the new l-UPF can now be forwarded to NG-RAN and UE.

17b. UPF to SMF: N4 Session Modification Response.

18a. If a User Plane is to be setup or modified and after the modification there is no I- UPF, the SMF initiates a N4 Session Modification procedure to UPF (PSA) and provides AN Tunnel Info. The Downlink Data from the UPF (PSA) can now be forwarded to NG- RAN and UE.

18b. UPF to SMF: N4 Session Modification Response.

19. SMF to AMF: Nsmf_PDUSession_UpdateSMContext Response.

20a. If forwarding tunnel has been established to the new l-UPF, SMF sends N4 Session modification request to new (intermediate) UPF acting as N3 terminating point to release the forwarding tunnel.

20b. New (intermediate) UPF acting as N3 terminating point sends N4 Session Modification response to SMF. 21a. If forwarding tunnel has been established to the UPF (PSA), SMF sends N4 Session modification request to UPF (PSA) acting as N3 Terminating Point to release the forwarding tunnel.

21b. UPF (PSA) acting as N3 Terminating Point sends N4 Session Modification Response to SMF.

22a. If the SMF decided to continue using the old UPF in step 5b, the SMF sends an N4 Session Modification Request, providing AN Tunnel Info.

22b. The old UPF acknowledges with an N4 Session Modification Response or N4 Session Release Response message to confirm the modification or release of resources.

Details of the procedures shown in Figs. 2 to 6 are explained in 3GPP TS 23.502.

There is a discussion to introduce the benefits of a service-based architecture also within the RAN (see PCT EP/2020/087184 and PCT EP/2021/053293).

Summary

It is an object of the present invention to improve the prior art.

According to a first aspect of the invention, there is provided an apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: receiving a registration informing that one or more instances of a network function serve a terminal, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the terminal is identified by a first terminal identifier; storing the one or more identifiers of the one or more instances of the network function along with said first terminal identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second terminal identifier; checking whether the first terminal identifier is identical to the second terminal identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first terminal identifier is identical to the second terminal identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request.

According to a second aspect of the invention, there is provided an apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: receiving a registration informing that one or more instances of a network function serve a protocol data unit session, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the protocol data unit session is identified by a first session identifier; storing the one or more identifiers of the one or more instances of the network function along with the first session identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second session identifier; checking whether the first session identifier is identical to the second session identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first session identifier is identical to the second session identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request.

According to a third aspect of the invention, there is provided an apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: monitoring whether a terminal registers for being served by one or more instances of a network function; registering one or more identifiers of the one or more instances of the network function mapped to a terminal identifier at a mobility database if the terminal registers for being served, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the terminal is identified by the terminal identifier.

According to a fourth aspect of the invention, there is provided an apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: monitoring whether a protocol data unit session is being created or transferred and being served by one or more instances of a network function; registering one or more identifiers of the one or more instances of the network function mapped to a session identifier at a mobility database if the protocol data unit session is being created or transferred and being served, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the protocol data unit session is identified by the session identifier.

According to a fifth aspect of the invention, there is provided a method comprising: receiving a registration informing that one or more instances of a network function serve a terminal, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the terminal is identified by a first terminal identifier; storing the one or more identifiers of the one or more instances of the network function along with said first terminal identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second terminal identifier; checking whether the first terminal identifier is identical to the second terminal identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first terminal identifier is identical to the second terminal identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request. According to a sixth aspect of the invention, there is provided a method comprising: receiving a registration informing that one or more instances of a network function serve a protocol data unit session, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the protocol data unit session is identified by a first session identifier; storing the one or more identifiers of the one or more instances of the network function along with the first session identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second session identifier; checking whether the first session identifier is identical to the second session identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first session identifier is identical to the second session identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request.

According to a seventh aspect of the invention, there is provided a method comprising: monitoring whether a terminal registers for being served by one or more instances of a network function; registering one or more identifiers of the one or more instances of the network function mapped to a terminal identifier at a mobility database if the terminal registers for being served, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the terminal is identified by the terminal identifier.

According to an eighth aspect of the invention, there is provided a method comprising: monitoring whether a protocol data unit session is being created or transferred and being served by one or more instances of a network function; registering one or more identifiers of the one or more instances of the network function mapped to a session identifier at a mobility database if the protocol data unit session is being created or transferred and being served, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the protocol data unit session is identified by the session identifier.

Each of the methods of the fifth to eighth aspects may be a method of handling mobility.

According to a ninth aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of the fifth to eighth aspects. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer.

According to some embodiments of the invention, at least one of the following advantages may be achieved:

• SBA may be employed in both CN and AN;

• security concerns are overcome.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives.

Brief description of the drawings

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein:

Fig. 1 shows interfaces of a 5GS;

Fig. 2 replicates 3GPP TS 23.502 Figure 4.3.2.2.1-1 : UE-requested PDU Session Establishment for non-roaming and roaming with local breakout;

Fig. 3 replicates 3GPP TS 23.502 Figure 4.9.1.2.2-1 : Xn based inter NG-RAN handover without UPF re-allocation;

Fig. 4 replicates 3GPP TS 23.502 Figure 4.9.1.3.2-1 : Inter NG-RAN node N2 based handover, Preparation phase;

Fig. 5 replicates 3GPP TS 23.502 Figure 4.9.1.3.3-1 : inter NG-RAN node N2 based handover, execution phase; Fig. 6 replicates 3GPP TS 23.502 Figure 4.2.3.2-1 : UE Triggered Service Request procedure

Fig. 7 shows a message flow according to some example embodiments of the invention; Fig. 8 shows a message flow according to some example embodiments of the invention; Fig. 9 shows a message flow according to some example embodiments of the invention; Fig. 10 shows a message flow according to some example embodiments of the invention; Fig. 11 shows a message flow according to some example embodiments of the invention; Fig. 12 shows a message flow according to some example embodiments of the invention; Fig. 13 shows a message flow according to some example embodiments of the invention;

Fig. 14 shows an apparatus according to an example embodiment of the invention;

Fig. 15 shows a method according to an example embodiment of the invention;

Fig. 16 shows an apparatus according to an example embodiment of the invention;

Fig. 17 shows a method according to an example embodiment of the invention;

Fig. 18 shows an apparatus according to an example embodiment of the invention;

Fig. 19 shows a method according to an example embodiment of the invention;

Fig. 20 shows an apparatus according to an example embodiment of the invention;

Fig. 21 shows a method according to an example embodiment of the invention; and Fig. 22 shows an apparatus according to an example embodiment of the invention.

Detailed description of certain embodiments

Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

Hereinafter, the terms “serving a UE” and “serving a UE context” and the terms “serving a PDU session” and “serving a PDU session context” are synonymously used, unless otherwise stated or made clear from the context. According to some example embodiments, a mobility database stores information about the identity (e.g. address information, a node ID or a set ID) of an access network node serving a UE context and/or PDU session and possibly of the SM context for the PDU session, as identified by some UE identity and/or PDU session ID, and supports registration of related information and/or discovery of AN nodes based on UE IDs and/or subscription based on UE ID and/or PDU session ID and/or subscription based on UE ID and/or PDU session ID to notifications of changes of AN nodes handling a UE context.

According to some example embodiments, a mobility database stores information about the identity (e.g. Address information, a node ID or a set ID) of a core network node (e.g. SMF) serving a UE context or PDU session and possibly of the SM context for the PDU session, as identified by some UE identity and/or PDU session ID, and supports registration of related information and/or discovery of CN nodes based on UE IDs and/or PDU session ID and/or subscription based on UE ID and/or PDU session ID to notifications of changes of CN nodes handling a UE context or PDU session.

The former database may be the same as the latter database or different therefrom.

Registration of AN nodes in mobility database

Mobility database stores information about the identity (e.g. address information, a node ID or a set ID) of access network node (e.g. gNB) serving a UE context, as identified by some UE identity (e.g. SUPI, AMF UE NGAP ID, RAN UE NGAP ID, GUTI) and support registration of related information and/or discovery of AN nodes based on UE IDs and/or subscription based on UE ID to notifications of changes of AN nodes handling a UE context.

• The mobility database may be a standalone database.

• The mobility database may be integrated in an NRF that also stores NF profiles and supports the discovery of NF profiles, e.g. an NRF serving AN and core or an NRF only serving the AN.

• The mobility database could be integrated in an UDR or UDSF

• In a variant (variant 1 in Fig. 7), a node (e.g. an AMF) handling NAS signaling with an UE (e.g. registration and authentication of the UE) may register identifier(s) of that UE and AN node ID(s) or an AN node set ID handling the UE related context together with related UE identifier(s) in the mobility database.

• The node handling NAS signaling registers the AN node when the UE registers in the network, when the UE is handed over to another AN node, when an AN node is assigned to a UE transitioning from IDLE to connected state, and/or when a new UE identifier is assigned to the UE.

• As another variant (variant 2 in Fig. 7), an AN node handling a UE context may register identifier(s) of that UE and AN node ID(s) or an AN node set ID handling the UE context in the mobility database.

• The AN node registers itself when it is assigned a new UE context, (e.g. due to the UE registering in the network, due to an handover, when the AN node is assigned to a UE transitioning from IDLE to connected state), and/or when a new UE identifier is assigned to the UE

• In still another variant, both the node handling NAS signaling and the AN node handling the UE may register identifier(s) of that UE and AN node ID(s) or an AN node set ID handling the UE context in the mobility database. The mobility database may detect the duplication and ignore the later registration request.

In some example embodiments, instead or in addition of the UE identified by some UE ID, the mobility database may treat a PDU session of the UE identified by a PDU session ID in a corresponding way.

Fig. 7 shows a message flow according to some example embodiments of the invention. It (and the following Figs. 8 to 11) comprise both variants 1 and 2 outlined hereinabove. Note that in some example embodiments, only variant 1 may be employed for the scenarios of Figs. 7 to 11 , while in other example embodiments, only variant 2 may be employed for the scenarios of Figs. 7 to 11. In some example embodiments, for some of the scenarios of Figs. 7 to 11 , variant 1 may be employed and for some (potentially other, but not necessarily other) scenarios, variant 2 may be employed.

As shown in Fig. 7, if the mobility database is a part of a NRF, an access node (e.g. gNB) may first register at the mobility database. The registration comprises the AN node profile, which may comprise one or more of the AN node ID, one or more IP addresses of the AN node, potentially an AN set to which the A node belongs, an indication of the services provided by the AN node, etc.. Furthermore, as shown in Fig. 7, a UE wants to register with the AN node. The AN node forwards the request to the NAS handler, which may be located in AMF. After the UE is authentifcated, identities are assigned to the UE. For example, AMF and AN node may assign the same or different identities to the UE (e.g. AMF assigns AMF UE NGAP ID to the UE, while AN node assigns RAN UE NGAP ID to the UE). Then NAS handler accepts the registration request.

According to variant 1 , NAS handler informs the mobility database that the AN node serves the UE. If plural identities are assigned to the UE, NAS handler may inform the mobility database on the plural identities.

According to variant 2, AN node informs the mobility database that the AN node serves the UE. If plural identities are assigned to the UE, AN node may inform the mobility database on the plural identities.

The remainder of Fig. 7 is independent from whether variant 1 and/or variant 2 is employed. The same applies correspondingly to Figs. 8 to 11.

A NF service consumer (e.g. a CN node such as SMF, or a AN node, or a proxy between CN and AN) wants to consume a service of the AN node type for the UE. For that purpose, the NF service consumer sends a discovery request including a UE ID to the mobility database. The mobility database identifies the AN node based on the UE ID and replies with the AN node profile. It may additionally include one or more UE IDs mapped to the requested UE ID. Then, NF service consumer may request the service from the AN node, based on the mapped UE ID.

Optionally, the NF service consumer may store the AN node information for the UE ID. In this case, it is preferable that the NF service consumer additionally subscribes to modifications of the mapping relationship between UE ID and AN node type to get informed about any updates.

The registration of the AN node at the mobility database is updated during a handover.

• In variant 1 , the target AN node updates the registration; • In variant 2, the NAS handler updates the registration. If the NAS handler changes during an Xn based handover, preferably the target NAS handler performs the update, as shown in Fig. 9. However, in some example embodiments (not shown in Fig. 9), the source NAS handler may update the registration.

Fig. 8 shows registration update during Xn based handover, i.e. , when the NAS handler for the UE remains. After the path switch command from the target AN node to the NAS handler, either the target AN (variant 1) or the NAS handler (variant 2) informs the mobility database that the target AN node serves the UE. In still another variant (not shown in Figs. 8 and 9), the source AN node may inform the mobility database.

Fig. 9 shows registration update during N2 based handover, where not only the AN node but also the NAS handler for the UE changes. After handover preparation, target AN node sends handover command to source AN node, which forwards the command to UE. UE replies with handover complete. Then target AN node notifies target NAS handler on the handover.

In variant 1 , target AN node informs the mobility database on both the target AN and the target NAS handler for the UE. In variant 2, target NAS handler informs the mobility database on both the target AN and the target NAS handler for the UE.

The information on the handover to the mobility database, as shown in Figs. 8 and 9, may also comprise an information to deregister the source AN node and/or source NAS handler. However, in some example embodiments, the mobility database may maintain this information and mark it as “old”.

Fig. 10 flows a flow chart according to some example embodiments of the invention for a case that the UE was idle (RRC idle) and reconnects (RRC Connected). Similarly to the flow chart of Fig. 7, the AN node (variant 1) and/or the NAS handler (variant 2) may inform the mobility database that the AN node serves the UE, and provide one or more UE identities to the mobility database.

New UE identities may be assigned to a UE e.g. during a handover. In a variant the mobility database stores both an old and a new UE identity. • A registration request may contain both an unchanged UE identity (SlIPI) and a changed UE identity (e.g. AMF UE NGAP ID and RAN UE NGAP ID). As another option, the registration request contains both an old and a new value of a UE identity of a certain type. If the mobility database already has a stored UE identity of a certain type it maintains the old value and adds the new value. If it hasn’t stored a mapping of the UE to an AN node, it may store all the identities of the UE, together with the ID of the AN node. The mobility database may store several old values. The newest value may be marked as “new”, and/or the other values may be marked as “old”.

• When receiving discovery requests for the old UE identity, the mobility proxy may provide not only information about the AN node handling the UE context but also the new UE identity in the reply.

• The mobility database may also support a subscription to notifications about changed UE identities and provide notifications about new registered UE identities.

When the UE deregisters or AN is released when the UE becomes idle, the mobility database is informed either by AN node or NAS handler (see Fig. 11 for both variants).

• In a variant, the UE registration in the mobility database is then deleted.

• In another variant, when the UE becomes idle the mobility database starts an expiry timer but maintains the old AN registration until that timer expirers or the mobility database obtains a new registration related to that UE. If other nodes query the mobility database for the AN node serving the UE, the mobility database indicates in the reply that the UE is idle. This can be used by the inquiring node e.g. to determine that a paging of the UE is necessary and also to determine a paging area for the UE. The Mobility Data base can also offer a service enabling consumers to inquire the former AN node of idle UE (input UE ID, output AN node ID) to provide assistance info to optimize paging of a UE.

The AN and the core network may use different UE identifiers for security reasons.

• In some example embodiments, the mobility database checks the identity of nodes sending discovery or subscription requests and accepts only and provides to those nodes only types of UE identifiers that the node is entitled to use. • For instance, the mobility database may only accept discovery requests and subscriptions for AMF UE NGAP ID and RAN UE NGAP ID from mobility proxies located within the RAN, and only provide those identities to such mobility proxies.

• In some example embodiments, the access to Mobility Database service I specific resources (e.g. specific UE identity) may be authorized using OAuth2.

• the mobility database may also accept discovery requests and subscriptions for SUPIs from mobility proxies located at the border between RAN and core network, and provide AMF UE NGAP ID and/or RAN UE NGAP ID when receiving SUPIs and provide SUPI when receiving AMF UE NGAP ID and/or RAN UE NGAP ID to enable the mobility proxies to perform a mapping between those identities.

• The mobility database may register itself at an NRF. The Mobility Proxy, and/or the NAS handler, and/or the AN node may then use that NRF to discover the mobility database. Alternatively, the Mobility Proxy, the NAS handler, and/or the AN node may have configured information about the mobility database, (not shown in any figure)

• In a variant, the mobility database is integrated in the node (e.g. an AMF) handling NAS signaling and no registration by external nodes of UE IDs and related AN node IDs is performed.

• A node that wants to send requests toward RAN nodes (e.g SMF, RAN node, proxy) targeting the AN node(s) that handle a UE context of the corresponding UE, selects such AN node(s) based on the UE ID, and sends service requests towards those AN node(s) may send discovery requests including the UE ID to the mobility database and receive AN node IDs, AN node set IDs or AN profiles in response.

• The node may use received AN node IDs or AN node set IDs to retrieve AN node profiles from an NRF (in case the NRF is separate from the mobility proxy)

• If the mobility proxy is integrated in an NRF, it can return AN node profiles.

• The node may store the received information and use it to handle subsequent service requests relating to the same UE, and subscribe at the mobility database to notifications about changes of assigned AN node(s) for a UE identity. In some example embodiments, the mobility database may be integrated in a proxy. In some of these example embodiments, discovery requests and notification subscriptions are not performed.

Figs. 7 to 11 are related to a UE identified by some UE identifier, such as SlIPI. In some example embodiments, instead of or in addition to the UE, a PDU session identified by a session ID may be treated in a corresponding way.

Registration of CN nodes in mobility database

Mobility database stores information about the identity (e.g. address information, a node ID or a set ID) of a core network node (e.g. SMF) serving a UE context or PDU session and possibly of the SM context for the PDU session, as identified by some UE identity (e.g. SUPI, AMF UE NGAP ID, RAN UE NGAP ID, GUTI) and/or PDU session ID and supports registration of related information and/or discovery of CN nodes based on UE IDs and/or PDU session ID and/or subscription based on UE ID and/or PDU session ID to notifications of changes of CN nodes handling a UE context or PDU session.

• The mobility database may be a standalone database.

• The mobility database may be integrated in an UDR or UDSF

• The mobility database storing information about CN nodes may be the same database as the database storing information about AN nodes or a separate database.

• Variant 1 shown in Fig. 12: A node (e.g. an AMF) handling NAS signaling with a UE (e.g. registration and authentication of the UE) may register identifier(s) of that UE and CN node ID(s) or an CN node set ID handling the UE related context and or the PDU session ID and possibly the SM context ID together with related UE identifier(s) and/or PDU session ID in the mobility database.

• The node handling NAS signaling registers the CN node when the CN node is assigned, e.g. when a PDU session is established, and/or when a new UE identifier is assigned to the UE.

• Variant 2 shown in Fig. 12: A CN node handling a UE context or PDU session may register identifier(s) of that UE or PDU session and CN node ID(s) or an CN node set ID handling the UE context and possibly of the SM context for the PDU session in the mobility database.

• The CN node registers itself when it is assigns a new UE context or PDU session.

• When the CN node releases a UE context or PDU session, the mobility database is informed either by CN node or NAS handler.

Fig. 12 shows a message flow according to some example embodiments of the invention. It (and the following Fig. 13) comprises both variants 1 and 2 outlined hereinabove. Note that in some example embodiments, only variant 1 may be employed for the scenarios of Figs. 12 and 13, while in other example embodiments, only variant 2 may be employed for the scenarios of Figs. 12 and 13. In some example embodiments, for some of the scenarios of Figs. 12 and 13, variant 1 may be employed and for some (potentially other, but not necessarily other) scenarios, variant 2 may be employed.

As shown in Fig. 12, if the mobility database is a part of a NRF, a CN node may first register at the mobility database. The registration comprises the CN node profile, which comprises one or more of the CN node ID, one or more IP addresses of the CN node, potentially a CN set to which the CN node belongs, an indication of the services provided by the CN node, etc..

As further shown in Fig. 12, if the UE requests a service from a CN node (such as PDU session establishment), the NAS handler selects a CN node and requests the CN node to provide the service. The CN node replies accordingly. , and te NAS handler provides the reply to the UE. Then, in variant 1 , NAS handler registers, at the mobility database, the CN node as serving the UE. In variant 2, the CN node registers itself at the mobility database. The registration comprises an ID of the Cn node (or a set ID of a set to which the CN node belongs) and one or more UE IDs.

The remainder of Fig. 12 is independent from whether variant 1 and/or variant 2 is employed. The same applies correspondingly to Fig. 13.

A service consumer sends a discovery request to the mobility database. The discovery request comprises a UE ID. Mobility database retrieves the CN node ID based on the UE ID and provides the CN node ID (or even CN node profile) in the discovery response. In addition, the discovery response may comprise one or more UE IDs. Thus, the service consumer is enabled to send its SB request for the UE to the correct CN node.

Optionally, correspondingly to Fig. 7, the NF service consumer may store the CN node information for the UE ID. In this case, it is preferable that the NF service consumer additionally subscribes to modifications of the mapping relationship between UE ID and CN node type to get informed about any updates.

The flowchart of Fig. 13 corresponds to that of Fig. 12, except that, instead of an arbitrary CN node, a SMF handling a PDU session is shown, and that a PDU session identified by a session ID and an SM context ID is registered instead of a UE identifier-.

Fig. 14 shows an apparatus according to an example embodiment of the invention. The apparatus may be a database (such as a mobility database) or an element thereof. Fig. 15 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 14 may perform the method of Fig. 15 but is not limited to this method. The method of Fig. 15 may be performed by the apparatus of Fig. 14 but is not limited to being performed by this apparatus.

The apparatus comprises means for receiving 10, means for storing 20, means for monitoring 30, means for checking 40, means for retrieving 50, and means for providing 60. The means for receiving 10, means for storing 20, means for monitoring 30, means for checking 40, means for retrieving 50, means for providing 60 may be a receiving means, storing means, monitoring means, checking means, retrieving means, and providing means, respectively. The means for receiving 10, means for storing 20, means for monitoring 30, means for checking 40, means for retrieving 50, and means for providing 60 may be a receiver, storage device, monitor, checker, retriever, and provider, respectively. The means for receiving 10, means for storing 20, means for monitoring 30, means for checking 40, means for retrieving 50, and means for providing 60 may be a receiving processor, storing processor, monitoring processor, checking processor, retrieving processor, and providing processor, respectively.

The means for receiving 10 receives a registration (S10). The registration informs that one or more instances of a network function serve a terminal. The one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses. The terminal is identified by a first terminal identifier.

The means for storing 20 stores the one or more identifiers of the one or more instances of the network function (i.e., the set identifier, the one or more node or network function identifiers, and the one or more network addresses, respectively) along with the first terminal identifier in a mapping relationship (S20). For example, the mapping relationship may be stored in a database such as a mobility database.

The means for monitoring 30 monitors whether a discovery request is received (S30). The discovery request comprises a second terminal identifier.

If the discovery request is received (S30 = yes), the means for checking 40 checks whether the first terminal identifier is identical to the second terminal identifier.

If the first terminal identifier is identical to the second terminal identifier (S40 = yes), the means for retrieving 50 retrieves the one or more identifiers of the one or more instances of the network function from the mapping relationship (S50). The means for providing 60 provides the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request (S60).

Fig. 16 shows an apparatus according to an example embodiment of the invention. The apparatus may be a network function of a NAS handler (such as a AMF) or an element thereof. Fig. 17 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 16 may perform the method of Fig. 17 but is not limited to this method. The method of Fig. 17 may be performed by the apparatus of Fig. 16 but is not limited to being performed by this apparatus.

The apparatus comprises means for monitoring 110 and means for registering 120. The means for monitoring 110 and means for registering 120 may be a monitoring means, and registering means, respectively. The means for monitoring 110 and means for registering 120 may be a monitor and registrator, respectively. The means for monitoring 110 and means for registering 120 may be a monitoring processor and registering processor, respectively. The means for monitoring 110 monitors whether a terminal registers for being served by one or more instances of a network function (S110). The one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses. The terminal is identified by a terminal identifier.

If the terminal registers for being served by the one or more instances of the network function (S110 = yes), the means for registering 120 registers the one or more identifiers of the one or more instances of the network function at a mobility database (S120). In the mobility database, the one or more identifiers of the one or more instances of the network function are mapped to the terminal identifier.

Fig. 18 shows an apparatus according to an example embodiment of the invention. The apparatus may be a database (such as a mobility database) or an element thereof. Fig. 19 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 18 may perform the method of Fig. 19 but is not limited to this method. The method of Fig. 19 may be performed by the apparatus of Fig. 18 but is not limited to being performed by this apparatus.

The apparatus comprises means for receiving 210, means for storing 220, means for monitoring 230, means for checking 240, means for retrieving 250, and means for providing 260. The means for receiving 210, means for storing 220, means for monitoring 230, means for checking 240, means for retrieving 250, means for providing 260 may be a receiving means, storing means, monitoring means, checking means, retrieving means, and providing means, respectively. The means for receiving 210, means for storing 220, means for monitoring 230, means for checking 240, means for retrieving 250, and means for providing 260 may be a receiver, storage device, monitor, checker, retriever, and provider, respectively. The means for receiving 210, means for storing 220, means for monitoring 230, means for checking 240, means for retrieving 250, and means for providing 260 may be a receiving processor, storing processor, monitoring processor, checking processor, retrieving processor, and providing processor, respectively.

The means for receiving 210 receives a registration (S210). The registration informs that one or more instances of a network function serve a PDU session. The one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses. The PDU session is identified by a first session identifier.

The means for storing 220 stores the one or more identifiers of the one or more instances of the network function (i.e., the set identifier, the one or more node or network function identifiers, and the one or more network addresses, respectively) along with the first session identifier in a mapping relationship (S220). For example, the mapping relationship may be stored in a database such as a mobility database.

The means for monitoring 230 monitors whether a discovery request is received (S230). The discovery request comprises a second session identifier.

If the discovery request is received (S230 = yes), the means for checking 240 checks whether the first session identifier is identical to the second session identifier.

If the first session identifier is identical to the second session identifier (S240 = yes), the means for retrieving 250 retrieves the one or more identifiers of the one or more instances of the network function from the mapping relationship (S250). The means for providing 260 provides the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request (S260).

Generally, the first and second session identifiers (and, optionally further session identifiers) may also comprise an identifier of a terminal / UE and/or a (relative) identifier of the respective PDU session established by the terminal I UE. This may be the case as e.g. a PDU session ID may be relative to a given terminal I UE. Thus, the session identifier may comprise an identifier of a terminal and a relative identifier of the protocol data unit session established by said terminal.

Fig. 20 shows an apparatus according to an example embodiment of the invention. The apparatus may be a network function of a NAS handler (such as a AMF) or an element thereof. Fig. 21 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 20 may perform the method of Fig. 21 but is not limited to this method. The method of Fig. 21 may be performed by the apparatus of Fig. 20 but is not limited to being performed by this apparatus. The apparatus comprises means for monitoring 310 and means for registering 320. The means for monitoring 310 and means for registering 320 may be a monitoring means, and registering means, respectively. The means for monitoring 310 and means for registering 320 may be a monitor and registrator, respectively. The means for monitoring 310 and means for registering 320 may be a monitoring processor and registering processor, respectively.

The means for monitoring 310 monitors whether a PDU session is being created or transferred and is being served by one or more instances of a network function (S310). The one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses. The PDU session is identified by a session identifier.

If the PDU session is being created or transferred and is being served by the one or more instances of the network function (S310 = yes), the means for registering 320 registers the one or more identifiers of the one or more instances of the network function at a mobility database (S320). In the mobility database, the one or more identifiers of the one or more instances of the network function are mapped to the session identifier.

Fig. 22 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 810, at least one memory 820 including computer program code, and the at least one processor 810, with the at least one memory 820 and the computer program code, being arranged to cause the apparatus to at least perform at least the method according to at least one of Figs. 15, 17, 19, and 21 and related description.

Some example embodiments are explained with respect to a 6G network. However, the invention is not limited to 6G. It may be used in other networks, too, e.g. in previous of forthcoming generations of 3GPP networks such as 4G, 5G, or 7G, etc. The invention is not even limited to mobile communication networks but may be applied anywhere where service provider and service consumer are located in different domains, such as CN and AN.

A terminal may be a UE, a MTC device, or any other device that may be served by the respective access network. One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.

Names of network elements, network functions, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or network functions and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be deployed in the cloud.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a database (such as a mobility database) or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s). According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a network function and/or a NAS handler (such as a AMF or SMF) or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Each of the entities described in the present description may be embodied in the cloud.

It is to be understood that what is described above is what is presently considered the preferred example embodiments of the present invention. However, it should be noted that the description of the preferred example embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.

Claims

32 Claims:

1. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: receiving a registration informing that one or more instances of a network function serve a terminal, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the terminal is identified by a first terminal identifier; storing the one or more identifiers of the one or more instances of the network function along with said first terminal identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second terminal identifier; checking whether the first terminal identifier is identical to the second terminal identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first terminal identifier is identical to the second terminal identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request.

2. The apparatus according to claim 1 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: supervising whether the registration comprises one or several third terminal identifiers identifying the terminal, wherein the one or several third terminal identifiers are different from the first terminal identifier; storing the one or several third terminal identifiers in the mapping relationship such that the one or several third terminal identifiers are mapped to the first terminal identifier and the one or more identifiers of the one or more instances of the network function.

3. The apparatus according to claim 2, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: 33 checking whether the mapping relationship maps the second terminal identifier to one of the one or several third terminal identifiers; retrieving the identifiers of the one or more instances of the network function from the mapping relationship if the mapping relationship maps the second terminal identifier to one of the one or several third terminal identifiers.

4. The apparatus according to claim 3, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: providing the one or several third terminal identifiers along with the one or more identifiers of the one or more instances of the network function in response to the discovery request if the mapping relationship maps the second terminal identifier to the first terminal identifier.

5. The apparatus according to any of claims 2 to 4, wherein the supervising comprises supervising whether one or several of the one or several third terminal identifiers are one or several previous identifiers of the terminal; and, if one or several of the one or several third terminal identifiers are the one or several previous identifiers of the terminal, the storing comprises at least one of marking the one or several of the one or several third terminal identifiers as previous identifiers and marking another one of the one or several third terminal identifiers as a current identifier.

6. The apparatus according to any of claims 1 to 5, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: monitoring whether a deregistration information is received, wherein the deregistration information informs that the one or more instances of the network function do not handle the terminal anymore; and at least one of deleting the mapping relationship comprising the one or more identifiers of the one or more instances of the network function; and marking the mapping relationship comprising the one or more identifiers of the one or more instances of the network function as an old mapping relationship.

7. The apparatus according to any of claims 1 to 6, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: monitoring whether a subscription request is received from a second network function, wherein the subscription request comprises a fourth terminal identifier; checking whether the first terminal identifier is identical to the fourth terminal identifier if the subscription request is received; storing the subscription request as part of the mapping relationship if the first terminal identifier is identical to the fourth terminal identifier; receiving a registration informing on at least one of that a new instance of the network function serves the terminal, and that a new identifier identifies the terminal; providing an identifier of the new instance of the network function and the new identifier, respectively, in a notification towards the second network function.

8. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: receiving a registration informing that one or more instances of a network function serve a protocol data unit session, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the protocol data unit session is identified by a first session identifier; storing the one or more identifiers of the one or more instances of the network function along with the first session identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second session identifier; checking whether the first session identifier is identical to the second session identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first session identifier is identical to the second session identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request.

9. The apparatus according to claim 8, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: supervising whether the registration comprises one or several third session identifiers identifying the protocol data unit session, wherein the one or several third session identifiers are different from the first session identifier; storing the one or several third session identifiers in the mapping relationship such that the one or several third session identifiers are mapped to the first session identifier and the one or more identifiers of the one or more instances of the network function.

10. The apparatus according to claim 9, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: checking whether the mapping relationship maps the second session identifier to one of the one or several third session identifiers; retrieving the identifiers of the one or more instances of the network function from the mapping relationship if the mapping relationship maps the second session identifier to one of the one or several third session identifiers.

11 . The apparatus according to claim 10, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: providing the one or several third session identifiers along with the one or more identifiers of the one or more instances of the network function in response to the discovery request if the mapping relationship maps the second session identifier to the first session identifier.

12. The apparatus according to any of claims 9 to 11 , wherein the supervising comprises supervising whether one or several of the one or several third session identifiers are one or several previous identifiers of the protocol data unit session; and, if one or several of the one or several third session identifiers are the one or several previous identifiers of the session, the storing comprises at least one of marking the one or several of the one or several third session identifiers as previous identifiers and marking another one of the one or several third session identifiers as a current identifier.

13. The apparatus according to any of claims 8 to 12, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: 36 monitoring whether a deregistration information is received, wherein the deregistration information informs that the one or more instances of the network function do not handle the protocol data unit session anymore; and at least one of deleting the mapping relationship comprising the one or more identifiers of the one or more instances of the network function; and marking the mapping relationship comprising the one or more identifiers of the one or more instances of the network function as an old mapping relationship.

14. The apparatus according to any of claims 8 to 13, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: monitoring whether a subscription request is received from a second network function, wherein the subscription request comprises a fourth session identifier; checking whether the first session identifier is identical to the fourth session identifier if the subscription request is received; storing the subscription request as part of the mapping relationship if the first session identifier is identical to the fourth session identifier, respectively; receiving a registration informing on at least one of that a new instance of the network function serves the protocol data unit session, and that a new identifier identifies the protocol data unit session; providing an identifier of the new instance of the network function and the new identifier, respectively, in a notification towards the second network function.

15. The apparatus according to any of claims 8 to 14, wherein the protocol data unit session is a protocol data unit session of a terminal.

16. The apparatus according to any of claim 8 to 15, wherein each session identifier comprises an identifier of a terminal and an identifier of the protocol data unit session established by said terminal.

17. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: monitoring whether a terminal registers for being served by one or more instances of a network function; 37 registering one or more identifiers of the one or more instances of the network function mapped to a terminal identifier at a mobility database if the terminal registers for being served, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the terminal is identified by the terminal identifier.

18. The apparatus according to claim 17, wherein at least one of the apparatus is comprised in a non-access stratum handler; and the apparatus is comprised in one of the one or more instances of the set of instances of the network function.

19. The apparatus according to any of claims 17 and 18, wherein the monitoring comprises monitoring if the terminal is being handed over to one of the one or more instances of the network function.

20. The apparatus according to any of claims 17 to 19, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: monitoring whether the terminal deregisters or is being deregistered from being served by the one or more instances of the network function; deregistering the one or more instances of the network function mapped to the terminal from the mobility database if the terminal deregisters or is being deregistered from being served.

21. The apparatus according to any of claims 17 to 2019, wherein the network function is a network function of a core network or a network function of an access network.

22. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: monitoring whether a protocol data unit session is being created or transferred and being served by one or more instances of a network function; registering one or more identifiers of the one or more instances of the network function mapped to a session identifier at a mobility database if the protocol data unit session is being created or transferred and being served, wherein the one or more 38 instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the protocol data unit session is identified by the session identifier.

23. The apparatus according to claim 22, wherein at least one of the apparatus is comprised in a non-access stratum handler; and the apparatus is comprised in one of the one or more instances of the set of instances of the network function.

24. The apparatus according to any of claims 22 and 23, wherein the monitoring comprises monitoring if the protocol data unit session is being handed over to one of the one or more instances of the network function.

25. The apparatus according to any of claims 22 to 24, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: monitoring whether the protocol data unit session deregisters or is being deregistered from being served by the one or more instances of the network function; deregistering the one or more instances of the network function mapped to the protocol data unit session from the mobility database if the protocol data unit session deregisters or is being deregistered from being served.

26. The apparatus according to any of claims 22 to 25, wherein the network function is a network function of a core network or a network function of an access network.

27. The apparatus according to any of claims 22 to 26, wherein the protocol data unit session is a protocol data unit session of a terminal.

28. Method comprising: receiving a registration informing that one or more instances of a network function serve a terminal, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network function identifiers, and one or more network addresses, and the terminal is identified by a first terminal identifier; storing the one or more identifiers of the one or more instances of the network function along with said first terminal identifier in a mapping relationship; 39 monitoring whether a discovery request is received, wherein the discovery request comprises a second terminal identifier; checking whether the first terminal identifier is identical to the second terminal identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first terminal identifier is identical to the second terminal identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request.

29. The method according to claim 28, further comprising: supervising whether the registration comprises one or several third terminal identifiers identifying the terminal, wherein the one or several third terminal identifiers are different from the first terminal identifier; storing the one or several third terminal identifiers in the mapping relationship such that the one or several third terminal identifiers are mapped to the first terminal identifier and the one or more identifiers of the one or more instances of the network function.

30. The method according to claim 29, further comprising: checking whether the mapping relationship maps the second terminal identifier to one of the one or several third terminal identifiers; retrieving the identifiers of the one or more instances of the network function from the mapping relationship if the mapping relationship maps the second terminal identifier to one of the one or several third terminal identifiers.

31. The method according to claim 30, further comprising: providing the one or several third terminal identifiers along with the one or more identifiers of the one or more instances of the network function in response to the discovery request if the mapping relationship maps the second terminal identifier to the first terminal identifier.

32. The method according to any of claims 29 to 31 , wherein 40 the supervising comprises supervising whether one or several of the one or several third terminal identifiers are one or several previous identifiers of the terminal; and, if one or several of the one or several third terminal identifiers are the one or several previous identifiers of the terminal, the storing comprises at least one of marking the one or several of the one or several third terminal identifiers as previous identifiers and marking another one of the one or several third terminal identifiers as a current identifier.

33. The method according to any of claims 28 to 32, further comprising: monitoring whether a deregistration information is received, wherein the deregistration information informs that the one or more instances of the network function do not handle the terminal anymore; and at least one of deleting the mapping relationship comprising the one or more identifiers of the one or more instances of the network function; and marking the mapping relationship comprising the one or more identifiers of the one or more instances of the network function as an old mapping relationship.

34. The method according to any of claims 28 to 33, further comprising: monitoring whether a subscription request is received from a second network function, wherein the subscription request comprises a fourth terminal identifier; checking whether the first terminal identifier is identical to the fourth terminal identifier if the subscription request is received; storing the subscription request as part of the mapping relationship if the first terminal identifier is identical to the fourth terminal identifier; receiving a registration informing on at least one of that a new instance of the network function serves the terminal, and that a new identifier identifies the terminal; providing an identifier of the new instance of the network function and the new identifier, respectively, in a notification towards the second network function.

35. Method comprising: receiving a registration informing that one or more instances of a network function serve a protocol data unit session, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node or network 41 function identifiers, and one or more network addresses, and the protocol data unit session is identified by a first session identifier; storing the one or more identifiers of the one or more instances of the network function along with the first session identifier in a mapping relationship; monitoring whether a discovery request is received, wherein the discovery request comprises a second session identifier; checking whether the first session identifier is identical to the second session identifier if the discovery request is received; retrieving the one or more identifiers of the one or more instances of the network function from the mapping relationship if the first session identifier is identical to the second session identifier; providing the retrieved one or more identifiers of the one or more instances of the network function in response to the discovery request.

36. The method according to claim 35, further comprising: supervising whether the registration comprises one or several third session identifiers identifying the protocol data unit session, wherein the one or several third session identifiers are different from the first session identifier; storing the one or several third session identifiers in the mapping relationship such that the one or several third session identifiers are mapped to the first session identifier and the one or more identifiers of the one or more instances of the network function.

37. The method according to claim 36, further comprising: checking whether the mapping relationship maps the second session identifier to one of the one or several third session identifiers; retrieving the identifiers of the one or more instances of the network function from the mapping relationship if the mapping relationship maps the second session identifier to one of the one or several third session identifiers.

38. The method according to claim 37, further comprising: providing the one or several third session identifiers along with the one or more identifiers of the one or more instances of the network function in response to the discovery request if the mapping relationship maps the second session identifier to the first session identifier. 42

39. The method according to any of claims 36 to 38, wherein the supervising comprises supervising whether one or several of the one or several third session identifiers are one or several previous identifiers of the protocol data unit session; and, if one or several of the one or several third session identifiers are the one or several previous identifiers of the session, the storing comprises at least one of marking the one or several of the one or several third session identifiers as previous identifiers and marking another one of the one or several third session identifiers as a current identifier.

40. The method according to any of claims 35 to 39, further comprising: monitoring whether a deregistration information is received, wherein the deregistration information informs that the one or more instances of the network function do not handle the protocol data unit session anymore; and at least one of deleting the mapping relationship comprising the one or more identifiers of the one or more instances of the network function; and marking the mapping relationship comprising the one or more identifiers of the one or more instances of the network function as an old mapping relationship.

41 . The method according to any of claims 35 to 40, further comprising: monitoring whether a subscription request is received from a second network function, wherein the subscription request comprises a fourth session identifier; checking whether the first session identifier is identical to the fourth session identifier if the subscription request is received; storing the subscription request as part of the mapping relationship if the first session identifier is identical to the fourth session identifier, respectively; receiving a registration informing on at least one of that a new instance of the network function serves the protocol data unit session, and that a new identifier identifies the protocol data unit session; providing an identifier of the new instance of the network function and the new identifier, respectively, in a notification towards the second network function.

42. The method according to any of claims 35 to 41 , wherein the protocol data unit session is a protocol data unit session of a terminal. 43

43. The method according to any of claims 35 to 42, wherein each session identifier comprises an identifier of a terminal and an identifier of the protocol data unit session established by said terminal.

44. Method comprising: monitoring whether a terminal registers for being served by one or more instances of a network function; registering one or more identifiers of the one or more instances of the network function mapped to a terminal identifier at a mobility database if the terminal registers for being served, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the terminal is identified by the terminal identifier.

45. The method according to claim 44, wherein at least one of an apparatus performing the method is comprised in a non-access stratum handler; and an apparatus performing the method is comprised in one of the one or more instances of the set of instances of the network function.

46. The method according to any of claims 44 and 45, wherein the monitoring comprises monitoring if the terminal is being handed over to one of the one or more instances of the network function.

47. The method according to any of claims 44 to 46, further comprising: monitoring whether the terminal deregisters or is being deregistered from being served by the one or more instances of the network function; deregistering the one or more instances of the network function mapped to the terminal from the mobility database if the terminal deregisters or is being deregistered from being served.

48. The method according to any of claims 44 to 47, wherein the network function is a network function of a core network or a network function of an access network.

49. Method comprising: 44 monitoring whether a protocol data unit session is being created or transferred and being served by one or more instances of a network function; registering one or more identifiers of the one or more instances of the network function mapped to a session identifier at a mobility database if the protocol data unit session is being created or transferred and being served, wherein the one or more instances of the network function are identified by at least one of a set identifier, one or more node identifiers, and one or more network addresses, and the protocol data unit session is identified by the session identifier.

50. The method according to claim 49, wherein at least one of an apparatus performing the method is comprised in a non-access stratum handler; and an apparatus performing the method is comprised in one of the one or more instances of the set of instances of the network function.

51 . The method according to any of claims 49 and 50, wherein the monitoring comprises monitoring if the protocol data unit session is being handed over to one of the one or more instances of the network function.

52. The method according to any of claims 49 to 51 , further comprising: monitoring whether the protocol data unit session deregisters or is being deregistered from being served by the one or more instances of the network function; deregistering the one or more instances of the network function mapped to the protocol data unit session from the mobility database if the protocol data unit session deregisters or is being deregistered from being served.

53. The method according to any of claims 49 to 52, wherein the network function is a network function of a core network or a network function of an access network.

54. The method according to any of claims 49 to 53, wherein the protocol data unit session is a protocol data unit session of a terminal.

55. A computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of claims 28 to 54. 45

56. The computer program product according to claim 55, embodied as a computer-readable medium or directly loadable into a computer.