EP3900264A1 - Procédés et noeuds pour une notification de prédiction de qos à l'avance - Google Patents

Procédés et noeuds pour une notification de prédiction de qos à l'avance

Info

Publication number
EP3900264A1
EP3900264A1 EP19700800.6A EP19700800A EP3900264A1 EP 3900264 A1 EP3900264 A1 EP 3900264A1 EP 19700800 A EP19700800 A EP 19700800A EP 3900264 A1 EP3900264 A1 EP 3900264A1
Authority
EP
European Patent Office
Prior art keywords
iqn
quality
service
qos
advance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP19700800.6A
Other languages
German (de)
English (en)
Inventor
Mats Eriksson
Ali HAMIDIAN
Siva VAKEESAR
Antonio Consoli
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of EP3900264A1 publication Critical patent/EP3900264A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/32—Reselection being triggered by specific parameters by location or mobility data, e.g. speed data
    • H04W36/322—Reselection being triggered by specific parameters by location or mobility data, e.g. speed data by location data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]

Definitions

  • 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.
  • a mechanism is herein described, for providing an in advance Quality of Service prediction notification.
  • QoS Quality of Service
  • KPIs Key Performance Indicators
  • 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.
  • the mobile network when it 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.
  • PDU Protocol Data Unit
  • 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.
  • the remote driver 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.
  • 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.
  • V2X Vehicle-to-everything
  • OBU On-Board Unit
  • the network must deliver a specific QoS to the TOD application, in terms of bitrate and maximum packet delay budget.
  • 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.
  • the network 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.
  • 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.
  • 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).
  • PCF Policy Control Function
  • 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.
  • PDU Protocol Data Unit
  • NWDAF Network Data Analytics Function
  • 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).
  • NAS Non-Access Stratum
  • SBA Service Based Architecture
  • 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.
  • a mechanism 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • the IQN consumer/ recip ient 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.
  • 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.
  • 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.
  • the SMF node is enabled to compose the IQN of the PDU session.
  • 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.
  • the SMF node may also be configured to verify that a Predictive Function is allowed to make predictions for the PDU session.
  • 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.
  • a method in a SMF node.
  • the method comprises the step of receiving a request for an IQN from the IQN consumer.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method may also comprise sending the assembled IQN to the IQN consumer/ recipient via a V2X Control Function.
  • 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.
  • the SMF node is enabled to compose the IQN of the PDU session.
  • 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.
  • the method may also comprise verifying that a Predic tive Function is allowed to make predictions for the PDU session.
  • the method may comprise verifying that the QoS prediction is valid for the PDU session, before sending the IQN to the IQN consumer/ recipient.
  • 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.
  • 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.
  • 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.
  • a method in a NWDAF node 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.
  • 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.
  • 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).
  • the UE is also configured to receive the requested IQN from the SMF node in a NAS message via AMF node.
  • the UE 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.
  • a method in a UE 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.
  • the UE 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.
  • the step of sending the request comprises a request for a subscription for IQN updates.
  • the UE is ascertained that information concerning any IQN update is received.
  • a 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • V2V/ V2X Vehicle-to-Vehicle/ Vehicle-to-Everything
  • 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.
  • 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).
  • RAN Radio Access Network
  • 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.
  • AMF Access and Mobility Man agement Function
  • 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.
  • the network 100 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.
  • PF Predictive Function
  • 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).
  • IQN In-Advance QoS Prediction Notification
  • 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.
  • 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.
  • an IQN distribution framework is provided, supporting multiple IQN pro ducers and multiple IQN consumers.
  • a solution is provided for the network 100 to assemble and deliver IQNs to multiple IQN consumers.
  • 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.
  • MNO Mobile Network Operator
  • 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 may be used to pre-empt resources from that PDU Session that could be scheduled to be used in other PDU Sessions.
  • 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).
  • NWDAF 150 a node inside the core network
  • AF wireless com munication network
  • 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.
  • 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.
  • session management e.g. Session Estab lishment, modify and release, comprising tunnel maintain between User Plane Function (UPF) and AN node
  • UPF User Plane Function
  • SMF 140 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.
  • 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.
  • PCC Policy and Charging Control
  • Predicted network performance may be assessed with respect to currently negotiated per formance (or QoS KPIs).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PDU Session id Nsmf EventEx- posure_Subscribe Request
  • 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.
  • 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.
  • the NWDAF 150 may collect from, e.g., OAM system, the QoS KPIs infor mation relevant for the IQN generation.
  • a network node 120a, 120b, 130, 140, 150 of the wireless network 100 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.
  • additional context information may correlate with the QoS KPIs and affect the QoS.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • appropriate channel e.g. NAS via AMF 130 to the UE 1 10, SBA to Network Exposure Function (NEF)/ AF
  • V2X CF 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.
  • application adjustment may take place at the UE 1 10 and/ or AF upon recep tion of the IQN.
  • an AMF 130 may issue a Nsmf PDUSession ContextRequest while including PDU Session ID.
  • 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.
  • SM Session Management
  • the UE 1 10 may use Up-link (UL) NAS Transport for this purpose while including a PDU Session ID.
  • UL Up-link
  • An example of the procedure is depicted in Figure 4.
  • the AMF 130 may issue a Nsmf PDUSession ContextRequest while including PDU Session ID.
  • 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.
  • the AF may use UL NAS Transport for this purpose while including a PDU Session ID.
  • the signalling may be mediated by NEF.
  • NEF may issue a corresponding Nsmf_EventExposure_Subscribe Request to the SMF 140 while including PDU Session ID.
  • 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.
  • 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.
  • 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.
  • INITIAL CONTEXT SETUP REQUEST can be used to enable QoS change prediction at a PF that is located within the wireless network 100.
  • 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.
  • 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.
  • the AF may use Nsmf PDUSession UpdateSM Context Request to send the IQN to the SMF 140.
  • the SMF 140 may add the IQN to the PDU session Context.
  • the SMF 140 may send Nsmf PDUSession UpdateSM Context Re sponse, to signal AF that the SMF 140 has received the IQN correctly.
  • the IQN distribution policy may be executed to possibly filter IQN from being delivered (e.g. throttling IQN), or for authorisation purposes.
  • 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.
  • 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.
  • 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.
  • 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.
  • the SMF 140 may add the IQN to the SM Context.
  • the policy may be executed to possibly filter IQN from being delivered (e.g. throttling IQN) or for authorisation purposes.
  • step four the IQN may be delivered to the V2X CF.
  • 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.
  • 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 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.
  • 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).
  • RAN e.g. gNB 120a, 120b
  • 5GC e.g. NWDAF 150
  • DN e.g. AF
  • 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.
  • 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.
  • 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.
  • 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 consumer of such service e.g. AF or other 5GC NF
  • 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.
  • another NF e.g. AF or other core network NF
  • the mechanism to enable core network reaction to the IQN by allowing the NF re DCving the IQN to implement potential actions to prevent or counterbalance predicted is fo cused on degraded QoS.
  • the SMF 140 can use this information when scheduling usage of resources that could be needed by other PDU Sessions.
  • the SMF 140 may potentially decide to schedule the other resources (y, z) from time T to other PDU Sessions.
  • x may be the radio resources at a specific location
  • 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.
  • UPF User Plane Func tion
  • 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.
  • 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.
  • the method 900 may comprise a number of steps 901 -91 1 .
  • 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 .
  • 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 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.
  • 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.
  • 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.
  • 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 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 asttled IQN to the IQN consumer/ recipient.
  • Step 907 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • another entity 1 1 1 such as e.g. another UE or another PDU Session or QoS Flow.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • CPU Central Processing Unit
  • ASIC Application Specific Integrated Circuit
  • 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.
  • 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 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un nœud SMF (140) et un procédé (900) associé. Le nœud SMF (140) est conçu pour recevoir une demande d'IQN et recevoir une politique de distribution d'IQN ; déterminer que la QoS de la session PDU gérée par le nœud SMF (140) est prédite pour être affectée en fonction de la demande et de la politique de distribution ; et envoyer l'IQN à un destinataire associé à la session PDU dans un message NAS lorsque le destinataire est un UE (110), ou un message SBA lorsque le destinataire est une AF ou une autre NF. L'invention concerne également un nœud de fonction d'analyse de données de réseau (150) et un procédé (1000) associé, ainsi qu'un UE (110) et un procédé (1100) associé.
EP19700800.6A 2019-01-15 2019-01-15 Procédés et noeuds pour une notification de prédiction de qos à l'avance Pending EP3900264A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2019/050925 WO2020147927A1 (fr) 2019-01-15 2019-01-15 Procédés et nœuds pour une notification de prédiction de qos à l'avance

Publications (1)

Publication Number Publication Date
EP3900264A1 true EP3900264A1 (fr) 2021-10-27

Family

ID=65033594

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19700800.6A Pending EP3900264A1 (fr) 2019-01-15 2019-01-15 Procédés et noeuds pour une notification de prédiction de qos à l'avance

Country Status (2)

Country Link
EP (1) EP3900264A1 (fr)
WO (1) WO2020147927A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210037416A (ko) * 2019-09-27 2021-04-06 삼성전자주식회사 이동 통신 시스템에서 nwdaf를 활용한 서비스의 탐지 및 서비스의 특성 분석을 위한 방법 및 장치
WO2021136596A1 (fr) 2020-01-03 2021-07-08 Huawei Technologies Co., Ltd. Un premier nœud de réseau et un deuxième nœud de réseau pour la coordination des usagers des fonctions réseau
US20240098495A1 (en) * 2020-11-24 2024-03-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for exposing radio access network (ran) data
CN117044246A (zh) 2021-02-24 2023-11-10 大众汽车股份公司 用于远程控制中心并且用于远程操作车辆的计算机程序、设备和方法
CN113038553B (zh) * 2021-02-25 2023-10-27 腾讯科技（深圳）有限公司 基于切换过程的消息发送方法、装置、设备及介质
CN113784397A (zh) * 2021-09-10 2021-12-10 腾讯科技（深圳）有限公司 一种数据处理方法、设备以及可读存储介质
WO2023083436A1 (fr) * 2021-11-09 2023-05-19 Huawei Technologies Co., Ltd. Dispositif et procédé de prédiction de qos à base de ran
WO2023147708A1 (fr) * 2022-02-07 2023-08-10 北京小米移动软件有限公司 Procédé et appareil de mise à jour de session d'intelligence artificielle
CN115086940B (zh) * 2022-05-13 2023-06-06 广州爱浦路网络技术有限公司 基于5G的QoS调整方法、系统、装置及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015193727A1 (fr) * 2014-06-19 2015-12-23 Orange Procédés, appareil et support lisible permettant à une api de notifier une application d'un changement futur de qos

Also Published As

Publication number Publication date
WO2020147927A1 (fr) 2020-07-23

Similar Documents

Publication Publication Date Title
WO2020147927A1 (fr) Procédés et nœuds pour une notification de prédiction de qos à l'avance
EP3850889B1 (fr) Notification d'informations sur la qualité de service à un équipement utilisateur, à des utilisateurs et à un serveur d'applications
JP7504128B2 (ja) 車両と受信デバイスとの間のｖ２ｘ通信を管理するためのシステムおよび方法
CN113595766B (zh) 通信方法和装置
CN113498076A (zh) 基于o-ran的性能优化配置方法与设备
EP3023961B1 (fr) Procédés et dispositifs pour commander des communications sans fil d'un véhicule
US10212616B2 (en) RF resource allocation device and method, and radio communication system
US8495237B1 (en) Techniques for providing a media stream to a mobile computing device based on a predicted route of the mobile computing device
US20220110024A1 (en) Potential qos change notification methods and nodes for assisting application adjustment
KR20190008928A (ko) 이동 사물 네트워크에서 업로드 방향으로 데이터의 라우팅 및 복제를 관리하기 위한 시스템 및 방법
KR20190008932A (ko) 이동 사물 네트워크에서 다운로드 방향으로 데이터의 라우팅 및 복제를 관리하기 위한 시스템 및 방법
KR102327904B1 (ko) 사용자 평면을 분리하기 위한 서비스 품질 구현들
US10805426B2 (en) Method and system for supporting data upload from a mobile gateway device to a backend entity
CN111147270A (zh) 一种数据驱动的网元的构建方法、网元及计算机可读存储介质
EP3901726A1 (fr) Procédé de détermination d'itinéraire de déplacement et dispositif associé
Rastogi et al. A novel safety message dissemination framework in LTE‐V2X system
US20140343838A1 (en) Method for calculating paths, method for obtaining paths as well as terminal for same
WO2016058648A1 (fr) Commande de service de transmission en continu
WO2023083436A1 (fr) Dispositif et procédé de prédiction de qos à base de ran
CN117015991A (zh) 预警信息的发送方法、接收方法、装置、设备及介质
KR20230050381A (ko) 무선통신시스템에서 센서 로우 데이터 공유와 피드백에 관련된 ue의 동작 방법.
US20150118954A1 (en) Maritime machine-to-machine (m2m) application priority management
WO2020011350A1 (fr) Dispositifs et procédés de gestion de ressources de réseau
US20230144248A1 (en) Dynamic quality of service traffic steering in a multi-access edge computing environment
Khalid et al. Optimizing Hybrid V2X Communication: An Intelligent Technology Selection Algorithm Using 5G, C-V2X PC5 and DSRC

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210720

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20221013