WO2023001353A1

WO2023001353A1 - Ue persistent information storage across cm state transitions

Info

Publication number: WO2023001353A1
Application number: PCT/EP2021/070096
Authority: WO
Inventors: Bahare MASOOD KHORSANDI; Ömer BULAKCI; Subramanya CHANDRASHEKAR; Mu HE
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2021-07-19
Filing date: 2021-07-19
Publication date: 2023-01-26
Anticipated expiration: 2024-01-19

Abstract

It is provided a method comprising: monitoring if a terminal transits from a connected state into an idle state, wherein a terminal context is related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; storing the terminal context for the terminal into a database while the terminal is in the connected state or when the terminal transits from the connected state into the idle state; maintaining at least a part of the session-unrelated portion of the terminal context for the terminal in the database if the terminal transits from the connected state into the idle state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

Description

UE persistent information storage across CM state transitions

Field of the invention

The present disclosure relates to UE context in relation state transitions (in particular CM state transitions).

Abbreviations

3GPP 3^rd Generation Partnership Project

4G / 5G / 6G 4^th / 5^th / 6^th Generation 5GS 5G System

AMF Access and Mobility Management Function

AN Access Network

AN-DSF AN Data Storage Function

CM Connection Management

CN Core Network

CN-RNTI Core Network - Radio Network Temporary Identification

CP Control Plane

CU Central Unit

DB Database

DRB Data Radio Bearer

DU Distributed Unit eNB evolved NodeB gNB next Generation NodeB

GSM Global System for Mobile Communication

GUTI Global Unique Temporary Identifier

ID Identifier

IMEI International Mobile Station Equipment Identity

IMEISV International Mobile Station Equipment Identity Software Version

IMSI International Mobile Subscriber Identity

LTE Long-Term Evolution

MME Mobility Management Entity

MSC Mobile Switching Center NAS Non-Access Stratum

NF Network Function

NG-AP Next Generation Application Protocol

NG-C Control plane interface of NG-RAN

NG-RAN Next Generation RAN

PDU Protocol Data Unit

PLMN Public Land Mobile Network

RACH Random Access Channel

RAN Radio Access Network

RAN-DB RAN database

RA-RNTI Radio Access - Radio Network Temporary Identification

RIC RAN Intelligent Controller

RM Registration Management

RRC Radio Resource Control

SB Service- Based

SBI Service-Based Interface

S-TMSI Serving TMSI

SUPI Subscription Permanent Identifier

TMSI Temporary Mobile Subscriber Identities

TS Technical Specification

UE User Equipment

UP User Plane

Background

In 3GPP TS 38.300 the NG control plane interface (NG-C) is defined as an interface between the NG-RAN node and the AMF over N2 interface. The NG interface supports the UE Context Management function which allows the AMF to establish, modify or release a UE Context in the AMF and the NG-RAN node, e.g. to support user associated signaling on NG-C. The corresponding procedures are defined:

• Initial Context Setup;

• UE Context Release Request;

• UE Context Release;

• UE Context Modification;

• RRC Inactive Transition Report. In 3GPP TS 23.501, the Connection Management (CM) procedure is defined which comprises the functions of establishing and releasing a NAS signaling connection between a UE and the AMF over N1 interface. It comprises both the access network (AN) signaling connection between the UE and the AN (e.g., RRC Connection over 3GPP access) and the N2 connection for this UE between the AN and the AMF. Two CM states are used to reflect the NAS signaling connection of the UE with the AMF:

• CM-IDLE: A UE in a CM-IDLE state has no NAS signaling connection established with the AMF over N1 interface. There are no AN signaling connections, N2 connection, and N3 connections for the UE in the CM-IDLE state. In the CM-IDLE state, the UE is in the RRC IDLE state in the AN.

• CM-CONNECTED: A UE in a CM-CONNECTED state has a NAS signaling connection with the AMF over N1 interface. A NAS signaling connection uses an RRC Connection between the UE and the NG-RAN and an NGAP UE association between the AN and the AMF for 3GPP access. In the CM- CONNECTED state, the UE is either in RRC CONNECTED state or RRC INACTIVE state in the AN.

In addition, a UE/user needs to register with the network to receive services that require registration. Once registered, and if applicable, the UE updates its registration with the network. The Registration Management (RM) is used to register or deregister a UE/user with the network and establish the UE context in the network. Two RM states are used in the UE and the AMF to reflect the registration status of the UE in the network (PLMN):

• RM-DEREGISTERED: In this state, the UE is not registered with the network. The UE context in AMF holds no valid location or routing information for the UE so the UE is not reachable by the AMF.

• RM-REGISTERED: In this state, the UE is registered with the network and can receive services that require registration with the network.

If the UE is both in CM-IDLE state and in RM-REGISTERED state, the UE shall

• Respond to paging by performing a Service Request procedure;

• Perform a Service Request procedure when the UE has uplink signaling or user data to be sent. NG-RAN node UE context is a collection of information in an NG-RAN node associated with one UE, which contains the necessary information required to maintain the NG-RAN services towards the UE in a CONNECTED state. This includes UE’s identifiers and those allocated by network, PDU session details, user plane tunnel addresses and other user session information. The UE context also includes some capability information and intelligence generated by network pertaining to that UE. The NG-RAN node UE context is created when the UE transitions to RRC CONNECTED for the first time. During handover preparation, the UE context is passed to the target NG-RAN node.

A similar UE context is stored in the UE as well, albeit not all information in the UE context stored in NG-RAN is typically stored in the UE. The respective UE context is released in both network and the UE whenever the UE transitions from CM-CONNECTED to CM- IDLE.

RAN uses N2 interface (for the control plane) and N3 interface (for the user plane) to communicate with the core network. N1 interface is an interface from 5G-UE to AMF of core (via NG-RAN). N1 interface is transparent for NG-RAN.

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: monitoring if a terminal transits from a connected state into an idle state, wherein a terminal context is related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; storing the terminal context for the terminal into a database while the terminal is in the connected state or when the terminal transits from the connected state into the idle state; maintaining at least a part of the session-unrelated portion of the terminal context for the terminal in the database if the terminal transits from the connected state into the idle state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

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: supervising if a terminal transits from an idle state into a connected state, wherein a terminal context is to be related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; retrieving at least a part of the session-unrelated portion of the terminal context for the terminal from a database if the terminal transits from the idle state into the connected state; applying the retrieved at least part of the session-unrelated portion of the terminal context to the connected state of the terminal if the terminal transits from the idle state into the connected state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

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: storing a terminal context associated with a context key for a terminal in a first database, wherein the terminal context is received from a first instance of a network function, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; receiving a first request from a second instance of the network function, including a context key, to provide at least a part of the session-unrelated portion of the terminal context for the terminal; providing at least the part of the session-unrelated portion of the terminal context for the terminal, associated with the context key, to the second instance of the network function in response to receiving the first request. 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: supervising if a first database receives a request to provide at least a part of a session-unrelated portion of a terminal context associated with a given context key for a terminal, wherein the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; checking, based on the given context key, if the first database stores at least the part of the session-unrelated portion of the terminal context for the terminal if the first database receives the request; querying a global database, based on the given context key, for an identification of a second database storing at least the part of the session-unrelated portion of the terminal context for the terminal if the first database does not store at least the part of the session-unrelated portion of the terminal context for the terminal; receiving at least the part of the session-unrelated portion of the terminal context for the terminal from the second database.

According to a fifth 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 if a query for an identification of a second database is received from a first database based on at least a context key or a cell id, wherein the second database stores at least a part of a session-unrelated portion of a terminal context for a terminal, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; causing a transfer of at least the part of the session-unrelated portion of the terminal context for the terminal from the second database to the first database if the query is received from the first database.

According to a sixth 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: supervising if a terminal in a connected state receives an identifier from a network function, wherein a terminal context is related to the terminal in the connected state, and the identifier is related to the terminal context; instructing the terminal to store the identifier if the terminal receives the identifier; monitoring if the terminal decides to send a connection request to transit from an idle state to the connected state; providing the identifier to the network function if the terminal sends the connection request; each of the connected state and the idle state is a respective state of a connection management for the terminal.

According to a seventh aspect of the invention, there is provided a method comprising: monitoring if a terminal transits from a connected state into an idle state, wherein a terminal context is related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; storing the terminal context for the terminal into a database while the terminal is in the connected state or when the terminal transits from the connected state into the idle state; maintaining at least a part of the session-unrelated portion of the terminal context for the terminal in the database if the terminal transits from the connected state into the idle state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

According to an eighth aspect of the invention, there is provided a method comprising: supervising if a terminal transits from an idle state into a connected state, wherein a terminal context is to be related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; retrieving at least a part of the session-unrelated portion of the terminal context for the terminal from a database if the terminal transits from the idle state into the connected state; applying the retrieved at least part of the session-unrelated portion of the terminal context to the connected state of the terminal if the terminal transits from the idle state into the connected state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

According to a ninth aspect of the invention, there is provided a method comprising: storing a terminal context associated with a context key for a terminal in a first database, wherein the terminal context is received from a first instance of a network function, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; receiving a first request from a second instance of the network function, including a context key, to provide at least a part of the session-unrelated portion of the terminal context for the terminal; providing at least the part of the session-unrelated portion of the terminal context for the terminal, associated with the context key, to the second instance of the network function in response to receiving the first request.

According to a tenth aspect of the invention, there is provided a method comprising: supervising if a first database receives a request to provide at least a part of a session-unrelated portion of a terminal context associated with a given context key for a terminal, wherein the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; checking, based on the given context key, if the first database stores at least the part of the session-unrelated portion of the terminal context for the terminal if the first database receives the request; querying a global database, based on the given context key, for an identification of a second database storing at least the part of the session-unrelated portion of the terminal context for the terminal if the first database does not store at least the part of the session-unrelated portion of the terminal context for the terminal; receiving at least the part of the session-unrelated portion of the terminal context for the terminal from the second database. According to an eleventh aspect of the invention, there is provided a method comprising: monitoring if a query for an identification of a second database is received from a first database based on at least a context key or a cell id, wherein the second database stores at least a part of a session-unrelated portion of a terminal context for a terminal, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; causing a transfer of at least the part of the session-unrelated portion of the terminal context for the terminal from the second database to the first database if the query is received from the first database.

According to a twelfth aspect of the invention, there is provided a method comprising: supervising if a terminal in a connected state receives an identifier from a network function, wherein a terminal context is related to the terminal in the connected state, and the identifier is related to the terminal context; instructing the terminal to store the identifier if the terminal receives the identifier; monitoring if the terminal decides to send a connection request to transit from an idle state to the connected state; providing the identifier to the network function if the terminal sends the connection request; each of the connected state and the idle state is a respective state of a connection management for the terminal.

Each of the methods of the seventh to twelfth aspect may be a method of terminal context storage.

According to a thirteenth 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 seventh to twelfth 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:

• signaling load may be reduced or offloaded as a background task; • session independent information for the UE does not get lost and may be applied whenever appropriate, regardless of the UE’s state transitions.

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 a RAN DB implementation;

Fig. 2 (comprising Figs. 2a and 2b) shows a message flow according to some example embodiments of the invention;

Fig. 3 shows a hierarchical database design according to some example embodiments of the invention;

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

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

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

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

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

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

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

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

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

Fig. 13 shows a method according to an example embodiment 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; and Fig. 16 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.

RAN Database (hereafter RAN DB, also known as AN DB) is a context storage shared by a set of NG-RAN nodes and AMFs, e.g., in the same target area or geographical area. The RAN DB may be implemented as a central entity or multiple local entities with a central entity co-ordinating them. The usefulness is when data stored by one entity is retrieved by another entity by providing the same key. The storing and retrieving entities could be NG-RAN nodes, AMFs or one of the logical components of those nodes. Fig. 1 shows an example of a RAN DB, wherein the RAN DB is connected to two gNBs and three AMFs.

For a UE undergoing state transitions from CM-IDLE to CM-CONNECTED, the UE context needs to be created fora regular operation of the UE, e.g., related to the handling of the sessions of the UE according to the UE subscription and profile. Subsequent state transitions for each individual UE may happen several times between CM-IDLE and CM- CONNECTED and back, and each time when the UE transitions to CM-CONNECTED state, a new connection to NG-RAN node (hereafter gNB) and registration request toward AMF is required.

UE context information can be divided into two main categories:

• UE Connection Context which is regarding the establishment of the UE connection such as UE identifiers, UE capability, PDU sessions IDs, allowed NSSAI, etc.);

• UE Historical Intelligence is the information generated based on the use cases such as SON applications and AI/ML solutions and used to identify and optimize service for UE groups, such as UE trajectory, power-related, mobility-related behaviors or patterns, etc.

The difference between the UE connection context and the historical intelligence is that the former is session related which includes dynamic resource allocation in each logical entity like UE identifiers, network addresses and identifiers, tunnel end-point identifiers, UE’s DRB info, etc. The latter is kind of semi-static information like UE mobility history information, UE power related data/inference, intelligence built based on UE/network reporting/monitoring, n/w algorithm information applicable to the UE etc. The UE historical intelligence is assumed to be built over a longer period of time and maybe used by the network whenever the UE enters CONNECTED mode. The historical intelligence may be a part of other information stored in the context which is not related to a particular user session. This part is also called a general (or session-unrelated) portion of the respective UE context. The UE connection context and the session-unrelated portion jointly make up the UE context information. I.e., the UE context information may consist of the session-related portion and the session-unrelated portion. Hereinafter, historical intelligence may be read as a pars pro toto for the session-unrelated portion.

In addition to 3GPP technology, the Open-Radio Access Networks (O-RAN) Alliance is developing technology to provide open radio access networks (see, e.g., O-RAN Near- Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles 1.01 - July 2020 and O-RAN Near-Real-time RAN Intelligent Controller, E2 Application Protocol 1.01 - July 2020). The O-RAN system architecture can include an automation part that consists of a Near-Real-time (Near-RT) RAN Intelligence Controller (RIC) within the RAN and a Non-RT RIC within Service Management and Orchestration (SMO). The Near-RT may connect via an E2 interface to the 3GPP RAN, e.g., 5G standalone architecture with split RAN (CU/DU-split), where the RAN nodes are called E2 Nodes. The Non-RT RIC may reside in service management & orchestration (SMO). The Non- RT RIC may perform non-real-time operations and may (through the A1 interface) communicate with Near-RT RIC over a defined A1 interface. Moreover, the Non-RT RIC may modify internal applications at the Non-RT RIC or Near-RT RIC. The Non-RT RIC 330 may monitor, analyze, and feedback on the Near-RT RIC state; provide enrichment information; and facilitate, train, and distribute machine learning (ML) models for previous tasks. The Near-RT RIC may, through the E2 interface, communicate with one or more E2 Nodes, such as E2 node (open control unit (O-CU) control plane (O-CU-CP), O-CU user plane (O-CU-UP), open distributed unit (O-DU), and open evolved NodeB (O-eNB)) for time sensitive management and control of the radio resources, such as interference management, handover management, Quality of Service (QoS) management, and radio connection management. Both Non-RT RIC and Near-RT RIC employ SBA principles and utilize SBI for communicating internally and with each other. Nevertheless, the ORAN also employs P2P interfaces, such as the E2 interface towards E2 Nodes, rather than a service-based architecture including service-based interfaces (SBI).

The intelligence generated at RAN or RIC, based on AI/ML methods and employed for optimization algorithms in RAN is not stored in the AMF UE context. Hence this cannot be retrieved from the CN when a UE transitions to CM-CONNECTED from CM-IDLE subsequently.

In the prior art, the network does not store the UE context when a UE is transitioned to IDLE mode. Whenever UE changes its status to CM-IDLE and comes back to CM- CONNECTED, gNB creates UE Connection Context. On the other hand, the UE Historical Intelligence is lost as a result of the previous status change of UE from CM- CONNECTED to CM-IDLE and it is not maintained in the CM-IDLE mode. It cannot be retrieved when the UE comes back to CM-CONNECTED and has to be regenerated in the new session, which takes quite a long time.

Some example embodiments of the invention address the issue of data loss during multiple UE state transitions.

Some aspects of some example embodiments of the invention may be described roughly as follows: a. In some example embodiments, when the UE leaves the CONNECTED mode to IDLE mode for the first time, the UE context, which includes both UE Historical Intelligence and UE Connection Context data, is stored in the RAN DB. NG- RAN node and/or AMF may retrieve the UE context (at least the UE historical intelligence) from the RAN DB whenever the UE transitions from CM-IDLE to CM- CONNECTED. The UE context is stored or updated in the RAN DB in the subsequent CONNECTED to IDLE state transitions as well. In 5G core, one or more (if not all) of the functions are defined as a service-based (SB) architecture (SBA) which can be implemented in a cloud-based platform and utilizes service-based interfaces (SBI) for exposing and accessing the defined and/or implemented services (see, e.g., 3GPP TS 23.501] For example, core network functions, such as the network slice selection function (NSSF), network exposure function (NEF), policy control function (PCF), and the like. These network functions (NFs) may be self-contained, independent, and reusable. For example, a network function may provide a service, such as a service provider as well as consume services, such as a service consumer. And, the network function may expose its services through a Service Based Interface (SBI) that employs a well-defined interface application programming interface (API), such as a REST API using a cloud-friendly transfer protocol, such as HTTP(S) (also referred to an SBI messaging bus). In the 5G core SBA for example, a consumer inquires at a network repository function (NRF) in order to discover an appropriate service producer instance. In the 5G core for example, in order to discover and select the appropriate service instances, multiple filtering criteria may be applied by NRF (see, e.g., 3GPP TS 29.510). The network function (NF) service is one type of capability exposed by an NF (e.g., a NF service producer) to other authorized NFs (NF service consumers) through a service-based interface (SBI) as described in for example 3GPP TS 23.501. The NF may expose one or more NF services. NF services may communicate directly between NF Service Consumers and NF Service Producers, or indirectly via a Service Communication Proxy (SCP). However, according to the current specifications, the access network (AN), such as a radio access network (RAN), and the associated interfaces within the access network and between the access network and the core network (CN) may continue to be defined in terms of legacy point- to-point (P2P) interfaces, rather than in accordance with a service-based architecture. Moreover, the ORAN also employs peer-to-peer (P2P) interfaces, such as the E2 interface towards E2 Nodes, rather than a service-based architecture including service- based interfaces (SBI).

In the 5G System (5GS) for example, the N2 interface 112 is a 3GPP NG-C Application Protocol over stream control transmission protocol (SCTP), and is between RAN (e.g., a gNB) and an Access and Mobility management Function (AMF) in the core network. Within the access network, there are other point-to-point (P2P) interfaces, such as the Xn interface between two base stations (e.g., gNBs), the F1 interface between a central unit (CU) and a distributed unit (DU) in case of a disaggregated base station (gNB), and the E1 interface between the Centralized Unit Control Plane (CU-CP) and the Centralized Unit User Plane (CU-UP) (see, e.g., 3GPP TS 38.401 fora description of the disaggregated gNB including the CU-CP, CU-CP, DU, and the like).

In some example embodiments, the RAN DB may be employed as a data storage function (DSF) as part of service based architecture in RAN, referred to as service-based RAN (SB-RAN) herein. In SB-RAN, overall system architecture and framework can include Service-Based Interfaces (SBI) between (R)AN and CN, and within (R)AN. An SB-RAN architecture can comprise AN elements, such as RAN NFs belonging to a 3GPP and O-RAN. Such SB-RAN architecture may be referred to as a unified SB-(R)AN architecture. In some example embodiments, one of the proposed functions is AN Data Storage Function (AN-DSF) which is a database that can be implemented in a centralized way, e.g., AN-DSF for multiple AN nodes, or a distributed way, e.g., AN node DSF. It proposes a Data Storage service that involves a DB to store data (e.g., UE context data) that may be accessible to any authorized network function (NF).

In some example embodiments, there is provided a data storage function (DSF) having a service-based interface (SBI). In some example embodiments, the DSF is a (R)AN element (function, or node), in which case it is referred to as a (R)AN-DSF. The (R)AN DSF may be used to retrieve (e.g., fetch), store, and update a UE’s context information. These operations may be performed by any authorized network function (NF), such as a source gNB base station, a target gNB base station, Near-RT RIC, and/or other network functions or entities in the (R)AN and/or core and/or another domain, e.g., network management or service domain. The DSF may be accessed by an authorized entity to store a UE’s context information. Moreover, the UE context information at the DSF may be accessed for updating in case of an event occurrence requiring an update on one or more pieces of UE context information or for retrieving in case of an event occurrence requiring the presence one or more pieces of UE context information. The DSF may provide UE context storage, update, fetch and any other operation that may provide efficient handling of UE context information in the network.

Although some of the examples described herein depict and describe the RAN-DSF as a single NF, the RAN-DSF may be implemented as part of a data storage architecture that may include one or more elements (e.g., functions or nodes). For example, a RAN data storage architecture may include a RAN-DSF, a data repository, and/or a data management entity. Moreover, different deployment options may be implemented, where the elements may be collocated. Furthermore, the elements of the data storage architecture may perform storage and retrieval of data, such as UE context information.

In some example embodiments, the authorized and registered (R)AN elements (e.g., NFs, access nodes, and/or Near-RT RIC(s)) may subscribe, via the SBI, to the (R)AN DSF’s UE context service with the associated (R)AN element ID, e.g., gNB ID and/or E2 Node ID. The context service at the DSF is responsible for handling registration, subscription, retrieval, and/or publication of UE context information. The authorization may be performed by the RAN DSF or another NF, e.g., network repository function, which can be in RAN. For the authorization, the NF profiles and the associated authorized services may be pre-configured. The authorization can be based on, e.g., operator configurations and/or network management configurations, such as OAM.

In some use cases, the UE Connection Context can also be useful in a subsequent session, e.g., in case of stationary UEs that are associated with certain slices or services. For such UEs, some information in the connection context could be more deterministic over certain time period. Thus, in some example embodiments, the NG-RAN node and/or AMF may retrieve at least some part of the UE connection context, too. b. In some example embodiments, a UE persistent identifier which remains same across one or more state transitions (e.g.: Masked IMEI or its derivative, S-TMSI, GUTI, etc.) is used as a key to index the UE context stored in RAN DB so that the context retrieval can be performed from anywhere in the RAN. As another option, in some example embodiments, a network allocated identifier (e.g.: AMF ID + AMF UE NGAP ID) is sent to the UE while it is in CM-CONNECTED mode and the UE is asked to remember and return it whenever the UE returns from CM-IDLE to CM-CONNECTED mode.

Some example embodiments of the invention address the problem of UE context transfer in case of a UE entering CM-CONNECTED mode from CM-IDLE mode. In the description of the embodiments it is assumed that the UE context storage is performed only after the UE’s first network access, i.e. its first state transition to CM-CONNECTED mode. Hence, UE context retrieval is only possible after the UE context has been stored for the first time.

The case of UE Context retrieval when UE changes its status from CM-IDLE to CM- Connected, after having gone from CONNECTED to IDLE, is illustrated at greater detail hereinafter. Herein, it is assumed that some or all of the gNBs and AMFs who are under the same coverage/geographical area (i.e. , serving the same set of cells) share a RAN DB. However, in some example embodiments, the RAN DB may be connected to a single gNB and/or to a single AMF. Having a shared database between the gNBs and AMFs can help to facilitate the storage and retrieval of UE Context information. For the first time registration of a UE to the CN and each time that UE changes its status (e.g., CM-IDLE to CM-CONNECTED), the serving gNBs and AMFs may add/update the respective UE context in the RAN DB. A UE may have information stored by both NG RAN and AMF in the same or different UE context (depending on the context key used) which can be later retrieved by the corresponding entities by providing the same context key.

Fig. 2 (comprising Figs. 2a and 2b) shows a call flow of the UE context retrieval in case of a state transition of a UE according to some example embodiments of the invention. Figs. 2a and 2b are parts of the message flow for the same UE, where the UE undergoes transition from idle mode to connected mode more than once.

The call flow, first (on Fig. 2a) shows some actions related to the UE connection request according to the prior art. In addition, during the first time period when the UE is in CM- CONNECTED and RM REGISTERED state (latest when the UE transitions to CM-IDLE), (source) gNB and/or (source) AMF will store/update the respective UE context in RAN DB using a respective context key. Then, potentially after some time, the UE goes into CM-IDLE state.

The second part of the call flow (on Fig. 2b) is related to the scenario where the same UE returns to CM-CONNECTED, after being in CM-IDLE mode. In this case, related UE context can be retrieved by target gNB and/or serving AMF from RAN DB, by providing the same identifier which was used as context key. In some example embodiments, in particular if a network allocated context key is employed, the UE is expected to store and return the context key in the RRC Connection Request to the target gNB. The target gNB is the gNB at which the UE goes into CM-CONNECTED again. The target gNB may be the same as or different from the source gNB. Correspondingly, the serving AMF before the state transition to CM-IDLE may be the same as or different from the serving AMF after the state transition from CM-IDLE.

For the retrieval, the context is stored in the RAN DB indexed by the context key. We propose the following options for the context key: a. UE 5G-GUTI (Global Unique Temporary Identifier). 5G-GUTI contains a variety of information e.g., information regarding the cell and also the responsible AMF, and also it is one of the most secure UE identification that can be used between UE, gNB, and AMF. b. S-TMSI c. Masked IMEI (International Mobile Station Equipment Identity) or a derivative of it. d. A network allocated identifier may be employed for this purpose. Here, the network may allocate the identifier (e.g.: AMF ID + AMF UE NGAP ID) to the UE and the UE is asked to remember and return it whenever the UE returns from IDLE to CONNECTED mode. The network allocated identifier should be unique in the RAN area.

NOTE: AMF ID is unique in the entire RAN and AMF UE NGAP ID is a ID allocated by the AMF to the UE and is unique inside the coverage of the AMF. A combination of these two IDs will be unique in the entire RAN.

In detail, the call flow for PART-1 (Fig. 2a) of some example embodiments is as follows:

1. UE requests network access for the first-time using RRC connection setup request to Source gNB. There can be different trigger events for the connection setup request. For example, the trigger for such connection request can be by the UE, i.e. , mobile originated (MO) traffic or can be by the network via paging, i.e. , mobile terminated (MT) traffic. The UE may perform the initial access via, e.g., 2-step RACH and 4-step RACH.

2. Upon receipt of RRC connection setup request, Source gNB creates a UE context.

3. Source gNB replies to the RRC connection setup request by RRC connection setup and provides the created UE context or a part of it to UE. UE is now in CM- CONNECTED mode. After the RRC connection is established, gNB selects an AMF. Source gNB stores the UE context, indexed by UE context key, into the RAN DB (may be implemented as RAN DSF). RAN DB acknowledges that the UE context is stored. Actions 3 and (4+5) may be performed in parallel or in an arbitrary sequence. In order to register the UE with the core network, before establishing a PDU session, source gNB sends an Initial UE message to the AMF. The NG-C message containing the Initial UE message to the AMF may optionally comprise information regarding the stored UE context of the gNB. Upon receipt of the Initial UE message, AMF creates its UE context for the session after the UE authentication is successful. AMF stores its UE context in RAN DB. If the NG-C message comprises information of the stored UE context for the gNB, AMF may re-use the same context key. Thus, it may store “its” UE context in the same UE context as the UE context of the gNB. Alternatively, AMF may use an own context key and, thus, store a further UE context for the UE in the RAN DB. RAN DB acknowledges that the UE context of the AMF is stored in the RAN DB. The UE may setup PDU sessions to perform UP data transmission (in UL and/or DL), and any NG-RAN logical entity (e.g.: gNB-CU-CP, gNB-DU, gNB-CU-UP) or any other RAN network function or AMF may generate “UE historical intelligence” information, while the UE is in CONNECTED mode. This is stored in the RAN DB indexed by the same context key which was used to store the session-related portion of the UE context. Some time later, the PDU sessions are released at AMF and the session-related portion of the UE context may be removed. In some example embodiments, AMF may send an Update UE Context message associated with the UE context key. This message may include an indication to delete only the session related data. Furthermore, this message may include modifications to the UE context before the UE is sent to the Idle state. The UE is sent to CM-IDLE. UE may remain in RM-REGISTERED state. For this purpose, AMF sends UE context release command to source gNB. Accordingly, source gNB releases (removes) its UE context. In some example embodiments, source gNB may send an Update UE Context message associated with the UE context key. This message may include an indication to delete only the session related data. Furthermore, this message may include modifications to the UE context before the UE is sent to the Idle state. 13. The Source gNB sends RRC Release to UE such that the UE goes to CM-IDLE. The source gNB may also provide the UE with a UE persistent identifier (ID) which the UE is expected to return to the NG-RAN node in the next RRC Connection Request. In some example embodiments, the persistent identifier can be the UE context key. That is, the UE persistent ID and the UE context key are either the same or are mapped to each other at the network side.

In Fig. 2a, at release of the PDU sessions and the RRC connection, RAN DB is not informed on the UE release. Therefore, RAN DB maintains the UE context(s). However, in some example embodiments, AMF and/or gNB inform RAN DB on the release(s). In such example embodiments, RAN DB may remove a part of the UE context(s). However, RAN DB maintains at least a part of the session-unrelated portion of the UE context(s). In some example embodiments, RAN DB maintains the entire session-unrelated portion of the UE context(s).

The call flow for PART-2 (Fig. 2b) of this embodiment is described below. The actions of PART-2 follow those of PART-1. The time lag between these PARTs is arbitrary.

14. UE performs 2^nd (or subsequent) network access using RRC Connection request to target gNB. Source gNB and Target gNB may be the same or different from each other. There can be different trigger events for the connection setup request. For example, the trigger for such connection request can be by the UE, i.e. , mobile originated (MO) traffic or can be by the network via paging, i.e., mobile terminated (MT) traffic. The UE may perform the initial access via, e.g., 2-step RACH and 4-step RACH.

15. Since the Target gNB may want to reuse at least a portion of the stored UE context, the target gNB retrieves the UE context from RAN DB using the context key. In some example embodiments, this context key may be obtained on the network side based on the UE persistent identifier which is returned by the UE in the RRC Connection Request. As mentioned before, the UE persistent ID and the UE context key are either the same or are mapped to each other at the network side.

16. In response, RAN DB sends UE context to target gNB. Since the UE context stored in the RAN DB comprises at least some session-unrelated information such as UE historical information, the same is available for the new sessions, even if the target gNB is different from the source gNB. Besides, if the UE context stored in RAN DB while the UE was in CM-IDLE comprises session-related data, too, these may be used in the RRC Connection setup. The target gNB may create the UE context using at least a part of the data retrieved from RAN DB.

17. Target gNB sends RRC connection setup and provides the created context or a part of it to the UE. Thus, UE is in CM-CONNECTED state.

18. The context key may also be shared with the selected AMF along with the Initial UE message

19. AMF decides on the key to retrieve the UE context from RAN DB. AMF may also use the key received from target gNB,, or the AMF may have an internal mapping between the RAN UE context key and its own, if it used a different key than the RAN.

20. AMF retrieves the UE context using the appropriate context key.

21. In response, RAN DB provides the UE context to AMF. Thus, AMF may create a UE context using the UE context stored at RAN DB, too.

Actions 22 to 25 correspond to actions 10 to 13 of PART-1, wherein the source gNB is replaced by the target gNB.

According to some example embodiments, keeping the UE persistent ID across the state transitions, particularly when the UE transitions from the Connected state to Idle state, provides the target access node, e.g., target gNB, to which the UE performs a new connection establishment, with the capability of retrieving the UE context from the RAN DB. Such UE persistent ID can be unique RAN-wide. In some example embodiments, the UE persistent ID can be unique in the registration area (RA) of the UE.

The information stored in the UE context of the RAN DB is available for use at the target gNB and serving AMF. Here particularly the UE context information related the UE intelligence can be utilized for further UE-related optimizations. Such intelligence information can be utilized by AI/ML algorithms or data analytics functions in the 5GS. The historical intelligence can be considered as kind of semi-static information like UE mobility history information, UE power related data/inference, intelligence built based on U E/network reporting/monitoring, n/w algorithm information applicable to the UE etc. The UE historical intelligence is assumed to be built over a longer period of time and maybe used by the network whenever the UE enters CONNECTED mode. In some example embodiments, the UE context storage in the RAN DB may be done only once, after execution of the initial access procedure.

Fig. 2 shows a case where the gNBs are split in CU and DU. In this case, the respective actions are performed by CU-CP. In other example embodiments, the respective actions may be performed by the (unsplit, i.e., aggregated) gNB. Moreover, within SB-RAN architecture, the shown entities herein can be in any form that consequently realizes service-based architecture principles. Similarly, the communication among these entities can be performed over interfaces via any communication technology that enables service-based communication. For example, the shown entities can be in the form of (but not limited to) NFs or microservices and the shown procedures can be performed via SBI. Furthermore, for example HTTP(S) can be used for the communications between the network elements/network functions/microservices. Accordingly, the shown information elements can be communicated via HTTP Request and Response messages, e.g., HTTP POST, HTTP GET, HTTP PUT, HTTP PATCH Request messages and the associated HTTP Response messages. Microservices could be understood as more modular services (as compared with services produced/provided by NFs) that come together to provide a meaningful service/application. In this scope, one can deploy and scale the small modules flexibly (e.g. within a NF or between various NFs). For example, an NF can provide one or more services, and a microservice can represent small modules that make up the services in the NF. Moreover, microservices can communicate with each other, e.g., statelessly.

In some example embodiments, the UE context key maybe IMSI, which is accessible only to AMF (NAS message), but not to NG-RAN node.

In such a scenario, the UE context maybe stored in the RAN DB for the first time by AMF and the context key shared with the NG-RAN node over NG interface. The NG-RAN node may use the same context key or one of its own.

This implies that, in a subsequent UE state transition from CM-IDLE to CM- CONNECTED, the NG-RAN node may be able to retrieve the UE context key for a given UE only after AMF identifies the UE based on NG: Initial UE message, and sends back the context key to the NG-RAN node in a response message thereto. This scenario is also applicable to other context keys which are accessible only to AMF (NAS message), but not to NG-RAN node.

According to some example embodiments of the invention, the RAN DB has an architecture to ensure that UE Context retrieval can be performed from anywhere within the RAN, or at least from large parts of the RAN. As stated before, (Local) RAN DBs are typically shared between sets of gNBs and AMFs which have the same coverage or geographical area (“registration area”). The Local RAN DB is used to store the relevant UE Context information (as explained in the previous sections). In some example embodiments, there is a hierarchy architecture for RAN DBs in order to address the problem of the coverage limitation of Local RAN DB. As Fig. 3 illustrates, some (or even all) Local RAN DBs may be connected to a Global DB registration entity, called hereafter Global DB. Global DB is a registry for all the UE Context information and their respective RAN DB ID. The RAN DB ID indicates the Local RAN DB where the UE context is stored, i.e. the location of that information. In case UE changes its status from CM-IDLE to CM- CONNECTED and requests connection, but not in a gNB or AMF connected to its previous Local RAN DB, then Global DB can help to locate the Local RAN DB containing the UE Context information.

In some example embodiments, there are 3 potential scenarios, whereof scenario 2 illustrated in Fig. 3. In any case, the previous local RAN DB informs the Global DB (1. in Fig. 3) on the context key for which it has stored the UE context (at least the historical intelligence information):

1. UE changes its status from CM-IDLE to CM-CONNECTED in the same registration area in which it was CM-CONNECTED before. In this case, the target gNB and the serving AMF can easily fetch the relative information from the local RAN DB by having the correct UE context key. This scenario does not need a Global DB involvement.

2. If UE requests the connection in a new registration area, then the target gNB and the new serving AMF cannot locate the UE context (including UE Historical Intelligence information) in the Local RAN DB. In this case, Local RAN DB queries (2. in Fig. 3) the Global DB for the exact location of the UE context (including Historical Intelligence information) (the location of the RAN DB which was previously serving the UE). Global DB searches its database based on the UE identification for a match. If the search is successful, then Global DB requests the previous local RAN DB (3. in Fig. 3) to send over the UE context (at least the UE Historical Intelligence information) to the new local RAN DB, or instructs the new Local RAN DB (from which the Global DB received the query) to request a transfer of the UE context (at least the UE Historical Intelligence information) from the previous local RAN DB (not shown in Fig. 3). Then, the previous local RAN DB transfers the UE context (at least the UE Historical Intelligence information) to the new local RAN DB (4. in Fig. 3). Obviously, the transfer is feasible due to the current UE status (CM-IDLE). Typically, the transition from CM-IDLE to CM- CONNECTED state is not delay-critical because the UE is still in the CM-IDLE state and user plane information is not transmitted to or from the UE. After the successful transfer, Global DB updates its registry with the new location of the UE Historical Intelligence information.

3. In the last scenario, neither the new local RAN DB nor Global DB can locate the UE context (incl. UE Historical Intelligence information). This may happen e.g. if UE connects to network for the first time. In this case, the target gNB and the serving AMF undergo the standard procedures to register the UE in the Core Network.

Fig. 4 shows an apparatus according to an example embodiment of the invention. The apparatus may be a connection management function, such as a gNB or eNB, or a registration management function, such as a AMF, or an element thereof. Fig. 5 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 4 may perform the method of Fig. 5 but is not limited to this method. The method of Fig. 5 may be performed by the apparatus of Fig. 4 but is not limited to being performed by this apparatus.

The apparatus comprises means for storing 10, means for monitoring 20, and means for maintaining 30. The means for storing 10, means for monitoring 20, and means for maintaining 30 may be a storing means, monitoring means, and maintaining means, respectively. The means for storing 10, means for monitoring 20, and means for maintaining 30 may be a storage device, monitor, and maintainer, respectively. The means for storing 10, means for monitoring 20, and means for maintaining 30 may be a storing processor, monitoring processor, and maintaining processor, respectively. The means for storing 10 stores a context for the terminal (“terminal context” or “UE context”) into a database (S10). The context comprises a session-related portion and a session-unrelated portion different from the session-related portion. The context is stored into the database while the terminal is in the connected state or (latest) when the terminal transits from the connected state into the idle state.

The means for monitoring 20 monitors if a terminal transits from a connected state into an idle state (S20). The connected state is a state of a connection management for the terminal. The idle state is another state of the connection management for the terminal. The context is related to the terminal in the connected state. A context is typically not related to the terminal in the idle state.

The means for maintaining 30 maintains at least a part of the session-unrelated portion of the context for the terminal in the database if the terminal transits from the connected state into the idle state (S30). I.e., the database is inhibited to remove at least the session-unrelated portion of the context in the idle state after the transition from the connected state. For example, the means for maintaining 30 may inhibit that the database gets informed on the state transition to the idle state, or the means for maintaining 30 may inhibit to request removing at least the session-unrelated portion of the context from the database.

Fig. 6 shows an apparatus according to an example embodiment of the invention. The apparatus may be a connection management function, such as a gNB or eNB, or a registration management function, such as an AMF, or an element thereof. Fig. 7 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 6 may perform the method of Fig. 7 but is not limited to this method. The method of Fig. 7 may be performed by the apparatus of Fig. 6 but is not limited to being performed by this apparatus.

The apparatus comprises means for supervising 110, means for retrieving 120, and means for applying 130. The means for supervising 110, means for retrieving 120, and means for applying 130 may be a supervising means, retrieving means, and applying means, respectively. The means for supervising 110, means for retrieving 120, and means for applying 130 may be a supervisor, retriever, and applicator, respectively. The means for supervising 110, means for retrieving 120, and means for applying 130 may be a supervising processor, retrieving processor, and applying processor, respectively.

The means for supervising 110 supervises if a terminal transits from an idle state into a connected state (S110). The connected state is a state of a connection management for the terminal. The idle state is another state of the connection management for the terminal.

If the terminal transits from the idle state into the connected state (S110 = yes), the means for retrieving 120 retrieves at least a part of a session-unrelated portion of a context for the terminal (“terminal context” or “UE context”) from a database (S120). The context is to be related to the terminal in the connected state. The context comprises a session-related portion and a session-unrelated portion different from the session- related portion. A context is typically not related to the terminal in the idle state.

If the terminal transits from the idle state into the connected state (S110 = yes), the means for applying 130 applies the retrieved session-unrelated portion of the context to the connected state of the terminal (S130).

Fig. 8 shows an apparatus according to an example embodiment of the invention. The apparatus may be a database such as a (local) RAN DB, or an element thereof. Fig. 9 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 8 may perform the method of Fig. 9 but is not limited to this method. The method of Fig. 9 may be performed by the apparatus of Fig. 8 but is not limited to being performed by this apparatus.

The apparatus comprises means for storing 210, means for receiving 220, and means for providing 230. The means for storing 210, means for receiving 220, and means for providing 230 may be a storing means, receiving means, and providing means, respectively. The means for storing 210, means for receiving 220, and means for providing 230 may be a storage device, receiver, and provider, respectively. The means for storing 210, means for receiving 220, and means for providing 230 may be a storing processor, receiving processor, and providing processor, respectively. The means for storing 210 stores a context for a terminal (“terminal context” or “UE context”) in a first database (S210). The context is received from a first instance of a network function (such as a connection management function (e.g. gNB, eNB) or registration management function (e.g. AMF). The context is related to the terminal in a connected state. The context comprises a session-related portion and a session- unrelated portion different from the session-related portion. A context is typically not related to the terminal in the idle state.

The means for receiving 220 receives a first request from a second instance of the network function (S220). The request requests to provide at least a part of the session- unrelated portion of the context for the terminal. The first instance of the network function may be different from or the same as the second instance of the network function.

The means for providing 230 provides at least the part of the session-unrelated portion of the context for the terminal to the second instance (S230) in response to receiving the first request.

Fig. 10 shows an apparatus according to an example embodiment of the invention. The apparatus may be a database such as a (local) RAN DB, or an element thereof. Fig. 11 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 10 may perform the method of Fig. 11 but is not limited to this method. The method of Fig. 11 may be performed by the apparatus of Fig. 10 but is not limited to being performed by this apparatus.

The apparatus comprises means for supervising 310, means for checking 320, means for querying 330, and means for receiving 340. The means for supervising 310, means for checking 320, means for querying 330, and means for receiving 340 may be a supervising means, checking means, querying means, and receiving means, respectively. The means for supervising 310, means for checking 320, means for querying 330, and means for receiving 340 may be a supervisor, checker, questor, and receiver, respectively. The means for supervising 310, means for checking 320, means for querying 330, and means for receiving 340 may be a supervising processor, checking processor, querying processor, and receiving processor, respectively. The means for supervising 310 supervises if a first database receives a request to provide at least a part of a session-unrelated portion of a context for a terminal (“terminal context” or “UE context”) (S310). The context is related to the terminal in a connected state. The context comprises a session-related portion and the session-unrelated portion different from the session-related portion. A context is typically not related to the terminal in the idle state.

If the first database receives the request (S310 = yes), the means for checking 320 checks if the first database stores at least the part of the session-unrelated portion of the context for the terminal (S320).

If the first database does not store at least the part of the session-unrelated portion of the context for the terminal (S320 = no), the means for querying 330 queries a global database for an identification of a second database (S330). According to the global database, the second database stores at least the part of the session-unrelated portion of the context for the terminal.

The means for receiving 340 receives at least the part of the session-unrelated portion of the context for the terminal from the second database (S340). It may then store at least the part of the session-unrelated portion of the context into the first database, and provide at least the part of the session-unrelated portion in response to the request of S310.

Fig. 12 shows an apparatus according to an example embodiment of the invention. The apparatus may be a database such as a global DB, or an element thereof. Fig. 13 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 12 may perform the method of Fig. 13 but is not limited to this method. The method of Fig. 13 may be performed by the apparatus of Fig. 12 but is not limited to being performed by this apparatus.

The apparatus comprises means for monitoring 410 and means for causing 420. The means for monitoring 410 and means for causing 420 may be a monitoring means and causing means, respectively. The means for monitoring 410 and means for causing 420 may be a monitor and causer, respectively. The means for monitoring 410 and means for causing 420 may be a monitoring processor and causing processor, respectively. The means for monitoring 410 monitors if a query for an identification of a second database is received from a first database (S410). According to a relationship stored in a global database, the second database stores at least a part of a session-unrelated portion of a context for a terminal (“terminal context” or “UE context”). The context is related to the terminal in a connected state. The context comprises a session-related portion and the session-unrelated portion different from the session-related portion. A context is typically not related to the terminal in the idle state.

If the query is received from the first database (S410 = yes), the means for causing 420 causes a transfer of at least the part of the session-unrelated portion of the context for the terminal from the second database to the first database (S420). For that purpose, the means for causing may trigger the second database to provide at least the part of the session-unrelated portion of the context to the first database, or trigger the first database to request at least the part of the session-unrelated portion of the context from the second database.

Fig. 14 shows an apparatus according to an example embodiment of the invention. The apparatus may be a terminal such as a UE, 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. 14 may be performed by the apparatus of Fig. 14 but is not limited to being performed by this apparatus.

The apparatus comprises means for supervising 510, means for instructing 520, means for monitoring 530, and means for providing 540. The means for supervising 510, means for instructing 520, means for monitoring 530, and means for providing 540 may be a supervising means, instructing means, monitoring means, and providing means, respectively. The means for supervising 510, means for instructing 520, means for monitoring 530, and means for providing 540 may be a supervisor, instructor, monitor, and provider, respectively. The means for supervising 510, means for instructing 520, means for monitoring 530, and means for providing 540 may be a supervising processor, instructing processor, monitoring processor, and providing processor, respectively. The means for supervising 510 supervises if a terminal in a connected state receives an identifier from a network function (S510). In the connected state, a terminal context (UE context) is related to the terminal in a connected state. The identifier is related to the terminal context. I.e., the identifier may be a context key of the terminal context.

If the terminal receives the identifier (S510 = yes), the means for instructing 520 instructs the terminal to store the identifier (S520).

The means for monitoring 530 monitors if the terminal decides to send a connection request to transit from an idle state to the connected state (S530). In some example embodiments, the means for monitoring 530 monitors only if the means for instructing 520 instructed the terminal to store the identifier previously, i.e., if the UE decides to transit at least for the second time into connected state. Each of the connected state and the idle state is a respective state of a connection management for the terminal. The terminal may decide to send the connection request for a mobile originated traffic or a mobile terminated traffic (after being paged).

If the terminal sends the connection request (S530 = yes), the means for providing 540 provides the identifier to the network function (S540). For example, the terminal may provide the identifier in the connection request, or it may provide the identifier in a separate message. The separate message may precede or follow the connection request,

Fig. 16 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 one of the methods according to Figs. 5, 7, 9, 11, 13, and 15 and related description.

Some example embodiments of this invention are particularly useful in a 5G network. However, the invention is not limited to 5G. It may be used in other networks, too, e.g. in former or forthcoming generations of 3GPP networks such as 4G, 6G, 7G, etc. It may be used in any wireless (mobile) and wireline communication networks, where a UE context may comprise both session-related context data and other context data that are not related to the session. The other context data may be named e.g. session- unrelated context data, or general context data, or semi-static context data.

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.

In particular, AMF serves as a function to which all UEs which are currently served must be registered. In other networks than 5G networks, this role may have a different name. E.g., in this aspect, the AMF corresponds to a MME of LTE or a MSC of GSM. Apart from Registration Management, AMF may be responsible for Connection Management, Reachability Management, Mobility Management and/or various functions relating to security and access management and authorization for the slice.

Some example embodiments are described with a gNB as an access node. gNB is an access node of a 5G RAN. However, example embodiments are not restricted to 5G RAN. E.g. in a 4G RAN, eNB may take the role of the access node. Example embodiments are not even restricted to 3GPP networks. For example, in WiFi networks, AP may take the role of the access node.

The terminal may correspond to the technology of the access node. E.g. the terminal may be a UE. It may be a MTC device, etc. Correspondingly, a UE context may be named terminal context instead.

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 network function involved in configuration management and/or registration management of a UE, such as an access management function and/or node of an access network (e.g. RAN) such as a gNB, eNB, etc., 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 database such as a AN DB (e.g. a RAN DB), 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 embodiments of the present invention. However, it should be noted that the description of the preferred 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

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: monitoring if a terminal transits from a connected state into an idle state, wherein a terminal context is related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; storing the terminal context for the terminal into a database while the terminal is in the connected state or when the terminal transits from the connected state into the idle state; maintaining at least a part of the session-unrelated portion of the terminal context for the terminal in the database if the terminal transits from the connected state into the idle state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

2. The apparatus according to claim 1, wherein the maintaining at least the part of the session-unrelated portion of the terminal context for the terminal from the database comprises inhibiting to inform the database that the terminal transits from the connected state into the idle state.

3. The apparatus according to claim 1, wherein the maintaining at least the part of the session-unrelated portion of the terminal context for the terminal from the database comprises instructing the database to keep the session-unrelated portion of the terminal context.

4. The apparatus according to any of claims 1 to 3, wherein the supervising if the terminal transits from the idle state into the connected state is based on a first identifier of the terminal; and the instructions, when executed by the one or more processors, further cause the apparatus to perform: mapping the first identifier to a second identifier of the terminal based on a mapping relationship if the terminal transits from the idle state into the connected state; wherein the terminal context for the terminal is stored into the database based on the second identifier.

5. The apparatus according to claim 4, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform generating a third identifier of the terminal; informing the terminal on the third identifier; wherein either

• the third identifier is the same as the second identifier; or

• the third identifier is different from the second identifier and the instructions, when executed by the one or more processors, further cause the apparatus to perform storing a mapping relationship between the second identifier and the third 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: supervising if the terminal transits from the idle state into the connected state after the terminal transited from the connected state into the idle state; retrieving at least the part of the session-unrelated portion of the terminal context for the terminal from the database if the terminal transits from the idle state into the connected state after the terminal transited from the connected state into the idle state; applying the retrieved at least part of the session-unrelated portion of the terminal context to the connected state of the terminal after the terminal transited from the idle state into the connected state.

7. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: supervising if a terminal transits from an idle state into a connected state, wherein a terminal context is to be related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; retrieving at least a part of the session-unrelated portion of the terminal context for the terminal from a database if the terminal transits from the idle state into the connected state; applying the retrieved at least part of the session-unrelated portion of the terminal context to the connected state of the terminal if the terminal transits from the idle state into the connected state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

8. The apparatus according to claim 7, wherein the supervising if the terminal transits from the idle state into the connected state is based on a first identifier of the terminal; and the instructions, when executed by the one or more processors, further cause the apparatus to perform: mapping the first identifier to a second identifier of the terminal based on a mapping relationship; wherein at least the session-unrelated portion of the terminal context for the terminal is retrieved from the database based on the second identifier.

9. The apparatus according to claim 8, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: receiving a third identifier from the terminal if the terminal transits from the idle state into the connected state; mapping the third identifier to the second identifier based on a stored mapping relationship.

10. The apparatus according to any of claims 1 to 9, wherein the terminal context is stored into the database and retrieved from the database using an identifier of the terminal; and the identifier of the terminal is one of a global unique temporary identifier, a temporary mobile subscription identity, an international mobile station equipment identity, a network allocated identifier, or an identifier derived from one of these identifiers, wherein, if the claim is dependent on one of claims 5 and 8, the identifier of the terminal is the second identifier.

11. The apparatus according to claim 10, wherein the network allocated identifier comprises at least an identifier of the access management function of the network serving the terminal equipment and an identifier of the terminal assigned by the access management function.

12. System, comprising a first apparatus according to any of claims 1 to 5; a second apparatus according to any of claims 7 to 11; the terminal monitored by the first apparatus; the database into which the first apparatus stores the terminal context; wherein the terminal monitored by the first apparatus is the same as the terminal supervised by the second apparatus; the database into which the first apparatus stores the terminal context is the same as the database, from which the second apparatus retrieves at least a part of the session- unrelated portion of the terminal context; the terminal context stored by the first apparatus is the same as the terminal context of which at least a part of the session-unrelated portion is retrieved by the second apparatus; when the terminal stores the terminal context, the terminal is in the connected state connected to a first base station; when the terminal retrieves at least a part of the session-unrelated portion of the terminal context, the terminal is in the connected state connected to a second base station different from the first base station.

13. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: storing a terminal context associated with a context key for a terminal in a first database, wherein the terminal context is received from a first instance of a network function, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; receiving a first request from a second instance of the network function, including a context key, to provide at least a part of the session-unrelated portion of the terminal context for the terminal; providing at least the part of the session-unrelated portion of the terminal context for the terminal, associated with the context key, to the second instance of the network function in response to receiving the first request.

14. The apparatus according to claim 13, wherein the first instance of the network function is different from the second instance of the network function, or the first instance of the network function is the same as the second instance of the network function.

15. The apparatus according to any of claims 13 and 14, wherein the network function is one of a base station function or a core network function.

16. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: supervising if a first database receives a request to provide at least a part of a session-unrelated portion of a terminal context associated with a given context key for a terminal, wherein the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; checking, based on the given context key, if the first database stores at least the part of the session-unrelated portion of the terminal context for the terminal if the first database receives the request; querying a global database, based on the given context key, for an identification of a second database storing at least the part of the session-unrelated portion of the terminal context for the terminal if the first database does not store at least the part of the session-unrelated portion of the terminal context for the terminal; receiving at least the part of the session-unrelated portion of the terminal context for the terminal from the second database.

17. The apparatus according to claim 16, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: receiving the identification of the second database from the global database in response to the querying; causing the second database to provide at least the session-unrelated portion of the terminal context for the terminal; wherein the terminal context for the terminal is received in response to the causing.

18. 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 if a query for an identification of a second database is received from a first database based on at least a context key or a cell id, wherein the second database stores at least a part of a session-unrelated portion of a terminal context for a terminal, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; causing a transfer of at least the part of the session-unrelated portion of the terminal context for the terminal from the second database to the first database if the query is received from the first database.

19. The apparatus according to claim 18, wherein at least one of the causing comprises requesting the second database to transfer at least the part of the session-unrelated portion of the terminal context for the terminal to the first database; and the causing comprises instructing the first database to request the second database to transfer at least the part of the session-unrelated portion of the terminal context to the first database.

20. The apparatus according to any of claims 1 to 19, wherein the session-unrelated portion of the terminal context comprises a historical intelligence.

21. Apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: supervising if a terminal in a connected state receives an identifier from a network function, wherein a terminal context is related to the terminal in the connected state, and the identifier is related to the terminal context; instructing the terminal to store the identifier if the terminal receives the identifier; monitoring if the terminal decides to send a connection request to transit from an idle state to the connected state; providing the identifier to the network function if the terminal sends the connection request; each of the connected state and the idle state is a respective state of a connection management for the terminal.

22. Method comprising: monitoring if a terminal transits from a connected state into an idle state, wherein a terminal context is related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; storing the terminal context for the terminal into a database while the terminal is in the connected state or when the terminal transits from the connected state into the idle state; maintaining at least a part of the session-unrelated portion of the terminal context for the terminal in the database if the terminal transits from the connected state into the idle state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

23. The method according to claim 22, wherein the maintaining at least the part of the session-unrelated portion of the terminal context for the terminal from the database comprises inhibiting to inform the database that the terminal transits from the connected state into the idle state.

24. The method according to claim 22, wherein the maintaining at least the part of the session-unrelated portion of the terminal context for the terminal from the database comprises instructing the database to keep the session-unrelated portion of the terminal context.

25. The method according to any of claims 22 to 24, wherein the supervising if the terminal transits from the idle state into the connected state is based on a first identifier of the terminal; and the method further comprises: mapping the first identifier to a second identifier of the terminal based on a mapping relationship if the terminal transits from the idle state into the connected state; wherein the terminal context for the terminal is stored into the database based on the second identifier.

26. The method according to claim 25, further comprising generating a third identifier of the terminal; informing the terminal on the third identifier; wherein either

• the third identifier is the same as the second identifier; or

• the third identifier is different from the second identifier and the method comprises storing a mapping relationship between the second identifier and the third identifier.

27. The method according to any of claims 22 to 26, further comprising: supervising if the terminal transits from the idle state into the connected state after the terminal transited from the connected state into the idle state; retrieving at least the part of the session-unrelated portion of the terminal context for the terminal from the database if the terminal transits from the idle state into the connected state after the terminal transited from the connected state into the idle state; applying the retrieved at least part of the session-unrelated portion of the terminal context to the connected state of the terminal after the terminal transited from the idle state into the connected state.

28. Method comprising: supervising if a terminal transits from an idle state into a connected state, wherein a terminal context is to be related to the terminal in the connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; retrieving at least a part of the session-unrelated portion of the terminal context for the terminal from a database if the terminal transits from the idle state into the connected state; applying the retrieved at least part of the session-unrelated portion of the terminal context to the connected state of the terminal if the terminal transits from the idle state into the connected state; wherein each of the connected state and the idle state is a respective state of a connection management for the terminal.

29. The method according to claim 28, wherein the supervising if the terminal transits from the idle state into the connected state is based on a first identifier of the terminal; and the method further comprises: mapping the first identifier to a second identifier of the terminal based on a mapping relationship; wherein at least the session-unrelated portion of the terminal context for the terminal is retrieved from the database based on the second identifier.

30. The method according to claim 29, further comprising: receiving a third identifier from the terminal if the terminal transits from the idle state into the connected state; mapping the third identifier to the second identifier based on a stored mapping relationship.

31. The method according to any of claims 22 to 30, wherein the terminal context is stored into the database and retrieved from the database using an identifier of the terminal; and the identifier of the terminal is one of a global unique temporary identifier, a temporary mobile subscription identity, an international mobile station equipment identity, a network allocated identifier, or an identifier derived from one of these identifiers, wherein, if the claim is dependent on one of claims 26 and 29, the identifier of the terminal is the second identifier.

32. The method according to claim 31 , wherein the network allocated identifier comprises at least an identifier of the access management function of the network serving the terminal equipment and an identifier of the terminal assigned by the access management function.

33. Method comprising: storing a terminal context associated with a context key for a terminal in a first database, wherein the terminal context is received from a first instance of a network function, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and a session-unrelated portion different from the session-related portion; receiving a first request from a second instance of the network function, including a context key, to provide at least a part of the session-unrelated portion of the terminal context for the terminal; providing at least the part of the session-unrelated portion of the terminal context for the terminal, associated with the context key, to the second instance of the network function in response to receiving the first request.

34. The method according to claim 33, wherein the first instance of the network function is different from the second instance of the network function, or the first instance of the network function is the same as the second instance of the network function.

35. The method according to any of claims 33 and 34, wherein the network function is one of a base station function or an core network function.

36. Method comprising: supervising if a first database receives a request to provide at least a part of a session-unrelated portion of a terminal context associated with a given context key for a terminal, wherein the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; checking, based on the given context key, if the first database stores at least the part of the session-unrelated portion of the terminal context for the terminal if the first database receives the request; querying a global database, based on the given context key, for an identification of a second database storing at least the part of the session-unrelated portion of the terminal context for the terminal if the first database does not store at least the part of the session-unrelated portion of the terminal context for the terminal; receiving at least the part of the session-unrelated portion of the terminal context for the terminal from the second database.

37. The method according to claim 36, further comprising: receiving the identification of the second database from the global database in response to the querying; causing the second database to provide at least the session-unrelated portion of the terminal context for the terminal; wherein the terminal context for the terminal is received in response to the causing.

38. Method comprising: monitoring if a query for an identification of a second database is received from a first database based on at least a context key or a cell id, wherein the second database stores at least a part of a session-unrelated portion of a terminal context for a terminal, the terminal context is related to the terminal in a connected state, and the terminal context comprises a session-related portion and the session-unrelated portion different from the session-related portion; causing a transfer of at least the part of the session-unrelated portion of the terminal context for the terminal from the second database to the first database if the query is received from the first database.

39. The method according to claim 38, wherein at least one of the causing comprises requesting the second database to transfer at least the part of the session-unrelated portion of the terminal context for the terminal to the first database; and the causing comprises instructing the first database to request the second database to transfer at least the part of the session-unrelated portion of the terminal context to the first database.

40. The method according to any of claims 22 to 39, wherein the session-unrelated portion of the terminal context comprises a historical intelligence.

41. Method comprising: supervising if a terminal in a connected state receives an identifier from a network function, wherein a terminal context is related to the terminal in the connected state, and the identifier is related to the terminal context; instructing the terminal to store the identifier if the terminal receives the identifier; monitoring if the terminal decides to send a connection request to transit from an idle state to the connected state; providing the identifier to the network function if the terminal sends the connection request; each of the connected state and the idle state is a respective state of a connection management for the terminal.

42. 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 22 to 41.

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