WO2023158350A1

WO2023158350A1 - Network node and methods in a communications network

Info

Publication number: WO2023158350A1
Application number: PCT/SE2022/050169
Authority: WO
Inventors: Massimo CONDOLUCI; Péter Hága; Tamas Borsos; Paul Schliwa-Bertling
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-02-16
Filing date: 2022-02-16
Publication date: 2023-08-24

Abstract

A method performed by a network node for handling multiple flows related to a same collective service in a wireless communications network is provided. The flows relate to data traffic flows. 5The network node obtains (301) information data. The data relates to the collective service and identifies the multiple flows that are involved in the same collective service. The information data further comprises:- collective Quality of Service, QoS, requirements for the collective service, to be fulfilled by considering contributions from the multiple flows, and 10- information about inter-flow relationships between the multiple flows,The network node determines (303) flow-specific characteristics and inter-flow characteristics based on the obtained information data. The flow-specific characteristics relate to flow-specific data traffic handling characteristics, and the inter-flow characteristics relate to inter-flow data traffic handling characteristics. 15The network node handles (304) the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics.

Description

NETWORK NODE AND METHODS IN A COMMUNICATIONS NETWORK

The project leading to this application has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 101015956.

TECHNICAL FIELD

Embodiments herein relate to a network node and methods therein. In some aspects, the embodiments relate to handling multiple data traffic flows related to the same collective service in a wireless communications network.

BACKGROUND

In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or User Equipment (UE), communicate via a Wide Area Network or a Local Area Network such as a Wi-Fi network or a cellular network comprising a Radio Access Network (RAN) part and a Core Network (CN) part. The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in Fifth Generation (5G) telecommunications. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.

3GPP is the standardization body for specifying the standards for the cellular system evolution, e.g., including 3G, 4G, 5G and the future evolutions. Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network, have been completed within the 3rd Generation Partnership Project (3GPP). As a continued network evolution, the new releases of 3GPP specifies a 5G network also referred to as 5G New Radio (NR).

Frequency bands for 5G NR are being separated into two different frequency ranges, Frequency Range 1 (FR1) and Frequency Range 2 (FR2). FR1 comprises sub-6 GHz frequency bands. Some of these bands are bands traditionally used by legacy standards but have been extended to cover potential new spectrum offerings from 410 MHz to 7125 MHz. FR2 comprises frequency bands from 24.25 GHz to 52.6 GHz. Bands in this millimeter wave range have shorter range but higher available bandwidth than bands in the FR1.

Multi-antenna techniques may significantly increase the data rates and reliability of a wireless communication system. For a wireless connection between a single user, such as UE, and a base station, the performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. This may be referred to as Single-User (SU)-MIMO. In the scenario where MIMO techniques is used for the wireless connection between multiple users and the base station, MIMO enables the users to communicate with the base station simultaneously using the same time-frequency resources by spatially separating the users, which increases further the cell capacity. This may be referred to as Multi-User (MU)-MIMO. Note that MU-MIMO may benefit when each UE only has one antenna. Such systems and/or related techniques are commonly referred to as MIMO.

In 3GPP systems, traffic handling and/or Quality of Service (QoS) handling are built with a UE flow granularity. This means that a wireless communication system is able to identify and apply a different QoS and/or traffic treatment for each flow of a certain UE. Further, this means that a 3GPP system would treat each UE flow independently from other flows, including other flows of the same UE as well as other flows of other UEs. This comes from the fact that data traffic over mobile networks, and, in general, data traffic over the Internet, is mainly client-server based. Consequently, the 5G system is able to enforce different traffic treatments for each session and/or flow of a certain UE, as well as to differentiate traffic treatments among UEs according e.g. to subscription information. For a certain flow, the 3GPP system defines the following parameters for a QoS Flow, considering a 5G system, where more details are found in 3GPP TS 23.501 :

- 5G QoS Identifier (5QI)

Resource type Priority level Packet Delay Budget (PDB) Packet Error Rate (PER) Averaging window, which represents the duration over which the GFBR and MFBR shall be calculated

Maximum data burst volume

- Allocation/Retention Priority (ARP)

- Reflective QoS

- Guaranteed Flow Bit Rate (GFBR)

- Maximum Flow Bit Rate (MFBR)

- Notification control

- Maximum packet loss rate

In addition to the information above, the 5G system introduced a feature that data traffic may have associated additional alternative QoS profiles. These complement a main QoS profile and are provided together with a prioritization among them. These alternative QoS profiles are used as follows: As the RAN tries to fulfill the main QoS profile, if this cannot be achieved, a notification control is triggered to inform the concerned UE about the RAN unfulfillment. In this case, the RAN may compute which alternative QoS profile may be achievable, and may provide such information to the UE, together with a notification about the unfulfillment of the main QoS profile. In this way, the UE has an enriched information about what to expect QoS-wise from the RAN even if the main QoS profile is not fulfilled.

There are use cases which are related to having a group of devices and/or a group of flows involved in a certain service. Examples include collaborative robots, drones, autonomous intersection management, collaborative maneuver, etc. These use cases are based on a requirement that information sent by all devices belonging to the service will affect the overall service performance. The requirement is not limited to when information sent by a device should be delivered to other devices, but also relates to a case when there is a central entity, e.g., a controller. 3GPP Service and System Aspect (SA) Working Group (WP) 1 (SA WP1) started looking into requirements for upcoming 5G systems in supporting multi-modality use cases, S1-212057. In such use cases, multi-modality refers to the fact that, for a certain use case, there is an actor, usually an application layer located at server-side, which requires inputs from multiple sources and/or UEs or generates coordinates outputs towards multiple UEs. That is a group of UEs that are working all together for the realization of a certain use case, e.g., a decision actor requires both video camera and sensor inputs to make a decision. In this case, there is a relationship among the different inputs from the point of view of how such inputs are used by the decision actor, e.g., inputs are aggregated by the decision actor. However, the actual flows are independent from each other, i.e., the behavior of a single flow does not affect how another flow behaves, and they do not interact among each other in the way they behave. Consequently, SA1 is currently considering that independent flows need to be aggregated to reach a final goal. This means that flows behave independently from each other, and then their inputs are finally aggregated. Nevertheless, this shows that 3GPP is already looking at some sort of services where multiple UEs and/or flows contribute to the final service experience. Also, 3GPP SA WP2 started looking into network features to support multi-modality traffic, see 3GPP S2-2109360, with proposals to study how to support differentiated QoS handling considering different importance of media units, e.g., eligible drop packets belong to less important media units to reduce the resource wasting.

Looking further ahead, timewise such group-based way of working is expected to move towards having direct relationships and implications for the behavior of UEs and/or flows belonging to the same group, i.e., single flows may not anymore be independent but behave accordingly to how other flows behave, and their joint behavior contribute to and influence the overall performance. This may be seen as a native way of working for certain Artificial Intelligence (Al) networks, which are expected to be used by several use cases in 6G timeframe. A first example is Federated Learning (FL), where a common Machine Learning (ML) model is trained by using multiple edge devices in a decentralized manner. An initial model is sent to edge devices, which have access to training data locally. Based on the initial model and local data, each device calculates a set of training gradients or updated model weights, which is collected by the server for aggregation. The model quality improves with each aggregation round, but the quality improvement depends on the composition of device updates. Another example is Spiking Neural Network (SNN), which is an artificial neural network that more closely mimics natural neural networks. SNN is intrinsically based on the concept that the behavior of a neuron directly impacts how other neurons behave. In fact, in SNN, a neuron transmits information, or fires, when a certain threshold is reached. When the neuron fires, such information is propagated to other neurons which, in turn, increase or decrease their potentials in response to this information. This indicates that SNN is not only based on contributions from multiple neurons, but also on how a neuron’s behavior has impact on how other neurons behave. Thus, flows of information from different neurons are not anymore independent from each other. In use cases in which UEs and/or flows are together involved in a certain service, a quality in service delivery, e.g., Quality of Experience (QoE), is not anymore based on a single UE and/or flow but its value is influenced by multiple sources whose contributions vary depending on other sources’ contributions. This is particularly true when considering Al-based applications.

Current traffic and/or QoS handling is designed with the aim that the network should be able to know how to treat a specific traffic for each UE. Considering the evolution of 5G use cases towards complex multi-modality use cases, or Al-powered 6G use cases, the current approach has the limitation that the network has no visibility of the relationship among multiple flows. Thus, when issues arise, e.g., network congestion, the network currently treats flows independently, without considering the impact on the overall quality of service delivery.

SUMMARY

As a part of developing embodiments herein a problem was identified by the inventors and will first be discussed.

In use cases, e.g., in Al-based applications, which are related to having a group of devices and/or a group of flows involved in a certain service, the quality in service delivery, e.g., QoS or QoE, is not based on a single UE/flow but is a collective QoS or QoE which depends on multiple sources whose contributions vary depending on each other’s contribution. There are many possibilities for how a certain flow contributes to the collective QoE, e.g., there may be cases where all flows have the same weight to the collective QoE, cases when some flows have higher impact, etc. It may also be that the impact of a single flow to the collective QoE may vary over time, and/or in space, depending on the specific realization of the use. For example, in a cooperative intersection use case, a vehicle may have a low impact to the collective QoE when it is in a queue behind other vehicles, but it may have a high impact to the collective QoE when it is at the center of the intersection.

As mentioned above, the current approach to handling flows has the limitation that the network has no visibility of the relationship among multiple flows, i.e., how a certain flow influences the overall delivery of complex services based on multiple contributions and where the different contributions are related among themselves. This limits the possibilities for a mobile network to satisfy the QoE for a group-based or multi-modality service (hereinafter interchangeably referred to as collective QoE or collective QoS), as, in this case, the overall QoE does not depend only on the QoE of the single UE/flow and, in addition, the traffic of a single UE depends on the traffic of other UEs. Guaranteeing a good quality for each single flow influencing the collective QoS may result in a satisfactory collective QoS, but this may not be always possible. Specifically, when issues, such as, e.g., network congestion, arise, currently the network will be treating flows independently without considering the impact to the collective QoS.

Using the legacy QoS framework, parameters such as, e.g., guaranteed bitrate and/or packet loss requirements, may be set for each UE. However, the actual bitrate may be very bursty depending on the input. Thus, bitrate requirements may not be realistic to be known a-priori, especially not for each UE. If the network does not have enough resources to meet the conservative requirements, it fails to make Radio Resources Management (RRM) decisions to optimize QoS or to meet requirements, due to one or more of the following reasons:

• Only one UE, e.g., UE A, is in a bad channel conditions, and, to meet the bitrate requirements for such UE the network should allocate a high number of resources (due to the need of using a very robust MCS) but, by doing, so there will not be enough resources for the other UEs to meet their bitrate requirements.

• The network is getting congested, queues are raising, and packets should be dropped.

• The network is getting congested, queues are raising, and packets start to experience high delay, and are getting close to go above their PDB budget.

An object of embodiments herein is to improve the efficiency and performance of providing collective services to mobile devices in a communications network.

According to an aspect of embodiments herein, the object is achieved by a method performed by a network node, for handling multiple flows related to a same collective service in a wireless communications network, and which flows relate to data traffic flows.

The network node obtains information data. The data relates to the collective service and identifies the multiple flows that are involved in the same collective service. The information data further comprises: - collective Quality of Service, QoS, requirements for the collective service, to be fulfilled by considering contributions from the multiple flows, and

- information about inter-flow relationships between the multiple flows,

The network node determines flow-specific characteristics and inter-flow characteristics based on the obtained information data. The flow-specific characteristics relate to flow-specific data traffic handling characteristics, and the inter-flow characteristics relate to inter-flow data traffic handling characteristics.

The network node handles the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics.

According to another aspect of embodiments herein, the object is achieved by a network node configured to handle multiple flows related to a same collective service in a wireless communications network, and which flows are adapted to relate to data traffic flows. The network node is configured to:

- obtain information data relating to the collective service and identifying the multiple flows that are involved in the same collective service, which information data further is adapted to comprise collective Quality of Service (QoS) requirements for the collective service, adapted to be fulfilled by considering contributions from the multiple flows, and information about inter-flow relationships between the multiple flows,

- determine flow-specific characteristics and inter-flow characteristics based on the obtained information data, wherein the flow-specific characteristics are adapted to relate to flow-specific data traffic handling characteristics, and wherein the inter-flow characteristics are adapted to relate to inter-flow data traffic handling characteristics, and

- handle the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics.

In this way, the network node has enriched information data on how a certain flow of the multiple flows should be handled with respect to the other flows of the multiple flows it relates to. This allows the network node to handle the multiple flows such as make improved decisions about, e.g., RRM strategies during traffic handling.

This results in an improved efficiency and performance of providing collective services to mobile devices in the communications network. BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to attached drawings in which:

Figure 1 shows analysis of different types of loss patterns to inference accuracy.

Figure 2 is a schematic block diagram illustrating embodiments of a communications network.

Figure 3 is a flowchart depicting an embodiment of a method in a network node.

Figure 4 is a flowchart illustrating embodiments herein.

Figure 5 is another flowchart illustrating embodiments herein.

Figures 6 a and b are schematic block diagrams illustrating embodiments of a network node.

Figure 7 schematically illustrates a telecommunication network connected via an intermediate network to a host computer.

Figure 8 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection.

Figures 9-12 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

DETAILED DESCRIPTION

As a part of developing embodiments herein a problem was identified by the inventors and will be further evaluated here.

In the following, several examples are presented for use cases that benefit from collective QoE support from the network.

Federated learning (FL) is known to suffer from stragglers, which are devices with late updates. The more devices take part in the FL system, the higher the likelihood of having stragglers due to various reasons, e.g., a slow network connection. The model updates may be very large for deep learning use cases. There are several publications analyzing this problem and proposing an application-level control framework, e.g., Li et al., “SmartPC: Hierarchical Pace Control in Real-Time Federated Learning System,” 2019 IEEE Real-Time Systems Symposium (RTSS), 2019, pp. 406-418, doi: 10.1109/RTSS46320.2019.00043. These solutions are based on the observation that only a proportion of updates from the devices is required to achieve high model accuracy, and it is not worth waiting for stragglers for minor performance improvements. Since the wireless network connection quality can vary significantly, scheduling and resource management decisions in the network can significantly influence update delays. An example may be a requirement of at least 70% of the devices to contribute with their model updates within a certain deadline. Requirements may be more complex, when, for instance, the per-device contributions may have weighted importance, e.g., different sample sizes, aging, etc. Or data transmission scheduling may react to changes in radio environment by, e.g., pre-empting one transmission in favor of another. With traditional QoS mechanism, it is possible to place requirements for selected individual connections, which may be too conservative to be feasible.

As another example, three UEs, such as UE1, UE2, and UE3, defined so and described by way of example only, may have the same priority, but UE1 and UE2 may be involved in and contribute to the same collective service. For instance, UE1 and UE2 may belong to a distributed SNN, i.e. , UE1 and UE2 may have neurons which should communicate to perform a certain task. If the network is congested and traffic of one UE cannot be scheduled as there are not enough resources, there is no difference for the network in dropping either UE1 , UE2, or UE3, but overall it may be better to drop UE3 as this would not have consequences on other UEs. Instead, dropping UE1 or UE2 may cause negative consequences on the other UEs involved in the same service (i.e., two UEs might be dissatisfied), as for the way of working of SNN neurons at UE1 (UE2) will lack information on how neurons at UE2 (UE1) are behaving. This may limit the overall accuracy of the task performed by the distributed SNN. A representation is shown in FIG. 1 , considering a SNN with distributed sensory input and the model split among 10 UEs, which perform the inference step in a distributive manner.

Figure 1 shows analysis of different types of loss patterns to inference accuracy. In Figure 1 , the X-axis represents spike loss, and the Y-axis represents SNN accuracy (QoE) of the collective service that in this example is a SNN service. The case “loss on UE” means that all losses are due to one UE. For example, one UE has 40% of packet losses, other UEs do not have losses. See loss on UE case A marked with triangular symbols and loss on UE case B marked with square formed symbols in Figure I .This may be translated into the fact that only that UE does not meet its requirements. The case “equal loss” refers to the case that losses are distributed among the UEs, e.g., 40% of packet losses are obtained by each of the ten UEs having a 4% packet loss. From the analysis above, one can see that the overall performance (SNN accuracy) depends on how losses are distributed among the UEs. In fact, the accuracy of SNN is more resilient to the case of equal losses. Considering for example the 40% loss point, accuracy drops between -90% and -95%, and the losses impact only one UE, whereas accuracy stays around -99% in the case of equal loss. The gap becomes much larger when moving towards higher loss rates. It is noted that, in the case of equal losses, in an extreme situation, all UEs may have losses beyond a specified QoS target, i.e. , all UEs may not meet their single-UE requirements.

For the sake of an example, it may be assumed a use case where there are 10 UEs involved in a SNN-based application, i.e., the 10 UEs belong to a collective SNN service. The collective SNN service may be satisfied when achieving a bit rate of 100Mbps, and the application has a target SNN accuracy of at least 95% and, as shown in Figure 1 , this may be achieved if all UEs have less than 40% losses. In fact, Figure 1 illustrates that, if UE B has more losses than 40%, the overall SNN accuracy drops below the target 90%. On the contrary, when losses are distributed among the UEs, (equal loss line), the accuracy remains above 90%. For the sake of simplicity, in the reminder, it may be considered that losses are reflected as a lower bitrate. When communicating the QoS requirements, the application may communicate that each UE has a first high priority GFBR of e.g. 10Mbps and a second lower priority GFBR of e.g. 2Mbps. In this way, if all UEs are above the second GFBR of 6Mbps, then each UE will have <40% losses and the overall SNN accuracy will be >90%, see the equal loss line marked with round symbols in Figure 1. Now, it may be assumed that the network is in a situation where it may either: Case A, fulfill the primary GFBR of 10Mbps for 9 UEs (out of 10), but in this case the remaining UE does not even meet the alternative GFBR of 6Mbps, or Case B, fulfill the secondary GFBR of 6Mbps for all the 10 UEs.

Considering the use case above realized through legacy network approaches, the mobile network may be treating each UE as an individual UE, i.e., the network considers whether a UE is satisfied or not. In the situation considered above, the mobile network knows that, if choosing case A, there will be 9 UEs fully satisfied as they will be meeting the primary GFBR of 10Mbps, whereas only one UE will not be satisfied, secondary GFBR not met. In case B, the network knows that none of the UEs will be fully satisfied as none will be meeting the primary GFBR. It is up to network implementation to decide whether to go with case A or B but, from a single UE point of view, case A looks promising as it allows to fully satisfy the majority of UEs. For instance, for cell capacity maximization, case A would allow to get at least 90Mbps, whereas case B only 60Mbps, so case A would be preferred. From a single UE point of view, case B means that the network should dissatisfy 9 UEs to make one UE satisfied. If case A is chosen, the SNN service will be in a situation where there will be more than 40% of losses from one UE, Loss on UE B line in Figure 1 , and the SNN accuracy will be below 90%, thus the SNN application will not meet its accuracy requirement.

As mentioned above, the object of embodiments herein is to improve the efficiency and performance of providing collective services to mobile devices in a communications network.

According to some example embodiments herein, functionality is introduced in a wireless communications network wherein a network node e.g. may:

(i) Receive information data about a collective service. This information data may include collective QoS requirements that should be fulfilled by considering contributions from multiple flows and information about inter-flow relationships.

(ii) Use such information to derive flow-specific and inter-flow traffic handling characteristics that may be used by e.g. an RRM functionality,

(iii) Monitor flow-specific performance to understand whether collective QoS requirements are met. And:

(iv) Eventually adjust flow-specific and inter-flow traffic handling characteristics.

This mechanism may be considered as an extension of the current QoS framework of mobile networks, such as wireless communications networks, that allows to support collective services.

NOTE that embodiments herein may be applied to services involving flows belonging to multiple UEs, as well as to services involving multiple flows of the same UE.

Embodiments herein may be considered as an extension of the current QoS framework of mobile networks that allows to support collective services. Embodiments herein may be applied to services e.g. involving multiple flows belonging to different multiple UEs, as well as to services involving multiple flows of the same UE.

Embodiments herein allow a mobile network, e.g., a network node, to know how several flows jointly influence a QoS of a certain collective service, enabling the mobile network to have features to efficiently support services with collective QoS, or QoE, requirements. In this way, the network node has enriched information on how a certain flow should be handled, e.g. treated, with respect to the other flows it relates to. This allows the network node to handle the flows by e.g. making improved decisions about, e.g., RRM strategies during traffic handling. This has two main advantages:

(i) From the service point of view, the perceived QoS will be higher, as the network node has visibility of how all different traffic components influence the overall collective QoS, and consequently is capable of making more educated choices when serving such traffic components.

(ii) From the network point of view, the information data about collective QoS may be exploited for efficient network resource management, such as e.g., avoiding that too many resources are used for a certain UE if, for example, the collective QoS is not impacted by a temporary QoS unfulfillment of a single mobile device.

Referring again to Figure 1. An example use case using collective QoS requirements according to embodiments herein corresponding to the example scenario discussed in the above legacy use case, will be now described. In this case, an application layer communicates collective QoS information data to the concerned network node, indicating that multiple flows relating to multiple UEs: UE1, UE2, ... ., and LIE10, are involved in a collective service. The collective QoS information data indicates that there is a collective primary GFBR of 100Mbps and a secondary collective GFBR of 60Mbps, with an inter-flow relationship “Equal 100%”, This means that all UEs should contribute in the same way to the requirement fulfillment. In this case, the wireless communications network associates a collective QoS Flow to all the ten UEs of the collective service and has visibility that the QoS fulfillment should be computed from a collective service point of view, and not anymore from a single UE point of view. In the situation considered here, the wireless communications network now knows that, if choosing case A, the collective QoS requirement will not be fulfilled as, even if the aggregate bit rate will be above 90Mbps, there will be 9 UEs contributing with 10Mbps and one UE contributing with less than 6Mbps. The requirement is not met as “Equal 100%” indicates that all UEs should be contributing in the same way. On the contrary, in case B, the network node knows that the collective secondary GFBR requirement could be met, as the aggregate bit rate will be 60Mbps and all UEs will be equally contributing with 6Mbps. With the example use case using collective QoS requirements according to embodiments herein, the network node is capable of understanding that case B is a good choice to satisfy the service. The SNN service will be in a situation where none of the UEs will have more than 40% of losses, Equal loss line in Figure 1 , the SNN accuracy will be >90% and thus the accuracy requirement will be met.

This results in an improved efficiency and performance of providing collective services to mobile devices in a communications network.

Figure 2 is a schematic overview depicting a wireless communications network 100 wherein embodiments herein may be implemented. The wireless communications network 100 comprises one or more RANs and one or more CNs. The wireless communications network 100 may use a number of different technologies, such as mmWave communication networks, Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, 5G, NR, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations. Embodiments herein relate to recent technology trends that are of particular interest in a 5G context and/or a 6G context, however, embodiments are also applicable in further development of the existing wireless communication systems such as e.g. WCDMA and LTE.

A number of network nodes operate in the wireless communications network 100 such as e.g., a network node 110. The network node 110 provides radio coverage in one or more cells which may also be referred to as a service area, a beam or a beam group of beams, such as e.g. a cell 11.

The network node 110 may be any of a NG-RAN node, a transmission and reception point e.g. a base station, a radio access network node such as a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), a gNB, an NG-RAN node, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of communicating with mobile devices such as e.g. mobile devices 121 , 122, 123, within the respective cells 11 , 12, 13 served by the network node 110 depending e.g. on the first radio access technology and terminology used. The network node 110 may communicate with mobile devices such as the mobile devices 121 , 122, 123, in DL transmissions to the mobile devices and UL transmissions from the mobile devices.

A number of mobile devices operate in the wireless communication network 100, such as e.g. a first mobile device 121, a second mobile device 122 and one or more third mobile devices 123. Each of the mobile devices 121, 122, and 123 may also referred to as a UE, an loT device, a collaborative robot, a drone, a vehicle, a mobile station, a non-access point (non-AP) STA, a STA, and/or a wireless terminals, that communicates via one or more Access Networks (AN), e.g. RAN, to one or more core networks (CN). It should be understood by the skilled in the art that “wireless device” is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g., smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station communicating within a cell.

A service node 130 operate in the wireless communication network 100 operates, e.g. in a cloud 135. The service node 130 handles use cases where multiple flows from one or more mobile devices 121 , 122, 123 are involved in a certain service. Examples of services with multiple flows may e.g. include services related to collaborative robots, drones, autonomous intersection management, collaborative maneuver, etc. These use cases will be based on a requirement that information sent by all mobile devices belonging to the same service will affect the overall service performance.

The service node 130, may e.g. be an Application Function (AF) providing collective service and/or updates collective QoS information, such as e.g. target flows, collective QoS requirements, inter-flow relationships, etc., or collective service requirements. Such information may be received by e.g., a PCF, and then processed and provided to other network entities such as, e.g., a Session Management Function (SMF), a User Plane Function (UPF), an Access and Mobility Management function (AMF), and RAN nodes such as the network node 110.

Methods herein may be performed by the network node 110. As an alternative, a Distributed Node (DN) and functionality, e.g. comprised in the cloud 135 as shown in Figure 2, may be used for performing or partly performing the methods herein. A number of embodiments will now be described, some of which may be seen as alternatives, while some may be used in combination.

According to an example of embodiments herein, a mobile network such as the network node 110, receives information data on a collective service. The information data e.g. comprises information data on relationships and joint requirements for data traffic transferred among multiple flows involved in the same collective service. Such information data allows the network node 110 to know how the performance and/or behavior of a certain flow influences the overall performance of the collective service. Flows that constitute part of a collective service may be tagged to indicate their association to the same collective service. The information data on relationships and joint requirements of the collective service is used to generate flow-specific and inter-flow traffic handling characteristics that may be used by, e.g., an RRM functionality, such as a scheduler in a base station. The collective QoS requirements may then e.g. be monitored by considering contributions of all flows belonging to the collective service, and flow-specific and interflow traffic handling characteristics may be adjusted.

In the present disclosure, a collective service refers to a service which works by having contributions from multiple sources, referred to as flows and/or mobile devices herein, and where a contribution of a certain source is impacted by how the other sources are behaving. Non-limiting examples of collective services are a multi-modality service and a distributed Al-based service based, for example, on FL, SNN, etc.

Figure 3 shows example embodiments of a method performed by the network node 110, for handling multiple flows related to a same collective service in the wireless communications network 100. The network node 110 performing the method, e.g. comprises functionality to perform the method, and may e.g. be a RAN node part of e.g. Next Generation Radio Access Network (NG-RAN) such a Next Generation Node B (gNB), or a Centralized Unit (CU) or a Distributed Unit (DU) of a RAN node. The flows relate to data traffic flows. A data traffic flow may refer to a User Plane (UP) traffic or a Control Plane (CP) traffic.

The multiple flows may relate to any one out of: one mobile device 121 or multiple mobile devices 121 , 122, 123. This means that all multiple flows may relate to one mobile device 121 , or all the multiple flows may relate to respective different mobile devices 121, 122, 123. As an alternative, some of the multiple flows relate to one mobile device 121, and some other of the multiple flows may relate to respective different mobile devices 122, 123. The multiple flows may in examples be referred to as the flows F1 , F2, F3 and F4.

A flow in the multiple flows may reach from a source such as one of the mobile devices 121, 122, 123 via the network node 110 to the service node 130.

The method comprises the following actions, which actions may be taken in any suitable order. Optional actions are referred to as dashed boxes in Figure 3.

The actions described here will be described and exemplified more in detail below.

Action 301

The network node 110 obtains information data relating to the collective service. It should be noted the wordings “information”, “information data” and “collective QoS information” are supposed to have the same meaning and may be used interchangeable herein. The information data may be obtained from the service node 130. The information data identifies the multiple flows that are involved in the same collective service. One example is that the multiple flows are identified in a list of mobile devices 121, 122, 123 involved in the multiple flows. Another example is that the multiple flows are identified in a list of flow identifiers. Another example is that the information data identifying the multiple flows comprises an application ID. All flows whose traffic is associated to this application ID will be considered part of the collective service.

The information data further comprises collective QoS requirements for the collective service, to be fulfilled by considering contributions from the multiple flows.

The wording collective QoS requirements when used herein e.g. means requirements and parameters that are associated to QoS required by the collective service. The collective QoS requirements may e.g. comprise parameters that should be fulfilled in a collective manner, i.e. , considering the flows belonging to the collective service. The collective QoS requirements may be provided in the form of target QoS characteristics.

The information data further comprises information about inter-flow relationships between the multiple flows. The information about the inter-flow relationships between the multiple flows comprises, e.g., information on how the different flows contribute to the fulfilment of the collective QoS requirements.

The information about the inter-flow relationships between the multiple flows may comprise an indication of one or more flows from the multiple flows that contribute to the fulfilment of the collective QoS requirements and/or a manner of contribution of the one or more flows to the fulfilment of the collective QoS requirements.

Action 302

The network node 110 tags, e.g. by marking, each flow in the multiple flows related to the same collective service with an indicator. This is to indicate an association of the flow to the same collective service.

This is an advantage since it allows network node 110 to determine which flows are part of a certain collective service, and to consequently monitor the fulfillment of collective QoS requirements.

The indicator may be, for example, the collective service indicator (ID), a collective 5QI, or any other suitable indicator. The indicator may be preconfigured or set up through interactions such with network entities such as a Policy Control Function (PCF), an SMF, an Access and Mobility Function (AMF), where the indicator value could be configured through e.g. management system. The indicator may be associated to a certain flow from the multiple flows. In some cases, each flow may have its own flow information, e.g., 5QI X, plus an indicator of the collective service it is associated to, e.g., a collective flow ID, a collective 5QI, etc. Another example is that each flow may have only the collective service indicator.

Action 303

The network node 110 determines flow-specific characteristics and inter-flow characteristics based on the obtained information data. The flow-specific characteristics relate to flow-specific data traffic handling characteristics, and wherein the inter-flow characteristics relate to inter-flow data traffic handling characteristics.

In some embodiments the network node 110 determines the flow-specific characteristics by deriving single-flow data traffic handling characteristics for each data traffic flow out of the multiple flows of the collective service based on the information data related to. The network node 110 may determine the inter-flow characteristics by deriving inter-flow traffic handling characteristics.

The flow-specific characteristics and the inter-flow characteristics are derived based on the information data. Such information data comprises, e.g., collective QoS information and requirements, inter-flow relationships, and on network status information e.g., cell load, radio resource utilization, etc. Traffic handling characteristics may be, e.g., scheduling priority, target requirements, etc. Action 304

The network node 110 then handles the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics. These single-flow and inter-flow traffic handling characteristics may be, e.g., provided to an RRM functionality of a base station, such as e.g. the network node 110.

In some embodiments the handling of the multiple flows related to the collective service comprises that the network node 110 schedules the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics.

Action 305

In some embodiments the network node 110 decides whether or not the collective QoS requirements are fulfilled or are predicted to be fulfilled. The deciding is based on monitoring flow-specific performance of the multiple flows handled according to the determined flow-specific characteristics and inter-flow characteristics.

The wording collective QoS requirements are fulfilled means that the traffic exchanged by the multiple flows meets the QoS parameters and requirements defined by the collective service, latency is met, data rate is met, etc. The wording collective QoS requirements are predicted to be fulfilled may mean that, for example based on historical data on the same or similar collective service and/or based on processing of data related to same or similar collective service through e.g. Artificial Intelligence (Al) and/or Machine Learning (ML) tools, the traffic exchanged by the multiple flows is expected to meet the QoS parameters and requirements defined by the collective service in a certain upcoming time window.

The network node 110 may monitor the flow-specific performance of the multiple flows by collecting performance information of specific flows, e.g., data rate, latency, packet loss.

In some embodiments the the deciding of whether or not the collective QoS requirements are fulfilled or are predicted to be fulfilled based on monitoring flow-specific performance of the multiple flows handled according to the determined flow-specific characteristics and inter-flow characteristics, is repeated until the collective service is terminated. Action 306

In some embodiments the network node 110 adjusts the determined flow-specific characteristics and/or inter-flow characteristics based on the monitored flow-specific performance of the multiple flows, and e.g. based on the status of fulfillment of collective QoS requirements. This is an advantage since the adjustment is performed considering the overall set of flows belonging to the collective service, rather than the behavior of a single flow, i.e. , it gives the possibility to adjust the parameter of a certain flow based on the behavior of another flow in the same collective service, taking into consideration as final aim the fulfilment of the collective QoS requirements.

This may be performed repeatedly until the collective service is terminated. For example, the flow-specific performance of the multiple flows may be monitored until data traffic related to the collective service is ongoing.

In some embodiments this is performed when the network node 110 has decided that the collective QoS requirements are fulfilled or are predicted to be fulfilled.

The above method at least comprises two great advantages:

- From the service point of view, such as the service node 130 point of view, the perceived QoS will be higher, as the network such as the network node 110 has visibility of how all different traffic components, i.e. the determined flow-specific characteristics and inter-flow characteristics, related to the multiple flows influence the overall collective QoS. As a consequence, the network node 110 is capable of making more educated choices for the multiple flows when serving such traffic components.

- From the network point of view, such as the network node 110 point of view, it is possible to exploit the information data about collective QoS requirements, and also the determined flow-specific characteristics and inter-flow characteristics, for efficient network resource management, e.g., avoiding that too many resources are used for a certain mobile device if, for example, the collective QoS is not impacted by a temporary QoS unfulfillment of a single mobile device.

The above embodiments will now be further explained and exemplified below. The embodiments below may be combined with any suitable embodiment above.

Functionality for handling collective service According to embodiments herein, a mobile network such as the wireless communications network 100 is extended with the method, e.g. a functionality, performed in the network node 110 for handling collective services. An example of the functionality behaves as follows:

- The network node 110 receives collective QoS information data which includes information on which flows belong to the collective service, the collective QoS requirements of the collective service and the relationships among flows of the collective services.

- The network node 110 may mark the flows comprised in the multiple flows, to identify that they are part of the collective service. In this way, the entities in the wireless communications network 100 are aware that a certain traffic, i.e. in the multiple flows, is associated to a certain collective service. These entities may be, e.g., RAN nodes, or CU/lIP entities of a RAN node, or specific layer of the stack of a RAN node, or specific components of a RAN node such as a scheduler or a radio resource handler. These entities could be also, e.g., a Session Management Function (SMF), a UPF.

- The network node 110 derives single-flow traffic handling characteristics for each traffic flow of the collective service, as well as inter-flow traffic handling characteristics, based on collective QoS information and requirements, on inter-flow relationships, and on network status information e.g., cell load, radio resource utilization, etc. Traffic handling characteristics may be, e.g., scheduling priority, target requirements, etc. These single-flow and inter-flow traffic handling characteristics could be, e.g., provided to an RRM functionality of a base station such as the network node 110.

- The network node 110 may then gather information on single-flow performance to monitor fulfilment of collective QoS requirements based on collective QoS features. If required, single-flow and inter-flow traffic handling characteristics may be updated based on monitored performance of the collective service.

Figure 4 illustrates the method, such as the functionality 400, for handling the collective service introduced by embodiments of the present disclosure.

As shown in Figure 4, a network node, such as the network node 110, may receive 401 collective QoS information data such as, e.g., information on the multiple flows, here referred to as target flows, collective QoS requirements, and inter-flow relationships. This relates to and may be combined with Action 301 described above.

As shown in Figure 4, the functionality of handling the collection QoS information data tags, e.g., marks, 402 target flows belonging to the collective service. In this example, the multiple flows are represented by target flows F1 , F2, and F3 of three respective UEs UE1 , UE2, and UE3, belong to the collective service. In this example the first mobile device 121 is represented by UE1, the second mobile device 122 is represented by UE2, and the third mobile device 123 is represented by UE3. Thus, each of the target flows F1 , F2, and F3 is tagged with an indication such as a collective service ID, as shown schematically in Figure 4. In this way, the collective service ID is associated to the target flows F1, F2, and F3.

Traffic handling characteristics for each traffic flow and inter-flow relationships are derived 403 based on collective QoS information and collective QoS requirement fulfilment. As shown in Figure 4, the traffic handling characteristics and inter-flow relationships are derived for the flows F1, F2, and F3. This relates to and may be combined with Action 303 described above.

The functionality of handling the collection QoS information data may be associated 404 with e.g., an RRM and/or a scheduling functionality of a base station such as the network node 110 or associated with a functionality which interacts directly with an RRM/scheduling functionality. This relates to and may be combined with Action 304 described above.

Fulfilment of the collective QoS requirements is monitored 405, considering the inter-flow relationships. This relates to and may be combined with Action 305 described above.

Information data relating to the collective service - also referred to as Collective QoS information

This relates to and may be combined with Action 301 described above.

In the present disclosure, the network node 110 obtains information data relating to the collective service. The information data relating to the collective service is here referred to as collective QoS information. This refers to the multiple traffic flows, from the same mobile device 121 and/or from multiple mobile devices 121 , 122, 123. The collective QoS information means that the listed traffic flows are involved in the same collective service and thus there is a mutual dependency/relationship among the involved flows. The collective QoS information enriches information data on collective QoS requirements, i.e. , requirements that should be considered by jointly taking into account all traffic flows of the collective service. These collective QoS requirements are complemented by inter-flow relationships information, i.e., information on how the different flows belonging to the collective service contribute to the collective requirements. The information data relating to the collective service, e.g., the collective QoS information, may be provided to a network entity e.g., a PCF, then processed and provided to other network entities such as the network node 110, e.g., being any one or more out of: an SMF, a UPF, an AMF, RAN node, etc. The collective QoS information may be provided to the network node 110 by, e.g., an application function (AF) such as the service node 130 which interacts with an application server/client. The collective QoS information from the AF may be received by, e.g., a network exposure function (NEF) and then processed and provided to, e.g., a PCF, or it may be directly received by the PCF, and then finally provided to network entities such as the network node 110. The collective QoS information may be also provided to the network node 110, by e.g., one of the UEs belonging to the collective service, via, e.g., radio resource control (RRC) in case the network node 110 is a RAN node or via non-access stratum (NAS) signalling in case the network node 110 is an AMF.

The information data relating to the collective service, e.g. the collective QoS information data may include, but is not limited to, the following information data: i. Target flows, indicating which flows are to be considered as part of the collective service. This may be done in several ways. One example is that target flows are given as list of mobile devices 121, 122, 123, e.g., UE Identifiers (IDs) such as Generic Public Subscription Identifier (GPSI), Subscription Permanent Identifier (SlIPI), Internet Protocol (IP) address(es), 5-tuple, etc., together with information about which flows of the mobile devices 121 , 122, 123 that are relevant to the collective service, e.g., one or more 5Qls, one or more QoS Flows IDs, etc. Another example is that the target flows are given as list of flow identifiers, e.g., QoS Flows IDs. Another example is to use an application ID, and all flows whose traffic is associated to this application ID will be considered part of the collective service. ii. Collective QoS requirements, indicating key performance indicators (KPIs) or parameters that should be fulfilled in a collective manner, i.e., considering the flows belonging to the collective service. The collective QoS requirements may be provided in the form of target QoS characteristics, such as, e.g.: o collective GFBR. For services which require a certain minimum bitrate to be satisfied, this collective GFBR is intended as a minimum bitrate that satisfies the collective service if achieved with contributions from the target flows, e.g., obtained from aggregating the bit rates of different flows. o collective MFBR. For services which are bitrate-adaptive, this collective MFBR is intended as a maximum bitrate that satisfies the collective service if achieved with contributions from the target flows. o collective maximum packet losses. For services which are sensitive to losses, this collective maximum packet losses is intended as a maximum packet losses tolerated by the collective service computed by considering the target flows. o Collective delay budget. For services which are latency-sensitive, this collective delay budget is intended the maximum packet delay budget tolerated by the target flows belonging to the collective service. o Collective synchronization delay budget. For services which require a certain level of synchronization among the flows of the service, this collective synchronization delay budget is intended as the maximum delay difference which is tolerated among data of two or more different target flows. For example, with a collective synchronization delay budget of X ms, if the network receives a packet from a target flow A, then the collective service would consider beneficial if a packet from a target flow B is received by X ms from the reception of the packet of the target flow A - otherwise, the packet from target flow B is not useful for the collective service.

It should be noted that the wordings “flow” and “target flow” are used interchangeable herein. o Collective survival time. For services which are QoS-sensitive, the collective survival time is intended to indicate how long the collective service can survive if the collective QoS requirements are not met.

In some cases, the collective QoS requirements may be provided in the form of an order list, where a first set of collective QoS requirements may be main collective QoS requirements to be fulfilled, the second set of collective QoS requirements may be the first alternative collective QoS requirements to be fulfilled if the main collective QoS requirements are not met, the third set of collective QoS requirements may be the second alternative collective QoS requirements to be fulfilled if the second collective QoS requirements are not met, and so on. iii. Inter-flow relationships, an additional information on how the different target flows contribute to the fulfilment of the collective QoS requirements. Non-limiting examples are: o Any target indication, indicating that the collective QoS requirement is considered as fulfilled if any of the indicated targets contribute to the fulfilment of the QoS requirement with no difference in terms of how they contribute. This feature indicates that the wireless communications network 100 may prioritize any of the target flows to fulfil the collective QoS requirement, i.e. , the fulfilment is independent from how a single flow contributes to it. o Equal target indication, indicating that the collective QoS requirement is considered as fulfilled if any of the indicated targets contribute to the fulfilment of the requirement, but, in this case, the indicated targets should contribute in the same way to fulfilment. This feature indicates that all flows indicated as target have the same importance in the fulfilment, and the fulfilment depends on how a single flow contributes to it. o Most active target indication, indicating that the collective QoS requirement is considered as fulfilled if most active flows (e.g., the ones which have been sending most of the traffic) contribute to the target.

The target indication used above indicates which flows contribute to the fulfilment of the collective QoS requirements. Examples of target indication include, but not limited to, the following: iv. A list of specific target flows (GPSI, SlIPI, QoS Flow ID, etc.). In this case, the fulfilment of collective QoS requirements is related to the contribution of specific UEs/flows. v. A percentage value %. In this case, the fulfilment of collective QoS requirements is related to the contribution of a certain percentage of UEs/flows. For example, if the collective service is composed by 10 flows, a target indication of 50% indicates that the collective QoS requirements are met if at least 50% of the target flows (no matter which) contribute to its fulfilment. vi. A number of target flows X. In this case, the fulfilment of collective QoS requirements is related to the contribution of a certain numbers of UEs/flows. For example, if the collective service is composed by 10 flows, a target indication of 5 indicates that the collective QoS requirements are met if at least 5 of the target flows (no matter which) contribute to its fulfilment. It should be noted that each collective QoS requirement may have its own collective QoS feature, in which case they may be provided as a list comprising Collective QoS requirement, Collective QoS feature.

Examples of information data relating to the collective service, e.g., collective QoS information data:

Collective GFBR, AnyX% - indicates that the collective QoS requirement is fulfilled if any X%, no difference which, of the target flows contribute to the fulfilment of the requirement with no difference in terms of how they contribute. As there is no difference, the mobile network, such as the network node 110 may, e.g., select the most performing flows, the ones requiring less radio resources, etc. Considering an example with collective GFBR of, e.g., 10Mbps and four target flows F1 , F2, F3 and F4, for example, Any 0% may indicate that the collective GFBR is fulfilled if the aggregated bit rate is reached no matter which flow contributed to and no matter how much contributed to. In another example, “Any 50%” indicates that the collective GFBR is fulfilled if the aggregated bit rate is reached with at least 50% of the flows contributing and no matter how much they contributed. For example, if e.g. the flow F1 and the flow F2 reach a bit rate of 5Mbps, the flow F3 and the flow F4 reach a bit rate of 0Mbps. In a further example, “Any 100%” may indicate that the collective GFBR is fulfilled if all flows transmit something but no matter how they contributed, e.g., if e.g. the flow F1 reaches a bit rate of 5Mbps, the flow F2 of 3Mbps, the flow F3 of 2Mbps, and the flow F4 of 1Mbps.

Collective GFBR, Equal X% - indicates that the collective QoS requirement is fulfilled when X% (no matter which) of the target flows contribute to the fulfilment of the requirement but with X% of the flows contributing in the same way to the fulfilment. Considering an example with collective GFBR of e.g. 10Mbps and four target flows F1, F2, F3, and F4, for example, “Equal 50%” may indicate that the collective GFBR is fulfilled if 50% of the target flows contribute in the same way to the fulfilment. For example, if e.g. the flow F1 and the flow F2 reach a bit rate of 5Mbps and the flow F3 and the flow F4 reach a bit rate of 0Mbps, or if e.g. the flow F3 and the flow F4 reach a bit rate of 5Mbps and F1 and F2 reach a bit rate of 0Mbps. In this case, “Equal 100%” may indicate that the collective GFBR is fulfilled only if e.g. each of the flows F1 , F2, F3, and F4 reaches a bit rate of 2.5Mbps. Collective GFBR, Most active X% - indicates that the collective QoS requirement is fulfilled if X% of the most active flows contribute to the fulfilment of the requirement with no difference in terms of how they contribute. Considering an example with collective GFBR of e.g. 10Mbps and four target flows F1 , F2, F3, and F4, for example, “Most active 0%” may indicate that the collective GFBR is fulfilled if the flow F1 and the flow F2 contribute to achieving an aggregated bit rate of 10Mbps, assuming that the flow F1 and the flow F2 have been the most active flows in a certain time window.

Collective delay budget, AnyX% - for example, with collective delay budget of e.g. 10ms and four target flows F1 , F2, F3, and F4, for example, “Any 50%” indicates that the collective delay budget is fulfilled if at least 50% of the flows belonging to the collective service have a packet delay budget lower than 10ms, and the remaining 50% may exceed such threshold without affecting the collective QoE.

In should be noted that, in the example above, target indication is considered from the point of view of a percentage value by way of example only, but different approaches, e.g., explicit reference to target flows, numbers of target flows, etc., may be considered as well.

It should further be noted that, for an ongoing collective service, the information data, e.g., the collective QoS information, may be updated. In this case, the following may be indicated:

(i) which collective service, e.g. identified by a collective service ID, or which collective QoS requirements, e.g. identified by a collective QoS Flow ID, should be modified;

(ii) the type of modification, e.g., one or more of addition, removal, and modification; and

(iii) the collective QoS information or part of the collective QoS information. For example, new target flows may be added or removed, collective QoS requirements may be modified or removed, or new requirements added, and collective QoS features may be modified or removed, or new features added.

Usage of the method, such as the functionality, for handling collective services in a wireless communications network In some embodiments, the functionality is performing the method. The functionality may be co-located with the network node 110 or be accessible by, e.g., associated to, the network node 110 for performing the method.

An example embodiment of the method, e.g., the functionality, for handling collective services may be used by the wireless communications network 100 in the following ways:

(i) Collective service such as the service node 130, e.g., AF, provides and/or updates collective QoS information (target flows, collective QoS requirements, inter-flow relationships, etc.) or collective service requirements. Such information may be received by e.g., a PCF, and then processed and provided to the network node 110, which network node 110 may e.g., comprise any one or more out of an SMF, a UPF, an AMF, and a RAN node. This relates to and may be combined with Action 301 described above.

(ii) The mobile network, such as the network node 110, instantiates a functionality to handle the collective service. This functionality may be instantiated depending on the network location of the flows, e.g. the target flows. For example, if all flows are associated to the mobile devices 121 , 122, 123 attached to the same cell or base station, e.g. the network node 110, the functionality may be instantiated at the target base station, e.g. the network node 110. If the target flows belong to the mobile devices 121, 122, 123 being attached to multiple base stations, e.g., one of them the network node 110, multiple instances of this functionality may be created and may be tailored depending on which flows are attached to a certain base station. This functionality may be associated to e.g., an RRM or a scheduling functionality of a base station such as the network node 110 or associated to a functionality which interacts directly with an RRM/scheduling functionality.

(iii) The functionality may trigger the network node 110 to mark the traffic flows to identify that they are part of the collective service. In this way, the mobile network such as the wireless communications network 100, is aware of which flows belong to the collective service. The marking may be done by introducing a new tag specific to the collective service, e.g., a specific collective flow ID, a specific collective 5QI, etc. This tag may be associated to the flow, e.g., the target flow, of the collective service. For example, each flow may have associated the tag with its own flow information, e.g., 5QI X, plus an indication of the collective service it is associated to, e.g., a collective flow ID, a collective 5QI, etc. As another example, each flow may have only the collective service indication, e.g., a collective flow ID, a collective 5QI, etc. A pre-configured 5QI may also be used to indicate a collective flow. This relates to and may be combined with Action 304 described above.

(iv) The network node 110 derives single-flow traffic handling characteristics for each traffic flow of the collective service, as well as inter-flow traffic handling characteristics based on the collective QoS information and on inter-flow relationships. This relates to and may be combined with Action 303, described above. Traffic handling characteristics may be, e.g., priorities, QoS characteristics, parameters to be fulfilled, parameters to be monitored, etc. These single-flow and inter-flow traffic handling characteristics may be, e.g., provided to an RRM functionality of a base station, such as e.g., the network node 110.

For example, if the collective QoS requirement indicates a collective GFBR: XMbps, Equal 100%> for the multiple flows F1 , F2, F3, and F4, then the network node 110, e.g. its functionality, may: (i) set a GFBR of X/4 Mbps for F1 , F2, F3, and F4; (ii) indicate that collective GFBR is the parameter to monitor; (iii) and indicate that the collective GFBR is fulfilled only if each of the flows contributes with at least X/4 Mbps.

Another example is that the information data, e.g., the collective QoS information, may indicate a collective GFBR of, e.g. 10Mbps with an inter-flow relationship “Equal 100%”. If only the flow F1 is present in the collective service, the functionality may set the GFBR for F1 to 10Mbps. But if, for instance, the flow F2 is added to the collective service, then the network node 110, may adjust, also referred to as modify, the GFBR of the flow F1 to 5Mbps and set the GFBR of the flow F2 to 5 Mbps.

The adjustment may be also in the form of adding new QoS characteristics to a certain flow. Considering the previous example, instead of modifying the GFBR of the flow F1 from 10Mbps to 5Mbps, the network node 110 may decide to add an alternative QoS service to the flow F1 with GFBR of 5Mbps, so, the flow F1 will have a main QoS profile with GFBR of 10Mbps and an alternative QoS Profile with GFBR of 5Mbps, and similarly for the flow F2.

It may be noted that, for the sake of fulfilment checking, the adjustment of the QoS information for the target flows may also include enabling features such as, e.g., notification control. For example, if the collective service involving the flow F1 and the flow F2 has a collective GFBR of 10Mbps with an inter-flow relationship “Equal 100%”, the functionality may trigger a subscription to notification control for the flow F1 and the flow F2, and the notification control information may be provided to the functionality aimed at checking the collective QoS requirement fulfilment. In this case, the collective service may not need to update the QoS information of each single flow in the collective service at any group modification, as this will be done automatically by the mobile network such as the network node 110.

See Action 305 above relating to the monitoring, and Action 306 above for the adjusting.

(v) The traffic of flows associated to the collective service may be handled by the network node 110, such as an RRM of the network node 110, by using the single-flow and inter-flow traffic handling characteristics. For example, considering a collective service with the multiple flows F1 , F2, F3 with a collective GFBR requirement of 10Mbps with an inter-flow relationship “Any 50%”, this may be translated with e.g., GFBR for the flows F1 , F2, and F3 equal to 5Mbps. This is to increase the probability that the collective GFBR will be met. But, if there are resources for, e.g., the flow F1 to transmit 10Mbps and for F2 to transmit 5Mbps, then the functionality understands that the collective GFBR is already met, as more than 50% of the flows in the collective service are contributing to the GFBR. Consequently, the RRM may use the inter-flow traffic handling characteristic such that the flow F3 may avoid being scheduled if the GFBR is already met with contributions from other flows. This relates to and may be combined with Action 304 described above

(vi) The network node 110, such as its functionality, for handling collective service gathers single-flow performance information and monitors fulfilment of collective QoS requirements, considering inter-flow relationship. If the network node 110 understands that collective QoS requirements cannot be met with current single-flow traffic handling, it may adjust the traffic handling characteristics for single-flow and interflow, e.g., flow-specific QoS characteristics, scheduling, etc., based on the monitored collective QoS. See Action 305 above relating to the monitoring, and Action 306 above for the adjusting.

A visual representation of how a mobile network, e.g., the network node 110, may make use of the method in accordance with the present disclosure is shown in Figure 5.

As shown in Figure 5, the collective service, e.g., AF, provides and/or updates 501 collective QoS information data, such as, e.g., target flows collective QoS requirements, and inter-flow relationships. The network node instantiates and/or updates 502 functionality for handling the collective service traffic, e.g., traffic handling, monitoring, etc., based on the collective services information. These relate to and may be combined with Action 301 described above (Figure 3).

The network note tags, e.g. marks 503 traffic flows to identify that they are part of the collective service. This relates to and may be combined with Action 302 described above (Figure 3).

The network node then derives and updates 504 traffic handling characteristics for each traffic flow and inter-flow relationships of the collective service based on the collection QoS information and the collective QoS requirements fulfilment. These relate to and may be combined with Actions 303, 304, 305, and 306, described above (Figure 3).

The network node obtains or gathers 505 information on QoS fulfilment of the flows belonging to the collective service and monitors 506 fulfilments of the collective QoS requirements considering inter-flow relationships. This relates to and may be combined with Action 305, described above (Figure 3).

If the collective QoS requirements cannot be met 507 with the current traffic handling, or if they need to be updated for some reasons, the traffic handling characteristics are updated 504, as shown in Figure 5. This relates to and may be combined with Actions 305 and 306, described above (Figure 3).

Considering the above-discussed problems of handling multi-flow services using the legacy QoS framework, embodiments herein may help in the following way when the serving mobile devices 121, 122, 123 belong to the same collective service:

• When only one mobile device, e.g., the mobile device 121 , is in bad channel conditions, to meet the bitrate requirements for such mobile device 121 , the network node 110 may allocate a high number of resources, due to the need for using a very robust Modulation and Coding scheme (MCS). But, by doing, so there will not be enough resources for the other mobile devices 122, 123 to meet their bitrate requirements. In this case, the network node 110 may decide to not schedule the mobile device 121 as, by doing so, it will be possible to schedule all remaining mobile devices 122, 123 with enough resources for achieving, e.g., their target bitrate.

• When the wireless communications network 100 is getting congested, queues are raising, and packets should be dropped. Here, the network node 110 may decide to drop only packets of a mobile device and/ or a flow which does not belong to the collective service, to avoid that many flows will be affected by losses as they are jointly contributing to a collective service.

• When the wireless communications network 100 is getting congested, queues are raising, and packets start to experience high delay, and are getting close to going above their PDB budget. Similarly to the previous case, to free up queues, the network node 1120 may decide to drop only packets of a mobile device and/ or a flow which does not belong to the collective service. This is to avoid that many flows will be affected by a higher latency or even losses if packets beyond PDB are useless for the application as they are jointly contributing to the collective service.

To perform the method actions above, the network node 110 is configured to handle multiple flows related to a same collective service in a wireless communications network 100, wherein the multiple flows are adapted to relate to data traffic flows.

The network node 110 may comprise an arrangement depicted in Figures 6a and 6b.

The network node 110 may comprise an input and output interface 600 configured to communicate in the wireless communications network 100, e.g. with any one or more out of the mobile devices 121 , 122, 123, and with any other devices in the wireless communications network 100, such as the service node 130. The input and output interface 600 may comprise a wireless receiver (not shown) and a wireless transmitter (not shown).

The network node 110 may further be configured to, e.g., by means of an obtaining unit 601 in the network node 110, obtain information data relating to the collective service and identifying the multiple flows that are involved in the same collective service. The information data further is adapted to comprise:

- collective QoS requirements for the collective service, adapted to be fulfilled by considering contributions from the multiple flows, and

- information about inter-flow relationships between the multiple flows.

The multiple flows may be adapted to relate to any one out of: one mobile device, e.g., the mobile device 121, or multiple mobile devices, e.g., mobile devices 121, 122, 123. The information about inter-flow relationships between the multiple flows may be adapted to comprise an indication of one or more flows from the multiple flows that contribute to the fulfilment of the collective QoS requirements and/or a manner of contribution of the one or more flows to the fulfilment of the collective QoS requirements.

The network node 110 may further be configured to, e.g., by means of a tagging unit 602 in the network node 110, tag, e.g. mark, each flow in the multiple flows related to the same collective service with an indicator, to indicate an association of the flow to the same collective service.

The network node 110 may further be configured to, e.g., by means of a determining unit 603 in the network node 110, determine flow-specific characteristics and inter-flow characteristics based on the obtained information data. The flow-specific characteristics are adapted to relate to flow-specific data traffic handling characteristics, and wherein the inter-flow characteristics are adapted to relate to inter-flow data traffic handling characteristics.

The network node 110 may further be configured to, e.g., by means of a handling unit 604 in the network node 110, handle the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics. The network node may be configured to handle the multiple flows related to the collective service by scheduling the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics.

The network node 110 may further be configured to, e.g., by means of a deciding unit 605 in the network node 110, decide whether or not the collective QoS requirements are fulfilled or are predicted to be fulfilled based on monitoring flow-specific performance of the multiple flows handled according to the determined flow-specific characteristics and inter-flow characteristics. The deciding may be performed repeatedly, until the collective service is terminated.

The network node 110 may further be configured to, e.g., by means of an adjusting unit 606 in the network node 110, any one out of: when decided that the collective QoS requirements are fulfilled or are predicted to be fulfilled, adjust the determined flow-specific characteristics and/or inter-flow characteristics based on the monitored flow-specific performance of the multiple flows; or adjust the determined flow-specific characteristics and inter-flow characteristics based on the monitored flow-specific performance of the multiple flows.

The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor 660 of a processing circuitry in the network node 110 depicted in Figure 6a, together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the network node 110. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the network node 110.

The network node 110 may further comprise a memory 670 comprising one or more memory units. The memory 670 comprises instructions executable by the processor in network node 110. The memory 670 is arranged to be used to store e.g. information, indications, data, configurations, device types, device information, feature tags, communication data, and applications to perform the methods herein when being executed in the network node 110.

In some embodiments, a computer program 680 comprises instructions, which when executed by the respective at least one processor 660, cause the at least one processor of the network node 110 to perform the actions above.

In some embodiments, a respective carrier 690 comprises the respective computer program 680, wherein the carrier 690 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

Those skilled in the art will appreciate that the units in the network node 110 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the network node 110, that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry ASIC, or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a- chip SoC.

With reference to Figure 7, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, e.g. the wireless communications network 100, which comprises an access network 3211, such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c, e.g. radio network nodes 141,142, is connectable to the core network 3214 over a wired or wireless connection 3215. A first user equipment (UE), e.g. mobile device 121, 122, 123, or the network node 110, such as a Non-AP STA 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 such as a Non-AP STA in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291, 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud- implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221, 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).

The communication system of Figure 7 as a whole enables connectivity between one of the connected UEs 3291 , 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291 , 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211 , the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Figure 8. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311 , which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Figure 8) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Figure 8) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, applicationspecific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331, which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides. It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Figure 8 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291 , 3292 of Figure 7, respectively. This is to say, the inner workings of these entities may be as shown in Figure 8 and independently, the surrounding network topology may be that of Figure 7.

In Figure 8, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the use equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the RAN effect: data rate, latency, power consumption and thereby provide benefits such as e.g. the applicable corresponding effect on the OTT service: reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311 , 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311, 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Figure 9 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 7 and Figure 8. For simplicity of the present disclosure, only drawing references to Figure 9 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional sub step 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 3440, the UE executes a client application associated with the host application executed by the host computer.

Figure 10 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 7 and Figure 8. For simplicity of the present disclosure, only drawing references to Figure 10 will be included in this section. In a first step 3510 of the method, the host computer provides user data. In an optional sub step (not shown) the host computer provides the user data by executing a host application. In a second step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 3530, the UE receives the user data carried in the transmission.

Figure 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 7 and Figure 8. For simplicity of the present disclosure, only drawing references to Figure 11 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 3620, the UE provides user data. In an optional sub step 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional sub step 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third sub step 3630, transmission of the user data to the host computer. In a fourth step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Figure 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to Figure 7 and Figure 8. For simplicity of the present disclosure, only drawing references to Figure 12 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.

When using the word "comprise" or “comprising” it shall be interpreted as nonlimiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the preferred embodiments described above. Various alternatives, modifications and equivalents may be used.

Claims

CLAIMS A method performed by a network node (110), for handling multiple flows related to a same collective service in a wireless communications network (100), and which flows relate to data traffic flows, the method comprising: obtaining (301) information data relating to the collective service and identifying the multiple flows that are involved in the same collective service, which information data further comprises:

- collective Quality of Service, QoS, requirements for the collective service, to be fulfilled by considering contributions from the multiple flows, and

- information about inter-flow relationships between the multiple flows, determining (303) flow-specific characteristics and inter-flow characteristics based on the obtained information data, wherein the flow-specific characteristics relate to flow-specific data traffic handling characteristics, and wherein the inter-flow characteristics relate to inter-flow data traffic handling characteristics, and handling (304) the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics. The method according to claim 1 , wherein the information about inter-flow relationships between the multiple flows comprises an indication of one or more flows from the multiple flows that contribute to the fulfilment of the collective QoS requirements and/or a manner of contribution of the one or more flows to the fulfilment of the collective QoS requirements. The method according to claim 1 or claim 2, wherein the handling (304) of the multiple flows related to the collective service comprises scheduling the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics. The method according to any of the claims 1-3, further comprising: deciding (305) whether or not the collective QoS requirements are fulfilled or are predicted to be fulfilled based on monitoring flow-specific performance of the multiple flows handled according to the determined flow-specific characteristics and inter-flow characteristics.

5. The method according to claim 4, wherein: the deciding (305) of whether or not the collective QoS requirements are fulfilled or are predicted to be fulfilled based on monitoring flow-specific performance of the multiple flows handled according to the determined flowspecific characteristics and inter-flow characteristics, is repeated until the collective service is terminated.

6. The method according to claim 4 or claim 5, further comprising any one out of: when decided that the collective QoS requirements are fulfilled or are predicted to be fulfilled, adjusting (306) the determined flow-specific characteristics and/or inter-flow characteristics based on the monitored flowspecific performance of the multiple flows; or adjusting (306) the determined flow-specific characteristics and inter-flow characteristics based on the monitored flow-specific performance of the multiple flows.

7. The method according to any of the claims 1-6, further comprising tagging (302) each flow in the multiple flows related to the same collective service with an indicator, to indicate an association of the flow to the same collective service.

8. The method according to any of the claims 1-7, wherein the multiple flows relate to any one out of: one mobile device (121) or multiple mobile devices (121 , 122, 123).

9. A computer program (680) comprising instructions, which when executed by a processor (660), causes the processor (660) to perform actions according to any of the claims 1-8.

10. A carrier (690) comprising the computer program (680) of claim 9, wherein the carrier (690) is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

11 . A network node (110) configured to handle multiple flows related to a same collective service in a wireless communications network (100), and which flows are adapted to relate to data traffic flows, the network node being configured to: obtain information data relating to the collective service and identifying the multiple flows that are involved in the same collective service, which information data further is adapted to comprise:

- collective Quality of Service, QoS, requirements for the collective service, adapted to be fulfilled by considering contributions from the multiple flows, and

- information about inter-flow relationships between the multiple flows, determine flow-specific characteristics and inter-flow characteristics based on the obtained information data, wherein the flow-specific characteristics are adapted to relate to flow-specific data traffic handling characteristics, and wherein the inter-flow characteristics are adapted to relate to inter-flow data traffic handling characteristics, and handle the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics.

12. The network node (110) according to claim 11 , wherein the information about interflow relationships between the multiple flows is adapted to comprise an indication of one or more flows from the multiple flows that contribute to the fulfilment of the collective QoS requirements and/or a manner of contribution of the one or more flows to the fulfilment of the collective QoS requirements.

13. The network node (110) according to claim 11 or claim 12, wherein the network node is configured to handle the multiple flows related to the collective service by scheduling the multiple flows related to the collective service according to the determined flow-specific characteristics and inter-flow characteristics.

14. The network node (110) according to any of the claims 11-13, wherein the network node is further configured to: decide whether or not the collective QoS requirements are fulfilled or are predicted to be fulfilled based on monitoring flow-specific performance of the multiple flows handled according to the determined flow-specific characteristics and inter-flow characteristics.

15. The network node (110) according to claim 14, wherein the network node is further configured to: repeatedly decide whether or not the collective QoS requirements are fulfilled or are predicted to be fulfilled based on monitoring flow-specific performance of the multiple flows handled according to the determined flow-specific characteristics and inter-flow characteristics, until the collective service is terminated. The network node (110) according to claim 14 or claim 15, wherein the network node is further configured to any one out of: when decided that the collective QoS requirements are fulfilled or are predicted to be fulfilled, adjust the determined flow-specific characteristics and/or inter-flow characteristics based on the monitored flow-specific performance of the multiple flows; or adjust the determined flow-specific characteristics and inter-flow characteristics based on the monitored flow-specific performance of the multiple flows. The network node (110) according to any of the claims 11-16, wherein the network node is further configured to tag each flow in the multiple flows related to the same collective service with an indicator, to indicate an association of the flow to the same collective service. The network node (110) according to any of the claims 11-17, wherein the multiple flows are adapted to relate to any one out of: one mobile device (121) or multiple mobile devices (121 , 122, 123).