WO2017074362A1

WO2017074362A1 - Multi-level data rate control for wireless networks

Info

Publication number: WO2017074362A1
Application number: PCT/US2015/057859
Authority: WO
Inventors: Anand Bedekar; Samuli Heikki TURTINEN; Christian Mahr
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2015-10-28
Filing date: 2015-10-28
Publication date: 2017-05-04

Abstract

A technique is provided for providing a multi-level data rate control for a service flow within a wireless network, the technique including: sending, by a network convergence service to one or more data providers, a first level data rate limit for a service flow, receiving, by the network convergence service from the one or more data providers, data for the service flow, applying, by the network convergence service, a second level data rate limit for the service flow, and forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

Description

Multi-Level Data Rate Control For Wireless Networks

TECHNICAL FIELD

[0001] This description relates to communications.

BACKGROUND

[0002] A communication system may be a facility that enables communication between two or more nodes or devices, such as fixed or mobile communication devices. Signals can be carried on wired or wireless carriers.

[0003] An example of a cellular communication system is an architecture that is being standardized by the 3^rd Generation Partnership Project (3 GPP). A recent development in this field is often referred to as the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology. E- UTRA (evolved UMTS Terrestrial Radio Access) is the air interface of 3GPP's Long Term Evolution (LTE) upgrade path for mobile networks. In LTE, base stations or access points (APs), which are referred to as enhanced Node AP (eNBs), provide wireless access within a coverage area or cell. In LTE, mobile devices, or mobile stations are referred to as user equipments (UE). LTE has included a number of improvements or developments. [0004] A global bandwidth shortage facing wireless carriers has motivated the consideration of the underutilized millimeter wave (mm Wave) frequency spectrum for future broadband cellular communication networks, for example. mmWave (or extremely high frequency) may, for example, include the frequency range between 30 and 300 gigahertz (GHz). Radio waves in this band may, for example, have

wavelengths from ten to one millimeters, giving it the name millimeter band or millimeter wave. The amount of wireless data will likely significantly increase in the coming years. Various techniques have been used in attempt to address this challenge including obtaining more spectrum, having smaller cell sizes, and using improved technologies enabling more bits/s/Hz, and/or allowing a more efficient use of resources. One element that may be used to obtain more spectrum is to move to higher

frequencies, above 6 GHz. For fifth generation wireless systems (5G), an access architecture for deployment of cellular radio equipment employing mm Wave radio spectrum has been proposed. Other example spectrums may also be used, such as cm Wave radio spectrum (3-30 GHz).

SUMMARY

[0005] According to an example implementation, a method may include sending, by a network convergence service to one or more data providers, a first level data rate limit for a service flow; receiving, by the network convergence service from the one or more data providers, data for the service flow; applying, by the network convergence service, a second level data rate limit for the service flow; and forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

[0006] According to another example implementation, an apparatus may include at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: send, by a network convergence service to one or more data providers, a first level data rate limit for a service flow; receive, by the network convergence service from the one or more data providers, data for the service flow; apply, by the network convergence service, a second level data rate limit for the service flow; and forward, by the network convergence service, data for the service flow within the second level data rate limit. .

[0007] According to another example implementation, a computer program product may include a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method including sending, by a network convergence service to one or more data providers, a first level data rate limit for a service flow; receiving, by the network convergence service from the one or more data providers, data for the service flow; applying, by the network convergence service, a second level data rate limit for the service flow; and forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

[0008] According to an example implementation, an apparatus may include means for sending, by a network convergence service to one or more data providers, a first level data rate limit for a service flow; means for receiving, by the network convergence service from the one or more data providers, data for the service flow;

means for applying, by the network convergence service, a second level data rate limit for the service flow; and means for forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

[0009] The details of one or more examples of implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 is a block diagram of a wireless network according to an example implementation.

[0011 ] FIG. 2 A is a block diagram of a wireless network 260 according to another example implementation.

[0012] FIG. 2B is a block diagram of a wireless network 200 according to another example implementation.

[0013] FIG. 3 is a flow chart illustrating operation of a network convergence service according to an example implementation.

[0014] FIG. 4 is a flow chart illustrating operation of a data rate control for a downlink bit rate control according to an example implementation.

[0015] FIG. 5 is a flow chart illustrating operation of an uplink data rate control according to an example implementation.

[0016] FIG.6 is a block diagram of a wireless station or network device (e.g., base station/access point or mobile station/user device/user equipment or other device) according to an example implementation.

DETAILED DESCRIPTION

[0017] FIG. 1 is a block diagram of a wireless network 130 according to an example implementation. In the wireless network 130 of FIG. 1, user devices 131, 132, 133 and 135, which may also be referred to as mobile stations (MSs) or user equipment (UEs), may be connected (and in communication) with a base station (BS) 134, which may also be referred to as an Access Point (AP) or an enhanced Node B (eNB). At least part of the functionalities of a base station (BS), access point (AP) or (e)Node B (eNB) may be also be carried out by any node, server or host which may be operably coupled to a transceiver, such as a remote radio head. BS 134 provides wireless coverage within a cell 136, including to user devices 131, 132, 133 and 135. Although only four user devices are shown as being connected or attached to BS 134, any number of user devices may be provided. BS 134 is also connected to a core network 150 via a SI interface 151. This is merely one simple example of a wireless network, and others may be used.

[0018] A user device (or user terminal, or user equipment (UE)) may refer to a portable computing device that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (MS), a mobile phone, a cell phone, a smartphone, a personal digital assistant (PDA), a handset, a device using a wireless modem (alarm or measurement device, etc.), a laptop and/or touch screen computer, a tablet, a phablet, a game console, a notebook, and a multimedia device, as examples. It should be appreciated that a user device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A user device may also be referred to herein as a user equipment (UE).

[0019] In LTE (as an example), core network 150 may be referred to as Evolved Packet Core (EPC), which may include a mobility management entity (MME) which may handle or assist with mobility/handover of user devices between BSs, one or more gateways that may forward data and control signals between the BSs and packet data networks or the Internet, and other control functions or blocks.

[0020] The various example implementations may be applied to a wide variety of wireless technologies or wireless networks, such as LTE, LTE-A, 5G, cm Wave, and/or mm Wave band networks, or any other wireless network. LTE, 5G, cmWave and mm Wave band networks are provided only as illustrative examples, and the various example implementations may be applied to any wireless technology/wireless network.

[0021] According to an example implementation, a multi-level (e.g., two-level) data rate control for a service flow is provided for a wireless network. In an example implementation, the service flow may include a plurality of sub-flows. A first level data rate limit may be used by a data provider to limit a data rate for the service flow.

However, the data provider may not be aware of the various sub-flows for the service flow, nor the QoS parameters or requirements for each sub-flow. Thus, the data provider may not be sub-flow aware. Thus, in the event that the data received by the data provider exceeds the first level data rate limit, the data provider may discard or drop one or more data packets for the service flow, without regard to sub-flows and the QoS information for each sub-flow. A network convergence service (NCS) may receive data from a data provider. The NCS may implement a second level data rate limit for the service flow. In an example implementation, the NCS may be aware of the various sub-flows for the service flow and other information for the wireless network. The NCS may, for example, receive and classify each received packet as being for or associated with one of the sub- flows. And, if the data rate at the NCS exceeds the second level data rate limit for the service flow, the NCS may selectively perform rate limiting, e.g., delay, drop or discard data for one sub-flow (e.g., a lower priority sub-flow) instead of delaying,

discarding/dropping data for another sub-flow (e.g., a higher priority, or higher QoS sub- flow). Further example details will be described herein.

[0022] FIG. 2 A is a block diagram of a wireless network 260 according to another example implementation. In this illustrative example, one or more data sources 262, such as data source 262A and 262B, may generate data for one or more service flows to be sent to one or more data providers 264, which may include data providers 264A, 264B, 264C, for example. According to an example implementation, a service flow may include, for example, data or packets for Internet traffic directed to one data destination 270 (for example) or alternatively that may be directed to multiple destinations. This is merely an example of a service flow, and other types of service flows may be used. In an example implementation, in the downlink (DL) direction of data flow, an example data source 262 may be an application or program running on a computer, a server, a network or in the cloud. While, for example, in the uplink (UL) direction of data flow, an example data source 262 may be a UE/user device, for example. The various examples described herein are provided as illustrative examples, and the various implementations are not limited thereto.

[0023] Each service flow may include one or more sub-flows, where each sub- flow may include data for a particular application or service, for example. Some example sub-flows may include data/traffic for one or more of the following example

applications/services (e.g., to/from a UE that may be running the application): an email application, a streaming video application, a streaming audio (or streaming music) application, a Web browser, a messaging application, a video conferencing application, etc. In some cases, traffic or data packets may be identified for these sub-flows based on one or more fields of each packet, such as based on an address or port number, an application identifier, a protocol identifier, etc., or other information that may be included in the data packets. Each sub-flow may include a QoS, which may include one or more of the following parameters, for example: a priority of the data for the sub-flow; a subscription level (e.g., a priority subscription level, or a normal subscription level for wireless service or network service) for the sub-flow; a requested data rate; a maximum number of hops; a maximum latency; an average data rate; a maximum or peak data rate; and a maximum packet error rate, as some example QoS parameters. NCS 266 may perform packet forwarding, and may also perform rate limiting by delaying forwarding of packets and/or packet dropping/discarding (in the event that data exceeds the second level data rate limit) based on the QoS for each sub-flow, for example. Each UE.may also include a NCS entity.

[0024] Referring again to FIG. 2A, a plurality of data providers 264 are shown, including, e.g., data providers 264A, 264B and 264C. Each data provider 264 (e.g., 264A, 264B, 264C, ...) may receive, from one or more data sources (directly or indirectly), data for one or more service flows. Each data provider may receive data for one or more sub-flows of the service flow. However, in an illustrative example implementation, each data provider may not be sub-flow aware. That is, each data provider 264 A, 264B, 264C may not be aware of the various sub-flows within a service flow (e.g., the data provider(s) 264 may not necessarily know the packet field(s) that indicate or identify each sub-flow, nor review one or more fields of each received packet to classify each packet into one of a plurality of sub-flows). As a result, if the received data at data provider 264A (for example) exceeds the first level data rate limit for the service flow, the data provider 264A may be unable to delay, drop or discard packets for a specific sub-flow. Rather, being sub-flow unaware, the data provider 264A may simply, for example, discard packets for the service flow generally, in the event that the data rate at the data provider 264A exceeds the first level data rate limit. Data provider 264A may forward data for the service flow via line 265 to network convergence service (NCS) 266. According to an illustrative example, in the downlink direction, a data provider 264A may include a user plane gateway (U-GW), while in the uplink direction a data provider 264A may include a base station (BS) or radio leg that is connected to a user device/UE as part of a multiple connection/multi-connectivity between multiple BSs and a UE, for example.

[0025] A network convergence service (NCS) 266 is coupled to data providers 264 (e.g., data providers 264A, 264B, 264C) and data receivers 268 (e.g., data receivers 268 268A, 268B and 268C). According to an example implementation, a network convergence service (NCS) 266 may be provided for each UE/user device and/or for each service flow. A NCS 266 may, for example, provide network convergence services for a service flow or a user device, such as coordinating the communication of data for a service flow or UE, coordinating a flow of data to and/or from one or more of the user devices via one or more data providers and data receivers, e.g., coordinate a flow of data for a UE or service flow between multiple base stations/radio legs and multiple use plane gateways (U-GWs).

[0026] NCS 266 may send a first level data rate limit for a service flow to each of the data providers 264, where a data provider-specific (possibly different) first level rate limit may be provided to each data provider 264A, 264B, 264C. For example, NCS 266 may send, e.g., via line 267, a first level data rate limit for a service flow to data provider 264A. Each data provider 264A, 264B and 264C may then limit the data rate output by the data provider for the service flow so as not to exceed the first level data rate limit for the service flow. In an example implementation, each data provider 264 may delay forwarding and/or drop/discard one or more data packets for the service flow in order to comply with the first level data rate limit.

[0027] According to example implementations, the first level data rate limit(s) sent by NCS 266 to data providers 264 may be the same data rate limit, or may be a different first level data rate limit for each data provider. For example, different sub- flows (each having its own QoS) of the service flow may be received by NCS 266 via a different data provider. For example, a high priority sub-flow may be received by NCS 266 from data provider 264A, and a lower priority sub-flow may be received by NCS 266 from data provider 264B. Thus, in this example, NCS 266 may send a first level data rate limit for the service flow to data provider 264A that is higher than the first level data rate limit for the service flow that is sent to data provider 264B, e.g., to allow more data for the higher priority sub-flow to be forwarded to NCS 266, and/or to make it less likely that data of the high priority sub-flow will be discarded by data provider 264A as compared to the lower priority sub-flow.

[0028] In an example implementation, the NCS 266 may detect that one or more packets of a (e.g., high priority) sub-flow are being dropped (or delayed) by a data provider 264A, e.g., by failure to receive such packets/data. In such case, the NCS 266 may send an instruction to the data provider 264A to increase its first level data rate limit (or may send to data provider 264A an updated first level data rate limit for the service flow that is greater than a previously used first level data rate limit), which will likely result in more packets of (possibly) multiple sub-flows (or multiple/all sub-flows of the service flow that are received by data provider 264A) being forwarded to the NCS 266. The NCS 266 may then, for example, receive more data (a higher data rate) from data provider 264A for multiple sub-flows of the service flow, including the high priority sub- flow, and the NCS 266 can then simply discard lower priority sub-flow data, if necessary.

[0029] According to an example implementation, data provider 264A may discard or drop one or more data packets of the service flow, e.g., in the event the received data would exceed the first level rate limit assigned to such data provider for the service flow. In such case, data provider 264A may send a rate limit exceeded notification via line 269 to NCS 266, e.g., to indicate that the data rate for the service flow at the data provider 264A has exceeded the first level data rate limit for the service flow (e.g., likely causing data provider 264A to drop/discard one or more packets of the service flow). NCS 266 may then send an instruction to data provider 264A to adjust (e.g., increase or decrease) its first level data rate limit for the service flow.

[0030] According to an example implementation, each data provider 264 may have a different first level data rate limit for each of a plurality of service flows. For example, each service flow may be associated with a different UE/user device. For example, a service flow may include Internet traffic to/from a UE/user device, and may include one or more sub-flows, e.g., including data/traffic for different applications running on the UE/user device, such as email, Web browsing, streaming audio/radio, streaming video, video conferencing, etc. However, as noted, the data providers may implement a first level data rate limit, while being sub-flow unaware. In other words, in the event that the received data rate at a data provider 264 exceeds the first level rate limit for the service flow, the data provider 264 may drop/discard data packets without regard for the QoS requirements of the different sub-flows.

[0031] On the other hand, NCS 266 is sub-flow aware, and may for example, receive/read one or more fields of each received data packet, may classify each data packet into one of the sub-flows (e.g., classify the packet as being part of a sub-flow of the service flow). NCS 266 is also aware of the QoS requirements of each of the sub- flows. NCS knows or determines the aggregate maximum bit rate (AMBR) for the service flow, which may be provided, for example, as the second level data rate limit for the service flow. And, based on the QoS needs/requirements for each service flow, the NCS 266 can determine how much of the AMBR (or second level data rate limit) for the service flow may be allocated to each of the sub-flows. NCS 266 may also be aware of the multiple data receivers 268 (e.g., including data receivers 268A, 268B and 268C) that are coupled to the NCS 266, and any parameters for these data receivers 268, e.g., such as a current congestion, latency, data rate, etc. at each of the data receivers 268.

[0032] According to an example implementation, NCS 266 may: 1) selectively perform rate limiting on a per sub-flow basis, by, e.g., delaying forwarding of one or more received packets/data, and/or by dropping/discarding one or more received data packets for one or more sub-flows, e.g., in the event the data rate at the NCS 266 would exceed the second level data rate limit (or AMBR) for the service flow; and 2) may select one of the data receivers 268A, 268B, or 268C to receive each data packet of the service flow. In an example implementation, NCS 266 may selectively drop/discard packet(s) for one or more sub-flows and/or select a data receiver 268 to receive each data packet based on one or more (or even all) of the: second level data rate limit for the service flow (or AMBR for the service flow), the QoS requirements for each sub-flow and/or the amount or percentage of the AMBR that may be (or has been) allocated by NCS 266 to each sub-flow, and/or the arrangement and/or connectivity of the multiple data receivers 268A, 268B, 268C (and/or the performance of each data receiver, such as latency, congestion, data rate), and possibly other information. The NCS 266 may then forward one or more data packets for one or more sub-flows of the service flow to a data destination 270 via one or more data receivers 268. Each data receiver 268 A, 268B, 268C may then forward any received data packets of the service flow to the data destination 270. Each data receiver 268 may also forward data packets for other service flows to other destinations, e.g., a service flow may be associated with a particular destination.

[0033] According to an example implementation, in the downlink direction: data receivers 268A, 268B, 268C may each be or include, for example, a base station (BS) or radio leg, and data destination 270 may include a UE/user device. According to an example implementation, in the uplink direction: the data receivers may include a user plane gateway (U-GW), while the data destination 270 may be an application running on a network, a service, in a cloud, another computer or device, etc.

[0034] FIG. 2B is a block diagram of a wireless network 200 according to another example implementation. Wireless network 200 may include a user device or UE 210 that is connected to multiple base stations (BSs) or access points (APs) or similar radio connection points. In the example shown in FIG. 2B, UE 210 is connected to multiple BSs, including BS 220A and BS 220B. Thus, UE 210 includes multiple wireless connections, e.g., a wireless or radio connection to each of multiple BSs, which may be referred to as multi-connectivity. The radio connections may all use the same radio access technology, or may use different radio access technologies.

[0035] With respect to UE 210, BS 220A may also be referred to as radio leg 1, while BS 220B may be referred to as radio leg 2, because UE 210 (configured for multi- connectivity or multiple BS connections) may send and receive data via these two radio legs or BSs, as part of multi-connectivity. Thus, for UE 210, BSs 220A and 220B provide two radio legs for the communications of data and/or control signals to and from UE 210. The UE 210 may send and/or receive data for a service flow, e.g., Internet traffic directed to or from the UE 210. The service flow (service flow 1) may include multiple sub-flows, including, for example, sub-flow 1 and sub-flow 2, and possibly other sub-flows. Each sub-flow may, for example, be associated with an application running on the UE 210 and/or a service provided to UE 210. And, each sub-flow may include its own quality of service (QoS) requirements, such as, for example, a priority, a service level, a requested data rate, a maximum number of hops, a maximum latency, an average data rate, a maximum or peak data rate, a maximum or average allowed delay, and a maximum error rate (e.g., maximum packet error rate or packet drop rate), as some example QoS parameters for each sub-flow for UE 210. The QoS requirements may include other parameters.

[0036] According to an example implementation, BS 220A may include a protocol stack, which may include a number of protocol entities, with each entity performing one or more functions or operations. An example protocol stack for BS 220A may include, for example, a radio convergence service (RCS) 224A for a first group of sub-flows (typically all corresponding to a first QoS level), a RCS (RCS2) for a second group of sub-flows (typically all corresponding to a second QoS level), a Media Access Control (MAC) entity 226A, and a Physical layer (PHY) entity 228A. While only one service flow (e.g., service flow 1) is shown for UE 210, the BSs 220A and 220B may handle traffic for service flows for other UEs as well, e.g., service flow 2 for another UE (not shown). BS 220B may include a similar set of protocol entities/services. BS 220A may also include a lower network convergence service (NCS-L) 222A which may be a thin or limited functionality service or entity that communicates (may send and received packets or messages) with the network convergence service (NCS) 266 that is located at a NCS hosting site, and/or may provide feedback to the NCS 266 for flow control, e.g., for the service flow, and/or for specific sub-flows. Unless otherwise noted, the term network convergence service or NCS only refers to the NCS 266 located or instantiated at a NCS hosting site, and generally does not refer to the NCS-L at a BS. The term NCS-L refers only to the lower NCS (NCS-L) provided at a BS for communication with the NCS 266 provided at NCS hosting sites. Although not shown, other protocol entities/services may also be included for BSs 220A and 220B. A BS or AP may include all of its protocol entities or services in the same location, or may have a functionality split in which different subsets of its protocol entities or services are in different locations. For example, some of the protocol entities or services may be located at the same site as the antennas, while others may be located in a more central or cloud location.

[0037] According to an example implementation, RCS 224A may perform segmentation/concatenation or reassembly, error detection and correction, data retransmission (for example using an Automatic Repeat Request (ARQ) protocol), duplicate detection and in-sequence data delivery to higher layers. RCS may be known by alternative names such as RLC (Radio Link Control). MAC entity 226A may perform multiplexing of logical channels, hybrid ARQ (HARQ) retransmissions (where ARQ may refer to automatic repeat request), and other MAC-related functions. The PHY entity 224 A may perform coding/decoding, modulation/demodulation, multi-antenna mapping, and other physical layer functions. Other protocol entities or services, not shown, may also be provided at each BS or radio leg.

[0038] Referring to FIG. 2B, network 200 may also include gateways, such as a control gateway C-MGW 232 and user-plane gateways U-GW 234A, 234B, a transport network 230, and one or more network convergence services (NCSs), such as network convergence service (NCS) 266. Network Convergence Service may be known by alternative names, such as PDCP (Packet Data Convergence Protocol) or other names. The transport network 230 may include a plurality of network devices, e.g., switches, IP (Internet Protocol) Routers, or other network devices that are connected via a plurality of data links, to allow data and control messages to be sent or routed for one or more service flows and one or more sub-flows, e.g., between user gateway U-GW 234A and/or U-GW 234B and the one or more base stations (BSs), such as BSs 220A and 220B.

[0039] According to an example implementation, a network convergence service (NCS) may be provided per (or for each) user device or per service flow, or per sub-flow. Each NCS may be located or instantiated at one of a plurality of NCS hosting sites, such as one of NCS hosting sites 236, , etc. For example, NCS hosting sites may be provided at a variety of locations or implementations to host the NCS, such as on a BS/AP, on a network device within transport network 230, provided as a virtual NCS within a cloud- based service, or at another location or on another device within network 200. Thus, each NCS may be created or instantiated physically on a BS/AP or network device, on a network device, or may be provided or instantiated as a virtualized/cloud-based implementation within a cloud-based service, for example.

[0040] According to an example implementation, a network convergence service (NCS) may be provided for each user device and/or for each service flow. A NCS may, for example, provide network convergence services for a service flow or a user device, such as coordinating a flow of data to and/or from one or more of the user devices via multiple base stations/radio legs, and to/from one or more U-GWs 234. The coordinating of a flow of data may involve various operations, such as ciphering, or header

compression, or distributing the packets of a flow to be transmitted over multiple available radio legs, or prioritizing different types of packets/different sub-flows, or selecting an amount of traffic to send over each of multiple available radio legs, or providing in-sequence delivery, or the like. For example, as shown in FIG. 2B, two user plane gateways (U-GWs 234A, 234B) are shown, which may receive incoming traffic/data from another network, such as the Internet. As noted, data may be sent and received for one or more user devices, and/or for one or more service flows, where each service flow may include plurality of sub-flows, where each sub-flow may include a flow of packets or data from a common source or category of applications and may have QoS requirements.

[0041] According to an illustrative example, a network convergence service, NCS 266, may initially be created or instantiated on NCS hosting site 236. For example, NCS 266 may provide network convergence services for service flow 1, and/or for UE 210. Thus, among other operations or functions, NCS 266 may coordinate a flow of data to and from UE 210 via multiple U-GWs and via multiple base stations/radio legs (e.g., via BS 220A and BS 220B) that are connected to the UE 210. In an example

implementation, for service flow 1, sub-flow 1 may be sent and/or received via U-GW 234A, and sub-flow 2 may be sent and/or received via U-GW 234B. Although, alternatively, each U-GW may send/receive data for both sub-flows. As an illustrative example, NCS 266 may receive data for service flow 1 via U-GW 234A and/or U- GW234B, and then may forward (shown as line 237A) a portion (e.g., packets with even sequence numbers) of the data via a transport network 230 to BS 220A for forwarding via wireless connection to UE 210, and may forward (shown as line 237B) a remaining portion (e.g., packets with odd sequence numbers) via transport network 230 to BS 220B for forwarding via wireless connection to UE 210. While only two BSs/radio legs are shown as being connected to UE 210, any number of BSs may be connected to UE 210 to provide multi-connectivity.

[0042] In this simple example, while NCS 266 may, for example, select even packets of a service flow to be sent to UE 210 via BS 220A and odd packets to be sent to UE 210 via BS 220B, this is merely an illustrative example, and NCS 266 may allocate data or traffic for the various sub-flows (e.g., sub-flow 1, sub-flow 2) among the multiple BSs in any manner, e.g., taking into consideration a number of conditions or parameters, such as, e.g., any QoS requirements for each sub-flow, an available capacity or load at each BS or radio leg, latency within transport network 230 between NCS 266 and each BS (which would typically involve different paths, and thus, may include different latencies across transport network 230), and other conditions or parameters. NCS 266 may similarly instruct UE 210 to transmit data over one or more BSs for each sub-flow of service flow 1, e.g., NCS 266 may control or allocate uplink data for service flow 1 in a similar manner, among the multiple U-GWs.

[0043] A radio access network (RAN) control plane 250 may include a RAN orchestrator 252, a radio resource control (RRC) entity 254. A software defined network (SDN) controller 256 may be included in the RAN control plane 250 or may be a separate entity. Each of these entities may be provided at a same location/device, or on different locations/devices, either on physical devices (e.g., on a network device, AP/BS or other device) or as a virtualized entity on a cloud-based service, or other location.

[0044] RRC entity 254 may communicate with each BS to assist in setting up each radio leg or each connection between UE 210 and a plurality of BSs, e.g., to assist in setting up the wireless connections between UE 210 and each of BS 220 A and 220B. Thus, the RRC entity 254 may determine the multi-connectivity status information for each UE, including an indication of the BSs/radio legs that are connected to each UE.

[0045] In addition, the RRC entity 254 may learn or obtain the QoS requirements for each sub-flow or user device, e.g., when the sub-flow is started or created, and may also receive a QoS requirements update when the QoS requirements for the sub-flow change. According to an illustrative example implementation, the QoS requirements for a sub-flow or for a UE may include one or more of the following: a priority, a service level, a requested data rate; a maximum number of hops; a maximum latency; an average data rate; a maximum or peak data rate; and a maximum error rate (e.g., a maximum packet error rate). These are merely some example QoS parameters, and other parameters may be used for the QoS requirements for a sub-flow or UE. RAN

orchestrator 252 may receive from RRC 254 the QoS requirements for each service flow or UE. NCS 266 may also obtain the QoS requirements for each sub-flow, e.g., via RRC entity 254, via RAN orchestrator 252 or from other entity.

[0046] NCS 266 may receive, e.g., from RRC 254 or from another entity, the multi-connectivity status information for each user device/UE indicating the one or more (or plurality) of base stations or radio legs connected to each user device. For example, if a UE is connected to three BSs/radio legs, then NCS 266 can allocate traffic/data packets among the three BSs/radio legs, e.g., for downlink traffic. For example, a greater portion of the downlink traffic for the service flow may be sent over BS220A, and a lower portion of the downlink traffic for the service flow may be sent over BS 220B, e.g., if BS 220A has a greater capacity and/or BS 220B is congested (e.g., higher latency, more UEs handled by BS 220B). NCS 266 may receive downlink data for a plurality of sub-flows (e.g., sub-flow 1, sub-flow 2) for service flow 1, and may selectively discard packets for one or more sub-flows, e.g., based on QoS requirements for each sub-flow.

[0047] Referring to FIG. 2B, network 200 may implement a multi-level (e.g., two-level) data rate control for a service flow. For example, a first level data rate limit may be implemented or used by U-GWs 234, which may be considered as data providers for downlink traffic, and a first level data rate limit may be used by each of multiple connected BSs/radio legs 220A, 220B, which may be considered as data providers in the uplink direction. In both cases, uplink and downlink data flow, the NCS 266 is sub-flow aware and may implement a second level data rate limit. In an example implementation, the U-GWs and BSs/radio legs may be sub-flow unaware, and thus, may be unable to prioritize (or selectively discard data) one (e.g., higher priority) sub-flow over another (e.g., lower priority) sub-flow.

[0048] In the downlink direction (data flow from U-GW 234, via NCS 266, to BSs 220A, 220B, and then to UE 210), NCS 266 may send a first level data rate limit to both U-GWs 234A, 234B for service flow 1. These data rate limits sent to U-GWs 234A, 234B may be the same data rate limit, or may be different, e.g., these first level data rate limits may be specific for each U-GW. As noted, the service flow 1 may include a plurality of sub-flows. In an illustrative example implementation, sub-flow 1 may be received by NCS 266 from U-GW 234A, and sub-flow 2 may be received via/from U- GW 234B. In an example implementation, U-GWs 234A, 234B are sub-flow unaware. When traffic at each U-GW 234 for the service flow exceeds its first level data rate limit for the service flow, the U-GW may discard or drop packets for the service flow.

However, in an example implementation, because the U-GW is sub-flow unaware, the U- GW drops/discards packets generally and without regard to the QoS for different sub- flows. Each U-GW 234 may provide a rate limit exceeded notification to NCS 266 if traffic for the service flow at the U-GW has exceeded the first level data rate limit. And, the NCS 266 may send an updated first level data rate limit to one or more of the U-GWs 234, e.g., in response to the rate limit exceeded notification , or if NCS determines that one or more packets of a high priority sub-flow are being discarded by a U-GW, etc. NCS 266 may classify each received data packet (e.g., based on one or more fields of each packet) into one of the sub-flows, and then may selectively drop/discard one or more packets of one or more sub-flows (e.g., a lower priority sub-flow) if the traffic at the NCS 266 reaches or exceeds a second level data rate limit.

[0049] The NCS 266 may then determine an allocation of traffic for the service flow among the multiple BSs 220A, 220B/radio legs that are connected to UE 210, (e.g., determine which packets to send/forward to UE 210 via which BSs/radio legs). NCS 266 may determine this allocation among multiple BSs and/or forward traffic for the service flow 1 to UE 210 via multiple BSs, e.g., based on the status of transport network 230, multi-connectivity status information for BSs 220A, 220B, the QoS requirements for each sub-flow, and possibly other information.

[0050] In the uplink direction, UE 210 may send data for one or more sub-flows of the service flow 1 via one or more connected BSs 220A, 220B/radio legs. NCS 266 may send each BS/radio leg a first level data rate limit for the service flow 1. Each BS/radio leg may, for example, discard/drop one or more packets of the service flow 1 when the data rate at the BS/radio leg reaches the first level data rate limit. Although, in an example implementation, each BS/radio leg may be sub-flow unaware, and thus, may be unable to selectively discard/drop packets of one flow (e.g., a low priority flow). Each BS may notify the NCS 266 when traffic at the BS reaches or exceeds its first level data rate limit, and may receive an updated first level data rate limit from NCS 266. The NCS 266 may receive packets of service flow 1, and may selectively discard/drop packets of one flow, e.g., based on QoS requirements of the flows, in the event that data rate at the NS 266 reaches or exceeds the second level data rate limit. NCS 266 may then forward data to an end user (not shown) via one or more U-GWs, e.g., via U-GWs 234A, 234B. For example, NCS 266 may forward traffic for sub-flow 1 to U-GW 234A, and may forward traffic for sub-flow 2 to U-GW 234B.

[0051] FIG. 3 is a flow chart illustrating operation of a network convergence service according to an example implementation. FIG. 3 is an illustrative example of a technique of providing a multi-level data rate control for a service flow within a wireless network. Operation 310 includes sending, by a network convergence service to one or more data providers, a (e.g., data provider-specific) first level data rate limit for a service flow; Operation 320 includes receiving, by the network convergence service from the one or more data providers, data for the service flow. Operation 330 includes applying, by the network convergence service, a second level data rate limit for the service flow. Operation 340 includes forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

[0052] According to an example implementation of the method of FIG. 3, the service flow may include a plurality of sub-flows, wherein the data providers are sub- flow unaware, and the network convergence service is sub-flow aware, the method further including: selectively discarding, by the network convergence service, one or more data packets for one of the sub-flows.

[0053] According to an example implementation of the method of FIG. 3, the service flow may include a plurality of sub-flows, wherein the forwarding may include: determining, by the network convergence service, a quality of service (QoS) for each of the plurality of sub-flows; classifying, by the network convergence service, each of a plurality of data packets received from the one or more data providers as being associated with one of the sub-flows; determining, by the network convergence service, that a current data rate for the service flow has exceeded the second level data rate for the service flow; selectively discarding, by the network convergence service, at least one of the received packets for at least one of the sub-flows; and forwarding one or more remaining packets.

[0054] According to an example implementation of the method of FIG. 3, the method may further include: sending, by the network convergence service, an instruction to increase or decrease the first level data rate limit.

[0055] According to an example implementation of the method of FIG. 3, the method may further include: receiving, by the network convergence service from a first data provider of the one or more data providers, a rate limit exceeded notification indicating that the data received by the first data provider has exceeded the first level data rate limit for the first data provider, causing the first data provider to discard data for the service flow; and, sending, by the network convergence service to the first data provider, an instruction to increase the first level data rate limit for the service flow for the first data provider.

[0056] According to an example implementation of the method of FIG. 3, the service flow includes a plurality of sub-flows, the method further including: determining, by the network convergence service, that one or more packets have been discarded by a first data provider of the one or more data providers; and sending, by the network convergence service to the first data provider, an instruction to increase the first level data rate limit for the service flow for the first data provider.

[0057] According to an example implementation of the method of FIG. 3, the method further including: determining, by the network convergence service, a presence of a sub-flow within the service flow requiring a quality of service (QoS).

[0058] According to an example implementation of the method of FIG. 3, the service flow includes a plurality of sub-flows, the method further including: determining that a first sub-flow has a first priority and is being received from a first data provider of the one or more data providers; determining that a second sub-flow has a second priority that is lower than the first priority and is being received from a second data provider; wherein the sending, by the network convergence service to one or more data providers, a first level data rate limit for a service flow includes: sending an instruction to the first data provider to update the first level data rate limit (used by the first data provider) for the service flow.

[0059] According to an example implementation of the method of FIG. 3, the one or more data providers may include one or more gateways that receives data for the service flow, the method including: sending, by a network convergence service to the one or more gateways, a gateway-specific first level data rate limit for the service flow; and receiving, by the network convergence service from the one or more gateways, data for the service flow.

[0060] According to an example implementation of the method of FIG. 3, the service flow is associated with a user device, the method further including: receiving a multi-connectivity status information for the user device for a plurality of base stations that are connected to the user device; and wherein the forwarding includes: forwarding, by the network convergence service, data for the service flow within the second level data rate limit to one or more of the base stations that are connected to the user device.

[0061] According to an example implementation of the method of FIG. 3, the service flow is associated with a user device, the service flow including a plurality of sub-flows, each sub-flow associated with a particular application or service, the method further including: receiving a multi-connectivity status information for a user device for a plurality of base stations that are connected to the user device; determining a quality of service (QoS) associated with one or more of the sub-flows, including a first quality of service associated with a first sub-flow and a second quality of service associated with a second sub-flow; determining, by the network convergence service, that a current data rate for the service flow has exceeded the second level data rate for the service flow; and discarding, by the network convergence service, at least one of the received packets for the first sub-flow.

[0062] According to an example implementation of the method of FIG. 3, the one or more data providers comprise a plurality of base stations that are connected to a user device as part of multi-connectivity for the user device, each of the base stations receiving data for the service flow from the user device, the method including: sending, by the network convergence service to each of the plurality of base stations, a base station-specific first level data rate limit for the service flow; and receiving, by the network convergence service from each of the plurality of base stations, data for the service flow.

[0063] According to an example implementation of the method of FIG. 3, the forwarding including: forwarding, by the network convergence service, data for the service flow within the second level data rate limit to one or more gateways.

[0064] An apparatus comprising at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: send, by a network convergence service to one or more data providers, a data provider-specific first level data rate limit for a service flow; receive, by the network convergence service from the one or more data providers, data for the service flow; apply, by the network convergence service, a second level data rate limit for the service flow; and forward, by the network convergence service, data for the service flow within the second level data rate limit.

[0065] According to an example implementation, a computer program product includes a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method including: sending, by a network convergence service to one or more data providers, a data provider-specific first level data rate limit for a service flow; receiving, by the network convergence service from the one or more data providers, data for the service flow; applying, by the network convergence service, a second level data rate limit for the service flow; and forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

[0066] According to an example implementation, an apparatus includes means (e.g., 602A/602B, and/or 604) for sending, by a network convergence service to one or more data providers, a data provider-specific first level data rate limit for a service flow; means (e.g., 602A/602B, and/or 604) for receiving, by the network convergence service from the one or more data providers, data for the service flow; means (e.g., 602A/602B, and/or 604) for applying, by the network convergence service, a second level data rate limit for the service flow; and means (e.g., 602A/602B, and/or 604) for forwarding, by the network convergence service, data for the service flow within the second level data rate limit. Additional example details of one or more example implementations will now be further described.

[0067] According to an example implementation, for 5G (or other example wireless network), a flexible RAN (radio access network) architecture may be provided, where an NCS 266/NCS functional entity in the RAN may be in charge of one or more of the following functions:

[0068] 1) Classifying, incoming traffic into sub- flows (classifiers can be generic or application-specific, or even identify specific packets within a given application's traffic) - the data providers such as the gateway entity (e.g., U-GW 234) may not have such sub-flow awareness;

[0069] 2) Deciding which (and how much) traffic of each sub-flow to send down each multi-connectivity leg/BS that the UE currently has; and,

[0070] 3) Receiving flow control data from the lower layer (e.g., NCS-L) of each multi-connectivity leg (RCS, roughly similar to RLC in LTE) regarding the space in the buffer, throughput achievable on that leg, delay, and other characteristics of the multi- connectivity leg.

[0071] Further, the NCS 266 may also enforce an AMBR (aggregate maximum bit-rate), which may be on a per-service flow (SF-AMBR) and/or per-UE basis (UE- AMBR). The AMBR may, for example, be used by network/wireless operators to differentiate tiers of service. In the DL direction, the gateway node is typically the first point of ingress of the traffic into the operator network. Thus, it is beneficial to apply some limit to the traffic rate at the gateway, to prevent unbounded traffic coming in. However, directly applying the AMBR at the gateway itself is suboptimal, since the gateway does not have awareness of sub-flow differentiation and relative importance of different traffic. In some example implementations, this sub-flow awareness is available only at NCS 266, for example.

[0072] A service flow may for example include traffic for multiple IP (Internet Protocol) addresses of the UE, each of which may be homed at a separate U-GW (User Plane Gateway) node (e.g., traffic for the sub-flow forwarded via a different U-GW). Thus, for example, an NCS functional entity may receive traffic for a UE's service flow from different U-GWs.

[0073] Therefore, according to an example implementation, an efficient mechanism may be provided for data rate control, such as for the enforcement of AMBR in a 5G network, in order to, by way of example, to:

[0074] (i) allow enforcement of a reasonable traffic limit at the U-GW without sub-flow awareness, while still allowing the NCS to efficiently apply AMBR with awareness of sub-flows, and/or

[0075] (ii) supporting the above in the presence of multiple U-GWs when a single service flow is composed of multi-homed traffic, and/or

[0076] (iii) allow the enforcement of AMBR in the presence of multiple multi-connectivity legs of a UE. In the uplink, the network may, for example, enforce the AMBR or data rate limit, not the UE.

[0077] To allow applying a reasonable rate limit at the U-GW without application/sub-flow awareness, while still allowing NCS to make a sub-flow-aware enforcement of SF-AMBR, a 2-level enforcement mechanism is provided, wherein the U- GW applies one limit (a first level data rate limit for the service flow) without sub-flow awareness, while the NCS 266 enforces another rate limit (a second level data rate limit for the service flow) with full knowledge of sub-flows, QoS, and multi-connectivity characteristics.

If the allowed SF-AMBR is R and the amount of U-GWs serving a specific service flow is N, the gateway is provided a rate limit R*(l/N+delta) that it applies to the UE's traffic overall without needing awareness of sub-flows. If there is just one gateway (i.e., N=l), then the rate limit of R*(l+delta) would represent the first data rate limit provided to the gateway. Delta represents the additional amount over and above the SF- AMBR in the first data rate limit provided to the gateway. According to an example implementation, the NCS 266 applies the rate limit of R, after classifying the traffic into sub-flows, and with awareness of the QoS requirements of the sub-flows, the multi- connectivity status of the UE (including flow-control feedback from each multi- connectivity leg/BS). If the incoming traffic is more than R, the NCS can thus prioritize among the flows, as well as decide which traffic should be sent on each leg, while limiting the total rate to R. If packets need to be dropped, the NCS 266 can make the decision across the sub-flows based on this prioritization (as an example, prioritize TCP (transmission control protocol) packet of a certain sub-flow over a UDP (user datagram protocol) packet which is more tolerant to packet drops). Depending on the throughput achievable on each multi-connectivity leg (and other leg-specific factors), the NCS 266 can decide how much traffic to send on each radio leg/BS, while limiting the total traffic rate (for the service flow) to R, for example.

[0078] According to an example implementation, the NCS 266 may/will selectively drop packets of different sub-flows, depending on the flow priorities, QoS needs, and available multi-connectivity legs. E.g. the NCS 266 can drop more packets of a low priority flow compared to a high priority flow. Alternatively, as another example, if the current multi-connectivity radio legs/BSs for the UE 210/service flow cannot anyway support the QoS needs of a high priority flow, the NCS may decide to drop the high priority flow more and let through more of the low priority traffic. These are just some examples.

[0079] The NCS 266 can decide to adjust the value of "delta" to be used by one or more U-GWs. Consider a particular U-GW which has currently been provided a first data rate limit of R*(l+deltal): If the NCS finds that the incoming traffic from U-GW1 contains too much of a low priority sub-flow, and the QoS of a high priority flow is being affected because of indiscriminate throttling/dropping at the U-GW1, the NCS 266 can decide to increase the value of delta 1. The increased value of delta 1 can get signaled to the U-GW1 either by an explicit signaling protocol, or by in-band signaling indication, for example. When the U-GW1 applies the increased limit of deltal, it will let in a higher amount of both the low and high priority sub-flows. The NCS 266 may then take care of further limiting the traffic rate to a second data rate limit representing the AMBR value R, at which time it may enforce that more of the low priority sub-flow will be dropped, and less of the high priority flow will be dropped, as an example.

[0080] According to an example implementation, in the case of multiple U-GWs, the NCS 266 can decide the delta to apply at each of the U-GWs, taking into account the priorities/traffic load of the sub-flows from the gateways/U-GWs. E.g. if one of the U- GWs has a higher priority sub-flow, while the other U-GW has only low-priority traffic/sub-flow, the NCS 266 can decide a higher delta value to be used by the first U- GW compared to the second U-GW. In case of multiple U-GWs, the NCS 266 can provide specific U-GW(s) also with negative delta value, so that the NCS 266 may provide U-GWs with higher priority/high volume of traffic higher thresholds while keeping the ingress traffic from U-GWs/gateways still at a reasonable level.

[0081 ] In a situation where the traffic volume exceeds the rate limit of

R*(l/N+delta), U-GW can be configured to indicate the occurrence of this situation to NCS either by explicit signaling, or by in-band signaling indication, for example. A U- GW may also be configured for an additional threshold Th which would trigger the indication, i.e., if the traffic volume exceeds the rate limit of R*(l/N+delta) + Th, the indication (e.g., rate limit exceeded notification) is triggered by the gateway/U-GW. This way the NCS 266 may trigger balancing the rate limits between the U-GWs if it determines certain gateways/U-GWs are not working at their defined rate limits.

[0082] According to an example implementation, an NCS 266/NCS functional entity is described in the context of serving one service flow (e.g., service flow 1 in FIG. 2B) and enforcing one SF-AMBR, however, the various implementations may be applied to the enforcing of a data rate limit or SF-AMBR for each of multiple service flows. In an example case where NCS 266 serves multiple service flows simultaneously, it will adopt the above defined functionality for each service flow separately, e.g., including, for each service flow, a SF-AMBR for each service flow, and/or a first level data rate limit for each service flow, and/or a second level data rate limit for each service flow.

[0083] According to an example implementation, the SF-AMBR values for the NCS 266 are configured by the RRC and/or C-MGW (Controlling Mobility Gateway) such that the aggregate of all SF-AMBRs won't exceed the operator configured UE- AMBR. The NCS 266 can be configured to report RRC about the maximum/approximate rate of certain service flow and RRC can adjust the defined SF-AMBR values based on those reports and the configured UE-AMBR. Some of the services (like V2V/vehicle-to- vehicle as an example) may also be accounted as an exceptional priority and such a sub- flow may not be considered for the AMBR enforcement at all. This could be indicated by AMBR value infinity or unlimited, in the configuration of NCS and other entities.

[0084] The proposed solution can also be applied to the enforcement of uplink AMBR in 5G (or other example wireless networks) in the following way, by way of example: UL AMBR enforcement mechanism depends on different architecture options: whether the network radio scheduler (in each BS) is made aware of UL service flows and sub-flows; whether the UE MAC is made aware of UL service flows and sub-flows; or whether the UL service flows and sub-flows are invisible to both of these and only known by the NCS entity in either the UE or the network; the options are referred below to as 1), 2), and 3), respectively. A 2-level enforcement mechanism can be used, wherein the radio scheduler of each multi-connectivity leg/BS applies one rate limit (e.g., a first level data rate limit) without awareness of multi-connectivity transmissions on other legs or sub-flows, while the NCS 266 enforces another rate limit (e.g., a second data rate limit for the service flow) with full knowledge of sub-flows, QoS, and multi-connectivity characteristics.

[0085] 1) If the allowed SF-AMBR is R' and the amount of multi-connectivity legs for a given UE is M, the radio scheduler of each multi-connectivity leg is provided a rate limit R'*(l/M+delta') that it applies to the UE's traffic per service flow overall without needing awareness of sub-flows. Delta can be chosen by the NCS, and may depend on the number or throughput of multi-connectivity legs or other multi- connectivity/radio level characteristics (like RAT, coverage, UE mobility, channel conditions, etc.). Additionally, if the allowed UE-AMBR is U, the radio scheduler of each multi-connectivity leg is provided a rate limit U*(l/M+delta2) that it applies to the UE's traffic overall. Delta2 can be configured by RRC. If there is just one gateway (i.e., N=l), then the rate limit of R'*(l+delta') would represent the first data rate limit provided to the gateway. Delta' represents the additional amount over and above the SF-AMBR in the first data rate limit provided to the radio scheduler of a multi-connectivity leg."

[0086] 2) If the allowed SF-AMBR is R'; the allowed UE-AMBR is U; and the amount of multi-connectivity legs for a given UE is M, the radio scheduler of each multi- connectivity leg is provided a rate limit U*(l/M+delta2) that it applies to the UE's traffic overall. Delta2 can be configured by RRC. The UE's MAC of each multi-connectivity leg is provided a rate limit R'*(l/M+delta') that it applies per service flow. Delta' can be chosen by the NCS and configured by NCS or RRC to the UE's MAC.

[0087] 3) In this option the radio scheduler of each multi-connectivity leg is provided a rate limit U*(l/M+delta2) as in above option 2). The UE NCS (NCS-L) entity can be provided a rate limit of R'*(l+delta") that it applies to the traffic it serves. Delta" can be chosen by the NCS 266 and configured by NCS 266 via in-band signaling or by RRC signaling to the UE.It should be noted that although the above embodiments assume that the value of the first data rate limit provided to all multi-connectivity legs is equal, in some embodiments, some of the multi-connectivity legs may offer much higher throughput to a UE or service flow than other multi-connectivity legs. The first level data rate limit provided to the different multiconnectivity legs may be chosen to be different in such cases.

[0088]

[0089] The NCS 266 applies the rate limit of R' and with awareness of the QoS requirements of the sub-flows, the multi-connectivity status of the UE. If the incoming traffic is more than R', the NCS 266 can thus prioritize among the flows, and selectively drop packets by prioritizing across sub-flows, while limiting the total rate to R' . The NCS 266 can modify/trigger modification of the delta' value to be used by each multi- connectivity leg based on various factors like the QoS achieved by the sub-flows relative to their expected QoS, the relative amounts of traffic of the different sub-flows received on each multi-connectivity leg, change in multi-connectivity characteristics such as throughput of different radio legs/BSs or addition and deletion of multi-connectivity radio legs. Deltas can be negative for one or more multi-connectivity legs. Similar threshold based indication can also be implemented to the radio scheduler/UE MAC/UE NCS (NCS-L) functionality:

[0090] 1) In case the traffic volume (based on UE buffer status reports) exceeds the rate limit of R'*(l/M+delta') + Th', the radio scheduler can be configured to report this event to NCS.

[0091] 2) In case the traffic volume exceeds the rate limit of R'*(l/M+delta') + Th', the UE can be configured to report this event to NW.

[0092] 3) In case the traffic volume exceeds the rate limit of R'*(l+delta") + Th", the UE can be configured to report this event to NW (e.g., via NCS in-band signaling). It should be noted that the RRC may configure delta2 values to radio schedulers such that the configured UE-AMBR will not be exceeded. Thus, if a first multi-connectivity radio leg's radio scheduler receives positive delta2 value, a second multi-connectivity radio leg receives may typically receive a negative delta2 value, according to an example implementation.

[0093] FIG. 4 is a flow chart illustrating operation of a data rate control for a downlink bit rate control according to an example implementation. At 408, the U-GW 234A (FIG. 2B) applies a rate limit of R*(l+delta) to the UL allocations given to the UE on that radio leg. The U-GW then sends the traffic to the NCS 266. At 410, NCS 266 (FIG. 2B) receives uplink traffic from possibly multiple multi-connectivity radio legs/BSs. At 420, the NCS 266 classifies the incoming traffic into sub-flows. At 430, the NCS 266 determines (e.g., based on the QoS needs/priorities of sub-flows, and the aggregate rate limit R) how much traffic of each sub-flow to send onward to the U- GW(s). At 440, the NCS 266 selectively drops packets from each (or one or more) sub- flow, e.g., based on how much traffic of the sub-flow is able to be sent/forwarded. At 450, the NCS 266 determines the delta value to be used by each multi-connectivity leg's lower layer that is sending traffic to this NCS entity. At 460, the NCS 266 signals the delta value to the multi-connectivity radio leg/BS. Then, the process returns to operation 408.

[0094] FIG. 5 is a flow chart illustrating operation of an uplink data rate control according to an example implementation. At 508, at each multi-connectivity radio leg's (BS's) MAC scheduler, the following is performed: Apply rate limit of R*(l+delta) to the uplink allocations given to the UE on that radio leg; send traffic to NCS 266. . At 510, the NCS 266 receives uplink traffic from possibly multiple multi-connectivity legs. At 520, the NCS 266 classifies the incoming traffic into sub-flows. At 530, the NCS 266 determines (e.g., based on the QoS needs/priorities of sub-flows, and the aggregate rate limit R) how much traffic of each sub-flow to send onward to the U-GW(s). At 540, the NCS 266 selectively drops packets from each (or one or more) sub-flow, e.g., based on how much traffic of the sub-flow is able to be sent/forwarded. At 550, the NCS 266 determines the delta value to be used by each multi-connectivity leg's lower layer that is sending traffic to this NCS entity. At 560, the NCS 266 signals the delta value to the multi-connectivity radio leg/BS. Then, the process returns to operation 508. [0095] According to an example implementation, an apparatus may include means (e.g., 602A/602B and/or 604, FIG. 6) for sending, by a network convergence service to one or more data providers, a first level data rate limit for a service flow; means (e.g., 602A/602B and/or 604, FIG. 6) for receiving, by the network convergence service from the one or more data providers, data for the service flow; means (e.g., 602A/602B and/or 604, FIG. 6) for applying, by the network convergence service, a second level data rate limit for the service flow; and means (e.g., 602A/602B and/or 604, FIG. 6) for forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

[0096] FIG. 6 is a block diagram of a wireless station (e.g., base station, access point or user device, or other network device) 600 according to an example

implementation. The wireless station 600 may include, for example, one or two RF (radio frequency) or wireless transceivers 602A, 602B, where each wireless transceiver includes a transmitter to transmit signals and a receiver to receive signals. The wireless station also includes a processor or control unit/entity (controller) 604 to execute instructions or software and control transmission and receptions of signals, and a memory 806 to store data and/or instructions.

[0097] Processor 604 may also make decisions or determinations, generate frames, packets or messages for transmission, decode received frames or messages for further processing, and other tasks or functions described herein. Processor 604, which may be a baseband processor, for example, may generate messages, packets, frames or other signals for transmission via wireless transceiver 602 (602A or 602B). Processor 604 may control transmission of signals or messages over a wireless network, and may control the reception of signals or messages, etc., via a wireless network (e.g., after being down-converted by wireless transceiver 602, for example). Processor 604 may be programmable and capable of executing software or other instructions stored in memory or on other computer media to perform the various tasks and functions described above, such as one or more of the tasks or methods described above. Processor 604 may be (or may include), for example, hardware, programmable logic, a programmable processor that executes software or firmware, and/or any combination of these. Using other terminology, processor 604 and transceiver 602 together may be considered as a wireless transmitter/receiver system, for example.

[0098] In addition, referring to FIG. 6, a controller (or processor) 608 may execute software and instructions, and may provide overall control for the station 600, and may provide control for other systems not shown, such as controlling input/output devices (e.g., display, keypad), and/or may execute software for one or more applications that may be provided on wireless station 600, such as, for example, an email program, audio/video applications, a word processor, a Voice over IP application, or other application or software.

[0099] In addition, a storage medium may be provided that includes stored instructions, which when executed by a controller or processor may result in the processor 604, or other controller or processor, performing one or more of the functions or tasks described above.

[00100] According to another example implementation, RF or wireless transceiver(s) 602A/602B may receive signals or data and/or transmit or send signals or data. Processor 604 (and possibly transceivers 1202A/1202B) may control the RF or wireless transceiver 602A or 602B to receive, send, broadcast or transmit signals or data.

[00101 ] The embodiments are not, however, restricted to the system that is given as an example, but a person skilled in the art may apply the solution to other

communication systems. Another example of a suitable communications system is the 5G concept. It is assumed that network architecture in 5G will be quite similar to that of the LTE-advanced. 5G is likely to use multiple input - multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates.

[00102] It should be appreciated that future networks will most probably utilise network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications this may mean node operations may be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labour between core network operations and base station operations may differ from that of the LTE or even be non-existent.

[00103] Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. Implementations may also be provided on a computer readable medium or computer readable storage medium, which may be a non-transitory medium. Implementations of the various techniques may also include implementations provided via transitory signals or media, and/or programs and/or software

implementations that are downloadable via the Internet or other network(s), either wired networks and/or wireless networks. In addition, implementations may be provided via machine type communications (MTC), and also via an Internet of Things (IOT).

[00104] The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers include a record medium, computer memory, read- only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers.

[00105] Furthermore, implementations of the various techniques described herein may use a cyber-physical system (CPS) (a system of collaborating computational elements controlling physical entities). CPS may enable the implementation and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers,...) embedded in physical objects at different locations. Mobile cyber physical systems, in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronics transported by humans or animals. The rise in popularity of smartphones has increased interest in the area of mobile cyber- physical systems. Therefore, various implementations of techniques described herein may be provided via one or more of these technologies.

[00106] A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit or part of it suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[00107] Method steps may be performed by one or more programmable processors executing a computer program or computer program portions to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[00108] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer, chip or chipset. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data.

Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non- volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[00109] To provide for interaction with a user, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a user interface, such as a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

[00110] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

[00111] While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the various embodiments.

Claims

WHAT IS CLAIMED IS:

1. A method of providing a multi-level data rate control for a service flow within a wireless network, the method comprising:

sending, by a network convergence service to one or more data providers, a first level data rate limit for a service flow;

receiving, by the network convergence service from the one or more data providers, data for the service flow;

applying, by the network convergence service, a second level data rate limit for the service flow; and

forwarding, by the network convergence service, data for the service flow within the second level data rate limit.

2. The method of any preceding claim, wherein the service flow comprises a plurality of sub-flows, wherein the data providers are sub-flow unaware, and the network convergence service is sub-flow aware, the method further comprising: selectively discarding, by the network convergence service, one or more data packets for one of the sub-flows.

3. The method of any preceding claim, wherein the service flow comprises a plurality of sub-flows, wherein the forwarding comprises:

determining, by the network convergence service, a quality of service (QoS) for each of the plurality of sub-flows;

classifying, by the network convergence service, each of a plurality of data packets received from the one or more data providers as being associated with one of the sub-flows;

determining, by the network convergence service, that a current data rate for the service flow has exceeded the second level data rate for the service flow; and selectively discarding, by the network convergence service, at least one of the received packets for at least one of the sub-flows; and

forwarding one or more remaining packets.

4. The method of any preceding claim and further comprising:

sending, by the network convergence service, an instruction to increase or decrease the first level data rate limit.

5. The method of any preceding claim and further comprising:

receiving, by the network convergence service from a first data provider of the one or more data providers, a rate limit exceeded notification indicating that the data received by the first data provider has exceeded the first level data rate limit for the first data provider, causing the first data provider to discard data for the service flow;

sending, by the network convergence service to the first data provider, an instruction to increase the first level data rate limit for the service flow for the first data provider.

6. The method of any preceding claim wherein the service flow includes a plurality of sub-flows, the method further comprising:

determining, by the network convergence service, that one or more packets have been discarded by a first data provider of the one or more data providers; and

7. The method of any preceding claim and further comprising:

determining, by the network convergence service, a presence of a sub-flow within the service flow requiring a quality of service (QoS).

8. The method of any preceding claim, wherein the service flow includes a plurality of sub-flows, the method further comprising:

determining that a first sub-flow has a first priority and is being received from a first data provider of the one or more data providers;

determining that a second sub-flow has a second priority that is lower than the first priority and is being received from a second data provider;

wherein the sending, by the network convergence service to one or more data providers, a first level data rate limit for a service flow comprises:

sending an instruction to the first data provider to update the first level data rate limit for the service flow.

9. The method of any preceding claim, wherein the one or more data providers comprise one or more gateways that receives data for the service flow, the method comprising:

sending, by a network convergence service to the one or more gateways, a gateway-specific first level data rate limit for the service flow; and

receiving, by the network convergence service from the one or more gateways, data for the service flow.

10. The method of any preceding claim, wherein the service flow is associated with a user device, the method further comprising:

receiving a multi-connectivity status information for the user device for a plurality of base stations that are connected to the user device; and

wherein the forwarding comprises:

forwarding, by the network convergence service, data for the service flow within the second level data rate limit to one or more of the base stations that are connected to the user device.

11. The method of any preceding claim wherein the service flow is associated with a user device, the service flow including a plurality of sub-flows, each sub- flow associated with a particular application or service, the method further comprising:

receiving a multi-connectivity status information for a user device for a plurality of base stations that are connected to the user device;

determining a quality of service (QoS) associated with one or more of the sub- flows, including a first quality of service associated with a first sub-flow and a second quality of service associated with a second sub-flow;

determining, by the network convergence service, that a current data rate for the service flow has exceeded the second level data rate for the service flow; and

discarding, by the network convergence service, at least one of the received packets for the first sub-flow.

12. The method of any preceding claim, wherein the one or more data providers comprise a plurality of base stations that are connected to a user device as part of multi-connectivity for the user device, each of the base stations receiving data for the service flow from the user device, the method comprising:

sending, by the network convergence service to each of the plurality of base stations, a base station-specific first level data rate limit for the service flow; and

receiving, by the network convergence service from each of the plurality of base stations, data for the service flow.

13. The method of any preceding claim wherein the forwarding comprises:

forwarding, by the network convergence service, data for the service flow within the second level data rate limit to one or more gateways.

14. An apparatus comprising at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to perform the method of any preceding claim.

15. A computer program product, the computer program product comprising a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method of any of claims 1-13.

16. An apparatus comprising at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to:

send, by a network convergence service to one or more data providers, a first level data rate limit for a service flow;

receive, by the network convergence service from the one or more data providers, data for the service flow;

apply, by the network convergence service, a second level data rate limit for the service flow; and

forward, by the network convergence service, data for the service flow within the second level data rate limit.

17. A computer program product, the computer program product comprising a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method comprising: