Patent Application
20250056207
Embodiments presented herein relate to methods, a Network Exposure Function node, a Unified Data Management node, computer programs, and a computer program product for handling groups of User Equipment in a core network.
In general terms, a fifth-generation (5G) system (5GS) is a telecommunication system using the 5G New Radio (NR) air interface, or the Evolved Universal Terrestrial Radio Access (E-UTRA) air interface connected to a 5G core network (5GC). The 5GC comprises functional entities called Network Functions (NFs). System functionality is achieved by a set of NFs providing services to other authorized NFs to access their services. Each NF offers different functionalities and thereby provides different services.
In general terms, the 5G System supports management of 5G Virtual Network (VN) Group identification and membership (i.e., definition of 5G VN group identifiers and membership) and 5G VN Group data (i.e., definition of 5G VN group data). The 5G VN Group management can be configured by a network administrator or can be managed dynamically by AF. A 5G VN group is characterized by 5G VN group identities, 5G VN group membership, and 5G VN group data. With respect to 5G VN group identities, an External Group ID and an Internal Group ID are used to identify each 5G VN group. The 5G VN group members are uniquely identified by their Generic Public Subscription Identifier (GPSI). The 5G VN group data may include the following parameters: Protocol Data Unit (PDU) session type, Data Network Name (DNN), Single Network Slice Selection Assistance Information (S-NSSAI) and Application descriptor, Information related with secondary authentication/authorization (e.g., to enable IP address assignment by the Data Network Authentication Authorization and Accounting (DN-AAA) server).
A 5G VN group is identified by the AF using the External Group ID. The NEF provides the External Group ID to the UDM. The UDM maps the External Group ID to the Internal Group ID. For a newly created 5G VN group, an Internal Group ID is allocated by the UDM. The NEF can retrieve the Internal Group ID from the UDM via Nudm_SDM_Get service operation (External Group ID, Group Identifier translation). In this respect, in the technical specification 3GPP TS 23.501 entitled “System architecture for the 5G System (5GS)” version 17.3.0 is included the following note in Section 5.29.2:
NOTE 1: It is assumed that all members of a 5G VN group belong to the same UDM Group Identifier. The NEF can select a UDM instance supporting the UDM Group Identifier of any of the member GPSIs of the 5G VN group.
Here, a UDM Group ID refers to one or more UDM instances managing a specific set of SUPIs. A UDM Group consists of one or multiple UDM sets. This implies that all UE group members must be associated with the same UDM Group Identifier. In other words, the existing 3GPP standards do not allow to have different UE group members belonging to different UDM Group Identifiers.
An object of embodiments herein is to address the above issues.
According to a first aspect there is presented a method for handling groups of UEs in a core network. The method is performed by an NEF node in the core network. The method comprises obtaining an indication that a group of UEs is formed. The group of UEs is associated with a single virtual External Group Identifier. The method comprises identifying to which UDM group each of the UEs belongs. Each UDM group comprise at least one UDM node. The method comprises sending a request to each identified UDM group for the UEs to be added to the group of UEs, and for each identified UDM group to, for the group of UEs, allocate a respective External Group Identifier which will serve the group of UEs. The method comprises receiving, from each identified UDM group, a respective External Group Identifier for the group of UEs. The method comprises associating all the received External Group Identifiers with the single virtual External Group Identifier.
According to a second aspect there is presented a NEF node for handling groups of UEs in a core network. The NEF node comprises processing circuitry. The processing circuitry is configured to cause the NEF node to obtain an indication that a group of UEs is formed. The group of UEs is associated with a single virtual External Group Identifier. The processing circuitry is configured to cause the NEF node to identify to which UDM group each of the UEs belongs. Each UDM group comprise at least one UDM node. The processing circuitry is configured to cause the NEF node to send a request to each identified UDM group for the UEs to be added to the group of UEs, and for each identified UDM group to, for the group of UEs, allocate a respective External Group Identifier which will serve the group of UEs. The processing circuitry is configured to cause the NEF node to receive, from each identified UDM group, a respective External Group Identifier for the group of UEs. The processing circuitry is configured to cause the NEF node to associate all the received External Group Identifiers with the single virtual External Group Identifier.
According to a third aspect there is presented a NEF node for handling groups of UEs in a core network. The NEF node comprises an obtain module configured to obtain an indication that a group of UEs is formed. The group of UEs is associated with a single virtual External Group Identifier. The NEF node comprises an identify module configured to identify to which UDM group each of the UEs belongs. Each UDM group comprise at least one UDM node. The NEF node comprises a send module configured to send a request to each identified UDM group for the UEs to be added to the group of UEs, and for each identified UDM group to, for the group of UEs, allocate a respective External Group Identifier which will serve the group of UEs. The NEF node comprises a receive module configured to receive, from each identified UDM group, a respective External Group Identifier for the group of UEs. The NEF node comprises an associate module configured to associate all the received External Group Identifiers with the single virtual External Group Identifier.
According to a fourth aspect there is presented a computer program for handling groups of UEs in a core network, the computer program comprising computer program code which, when run on processing circuitry of an NEF node, causes the NEF node to perform a method according to the first aspect.
According to a fifth aspect there is presented a method for handling groups of UEs in a core network. The method is performed by a UDM node in the core network. The method comprises obtaining a request from a NEF node, for at least one UE to be added to a group of UEs and to, for the group of UEs, allocate an External Group Identifier which will serve the group of UEs. The method comprises allocating the External Group Identifier to the group of UEs. The method comprises sending the External Group Identifier for the group of UEs to the NEF node.
According to a sixth aspect there is presented a UDM node for handling groups of UEs in a core network. The UDM node comprises processing circuitry. The processing circuitry is configured to cause the UDM node to obtain a request from a NEF node, for at least one UE to be added to a group of UEs and to, for the group of UEs, allocate an External Group Identifier which will serve the group of UEs. The processing circuitry is configured to cause the UDM node to allocate the External Group Identifier to the group of UEs. The processing circuitry is configured to cause the UDM node to send the External Group Identifier for the group of UEs to the NEF node.
According to a seventh aspect there is presented a UDM node for handling groups of UEs in a core network. The UDM node comprises an obtain module configured to obtain a request from a NEF node, for at least one UE to be added to a group of UEs and to, for the group of UEs, allocate an External Group Identifier which will serve the group of UEs. The UDM node comprises an allocate module configured to allocate the External Group Identifier to the group of UEs. The UDM node comprises a send module configured to send the External Group Identifier for the group of UEs to the NEF node.
According to an eighth aspect there is presented a computer program for handling groups of UEs in a core network, the computer program comprising computer program code which, when run on processing circuitry of a UDM node, causes the UDM node to perform a method according to the fifth aspect.
According to a ninth aspect there is presented a computer program product comprising a computer program according to at least one of the fourth aspect and the eighth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.
Advantageously, these aspects enable a third-party application (as represented by the AF) to manage a group of UEs with one single/unique External Group Identifier, no matter the set of UEs in the group and how the network is partitioned. This is achieved in an automated manner, without requiring any manual intervention by the MNO.
Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.
Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a/an/the element, apparatus, component, means, module, step, etc.” are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.
The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:
The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.
As noted above, existing 3GPP standards do not allow to have different UE group members belonging to different UDM Group Identifiers. Issues with this as discovered by the inventors of the present disclosure will be further illustrated below.
As an illustrative non-limiting example, assume that there are three groups of UDMs, each having its own group identifier (UDM group ID=1, UDM group ID=2, and UDM group ID=3) and where each such group of UDMs comprises at least one UDM. Assume further that:
If the MNO and/or AF require(s) that UEs with SUPIs 50-51, SUPIs 150-151 and SUPIs 250-251 are to be group members of the same External Group Identifier, before adding these UEs to the group of UEs, the MNO needs to perform a re-allocation of the UEs (by means of the SUPIs) to be served as follows, where the UDM group with UDM group ID=1 is serving the External Group Identifier identifying the group of UEs:
This procedure works well if the UEs (or at least the SUPIs) are not previously split in different UDM groups. However, if the UEs (or at least the SUPIs) are already split into different UDM groups, it could be complicated and tedious for the MNO to reallocate the SUPIs so that the group of UEs is solely managed by a single UDM group. Typically, the MNO will allocate the SUPIs as convenient as possible (e.g., according to SUPI ranges, MNO requirements, other network information, etc.) for the UDM grouping so, if a group of UEs is created a later stage, some technique is required in order to make the groups of UEs usable.
One technique is to split the group of UEs into several groups of UEs, where each group of UEs is managed by a respective UDM group. Continuing the above illustrative example this yields:
It is here noted that the remaining SUPIs not associated with any External Group Identifiers are served by the UDM groups as initially disclosed (e.g., UDM group ID=1 also serves SUPIs 1-49).
In terms of Network Exposure, it is advantageous for the MNO to offer, display, or provide, a single group of UEs to external AFs. This is since the AFs should not, or at least need not to, be aware of the internal data model, or grouping of UEs or SUPIs, in the 5GC network. In the present illustrative example, it might therefore not be reasonable to require the AF to manage three groups of UEs as if they were a single group, since this would involve the AF to submit three requests (one for each group of UEs) for each procedure initiated by the AF. In the worst case, the MNO would be requiring the AFs to send as many requests as there are UDM Group Identifiers in the network if there are UE group members belonging to all UDM groups.
The embodiments disclosed herein therefore relate to techniques for handling groups of UEs 85 in a core network. In order to obtain such techniques there is provided an NEF node 100, a method performed by the NEF node 100, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the NEF node 100, causes the NEF node 100 to perform the method. In order to obtain such techniques there is further provided a UDM node 200, a method performed by the UDM node 200, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the UDM node 200, causes the UDM node 200 to perform the method.
Upon instruction by the NEF node 100, the UDM node 200 for each different UDM group generates an External Group Identifier. Each External Group Identifier will be managed by means of a UDM group identifier, so that, internally in the 5GC network, all UEs 85 in a group are managed by means of the same External Group Identifier.
All generated External Group Identifiers will be associated by the NEF node 100 and the UDM node 200 to a single virtual External Group Identifier as managed by the AF node 30. The association between the External Group Identifier and the single virtual External Group Identifier is stored in the UDR node 40 for persistency so that the MNO is aware that each group of UEs 85 is related to an AF-managed group (as identified by the virtual External Group Identifier), but does not contain all UE members, but only the UE members served by the UDM group. UDM instances subscribe to changes in other UDM NF profiles of the group and utilize a notification filtering criterion so that only when there is a new External Group Identifier being served by the UDM group, the rest of UDM instances within the group store such a new (generated by the UDM node) External Group Identifier as part of their NF profiles.
Reference is now made to
Embodiments relating to further details of handling groups of UEs 85 in a core network as performed by the NEF node 100 will now be disclosed.
In some aspects, the group of UEs 85 is formed either by the AF node 30 as a new 5G virtual network group, or by an MNO. Hence, in some embodiments, the indication that the group of UEs 85 is formed is obtained either from an AF node 30 or from an MNO node.
In some aspects, for each UE 85, the NEF 100 performs a discovery via the NRF 20 to locate its UDM group. In particular, in some embodiments, identifying to which UDM group each of the UEs 85 belongs involves the NEF node 100 to perform a discovery procedure with an NRF node 20.
In some aspects, the NEF node 100 stores the single virtual External group Identifier and the association to the UDM group which includes the generated External Group Identifier. Hence, in some embodiments, the NEF node 100 is configured to perform (optional) step S112.
In some aspects, once all the UDM groups have responded, each including its External Group Identifier, the NEF 100 returns a response to the AF node 30. Hence, in some embodiments, the NEF node 100 is configured to perform (optional) step S114.
In some aspects, when the NEF node 100 receives from the AF node 30 a request for event exposure related to a group of UEs 85, the NEF node 100 identifies the received AF-managed External Group Identifier as a “virtual” group comprised of different External Group Identifiers, each one corresponding to a different UDM group. The NEF node 100 then subscribes to events for each group of UEs 85 sending a request to a UDM instance of each UDM group. The NEF 100 might then aggregate the information of the responses from each UDM group into a single event subscription response that is sent to the AF node 30. Hence, in some embodiments, the NEF node 100 is configured to perform (optional) steps S116-S122.
Reference is now made to
As disclosed above, the NEF node 100 in step S106 sends a request to each identified UDM group for the UEs 85 to be added to the group of UEs 85. It is here assumed that this request is received by the UDM node 200.
Embodiments relating to further details of handling groups of UEs 85 in a core network as performed by the UDM node 200 will now be disclosed.
In some aspects, the request comprises the above-mentioned single virtual External Group Identifier. That is, in some embodiments, the request comprises a single virtual External Group Identifier for the group of UEs 85, and the single virtual External Group Identifier is common for all groups of UDMs serving the group of UEs 85.
In some aspects, the single virtual External Group Identifier is permanently stored in the UDR node 40. In particular, in some embodiments, the UDM node 200 is configured to perform (optional) step S210.
In some aspects, the UDM node 200 also stores the single virtual External Group Identifier as part of group data. In particular, in some embodiments, the UDM node 200 is configured to perform (optional) step S212.
In some aspects, the UDM node 200 updates its NF profile, ‘UDM info’, to indicate that two new External Group Identifiers (i.e., the External Group Identifier and the single virtual External Group Identifier) are managed/served. Hence, in some embodiments, the UDM node 200 has an NF profile, and the UDM node 200 is configured to perform (optional) step S214.
In some aspects, the UDM node 200 included a parameter to indicate to the NRF node 20 that partial notifications should be sent only when there is a change in External Group Identifiers support/management. In particular, in some embodiments, the UDM node 200 is part of a UDM group and the UDM node 200 is configured to perform (optional) step S202.
A first particular embodiment for handling groups of UEs 85 in a core network based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram of
A second particular embodiment for handling groups of UEs 85 in a core network based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram of
This embodiment enables AF to use a single External Group Identifier since NEF hides the complexity of the 5GC network and partitioning of UEs.
Particularly, the processing circuitry 110 is configured to cause the NEF node 100 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 130 may store the set of operations, and the processing circuitry 110 may be configured to retrieve the set of operations from the storage medium 130 to cause the NEF node 100 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 110 is thereby arranged to execute methods as herein disclosed.
The storage medium 130 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.
The NEF node 100 may further comprise a communications interface 120 for communications with other entities, nodes, functions, and devices, as in the communication network 10. As such the communications interface 120 may comprise one or more transmitters and receivers, comprising analogue and digital components.
The processing circuitry 110 controls the general operation of the NEF node 100 e.g. by sending data and control signals to the communications interface 120 and the storage medium 130, by receiving data and reports from the communications interface 120, and by retrieving data and instructions from the storage medium 130. Other components, as well as the related functionality, of the NEF node 100 are omitted in order not to obscure the concepts presented herein.
In general terms, each functional module 110a: 110k may be implemented in hardware or in software. Preferably, one or more or all functional modules 110a: 110k may be implemented by the processing circuitry 110, possibly in cooperation with the communications interface 120 and/or the storage medium 130. The processing circuitry 110 may thus be arranged to from the storage medium 130 fetch instructions as provided by a functional module 110a: 110k and to execute these instructions, thereby performing any steps of the NEF node 100 as disclosed herein.
Particularly, the processing circuitry 210 is configured to cause the UDM node 200 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 may be configured to retrieve the set of operations from the storage medium 230 to cause the UDM node 200 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.
The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.
The UDM node 200 may further comprise a communications interface 220 for communications with other entities, nodes, functions, and devices, as in the communication network 10. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components.
The processing circuitry 210 controls the general operation of the UDM node 200 e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the UDM node 200 are omitted in order not to obscure the concepts presented herein.
In general terms, each functional module 210a: 210g may be implemented in hardware or in software. Preferably, one or more or all functional modules 210a: 210g may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and/or the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 210a: 210g and to execute these instructions, thereby performing any steps of the UDM node 200 as disclosed herein.
Any of the NEF node 100 and the UDM node 200 may be provided as a standalone device or as a part of at least one further device. For example, the NEF node 100 and the UDM node 200 may be provided in one or more nodes of the core network. Alternatively, functionality of the NEF node 100 and the UDM node 200 may be distributed between at least two devices, or nodes. A first portion of the instructions performed by the NEF node 100 and the UDM node 200 may be executed in a respective first device, and a second portion of the instructions performed by the NEF node 100 and the UDM node 200 may be executed in a respective second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the NEF node 100 and the UDM node 200 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by an NEF node 100 and the UDM node 200 residing in a cloud computational environment. Therefore, although a single processing circuitry 110, 210 is illustrated in
In the example of
The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 22382297.4 | Mar 2022 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2022/083149 | 11/24/2022 | WO |
