Patent Description:
In recent communication systems, network slicing is a key technology to support very diverse range of services with very different performance requirements on a common physical infrastructure. It allows multiple virtual networks to be created on top of a common shared physical infrastructure. The virtual networks are then customized to meet the specific needs of applications, services, devices, customers or operators. Network slices may differ for supported features and network functions optimizations. On that account, in <CIT> an exemplary network slice selection policy mechanism is disclosed which enables the generation of automatic network slice selection processes in a <NUM> network system. Herein, the above-mentioned mechanism particularly stipulates to create specific network slice section policy (NSSP) rules by firstly transmitting existing application identifiers corresponding to an application profile as well as application providers to a processor and then determining for each of the aforementioned application identifiers one ore more network slice identifiers that are to be connected with a respective application. In addition, also in<NPL>), a number of different network slice selection strategies are discussed, including an Application Function (AF) based mechanism by which, similar to <CIT>, a network slice selection policy is created and/or updated by initially transmitting App-dependent information (App-identifier, provider) from the AF to the Network Exposure Function (NEF) and then determining and updating existing policies by transmitting the new App-Information to the Unified Data Management (UDR).

To solve the above-mentioned problem, the invention according to the independent claims is suggested. Dependent claims describe favorable embodiments of the invention. Generally, embodiments of the present disclosure relate to a method for terminal device influenced network slice selection and the corresponding communication devices.

Other features and advantages of the embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of embodiments of the disclosure.

Embodiments of the disclosure are presented in the sense of examples and their advantages are explained in greater detail below, with reference to the accompanying drawings, where.

Throughout the figures, same or similar reference numbers indicate same or similar elements.

The subject matter described herein will now be discussed with reference to several example embodiments. It should be understood these embodiments are discussed only for the purpose of enabling those skilled persons in the art to better understand and thus implement the subject matter described herein, rather than suggesting any limitations on the scope of the subject matter.

It will be further understood that the terms "comprises," "comprising," "includes" and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.

For example, two functions or acts shown in succession may in fact be executed concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

As used herein, the term "communication network" refers to a network following any suitable communication standards, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (<NUM>), the second generation (<NUM>), <NUM>, <NUM>, the third generation (<NUM>), the fourth generation (<NUM>), <NUM>, the future fifth generation (<NUM>) communication protocols, and/or any other protocols either currently known or to be developed in the future.

Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system. For the purpose of illustrations, embodiments of the present disclosure will be described with reference to <NUM> communication system.

The term "network device" used herein includes, but not limited to, a base station (BS), a gateway, a registration management entity, and other suitable device in a communication system. The term "base station" or "BS" represents a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), a NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, a low power node such as a femto, a pico, and so forth.

The term "terminal device" used herein includes, but not limited to, "user equipment (UE)" and other suitable end device capable of communicating with the network device. By way of example, the "terminal device" may refer to a terminal, a Mobile Terminal (MT), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT).

The term "circuitry" used herein may refer to one or more or all of the following:.

As discussed above, network slices may differ for supported features and network functions optimizations. Technical specifications of the <NUM>rd generation partnership project (3GPP) define the network slicing solution in the fifth generation (<NUM>) network already. Identification and selection of a Network Slice with the S-NSSAI (Single Network Slice Selection Assistance Information) and the NSSAI (Network Slice Selection Assistance Information) has been proposed already. Table <NUM> below shows <NUM> Slice/Service type (SST) supported so far.

With the introduction of network slicing technology in <NUM> network, a key issue for application domain is how an application can ensure a user or device with multiple <NUM> core (5GC) network slices and multiple application services to utilize the appropriate 5GC network slice for each application service and prevent inappropriate services been used from the incorrect 5GC network slice.

<FIG> illustrates a schematic diagram of a communication system <NUM>. As shown in <FIG>, the communication system <NUM> may comprise a terminal device <NUM>, an Application Server/ Application Function <NUM>, a Network Exposure Function (NEF) <NUM>, a Unified Data Management (UDM)/ Unified Data Repository (UDR) <NUM>, a policy control function (PCF) <NUM>, an Access and Mobility Management Function (AMF) <NUM>. The Application server may be a IP Multimedai Subsystem (IMS). The Application server may also be the AS/AF of internet provider, for example, facebook, youtube, wechat and the like. The terminal device <NUM> may also comprise the Application like IMS service module <NUM> and the UE Route Selection Policy(URSP)/Network Slice Selection Policy (NSSP) module <NUM>. In some embodiments, the URSP may include NSSP. The URSP may also include the traffic routing rule in one network slices. It should be noted that the devices shown in <FIG> are only examples. The communication system <NUM> may also comprise other devices. The IMS-AS <NUM> may transmit a request for an application profile to the NEF <NUM>. The NEF <NUM> may transmit a request for updating the profile to the UDM <NUM>. The UDM <NUM> may create the NSSP for the application and notify the PCF <NUM> about the created NSSP. The PCF <NUM> may transmit the created NSSP to the terminal device <NUM> via the AMF <NUM>.

However, how to determine the affected terminal devices is one key issue to prevent its commercial utilization. For the scenario that no terminal devices are included in the request between AF and 5GC, i.e., the request implicitly affects all terminal devices associated (for example, based on subscription) with the identified application provider, it requires the 5GC to maintain the mapping between the terminal devices and application provider. However, except some operator owned applications, the 5GC has no knowledge about the applications running on the terminal devices. How to setup such mapping is a technical question.

The scenario of including the external identity of a single terminal device (for example, Mobile Subscriber ISDN Number (MSISDN)), or the external identities of multiple terminal devices in the request between the AF and 5GC is also infeasible since the number of users/devices of an application is too huge in general to be included in one request message. Moreover, because dynamic change of the application on the terminal device (for example, install, uninstall, update), how to dynamic update its routing policy should also be considered.

According to embodiments of the present disclosure, a new terminal device influenced network slice selection is proposed. The NRF updates the application profile for the terminal device based on the change of the applications on the terminal device. The NRF may notify the PCF about the application profile and the PCF generates the route policy for the application on the terminal device. In this way, problems regarding the affected terminal devices of application influenced network slice selection are solved. Further, embodiments of the present disclosure can also help on routing for applications.

<FIG> illustrates a schematic diagram of a communication system <NUM> in which embodiments of the present disclosure can be implemented. As shown in <FIG>, the communication system <NUM> may comprise a NRF <NUM>, a terminal device <NUM>, a PCF <NUM> and an Application Function (AF) <NUM>. As shown in <FIG>, there may be some applications <NUM>, <NUM> and <NUM>. The application can be installed on the terminal device <NUM>. The number of applications shown in <FIG> is only an example, not a limitation. It should be noted that the communication system <NUM> may comprise an Application Server instead of the AF.

It should be noted that the NRF <NUM>, the PCF <NUM> and the Application Function <NUM> may be implemented at any suitable devices, entities or modules. It should be noted that the devices, modules, or entities shown in <FIG> are only examples. It should be understood that the communication system <NUM> may also comprise other elements which are omitted for the purpose of clarity. It is to be understood that the numbers of devices, modules, or entities shown in <FIG> are given for the purpose of illustration without suggesting any limitations.

Communications in the communication system <NUM> may be implemented according to any proper communication protocol(s), including, but not limited to, cellular communication protocols of the first generation (<NUM>), the second generation (<NUM>), the third generation (<NUM>), the fourth generation (<NUM>) and the fifth generation (<NUM>) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) <NUM> and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, including but not limited to: Code Divided Multiple Address (CDMA), Frequency Divided Multiple Address (FDMA), Time Divided Multiple Address (TDMA), Frequency Divided Duplexer (FDD), Time Divided Duplexer (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Divided Multiple Access (OFDMA) and/or any other technologies currently known or to be developed in the future.

<FIG> illustrates a schematic diagram of interactions <NUM> in accordance with embodiments of the present disclosure. The interactions <NUM> may be implemented at any suitable devices. Only for the purpose of illustrations, the interactions <NUM> are described to be implemented among the NRF <NUM>, the terminal device <NUM>, the PCF <NUM> and the Application Function <NUM>.

The NRF <NUM> obtains first information indicating the change in the application related to the terminal device <NUM>. In some embodiments, the terminal device <NUM> may transmit <NUM> the first information to the NRF <NUM>. Alternatively, the first information may be transmitted by other entity, for example, the application provider.

In an example embodiment, the first information may comprise a request for registering the application on the terminal device. The request may be transmitted to the NRF <NUM> to register the application (for example, the application <NUM>) on the terminal device <NUM>. The first information may comprise the identity of the terminal device <NUM> which uniquely indicate the terminal device <NUM> in the network. The first information may also comprise the identity of the application <NUM> which uniquely indicate the application <NUM>. Alternatively or in addition, the first information may comprise additional information. For example, the first information may comprise one or more of: the traffic type of the application <NUM>, the application provider, the application user indicator, the location of the terminal device <NUM> or software version on the terminal device <NUM>.

In other example embodiment, the first information may comprise a request for deregistering the application on the terminal device <NUM>. The request may be transmitted to the NRF <NUM> to deregister the application (for example, the application <NUM>) on the terminal device <NUM>. The first information may comprise the identity of the terminal device <NUM> which uniquely indicate the terminal device <NUM> in the network. The first information may also comprise the identity of the application <NUM> which uniquely indicate the application <NUM>. Alternatively or in addition, the first information may comprise additional information. For example, the first information may comprise one or more of: the traffic type of the application, the application provider, the application user indicator, the location of the terminal device <NUM> or software version on the terminal device <NUM>.

In another example embodiment, the first information may comprise a request for updating the application on the terminal device <NUM>. The request may be transmitted to the NRF <NUM> to update the application (for example, the application <NUM>) on the terminal device <NUM>. The first information may comprise the identity of the terminal device <NUM> which uniquely indicate the terminal device <NUM> in the network. The first information may also comprise the identity of the application <NUM> which uniquely indicate the application <NUM>. Alternatively or in addition, the first information may comprise additional information. For example, the first information may comprise one or more of: the traffic type of the application, the application provider, the application user indicator, the location of the terminal device <NUM> or software version on the terminal device <NUM>.

In some embodiments, there may be a new interface between the NRF <NUM> and the terminal device <NUM> to support to transmit the first information. In some embodiment, there may be two ways to implement above new interface between the NRF <NUM> and the terminal device <NUM>. The first one is to connect NRF <NUM> and UE Application through NEF (i.e. Terminal Device-NEF-NRF) and another one is through AMF (i.e. Terminal Device -AMF-NRF). In some embodiments, conventional NRF procedures, such as NF service Registration, NF service update, and NF service deregistration are reused for the registration, update and deregistration of application running on the terminal device <NUM>. The transmission of the first information may be triggered when an application is installed/update/uninstalled on the terminal device <NUM>.

The AF <NUM> generates <NUM> the provision request. The provision request is for AF to influence application route selection including network slice selection. Table <NUM> below shows the provision request. It should be noted that Table <NUM> is only an example.

The provision request comprises the identity of the application which uniquely indicates the application. The AF <NUM> may generate a route operation and a condition for applying the route operation. For example, the provision request may also comprise Application Route Selection Policy defined by the AF <NUM>. This Application Route Selection Policy is a set of traffic route rules which composed by rule criteria and rule operations. The rule operation may indicate the route operation when the rule criteria are met. The operation may be either implicit with the QoS profile (for example, QoS requirement like Delay < <NUM>) or explicit to nominate the network slice ID. In the case that the application user indicator is provided in application register to the NRF <NUM>, the criteria of Application Route Selection Policy can also include the application user indicator, which enables the AF <NUM> instruct network to provide different service to different application user.

The condition of applying related operation may be one or more of: the location of the terminal device, time, traffic type (for example, video, voice, message), a Flow ID, i.e. any information that can be used to differentiate one data flow, or Network conditions (for example, network (slice) working load, Network usage, charging rate). Table <NUM> shows an example of the policy. It should be noted that the contents in Table <NUM> are only examples.

The AF <NUM> transmits <NUM> the provision request to the NRF <NUM>. In some embodiments, the AF <NUM> may generate and transmit the prevision request before the terminal device <NUM> transmits the first information to the NRF210. Alternatively, the AF <NUM> may generate and transmit the prevision request after the terminal device <NUM> transmits the first information to the NRF <NUM>.

The NRF <NUM> updates <NUM> a profile for applications on the terminal device <NUM> based on the first information. In some embodiments, the NRF <NUM> may determine whether the profile exists. If the profile does not exist, the NRF <NUM> may generate the profile. If the profile exists, the NRF <NUM> may update the profile based on the first information. Table <NUM> below shows the profile for the applications on the terminal device <NUM>. It should be noted that the contents in Table <NUM> are only examples, not limitations.

The profile enables the network to track the Application status on specific terminal devices. In this way, it helps the network to provide accurate and efficient service controlling base on Application specific needs. In some embodiments, the NRF <NUM> may store the profile locally. Alternatively or in addition, the NRF <NUM> may store the profile in a database.

The NRF <NUM> generates <NUM> the second information based on the profile. In some embodiments, the NRF <NUM> may check <NUM> whether the provision request is received from the AF <NUM>. If the provision request is received, the NRF <NUM> may generate the second information based on the profile and the proviso request. Once provision request is received from the AF <NUM>, the NRF <NUM> may check the profile of the terminal device <NUM> to determine whether the application indicated in the provision request exist in the profile. If the application doesn't exist which means the application has not registered from the terminal device <NUM>, the NRF <NUM> may store the provision request.

Alternatively, if the application exists in the profile of the terminal device <NUM>, the NRF <NUM> may generate the second information based on the profile and the provision request. For example, the second information may comprise the profile and the Application Route Selection Policy (for example, Table <NUM>). In other embodiments, if the provision request shows "Traffic type = Message" will not be notified to PCF, the NRF <NUM> may not generate the second information if the traffic type of the application is message.

If the provision request is not received, the NRF <NUM> may generate the second information based on the profile and the subscription of the PCF <NUM>. The subscription may indicate the applications that the PCF <NUM> subscribes. The NRF <NUM> transmits <NUM> the second information to the PCF <NUM>.

The PCF <NUM> generates <NUM> the route policy for the terminal device <NUM> based on the second information. The route policy may be a UE Route Selection Policy (URSP). In some embodiments, the PCF <NUM> may generate the route policy for each application on the terminal device <NUM>. Alternatively, the PCF <NUM> may generate the route policy for a specific traffic of one application on the terminal device <NUM>. The PCF <NUM> applies <NUM> the route policy to the network <NUM>. In this way, the route policy may be generated with the consideration of the applications on the terminal devices.

<FIG> illustrates a flow chart of a method <NUM> in accordance with embodiments of the present disclosure. The method <NUM> may be implemented at any suitable devices. Only for the purpose of illustrations, the method <NUM> is described to be implemented at the NRF <NUM>.

At block <NUM>, the NRF <NUM> receives the first information indicating the change in the application related to the terminal device <NUM>. In some embodiments, the terminal device <NUM> may transmit the first information to the NRF <NUM>. Alternatively, the first information may be transmitted by other entity, for example, the application provider.

In an example embodiment, the first information may comprise a request for registering the application on the terminal device <NUM>. The request may be transmitted to the NRF <NUM> to register the application (for example, the application <NUM>) on the terminal device <NUM>. The first information may comprise the identity of the terminal device <NUM> which uniquely indicate the terminal device <NUM> in the network. The first information may also comprise the identity of the application <NUM> which uniquely indicate the application <NUM>. Alternatively or in addition, the first information may comprise additional information. For example, the first information may comprise one or more of: the traffic type of the application <NUM>, the application provider, the application user indicator, the location of the terminal device <NUM> or software version on the terminal device <NUM>.

In a further example embodiment, the first information may comprise a request for updating the application on the terminal device <NUM>. The request may be transmitted to the NRF <NUM> to update the application (for example, the application <NUM>) on the terminal device <NUM>. The first information may comprise the identity of the terminal device <NUM> which uniquely indicate the terminal device <NUM> in the network. The first information may also comprise the identity of the application <NUM> which uniquely indicate the application <NUM>. Alternatively or in addition, the first information may comprise additional information. For example, the first information may comprise one or more of: the traffic type of the application, the application provider, the application user indicator, the location of the terminal device <NUM> or software version on the terminal device <NUM>.

At block <NUM>, the NRF <NUM> updates the profile for applications on the terminal device <NUM> based on the first information. In some embodiments, the NRF <NUM> may determine whether the profile exists. If the profile does not exist, the NRF <NUM> may generate the profile. If the profile exists, the NRF <NUM> may update the profile based on the first information.

At block <NUM>, the NRF <NUM> generates the second information based on the profile. In some embodiments, the NRF <NUM> may check <NUM> whether the provision request is received from the AF <NUM>. If the provision request is received, the NRF <NUM> may generate the second information based on the profile and the proviso request. Once provision request is received from the AF <NUM>, the NRF <NUM> may check the profile of the terminal device <NUM> to determine whether the application indicated in the provision request exist in the profile. If the application doesn't exist which means the application has not registered from the terminal device <NUM>, the NRF <NUM> may store the provision request.

Alternatively, if the application exists in the profile of the terminal device <NUM>, the NRF <NUM> may generate the second information based on the profile and the proviso request. For example, the second information may comprise the profile and the Application Route Selection Policy (for example, Table <NUM>). In other embodiments, if the provision request shows "Traffic type = Message" will not be notified to PCF, the NRF <NUM> may not generate the second information if the traffic type of the application is message.

If the provision request is not received, the NRF <NUM> may generate the second information based on the profile and the subscription of the PCF <NUM>. The subscription may indicate the applications that the PCF <NUM> subscribes.

At block <NUM>, the NRF <NUM> transmits the second information to the PCF <NUM>. The route policy specifies route selection for the applications on the terminal device <NUM>. In this way, the route policy may be generated with the consideration of the applications on the terminal devices.

<FIG> illustrates a flow chart of a method <NUM> in accordance with embodiments of the present disclosure. The method <NUM> may be implemented at any suitable devices. Only for the purpose of illustrations, the method <NUM> is described to be implemented at the PCF <NUM>.

At block <NUM>, the PCF <NUM> receive the second information from the NRF <NUM>. For example, the second information may comprise the profile and the Application Route Selection Policy (for example, Table <NUM>). If the provision request is not received the second information may be generated based on the profile and the subscription of the PCF <NUM>. Alternatively, the second information may be generated based on the profile and the provision request.

At block <NUM>, the PCF <NUM> generates the route policy for the terminal device <NUM> based on the second information. The route policy may be a UE Route Selection Policy (URSP). In some embodiments, the PCF <NUM> may generate the route policy for each application on the terminal device <NUM>. Alternatively, the PCF <NUM> may generate the route policy for a specific traffic of one application on the terminal device <NUM>. The PCF <NUM> applies <NUM> the route policy to the network <NUM>. In this way, the route policy may be generated with the consideration of the applications on the terminal devices.

At block <NUM>, the PCF <NUM> transmits the route policy to the terminal device <NUM>. In this way, the route policy may be generated with the consideration of the applications on the terminal devices.

<FIG> illustrates a flow chart of a method <NUM> in accordance with embodiments of the present disclosure. The method <NUM> may be implemented at any suitable devices. Only for the purpose of illustrations, the method <NUM> is described to be implemented at the AF <NUM>.

At block <NUM>, the AF <NUM> generates the provision request. The provision request is for AF to influence application route selection including network slice selection. The provision request comprises the identity of the application which uniquely indicates the application.

In some embodiments, the AF <NUM> may generate a route operation and a condition for applying the route operation and combine the operations with the condition as a part of the provision request. For example, the provision request may also comprise Application Route Selection Policy defined by the AF <NUM>. This Application Route Selection Policy is a set of traffic route rules which composed by rule criteria and rule operations. The rule operation may indicate the route operation when the rule criteria are met. The operation may be either implicit with the QoS profile (for example, QoS requirement like Delay < <NUM>) or explicit to nominate the network slice ID.

In some embodiments, the condition of applying related operation may be one or more of: the location of the terminal device, time, traffic type (for example, video, voice, message), a Flow ID, i.e. any information that can be used to differentiate one data flow, or Network conditions (for example, network (slice) working load, Network usage, charging rate).

At block <NUM>, the AF <NUM> transmits the provision request to the NRF <NUM>. In some embodiments, the AF <NUM> may generate and transmit the prevision request before the terminal device <NUM> transmits the first information to the NRF210. Alternatively, the AF <NUM> may generate and transmit the prevision request after the terminal device <NUM> transmits the first information to the NRF <NUM>.

In some embodiments, an apparatus for performing the method <NUM> (for example, the NRF <NUM>) may comprise respective means for performing the corresponding steps in the method <NUM>. These means may be implemented in any suitable manners. For example, it can be implemented by circuitry or software modules.

In some embodiments, the apparatus comprises means for receiving, at a first device, first information indicating a change in an application related to a second device; means for updating a profile for applications on the second device based on the first information, the profile associated with traffics of the applications on the second device; means for generating second information indicating at least a part of the updating of the profile; and means for transmitting the second information to a third device for generating a route policy for the second device, the route policy specifying route selection for the applications on the second device.

In some embodiments, the first information comprises at least one of the following: a request for registering the application on the second device, a request for deregistering the application on the second device, or a request for updating the application.

In some embodiments, the first information comprises at least one of the following: an identity of the second device, or an identity of the application.

In some embodiments, the means for updating the profile for applications on the second device comprise: means for determining whether the profile is present; means for in response to a determination of absence of the profile, generating the profile for applications on the second device; and means for storing the generated profile.

In some embodiments, the means for generating the second information comprises: means for determining whether a provision request has been received from a fourth device, the provision request comprising an identity of the application, the provision request associated with selecting a network slice for the application; and means for in response to a determination that the provision request has been received, generating the second information based on the provision request and the profile.

In some embodiments, the means for generating the second information comprises: means for determining whether a provision request has been received from a fourth device, the provision request comprising an identity of the application, the provision request associated with selecting a network slice for the application; and means for in response to a determination of absence of the provision request, generating the second information based on subscription of the third device and the profile.

In some embodiments, the first device is a Network Repository Function, NRF, device, the second device is a terminal device, the third device is a policy control device.

In some embodiments, an apparatus for performing the method <NUM> (for example, the PCF <NUM>) may comprise respective means for performing the corresponding steps in the method <NUM>. These means may be implemented in any suitable manners. For example, it can be implemented by circuitry or software modules.

In some embodiments, the apparatus comprises means for receiving, at a third device, information from a first device, the information indicating at least a part of updating of a profile for applications on a second device; means for generating a route policy for the second device, the profile associated with traffics of the applications on the second device; and means for transmitting the generated route policy to the second device.

In some embodiments, the means for generating the policy of route selection for the second device comprises: means for generating the route policy for each application on the second device.

In some embodiments, the means for generating the policy of route selection for the second device comprises: means for generating the route policy for traffic of one application on the second device.

In some embodiments, an apparatus for performing the method <NUM> (for example, the AF <NUM>) may comprise respective means for performing the corresponding steps in the method <NUM>. These means may be implemented in any suitable manners. For example, it can be implemented by circuitry or software modules.

In some embodiments, the apparatus comprises means for generating, at a fourth device, a provision request associated with selecting network slice for an application, the provision request comprising an identity of the application; and means for transmitting the provision request to a first device.

In some embodiments, the means for generating the provision request comprises: means for generating a route operation; means for generating a condition for applying the route operation; and means for combining the route operation and the condition as a part of the provision request.

In some embodiments, the condition comprises at least one of the following: a location of a second device, a traffic type used by the second device, a flow ID, or a network condition.

In some embodiments, the first device is a Network Repository Function, NRF, device, the second device is a terminal device, the fourth device is an Application Function, AF, device.

<FIG> is a simplified block diagram of a device <NUM> that is suitable for implementing embodiments of the present disclosure. The device <NUM> may be provided to implement the communication devices as shown in <FIG>. As shown, the device <NUM> includes one or more processors <NUM>, one or more memories <NUM> coupled to the processor <NUM>, and one or more communication modules <NUM> coupled to the processor <NUM>.

It should be appreciated that future networks may utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications, this may mean node operations to be carried out, at least partly, in a central/centralized unit, CU, (e.g. server, host or node) operationally coupled to distributed unit, DU, (e.g. a radio head/node). It should also be understood that the distribution of labour between core network operations and base station operations may vary depending on implementation.

In an embodiment, the server may generate a virtual network through which the server communicates with the distributed unit. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Such virtual network may provide flexible distribution of operations between the server and the radio head/node. In practice, any digital signal processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the method <NUM> as described above with reference to <FIG>. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Claim 1:
A first device (<NUM>) being a network a network device of a mobile core network, comprising:
means for receiving (<NUM>), at the first device (<NUM>), first information indicating a change in an application related to a second device (<NUM>) being a terminal device from the second device (<NUM>);
means for updating (<NUM>) a profile, stored at the first device (<NUM>), for applications on the second device (<NUM>) based on the first information, the profile associated with traffics of the applications on the second device (<NUM>);
means for generating (<NUM>) second information indicating at least a part of the updating of the profile; and
means for transmitting (<NUM>) the second information to a third device (<NUM>) being a network device of the mobile core network for generating a route policy for the second device (<NUM>), the route policy specifying route selection for the applications on the second device (<NUM>).