WO2020147927A1

WO2020147927A1 - Methods and nodes for in-advance qos prediction notification

Info

Publication number: WO2020147927A1
Application number: PCT/EP2019/050925
Authority: WO
Inventors: Antonio Consoli; Mats Eriksson; Ali HAMIDIAN; Siva VAKEESAR
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-01-15
Filing date: 2019-01-15
Publication date: 2020-07-23
Anticipated expiration: 2021-07-15
Also published as: EP3900264A1

Abstract

An SMF node (140) and a method (900) therein are described. The SMF node (140) is configured to receive a request for an IQN and receive IQN distribution policy; determine that QoS of the PDU session handled by the SMF node (140) is predicted to be affected according to the request and to the distribution policy; and send the IQN to a recipient associated with the PDU session in a NAS message when the recipient is a UE (110), or a SBA message when the recipient is an AF or another NF. Also, a Network Data Analytics Function Node (150) and a method (1000) therein, and a UE (110) and a method (1100) therein are disclosed.

Description

METHODS AND NODES FOR IN-ADVANCE QOS PREDICTION NOTIFICATION

TECHNICAL FIELD

Implementations described herein generally relate to a Session Management Function Node, a method in the Session Management Function Node, a Network Data Analytics Function node, a method in the Network Data Analytics Function node, a User Equipment, and a method in the User Equipment. In particular, a mechanism is herein described, for providing an in advance Quality of Service prediction notification.

BACKGROUND

The number of mobile subscriptions has surpassed the total world population. In 2017, there were 7.8 B mobile subscriber connections, a number which is projected to grow much faster mostly pushed by demand of Internet of Things (loT) connections that is projected to grow 4.7 x times between 2017 and 2025, reaching 25B estimated loT connections in 2025 (on top of 9.0 B mobile subscribers’ connections). Development of 5th Generation networks (5G) is pushed not only by the demand for more connections (both by humans and objects) but also by demand for better network performance. The insurgence and wide penetration of new services such as advanced video (i.e. 4K, 8K, 3D video, 360-degree video for sports broadcasting), Augmented Reality (AR) and Virtual Reality (VR) applications for gaming and immersive TV, autonomous cars, and digital services and content for connected stadia and smart cities will be possible by the higher data rates and lower latencies brought by new 5G networks.

Mobile data networks have by nature finite resources. An unloaded network can potentially meet the needs of any service and any subscriber. In real life, network resources are shared among multiple services, each of which has different Quality of Service (QoS) requirements in terms of e.g. required bit rates, acceptable packet loss rates, and packet delay.

The same common infrastructure must be designed to support different applications with diverging requirements for what concerns the connectivity service provided by the mobile data network. Those requirements have traditionally been defined in terms of a set of Key Performance Indicators (KPIs) such as packet delay tolerance, acceptable packet loss rates, and required minimum bit rates. Mobile networks implement traffic differentiation and policy management in order to use network resources effectively and fulfil the required QoS of applications. The QoS model in 3rd Generation Partnership Project (3GPP) Release 16, which is the sec ond specification for 5G system architecture and that is the evolution of previous QoS frame works) provides means to specify what kind of QoS an application requires (e.g. in terms of bitrate of packet delay budget), how such QoS is controlled, policed and enforced. However, when the mobile network is not able to fulfil a level of QoS that is expected by the application, it will either downgrade or drop an associated Protocol Data Unit (PDU) Session without giving any in-advance notice to the application. In other words, there is no in-advance warn ing being given to an application to the effect that the QoS is going to degrade in the near future.

Automotive applications have introduced the requirement that the network must be able to notify in-advance when the QoS is about to change. This means that the network - before changing the QoS that is delivered to the automotive application - must be able to send a message to that application with a configurable notice period before the new QoS takes place.

An example of why this is needed can be a connected semi-autonomous vehicle that is op erated remotely by a Tele-Operated Driving (TOD) application. The remote operation can be performed either by a human or by a software application. In order for the remote operation to be successful, the remote driver must receive from the cameras on board of the vehicle a video of sufficient quality, and with very small delay. At the same time the driving commands shall be delivered to the Vehicle-to-everything (V2X) On-Board Unit (OBU) in the vehicle timely, because a delay may cause lack of responsiveness in the driving and potentially have fatal consequences. In such scenario, the network must deliver a specific QoS to the TOD application, in terms of bitrate and maximum packet delay budget. However, the network may still potentially downgrade the QoS as long as the V2X OBU in the vehicle is notified in advance. This may allow the vehicle to slow down to a speed that would still allow the tele operation or reach to a complete stop in case the QoS that network is able to deliver in that specific moment is not sufficient for tele-operation. In general application may also be able to cope with the fact that QoS may change without prior notice, however in-advance notifi cations enable an application proactive behaviour to QoS changes.

Another typical example in the case of infotainment is a 4K video streaming to a User Equip ment (UE) of a user travelling on a high-speed vehicle such as a train. 4K streaming requires a connection with a specific bit rate. When bit rate drops the video lags, freezes or run at a lower resolution. Buffering may be a solution, but size of buffering may not always be suffi cient to compensate the QoS drop. It would be desired to find a manner to predict a change in QoS and provide information concerning the change in QoS to the UE.

SUMMARY

It is therefore an object to obviate at least some of the above-mentioned disadvantages and to improve an in-advance QoS prediction notification mechanism. This and other objects are achieved by the features of the appended independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, a Session Management Function (SMF) Node is provided. The SMF node is configured to receive a request for an in-advance Quality of Service prediction notification (IQN) from a IQN consumer. The SMF node is in addition configured to receive IQN distribution policy, from a Policy Control Function (PCF). Furthermore, the SMF node is configured to determine whether QoS of the Protocol Data Unit (PDU) session will be af fected, based on the current QoS parameters of the PDU Session of which SMF is aware of because of the existing functionality according to [3GPP TS 23.501 ] and [3GPP TS 23.502], the trigger received from Network Data Analytics Function (NWDAF), the received request for IQN from a IQN consumer/ recipient and the received IQN distribution policy. Also, the SMF node is in addition configured to send the IQN to the IQN consumer/ recipient associ ated with the PDU session in a Non-Access Stratum (NAS) message when the IQN con sumer/ recipient is a UE, or a Service Based Architecture (SBA) message when the recipient is an Application Function (AF) or another Network Function (NF).

By receiving the request for the IQN, the trigger received from the NWDAF and also receiving the IQN distribution policy from the PCF, it could be determined whether the QoS is predicted to change or not and the IQN could be sent to the recipient in accordance with the IQN distribution policy when the QoS is predicted to be affected according to the IQN request. If QoS changes in a way that does not match the IQN request, no IQN may be sent to the IQN consumer/ recipient. E.g. the IQN consumer/ recipient may request IQN about the latency but information from the NWDAF may say that bitrate may change, no IQN may be sent to the IQN consumer/ recipient.

Thereby, a mechanism is provided for sending information concerning QoS change of the PDU session and send information concerning the QoS change to the IQN consumer/ recip ient. The IQN consumer/ recipient is thereby alerted of a QoS change at an early stage and may perform any appropriate action for eliminating or at least reducing impact of the QoS change i.e. by changing motion patterns, closing down programs/ applications, by increasing distance and/ or decrease speed when the UE is integrated in a vehicle, etc., in a controlled manner which avoids abrupt sudden shutdowns.

In a first possible implementation of the SMF node according to the first aspect, the SMF node may be further configured to verify, before the IQN is sent, that a maximum threshold limit concerning number of previously sent IQNs for the UE in question or for the PDU Ses sion in question has not been exceeded. Also, the SMF node may be configured to verify that a change in QoS of a KPI, requested by the IQN consumer/ recipient, has changed more than a threshold limit. This in order to send the IQN only when the predicted change is big enough to be considered for application reaction and limit those IQNs for QoS changes not relevant for possible action.

It is thereby assured that the IQN is sent to the recipient when the QoS of the KPI specified by and relevant to the recipient has changed more than the threshold limit. Thereby, trans mission of excessive and/ or redundant IQN messages are avoided.

In a second possible implementation of the SMF node according to the first aspect, or the first implementation thereof, the SMF node may also be configured to compare the predicted QoS with a pre-agreed QoS for the PDU session. Further, the SMF node may be configured to only send the IQN when the difference between the pre-agreed QoS and the predicted QoS exceeds a threshold limit.

The transmission of excessive and/ or redundant IQN messages are thereby further reduced.

In a third possible implementation of the SMF node according to the first aspect, or any implementation thereof, the SMF node may also be configured to check, before the IQN is sent, that the information of the predicted QoS has been requested/ subscribed to by the IQN consumer/ recipient. Further, the SMF node may be configured to check that the IQN consumer/ recipient is authorised to receive the IQN.

By checking that the recipient is authorised to receive the IQN, it is ascertained that IQNs are transmitted to the IQN consumer/ recipient, according to the IQN distribution policy.

In a fourth possible implementation of the SMF node according to the first aspect, or any implementation thereof, the SMF node may also be configured to detect that the predicted QoS may result in a degraded QoS for the UE and/ or for specific PDU Session(s). Further, the SMF node may be configured to schedule part of the resources originally scheduled for that UE and/ or for specific PDU Session(s) that will be available after the release of those from the PDU session of the IQN consumer/ recipient with the degraded QoS to another UE or PDU Session.

Hereby, resources that have been allocated to the PDU session of the UE could be used by another entity instead, leading to a better utilisation of network resources because the infor mation that those resources may become available is available at the SMF node earlier than existing 5GS described in [3GPP TS 23.501 ] and [3GPP TS 23.502] thanks to the fact that SMF received the trigger from NWDAF.

In a fifth possible implementation of the SMF node according to the first aspect, or any im plementation thereof, the SMF node may be configured to receive the request for IQN, com prising a request for a subscription for IQN updates, from the IQN consumer/ recipient.

By sending the IQN update subscription request, it is assured that the IQN consumer/ recip ient always receives IQN messages when the QoS is predicted to change by the PF/ NWDAF and the QoS prediction is made according to the IQN request and also that the IQN request is made according to the IQN distribution policy.

In a sixth possible implementation of the SMF node according to the first aspect, or any implementation thereof, the SMF node may be configured to send the assembled IQN to the IQN consumer/ recipient via a V2X Control Function. The V2X Control Function may perform further filtering of the IQN based on understanding of local context for the V2X system, or use the IQN message for triggering other V2X related actions.

Thereby, an alternative communication path is provided, ascertaining that the IQN is pro vided to the IQN consumer/ recipient.

In a seventh possible implementation of the SMF node according to the first aspect, or any implementation thereof, the SMF node may be configured to receive a message that triggers the sending of the IQN together with information required to assemble the IQN, relevant for the PDU session. This message may be received from the NWDAF.

By providing the information required to assemble the IQN, the SMF node is enabled to compose the IQN of the PDU session. In an eighth possible implementation of the SMF node according to the first aspect, or any implementation thereof, the SMF node may be configured to retrieve IQN policy for making prediction, from the PCF. The SMF node may also be configured to verify that QoS prediction is enabled for the PDU session. In addition, the SMF node may also be configured to verify that a Predictive Function is allowed to make predictions for the PDU session. Also, the SMF node may be configured to verify that the QoS prediction is valid for the PDU session ac cording to the IQN policy for making prediction, before sending the IQN to the IQN consumer/ recipient.

Thereby, further regulations of the IQN according to the IQN policy is implemented.

According to a second aspect, a method is provided in a SMF node. The method comprises the step of receiving a request for an IQN from the IQN consumer. In addition, the method furthermore comprises receiving IQN distribution policy, from a PCF. The method comprises determining whether QoS of the PDU session will be affected, based on the received request, the QoS parameters of the PDU Session in question and the received IQN distribution policy. Furthermore, the method comprises assembling the IQN, based on the obtained message and information. The method in addition comprises sending the assembled IQN to a IQN consumer/ recipient associated with the PDU session in a NAS message when the IQN con sumer/ recipient is a UE, or an SBA message when the IQN consumer/ recipient is an AF, or another NF.

By receiving the request for the IQN, the trigger from the NWDAF/ PF, by the QoS parame ters of the PDU Session in question and also receiving the IQN distribution policy from the PCF, it could be determined whether the IQN shall be sent or not and the IQN could be sent to the IQN consumer/ recipient in accordance with the IQN distribution policy when the QoS is predicted to be affected. Thereby, a mechanism is provided to distribute the IQN and send information concerning the predicted QoS change to the IQN consumer/ recipient. The IQN consumer/ recipient is thereby alerted of a QoS change at an early stage and may perform any appropriate action for eliminating or at least reducing impact of the QoS change i.e. by closing down programs/ applications, by increasing distance and/ or decrease speed when the UE is integrated in a vehicle, etc., in a controlled manner which avoids abrupt sudden shutdowns.

In a first possible implementation of the method according to the second aspect, the method also comprises the step of verifying, before the IQN is sent, that a maximum threshold limit concerning number of sent IQN has not been exceeded. Also, the method may comprise verifying that a change in QoS of a KPI, requested by the IQN consumer/ recipient, has changed more than a threshold limit.

It is thereby assured that the IQN is sent to the IQN consumer/ recipient when the QoS of the KPI specified by and relevant to the IQN consumer/ recipient has changed more than the threshold limit. Thereby, transmission of excessive and/ or redundant IQN messages are avoided.

In a second possible implementation of the method according to the second aspect, or any implementation thereof, the method may further comprise the step of comparing the pre dicted QoS with a pre-agreed QoS for the PDU session. Further, the method may comprise sending the IQN only when the difference between the pre-agreed QoS and the predicted QoS exceeds a threshold limit.

In a third possible implementation of the method according to the second aspect, or any implementation thereof, the method may also comprise the step of checking, before the IQN is sent, that the information of the predicted QoS has been requested/ subscribed to by the IQN consumer/ recipient. Further, the method may also comprise checking that the IQN con sumer/ recipient is authorised to receive the IQN.

By checking that that the IQN consumer/ recipient is authorised to receive the IQN, it is as certained that IQN are transmitted to the IQN consumer/ recipient according to the IQN pol icy.

In a fourth possible implementation of the method according to the second aspect, or any implementation thereof, the method may also comprise the step of detecting that the pre dicted QoS will result in a degraded QoS for the UE. Further, the method may further com prise scheduling part of the resources that will be available after the release of those from the PDU session of the IQN consumer/ recipient with the degraded QoS to another entity.

Hereby, resources that have been allocated to the PDU session of the UE could be used by another entity instead, leading to a better utilisation of network resources because the infor mation that those resources may become available is available at the SMF node earlier than existing 5GS described in [3GPP TS 23.501 ] and [3GPP TS 23.502] thanks to the fact that SMF received the trigger from the NWDAF or PF. In a fifth possible implementation of the method according to the second aspect, or any im plementation thereof, the method may also comprise the step of receiving the request for IQN, comprising a request for a subscription for IQN updates, from the IQN consumer/ re cipient.

By sending the IQN update subscription request, it is assured that the IQN consumer/ recip ient always receives IQN messages when the QoS is predicted to change according to the IQN subscription.

In a sixth possible implementation of the method according to the second aspect, or any implementation thereof, the method may also comprise sending the assembled IQN to the IQN consumer/ recipient via a V2X Control Function.

In a seventh possible implementation of the method according to the second aspect, or any implementation thereof, the method may also comprise receiving a message that trigger the sending of the IQN together with information required to assemble the IQN, relevant for the PDU session.

By providing the information required to assemble the IQN, the SMF node is enabled to compose the IQN of the PDU session.

In an eighth possible implementation of the method according to the second aspect, or any implementation thereof, the method may also comprise receiving IQN policy for making pre diction, from the PCF. The method may also comprise verifying that QoS prediction is ena bled for the PDU session. In addition, the method may also comprise verifying that a Predic tive Function is allowed to make predictions for the PDU session. Also, the method may comprise verifying that the QoS prediction is valid for the PDU session, before sending the IQN to the IQN consumer/ recipient.

According to a third aspect, a NWDAF node is provided. The basic functionality of the NWDAF is defined in 3GPP TR 23.791 , TS 23.501 and 23.502. The NWDAF is configured to periodically receive information related to position and/ or route of a UE, from the UE via the AMF and/ or the SMF. Further, the NWDAF is configured to receive information which affects QoS of a PDU session of the UE, at the position and/ or route of the UE. The NWDAF is also configured to receive information related to QoS parameters of the PDU session and also the QoS currently delivered by the PDU Session. In addition, the NWDAF is configured to send a message to a SMF node, for triggering the sending of a IQN together with infor mation required to assemble the IQN.

Thereby, a mechanism is provided to predict a QoS change of the PDU session and send information to the SMF node according to the first aspect, concerning the predicted QoS change to the IQN consumer/ recipient. The IQN consumer/ recipient is thereby alerted of a QoS change at an early stage and may perform any appropriate action for eliminating or at least reducing impact of the QoS change i.e. by closing down programs/ applications, by increasing distance and/ or decrease speed when the UE is integrated in a vehicle, etc., in a controlled manner which avoids abrupt sudden shutdowns.

According to a fourth aspect, a method in a NWDAF node is provided. The method comprises the steps of receiving information related to position and/ or route of a UE. Further, the method also comprises receiving information which affects QoS of a PDU session of the UE at the position and/ or route of the UE. The method in addition comprises receiving infor mation related to QoS of the PDU session. The method also comprises sending a message to a SMF node, for triggering the sending of the IQN together with received information re quired to assemble an IQN.

Thereby, a mechanism is provided to predict a QoS change of the PDU session and send information to the SMF node according to the first aspect, concerning the QoS change to the recipient. The recipient is thereby alerted of a QoS change at an early stage and may perform any appropriate action for eliminating or at least reducing impact of the QoS change i.e. by closing down programs/ applications, by increasing distance and/ or decrease speed when the UE is integrated in a vehicle, etc., in a controlled manner which avoids abrupt sudden shutdowns.

According to a fifth aspect, a UE is provided. The UE is configured to send a request for an IQN to a SMF node, via an AMF node. The UE is also configured to send information con cerning current location and/ or route of the UE periodically while a PDU Session that re quires QoS prediction is established (via AMF node to SMF). Furthermore, the UE is also configured to receive the requested IQN from the SMF node in a NAS message via AMF node.

By receiving information concerning QoS change of the PDU session, the UE is pre-warned and may adapt to the predicted QoS already before the QoS change becomes a reality e.g. by closing down programs/ applications, by increasing distance and/ or decrease speed when the UE is integrated in a vehicle, etc., in a controlled manner which avoids abrupt sudden shutdowns.

According to a sixth aspect, a method in a UE is provided. The method comprises the step of providing a request for an IQN to a SMF node. Further, the method in addition comprises sending information concerning current location and/ or route of the UE. Also, the method further comprises receiving the requested IQN from the SMF node in a NAS message.

In a first possible implementation of the UE method according to the sixth aspect, the step of sending the request comprises a request for a subscription for IQN updates.

Thereby, the UE is ascertained that information concerning any IQN update is received.

According to a seventh aspect, a computer program is provided. The computer program may comprise program code for performing a method according to the second aspect, or any implementations thereof, in a SMF node according to the first aspect, or any implementations thereof. Further, the computer program may comprise program code for performing a method according to the fourth aspect, or any implementations thereof, in a NWDAF node according to the third aspect, or any implementations thereof. The computer program may also com prise program code for performing a method according to the sixth aspect in a UE according to the fifth aspect, or any implementations thereof.

By requesting and acquiring information concerning QoS prediction, a mechanism is pro vided to notify the IQN consumer/ recipient concerning a predicted QoS change.

Other objects, advantages and novel features of the aspects of the invention will become apparent from the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments are described in more detail with reference to attached drawings, il- lustrating examples of embodiments of the invention in which:

Figure 1 is a block diagram illustrating a 5G wireless communication network according to an example, and a UE moving along a flight path or route.

Figure 2 is a combined flow chart and signalling scheme in a wireless communication network according to an example.

Figure 3 is a combined flow chart and signalling scheme in a wireless communication network according to an example.

Figure 4 is a combined flow chart and signalling scheme in a wireless communication network according to an example.

Figure 5 is a combined flow chart and signalling scheme in a wireless communication network according to an example.

Figure 6 is a combined flow chart and signalling scheme in a wireless communication network according to an example.

Figure 7 is a combined flow chart and signalling scheme in a wireless communication network according to an example.

Figure 8 is a combined flow chart and signalling scheme in a wireless communication network according to an example.

Figure 9A is a flow chart illustrating a method in a network node according to an exam ple.

Figure 9B is a flow chart illustrating a method in a network node according to an exam ple.

Figure 10 is a flow chart illustrating a method in a network node according to an exam ple.

Figure 11 is a flow chart illustrating a method in a UE according to an example.

Figure 12 is a block diagram illustrating a network node according to an example.

DETAILED DESCRIPTION

Embodiments of the invention described herein are defined as a SMF node, a NWDAF node, a UE and methods therein, which may be put into practice in the embodiments described below. These embodiments may, however, be exemplified and realised in many different forms and are not to be limited to the examples set forth herein; rather, these illustrative examples of embodiments are provided so that this disclosure will be thorough and complete.

Still other objects and features may become apparent from the following detailed description, considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the herein disclosed embodiments, for which reference is to be made to the appended claims. Further, the drawings are not necessarily drawn to scale and, unless oth erwise indicated, they are merely intended to conceptually illustrate the structures and pro cedures described herein.

Figure 1 is a schematic illustration over a wireless communication network 100 and a UE 110, for wireless communication of signals, data and/ or data packets over a wireless com munication interface. The wireless communication network 100 may be a 5G network.

The expressions“wireless communication network”,“wireless communication system” and / or“cellular telecommunication system” may within the technological context of this disclosure sometimes be utilised interchangeably.

The UE 1 10 may be moving, e.g. when situated in a vehicle, along a flight path 160 towards a destination 170. The UE 1 10 may for example comprise an integrated communication de vice of a vehicle, e.g. configured for Vehicle-to-Vehicle/ Vehicle-to-Everything (V2V/ V2X) communication with other vehicles, or other environmental structures. However, in other em bodiments, the UE 1 10 may be a cellular mobile telephone or similar communication device, used by a user which is moving on a vehicle such as a train or an autonomous car, etc.

When moving between different locations along the flight path 160, the UE 1 10 may have to make a hand over from a source serving cell 120a, to a target serving cell 120b. These cells 120a, 120b may also be referred to as access points of a Radio Access Network (RAN).

The wireless communication network 100 may also comprise an Access and Mobility Man agement Function (AMF) network node 130 and a SMF network node 140. Further, the wire less communication network 100 may comprise a NWDAF 150. The NWDAF 150 may be responsible for collecting/ providing network analytic information upon request. Information concerning the UE 1 10 such as the position of the UE 1 10 and/ or the route 160 of the UE 1 10 may be determined. By knowing or estimating the UE route 160, it becomes possible to predict serving cells 120a, 120b along the route 160. It also becomes possible to predict a change in QoS of a PDU Session of the UE 1 10, in advance.

This is possible by an analysis of statistics collected of previous QoS delivered on various positions along the route 160 to previous/ other UEs having passed the same way, e.g. by knowledge of the available resources on the specific network 100 or network slice; by the type of UE subscription; by the type of PDU Session and QoS Flows in the PDU Session in question to the specific UE 1 10, by the information on the current and predicted weather; by the information on the position and predicted positions of other UEs in the same network 100 or network slice; by the knowledge of the status of each network node 120a, 120b, 130, 140, 150 concerning resource availability; and/ or by the information of predicted events which may affect the number of UEs in the locations in question as well as the number and type of PDU Sessions or QoS flows that are or may be requested by those UEs in the specific net work 100 or network slice.

The source cell 120a, the target cell 120b, the AMF 130, the SMF 140, and/ or the NWDAF 150 may all be referred to as network nodes 120a, 120b, 130, 140, 150 in a common term. Some of these network nodes 120a, 120b, 130, 140, 150 such as the AMF 130, the SMF 140, and/ or the NWDAF 150 may also be referred to as core network nodes 130, 140, 150.

In some embodiments, the network 100, or at least one network node 120a, 120b, 130, 140, 150 therein may comprise a Predictive Function (PF), such as e.g. the NWDAF 150, serving cells 120a, 120b, RAN, AF, etc., enabled to determine a predictive QoS of a PDU session and deliver an in-advance notification about the potential QoS change to the application/ UE 1 10 of the PDU session. An external AF/ PF may alternatively be used for this purpose.

The notification may be referred to as an In-Advance QoS Prediction Notification (IQN). In the 5GS, the connectivity service provided between the UE 1 10 and a Data Network is rep resented by the PDU Session. A PDU Session may contain one or more QoS Flows. The QoS Flow is the finest granularity of QoS differentiation in the PDU Session. Therefore, in 5GS IQN refers to a PDU Session or to a QoS Flow within a PDU Session.

An IQN consumer is an entity that requests IQN (such as e.g. UE 1 10, AF). The IQN Pro ducer is the entity that produces IQN, e.g. the AF or PF or any appropriate network node 120a, 120b, 130, 140, 150. The IQN Notice Period may be defined as the time period indicating how long in advance the IQN Consumer requires/ desired to receive the IQN, before the QoS changes. This time period is use case-specific and is typically specified by the IQN Consumer at time of sub scription. When there is a request from the IQN consumer, the network 100 returns a QoS prediction which may be valid for a certain prediction time interval. The prediction time inter val may start at the time the QoS prediction is generated and ends when the aforementioned prediction is no longer valid.

The predictive QoS functionality according embodiments herein may introduce one, some or all the functionalities of data collection, prediction making and/ or prediction delivery.

The data collection functionality concerns what information to collect and from where to col lect it in order to make predictions that are relevant for the IQN consumers and according to their request or subscription. The prediction making functionality concerns how to make the QoS prediction according to the available collected data. The prediction delivery concerns how to deliver information concerning the prediction of the QoS, to the IQN consumer.

Embodiments concerning the herein provided solution are focused primarily on the issue of prediction delivery functionality, i.e. how to deliver the prediction to the IQN consumers.

More specifically, an IQN distribution framework is provided, supporting multiple IQN pro ducers and multiple IQN consumers. Thereby, a solution is provided for the network 100 to assemble and deliver IQNs to multiple IQN consumers.

Thus, an objective for herein disclosed solutions is to implement the IQN framework in 5GS with multiple IQN producers and multiple IQN consumers, which comprises: how to get an IQN when IQN producer, such as e.g. PF is within RAN, V2X AF or Core Network in order to make it available to intended recipients/ IQN consumers, such as the UE 1 10. Further, it comprises how to deliver IQN to intended recipients/ IQN consumers, comprising V2X Ap plication/ UE 1 10, AF and other NF within 5GC.

The objective further comprises how to manage independent requests for IQN from different IQN consumers that relate to the same PDU Session. Different IQN consumers may be in terested in different IQN information, frequency, and IQN production may be triggered upon different conditions. Also, the objective in addition comprises how to provide policies for IQN request and delivery. A Mobile Network Operator (MNO) may want to limit the number of IQN that are produced or distributed to different IQN consumers. Also, different IQN consumers may access differ ent information that may be comprised in the IQN.

Furthermore, the objective comprises how to perform a PDU Session management that is aware of IQN that have been received for other PDU Sessions sharing the same subset of network resources. Information about the future QoS issue in a PDU Session (or QoS Flow within that PDU Session) may be used to pre-empt resources from that PDU Session that could be scheduled to be used in other PDU Sessions.

In some embodiments, the SMF 140 may be responsible for PDU Session management, as well as QoS management in the wireless communication network 100, functioning as a core network control node. Further, the SMF 140 may be augmented with the role of IQN distrib utor. That is: SMF 140 becomes the node in charge of receiving IQN from where it is origi nated, e.g. the PF, either from within, or from outside the wireless communication network 100. In particular, procedures are disclosed for receiving the IQN from RAN 120a, 120b, a node inside the core network (e.g. NWDAF 150) and from a node outside the wireless com munication network 100 (e.g. AF).

The SMF 140 may be the node in charge of distributing IQN to the IQN consumer, such as the UE 1 10. In particular, it is herein described procedures for distributing the IQN to the UE 1 10, to AF and/ or to other NF within the wireless communication network 100. In order to perform the distribution, the SMF 140 also receives the subscriptions and requests to IQN performed by the IQN consumers. Procedures may be defined for one-time requests and/ or for subscriptions in different embodiments.

Further, the session management context is the information container that comprises the AMF-SMF association for a certain PDU Session. Since the SMF 140 manages the session management context for the PDU Session (and expose such management via the existing Nsmf PDUSession CreateSMContext, Update SM Context and Release SM Context service operations), some embodiments comprise adding the information contained in the IQN re ceived by the PF to the session management context. This allows the SMF 140 to distribute the content of the IQN via the existing Nsmf PDUSession SMContextStatusNotify service operation that is used by the SMF 140 to notify its IQN consumers about the status of a session management context related to the PDU Session. The SMF 140 is the network node in charge of session management (e.g. Session Estab lishment, modify and release, comprising tunnel maintain between User Plane Function (UPF) and AN node), performs session management of AN via the AMF 130 and of control of the User Plane function for what concerns PDU Session resource handling and QoS man agement/ control. This means that SMF 140 has complete view over the core network on session management and resource handling within a PDU Session (comprising resources in AN, resources in UPF and resources in tunnel between UPF and AN). As SMF 140 receives the IQN from the originating PF, it becomes also aware of any potential QoS issues related to the specific PDU Session (or QoS Flow within the PDU Session). By adding to the SMF 140 the additional information on the predicted QoS of the PDU Session, the SMF 140 be comes aware of which PDU Session may potentially release relevant resources. In fact, in order to deliver the connectivity service for which it is established, the PDU Session must use all of the resources that are required, in the AN, UPF and in the tunnel between UPF and AN. There is no reason to keep those resources allocated to a PDU Session (or QoS Flow) that is already expected to have QoS issues because part of those resources will be unavailable (e.g. radio link failure). Therefore, those remaining resources could be potentially scheduled to be available for other PDU Sessions already at the time of IQN receiving at the SMF node 140, and not when PDU Session is dropped, for example a PDU session of an other UE 1 1 1 . This makes the SMF 140 enabled to perform better PDU Session Manage ment by improving its visibility on future resource availability and potentially anticipating re source allocation to PDU Session in-advance, after reception of relevant IQN.

The SMF 140 receives the authorised QoS for a PDU Session by the PCF 180 in the Policy and Charging Control (PCC) Rule. According to this information, the SMF 140 may calculate the QoS parameters for the QoS Flows in a PDU Session and enforces those by controlling the UPF. Also, in some embodiments, the same PCC Rules may also contain additional information related to the IQN distribution policy. In this way the SMF 140 will receive the IQN distribution policy at the time of receiving PCC rule, e.g. during PDU Session Establish ment and Modification procedures. This allows the SMF 140 to be able enforce IQN policies related to IQN distribution as soon as the PDU Session is established.

Predicted network performance may be assessed with respect to currently negotiated per formance (or QoS KPIs). When the UE 1 10 has established a PDU Session, the wireless communication network 100 may be able to predict (with sufficient accuracy) when the QoS KPIs that the wireless communication network 100 is going to deliver will differ from the QoS KPIs that the UE 1 10 and the network 100 have negotiated for the PDU Session. To assess a potential change in QoS for the UE 1 10 within a time interval T, and send a corresponding IQN, the following information may be acquired: the negotiated (i.e. expected) QoS KPIs; the expected position(s) of the UE 1 10 in the time interval T and/ or the QoS KPIs statistics corresponding to the position(s) the UE 1 10 may be expected to be in the time interval T.

The negotiated QoS KPIs may be available at the control plane of the wireless communica tion network 100. The expected position(s) of the UE 1 10 may be available at the application and provided at regular intervals from the application to the wireless communication network 100. The QoS KPIs statistics are available at Operation and Maintenance (OAM) systems.

In addition to the information listed above, the QoS delivered at a specific location by the wireless communication network 100 may be impacted by external factors that can be fed to the wireless communication network 100, e.g. from a third-party service provider, for exam ple a weather forecast or a traffic flow estimation service. Weather effects may influence quality of the air link. Since weather at a specific location can be predicted, providing such information can increase the quality of the prediction of the QoS. Further, road traffic deter mines the vehicle density and therefore has an influence on UE density at a specific location. Since network resources are finite, knowing in advance the predicted concentration of UEs per location may help increasing the quality of the QoS prediction. The vehicle/ UE density may be based on statistics, i.e. measurements stored in a database associated with a time reference, for example; or on real time traffic measurements in different embodiments; or based on real time monitoring, or a combination thereof.

Whenever a prediction is made that the initially agreed QoS for an established PDU Session is going to change due to network load, wireless impairment, weather, capabilities of a target cell 120b, the network 100 may notify the UE 1 10 of the PDU Session with an IQN so that e.g. an V2X Application can take any corrective action such as changing speed, inter-vehicle distance or moving driving control from remote driver to a manual driver and at the same time adapt its QoS profile.

From high-level perspectives, embodiments of the herein provided solution enables the net work 100, i.e. a network node 120, 130, 140, 150 of the network 100, to send IQN to UE 1 10 and/ or AF, allowing timely dynamic application adjustments.

Some embodiments of the provided solution may comprise five phases 0-4 in some embod iments.

Phase 0 may comprise configuration. Firstly, the wireless network 100 may determine whether IQN is to be activated for the UE 1 10 or for a PDU Session initiated by the UE 1 10 in question based on information provided by the UE 1 10 at a time of Registration Request or PDU Session Establishment Request or UE-Specific Subscription data held in UDIW PCF 180. Also, if IQN is allowed, the wireless network 100 may retrieve configuration parameters needed to define the content, the timing, and the triggering conditions for the IQN from UE 1 10, AF or PCF 180. Some examples of configuration parameters may for example be IQN Notice period, how often the predicted location may be reported by the UE 1 10 to the wireless network 100 how often the IQN can be sent to the application, and/ or what order of magni tude of changes shall be reported in the IQN. During the configuration phase, the wireless network 100 also may determine which entities are the IQN consumers of the IQN (e.g. AF, UE 1 10, or both) and what information is to be comprised in the IQN to be sent to each relevant IQN consumer.

Phase 1 concerns collection of information. During the collection phase the wireless network 100 may collect information on the QoS KPIs of interests and on expected UE position(s), necessary input data to predict if the network performance at time T will change from cur rently expected performance. This information may be collected from OAM, AF and/ or from the UE 1 10 in different embodiments. Further, based on this information, it may be deter mined whether any IQN is to be sent or not. In some embodiments, additional third-party information concerning e.g. weather conditions and/ or road traffic information may be col lected. This phase may be repeated/ updated continuously or at time intervals.

Phase 2 relates to decision. During the decision phase, it is verified, according to the trigger ing conditions, whether the conditions for transmitting the IQN are met, based on the infor mation collected during the collection phase according to the configuration of the configura tion phase. This may be referred to as a QoS prediction or trigger message.

Phase 3 comprises delivery of the IQN. During the delivery phase the IQN is sent to the UE 1 10, AF and/ or other NF, when the triggering conditions verified at the decision phase are met.

Phase 4 comprises application adjustment. Upon reception of IQN, the eV2X application may be adjusted at UE 1 10 and/ or AF, e.g. in case of V2X application changing the Level of Automation, or reducing speed, changing the intended trajectory, etc.

The configuration phase with regards to the UE 1 10 may be assumed to be completed at PDU Session establishment. Based on UE provided input or network held subscription data, the wireless network 100 may decide whether to apply IQN for the UE 1 10 or a PDU Session initiated by the UE 1 10. When the UE 1 10 establishes a PDU Session with the wireless network 100, the wireless network 100 may retrieve the IQN Notice period, how often the predicted location shall be reported by the UE 1 10 to the wireless network 100, how often an IQN can be sent by the wireless network 100 to the UE 1 10, and what order of magnitude of changes shall be reported in a IQN, whether the UE 1 10 is a consumer of a IQN and what information shall be included in the IQN to be sent to the UE 1 10. The UE 1 10 requested configuration parameters may be validated against an IQN Distribution Policy that is retrieved by the SMF 140 from PCF 180 at the time the SMF 140 retrieves PCC Rules, in some em bodiments.

An advantage of the disclosed method, by detecting the future change in QoS of the PDU session, assembling the in-advance QoS notification concerning the QoS and providing the IQN to the UE 1 10, associated with the PDU session, when sent with sufficient time in ad vance, it would allow the UE 1 10 to take any appropriate measure before the deterioration of the radio channel.

For example, in the case of video streaming at the UE 1 10, the reception of the IQN may allow the UE 1 10 to pre-fetch a larger portion of the video in advance, to have sufficient streaming content available to play when the connectivity is going to degrade.

Figure 2 illustrates enhancements for supporting IQN.

In some embodiments, wherein the IQN applies to the current PDU Session, the SMF 140 may request IQN analytics for the ongoing PDU Session to the NWDAF 150 using Nnw- daf_Analyticslnfo Request in a sub-step 0a, signalling that the NWDAF 150 may provide support for predictable network performance for the current PDU Session and providing rel evant contextual information to the NWDAF 150, comprising e.g. the PDU Session ID and current negotiated QoS KPI for the relevant PDU Session and QoS Flows.

In sub-step 0b, the NWDAF 150 may respond with Nnwdaf_Analyticslnfo Response. Further, in sub-step 0c, the NWDAF 150 may subscribe to events that are related to the current PDU Session, using Nsmf_EventExposure_Subscribe Request (PDU Session id).

The SMF 140 may respond to the NWDAF 150 event subscription, using Nsmf EventExpo- sure_Subscribe Response in a further sub-step Od. If an AF also is configured as a consumer of the IQN in sub-step Oe, information concerning e.g. how often an IQN can be sent by the network 100 to the AF, what order of magnitude of changes shall be reported in a IQN to the AF, and a specification of information to be com prised in the IQN to be sent to the AF can be sent to the network 100 in an Nsmf EventEx- posure_Subscribe Request (PDU Session id) that may be issued by the AF to the SMF 140.

The SMF 140 may respond to the AF in sub-step Of with a Nsmf_EventExposure_Subscribe Response confirming the actual reception of the message and that the AF has been consid ered as a consumer of the IQN.

At this stage, the UE 1 10 has established the PDU Session, the service request for predict able network performance has been sent to the NWDAF 150 and relevant IQN consumers may have been specified and relevant configuration for the IQN completed.

In a sub-step 1 a, the NWDAF 150 may collect from, e.g., OAM system, the QoS KPIs infor mation relevant for the IQN generation.

In yet a sub-step 1 b, a network node 120a, 120b, 130, 140, 150 of the wireless network 100, such as e.g. the NWDAF 150 may collect additional context information, such as e.g. weather condition statistics, road traffic conditions etc., from e.g. a third-party AF which may be ex ternal, or alternatively internal, to the wireless network 100. This additional information may correlate with the QoS KPIs and affect the QoS. Further, the external context information may be mapped to coordinates (e.g. to cell Ids and/ or position inside the cell) and correlated with the QoS KPIs information.

Any or both of these sub-steps 1 a and/ or 1 b may be repeated whenever updated QoS KPIs statistics and/ or external context information is available. This may be relevant for any of the PDU Sessions for which the PF node is supposed to generate QoS predictions (that in turn may result in IQN to be sent to the IQN consumer).

In a sub-step 1 c, a network node of the wireless network 100 such as e.g. the SMF 140, possibly via the AMF 130, may receive updated expected trajectory from the UE 1 10 (array of location coordinates and relevant timestamps) to allow a mapping between collected QoS KPIs information and the expected future UE positions along the route 160. Such information may be passed to NWDAF 150 using Nsmf EventExposure Notify.

In yet a possible sub-step 2a, the NWDAF 150 may map received expected trajectory 160 and timestamps to collected statistics of QoS KPIs information, as well as third party external context information, if any, relating those to the expected UE position(s) along the trajectory 160.

The NWDAF 150 may then determine if the application has to be notified with an IQN. The decision may be determined based on e.g. current and/ or expected future UE positions; statistics of QoS KPIs information, retrieved from the NWDAF 150 as per sub-step 1 a; ex ternal context info collected as per sub-step 1 b; and/ or QoS KPIs and threshold(s) of interest received from the UE 1 10 as per step 0 during PDU Session establishment.

The NWDAF 150 may check whether the statistics of QoS KPIs information in any position identified in step 2 is below any of the threshold(s) provided by the AF and/ or UE 1 10 for the time the UE 1 10 is expected to be in the position, compared to the QoS KPI that the UE 1 10 has negotiated for the ongoing PDU Session. In this way NWDAF 150 may determine if an IQN has to be sent. Also, NWDAF 150 may also check if the difference between the expected and the predicted QoS KPI is higher than a predefined threshold limit.

Any node of the wireless network 100 such as e.g. the NF may send a QoS prediction or trigger message to SMF 140 informing about the outcome of step 4, i.e. the threshold(s) crossed and the time when the potential change(s) in QoS may happen or that no threshold is crossed, using NsmfPDUSession UdateSMContext.

The SMF 140 may receive the IQN content and add IQN to the PDU Session context in a sub-step 2c. In this step, the SMF 140 may validate that the QoS Prediction received by the PF/ NF is valid according to the IQN policy for making predictions.

In sub-step 2d, the SMF 140 may verify that the received prediction is relevant to an IQN subscription. Then, a relevant IQN Distribution Policy may be checked, by assistance of a PCF 180. The SMF 140 may retrieve the IQN Distribution Policy from the PCF 180 at the time of receiving PCC Rules by invoking the relevant service on PCF Npcf_SMPolicyControl. The policy may provide the information whether the relevant subscribed consumers (e.g. AF and UE 1 10) are authorised to receive the IQN according to the IQN Distribution Policy. Also, the SMF 140 may check that IQN sent in the unit of time is lower than maximum allowed IQN per unit of time, and that the information comprised in the IQN (e.g. which KPI is predicted to change) can be received by the relevant IQN consumer.

In sub-step 3, the IQN may be delivered by the SMF 140 using appropriate channel (e.g. NAS via AMF 130 to the UE 1 10, SBA to Network Exposure Function (NEF)/ AF) or via V2X CF to UE 1 10. The content and format of the notification should be defined to allow effective application adjustments, as well as restriction in 5GS information exposure to 3rd parties. The content of IQN may comprise predicted achievable QoS profiles per QoS flow belonging to a PDU Session of an interest.

In sub-step 4, application adjustment may take place at the UE 1 10 and/ or AF upon recep tion of the IQN.

According to one aspect, as part of PDU Session Establishment Request, in case the UE 1 10 would like to subscribe to a periodic IQN delivery that will be generated whenever the current QoS changes significantly, the UE 1 10 will indicate its intention. As depicted in Figure 3, on receiving a UE intention to subscribe to QoS change in-advance notifications, an AMF 130 may issue a Nsmf PDUSession ContextRequest while including PDU Session ID. In return, the SMF 140 may firstly check with subscription data retrieved from UDM or PCF 180 on UE-specific policy and subsequently update existing Session Management (SM) Context pertaining to the PDU Session in question in terms of the need to trigger IQN notifi cation in case a QoS change is predicted.

According to another aspect, after the PDU Session has been established, in case the UE 1 10 may like to get immediate QoS prediction results in terms of at what QoS a given PDU Session will be supported in a particular time or Space horizon, the UE 1 10 may use Up-link (UL) NAS Transport for this purpose while including a PDU Session ID. An example of the procedure is depicted in Figure 4. On receiving an immediate IQN Request, the AMF 130 may issue a Nsmf PDUSession ContextRequest while including PDU Session ID. In return, the SMF 140 may first check whether such IQN feature is comprised in SM Context and will also check if the IQN Distribution Policy allow servicing such request. If so, it will reply with IQN for the indicated space and time horizons. It may be assumed that the SMF 140 may be responsible for generating such IQN while interacting with its data collection sources such as the NWDAF 150, and possibly also network external sources.

According to one another aspect, after a PDU Session has been established, in case a V2X AS (AF) would like to get immediate QoS prediction results in terms of at what QoS a given PDU Session will be supported in a particular time or Space horizon, the AF may use UL NAS Transport for this purpose while including a PDU Session ID. When the AS is placed outside, the signalling may be mediated by NEF. On receiving a Nnef_EventExposure_Sub- scribe Request, NEF may issue a corresponding Nsmf_EventExposure_Subscribe Request to the SMF 140 while including PDU Session ID. In return, the SMF 140 may firstly check whether such IQN feature is comprised in SM Context, it may also check the IQN Distribution Policy to make sure such request is allowed. If so, it may reply with IQN for the indicated space and time horizons. It may be assumed that the SMF 140 may be responsible for gen erating such IQN while interacting with its data collection sources such as the NWDAF 150.

In case the AF is external to a Mobile Network Operator (MNO) and desires to subscribe to IQN, the AF can use Nnef_EventExposure_Subscribe Request to make such a request to the SMF 140 via the NEF, see Figure 5. The NEF and the AF may be distinct network func tions in some embodiments, although they are collocated in Figure 4 due to lack of space. If, on the other hand, the AF is internal to the MNO, it can subscribe to the SMF 140 for IQN directly.

Figure 6 depicts a procedure in terms of how AF Subscription request may be responded in case a prediction function is located within the wireless network 100. At the time of session establishment, the AMF 130 may check whether any V2X Application or AF has subscribed to IQN reports and if it is the case, INITIAL CONTEXT SETUP REQUEST can be used to enable QoS change prediction at a PF that is located within the wireless network 100. Alter natively, a new N2 messages may be required for the AMF 130 to forward subscription re quest initiated by the AF to the gNB 120a, 120b that currently serves the PDU Session in question and pass the IQN back to the AF.

Figure 7 depicts a procedure in terms of how AF, such as e.g. V2X AS may generate the IQN and use the SMF 140 to distribute the prediction to the various recipients, i.e. IQN con sumers.

The PDU Session is considered to be established and relevant IQN consumers have already subscribed to the specific PDU Session id IQN.

In a first step, the AF may use Nsmf PDUSession UpdateSM Context Request to send the IQN to the SMF 140.

In a second step, the SMF 140 may add the IQN to the PDU session Context.

Further, in a third step, the SMF 140 may send Nsmf PDUSession UpdateSM Context Re sponse, to signal AF that the SMF 140 has received the IQN correctly. In a fourth step, the IQN distribution policy may be executed to possibly filter IQN from being delivered (e.g. throttling IQN), or for authorisation purposes.

In step five, the IQN is delivered by the SMF 140 to the UE 1 10, other AF or other NF con sumers.

Figure 8 depicts a procedure in terms of how delivery to the UE 1 10 may be done via V2X CF instead of using direct channel via the AMF 130. An advantage of this procedure is that V2X CF may embed V2X specific business logic and contextual information about V2X ap plication to apply additional filtering to the initial trigger provided by the SMF 140. For exam ple, the IQN may be issued for a specific PDU Session as an initial warning but may be effective only if the UE 1 10 is in a specific location or region and therefore delivered only when the UE 1 10 reaches that region or when other conditions that are only known within the V2X system and not in the 3GPP system (5GS) are met. Such information may be located only at V2X CF in case the AMF 130 is unable to translate the location provided by the UE 1 10 in MNO specific location.

The PDU Session may be considered to be established and relevant IQN consumers have already subscribed to the specific PDU Session id IQN.

In a first step, the IQN may be received at the SMF 140 for the PDU Session, for the UE 1 10 or class of UEs from a PF.

In a second step, the SMF 140 may add the IQN to the SM Context.

In a third step, the policy may be executed to possibly filter IQN from being delivered (e.g. throttling IQN) or for authorisation purposes.

In step four, the IQN may be delivered to the V2X CF.

In a fifth step, the V2X CF may collect information from the UE 1 10, or another NF (e.g. location). This step may be repeated several times in some embodiments.

In step six, a match between the conditions for the IQN and the context of the UE 1 10 may be performed. Therefore, the IQN may be delivered to the UE 1 10 by the V2X CF. Advantages, according to different embodiments, comprises enablement of Real Time Situ ation Awareness and High Definition Map, e.g. for providing Hazardous Location Warnings; Software Updates; Tele-Operated Driving; High-Density Platooning. Two more use cases may be selected in order to stretch requirement on QoS in different directions: Advanced Safety (Lane Merge) and/ or Infotainment, for example.

The disclosed embodiments will enable the network 100 to provide a connectivity service augmented with IQN that can be originated in AF, (R)AN or 5GC and can be delivered to the UE 1 10, AF and/ or another NF within the wireless network 100. The disclosed solution does not cover how the IQN is generated but is mainly focused on distribution/ delivery of the IQN.

Thus, a distribution mechanism may allow a network control node, such as e.g. SMF 140 to receive IQN from where that is originated such as a Prediction Function, regardless of whether this happens within RAN (e.g. gNB 120a, 120b), 5GC (e.g. NWDAF 150) or DN (e.g. AF) and deliver it to the relevant IQN consumers that request or subscribe to IQN e.g. the UE 1 10 (using NAS and via AMF), AF or other 5GC NF (using e.g. SBA).

This mechanism may comprise embedding IQN consumer subscription in PDU Session es tablishment request and PDU Session modification request message within the Extended Protocol Control Options that is sent from the UE 1 10 to the SMF 140 via the AMF 130, reusing existing PDU SM NAS messages and saving on NAS signalling.

Further, the mechanism may comprise embedding IQN message in PDU Session modifica tion command within the Extended Protocol Control Options that is sent from the SMF 140 to the UE 1 10 via the AMF 130, reusing existing PDU SM NAS messages and saving on NAS signalling.

The mechanism may also comprise embedding IQN subscription cancel request in a PDU Session release request message that is sent from the UE 1 10 to the SMF 140 via the AMF 130, within the Extended Protocol Control Options, reusing existing PDU SM NAS messages and saving on NAS signalling.

Also, the provided mechanism may comprise adding the content of the IQN received by the SMF 140 (from the relevant PF) to the SM Context. This allows the SMF 140 to distribute the content of the IQN via the existing Nsmf PDUSession SMContextStatusNotify service op eration that is used by the SMF 140 to notify its IQN consumers about the status of an SM context related to a PDU Session, with the advantage or reusing existing API for the addi tional functionality.

Furthermore, the Nsmf PDUSession SMContextStatusNotify service operation that is sent by the SMF 140 to the consumer of such service (e.g. AF or other 5GC NF) to notify about a new IQN that has to be received by that IQN consumer.

The Nsmf PDUSession Update SM Context service operation may be used by another NF (e.g. AF or other core network NF) to send a new IQN to the SMF 140 for further distribution.

Further, the mechanism to enable core network reaction to the IQN, by allowing the NF re ceiving the IQN to implement potential actions to prevent or counterbalance predicted is fo cused on degraded QoS. In fact, by making the SMF 140 aware of the IQN. The SMF 140 can use this information when scheduling usage of resources that could be needed by other PDU Sessions. When a PDU Session that is using resources x, y, z is predicted to be down graded because one of these resources (e.g. x) is not going to be available any longer at time T, the SMF 140 may potentially decide to schedule the other resources (y, z) from time T to other PDU Sessions. As an example, x may be the radio resources at a specific location, while y and z could be computational resources in other nodes, such as a User Plane Func tion (UPF), or resources in the tunnel between UPF and the (R)AN or DN.

In some embodiments, the possibility to receive IQN generated not only on statistics col lected historically within the wireless network 100, but do not consider generation of IQN that is also based on real time monitoring of QoS parameters of a PDU Session as well as exter nal factors that may influence the QoS parameters of the PDU Session.

Further, the mechanism that allows embedding IQN policing with existing SM policing. This allows the SMF 140 to retrieve IQN policing at the time of retrieving relevant SM policing from the PCF 180 and being able to enforce relevant IQN Distribution Policy in terms of e.g. what IQN information each respective IQN consumer is capable of request/ subscribe, and/ or how often the IQN may be received by the IQN consumer.

The mechanism may in some embodiments allow the SMF 140 to mediate in retrieving pre diction supporting information from the UE 1 10 by collecting the relevant information from the UE 1 10, via the AMF 130 using NAS and publishing such information towards PF using e.g. service operation Nsmf Event Exposure Notify. The mechanism may allow the same control node to combine both the information of the current QoS that the wireless network 100 is expected to deliver at the current time (that may be known by the SMF 140 by its main role of Session Management node) and the predicted QoS. This will allow the SMF 140 to be able to immediately derive any deviation between what is expected by the UE 1 10 (according to the 5GS QoS model) and the predicted QoS in order to better filter the IQN that may be sent to the IQN consumers.

Thereby, superfluous or redundant signalling may be avoided by not sending any IQN when the predicted QoS approximately correspond to the expected QoS. Thereby, unnecessary signalling in the network 100 is avoided, saving resources.

Figures 9A and 9B form a flow chart illustrating embodiments of a method 900 in a SMF Node 140 for assembling and sending an IQN to a recipient.

In order to correctly assemble and send the IQN, the method 900 may comprise a number of steps 901 -91 1 . However, some of these steps 901 -91 1 may be performed solely in some alternative embodiments, like e.g. steps 906-908 and/ or steps 910-91 1 . Further, the de scribed steps 901 -91 1 may be performed in a somewhat different chronological order than the numbering suggests. The method 900 may comprise the subsequent steps:

Step 901 comprises receiving a request or subscription for the IQN from an IQN consumer.

The received request for IQN may comprise a request for a one-time request or for a sub scription for the IQN updates, from the IQN consumer/ recipient in some embodiments.

Step 902, which may be performed in some embodiments, comprises receiving a message that trigger the sending of the IQN together with information required to assemble the IQN, relevant for a PDU session from a PF.

Step 903 comprises retrieving an IQN distribution policy, from a PCF 180.

Two policy retrieval and checks may be performed, one for the QoS Prediction and one for the IQN, in some embodiments.

Further, in some embodiments wherein step 902 has been performed, a check may be per formed concerning trigger validity. Step 904 comprises determining whether QoS of the PDU session will be affected, based on the received 901 request and the received 903 IQN distribution policy.

The SMF 140 may thereby before assembling the IQN, also retrieve the QoS Prediction policy from the PCF 180 in order to check that QoS Prediction applies to this PDU Session and that the QoS Prediction is authorised to be applied to the PDU Session in question.

Also, the SMF 140 may receive/ retrieve IQN Policy from PCF 180 in order to check that IQN can be sent to the relevant IQN consumers because all of those apply: a) QoS predicted deviates from pre-agreed QoS more than the threshold b) IQN can be sent as the max num ber of IQN per unit of time has not been exceed c) Information that changes has been re quested by the IQN consumer. That is since QoS involves several metrics (data rate, latency, reliability, coverage) only a subset of those could be subscribed for change by the IQN con sumer, so IQN may be sent only if a change is predicted for something the IQN consumer subscribed for d) Other local rules may be applicable to filter the number of IQNs sent to the IQN consumer.

Step 905, which may be performed in some embodiments, comprises assembling the IQN.

Step 906, which only may be performed in some embodiments, comprises receiving IQN policy for making prediction, from the PCF 180, and verifying that QoS prediction is enabled for the PDU Session; verifying that PF is allowed to make predictions for the PDU Session; and verifying that the QoS Prediction is valid for the PDU Session before sending the as sembled IQN to the IQN consumer/ recipient.

Step 907, which only may be performed in some embodiments, comprises comparing the predicted QoS with a pre-agreed QoS for the PDU Session.

Step 908, which only may be performed in some embodiments, comprises verifying, before the IQN is sent, that a maximum threshold limit concerning number of sent IQN has not been exceeded; and that a change in QoS of a KPI, requested by the IQN consumer/ recipient, has changed more than a threshold limit.

The threshold limits may be specified in the IQN distribution policy.

Further, the verification may comprise checking that the information of the predicted QoS has been requested/ subscribed to by the IQN consumer/ recipient; and that the IQN con sumer/ recipient is authorised to receive the IQN.

Step 909 comprises sending the IQN to a recipient associated with the PDU session in a NAS message when the recipient is a user equipment 1 10, or a SBA message when the IQN consumer/ recipient is an AF or another NF.

The assembled 905 IQN may be sent to the IQN consumer/ recipient via a V2X Control Function.

The IQN may be sent only when the difference between the pre-agreed QoS and the pre dicted QoS exceeds a threshold limit, in some embodiments.

Step 910, which only may be performed in some embodiments, comprises detecting that the predicted QoS will result in a degraded QoS for the UE 1 10.

Step 911 , which only may be performed in some embodiments wherein step 910 has been performed, comprises scheduling part of the resources that will be available after the release of those from the PDU Session of the recipient with the predicted degraded QoS to another entity 1 1 1 .

Figure 10 forms a flow chart illustrating embodiments of a method 1000 in a NWDAF node 150 for collecting information required to assemble an IQN and sending a message to a SMF 130 to trigger sending of the IQN to the IQN consumer/ recipient.

In order to correctly collect the information and send the QoS prediction message, the method 1000 may comprise a number of steps 1001 -1004. The described steps 1001 -1004 may be performed in a somewhat different chronological order than the numbering suggests. The method 1000 may comprise the subsequent steps:

Step 1001 comprises receiving information related to position and/ or route 160 of a UE 1 10.

Step 1002 comprises receiving information which may affects the QoS of a PDU session of the UE 1 10 at the position and/ or route 160 of the UE 1 10. It has to be noted that statistics that QoS was affected a number of times in the past in a specific location do not always imply that QoS in that location will always be affected, Therefore deductions made at this step have to be considered to be probabilistic. Step 1003 comprises receiving information related to QoS of the PDU session of the UE 1 10.

Step 1004 comprises sending a QoS prediction message to a SMF node 140, for triggering the sending of the IQN. The message is sent together with the received 1001 , 1002, 1003 information, which may be required by the SMF node 140 to assemble the IQN. The QoS prediction comprises a probability.

Figure 11 forms a flow chart illustrating embodiments of a method 1 100 in a UE 1 10 for receiving an IQN of a PDU session.

In order to receive the IQN correctly, the method 1 100 may comprise a number of steps 1 101 -1 103. The described steps 1 101 -1 103 may be performed in a somewhat different chronological order than the numbering suggests. The method 1 100 may comprise the sub sequent steps:

Step 1101 comprises sending a request for an IQN, and/ or a subscription for IQN, to a SMF node 140.

Step 1102 comprises sending information concerning current location and/ or route 160 of the UE 1 10 to the SMF node 140.

Step 1103 comprises receiving the requested IQN from the SMF node 140 in a NAS mes sage.

The received IQN may then cause the UE 1 10 or the V2X Application running in the UE 1 10 to perform a further action when the QoS is predicted to deteriorate. In case the UE 1 10 is a part of an autonomous vehicle, the vehicle speed and/ or inter-vehicular distance may be adapted based on the received IQN information. Another action may be to buffer information to be received in advance, or to terminate a program or an application under controlled forms; and/ or starting a new program or application.

Figure 12 illustrates a network 1200 and various network nodes 120a, 120b, 130, 140, 150. In particular, an embodiment of an SMF node 140. The SMF node 140 is configured to per form at least some of the method steps 901 -91 1 of the method 900 for assembling and send ing an IQN to an IQN consumer/ recipient. The SMF node 140 is configured to receive a request for the IQN. The SMF node 140 is also configured to receive IQN distribution policy, from a PCF 180. In addition, the SMF node 140 is configured to determine whether QoS of the PDU session may be affected, based on the received request and the received IQN distribution policy. The SMF node 140 is in addition also configured to assemble the IQN. Also, the SMF node 140 is further configured to send the assembled IQN to a IQN consumer/ recipient associated with the PDU session in a NAS message when the IQN consumer/ recipient is a UE 1 10, or a SBA message when the IQN consumer/ recipient is an AF or another NF.

In some embodiments, the SMF node 140 may also be configured to retrieve IQN policy for making prediction, from a PCF 180. The SMF node 140 may be configured to verify that QoS prediction is enabled for the PDU session. Further, the SMF node 140 may be configured to verify that a PF is allowed to make predictions for the PDU session. The SMF node 140 may also be configured to verify that the QoS prediction is valid for the PDU session, before sending the assembled IQN to the IQN consumer/ recipient. In addition, the SMF 140 may verify that the probability that the PDU Session will be affected is higher than a predefined threshold specified by the UE 1 10 in the configuration phase or at subscription time. This in order to provide to the IQN consumer only IQNs containing information events about QoS changes or predicted QoS that have a probability that is sufficient enough to trigger actions at the UE or Application side.

In yet some embodiments, the SMF node 140 may be configured to verify, before the IQN is sent, that a maximum threshold limit concerning number of sent IQN has not been exceeded. The SMF node 140 may in addition be configured to verify that a change in QoS of a KPI, requested by the IQN consumer/ recipient, has changed more than a threshold limit.

Also, the SMF node 140 may be configured to compare the predicted QoS with a pre-agreed QoS for the PDU session. Further, the SMF node 140 may be configured to send the IQN only when the difference between the pre-agreed QoS and the predicted QoS exceeds a threshold limit.

In some embodiments, the SMF node 140 may also be configured to check, before the IQN is sent, that the information of the predicted QoS has been requested/ subscribed to by the IQN consumer/ recipient. Further, the SMF node 140 may be configured to check and con firm that the IQN consumer/ recipient is authorised to receive the IQN. Further, the SMF node 140 may be configured to obtain a message that triggers the sending of the IQN together with information required to assemble the IQN, relevant for a PDU ses sion.

The SMF node 140, according to some embodiments, may be configured to detect that the predicted QoS may result in a degraded QoS for the UE 1 10. Also, the SMF node 140 may be configured to schedule part of the resources that will be available after the release of those from the PDU session or QoS Flow of the IQN consumer/ recipient with the degraded QoS to another entity 1 1 1 , such as e.g. another UE or another PDU Session or QoS Flow.

Furthermore, the SMF node 140 may be additionally configured to detect that the received request for IQN comprises a request for a subscription for the IQN up-dates, from the IQN consumer/ recipient.

In addition, the SMF node 140 may also be configured to send the assembled IQN to the IQN consumer/ recipient via a V2X Control Function.

The SMF node 140 may be configured, when receiving the QoS Prediction and before adding the prediction to its internal memory for further processing to the PDU Session (or SM Con text), to retrieve IQN policy for making prediction from PCF 180 and verify that QoS prediction is enabled for that PDU Session and also that specific PF is allowed to make predictions for that PDU Session and also other local rules may apply to consider such QoS Prediction valid for the PDU Session in question, in some embodiments.

The IQN content may comprise for example IQN type (PDU Session IQN, QoS Flow IQN) and various identity references, e.g. the PDU Session Id for a PDU Session IQN; the PDU Session Id and the QoS Flow Id for a QoS Flow IQN. Further, the IQN may comprise pre dicted QoS such as IQN predicted parameter and/ or IQN predicted value.

This predicted value may not necessarily need to be one specific exact value (e.g. 14.5) but could rather be a value range or interval (e.g. 10-20). Specification of the value range or interval may be agreed as part of the configuration phase between UE 1 10 and SMF 140 or be specified within the IQN distribution policy.

Further the IQN content may comprise Time values for the IQN, which may include any of the time when the QoS prediction takes place or becomes effective, and/ or the time when the QoS prediction was generated. The IQN content may also comprise prediction accuracy. In case of a one-time QoS prediction request, the prediction validity time, may comprise a time period interval for how long the prediction that is received is considered to be valid.

The SMF node 140 may comprise a processing circuitry 1220. The processing circuitry 1220 is configured to perform at least some of the above described actions 901 -91 1 , when loaded into the processing circuitry 1220.

Such processing circuitry 1220 may comprise one or more instances of a processing circuit, i.e. a Central Processing Unit (CPU), a processing unit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The herein utilised expression“processing circuitry” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones enumerated above.

Furthermore, the SMF node 140 also may comprise a receiving circuit 1210 in some embod iments, for receiving signalling from the network node 120a, 120b, 130, 150 over a wired or wireless communication interface.

The SMF node 140 also comprises a transmitting circuit 1230, configured to transmit signals to the network node 120a, 120b, 130, 150 over the wired or wireless communication inter face.

The method 900 comprising the method steps 901 -91 1 ; the method 1000 comprising the method steps 1001 -1004; and/ or the method 1 100 comprising the method steps 1 101 -1 103 may be implemented through the one or more processing circuitries 1220 together with com puter program product for performing the functions of the methods 900, 1000, 1 100, for (en abling) assembling and sending of IQN to the recipient, when the respective computer pro gram runs on a computer.

The computer program product mentioned above may be provided for instance in the form of a data carrier carrying computer program code for performing the respective methods 900, 1000, 1 100. The data carrier may be, e.g., a hard disk, a CD ROM disc, a memory stick, an optical storage device, a magnetic storage device or any other appropriate medium such as a disk or tape that may hold machine readable data in a non-transitory manner. The com puter program product may furthermore be provided as computer program code on a server and downloaded to the network node 120a, 120b, 130, 140, 150 and/ or UE 1 10, e.g., over an Internet or an intranet connection. The terminology used in the description of the embodiments as illustrated in the accompa nying drawings is not intended to be limiting of the described methods 900, 1000, 1 100, network nodes 120a, 120b, 130, 140, 150 and/ or UE 1 10. Various changes, substitutions and/ or alterations may be made, without departing from the invention as defined by the appended claims.

As used herein, the term "and/ or" comprises any and all combinations of one or more of the associated listed items. The term“or” as used herein, is to be interpreted as a mathematical OR, i.e., as an inclusive disjunction; not as a mathematical exclusive OR (XOR), unless ex pressly stated otherwise. In addition, the singular forms "a", "an" and "the" are to be inter preted as“at least one”, thus also possibly comprising a plurality of entities of the same kind, unless expressly stated otherwise. It will be further understood that the terms "includes", "comprises", "including" and/ or "comprising", specifies the presence of stated features, ac- tions, integers, steps, operations, elements, and/ or components, but do not preclude the presence or addition of one or more other features, actions, integers, steps, operations, ele ments, components, and/ or groups thereof. A single unit such as e.g. a processor may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored/ distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware but may also be distributed in other forms such as via Internet or other wired or wireless communication system.

Claims

1 . A Session Management Function Node (140), configured to:

receive a request for an in-advance Quality of Service prediction notification;

receive an in-advance Quality of Service prediction notification distribution policy, from a Policy Control Function;

determine whether Quality of Service of the Protocol Data Unit session will be af fected, based on the received request and the received in-advance Quality of Service pre diction notification distribution policy; and

send the in-advance Quality of Service prediction notification to a recipient associ ated with the Protocol Data Unit session in a non-access stratum message when the recipi ent is a user equipment (1 10), or a Service Based Architecture message when the recipient is an Application Function or another Network Function.

2. The Session Management Function Node (140) according to claim 1 , further con figured to:

verify, before the in-advance Quality of Service prediction notification is sent, that: a maximum threshold limit concerning number of sent in-advance Quality of Service prediction notification has not been exceeded; and

a change in Quality of Service of a Key Performance Indicator, requested by the recipient, has changed more than a threshold limit.

3. The Session Management Function Node (140) according to any one of claim 1 or claim 2, further configured to:

compare the predicted Quality of Service with a pre-agreed Quality of Service for the Protocol Data Unit Session; and

wherein the in-advance Quality of Service prediction notification is sent only when the difference between the pre-agreed Quality of Service and the predicted Quality of Service exceeds a threshold limit.

4. The Session Management Function Node (140) according to any one of claims 1 - 3, further configured to:

check, before the in-advance Quality of Service prediction notification is sent, that: the information of the predicted Quality of Service has been requested/ subscribed to by the recipient; and

the recipient is authorised to receive the in-advance Quality of Service prediction notification.

5. The Session Management Function Node (140) according to any one of claims 1 -

4, further configured to:

detect that the predicted Quality of Service will result in a degraded Quality of Ser vice for the user equipment (1 10); and

schedule part of the resources that will be available after the release of those from the Protocol Data Unit Session of the recipient with the degraded Quality of Service to an other entity (1 1 1 ).

6. The Session Management Function Node (140) according to any one of claims 1 -

5, further configured to:

receive a message that trigger the sending of the in-advance Quality of Service prediction notification together with information required to assemble the in-advance Quality of Service prediction notification, relevant for a Protocol Data Unit session.

7. The Session Management Function Node (140) according to any one of claims 1 -

6, further configured to:

retrieve in-advance Quality of Service prediction notification policy for making pre diction, from a Policy Control Function; and

verify that

Quality of Service prediction is enabled for the Protocol Data Unit Session; a Predictive Function is allowed to make predictions for the Protocol Data Unit Session; and

the Quality of Service Prediction is valid for the Protocol Data Unit Session; before sending the assembled in-advance Quality of Service prediction notification to the recipient.

8. The Session Management Function Node (140) according to any one of claims 1 -

7, wherein the received request for in-advance Quality of Service prediction notification com prises a request for a subscription for the in-advance Quality of Service prediction notification updates, from the recipient.

9. The Session Management Function Node (140) according to any one of claims 1 -

8, wherein the assembled in-advance Quality of Service prediction notification is sent to the recipient via a Vehicle-to-Everything Control Function.

10. A method (900) in a Session Management Function Node (140), which method (900) comprises the steps of: receiving (901 ) a request for an in-advance Quality of Service prediction notification; receiving (903) in-advance Quality of Service prediction notification distribution pol icy, from a Policy Control Function;

determining (904) whether Quality of Service of the Protocol Data Unit session will be affected, based on the received (901 ) request and the received (903) in-advance Quality of Service prediction notification distribution policy; and

sending (909) the in-advance Quality of Service prediction notification to a recipient associated with the Protocol Data Unit session in a non-access stratum message when the recipient is a user equipment (1 10), or a Service Based Architecture message when the recipient is an Application Function or another Network Function.

1 1 . A Network Data Analytics Function Node (150), configured to:

receive information related to position and/ or route (160) of a user equipment (1 10); receive information which affects Quality of Service of a Protocol Data Unit session of the user equipment (1 10), at the position and/ or route (160) of the user equipment (1 10); receive information related to Quality of Service of the Protocol Data Unit session; and

send a message to a Session Management Function Node (140), for triggering the sending of the in-advance Quality of Service prediction notification together with information required to assemble an in-advance Quality of Service prediction notification.

12. A method (1000) in a Network Data Analytics Function Node (150), wherein the method (1000) comprises the steps of:

receiving (1001 ) information related to position and/ or route (160) of a user equip ment (1 10);

receiving (1002) information which affects Quality of Service of a Protocol Data Unit session of the user equipment (1 10) at the position and/ or route (160) of the user equipment (1 10);

receiving (1003) information related to Quality of Service of the Protocol Data Unit session; and

sending (1004) a message to a Session Management Function Node (140), for trig gering the sending of the in-advance Quality of Service prediction notification together with received (1001 , 1002, 1003) information required to assemble an in-advance Quality of Ser vice prediction notification.

13. A user equipment (1 10), configured to: send a request for an in-advance Quality of Service prediction notification to a Ses sion Management Function Node (140);

send information concerning current location and/ or route (160) of the user equip ment (1 10); and

receive the requested in-advance Quality of Service prediction notification from the

Session Management Function Node (140) in a non-access stratum message.

14. The user equipment (1 10) according to claim 13, wherein the provided request com prises a subscription for in-advance Quality of Service prediction notification updates.

15. A method (1 100) in a user equipment (1 10) wherein the method (1 100) comprises the steps of:

sending (1 101 ) a request for an in-advance Quality of Service prediction notification to a Session Management Function Node (140);

sending (1 102) information concerning current location and/ or route (160) of the user equipment (1 10); and

receiving (1 103) the requested in-advance Quality of Service prediction notification from the Session Management Function Node (140) in a non-access stratum message.

16. A computer program with a program code for performing a method (900) according to claim 10 in a Session Management Function Node (140) according to any one of claims 1 -9, a method (1000) according to claim 12 in a Network Data Analytics Function Node (150) according to claim 1 1 , or a method (1 100) according to claim 15 in a user equipment (1 10), according to any one of claims 13-14, when the computer program runs on a computer.