DEVICE AND METHOD FOR UE REGISTRATION ASSISTED BY ANALYTICS TO SUPPORT INTRA AND INTER NETWORK SLICE LOAD BALANCING

Abstract

The present invention relates to performing mobile network configurations or changes. The invention presents a first device for performing the mobile network configuration or change, and a second device for generating feedback for supporting the mobile network configuration or change. The first device is configured to send a support request to the second device, wherein the support request specifies a reusable or specific feedback type and a target information. The second device is configured to send reusable or specific feedback about the target information in response to the support request. The first device is then configured to determine a configuration or change of the mobile network based on the reusable or specific feedback. The reusable feedback includes a value or set of values of the target information and at least one coordination parameter indicating how the reusable feedback is to be used by multiple second devices.

Claims

1. A device for generating feedback for supporting a mobile network configuration or change, the device comprising: a processor; and a non-transitory computer-readable storage medium coupled to the processor and storing programming instructions for execution by the processor, the programming instructions instruct the processor to: receive a support request from a device for performing the mobile network configuration or change, wherein the support request specifies a reusable or specific feedback type and a target information, and send reusable or specific feedback about the target information in response to the support request, wherein the reusable feedback includes a value or set of values of the target information and at least one coordination parameter indicating how the reusable feedback is to be used by multiple devices performing mobile network configuration or change, and wherein the specific feedback includes a value or set of values of the target information and at least one organization parameter for the set of values.

2. The device according to claim 1, wherein the mobile network configuration or change includes a registration of user equipment (UE) to a network slice (NS) or network slice instance (NSI), or the target information is information about at least one NS or NSI capable of supporting traffic requirements of the UE, based on historical UE behavior.

3. The device according to claim 1, further configured to collect data about a network configuration or change, about at least one network slice (NS), network slice instance (NSI) or user equipment (UE), and generate the reusable or feedback based on the collected data.

4. The device according to claim 3, wherein the data about at least one NS, NSI or UE includes one or more of: past behavior of the UE; NS or NSI configuration information; NS or NSI network load; and a mapping of a plurality of equivalent NSIs.

5. The device according to one of the claim 3, wherein the data about at least one NSI includes one or more of: NS and NSI mapping; NSI topology information; mobile service level (MSL) information mapping to NS and NSI topology; radio access network (RAN) and core network (CN) association; and RAN configuration information associated with the NSI.

6. The device according to one of the claim 3, wherein the data about at least one NS includes one or more of: a network load of the NS or of one or more NSIs of the NS; a network latency or network throughput per type of service; a notification about a quality of service (QoS) non-fulfillment; and QoS experienced by one or more UEs of a given type of service.

7. The device according to one of the claim 3, wherein the data about at least one UE includes one or more of: a session historical behavior of the UE or of one or more other UEs; a type of services or application used in the past by the UE or by one or more other UEs; and a network usage per UE, particularly a volume of traffic or duration of session, per session, per NS, per NSI or per application and per UE.

8. The device according to one of the claim 1, wherein the support request includes at least one NS requested by a UE or at least one default NS for a UE and the UE identification as the target information, and the reusable feedback includes a current load value for at least one NS or NSI or a capability of the NS or NSI to accommodate the UE traffic requirements, particularly based on historical UE behavior.

9. The device according to one of the claim 1, wherein the support request includes at least one NS requested by UE or at least one default NS for UE and the UE identification as the target information, and the specific feedback includes a current load value for multiple NSs or NSIs and a ranking of the NSs or NSIs according to their current load values or a capability of the NS or NSI to accommodate the UE traffic requirements, particularly based on historical UE behavior.

10. A device for configuring or changing a mobile network, the device comprising: a processor; and a non-transitory computer-readable storage medium coupled to the processor and storing programming instructions for execution by the processor, the programming instructions instruct the processor to: send a support request to a device for generating feedback for supporting the configuration or change of the mobile network, wherein the support request specifies a reusable or specific feedback type and a target information, receive a reusable or specific feedback about the target information in response to the support request, and determine a configuration or change of the mobile network based on the reusable or specific feedback, wherein the reusable feedback includes a value or set of values of the target information and at least one coordination parameter indicating how the reusable feedback is to be used by multiple devices performing mobile network configuration or change, and wherein the specific feedback includes a value or set of values of the target information and at least one organization parameter for the set of values.

11. The device according to claim 10, wherein the mobile network configuration or change includes a registration of user equipment, (UE) to a network slice (NS) or network slice instance (NSI), or the target information is information about at least one NS or NSI capable of supporting traffic requirements of the UE, particularly based on historical UE behavior.

12. The device according to claim 10, further configured to subscribe to a service provided by the device for generating the feedback, in order to enable support requests and reception of reusable or feedback.

13. The device according to one of the claim 10, further configured to collect auxiliary information upon finding the reusable or feedback insufficient to determine the at least one mobile network configuration or change, and determine the at least one mobile network configuration or change based further on the collected auxiliary information.

14. A method for generating feedback for supporting a mobile network configuration or change, the method comprising receiving a support request that specifies a reusable or specific feedback type and target information, and sending reusable or specific feedback about the target information in response to the support request, wherein the reusable feedback includes a value or set of values of the target information and at least one coordination parameter indicating how the reusable feedback is to be used by multiple devices performing mobile network configuration or change, and wherein the specific feedback includes a value or set of values of the target information and at least one organization parameter for the set of values.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0061] The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

[0062] FIG. 1 shows a device for generating feedback for supporting a mobile network configuration and/or change, and shows a device for performing a mobile network configuration and/or change, respectively, according to embodiments of the invention.

[0063] FIG. 2 shows a flow diagram of a procedure, in which analytics (i.e., feedback) are used to influence UE registration.

[0064] FIG. 3 shows a flow diagram of a procedure for setting up a data collection for generating analytics, in order to influence UE registration using a specific feedback.

[0065] FIG. 4 shows a flow diagram of a procedure for a NWDAF to influence UE registration with AMF re-allocation using a specific feedback.

[0066] FIG. 5 shows a method according to an embodiment of the invention for generating feedback for supporting a mobile network configuration and/or change.

[0067] FIG. 6 shows a method according to an embodiment of the invention. For performing a mobile network configuration and/or change.

DETAILED DESCRIPTION OF EMBODIMENTS

[0068] FIG. 1 shows a device 100 according to an embodiment of the invention, and a device 110 according to another embodiment of the invention. The devices 100 and 110 form together a system according to an embodiment of the invention. The device 110 is particularly configured to perform a network configuration and/or change, e.g. to perform or support a UE registration to a NS and/or NSI. The device 100 may be, may comprise, or may be configured to implement, an Analytics Function, e.g. a NWDAF. The device 100 is particularly configured to generate feedback (i.e., analytics) for supporting the mobile network configuration and/or change of the device 100. The device 110 may be, may comprise, or may be configured to implement, a NF, NSSF, or AMF.

[0069] The device 100 is configured to send a support request 111 to the device 100, wherein the support request 111 specifies a reusable and/or specific feedback type 112 (“type”) and a target information 113 (“info”). Accordingly, the device 100 is configured to receive the support request 111 from the device 110.

[0070] The device 100 is further configured to send reusable and/or specific feedback 101 about the target information 113 in response to the support request 111 of the device 110. That is, the feedback 101 is generated and sent according to the feedback type 112 in the support request 111, and concerns the target information 113 indicated in the support request 111. Accordingly, the device 110 is configured to receive the reusable and/or specific feedback 101 about the target information 113 in response to its support request 111 from the device 100.

[0071] The device 110 is then configured to determine a configuration and/or change of the mobile network based on the reusable and/or specific feedback 101. The reusable feedback 101 particularly includes a value 102 or set of values 102 (“v”) of the target information 113 and at least one coordination parameter 103 (“cp”) indicating how the reusable feedback is to be used by multiple devices 110 performing mobile network configuration and/or change. The specific feedback 101 particularly includes a value 102 or set of values 102 of the target information 113 and at least one organization parameter 104 (“op”) for the set of values 102.

[0072] As mentioned above, the device 100 may be an Analytics Function. In this case, the Analytics Function 100 may be provided with the following capabilities: [0073] Generate the reusable and/or specific feedback 101. [0074] The reusable feedback 101 may be a type of feedback (analytics) generated by the Analytics Function 100, which can be consumed by any device 110 configured to perform mobile network configuration and/or change, e.g. any NF, application, and/or OAM. In addition to one or more values 102 with regard to the target information 113 (e.g., calculated KPIs), the reusable feedback 101 may also include the coordination parameter 103, which is intended to support that different NFs, application, and/or OAM consume reusable feedback 101 and at the same time avoid triggering simultaneous and potentially unnecessary changes in 5GS network. [0075] The specific feedback 101 may be a type of feedback (analytics) generated by the Analytics Function 100, in order to have a direct impact on and/or to be used exclusively by a specific device 110 configured to perform a configuration and/or change of the network, because the content of the specific feedback 101 is designed to be relevant for the target device 110 (consumer). [0076] Collect data about at least one of: [0077] Past UE historical behavior (e.g., session usage in specific network areas) where the exact granularity of the past data to be collected can be parametrized. [0078] NS and NSI configuration information (such as at least topology, NS RAN configuration such as tracking area, AN and tracking area association). [0079] Actual NS and NSI network load (e.g., active sessions, notification of QoS control, CN latency, etc.). [0080] Mapping of equivalent NSIs either within the same NS (intra NS equivalence) or among different NSs (inter NS equivalence). [0081] Offer one or more services that allow consumers (i.e. devices 110) to register/request and be notified or retrieve the types of feedbacks 101, reusable and/or specific, as defined in this invention.

[0082] As mentioned above, the device 110 may be a NF for performing a configuration and/or change of a mobile network, e.g. NS selection. In this case, the NF 110 may be provided with the following capabilities: [0083] Receive the reusable and/or specific feedback 101 from the device 100 (e.g. the above Analytics Function 100), either via subscribe/notify or via request/response modes communication models. [0084] Use the received feedback 101 (and optionally collect further information, if necessary) to decide on a mobile network configuration and/or change, e.g. on a list of allowed NSs and NSI for NS selection and UE registration.

[0085] FIG. 2 shows a flow diagram of an exemplary procedure, in which analytics (i.e., feedback) are used to influence registration of a UE 200. Entities shown in FIG. 2 are the UE 200, a NF 110 (acting as the device 110 for performing NS selection shown in FIG. 1), an Analytics Function 100 (acting as the device 100 for generating the feedback 101 for supporting the NS selection, as shown in FIG. 1) an Access Network (AN) 201, Operations, Administration and Maintenance (OAM) 202, and other NFs 203. The illustrated steps are described below. [0086] 0. The steps 0a-0c are performed before any UE registration request reaches the NF 110. The steps 0d-0h may be executed periodically by the Analytics Function 100. This periodicity can be parametrized. [0087] 0a. The NF 110 registers, in order to receive the at least one feedback 101 to influence its decision making of selecting the allowed NSs and NSIs for UE 200 registration. [0088] 0b. The Analytics Function 100 triggers a configuration and collection of data (“Sets of Info”) to be used for the generation of the requested feedback 101. [0089] 0c. Optionally, the NF 110, if necessary, triggers a configuration and data collection, in order to support its decision making of selecting the allowed NSs and NSIs for UE 200 registration. [0090] 0d. The Analytics Function 100 receives (if subscribe/notify is used for data collection) or retrieves (in the case of request/response data collection) the data (“Sets of Info”) to assist the generation of the requested feedback 101. [0091] 0e. The Analytics Function 100 checks if the Sets of Info required to generate the subscribed/requested feedback types 112 are available and valid. The availability of a Set of Info refers to the information being under the scope of the Analytics Function 100 (e.g., in a database of the Analytics Function 100), while the validity of a Set of Info refers to the check, if the timestamp of when the information was collected is still within the interval of time configured at Analytics Function 100 that indicates the expiration time of Sets of Info to be used for generating feedback types 112. [0092] 0f. The Analytics Function 100 triggers the collection of the data (Sets of Info) to support the generation of the feedback type for unavailable or invalid Sets of Info. [0093] 0g. The Analytics Function 100 generates the requested feedback type 112. [0094] 0h. The Analytics Function 100 notifies the generated feedback type 112 to the consumers, e.g. the NF 110, of such feedback 101. [0095] 1. This step includes all the steps from the UE 200 sending the registration request to the AN 201, triggering other NFs 203 (if this is the case), until the step where the NF 110 that will actually perform the determination of the allowed list of NS and NSIs for the UE registration request, is activated (e.g., receives the request from other NF 203). [0096] 2. The NF 110 checks if feedback from the Analytics Function 100 to influence the UE registration is available and valid (the same concepts of availability and validity apply for the NF 110 performing NS selection). If feedback is unavailable or invalid: [0097] 2a. The NF 110 requests from the Analytics Function 100 the feedback type 112 for influencing UE Registration. [0098] 2b The Analytics Function 100 executes the steps 0d-0g for generating the requested feedback type 112 for influencing UE Registration. [0099] 2c. The Analytics Function 100 sends the response to the NF 110 with the feedback 101 generated according to the requested feedback type 112. [0100] 3. Optionally, this step can be executed by the NF 110 in parallel to step 2. [0101] 3a. The NF 110 checks if the Sets of Info, in addition to the feedback type 112 from the Analytics Function 100, to influence UE registration are available and valid. [0102] 3b. If the Sets of Info are not available or valid, the NF 110 requests the required information from data sources. [0103] 4. The NF 110 defines the list of allowed NSs and associated NSIs for the UE registration request using the received feedback 101 from the Analytics Function 100, and optionally using the further collected information. [0104] 5. Further steps potentially involving other NFs 203 required for finalizing the UE registration procedure may be executed. [0105] 6. A registration response with the allowed NSs is sent to the UE 200, which requested registration.

[0106] In the following, the above-mentioned data (also referred to as “Sets of Info”), which are to be collected for the Analytics Function 100, in order to generate the feedback 101, are explained in more detail. Three different types of such Sets of Info can in particular be distinguished:

[0107] Set of Info 1 (related to the characteristics of the deployed NSIs, i.e. data about at least one NSI): [0108] The goal is to support the device 100 (e.g. Analytics Function 100), which produces the feedback/analysis on the identification of network load. [0109] Information elements to be considered in this Set of Info are at least: [0110] NS and NSI mapping, e.g., which NSI ID are associated with an S-NSSAI. [0111] NSI topology information (e.g., mapping of which NFs are associated with which regions of the NSI and NS). [0112] MSL information (e.g., tracking area, registration area, etc.) mapping to NS and NSI topology. [0113] RAN and Core association (e.g., which AN is associated with NFs in the core such as AMF). [0114] RAN configuration information associated with an S-NSSAI (e.g., tracking area and AN association). [0115] Equivalent NSI set, i.e. the set of NSIs (NSI IDs), which are able to satisfy the requirement of one S-NSSAI. The equivalent NSI set is defined based on operator policy and actual slice deployment. For instance: [0116] Equivalent NSI in the intra S-NSSAI: multiple NSIs deployed at different parts of PLMN for the same S-NSSAI. [0117] Equivalent NSI in inter S-NSSAIs: NSIs which are able to satisfy the requirements of different S-NSSAIs (e.g., operator can use an eMBB NSI to cover the case of mIoT if they prefer to).

[0118] Set of Info 2 (historical data related to the UE 200 behavior on NS and/or NSI, i.e. data about at least one UE 200): [0119] The goal is to assist analysis whether selected NS/NSIs would be able to support the behavior of the UE 200 in terms of traffic requirements of the UE based on historical information. [0120] Information elements to be considered in this Set of Info are at least: [0121] Type of services/applications used in the past per UE 200 (e.g., URLLC, eMBB, etc.) [0122] Network usage per UE 200 (e.g., information per UE session duration and volume at certain areas of the AN and CN network)

[0123] Set of Info 3 (related to the dynamic load of the NS and NSI, i.e. data about at least one NS): [0124] The goal is to verify the actual traffic conditions for the NSIs×per NSs×per network regions×per type of traffic in the NSIs. [0125] Information elements to be considered in this Set of Info are at least: [0126] Network latency and throughput (AN and CN) per type of service (e.g., calculated based on 5QI or Application ID, etc. . . . ) [0127] Notifications about QoS non-fulfilment [0128] Rejection rates of procedures at NFs associated with UEs connectivity (e.g., registration, session establishment, mobility, etc.)

[0129] In the following is next described, a possible implementation of the solution of the invention with 3GPP 5GS based on the Rel. 15. In particular, in this implementation, the NWDAF in 3GPP is enhanced based on the functions of the above-explained device 100 (particularly the Analytics Function 100). Thus, the NWDAF 100 is configured to generate the feedback 101 for supporting configuration and/or change of the mobile network. Further, NFs performing UE registration can be either NSSFs or AMFs, because according to Rel. 15 these are the entities involved in selecting the S-NSSAIs and NSI IDs which are equivalent to NS and NSI in this invention, respectively. Thus, an NF 110 (NSSF or AMF) is configured to perform the mobile network configuration and/or change based on the feedback 101.

[0130] First will be described the operations of the interfaces of the NWDAF 100 with the extensions to expose the reusable and/or specific feedback 101. Second, the fields (including the embodiment for type 112 and info 113, cp 103, and op 104 defined in this invention and shown in FIG. 1) included in these interfaces will be defined. Third, the Sets of Info used for the generation of the feedback 101 for assisting UE registration will be defined. Finally, one specific example for the procedure of UE registration with AMF re-allocation will be provided with respect to FIG. 3 and FIG. 4.

[0131] NWDAF Services for consuming reusable and/or specific feedback 101 may be implemented as shown in the following Table 1:

TABLE-US-00001 TABLE 1 NWDAF Services for consuming reusable and/or specific feedback 101 Service Name Operation Parameters of message Nnwdaf_AnalyticsInfo Request Feedback Category (FC) Feedback Type (FT) Feedback Target Data Structure associated with Feedback Type (FTDS) Filters** Feedback Output ID** Feedback Type (FT) Feedback Target Data Structure Values (FTDS) Timestamp of output generation (TS) Nnwdaf_EventSubscription Subscribe Feedback Category (FC) Feedback Type (FT) Feedback Target Data Structure associated with Feedback Type (FTDS) Filters** Notify Feedback Output ID** Feedback Type (FT) Feedback Target Data Structure Values (FTDS) Timestamp of output generation (TS) **Fields already defined in prior art.

[0132] New fields defined in the NWDAF interfaces to enable the UE registration and exposure of the defined feedback types 112 are designed as follows. [0133] Feedback Category: the general description of the use cases associated with the desired feedback 101. It may be composed of the following fields: [0134] Consumers Type (i.e., NFs, AFs, OAM); [0135] Influenced Procedure, i.e. influenced mobile network configuration and/or change (e.g., UE registration, NF Selection, Slice Adjustment); [0136] (Optional) Influenced Parameters (e.g., list of allowed network slices, list of NFs) [0137] Feedback Type: specifies the feedback type 112, i.e. whether the desired feedback 101 is: [0138] Reusable feedback 101 (i.e., the output of NWDAF 100 is an association of values 102 and/or set of values 102 to a desired target information 113 and at least one coordination parameter 104), or [0139] Specific feedback 101 (i.e., the output of NWDAF 100 is a specific value 102 or set of values 102 of the target information 113 and at least one organization parameter 104; the feedback 101 is to be consumed for supporting the decision making of a specific entity 110 e.g., NF, AF, OAM, or specific procedure, i.e. mobile network configuration and/or change). [0140] Feedback Target Data Structure (FTDS): this field specifies the target object of the desired feedback 101 and a format of the target object depends on the feedback type 112. [0141] Reusable Target Data Structure (RTDS): it is composed of [0142] a) information about the target object (or about an array of target objects) that needs to be analyzed by NWDAF 100. The target object may be part of type 112, for instance, the feedback type 112 may include a feedback type ID (which indicates reusable and/or specific feedback type 101) and the target object; and [0143] b) the target information 113 that needs to be associated with the target object. An example of a target object is: “per network slice, per application, per TA”, and an example of target information 113 is “network load, UE experience satisfaction”. The target object can be a tree or a nested list of objects, and the target information 113 can also be a list of information; and [0144] c) usage coordination parameter 103 which indicates how multiple consumers (devices 110) of the reusable feedback 101 should use the received feedback 101.

[0145] One possible embodiment for RTDS is: [0146] Data structure definition: [0147] Reusable Target Data Structure=Array([info_type_tree, info_target], usage_coordination), where: [0148] Info_type_tree=(Root_level, (leaf_level)) [0149] Root_level=Per UE|Per UE Application|Per NSI|Per S-NSSAI|Per Groups of UE|Per NF|Per DNN|Per PDU Session|etc. [0150] leaf_level=(Root_level, (leaf_level))|Empty [0151] info_target=target (target_name, target_value_type, granularity) [0152] target=(target_name, target_value_type, granularity)|Empty [0153] granularity=indicates the characteristics of the data used for generating the feedback (e.g., sample interval) [0154] usage_coordination=for instance, NWDAF can indicate the only consumer that should use the reusable feedback, and another consumer of the same feedback will discard the information. [0155] Specific Target Data Structure: is composed of: [0156] d) target object (e.g. as part of feedback type 112); and [0157] e) target information 113, both as defined in the Reusable Target Data Structure, and at least one organization parameter 114. [0158] f) collection definition (may be part of the organization parameter 114), which describes how the values 102 of the target information 113 associated with the target object should be organized, for instance, if as an ordered list, or a queue, or a binary tree, etc. [0159] g) criteria definition (may be part of the organization parameter 114) to be used to organize the values 102 into the collection, e.g., ascendant, descendent, high priority first, low priority first, etc.

[0160] One possible embodiment for the STDS is: [0161] md Data structure definition: [0162] Specific Target Data Structure=Array([collection_type, criteria_type, (Info_type_tree, info_target]]), where: [0163] Collection_type=ordered List|queue|stack|decision_tree, . . . [0164] Criteria_type (Optional)=ascendant|descendent| . . . [0165] Feedback Target Data Structure Values, which contains values associated with either the requested RTDS or STDS data structures. [0166] Timestamp of feedback generation, which allows consumers of the feedback 101 to decide until when the received information can be used. For instance, an NF 110 can deem a received notification from NWDAF 100 for a given feedback 101 as not valid based on this timestamp.

[0167] Examples of the Sets of Info for supporting the NWDAF 100 in obtaining the information (for supporting the smarter 3GPP UE Registration procedure) for generating specific feedback 101 are given in the following.

[0168] The information listed in the below Table 2 indicates measurements that need to be collected by NWDAF 100, in order to identify which are the predominant Applications used by the UE 200 as well as, the traffic load and the periodicity of such load that UE 200 imposes in the different areas of the network. The measurements presented in Table are pre-processed information based on the data collected from UE sessions at Service Management Function (SMF) and such data is described in Table 3. One possibility is to assume that the historical data about UE sessions (i.e., content of Table 3) is stored in Unified Data Repository (UDR) 300 (see FIG. 3) and that the NWDAF 100 collects the pre-processed data presented in Table 2. Another possible embodiment is to have the historical information about UE sessions stored at the OAM 202 and the NWDAF 100 collects this information from OAM 202.

TABLE-US-00002 TABLE 2 Input data to be collected by the NWDAF 100 related to UE historical data Information (all based on historical UE behavior) Presence Source Description Total number Sessions M UDR/OAM Combining this information it is per Application, per AN, possible to identify which kind of per S-NSSAI applications are predominant in Number of Sessions per UDR/OAM UE sessions (established in the Application, per AN, per past) S-NSSAI Number 5QI Flows per M UDR/OAM Support the comparison of current Application, per AN, per 5QIs Flows in the network regions S-NSSAI with the past 5QIs used for the Applications of the UE Volume of traffic per M UDR/OAM Identify regions in the network Application, per AN, per with most volume of traffic based S-NSSAI on UE historical usage Interval of time per M UDR/OAM Identify regions in the network Application, per AN, per with most duration of traffic based S-NSSAI on UE historical usage

TABLE-US-00003 TABLE 3 Information about each UE session to be used for generating UE historical data Information Presence Source Description UE ID M SMF Identifies the UE that established the session S-NSSAI SMF Identifies the network slice of the established session Session ID M SMF Identifies the established session NG-RAN ID M SMF Identifies the NG-RAN transmitting traffic associated with an established session Application ID M SMF Identifies the Application ID associated with an established session Data Network Name M SMF Identifies the data network associated (DNN)ID with the established session Volume M SMF Indicates the volume of traffic transmitted in the established session for a given application, DNN, and in a given AN Duration M SMF Indicates the duration of sessions established for a given application, DNN, and in a given AN

[0169] In order to be able to provide feedback 101 based on network regions, the NWDAF 100 shall collect from the OAM 202 the data related to the NS configuration, as described in the Table 4.

TABLE-US-00004 TABLE 4 Input data to be collected by NWDAF 100 related to NS configuration Information Presence Source Description Mapping AN x TA x M OAM Identify RAN regions S-NSSAI Mapping S-NSSAIs X NSI M OAM Identify RAN regions associated IDs with network slices and network slice Instances Equivalent NSIs M OAM Identify equivalent NSIs (intra and inter S-NSSAIs)

[0170] The NWDAF 100 may also use, as input for generating the feedback 101 for supporting NS selection during UE registration, the information about the network load. The characterization of network load may be done based on the parameters listed in the below Table 5. The parameters 1-5 identify the load at AN 201 in terms of combining information about: predominant traffic, QoS fulfilment, ratio of nominal versus actual throughput, where nominal is the value configured by OAM 202 at NS deployment. The parameters 6 and 7 determine how well the CN is performing in terms of latency and throughput. The parameters 8 and 9 determine if UPFs are overloaded. Finally, parameter 10 is related to the service experience and describes how many UE's service experience have been satisfied.

TABLE-US-00005 TABLE 5 Input data to be collected by the NWDAF 100 related to NS load ID Information Presence Source Description 1 Number Active flows per AN, per M OAM Combining S-NSSAI both 2 Number Active flow per 5QI per M OAM information it AN, per S-NSSAI is possible to identify which 5QI flows are predominant per AN 3 Number QoS Notification M AMF/SMF/OAM Identify per Control Messages per AN, per AN the ratio S-NSSAI between active 5QI with Guaranteed Flow Bit Rate (GFBR) and non fulfilment of QoS at AN 4 Throughput UL/DL per AN per O OAM Identify if the 5QI ratio between 5 Nominal Throughput UL/DL per O OAM expected and AN per 5QI actual throughput at AN 6 PDB and Bit rate per 5QI M OAM Identify if the 7 Latency and throughput per 5QI, M OAM ratio between per NSI path expected and actual latency and throughput in CN 8 Ratio between successful and O OAM Identify the failed session establishment per chances of S-NSSAI, per NSI IDs congestion of 9 Ratio between successful and O OAM the UPF. failed mobility management per S-NSSAI, per NSI IDs 10 UE's service experience per O NWDAF Identify how Application, per S-NSSAI, per many UE's NSI IDs service experience of applications per slice is being satisfied

[0171] An implementation for 3GPP of UE Registration procedure based on specific feedback 101 is now described. Notably, there are different possible implementations for the solution proposed in this invention. One possible implementation for the UE Registration procedure in accordance with 3GPP 5GS Rel. 15 defined in TS 23.502 is disclosed and considers the following options: [0172] Specific feedback type 112 is used to influence the UE 200 registration [0173] NSSF 110 is the NF performing NS selection, which means the procedure for UE Registration with AMF Reallocation originally described in Section 4.2.2.2.3, Figure 4.2.2.2.3-1 of 3GPP TS 23.502 is adapted to support the solution in this invention. [0174] The NSSF 110 will not collect further information (i.e. will not execute step 3 of the proposed method) for the decision-making of the allowed list of NS and NSIs to be associated with the UE requesting registration.

[0175] The implementations of the steps 0, as described in FIG. 2, are illustrated in the embodiment for data collection on 3GPP 5GS as shown in FIG. 3. The implementations of the steps 1-6, as described in FIG. 2, are illustrated in FIG. 4 and represent the actual procedure for UE registration with AMF re-allocation according to 3GPP Rel. 15. The NSSF 110 performs the mobile network modification and/or change (taking the function of device 110 shown in FIG. 1), and the NWDAF 100 generates the feedback 101 for supporting the modification and/or change of the mobile network (taking the function of device 100 shown in FIG. 1).

[0176] The steps for NSSF 110 subscription to receive specific feedback from the NWDAF 100, as well as the data collection setup performed by the NWDAF 100 to retrieve the data sets described, in order to generate the requested specific feedback 101, are as follows. Notably, step 3 to 7 are executed periodically by NWDAF 100, and the periodicity can be configured. [0177] 1. The NSSF 110 invokes Nnwdaf_EventSubcription Subcription( ) service from NWDAF 100 indicating the specific feedback 101 it requires in order to consider the NWDAF feedback 101 during UE registration. [0178] 2. The NWDAF 100 checks if there is the need to setup data collection for supporting the requested specific feedback 101. If required, the NWDAF 110 will trigger the data collection set up for Sets of Info as shown above in Table 2, Table 4 and Table 5. [0179] 2.1 The NWDAF 110 subscribes via Nudm_DataManagement subscribe( ) to receive information about historical session from UEs 200 from UDR 300. [0180] 2.2 The UDR 300 setups the notification to NWDAF 100 about the requested historical information. [0181] 2.3 The NWDAF 100 subscribes via Namf_EventExposure subscribe( ) to receive information about QoS Notification Control events from AMF 301. [0182] 2.4 The AMF 301 setups the notification to NWDAF 100 about the requested QoS Notification control. It is up to configuration at AMF 301 to define whether every event will be propagated to the NWDAF 100, or if pre-processing will be applied to the QoS notification messages and such pre-processed information will be sent to NWDAF 100. [0183] 2.5, 2.6, 2.7 [0184] The NWDAF 100 subscribes to OAM 202 services to collect information, respectively, from Configuration management services, performance management services, and fault management services. [0185] 2.8. OAM 202 setups the notification to NWDAF 100 about the requested information. [0186] 3. (a, b, c, d) [0187] Once the data collection for the generation of the specific feedback 101 is setup, the NWDAF 100 receives from the data sources the requested information. [0188] 4. Each data source might have its own cycle of notification, and information might not reach the NWDAF 100 at the same time. Therefore, the NWDAF 100 checks if all information required to generate the requested specific feedback 101 is available (i.e., if the NWDAF 100 received the information from the data source) and valid (i.e., this information is not expired). [0189] 5. If information required to generate requested specific feedback 101 is not available and/or not valid, the NWDAF 100 triggers the collection of the missing information. [0190] 6. The NWDAF 100 generates the requested specific feedback 101. [0191] 7. The NWDAF 100 exposes the requested specific feedback 101 for the subscribers of such feedback 101, in this case the NSSF 110.

[0192] FIG. 4 illustrates the steps in the procedure for UE registration with AMF re-allocation that are included in the procedure or modified by the solution of the invention. The Steps 1 to 5 in FIG. 4 are exactly the same as in the current (conventional) procedure described in Section 4.2.2.2.3 of 3GPP TS 23.502. The steps 6 to 11 are the modifications introduced by this invention to enable the UE registration with AMF re-allocation to be influenced by the specific feedback. Steps 12 and further are again exactly the same as the ones existing in the current procedure. [0193] 1. The UE 200 sends the registration request to the AN 201. [0194] 2. The AN 201 performs AMF selection. [0195] 3. The AN 201 sends a UE registration request to an Initial AMF 401. [0196] 4. Steps 2 and 3 defined in Figure 4.2.2.2.3-1 in TS 23.502 for the Registration with AMF re-allocation procedure are executed. [0197] 5. The Initial AMF 401 invokes Nnssf_NSSFSelection_Get( ) operation to receive a list of allowed S-NSSAIs, NSI IDs, and a candidate list of AMFs, among other information. [0198] 6. The NSSF 110 checks, if the analytics (i.e., feedback) for supporting slice selection for UE registration are available (i.e., if the NSSF 110 received a notification with such analytics from the NWDAF 100) and if this analytics is still valid (i.e., if such analytics did not expire—the interval of time from receiving the analytics from NWDAF 100 up to the moment that it is actually needed by the NF is not expired). If analytics is available and valid, the NSSF 110 executes step 11, otherwise steps 7-10 are executed. [0199] 7. The NSSF 110 identifies the need to request the specific feedback 101 for Influencing UE registration. The NSSF 110 invokes Nnwdaf_AnalyticsInfo Request( ) operation from NWDAF 100 including in this support request 111 the Feedback Type, the Specific target Data Structure, the Feedback Category, and includes the filters the information about the UE 200 that is requesting the registration. This information includes the S-NSSAIs related to the UE 200 subscription or requested S-NSSAIs (if included in the UE registration and received by NSSF 110). [0200] 8. The NWDAF 100 receives the request 111, applies the filters of the requested specific feedback 101, which in this case is the identification of the UE requesting registration and the set of requested or default S-NSSAIs associated with such UE 200. [0201] 9. The NWDAF 100 calculates the requested feedback 101. [0202] 10. The NWDAF 100 sends the Nnwdaf_AnalyticsInfo Request response( ) with the generated feedback 101 including, including the fields Feedback Type (FT), Specific Target Data Structure (STDS) values, and the timestamp of the feedback generation (TS). The STDS is composed of an ordered list of S-NSSAIs and associated NSI IDs with a normalized value between 0-1, where 0 is the lowest and 1 the highest probability of a S-NSSAIs and NSI IDs to be able to accommodate the traffic of the UE requesting registration. [0203] 11. The NSSF 110 uses the list of S-NSSAIs and NSI IDs with their probability values, and optionally further operator's policy to select the allowed S-NSSAIs and NSI IDs for the UE 200, as well as the list of AMFs that can support the UE registration on the allowed S-NSSAIs and NSI IDs. [0204] 12. The NSSF 110 sends the Nnssf_NSSFSelection_Get response( ) to the initial AMF 401. [0205] 13. Steps 5 to 8 defined in Figure 4.2.2.2.3-1 in TS 23.502 for the Registration with AMF re-allocation procedure are executed.

[0206] Once the NSSF 110 defined the list of allowed S-NSSAIs and NSI IDs, it also defines the AMFs that can finalize the UE registration and later handle the UE requests associated with the allowed S-NSSAIs. The NSSF 110 answers, in Step 12, the Initial AMF request with the list of AMFs, allowed S-NSSAIs and NSI IDs, and UE registration procedure proceeds from step 5 in Figure 4.2.2.2.3-1: Registration with AMF re-allocation procedure in TS 23.502.

[0207] FIG. 5 shows a method according to an embodiment of the invention. The method is for generating feedback 101 for supporting a mobile network configuration and/or change. Accordingly, the method 500 may be carried out by the device 100 shown in and explained with respect to FIG. 1. The method 500 comprises a step 501 of receiving a support request 111, wherein the support request 111 specifies a reusable and/or specific feedback type 112 and a target information 113. The method 500 further comprises a step 502 of sending reusable and/or specific feedback 101 about the target information 113 in response to the support request 111.

[0208] In the above step 502, according to box 503, the reusable feedback 101 includes a value 102 or set of values 102 of the target information 113 and at least one coordination parameter 103 indicating how the reusable feedback 101 is to be used by multiple devices 110 performing mobile network configuration and/or change. Further, the specific feedback 101 includes a value 102 or set of values 102 of the target information 113 and at least one organization parameter 104 for the set of values 102.

[0209] FIG. 6 shows a method 600 according to an embodiment of the invention for configuring and/or changing a mobile network. Accordingly, the method 600 may be carried out by the device 110 shown in and explained with respect to FIG. 1. The method 600 comprises a step 601 of sending a support request 111, wherein the support request 111 specifies a reusable and/or specific feedback type 112 and a target information 113. Further, the method 600 comprises a step 602 of receiving a reusable and/or specific feedback 101 about the target information 113 in response to the support request 111. The method 600 also comprises a step 603 of determining at least one mobile network configuration and/or change based on the reusable and/or specific feedback 101.

[0210] In the above steps 602 and 603, according to box 604, the reusable feedback 101 includes a value 102 or set of values 102 of the target information 113 and at least one coordination parameter 103 indicating how the reusable feedback 101 is to be used by multiple devices 110 performing mobile network configuration and/or change. Further, the specific feedback 101 includes a value 102 or set of values 102 of the target information 113 and at least one organization parameter 104 for the set of values 102.

[0211] The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.