Patent Description:
In a communication network, registration data related to a specific UE (user equipment) may be retrieved by various network function entities such as network data analytics function (NWDAF), home subscriber server (HSS), etc..

For example, data collection from network functions (NFs) may be used by NWDAF to subscribe/unsubscribe at any NF to be notified for data on a set of events. The data collection from NFs may be based on the services of the NFs such as AMF (Access and mobility management Function), SMF (Session Management Function), UDM (Unified Data Management), PCF (Policy Control Function), NRF (NF Repository Function) and AF (Application Function) (possibly via NEF (Network Exposure Function)). This data collection service may be used directly in order to retrieve behaviour data for individual UEs or groups of UEs (e.g. UE reachability), and also to retrieve global UE information (e.g. Number of UEs present in a geographical area). Table <NUM> shows services consumed by NWDAF for data collection.

To retrieve data related to a specific UE, the NWDAF shall first determine which NF instances are serving this UE as stated in Table <NUM> unless the NWDAF has already obtained this information due to recent operations related to this UE.

The AMF, SMF instances may be determined using a request to UDM providing the SUPI (subscription permanent identifier) or the group identity. To determine the SMF serving a PDU (protocol data unit) session, the NWDAF may in addition provide the DNN (data network name) and S-NSSAI (single network slice selection assistance information) of this PDU Session; otherwise the NWDAF will obtain a list of possibly multiple SMFs (e.g. one per PDU session).

<FIG> shows an interaction when SMS-GMSC (Short Message Service-Gateway Mobile Switch Center) retrieves routing information from the HSS for MT-SMS (mobile terminated - short message service) delivery.

At step <NUM>, the HSS receives a request for routing information from the SMS-GMSC via MAP (Mobile Application Part) or S6c.

At step <NUM>, the HSS queries the EPS-UDR via Ud to read the registered MME(Mobile Management Entity)/MSC(Mobile Switching Centre), the registered SGSN(Serving GPRS(General Packet Radio Service) Support Node), the UE-not-reachable flags for MME/MSC, SGSN, 3GppSMSF (3GPP Short Message Service Function) and Non3GppSMSF and the SMSF Registration Notification flag.

At step <NUM>, if the UE-not-reachable flags for 3GppSMSF, Non3GppSMSF and SMSF Registration Notification flag are not set and unless the user is known not to be registered in 5GC (fifth generation core network), the HSS retrieves the registered SMSF addresses (if any) from the UDM.

At steps <NUM>-<NUM>, the UDM retrieves the requested information from the 5GS-UDR (fifth generation system- unified date repository).

At step <NUM>, the UDM forwards the retrieved addresses to the HSS if any.

At step <NUM>, the HSS returns the relevant MT-SMS target node addresses registered in HSS and/or UDM to the SMS-GMSC and the procedure is terminated.

Otherwise, if there is no MT-SMS target node address registered in HSS nor in UDM, a negative response (Absent Subscriber SM) is sent to the SMS-GMSC and the procedure continues with steps <NUM> to <NUM>.

At step <NUM>, the HSS includes the SMSC address to the Message Waiting Data (MWD) stored in the EPS-UDR (evolved packet system-UDR) and informs the SMSC as defined in 3GPP TS <NUM> V15. The relevant UE-not-reachable flags and the SMSF Registration Notification flag are set in the EPS-UDR.

At step <NUM>, the HSS subscribes in UDM to be notified when the UE registers in the 5GC for SMS service (i.e. when an SMSF is registered in UDM) by using the Nudm_EE_Subscribe service operation (SUPI, SMSF Registration Notification event) as defined in 3GPP TS <NUM> V16.

In this case, the HSS subscribes to SMSF Registration Notification event in UDM instead to the UE Reachability Notification as even if the UE is reachable in an AMF, the UE will not be ready for SMS within the 5GC until an SMSF is registered for the UE in UDM.

At step <NUM>, the UDM stores the SMSF Registration Notification flag in the 5GS-UDR.

At step <NUM>, the UDM acknowledges the subscription to the HSS.

The messages as shown in <FIG> are same as the corresponding messages as described in 3GPP TS <NUM> V16.

<FIG> shows UDM UECM (UE Context Management) Resources, which is a copy of Figure <NUM>. <NUM>-<NUM> of 3GPP <NUM> V16.

Table <NUM> provides an overview of the resources and applicable HTTP (hyper text transfer protocol) methods, which is a copy of Table <NUM>. <NUM>-<NUM> of 3GPP <NUM> V16.

<CIT> discloses a service request processing method. The method comprises receiving a service request sent by a service consumer, wherein the service request comprises a plurality of service producer types.

As described above, to retrieve data related to a specific UE, the NWDAF shall first determine which NF instances are serving this UE as in Table <NUM>:.

To retrieve the SMS serving nodes related to a specific UE, the HSS shall check UDM for the serving SMSF addresses:.

However UDM only provides UECM service to get one serving node one time, which may result in some problems. For example, retrieving multiple registration data sets (e.g., serving NF instances) with a single GET request is not possible. It is inefficient to support different use cases based on multiple registration data sets, for examples:.

To overcome or mitigate at least one above mentioned problems or other problems, the embodiments of the present disclosure propose an improved registration data retrieval solution. Aspects of the invention are set out in the independent claims appended hereto.

In an embodiment, for a data management entity such as UDM, a new GET method to resource {ueld}/registrations is added as generic registration data sets retrieval method to enable the possibility to retrieve multiple registration data sets with a single GET request.

In an embodiment, for a data repository entity such as UDR, the GET method for the multiple context data sets retrieval is updated to enable the possibility to retrieve multiple context data sets together with the sessions context data (such as SMF PDU sessions context data) with a single GET request.

Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, for data management entity such as UDM, a new GET method on resource {ueld}/registrations is introduced as generic registration data sets retrieval method to enable the possibility to retrieve multiple registration data sets with a single GET request. So use cases which have been identified that benefit from retrieving multiple registration data sets with a single GET request are supported by the proposed method provided by the data management entity. In some embodiments herein, for data repository entity such as UDR, the GET method for the multiple context data sets retrieval is updated to enable the possibility to retrieve multiple context data sets together with the sessions context data (such as SMF PDU sessions context data) with a single GET request. So use cases which have been identified that benefit from retrieving multiple registration data sets including the session context data with a single GET request are supported by the proposed method provided by the data repository entity. In some embodiments herein, unnecessary signaling traffic are avoided and the network efficiency are improved from operation point of view, which means OPEX (operating expenses) reduction. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

As used herein, the term "network" or "communication network" refers to a network following any suitable (wireless or wired) communication standards. For example, the wireless communication standards may comprise new radio (NR), long term evolution (LTE), LTE-Advanced, wideband code division multiple access (WCDMA), high-speed packet access (HSPA), Code Division Multiple Access (CDMA), Time Division Multiple Address (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency-Division Multiple Access (OFDMA), Single carrier frequency division multiple access (SC-FDMA) and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), etc. UTRA includes WCDMA and other variants of CDMA. An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE <NUM> (Wi-Fi), IEEE <NUM> (WiMAX), IEEE <NUM>, Flash-OFDMA, Ad-hoc network, wireless sensor network, etc. In the following description, the terms "network" and "system" can be used interchangeably. Furthermore, the communications between two devices in the network may be performed according to any suitable communication protocols, including, but not limited to, the wireless communication protocols as defined by a standard organization such as 3rd generation partnership project (3GPP) or the wired communication protocols. For example, the wireless communication protocols may comprise the first generation (<NUM>), <NUM>, <NUM>, <NUM>, <NUM>, <NUM> communication protocols, and/or any other protocols either currently known or to be developed in the future.

The term "entity" used herein refers to a network device or network node or network function in a communication network. For example, in a wireless communication network such as a 3GPP-type cellular network, a core network device may offer numerous services to customers who are interconnected by an access network device. Each access network device is connectable to the core network device over a wired or wireless connection.

The term "network function (NF)" refers to any suitable function which can be implemented in a network entity (physical or virtual) of a communication network. For example, the <NUM> system (5GS) may comprise a plurality of NFs such as AMF (Access and mobility Function), SMF (Session Management Function), AUSF (Authentication Service Function), UDM (Unified Data Management), PCF (Policy Control Function), AF (Application Function), NEF (Network Exposure Function), UPF (User plane Function) and NRF (Network Repository Function), RAN (radio access network), SCP (service communication proxy), NWDAF (network data analytics function), etc. In other embodiments, the network function may comprise different types of NFs (such as HSS, SMS-GMSC, EPS-UDR, etc.) for example depending on the specific network.

The term "terminal device" refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE), or other suitable devices. The UE may be, for example, a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and a playback appliance, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA), a portable computer, a desktop computer, a wearable terminal device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a USB dongle, a smart device, a wireless customer-premises equipment (CPE) and the like. In the following description, the terms "terminal device", "terminal", "user equipment" and "UE" may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3GPP, such as 3GPP' LTE standard or NR standard. As used herein, a "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and/or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and/or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

As yet another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another terminal device and/or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the terminal device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

As used herein, the phrase "at least one of A and B" should be understood to mean "only A, only B, or both A and B. " The phrase "A and/or B" should be understood to mean "only A, only B, or both A and B.

It is noted that these terms as used in this document are used only for ease of description and differentiation among nodes, devices or networks etc. With the development of the technology, other terms with the similar/same meanings may also be used.

It is noted that some embodiments of the present disclosure are mainly described in relation to <NUM> or NR specifications being used as non-limiting examples for certain exemplary network configurations and system deployments. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples and embodiments, and does naturally not limit the present disclosure in any way. Rather, any other system configuration or radio technologies may equally be utilized as long as exemplary embodiments described herein are applicable.

For simplicity, the system architectures of <FIG> only depict some exemplary elements. In practice, a communication system may further include any additional elements suitable to support communication between terminal devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or terminal device. The communication system may provide communication and various types of services to one or more terminal devices to facilitate the terminal devices' access to and/or use of the services provided by, or via, the communication system.

<FIG> schematically shows a high level architecture in the next generation network such as <NUM>. The system architecture of <FIG> may comprise some exemplary elements such as AMF (Access and mobility Function), SMF (Session Management Function), AUSF (Authentication Service Function), UDM (Unified Data Management), PCF (Policy Control Function), AF (Application Function), NEF (Network Exposure Function), UPF (User plane Function) and NRF (NF Repository Function), RAN (radio access network), SCP (service communication proxy), etc..

In accordance with an exemplary embodiment, the UE can establish a signaling connection with the AMF over the reference point N1, as illustrated in <FIG>. This signaling connection may enable NAS (Non-access stratum) signaling exchange between the UE and the core network, comprising a signaling connection between the UE and the (R)AN and the N2 connection for this UE between the (R)AN and the AMF. The (R)AN can communicate with the UPF over the reference point N3. The UE can establish a protocol data unit (PDU) session to the DN (data network, e.g. an operator network or Internet) through the UPF over the reference point N6.

As further illustrated in <FIG>, the exemplary system architecture also contains the service-based interfaces such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf and Nsmf exhibited by NFs such as the NRF, the NEF, the AUSF, the UDM, the PCF, the AMF and the SMF. In addition, <FIG> also shows some reference points such as N1, N2, N3, N4, N6 and N9, which can support the interactions between NF services in the NFs. For example, these reference points may be realized through corresponding NF service-based interfaces and by specifying some NF service consumers and providers as well as their interactions in order to perform a particular system procedure.

<FIG> schematically shows data collection architecture from any NF. As depicted in <FIG>, the <NUM> System architecture allows NWDAF to collect data from any NF. The NWDAF may belong to the same PLMN (Public Land Mobile Network) where the network function that notifies the data is located.

The Nnf interface is defined for the NWDAF to request subscription to data delivery for a particular context, to cancel subscription to data delivery and to request a specific report of data for a particular context.

<FIG> schematically shows Network Data Analytics Exposure architecture. As depicted in <FIG>, the <NUM> System architecture allows any NF to request network analytics information from NWDAF. The NWDAF belongs to the same PLMN where the network function that consumes the analytics information is located. The Nnwdaf interface is defined for the network functions, to request subscription to network analytics delivery for a particular context, to cancel subscription to network analytics delivery and to request a specific report of network analytics for a particular context.

<FIG> schematically shows architecture to support SMS over NAS. <FIG> schematically shows the non-roaming architecture to support SMS over NAS using the reference point representation.

SMS Function (SMSF) may be connected to the SMS-GMSC/IWMSC (InterWorking MSC)/SMS Router via one of the standardized interfaces as shown in 3GPP TS <NUM>. UDM may be connected to the SMS-GMSC/IWMSC/SMS Router via one of the standardized interfaces as shown in3GPP TS <NUM>. When serving AMF is re-allocated for a given UE, the source AMF includes SMSF identifier as part of UE context transfer to target AMF. If the target AMF, e.g. in the case of inter-PLMN mobility, detects that no SMSF has been selected in the serving PLMN, then the AMF performs SMSF selection.

<FIG> schematically shows the roaming architecture to support SMS over NAS using the Service-based interfaces within the control plane. <FIG> schematically shows the roaming architecture to support SMS over NAS using the reference point representation.

N1: Reference point for SMS transfer between UE and AMF via NAS.

Following reference points are realized by service based interfaces:.

<FIG> schematically shows data storage architecture. As depicted in <FIG>, the <NUM> System architecture allows the UDM, PCF and NEF to store data in the UDR, including subscription data and policy data by UDM and PCF, structured data for exposure and application data (including Packet Flow Descriptions (PFDs) for application detection, AF request information for multiple UEs) by the NEF. UDR can be deployed in each PLMN and it can serve different functions as follows:.

The UDR deployed in each PLMN can store application data for roaming subscribers. There can be multiple UDRs deployed in the network, each of which can accommodate different data sets or subsets, (e.g. subscription data, subscription policy data, data for exposure, application data) and/or serve different sets of NFs. Deployments where a UDR serves a single NF and stores its data, and, thus, can be integrated with this NF, can be possible.

The internal structure of the UDR is shown for information only.

The Nudr interface is defined for the network functions (i.e. NF Service Consumers), such as UDM, PCF and NEF, to access a particular set of the data stored and to read, update (including add, modify), delete, and subscribe to notification of relevant data changes in the UDR.

Each NF Service Consumer accessing the UDR, via Nudr, shall be able to add, modify, update or delete only the data it is authorised to change. This authorisation shall be performed by the UDR on a per data set and NF service consumer basis and potentially on a per UE, subscription granularity.

The following data in the UDR sets exposed via Nudr to the respective NF service consumer and stored shall be standardized:.

The service based Nudr interface defines the content and format/encoding of the 3GPP defined information elements exposed by the data sets.

In addition, it shall be possible to access operator specific data sets by the NF Service Consumers from the UDR as well as operator specific data for each data set.

The content and format/encoding of operator specific data and operator specific data sets are not subject to standardization.

The organization of the different data stored in the UDR is not to be standardized.

Various NFs shown in <FIG> may be responsible for functions such as session management, mobility management, authentication, security, etc. The AUSF, AMF, DN, NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R)AN, SCP, SMSF, NWDAF, etc. may include the functionality for example as defined in 3GPP TS23. <NUM> or other 3GPP specifications.

<FIG> shows UE registration into 5GC with both 3GPP access and Non-3GPP access according to an embodiment of the present disclosure. <FIG> depicts a scenario that UE has registrations into 5GC network from both 3GPP access and non-3GPP access, and the 3GPP access and non-3GPP access belong to separate PLMN (Public Land Mobile Network). Therefore the access networks (AN) are different, denoted as AN(3GPP) and AN(Non-3GPP) accordingly in <FIG>. The AMFs are also different, denoted as AMF (3GPP) and AMF (non-3GPP) accordingly in <FIG>. The SMSFs are also different, denoted as SMSF(3GPP) and SMSF (non-3GPP) accordingly in <FIG>.

At step <NUM>, UE sends a registration request to AMF (3GPP) through AN (3GPP) from the 3GPP access network and indicates its capability to support SMS over NAS (Non-Access Stratum) by set "SMS supported" to true.

At step <NUM>, AMF initiates the UE registration procedure, which may optionally execute the primary authentication procedure which is not shown in <FIG> for the sake of simplicity. AMF registers into UDM through Nudm_UECM_Registration for 3GPP access service operation.

At step <NUM>, UDM creates the AMF registration context into UDR through the Nudr-Dr create service operation, so the AMF serving node for UE 3GPP access is stored in the UDR as context data.

At step <NUM>, UDM sends Nudm_UECM Registration response to AMF for the 3GPP access registration result.

At step <NUM>, as "SMS supported" is indicated in step <NUM>, AMF (3GPP) activates SMS service through Nsmsf_SMService_Activate service operation for the 3GPP access towards SMSF (3GPP).

At step <NUM>, SMSF (3GPP) initiates SMSF(3GPP) registration into UDM through the Nudm_UECM Registration for 3GPP access service operation.

At step <NUM>, UDM creates the SMSF (3GPP) registration context into UDR through Nudr-Dr create service operation, so the SMSF serving node for UE 3GPP access is stored in the UDR as SMSF context data.

At step <NUM>, UDM sends Nudm_UECM Registration response to SMSF for the 3GPP access registration result.

At step <NUM>, SMSF sends Nsmsf_SMService_Activate Response to AMF for the 3GPP access SMS service activate result.

At step <NUM>, AMF(3GPP) sends the Registration Accept message to UE through the 3GPP access network and indicates "SMS allowed" as the SMS service registration result.

At step <NUM>, UE sends a registration request to AMF (non-3GPP) through AN (non-3GPP) from the non-3GPP access network and indicates its capability to support SMS over NAS by set "SMS supported" to true.

At step <NUM>, AMF (non-3GPP) initiates the UE registration procedure, which may optionally execute the primary authentication procedure which is not shown in <FIG> for the sake of simplicity. AMF registers into UDM through Nudm_UECM Registration for non-3GPP access service operation.

At step <NUM>, UDM creates the AMF (non-3GPP) registration context into UDR through the Nudr-Dr create service operation, so the AMF serving node for UE non-3GPP access is stored in the UDR as context data.

At step <NUM>, UDM sends Nudm_UECM Registration response to AMF for the non-3GPP access registration result.

At step <NUM>, as "SMS supported" is indicated in step <NUM>, AMF (non-3GPP) activates SMS service through Nsmsf_SMService_Activate service operation for the non-3GPP access towards SMSF (non-3GPP).

At step <NUM>, SMSF (non-3GPP) initiates SMSF (non-3GPP) registration into UDM through the Nudm_UECM_Registration for non-3GPP access.

At step <NUM>, UDM creates the SMSF registration context into UDR through Nudr-Dr create service operation, so the SMSF serving node for UE non-3GPP access is stored in the UDR as SMSF context data.

At step <NUM>, UDM sends Nudm_UECM Registration response to SMSF for the non-3GPP access registration result.

At step <NUM>, SMSF(Non-3GPP) sends Nsmsf_SMService_Activate Response to AMF (non-3GPP) for the non-3GPP access SMS service activate result.

At step <NUM>, AMF (non-3GPP) sends the Registration Accept message to UE through the non-3GPP access network and indicates "SMS allowed" as the SMS registration result.

The messages as shown in <FIG> are same or similar as the corresponding messages as described in various 3GPP specifications such as 3GPP TS <NUM>, V16. <NUM>, 3GPP TS <NUM>, V16. <NUM>, etc..

<FIG> shows UE initiated PDU session establishment for both 3GPP access and Non-3GPP access according to an embodiment of the present disclosure. <FIG> depicts a scenario that UE initiates PDU session establishment from both 3GPP access and non-3GPP access for different data networks, and the 3GPP access and non-3GPP access belong to separate PLMN. The access networks (AN) are different, denoted as AN(3GPP) and AN(Non-3GPP) accordingly in <FIG>. The Access and Mobility Management Function (AMF) are also different, denoted as AMF (3GPP) and AMF (non-3GPP) accordingly in <FIG>. The Session Management Function (SMF) are also different, denoted as SMF (3GPP) and SMF (non-3GPP) accordingly in <FIG>. The data network accessed in 3GPP access and non-3GPP access may be different, denoted as Data Network Name <NUM> (DNN1) and Data Network Name <NUM> (DNN2) in step <NUM> and step <NUM> accordingly in the PDU session establishment request.

At step <NUM>, UE initiates PDU session establishment in the 3GPP access through the 3GPP access network for DNN1 and sends PDU session establishment request to AMF (3GPP).

At step <NUM>, AMF (3GPP) sends a request to SMF(3GPP) for creation of a new PDU session for 3GPP access and to DNN1 through the Nsmf_PDUSession_CreateSMContext service operation.

At step <NUM>, SMF(3GPP) executes the PDU session establishment procedure, which includes contacting UPF for the N3/N4 sessions which is not shown for the sake of simplicity.

At step <NUM>, SMF(3GPP) sends Nsmf_PDUSession_CreateSMContext response to AMF (3GPP) for the result of the PDU session establishment for the 3GPP access and to DNN1.

At step <NUM>, AMF (3GPP) sends PDU Session Establishment Accept message to UE through 3GPP access network for the PDU session to access DNN1.

At step <NUM>, SMF registers the created PDU session into UDM, which includes parameters of UE identity SUPI (subscription permanent identifier), DNN1, S-NSSAI, PDU session identity, SMF identity, etc..

At step <NUM>, UDM creates the SMF PDU session registration context into UDR through Nudr-Dr create service operation, so the SMF serving node for UE 3GPP PDU session and to DNN1 is stored in the UDR as SMF PDU session context data.

At step <NUM>, UDM sends the Nudm_UECM Registration Response to SMF (3GPP) for the PDU session <NUM> from 3GPP access and to DNN1.

At step <NUM>, UE initiates PDU session establishment in the non-3GPP access through the non-3GPP access network for DNN2 and sends PDU session establishment request to AMF (non-3GPP).

At step <NUM>, AMF (non-3GPP) sends a request to SMF (non-3GPP) for creation of a new PDU session for non-3GPP access and to DNN2 through the Nsmf_PDUSession_CreateSMContext service operation.

At step <NUM>, SMF (non-3GPP) executes the PDU session establishment procedure, which includes contacting UPF for the N3/N4 sessions which is not shown for the sake of simplicity.

At step <NUM>, SMF (non-3GPP) sends Nsmf_PDUSession_CreateSMContext response to AMF (non-3GPP) for the result of the PDU session establishment for the non-3GPP access and to DNN2.

At step <NUM>, AMF (non-3GPP) sends PDU Session Establishment Accept message to UE through non-3GPP access network for the PDU session to access DNN2.

At step <NUM>, SMF (non-3GPP) registers the created PDU session into UDM, which include parameters of UE identity SUPI, DNN2, S-NSSAI, PDU session identity, SMF identity, etc..

At step <NUM>, UDM creates the SMF PDU session registration context into UDR through Nudr-Dr create service operation, so the SMF serving node for UE non-3GPP PDU session and to DNN2 is stored in the UDR as SMF PDU session context data.

At step <NUM>, UDM sends the Nudm_UECM_Registration Response to SMF(non-3GPP) for the PDU session <NUM> from 3GPP access and to DNN2.

<FIG> shows a flowchart of a method according to an embodiment of the present disclosure, which may be performed by an apparatus implemented in/as a network function service consumer entity or communicatively coupled to the network function service consumer entity. As such, the apparatus may provide means for accomplishing various parts of the method <NUM> as well as means for accomplishing other processes in conjunction with other components. The network function service consumer entity may be a network function entity which can retrieve at least one registration data set related to a user equipment from a data management entity. For example, the network function service consumer entity may be NWDAF or HSS.

At block <NUM>, the network function service consumer entity may send a request for retrieving at least two registration data sets related to a user equipment to a data management entity. The request includes two or more corresponding registration data set names. For example, the network function service consumer entity may send a request for retrieving at least one registration data set related to a user equipment to a data management entity. The registration data set may be any suitable registration data set such as registration context data set. The data management entity may support various functionality such as UE's Serving NF Registration Management (e.g. storing serving AMF for UE, storing serving SMF for UE's PDU Session, storing serving SMSF for UE), MT-SMS delivery support, SMS subscription management, etc. The registration data set related to the user equipment may be stored in the network function service consumer entity, in this case the data management entity may require an internal user data storage. The at least one registration data set related to the user equipment may be stored in a data repository entity such as UDR and the data management entity may use subscription data that may be stored in the data repository entity such as UDR, in which case the data management entity implements the application logic and does not require the internal user data storage and then several different the data management entities may serve the same user in different transactions. In an embodiment, the data management entity may be UDM of 5GC.

The registration data set name includes at least one of a registration data set name identifying session management function registration information; a registration data set name identifying AMF 3GPP access registration information; a registration data set name identifying AMF Non 3GPP access registration information; a registration data set name identifying SMSF 3GPP access registration information; and a registration data set name identifying SMSF Non 3GPP access registration information. In other examples, the registration data set name may include any other suitable registration data set names identifying other registration information.

In an embodiment, when the request includes two or more registration data set names, two or more corresponding registration data sets related to the user equipment are requested to be retrieved.

In an embodiment, when the request does not include any registration data set name, all registration data sets related to the user equipment are requested to be retrieved.

In an embodiment, when the request includes one registration data set name, said one registration data set name identifies session management function registration information and session management function (SMF) protocol data unit (PDU) session registration information related to the user equipment is requested to be retrieved.

In an embodiment, when the request includes a registration data set name identifying session management function registration information, the request further includes single network slice selection assistance information and/or a data network name. For example, the single network slice selection assistance information may be SNSSAI as described in 3GPP TS23.

In an embodiment, the request further includes a user equipment identity representing the user equipment. For example, the user equipment identity (ueid) may represents the Subscription Identifier such as SUPI or GPSI (generic public subscription identifier) (see clause <NUM>. <NUM> of 3GPP TS <NUM> V16. SUPI (i.e., imsi (international mobile subscriber identity) or nai (network access identifier)) may be used with the HTTP PUT and PATCH methods; SUPI (i.e. imsi or nai) or GPSI (i.e., msisdn (mobile subscriber integrated services digital network number) or extid) may be used with the GET method. For example, a pattern may be "(imsi-[<NUM>-<NUM>]{<NUM>,<NUM>}|nai-. +|msisdn-[<NUM>-<NUM>]{<NUM>,<NUM>}|extid-[^@]+@[^@]+|. The term "extid" is same as "extid" as described in 3GPP <NUM><NUM>.

At block <NUM>, the network function service consumer entity may receive a response from the data management entity. In an embodiment, the response comprises at least two requested registration data sets related to the user equipment. For example, upon success, the response containing the requested at least one registration data set may be returned. On failure, error information may be returned in the response.

In an embodiment, the request may be an HTTP GET request and the response may be an HTTP GET response. In other embodiments, the request may be other type of request and the response may be other type of response.

In an embodiment, the HTTP GET response may include a response code <NUM> OK and a response body containing the requested at least one (e.g. at least two requested) registration data set related to the user equipment or a response code <NUM> Not Found. For example, on failure, the appropriate HTTP status code indicating the error may be returned and appropriate additional error information may be returned in the GET response body.

<FIG> shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in/as a data management entity or communicatively coupled to the data management entity. As such, the apparatus may provide means for accomplishing various parts of the method <NUM> as well as means for accomplishing other processes in conjunction with other components. The data management entity may be a network function entity which can support data management functionality. For example, the data management entity may be UDM of 5GS. For some parts which have been described in the above embodiments, detailed description thereof is omitted here for brevity.

At block <NUM>, the data management entity may receive a request for retrieving at least two registration data sets related to a user equipment from a network function service consumer entity. The request includes two or more corresponding registration data set names. For example, the data management entity may receive a request for retrieving at least one registration data set related to a user equipment from a network function service consumer entity. For example, the network function service consumer entity may send the request at block <NUM> of <FIG>, and then the data management entity may receive this request.

The registration data set name includes at least one of a registration data set name identifying session management function registration information; a registration data set name identifying AMF 3GPP access registration information; a registration data set name identifying AMF Non 3GPP access registration information; a registration data set name identifying SMSF 3GPP access registration information; and a registration data set name identifying SMSF Non 3GPP access registration information.

In an embodiment, when the request includes two or more registration data set names, two or more corresponding registration data sets related to the user equipment are requested to be retrieved. For example, the data management entity may query the two or more corresponding registration data sets related to the user equipment from a data repository entity such as UDR.

In an embodiment, when the request does not include any registration data set name, all registration data sets related to the user equipment are requested to be retrieved. For example, the data management entity may query all registration data sets related to the user equipment from a data repository entity such as UDR.

In an embodiment, when the request includes one registration data set name, said one registration data set name identifies session management function registration information and session management function protocol data unit session registration information related to the user equipment is requested to be retrieved. For example, the data management entity may query the session management function protocol data unit session registration information related to the user equipment from a data repository entity such as UDR.

In an embodiment, when the request includes a registration data set name identifying session management function registration information, the request further includes single network slice selection assistance information and/or a data network name. For example, the single network slice selection assistance information may be SNSSAI as described in 3GPP TS23. For example, to determine the SMF serving a PDU session, the NWDAF may provide the DNN and S-NSSAI of this PDU session; otherwise the NWDAF may obtain a list of possibly multiple SMFs (e.g., one per PDU session).

In an embodiment, the request further includes a user equipment identity representing the user equipment. The user equipment identity may be SUPI or GPSI.

At block <NUM> (optionally), the data management entity may send a request for retrieving at least two registration data sets related to a user equipment to a data repository entity. The request includes two or more corresponding registration data set names. For example, the data management entity may send a query quest for retrieving the at least one registration data set related to the user equipment to a data repository entity. The data repository entity may store various registration data sets related to the user equipment. In an embodiment, the data repository entity may be UDR of 5GS. The registration data set may be registration context data set.

At block <NUM> (optionally), the data management entity may receive a query response from the data repository entity. For example, upon success, the query response containing the requested at least one registration data set may be returned. On failure, error information may be returned in the query response. In an embodiment, the response comprises at least two requested registration data sets related to the user equipment.

In an embodiment, when the requested at least one registration data set is stored in the data management entity, the data management entity may query the requested at least one registration data by itself and blocks <NUM> and <NUM> may be omitted.

At block <NUM>, the data management entity may send a response to the network function service consumer entity. In an embodiment, the response comprises at least two requested registration data sets related to the user equipment. For example, upon success, the response containing the requested at least one registration data set may be returned. On failure, error information may be returned in the response.

<FIG> shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in/as a data repository entity or communicatively coupled to the data repository entity. As such, the apparatus may provide means for accomplishing various parts of the method <NUM> as well as means for accomplishing other processes in conjunction with other components. The data repository entity may be a network function entity which can support data repository functionality. For example, the data repository entity may be UDR of 5GS. For some parts which have been described in the above embodiments, detailed description thereof is omitted here for brevity.

At block <NUM>, the data repository entity may receive a query quest for retrieving at least two registration data sets related to a user equipment from a data management entity, wherein the query request includes two or more corresponding registration data set names. For example, the data repository entity may receive a query quest for retrieving at least one registration data set related to a user equipment from a data management entity. The registration data set may be registration context data set. The query request includes one or more registration data set names and the registration data set name includes a registration data set name identifying session management function registration information. For example, the data management entity may send the query quest at block <NUM> of <FIG>, and then the data repository entity may receive the query quest.

At block <NUM>, the data repository entity may send a query response to the data management entity. For example, upon success, the query response containing the requested at least one registration data set may be returned. On failure, error information may be returned in the query response. In an embodiment, the query response comprises at least two requested registration data sets related to the user equipment.

In an embodiment, the registration data set name further includes at least one of a registration data set name identifying AMF 3GPP access registration information; a registration data set name identifying AMF Non 3GPP access registration information; a registration data set name identifying SMSF 3GPP access registration information; and a registration data set name identifying SMSF Non 3GPP access registration information.

In an embodiment, the query request is an HTTP GET request and the query response is an HTTP GET response.

In an embodiment, when the query request includes a registration data set name identifying session management function registration information, the query request further includes single network slice selection assistance information and/or a data network name.

<FIG> shows a flowchart of a method of retrieval of multiple UE registration data sets according to another embodiment of the present disclosure. <FIG> depicts a scenario where the NF service consumer (e.g. NWDAF, HSS) sends a request to the UDM to receive multiple UE registration data sets. In this example scenario the UE's 3GPP AMF and the UE's non-3GPP AMF registration data are retrieved with a single request. It is noted that any other registration data sets can be retrieved with a single request. The request contains the UE's registrations({ueId}/registrations) and query parameters identifying the requested registration data sets (in this example: ?registration-dataset-names=AMF_3GPP, AMF_NON_3GPP).

At step <NUM>, the NF Service Consumer (e.g. NWDAF, HSS) sends a GET request to the resource representing the UE registrations. Query parameters indicate the requested UE registration data sets.

At step <NUM>, the UDM responds with "<NUM> OK" with the message body containing the requested UE registration data sets. On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information may be returned in the GET response body.

In an embodiment, the above Table <NUM> may be added with Registrations resource as following:.

In an embodiment, the following content may be added in 3GPP <NUM><NUM>.

This resource represents the UE's registration data.

Resource URI: {apiRoot}/nudm-uecm/v1/{ueId}/registrations
This resource shall support the resource URI variables defined in table <NUM>. <NUM>-<NUM>.

This method shall support the URI query parameters specified in table <NUM>. <NUM>-<NUM>. NOTE: The retrieval of these registration data sets can also be achieved by sending individual GET requests to the corresponding sub-resources under the {ueId}/registraions resource. When multiple registration data sets need to be retrieved by the NF Service consumer, it is recommended to use a single GET request with query parameters rather than issuing multiple GET requests.

This method shall support the request data structures specified in table <NUM>. <NUM>-<NUM> and the response data structures and response codes specified in table <NUM>. <NUM>-<NUM>.

The proposed data model is as following:.

In an embodiment, the UDR method may be updated to support the retrieval of SMF PDU session contexts in the request for multiple context data sets. Following are the updates on the data models which can be added in 3GPP TS <NUM><NUM>.

<FIG> shows a flowchart of some example use cases for getting multiple registration data sets in single request according to another embodiment of the present disclosure.

Example <NUM>: Retrieve all UE registration data sets from UDM, and UDM queries all UE registration related data sets from UDR. Example <NUM>: Retrieve all AMF registration data sets from UDM, and UDM queries AMF registration related data sets from UDR. Example <NUM>: Retrieve all SMSF registration data sets from UDM, and UDM queries SMSF registration related data sets from UDR. Example <NUM>: Retrieve all SMF PDU session registration data sets from UDM, and UDM queries SMF PDU session registration related data sets from UDR. Example <NUM>: Retrieve all AMF registration and SMF PDU session registration data sets from UDM, and UDM queries SMF PDU session registration related data sets from UDR.

At step <NUM>, the NF service consumer gets all UE registration data sets from UDM without any specification of the required registration data sets in the query parameter through the GET method on the resource. /{ueId}/registrations.

At step <NUM>, UDM queries multiple context data sets from UDR in one single request and sets the requested context-dataset-names=AMF_3GPP, AMF_NON_3GPP, SMF_PDU_SESSIONS, SMSF_3GPP, SMSF_NON_3GPP.

At step <NUM>, UDM returns to the NF service consumer the result from UDR, which could include all required registration data sets in the RegistrationDataSets: Amf3GppAccessRegistration (identified by AMF_3GPP in the request), AmfNon3GppAccessRegistration (identified by AMF_NON_3GPP in the request), SmfRegistrationInfo(identified by SMF_PDU_SESSIONS in the request, a list of PDU sessions), SmsfRegistration for 3GPP access (identified by SMSF_3GPP in the request), SmsfRegistration for non-3GPP access (identified by SMSF _NON_3GPP in the request).

At step <NUM>, the NF service consumer gets all UE AMF registration data sets from UDM with specification of the required registration data set in the query parameter through the GET method on the resource. /{ueId}/registrations?registration-dataset-names=AMF_3GPP, AMF_NON_3GPP.

At step <NUM>, UDM queries multiple context data sets from UDR in one single request and sets the requested context-dataset-names=AMF_3GPP, AMF_NON_3GPP.

At step <NUM>, UDM returns to the NF service consumer the result from UDR, which could include all required registration data sets in the RegistrationDataSets: Amf3GppAccessRegistration (identified by AMF_3GPP in the request), AmfNon3GppAccessRegistration (identified by AMF_NON _3GPP in the request).

At step <NUM>, the NF service consumer gets all UE SMSF registration data sets from UDM with specification of the required registration data set in the query parameter through the GET method on the resource. /{ueld}/registrations?registration-dataset-names=SMSF_3GPP, SMSF_NON_3GPP.

At step <NUM>, UDM queries multiple context data sets from UDR in one single request and sets the requested context-dataset-names=SMSF_3GPP, SMSF_NON_3GPP.

At step <NUM>, UDM returns to the NF service consumer the result from UDR, which could include all required registration data sets in the RegistrationDataSets: SmsfRegistration for 3GPP access (identified by SMSF_3GPP in the request), SmsfRegistration for non-3GPP access (identified by SMSF_NON_3GPP in the request).

At step <NUM>, the NF service consumer gets all SMF PDU session registration data sets from UDM with specification of the required registration data set in the query parameter through the GET method on the resource. /{ueId}/registrations?registration-dataset-names=SMF_PDU_SEESIONS.

At step <NUM>, UDM queries multiple context data sets from UDR in one single request and sets the requested context-dataset-names= SMF_PDU_SEESIONS.

At step <NUM>, UDM returns to the NF service consumer the result from UDR, which could include all required registration data sets in the RegistrationDataSets: SmfRegistrationInfo (identified by SMF_PDU_SESSIONS in the request, a list of PDU sessions).

At step <NUM>, the NF service consumer gets all UE AMF registration and SMF PDU session registration data sets from UDM with specification of the required registration data set in the query parameter through the GET method on the resource. /{ueld}/registrations?registration-dataset-names=AMF_3GPP, AMF_NON_3GPP, SMF_PDU_SEESIONS.

At step <NUM>, UDM queries multiple context data sets from UDR in one single request and sets the requested context-dataset-names= AMF_3GPP, AMF_NON_3GPP, SMF_PDU_SEESIONS.

At step <NUM>, UDM returns to the NF service consumer the result from UDR, which could include all required registration data sets in the RegistrationDataSets: Amf3GppAccessRegistration (identified by AMF_3GPP in the request), AmfNon3GppAccessRegistration (identified by AMF_NON_3GPP in the request), SmfRegistrationInfo(identified by SMF_PDU_SESSIONS in the request, a list of PDU sessions).

Some messages as shown in <FIG> are similar as the corresponding messages as described in various 3GPP specifications such as 3GPP TS <NUM>, V16. <NUM>, 3GPP TS <NUM>, V16. <NUM>, etc..

<FIG> shows a flowchart of NWDAF related use case for getting multiple registration data sets in single request according to another embodiment of the present disclosure. In this embodiment, the NF service consumer is NWDAF.

At step <NUM>, a NWDAF service consumer subscribes a data analytics report for a UE from NWDAF.

NWDAF firstly needs to get the currently serving nodes for the UE. So, the proposed method is used by NWDAF to retrieve the serving AMF and SMF instances from UDM in a single request. At step <NUM>, NWDAF gets all UE AMF registration and SMF PDU session registration data sets from UDM with specification of the required registration data sets in the query parameter through the GET method on the resource. /{ueld}/registrations?registration-dataset-names=AMF 3GPP, AMF_NON_3GPP, SMF_PDU_SEESIONS.

At step <NUM>, UDM queries multiple context data sets from UDR in one single request and sets the requested context-dataset-names=AMF_3GPP, AMF_NON_3GPP, SMF_PDU_SEESIONS.

At step <NUM>, UDM returns to the NF service consumer the result from UDR, which could include all registration data sets in the RegistrationDataSets: Amf3GppAccessRegistration (identified by AMF_3GPP in the request), AmfNon3GppAccessRegistration (identified by AMF_NON_3GPP in the request), SmfRegistrationInfo(identified by SMF_PDU_SESSIONS in the request, a list of PDU sessions).

At step <NUM>, NWDAF subscribes UE access and mobility related events from AMF (3GPP access) whose information is got in step <NUM>.

At step <NUM>, NWDAF subscribes UE access and mobility related events from AMF (non-3GPP access) whose information is got in step <NUM>.

At step <NUM>, NWDAF subscribes UE PDU session related events from SMF (3GPP access) whose information is got in step <NUM>.

At step <NUM>, NWDAF subscribes UE PDU session related events from SMF (non-3GPP access) whose information is got in step <NUM>.

At step <NUM>, NWDAF responds NWDAF service consumer the result of the data analytics report subscription.

<FIG> shows a flowchart of HSS related use case for getting multiple registration data sets in single request according to another embodiment of the present disclosure. In this embodiment, the NF service consumer is HSS.

At step <NUM>, the HSS receives a request for routing information from the SMS-GMSC via MAP or S6c.

At step <NUM>, the HSS queries the EPS-UDR via Ud to read the registered MME/MSC, the registered SGSN, the UE-not-reachable flags for MME/MSC, SGSN, 3GppSMSF and Non3GppSMSF and the SMSF Registration Notification flag.

At step <NUM>, if the UE-not-reachable flags for 3GppSMSF, Non3GppSMSF and SMSF Registration Notification flag are not set and unless the user is known not to be registered in 5GC, the HSS retrieves the registered SMSF addresses (if any) from the UDM. HSS uses the proposed method to get all UE SMSF registration data sets from UDM with specification of the required registration data set in the query parameter through the GET method on the resource. /{ueId}/registrations?registration-dataset-names=SMSF_3GPP, SMSF_NON_3GPP.

At steps <NUM>-<NUM>, the UDM retrieves the requested information from the 5GS-UDR. UDM queries multiple context data sets in one single request and set the requested context-dataset-names=SMSF_3GPP, SMSF_NON_3GPP.

At step <NUM>, the UDM forwards the retrieved addresses to the HSS if any. UDM returns to the NF service consumer the result from UDR, which could include all required registration data sets in the RegistrationDataSets: SmsfRegistration for 3GPP access (identified by SMSF_3GPP in the request), SmsfRegistration for non-3GPP access (identified by SMSF_NON_3GPP in the request).

At step <NUM>, the HSS returns the relevant MT-SMS target node addresses registered in HSS and/or UDM to the SMS-GMSC and the procedure is terminated. Otherwise, if there is no MT-SMS target node address registered in HSS nor in UDM, a negative response (Absent Subscriber SM) is sent to the SMS-GMSC and the procedure continues with steps <NUM> to <NUM>.

At step <NUM>, the HSS includes the SMSC address to the Message Waiting Data (MWD) stored in the EPS-UDR and informs the SMSC as defined in 3GPP TS <NUM>. The relevant UE-not-reachable flags and the SMSF Registration Notification flag are set in the EPS-UDR.

At step <NUM>, the HSS subscribes in UDM to be notified when the UE registers in the 5GC for SMS service (i.e. when an SMSF is registered in UDM) by using the Nudm_EE_Subscribe service operation (SUPI, SMSF Registration Notification event) as defined in 3GPP TS <NUM>. In this case, the HSS subscribes to SMSF Registration Notification event in UDM instead to the UE Reachability Notification as even if the UE is reachable in an AMF, the UE will not be ready for SMS within the 5GC until an SMSF is registered for the UE in UDM.

At step <NUM>, the UDM stores the SMSF Registration Notification flag in the <NUM>-UDR.

Some messages as shown in <FIG> are similar as the corresponding messages as described in various 3GPP specifications such as 3GPP TS <NUM>, V16. <NUM>, 3GPP TS <NUM>, V16. <NUM>, 3GPP TS <NUM> V16. <NUM>, etc..

In an embodiment, as <NUM> is based on service-based architecture (SBA) and the interface used between Network Functions (NFs) are based on service-based interface (SBI), the interface may be modeled as Open API (Application Programming Interface) and defined in yaml files, the Nudm-UECM open API delta updates may be as following:
/{ueId}/registrations:
get:
summary: retrieve UE registration data
operationId: GetRegistrations
tags:
- UECM Registration Info Retrieval
parameters:
- name: ueId
in: path
description: Identifier of the UE
required: true
schema:
$ref: 'TS29571_CommonData. yaml#/components/schemas/VarUeId'
- name: supported-features
in: query
schema:
$ref: 'TS29571_CommonData. yaml#/components/schemas/SupportedFeatures'
- name: registration-dataset-names
in: query
style: form
explode: false
description: List of UECM registration dataset names
required: true
schema:
$ref: '#/components/schemas/RegistrationDatasetNames'
- name: single-nssai
in: query
content:
application/json:
schema:
$ref: 'TS29571_CommonData. yaml#/components/schemas/Snssai'
- name: dnn
in: query
schema:
$ref: 'TS29571_CommonData. yaml#/components/schemas/Dnn'
responses:
'<NUM>':
description: Expected response to a valid request
content:
application/json:
schema:
$ref: '#/components/schemas/RegistrationDataSets'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
"<NUM>":
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
default:
description: Unexpected error.

In an embodiment, the Nudr-Dr open API delta updates especially on the data models may be following:
<IMG>.

<FIG> is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure. For example, any one of the network function service consumer entity, the data management entity and the data repository entity described above may be implemented as or through the apparatus <NUM>.

The apparatus <NUM> comprises at least one processor <NUM>, such as a DP, and at least one MEM <NUM> coupled to the processor <NUM>. The apparatus <NUM> may further comprise a transmitter TX and receiver RX <NUM> coupled to the processor <NUM>. The MEM <NUM> stores a PROG <NUM>. The PROG <NUM> may include instructions that, when executed on the associated processor <NUM>, enable the apparatus <NUM> to operate in accordance with the embodiments of the present disclosure. A combination of the at least one processor <NUM> and the at least one MEM <NUM> may form processing means <NUM> adapted to implement various embodiments of the present disclosure.

Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processor <NUM>, software, firmware, hardware or in a combination thereof.

The MEM <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories, as non-limiting examples.

The processor <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.

In an embodiment where the apparatus is implemented as or at the network function service consumer entity, the memory <NUM> contains instructions executable by the processor <NUM>, whereby the network function service consumer entity operates according to the method as described in reference to <FIG>.

In an embodiment where the apparatus is implemented as or at the data management entity, the memory <NUM> contains instructions executable by the processor <NUM>, whereby the data management entity operates according to the method as described in reference to <FIG>.

In an embodiment where the apparatus is implemented as or at the data repository entity, the memory <NUM> contains instructions executable by the processor <NUM>, whereby the data repository entity operates according to the method as described in reference to <FIG>.

<FIG> is a block diagram showing a network function service consumer entity according to an embodiment of the disclosure. As shown, the network function service consumer entity <NUM> comprises a sending module <NUM> and a receiving module <NUM>. The sending module <NUM> may be configured to send a request for retrieving at least two registration data sets related to a user equipment to a data management entity. The request includes two or more corresponding registration data set names. The receiving module <NUM> may be configured to receive a response from the data management entity. The response comprises at least two requested registration data sets related to the user equipment.

<FIG> is a block diagram showing a data management entity according to an embodiment of the disclosure. As shown, the data management entity <NUM> comprises a receiving module <NUM> and a sending module <NUM>. The receiving module <NUM> may be configured to receive a request for retrieving at least two registration data sets related to a user equipment from a network function service consumer entity. The request includes two or more corresponding registration data set names. The sending module <NUM> may be configured to send a response to the network function service consumer entity. The response comprises at least two requested registration data sets related to the user equipment.

<FIG> is a block diagram showing a data repository entity according to an embodiment of the disclosure. As shown, the data repository entity <NUM> comprises a receiving module <NUM> and a sending module <NUM>. The receiving module <NUM> may be configured to receive a query quest for retrieving at least two registration data sets related to a user equipment from a data management entity, wherein the query request includes two or more corresponding registration data set names. The sending module <NUM> may be configured to send a query response to the data management entity. The query response comprises at least two requested registration data sets related to the user equipment.

According to an aspect of the disclosure it is provided a computer program product being tangibly stored on a computer readable storage medium and including instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods as described above.

According to an aspect of the disclosure it is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods as described above.

Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, for data management entity such as UDM, a new GET method on resource {ueId}/registrations is introduced as generic registration data sets retrieval method to enable the possibility to retrieve multiple registration data sets with a single GET request. So use cases which have been identified that benefit from retrieving multiple registration data sets with a single GET request are supported by the proposed method provided by the data management entity. In some embodiments herein, for data repository entity such as UDR, the GET method for the multiple context data sets retrieval is updated to enable the possibility to retrieve multiple context data sets together with the sessions context data (such as SMF PDU sessions context data) with a single GET request. So use cases which have been identified that benefit from retrieving multiple registration data sets including the session context data with a single GET request are supported by the proposed method provided by the data repository entity. In some embodiments herein, unnecessary signaling traffic are avoided and the network efficiency are improved from operation point of view, which means OPEX (operating expenses) reduction. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function, or means that may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

Claim 1:
A method (<NUM>) performed by a network function service consumer entity, comprising:
sending (<NUM>) a request for retrieving at least two registration data sets related to a user equipment to a data management entity, wherein the request includes two or more corresponding registration data set names; and
receiving (<NUM>) a response from the data management entity, wherein the response comprises at least two requested registration data sets related to the user equipment;
wherein the registration data set name includes at least one of:
a registration data set name identifying session management function registration information;
a registration data set name identifying access and mobility management function, AMF, 3rd generation partnership project, 3GPP, access registration information;
a registration data set name identifying AMF Non 3GPP access registration information;
a registration data set name identifying short message service function, SMSF, 3GPP access registration information; and
a registration data set name identifying SMSF Non 3GPP access registration information.