WO2020182266A1

WO2020182266A1 - Network access node and network node for reporting of expected traffic

Info

Publication number: WO2020182266A1
Application number: PCT/EP2019/055814
Authority: WO
Inventors: Siva VAKEESAR; Ali HAMIDIAN
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2019-03-08
Filing date: 2019-03-08
Publication date: 2020-09-17

Abstract

The invention relates to reporting of expected traffic in one or more cells served by a first network access node (100). The first network access node (100) provide a request for expected traffic in at least one cell (700n) served by the first network access node (100) to a network node (300). In response to the request, the network node (300) provides at least one traffic update report (514) to the first network access node (100), where the traffic update report (514) comprises information about expected traffic in the at least one cell (700n) served by the first network access node (100). The information about the expected traffic in the at least one cell (700n) allows the first network access node (100) to efficiently manage its resources. Furthermore, the invention also relates to corresponding methods and a computer program.

Description

NETWORK ACCESS NODE AND NETWORK NODE FOR REPORTING OF EXPECTED

TRAFFIC

Technical Field

The invention relates to a network access node and a network node for reporting of expected traffic in one or more cells served by the network access node. Furthermore, the invention also relates to corresponding methods and a computer program.

Background

The need to support predictive quality-of-service (QoS) had recently been felt by different industries and in response the 3GPP specification group SA1 recently agreed on some requirements in this direction. The relevant SA1 requirements were captured in TR 22.886 V16.1.1. Although relevant stage 1 related requirements are captured, 3GPP specifications still focus on describing a variety of reactive behaviour expected on the 5G system (5GS) to deal with situation where changes to pre-agreed QoS happens. This is because although 5GS is reasonably reliable, it is not 100% reliable in terms of ensuring pre-agreed QoS throughout a lifetime of an established session. Under such circumstances, a new type of pro-active behaviour is required in order for the 5GS to alert an application running in a client device to take corrective actions in response to the inability of the network to meet a given pre-agreed QoS.

Summary

An objective of embodiments of the invention is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

The above and further objectives are solved by the subject matter of the independent claims. Further advantageous embodiments of the invention can be found in the dependent claims.

According to a first aspect of the invention, the above mentioned and other objectives are achieved with a first network access node for a wireless communication system, the first network access node being configured to

provide a traffic status request to a network node, wherein the traffic status request comprises a request for expected traffic in at least one cell served by the first network access node;

obtain a traffic status response from the network node; obtain at least one traffic update report from the network node, wherein the traffic update report comprises expected quality-of-service, QoS, requirements of at least one packet data unit, PDU, session associated with a client device expected to be served in the cell served by the first network access node.

An advantage of the first network access node according to the first aspect is that the first network node obtains information about expected traffic in at least one cell and thereby can manage resources among one or more cells of its cells. For example, make required resources available by pre-empting lower quality connections.

In an implementation form of a first network access node according to the first aspect, the traffic status request further comprises a reporting instruction to provide traffic update reports based on at least one of when traffic is expected in the cell served by the first network access node and a reporting periodicity; and the first network access node is further configured to obtain traffic update reports from the network node according to the reporting instruction.

The reporting instruction can be a flag but is not limited thereto.

An advantage with this implementation form is that the first network node can control when the network node should provide the traffic update reports. Thereby, controlling whether the traffic update reports will be obtained periodically and/or based on when traffic is expected in the cell served by the first network access node.

In an implementation form of a first network access node according to the first aspect, the first network access node is further configured to

obtain a handover notification from the network node, wherein the handover notification comprises a first time instance when a client device served by the first network access node will be handed over to a second network access node;

provide a handover resource reservation request to the second network access node when obtaining the handover notification, wherein the handover resource reservation request comprises the first time instance and expected QoS requirements of at least one PDU session associated with the client device.

An advantage with this implementation form is that the first network access node is informed about an expected handover of one of its client devices to the second network access node and thereby can inform the second network access node in advance that resources are going to be required in the second network access node for the client device.

obtain a handover resource reservation response from the second network access node, wherein the handover resource reservation response comprises an ACK or a NACK to the handover resource reservation request.

An advantage with this implementation form is that the first network access node is informed about the resource availability at the second network access node and hence whether the expected handover will be possible or not.

provide a handover request to a second network access node, wherein the handover request comprises an indication of an expected handover to the second network access node at a second time instance.

The indication can be a flag but is not limited thereto.

An advantage with this implementation form is that the first network access node can initiate an early handover request while indicating that the actual handover will happen at the future second time instance.

obtain a handover resource reservation request from a second network access node, wherein the handover resource reservation request comprises expected QoS requirements of at least one PDU session associated with a client device served by the second network access node;

provide a handover resource reservation response to the second network access node, wherein the handover resource reservation response comprises an ACK or a NACK to the handover resource reservation request. An advantage with this implementation form is that the first network access node is informed about an expected handover of the client device from the second network access node and thereby can check resource availability and make resource reservation in advance of the expected handover.

obtain a handover request from a second network access node, wherein the handover request comprises an indication of an expected handover to the first network access node at a second time instance.

An advantage with this implementation form is that the first network access node is informed that resources are going to be required in the first network access node for the client device at the second time instance and can thereby manage its resources efficiently.

According to a second aspect of the invention, the above mentioned and other objectives are achieved with a network node for a wireless communication system, the network node being configured to

obtain a traffic status request from a first network access node, wherein the traffic status request comprises a request for expected traffic in at least one cell served by the first network access node;

provide traffic status response to the first network access node;

provide at least one traffic update report to the first network access node, wherein the traffic update report comprises expected QoS requirements of at least one PDU session associated with a client device expected to be served in the cell served by the first network access node.

An advantage of the network node according to the second aspect is that the network node is informed about where expected traffic should be predicted.

In an implementation form of a network node according to the second aspect, the network node is further configured to

determine the traffic update report based on expected QoS requirements of at least one PDU session associated with a client device expected to be served in the cell served by the first network access node. An advantage with this implementation form is that the network node can efficiently determine the expected traffic.

In an implementation form of a network node according to the second aspect, the traffic status request further comprises a reporting instruction to provide traffic update reports based on at least one of when traffic is expected in the cell served by the first network access node and a reporting periodicity; and the network node is further configured to

provide traffic update reports to the first network access node according to the reporting instruction.

An advantage with this implementation form is that the network node knows when to provide traffic update reports.

provide a handover notification to the first network access node, wherein the handover notification comprises a first time instance when a client device served by the first network access node will be handed over to a second network access node.

An advantage with this implementation form is that the first network access node is informed about an expected handover of one of its client devices to the second network access node and thereby can prepare for the expected handover by requesting resource reservation in the second network access node.

According to a third aspect of the invention, the above mentioned and other objectives are achieved with a method for a first network access node, the method comprises

providing a traffic status request to a network node, wherein the traffic status request comprises a request for expected traffic in at least one cell served by the first network access node;

obtaining a traffic status response from the network node;

obtaining at least one traffic update report from the network node, wherein the traffic update report comprises expected quality-of-service, QoS, requirements of at least one packet data unit, PDU, session associated with a client device expected to be served in the cell served by the first network access node. The method according to the third aspect can be extended into implementation forms corresponding to the implementation forms of the first network access node according to the first aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the first network access node.

The advantages of the methods according to the third aspect are the same as those for the corresponding implementation forms of the first network access node according to the first aspect.

According to a fourth aspect of the invention, the above mentioned and other objectives are achieved with a method for a network node, the method comprises

obtaining a traffic status request from a first network access node, wherein the traffic status request comprises a request for expected traffic in at least one cell served by the first network access node;

providing traffic status response to the first network access node;

providing at least one traffic update report to the first network access node, wherein the traffic update report comprises expected QoS requirements of at least one PDU session associated with a client device expected to be served in the cell served by the first network access node.

The method according to the fourth aspect can be extended into implementation forms corresponding to the implementation forms of the network node according to the second aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the network node.

The advantages of the methods according to the fourth aspect are the same as those for the corresponding implementation forms of the network node according to the second aspect.

The invention also relates to a computer program, characterized in program code, which when run by at least one processor causes said at least one processor to execute any method according to embodiments of the invention. Further, the invention also relates to a computer program product comprising a computer readable medium and said mentioned computer program, wherein said computer program is included in the computer readable medium, and comprises of one or more from the group: ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), Flash memory, EEPROM (Electrically EPROM) and hard disk drive. Further applications and advantages of the embodiments of the invention will be apparent from the following detailed description.

Brief Description of the Drawings

The appended drawings are intended to clarify and explain different embodiments of the invention, in which:

- Fig. 1 shows a first network access node according to an example of the invention;

- Fig. 2 shows a method for a first network access node according to an example of the invention;

- Fig. 3 shows a network node according to an example of the invention;

- Fig. 4 shows a method for a network node according to an example of the invention;

- Fig. 5 shows a wireless communication network according to an example of the invention;

- Fig. 6 shows signalling between a first network access node and a network node according to an example of the invention;

- Fig.7 shows signalling between the first network access node, the network node and a client device according to an example of the invention;

- Fig. 8 shows signalling between the first network access node, a second network node, and the network node according to an example of the invention;

- Fig. 9 shows a flow chart of a method according to an example of the invention; and

- Fig. 10 shows a flow chart of yet another method according to an example of the invention.

Detailed Description

Fig. 1 shows a first network access node 100 according to an embodiment of the invention. In the embodiment shown in Fig. 1 , the first network access node 100 comprises a processor 102, a transceiver 104 and a memory 106. The processor 102 is coupled to the transceiver 104 and the memory 106 by communication means 108 known in the art. The first network access node 100 may be configured for both wireless and wired communications in wireless and wired communication systems, respectively. The wireless communication capability is provided with an antenna or antenna array 110 coupled to the transceiver 104, while the wired communication capability is provided with a wired communication interface 1 12 coupled to the transceiver 104.

That the first network access node 100 is configured to perform certain actions can in this disclosure be understood to mean that the first network access node 100 comprises suitable means, such as e.g. the processor 102 and the transceiver 104, configured to perform said actions.

According to embodiments of the invention the first network access node 100 is configured to provide a traffic status request 510 to a network node 300. The traffic status request 510 comprises a request for expected traffic in at least one cell 700n served by the first network access node 100. The first network access node 100 is further configured to obtain a traffic status response 512 from the network node 300. Furthermore, the first network access node 100 is configured to obtain at least one traffic update report 514 from the network node 300. The traffic update report 514 comprises expected quality-of-service (QoS) requirements of at least one packet data unit (PDU) session associated with a client device 600n expected to be served in the cell 700n served by the first network access node 100.

Fig. 2 shows a flow chart of a corresponding method 200 which may be executed in a first network access node 100, such as the one shown in Fig. 1. The method 200 comprises providing 202 a traffic status request 510 to a network node 300. The traffic status request 510 comprises a request for expected traffic in at least one cell 700n served by the first network access node 100. The method 200 further comprises obtaining 204 a traffic status response 512 from the network node 300. Furthermore, the method 200 comprises obtaining 206 at least one traffic update report 514 from the network node 300. The traffic update report 514 comprises expected QoS requirements of at least one PDU session associated with a client device 600n expected to be served in the cell 700n served by the first network access node 100.

Fig. 3 shows a network node 300 according to an embodiment of the invention. In the embodiment shown in Fig. 3, the network node 300 comprises a processor 302, a transceiver 304 and a memory 306. The processor 302 is coupled to the transceiver 304 and the memory 306 by communication means 308 known in the art. The network node 300 may be configured for both wireless and wired communications in wireless and wired communication systems, respectively. The wireless communication capability is provided with an antenna or antenna array 310 coupled to the transceiver 304, while the wired communication capability is provided with a wired communication interface 312 coupled to the transceiver 304.

That the network node 300 is configured to perform certain actions can in this disclosure be understood to mean that the network node 300 comprises suitable means, such as e.g. the processor 302 and the transceiver 304, configured to perform said actions. According to embodiments of the invention the network node 300 is configured to obtain a traffic status request 510 from a first network access node 100. The traffic status request 510 comprises a request for expected traffic in at least one cell 700n served by the first network access node 100. The network node 300 is further configured to provide traffic status response 512 to the first network access node 100. Furthermore, the network node 300 is configured to provide at least one traffic update report 514 to the first network access node 100. The traffic update report 514 comprises expected QoS requirements of at least one PDU session associated with a client device 600n expected to be served in the cell 700n served by the first network access node 100.

Fig. 4 shows a flow chart of a corresponding method 400 which may be executed in a network node 300, such as the one shown in Fig. 3. The method 400 comprises obtaining 402 a traffic status request 510 from a first network access node 100. The traffic status request 510 comprises a request for expected traffic in at least one cell 700n served by the first network access node 100. The method 400 further comprises providing 404 traffic status response 512 to the first network access node 100. Furthermore, the method 400 comprises providing 406 at least one traffic update report 514 to the first network access node 100. The traffic update report 514 comprises expected QoS requirements of at least one PDU session associated with a client device 600n expected to be served in the cell 700n served by the first network access node 100.

Fig. 5 shows a wireless communication system 500 according to an embodiment of the invention. The wireless communication system 500 comprises one client device 600n, one first network access node 100, one second network access node 100^", and one network node 300 configured to operate in the wireless communication system 500. However, the wireless communication system 500 may comprise any number of client devices 600n, first network access nodes 100, second network access nodes 100^", and network nodes 300 without deviating from the scope of the invention.

The client device 600n moves in the wireless communication system 500 and is in the embodiment shown in Fig. 5 currently served by the cell 700n served by the first network access node 100. The flightpath of the client device 600n, i.e. the expected route of the client device 600n, is shown with a dashed arrow in Fig. 5. Thus, the client device 600n is expected to move from the coverage of the cell 700n served by the first network access node 100 to the coverage of the cell 700n^" served by the second network access node 100^". According to embodiments of the invention the network node 300 collects information about the cells 700n, 700n^" and the expected traffic of the client devices 600n along their expected flightpaths in the wireless communication system 500, as well as general information such as road traffic and weather. Based on the collected information, the network node 300 can determine expected traffic in one or more cell 700n, 700n^". The network node 300 can provide the determined expected traffic in the cells 700n, 700n^" to the first network access node 100 and the second network access node 100^", respectively. Thereby, allowing the first network access node 100 and the second network access node 100^' to efficiently manage their resources e.g. at handover.

Fig. 6 shows signalling between the first network access node 100 and the network node 300 according to an embodiment of the invention. The signalling shown in Fig. 6 allows the first network access node 100 to request traffic updates for one or more of its served cells 700n from the network node 300. The traffic updates can be used by the first network access node 100 to manage resource allocations of future traffic to be served by any of its cells and handovers for one or more client devices 600n that the first network access node 100 serves. To initiate the reception of traffic updates, the first network access node 100 provides a traffic status request 510 to the network node 300, as shown in step I in Fig. 6. The first network access node 100 may e.g. transmit the traffic status request 510 to the network node 300, directly or via one or more intermediate nodes. The traffic status request 510 comprises a request for expected traffic in at least one cell 700n served by the first network access node 100. The at least one cell 700n may be any type of known cell such as e.g. a macro cell or a pico cell. Furthermore, the at least one cell 700n may in embodiments be served by a remote radio head (RRH) or a distributed unit associated with the network access node 100. In the traffic status request 510, the at least one cell 700n may be identified with a cell ID.

The network node 300 obtains the traffic status request 510 from the first network access node 100 and hence the request for expected traffic in the at least one cell 700n served by the first network access node 100. In response to the traffic status request 510, the network node 300 provides a traffic status response 512 to the first network access node 100, as shown in step II in Fig. 6. The traffic status response 512 may comprise an acknowledgment (ACK) or a negative acknowledgment (NACK) to the traffic status request 510 depending on whether the network node 300 accepts the traffic status request 510 or not. The first network access node 100 obtains the traffic status response 512 from the network node 300 and hence the ACK or NACK informing the first network access node 100 whether the traffic status response 512 has been accepted by the network node 300 or not. In the example shown in Fig. 6, the network node 300 accepts the traffic status request 510 and starts to determine the traffic update report 514 to provide to the first network access node 100 according to the traffic status request 510. The network node 300 may determine the traffic update report 514 based on expected QoS requirements of at least one PDU session associated with a client device 600n expected to be served in the cell 700n served by the first network access node 100. For example, the network node 300 may determine existing PDU sessions and expected new PDU sessions served by the at least one cell 700n together with details of each PDU session such as QoS requirements, expected time duration, and the client device 600n associated with the PDU session. Further details related to the determination of the traffic update report 514 by the network node 300 will be described below with reference to Figs. 7 and 9. In step III in Fig. 6, the network node 300 provides the determined expected traffic information to the first network access node 100 in the traffic update report 514. The traffic update report 514 comprises expected QoS requirements of at least one PDU session associated with the client device 600n expected to be served in the cell 700n served by the first network access node 100. Thus, the first network access node 100 obtains the traffic update report 514 from the network node 300 and hence the expected QoS requirements of the at least one PDU session associated with the client device 600n expected to be served in the cell 700n served by the first network access node 100.

Although only one traffic update report 514 is shown in Fig. 6, the network node 300 may provide any number of traffic update reports 514 to the first network access node 100. The network node 300 may provide the traffic update reports 514 periodically and/or based on a triggering event such as when traffic is expected in the at least one cell 700n. According to embodiments of the invention the first network access node 100 may indicate to the network node 300 whether the traffic update reports 514 should be provided periodically and/or based on when traffic is expected using a reporting instruction. In such embodiments, the traffic status request 510 may further comprise the reporting instruction to provide traffic update reports 514 based on at least one of when traffic is expected in the cell 700n served by the first network access node 100 and a reporting periodicity. When the network node 300 obtains the traffic status request 510 comprising the reporting instruction, the network node 300 provides traffic update reports 514 to the first network access node 100 according to the reporting instruction and the first network access node 100 hence obtains traffic update reports 514 from the network node 300 according to the reporting instruction. The reporting instruction may e.g. be a flag. In such embodiments, the flag may be set to“0” when traffic update reports 514 should be provided based on when traffic is expected in the cell 700n served by the first network access node 100 and set to“1” when traffic update reports 514 should be provided based on the reporting periodicity. The reporting periodicity may be p re-configured in the network node 300 or received from the first network access node 100 as part of the reporting instruction. In embodiments, the reporting instruction may instead be implemented as a bit map or as an information element (IE).

Fig. 7 shows determination of the traffic update report 514 by the network node 300 according to an embodiment of the invention. In step I in Fig. 7, the network node 300 collects information associated with road traffic and weather per road segment within a network. The road traffic and weather information may e.g. be collected from an external server at regular intervals. The network node 300 continuously checks whether any traffic update report 514 should be generated based on obtained traffic status requests 512. In the embodiment shown in Fig. 7 the network node 300 determines, based on a previously received traffic status request 512 from the first network access node 100, that a traffic update report 514 for at least one cell 700n served by the first network access node 100 should be provided to the first network access node 100. In step II in Fig. 7, the network node 300 collects geographical location and coverage of the at least one cell 700n. In step III in Fig. 7, the network node 300 collects information related to existing and expected PDU sessions in the cell 700n. For example, the network node 300 may collect flightpaths of each client device 600n, i.e. the expected route of each client device 600n, in the network or a segment of the network and check whether the flightpath of any of the client devices 600n overlaps with the coverage of the cell 700n. Furthermore, the network node 300 may collect traffic characteristics of already established PDU Sessions of the client devices 600n and approximate expected time at which those identified PDU Sessions will be served by the cell 700n. The information in step II and III may be collected from the first network access node 100 and the client device 600n, as well as from other nodes and devices in the network. Furthermore, the network node 300 may interact/communicate with the first network access node 100 directly or through one or more other nodes such as an AMF.

Based on the information collected in step l-lll in Fig. 7, the network node 300 determines the expected traffic in the cell 700n in step IV. The determined expected traffic may comprise expected QoS requirements of at least one PDU session associated with the client device 600n expected to be served in the cell 700n served by the first network access node 100. The PDU session may be a PDU session which the network node 300 has, based on the collected information, determined will be set-up in the cell 700n or handed over to the cell 700n at a future time instance. For each expected PDU session additional information such as time instance during which the PDU session is expected to be served by the cell 700n, slice and allocation retention priority (ARP) as defined in TS 38.423, etc. may be determined and included in the traffic update report 514. The additional information enables the first network access node 100 to move resources to a particular slice or start preparing for pre-empting existing traffic that has lower ARP than that of incoming traffic. In some cases, such traffic forecasting will help the first network access node 100 to orchestrate required slices as long as those slices do not require dedicated hardware or frequency range.

One way for the network node 300 to indicate QoS requirement of future traffic pertaining to each client device 600n in the traffic update report 514 is to use PDU Session Resources To Be Setup List IE of the HANDOVER REQUEST message as specified in specification TS 38.423 V15.2.0. Each information element (IE) in the HANDOVER REQUEST message is substantially described in TS 38.423 V15.2.0.

The network node 300 provides information about traffic to be expected in the cell 700n in the traffic update report 514 to the first network access node 100, as shown in step V in Fig. 7. As previously described, the traffic update report 514 may be provided to the first network access node 100 based on that an event has been detected and/or based on reporting periodicity, i.e. one or more traffic update report 514 may be provided to the first network access node 100 aperiodically and/or periodically.

With reference to Fig. 7 the procedure for determining expected traffic for one cell 700n served by the first network access node 100 is described. However, the network node 300 may determine the expected traffic for more than one cell served by the first network access node 100, as well as for one or more cells served by one or more other network access nodes.

Based on the information derived from the traffic update reports 514, the first network access node 100 may accumulate information about traffic per client device 600n per cell 700n. The first network access node 100 may use the accumulate traffic information to plan resource utilization and take actions to efficiently manage resources. Actions the first network access node 100 may perform based on the accumulated traffic information may e.g. comprise:

• Subject each PDU Session to admission control and reserve resources in a soft manner without committing physical radio and hardware resources, if a cell is not fully loaded. For example, if the first network access node 100 has a residual capacity of 16 physical resource blocks (PRBs) and a new connection requires 1 PRB, the first network access node 100 can use 15 PRBs for near future admission control purposes. • Check the possibility of orchestrating a slice on demand in a cell if hardware and frequency resources are available or move resources between slices depending on expected traffic per slice per cell. For example, assume a new connection requires a slice that is not currently supported by the first network access node 100 or the first network access node 100 will be fully overloaded when the new connection requires the slice. In this case, the first network access node 100 can either move PRB resources from under-loaded slices to the slice of interest or the first network access node 100 can orchestrate a required slice by moving resources from other under-loaded slices.

• In case of overload situation, check whether data radio bearers (DRBs) and associated resources based on ARP can be released by giving affected client devices enough warning.

• In case of overload situation, check whether client devices which are in RRC_CONNECTED or RRCJNACTIVE states can be moved to RRCJDLE to make additional resources available to serve the expected traffic.

According to an embodiment of the invention the network node 300 can assist the first network access node 100 to reserve resources with a second network access node 100^' in advance of a handover of the client device 600n served by the first network access node 100. Fig. 8 shows such an embodiment. In step I in Fig. 8, the client device 600n indicates to the network node 300 that the client device 600n requires predictive QoS support for a PDU session. The client device 600n is served by the first network access node 100 and may send the indication when the PDU session is established. Based on the indication from the client device 600n, the network node 300 start to collect information associated with the PDU session and the client device 600n in step II in Fig. 8. The network node 300 may e.g. collect information such as QoS requirements for the PDU session, flightpath of the client device 600n, current location the client device 600n, local road traffic and weather reports along the trajectory of the client device 600n, as described above with reference to Fig. 7. Based on the collected information and handover related information such as e.g. handover restriction list and registration area, the network node 300 determines a potential target network access node, i.e. a network access node that the client device 600n is expected to be handed over to at a future time instance. In the embodiment shown in Fig. 8, the network node 300 determines in step II that the second network access node 100^' is a handover target and further that the client device 600 served by the first network access node 100 is expected to be handed over to the second network access node 100^' at a time instance T1. The network node 300 provides a handover notification 516 to the first network access node 100, in step III in Fig.7. The handover notification 516 comprises the first time instance T 1 when the client device 600n served by the first network access node 100 will be handed over to the second network access node 100^". The first network access node 100 obtains the handover notification 516 from the network node 300, where the handover notification 516 comprises the first time instance T1 when the client device 600n served by the first network access node 100 will be handed over to the second network access node 100^". When obtaining the handover notification 516, the first network access node 100 determines in step IV in Fig. 8 when a handover resource reservation request 518 should be provided to the second network access node 100^", e.g. based on the first time instance T1 derived from the handover notification 516. The first network access node 100 further provides the handover resource reservation request 518 to the second network access node 100^", as shown in step V in Fig.7. The handover resource reservation request 518 comprises the first time instance T1 and expected QoS requirements of at least one PDU session associated with the client device 600n. Based on the obtained handover resource reservation request 518, the second network access node 100^' attempts to reserve resources for the client device 600n in step VI in Fig. 8. The second network access node 100^' provides a handover resource reservation response 520 to the first network access node 100, as shown in step VII in Fig. 8. Depending on whether the requested resources could be reserved or not the second network access node 100^' will indicate an ACK or a NACK to the handover resource reservation request 518. The first network access node 100 obtains the handover resource reservation response 520 from the second network access node 100^', where the handover resource reservation response 520 comprises an ACK or a NACK to the handover resource reservation request 518. Thereby, informing the first network access node 100 whether the second network access node 100^' have resources available to handle the client device 600n or not.

In embodiments, the first network access node 100 may in step IV in Fig. 8 determine to initiate a handover of the client device 600n to the second network access node 100^' instead of reserving handover resources in the second network access node 100^'. The first network access node 100 may in such embodiments provide a handover request to the second network access node 100^' (not shown in Fig. 8), when obtaining the handover notification 516 from the network node 300. The handover request may comprise an indication of an expected handover to the second network access node 100^' at a second time instance T2. The indication may e.g. be a flag to indicate that it is an early handover request to request the second network access node 100^' to reserve resources together with QoS requirement of the PDU session of the client device 600n and the second time instance T2 at which the resource reservation should take effect. According to embodiments of the invention the network node 300 may determine that the first network access node 100 is an expected target network access node for a client device 600n^" served by the second network access node 100’. In such embodiments, the first network access node 100 may obtain the handover resource reservation request 518 from the second network access node 100^", where the handover resource reservation request 518 comprises expected QoS requirements of at least one PDU session associated with the client device 600n^" served by the second network access node 100^' and in response provide the handover resource reservation response 520 to the second network access node 100^", where the handover resource reservation response 520 comprises an ACK or a NACK to the handover resource reservation request 518. Alternatively, the first network access node 100 may obtain the handover request from the second network access node 100^", where the handover request comprises an indication of an expected handover to the first network access node 100 at a second time instance T2^".

Fig. 9 shows a flow chart of a method 900 for determining traffic update reports 514 according to an embodiment of the invention. The method 900 may be performed by the network node 300. In step 902 in Fig. 9, the network node 300 collects information associated with road traffic and weather per road segment within a network. The road traffic and weather information may e.g. be collected from an external server at regular intervals. The network node 300 continuously checks in step 904 whether any traffic update reports 514 should be generated based on obtained traffic status requests 512. If no traffic update report 514 should be generated, the network node 300 continues to perform step 902, i.e. collect road traffic and weather information. On the other hand, if a traffic update report 514 should be generated, the network node 300 moves to step 906. In step 906, the network node 300 identifies the cells 700n for which expected traffic should be determined from the obtained traffic status requests 512. The network node 300 further collects geographical location and coverage of the identified cells 700n, as well as traffic and flightpath information associated with active client devices 600n within the network or within a given geographical segment of the network. The traffic information may e.g. comprise traffic characteristics such as e.g. QoS requirements of PDU sessions of the client device 600n. The flightpath information may e.g. comprise one or more of a starting point, one or more intermediate points, and a destination point. The client device 600n may e.g. be considered active if the client device 600n is in RRC_CONNECTED or RRCJNACTIVE state as defined in the 3GPP standard.

Based on the information collected in step 906, the network node 300 determines in step 908 the expected traffic in the cells 700n. For example, for each flightpath of each client device 600n the network node 300 will check identities of cells providing coverage along the flightpath. If any of the identified cells corresponds to the cell 700n for which expected traffic should be determined, the network node 300 determines the expected traffic of the client device 600n at the future time instance when the client device 600n is excepted to be served by the cell 700n and updates the expected traffic for the cell 700n based on this information. Thus, the expected traffic in each cell 700n can be determined by considering the flightpath of each active client device 600n and the expected traffic generated by the active client device 600n along the flightpath.

In step 910, the network node 300 generates the traffic update reports 514 based on the determined expected traffic in step 906 and provides each generated traffic update report 514 to the network access node which has requested the traffic update report 514.

Fig. 10 shows a flow chart of a method according to an embodiment of the invention. The method in Fig. 10 may also be performed by the network node 302. In this embodiment a client device corresponds to a UE, a network node corresponds to a PF, and a first network access node to a gNB. The method in Fig. 10 comprises:

• In step I, a PF collects geographical locations of each cell belong to a gNB within a PLMN. This is required for the PF to decide whether a flightpath of a UE lies on the footprint or coverage of one or many cells.

• At the decision point II, the PF checks whether it has received a traffic status request from a gNB that identifies cells for which future traffic along with associated QoS has to be determined. Such a request will also indicate whether traffic update report that is sent in response to a traffic status request has to be generated either periodically at a set time interval or whenever future traffic is predicted.

• In case the PF has received a traffic status request from a gNB, in step III the PF will identify the total number of cells n and consider the first cell /= 1 where ien.

• At the decision point, the PF will check whether future traffic determination for all identified cells has already been carried out. If it is the case, future traffic update per cell will be generated towards the requested gNB in step V.

• In case the prediction is yet to be carried out for one or many identified cells, in step VI, the PF will get the identifier of a cell and its physical coverage details.

• In step VII, the PF will get the total number of RRC_CONNECTED or RRCJNACTIVE UEs that are served by the PLMN.

• At the decision point VIII, it will be checked whether the PF has analyzed all UEs that were identified in step VII. • If one or many UEs is yet to be analyzed, in step IX, the PF will get the flightpath of each RRC_CONNECTED or RRCJNACTIVE UE together with QoS requirements of each PDU session each UE currently generates and the UE identifier.

• In step X, the PF will determine the total number of cells that lie on the flightpath of a considered UE. If a flightpath lies on one of the cells identified by the gNB in step II and III, the PF will accumulate total traffic QoS requirements per cell - this process will be repeated for all cells that form a flightpath. In other words, for every cell that makes up a flightpath in question, at the decision point XII, it will be checked whether the cell x is identical to the cell / taken into consideration in step III - if it is the case, the UE traffic will be accumulated for that cell / and the process continues with next cell x=x+ 1 of the flightpath. If, on the other hand, it is determined at the decision point XI that all cells that make up a flightpath in question have already been analyzed, the method will move to decision point VIII in case one or many RRC_CONNECTED or RRCJNACTIVE UEs need to be analyzed with a consideration of new UE u += 1.

• If, on the other hand, at the decision point VIII, it is decided that all RRC_CONNECTED or RRCJNACTIVE UEs that are served by the PLMN have been already analyzed for all identified cells, in step V, the PF will generate the traffic update report.

The client device 600n herein, may be denoted as a user device, a User Equipment (UE), a mobile station, an internet of things (loT) device, a sensor device, a wireless terminal and/or a mobile terminal, is enabled to communicate wirelessly in a wireless communication system, sometimes also referred to as a cellular radio system. The UEs may further be referred to as mobile telephones, cellular telephones, computer tablets or laptops with wireless capability. The UEs in this context may be, for example, portable, pocket-storable, hand-held, computer- comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another receiver or a server. The UE can be a Station (STA), which is any device that contains an IEEE 802.1 1 -conformant Media Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM). The UE may also be configured for communication in 3GPP related LTE and LTE-Advanced, in WiMAX and its evolution, and in fifth generation wireless technologies, such as New Radio.

The first network access node 100 and the second network access node 100’ herein may also be denoted as a radio network access node, an access network access node, an access point, or a base station, e.g. a Radio Base Station (RBS), which in some networks may be referred to as transmitter,“gNB”,“gNodeB”,“eNB”,“eNodeB”,“NodeB” or“B node”, depending on the technology and terminology used. The radio network access nodes may be of different classes such as e.g. macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also cell size. The radio network access node can be a Station (STA), which is any device that contains an IEEE 802.1 1 -conformant Media Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM). The radio network access node may also be a base station corresponding to the fifth generation (5G) wireless systems.

The network node 300 herein may be termed the prediction function network node that is configured to perform predictions in terms of changes to pre-agreed QoS associated with a PDU Session of the client device 600n which are likely to happen in the future. The network node 300 can be configured to collect capabilities of cells located along the client device 600n trajectory/flightpath, especially in terms of Slice Support the client device 600n is currently using/allocated, Radio Access Technology (RAT) type, frequency of operations (as some slices will be on certain frequency ranges), Carrier Aggregation (CA), Dual Connectivity (DC) and Coordinated Multipoint (COMP) Support, etc.

The AMF herein may support the following functionality which may be supported in a single instance of an AMF: Termination of RAN CP interface (N2); Termination of NAS (N1 ), NAS; ciphering and integrity protection; Registration management; Connection management; Reachability management; Mobility Management; Lawful intercept (for AMF events and interface to LI System); Provide transport for SM messages between UE and SMF; Transparent proxy for routing SM messages; Access Authentication; Access Authorization; Provide transport for SMS messages between UE and SMSF; Security Anchor Functionality (SEAF) as specified in specification TS 33.501 ; Location Services management for regulatory services; Provide transport for Location Services messages between UE and LMF as well as between RAN and LMF; EPS Bearer ID allocation for interworking with EPS; UE mobility event notification. Further details on AMF can e.g. be found in specification TS 23.501 V15.3.0. The first network access node 100 can interact with network node 300 directly or through an AMF.

Furthermore, any method according to embodiments of the invention may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive. Moreover, it is realized by the skilled person that embodiments of the client device 600n, the first network access node 100, and the network node 300 comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, deinterleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, MSDs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Especially, the processor(s) of the client device 600n, the first network access node 100, and the network node 300 may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression“processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Finally, it should be understood that the invention is not limited to the embodiments described above, but also relates to and incorporates all embodiments within the scope of the appended independent claims.

Claims

1. A first network access node (100) for a wireless communication system (500), the first network access node (100) being configured to

provide a traffic status request (510) to a network node (300), wherein the traffic status request (510) comprises a request for expected traffic in at least one cell (700n) served by the first network access node (100);

obtain a traffic status response (512) from the network node (300);

obtain at least one traffic update report (514) from the network node (300), wherein the traffic update report (514) comprises expected quality-of-service, QoS, requirements of at least one packet data unit, PDU, session associated with a client device (600n) expected to be served in the cell (700n) served by the first network access node (100).

2. The first network access node (100) according to claim 1 , wherein the traffic status request (510) further comprises a reporting instruction to provide traffic update reports (514) based on at least one of when traffic is expected in the cell (700n) served by the first network access node (100) and a reporting periodicity; and further configured to

obtain traffic update reports (514) from the network node (300) according to the reporting instruction.

3. The first network access node (100) according to any of the preceding claims, configured to obtain a handover notification (516) from the network node (300), wherein the handover notification comprises a first time instance (T1 ) when a client device (600n) served by the first network access node (100) will be handed over to a second network access node (100^'); provide a handover resource reservation request (518) to the second network access node (100^") when obtaining the handover notification (516), wherein the handover resource reservation request (518) comprises the first time instance (T1 ) and expected QoS requirements of at least one PDU session associated with the client device (600n).

4. The first network access node (100) according to claim 3, configured to

obtain a handover resource reservation response (520) from the second network access node (100^"), wherein the handover resource reservation response (520) comprises an ACK or a NACK to the handover resource reservation request (518).

5. The first network access node (100) according to any of the preceding claims, configured to provide a handover request to a second network access node (100^"), wherein the handover request comprises an indication of an expected handover to the second network access node (100^') at a second time instance (T2).

6. The first network access node (100) according to any of the preceding claims, configured to obtain a handover resource reservation request (518) from a second network access node (100^"), wherein the handover resource reservation request (518) comprises expected QoS requirements of at least one PDU session associated with a client device (600n^") served by the second network access node (100^');

provide a handover resource reservation response (520) to the second network access node (100^'), wherein the handover resource reservation response (520) comprises an ACK or a NACK to the handover resource reservation request (518).

7. The first network access node (100) according to any of the preceding claims, configured to obtain a handover request from a second network access node (100^'), wherein the handover request comprises an indication of an expected handover to the first network access node (100) at a second time instance (T2^').

8. A network node (300) for a wireless communication system (500), the network node (300) being configured to

obtain a traffic status request (510) from a first network access node (100), wherein the traffic status request (510) comprises a request for expected traffic in at least one cell (700n) served by the first network access node (100);

provide traffic status response (512) to the first network access node (100);

provide at least one traffic update report (514) to the first network access node (100), wherein the traffic update report (514) comprises expected QoS requirements of at least one PDU session associated with a client device (600n) expected to be served in the cell (700n) served by the first network access node (100).

9. The network node (300) according to claim 8, configured to

determine the traffic update report (514) based on expected QoS requirements of at least one PDU session associated with a client device (600n) expected to be served in the cell (700n) served by the first network access node (100).

10. The network node (300) according to claim 8 or 9, wherein the traffic status request (510) further comprises a reporting instruction to provide traffic update reports (514) based on at least one of when traffic is expected in the cell (700n) served by the first network access node (100) and a reporting periodicity; and further configured to

provide traffic update reports (514) to the first network access node (100) according to the reporting instruction.

1 1. The network node (300) according to any of claims 8 to 10, configured to

provide a handover notification (516) to the first network access node (100), wherein the handover notification comprises a first time instance (T 1 ) when a client device (600) served by the first network access node (100) will be handed over to a second network access node (100^').

12. A method (200) for a first network access node (100), the method (200) comprising

providing (202) a traffic status request (510) to a network node (300), wherein the traffic status request (510) comprises a request for expected traffic in at least one cell (700n) served by the first network access node (100);

obtaining (204) a traffic status response (512) from the network node (300);

obtaining (206) at least one traffic update report (514) from the network node (300), wherein the traffic update report (514) comprises expected quality-of-service, QoS, requirements of at least one packet data unit, PDU, session associated with a client device (600n) expected to be served in the cell (700n) served by the first network access node (100).

13. A method (400) for a network node (300), the method (400) comprising

obtaining (402) a traffic status request (510) from a first network access node (100), wherein the traffic status request (510) comprises a request for expected traffic in at least one cell (700n) served by the first network access node (100);

providing (404) traffic status response (512) to the first network access node (100); providing (406) at least one traffic update report (514) to the first network access node (100), wherein the traffic update report (514) comprises expected QoS requirements of at least one PDU session associated with a client device (600n) expected to be served in the cell (700n) served by the first network access node (100).

14. A computer program with a program code for performing a method according to claim 12 or 13 when the computer program runs on a computer.