Patent Description:
Wireless communication systems are under constant development. One way to meet the need for faster communication and huge increase of the data amount is network slicing, in which virtualized and independent logical networks are multiplexed on the same physical network infrastructure.

<CIT> discloses to use network slice tokens, whose adjustable token counter value may be used to assist allocation of transmission resources when network slicing is used.

<CIT> discloses a solution which is based on using overlapping peaks and valleys of load of network slices to coordinate resources between slides.

<CIT> discloses a solution in which each network slice has an independent access control parameter to implement by a network differential access control to network slices, the access control parameter being adjustable based on resource usage of each network slice in the network.

The scope of the invention is set out by the independent claims. The embodiments, examples and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

Embodiments are described below, by way of example only, with reference to the accompanying drawings, in which.

The following embodiments are examples. Further, although terms including ordinal numbers, such as "first", "second", etc., may be used for describing various elements, the structural elements are not restricted by the terms. The terms are used merely for the purpose of distinguishing an element from other elements. For example, a first element could be termed a second element, and similarly, a second element could be also termed a first element without departing from the scope of the present disclosure.

Embodiments and examples described herein may be implemented in any communications system comprising wireless connection(s). In the following, different exemplifying embodiments will be described using, as an example of an access architecture to which the embodiments may be applied, a radio access architecture based on new radio (NR, <NUM>) or long term evolution advanced (LTE Advanced, LTE-A), without restricting the embodiments to such an architecture, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures appropriately. Some examples of other options for suitable systems are the universal mobile telecommunications system (UMTS) radio access network (UTRAN or E-UTRAN), long term evolution (LTE, the same as E-UTRA), beyond <NUM>, wireless local area network (WLAN or WiFi), worldwide interoperability for microwave access (Wi-MAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, sensor networks, mobile ad-hoc networks (MANETs) and Internet Protocol multimedia subsystems (IMS) or any combination thereof.

<FIG> shows user devices <NUM> and <NUM>' configured to be in a wireless connection on one or more communication channels in a cell with an access node (such as (e/g)NodeB) <NUM> providing the cell. The physical link from a user device to a (e/g)NodeB is called uplink or reverse link and the physical link from the (e/g)NodeB to the user device is called downlink or forward link. It should be appreciated that (e/g)NodeBs or their functionalities may be implemented by using any node, host, server or access point (AP) etc. entity suitable for such a usage.

A communications system <NUM> typically comprises more than one (e/g)NodeB in which case the (e/g)NodeBs may also be configured to communicate with one another over links, wired or wireless, designed for the purpose. These links may be used for signalling purposes. The (e/g)NodeB is a computing device configured to control the radio resources of communication system it is coupled to. The NodeB may also be referred to as a base station, an access point or any other type of interfacing device including a relay station capable of operating in a wireless environment. The (e/g)NodeB includes or is coupled to transceivers. From the transceivers of the (e/g)NodeB, a connection is provided to an antenna unit that establishes bi-directional radio links to user devices. The antenna unit may comprise a plurality of antennas or antenna elements. The (e/g)NodeB is further connected to core network <NUM> (CN or next generation core NGC). Depending on the system, the counterpart on the CN side can be a serving gateway (S-GW, routing and forwarding user data packets), packet data network gateway (P-GW), for providing connectivity of user devices (UEs) to external packet data networks, or mobile management entity (MME), etc..

The user device typically refers 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 wireless devices: a mobile station (mobile phone), smartphone, personal digital assistant (PDA), handset, device using a wireless modem (alarm or measurement device, etc.), laptop and/or touch screen computer, tablet, game console, notebook, and multimedia device. The user device may also utilise cloud. The user device (or in some embodiments a relay node, such as a mobile termination (MT) part of the integrated access and backhaul (IAB) Node), is configured to perform one or more of user equipment functionalities.

Mobile cyber physical systems, in which the physical system in question has inherent mobility, are a subcat-egory of cyber-physical systems.

<NUM> enables using multiple input - multiple output (MIMO) antennas, many more base stations or nodes or corresponding network devices than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and employing a variety of radio technologies depending on service needs, use cases and/or spectrum available. <NUM> mobile communications supports a wide range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications (such as (massive) machine-type communications (mMTC), including vehicular safety, different sensors and real-time control. <NUM> is expected to have multiple radio interfaces, namely below <NUM>, cmWave and mmWave, and also being inte-gradable with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and <NUM> radio interface access comes from small cells by aggregation to the LTE. In other words, <NUM> is planned to support both inter-RAT operability (such as LTE-<NUM>) and inter-RI operability (inter-radio interface operability, such as below <NUM> - cmWave, below <NUM> - cmWave - mmWave). One of the concepts considered to be used in <NUM> networks is network slicing in which multiple independent and dedicated virtual sub-networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.

The communication system is also able to communicate with other networks, such as a public switched telephone network or the Internet <NUM>, or utilise services provided by them.

It is obvious for a person skilled in the art that the depicted system is only an example of a part of a radio access system and in practice, the system may comprise a plurality of (e/g)NodeBs, the user device may have an access to a plurality of radio cells and the system may comprise also other apparatuses, such as relay nodes, for example distributed unit (DU) parts of one or more IAB nodes, or other network elements, etc. At least one of the (e/g)NodeBs or may be a Home(e/g)nodeB.

<FIG> illustrates an access node, such as a base station gNB for the new radio, the base station being configured to support radio access network slicing. In the network slicing, virtual radio access network instances, called slices, are created, with tailored set of virtualized control functions, such as scheduling, and mobility management, based on individual slice/service requirements while at the same time ensuring performance guarantees and/or service level agreement guarantees between different slices. The slices can be seen to correspond to various applications, or services, like mobile broadband or ultra-reliable low-latency communication, and/or verticals, like automotive, and/or tenants, also called mobile virtual network operators, which have different statistical characteristics and different requirements for performance and for quality of experience/quality of service. To take into account that radio resources needed per slice vary, radio resources provided by the cell may be allocated (split) between the slices by defining for a slice a minimum amount of the resources and a maximum amount of resources, the minimum amount guaranteeing resources for a service level agreement and the maximum amount of resources being the upper limit the slice can schedule at a time or on average over a time window. The resource allocation may be based on resource partitioning (reserved spectrum) or resource sharing (spectrum shared), for example.

To provide an overload control mechanism configured to take into account the flexibility given by the minimum and maximum constraints, for example by minimum and maximum resource constraints and/or by minimum and maximum rate constraints, the access node is configured to contain an inter slice master instance <NUM>, which may be an instance within an orchestrator, i.e. within the instance allowing resources for slices. The inter-slice master instance is configured to monitor resource use of slices, and to command slices, if need is detected during monitoring, to release resources, as will be described in detail with <FIG>. As a counter-party to the inter-slice master instance, the slices comprise intra slice instances <NUM>-<NUM>, <NUM>-<NUM>. An intra slice instance <NUM>-<NUM>, <NUM>-<NUM> of a slice provides slice-specific release of resources, as will be described in detail with <FIG>. In other words, in the disclosed example, the inter slice master instance <NUM> monitors the behavior of the plurality of slices in the cell and may command the slices to release resources, and the intra slice instance <NUM>-<NUM>, <NUM>-<NUM> determines how to release resources in a single slice, if commanded to release resources. In other words, the intra slice instances <NUM>-<NUM>, <NUM>-<NUM> are independent of each other.

The inter-slice master instance <NUM> may be in a layer <NUM> packet scheduler in the access node, or it may be an instance in a higher layer entity. One or more of the intra-slice instances <NUM>-<NUM>, <NUM>-<NUM> or all of them or none of them may reside in the same entity, for example in the layer <NUM> packet scheduler, as the inter-slice master instance <NUM>. Further, it should be appreciated that even though in the example of <FIG> the instances locate in the access node, that need not to be the case. The instances may locate in different nodes or units. For example, the central unit (CU) may comprise the inter-slice master instance <NUM> and the distributed unit (DU) may comprise one or more intra-slice instances <NUM>-<NUM>, <NUM>-<NUM>.

<FIG> illustrates an example of a functionality of the inter-slice master instance in the access node having two or more slices. The described functionality may run periodically, being executed every few seconds, for example, and/or triggered by any congestion situation detected by the wireless network, for example by the layer <NUM> packet scheduler.

Referring to <FIG>, resource use of the two or more slices is monitored in block <NUM> by checking current obtained resources by all slices. If the resources used remain within the resource constraints (block <NUM>: yes), the monitoring in block <NUM> continues. If the resources used do not remain within the resource constraints (block <NUM>: no), the amount of resources to release are determined in block <NUM> per a slice, and commanding the two or more slices to release resources by the determined amounts is caused in block <NUM>. Then the process returns to block <NUM> to continue the monitoring.

As can be seen, it is possible to monitor and control service level agreements fulfillment in the slices without waiting for a slice to be congested before any corrective actions are made. Further, instead of borrowing resources from other cells, commands are dispatched to the two or more slices, to solve the resource constraints violation within the cell and its resources.

The functionality of <FIG> may be implemented by an algorithm ISRM (inter slice resource monitoring) according to the following pseudocode <NUM> :
<IMG>
wherein.

In the above pseudocode <NUM> in line <NUM> desired resources and the amount of resources to be released are initialised, and then initial check on minimum and maximum constraints is performed per a slice. In case the current obtained resources of a slice is less than the relaxed minimum constraint of the slice (row <NUM>), the total resource to be released is increased (row <NUM>), and in case the current obtained resources of a slice is more than the relaxed maximum constraint of the slice (row <NUM>), resources are released down to the maximum constraint (row <NUM>), and the total resource to be released is decreased (row <NUM>).

If after the initial check on the minimum and maximum constraints of all slices the amount of desired resources is more than zero, there are still resources to be released and the redistribute surplus function is performed.

After that the amount of resources to be released is known, per a slice, and the inter slice master instance can provide a set of commands to release resources. The resources to be released per a slice depends on the violated slice constraints by the slice itself (maximum resource constraint, and/or maximum rate constraint) and/or other slices' violated minimum constraints (minimum resource constraint, and/or minimum rate constraint).

Instead of the pseudocode <NUM> algorithm for the surplus redistribution, any other algorithm/routine may be used, provided that it ensures that the right amount of resources are released, and minimum resource constraints are fulfilled.

<FIG> illustrates an example of a functionality of the intra-slice instance. As said above, the slices perform the functionality illustrated in <FIG> independently, and using their own policies. Herein, a flow is an atomic entity that demands for data transfer, the term flow thereby covering also a data radio bearer and a user device.

Referring to <FIG>, when a command to release certain amount, a first amount, of resource is received in block <NUM>, flow constraints of the slice are taken into account by determining in block <NUM> the amount of resources missing to satisfy bit rate requirements of active flows. Examples of the bit rate requirements include requirements for a guaranteed bit rate and a nominal bit rate.

For example, following formula may be used to determine the amount of resources missing to satisfy the bit rate requirements: <MAT> wherein.

Ri and Xi may be smoothed using any smoothing in time technique, for example, using exponential smoothing.

When the amount of resources missing has been determined, the amount of resources to release are calculated in block <NUM> by calculating the sum of the first amount received in block <NUM>, and a second amount, which is the amount of resources missing to satisfy the bit rate requirement, determined in block <NUM>.

In the example of <FIG> it is assumed that the result of block <NUM> is that there is resources to be released. Naturally, if there is no resources to release the process would end herein.

To release resources, the flows are sorted to a release order. The release order may be called importance order or priority order. Any pre-determined sorting rule may be used. A sorting rule may be based, for example, on one or more of key performance indicators. A non-limiting list of such key performance indicators include a spectral efficiency of a flow, an achieved throughput of the flow, a guaranteed quality of service of the flow and/or a slice, and a priority (soft/hard priority) of the flow or the slice. One example of a sorting rule is described with <FIG>. A difference between the hard priority and the soft priority is that the hard priority depends only on priority index value, whereas the soft priority depends also on other metrics, as is done in the above examples. For example, when hard priority is used, all flows of a lower priority slice are removed before flows of a higher priority slice, whereas when soft priority is used a lower priority slice may still have one or more flows when flows of a higher priority slice are removed.

In the illustrated example, a flow undergoes this process once during an execution round of the procedure and in the next execution round the flow may undergo this process again. When the flows have been sorted to release order, a flow that has not yet undergone this process and is next according to the release order is taken in block <NUM> to be processed. (If the flows are sorted to a queue to an ascending order, the first one is taken, if they are sorted to a descending order, the last one is taken. ) Then the flow is in block <NUM> either removed, or its quality of service is degraded, depending on the bit rate requirement and possible other criteria defined for the slice instance. For example, a guaranteed bit rate may be degraded to a nominal bit rate, the nominal bit rate may be degraded to the best effort, and if the bit rate constraint is the best effort, the flow is released.

After removing or degrading the flow, it is checked in block <NUM>, whether enough resources have been released. When determining the amount of resources released in block <NUM>, both the resources allocated to the flow and the missing resources to satisfy the bit rate requirement of the flow may be taken into account. In other words, in block <NUM> it is checked whether all resources released amounts to the resources calculated in block <NUM>. If not (block <NUM>: no), the process checks in block <NUM>, whether all flows have undergone the removal or degrading (block <NUM>). If not (block <NUM>: no), the process continues to block <NUM> to take a flow to be processed.

If enough resources have been released (block <NUM>: yes), or if there is no unprocessed flows left (block <NUM>: no), the released/degrade process ends, and will be triggered next time, when a new command to release resources is received from the inter slice master instance is received.

In an example the value obtained as a result in block <NUM> is decremented, when a flow is released, by the amount of resources the flow was getting, and when a flow is degraded, by the amount of difference of the resource requirements of the constraints, and when, after being decremented, the result value is zero or less than zero, enough resources has been released.

The amount of resources, which are decremented, may be calculated as follows: <MAT> wherein.

In an implementation, the amount of data waiting to be transmitted in a transmit buffer of the instance is taken into account by using it as one factor for determining the value of the minimum bit rate constraint target for the flow i. For example, its value may depend on the quality of service type and the data in the transmit buffer, as follows:.

It should be appreciated that the above are mere non-limiting examples.

<FIG> illustrates another example of a functionality of the intra-slice instance. In the illustrated example of <FIG>, the procedure may be triggered either when a command is received or when the instance detects that one or more of its flows does not reach its quality of service level, a degraded flow may undergo within one execution round the procedure until the flow is released and that active flows are sorted to the ascending order.

Referring to <FIG>, the process is not triggered, if the quality of service (QoS) is satisfied (block <NUM>: yes) and no command to release resources is received (block <NUM>: no).

If a bit rate requirement of any of the flows is not satisfied, the quality of service is not satisfied (block <NUM>: no), the process is triggered and the amount of resources missing to satisfy the bit rate requirement are determined in block <NUM>, resulting to the second amount. Block <NUM> corresponds to block <NUM> and therefore it is not described more detail. However, since the quality of service is not satisfied, the result of block <NUM>, i.e. the second amount, will be more than zero. Further, since no command was received, zero is used as the first amount.

If a command to release the resources the first amount is received from the inter slice master instance (block <NUM>: yes), the process is triggered and the amount of resources missing to satisfy the bit rate requirement are determined in block <NUM>. When the process is triggered in response to the command, the result of block <NUM>, i.e. the second amount, may be less or more than zero or equal to the zero.

Triggering the process also cause that flows that have been active within a predetermined time period are determined in block <NUM>. Then the amount of resources to be released are calculated in block <NUM>, as described above, and it is checked in block <NUM>, whether the amount is more than zero. If the amount of resources is more than zero (block <NUM>: yes), the active flows are sorted in block <NUM> to a queue in the ascending order, using a predetermined rule, as described with block <NUM>, an example of the rule being illustrated in <FIG>.

The topmost flow is taken in block <NUM>, and it is either removed (block <NUM>: yes), or if not removed (block <NUM>: no) its quality of service is degraded in block <NUM> and the flow is put back to the queue in block <NUM>. (A removed flow is not any more active, whereas a degraded flow is. ) Whether the flow is removed or degraded depends on the bit rate requirement and possible other criteria defined for the slice instance, as explained with block <NUM>.

After removing (block <NUM>: yes) or degrading (block <NUM>), the process returns to block <NUM> to re-calculate the amount of resources to be released, the calculating taking into account the resources released in block <NUM> or in block <NUM>, using the principles described above with blocks 403and <NUM>.

If the amount of resources to be released is zero or less (block <NUM>: no), the execution round ends and the process returns to monitor, whether a command is received (block <NUM>), or a quality of service is not satisfied (block <NUM>).

<FIG> illustrates an example of a sorting rule, in which the flows are ordered by performing a process to a pair of rules, as long as the flows are in the sorted order. In the illustrated example, it is assumed that active flows are sorted to an ascending order, meaning that the first one is the one that releases resources before the second one.

Referring to <FIG>, a presumption is that flows that have been active within a predetermined time period before sorting have been determined in block <NUM>. The active flows are sorted by performing to all combinations of two flows the following sorting procedure, starting by taking in block <NUM> two of the active flows to determine their order. The throughput of the flows is determined in block <NUM>. If at least one of the flows do not have the same or higher throughput than its minimum throughput constraint of the flow (block <NUM>: no), it is checked in block <NUM>, whether one of them has a higher throughput than its minimum throughput constraint. If one of the flows has the same or a higher throughput (block <NUM>: yes) than its minimum throughput constraint, it is sorted in block <NUM> to be the first one in the order (and then the one having throughput lower than the minimum throughput is the second one in the order). The minimum throughput constraint is a minimum throughput target required to be enforced. For the guaranteed bit rate it may be the same as <MAT> but for the nominal bit rate and the best effort it may be smaller than <MAT>.

If both flows have the same or a higher throughput than the minimum throughput (block <NUM>: yes), it is checked in block <NUM>, whether the flows have the same priority. If not (block <NUM>: no), the one having the lower priority is sorted in block <NUM> to be the first one in the order (and then the one having the higher priority is the second one in the order).

If both flows have the same or a higher throughput than the minimum throughput (block <NUM>: yes), and the same priority (block <NUM>: yes), spectral efficiencies of the flows are determined in block <NUM>, and if they are different (block <NUM>: no), the one having the lower is sorted in block <NUM> to be the first one in the order.

If both flows have the same or a higher throughput than the minimum throughput (block <NUM>: yes), the same priority (block <NUM>: yes), and the same spectral efficiency (block <NUM>: yes), the flows are sorted in block <NUM> using corresponding mobile identifiers as a default ordering criterion. For example, the one having the smaller identifier is sorted in block <NUM> to be the first one in the order.

The intra slice instance may be configured further run in parallel with a process based on <FIG>, a process described in <FIG> to detect and remove latency critical flows, if needed.

Referring to <FIG>, packet delay budget failure ratio of latency critical flows is updated in block <NUM>, per a flow.

The packet delay budget failure ration of a flow may be determined using exponential smoothing or averaging window.

When exponential smoothing is used, assuming that each flow is associated with an averaging window, following formula may be used: <MAT> wherein <MAT>.

The variable αi may be selected to match a desired averaging window. For example, following formula, in which an effect of a failure is smoothed to e-<NUM> after certain updates, may be used: <MAT> wherein.

In an embodiment, <MAT> may be initialized to zero.

When the averaging window is used, after receiving Nth packet, following formula may be used: <MAT> wherein <MAT>.

In both above examples, if the packet inter-arrival time is not known, an estimate may be used, or a value based on previous differences of two consecutive packet arrivals may be used.

Regardless how the failure ratios are determined, they are compared in block <NUM> to a predetermined threshold th. The threshold may be, for example, <NUM>%. If there are one or more flows whose failure ratio is above the threshold (block <NUM>), the one or more flows having the failure ratio above the threshold are removed in block <NUM>, and the process returns to block <NUM>. In an implementation, if averaging window was used in block <NUM>, after block <NUM> the exponential smoothing will be used in block <NUM>,.

If all failure ratios are equal to or smaller than the threshold (block <NUM>: no), the process returns to block <NUM>.

Although not illustrated in <FIG>, the process may be frozen during a congestion time of the network.

Although not illustrated in <FIG>, when the resources are updated, tokens of modified data resource bearers or slices are reset and updated correspondingly.

Further, it may happen that a slice releases more resources than needed, due to the process releasing resources per flow. Depending on an implementation, the extra resources thus obtained may be shared within the slice or re-used by other slices, provided that the minimum resource constraint of the slice is not violated. There exists several possibilities to re-assign resources. For example, the slices may be arranged in an ascending order of priority, and the extra resources could be dedicated to increase slice resources of one or more higher priority slices, starting from the slice of the highest priority. If the processes (releasing and commanding) are performed in parallel, and if the process of <FIG> is performed so that slices are processed in a priority order, starting from the lowest one, and a command to release resources is caused to be sent immediately it has been determined, information of the extra resources may be used to decrease the amount of resources to release by the higher priority slices. <FIG> illustrates such a procedure in more detail.

Referring to <FIG>, resource use of the two or more slices is monitored in block <NUM>, corresponding to block <NUM>, by checking current obtained resources by all slices. If the resources used remain within the resource constraints (block <NUM>: yes), the monitoring in block <NUM> continues. If the resources used do not remain within the resource constraints (block <NUM>: no), the amount of resources to release are determined in block <NUM> per a slice, as described with block <NUM>. The slices, whose resources are determined to be released, are also sorted in block <NUM> to a queue in an ascending order of priority.

The topmost slice form the queue is taken in block <NUM> and commanding the slice to release resources by the determined amount is caused in block <NUM>. If the slice was not the last slice to be commanded, i.e. the queue is not empty (block <NUM>: no) and if the slice informs that it released more resources than the amount in the command in block <NUM>, i.e. information of extra resources is received (block <NUM>: yes), the extra resources will be used in block <NUM> to update the amount of resources to release for at least one slice by decreasing the amount of resources. Then (after block <NUM>), or if no extra resources were released (block <NUM>: no), the process proceeds to block <NUM> to take the topmost slice. (Naturally, if the update in block <NUM> results that no resources should be released, the slice or slices are taken from the queue, and if it causes the queue to be empty, the process returns to block <NUM> to continue monitoring.

If all slices are commanded to release resources (block <NUM>: yes), the process returns to block <NUM> to continue the monitoring.

As is evident, the above examples disclose overload control mechanisms that are slice-aware and can be configured take into account flexible slice resources, provided by the minimum and maximum slice constraints. Thereby it can guarantee service level agreement/quality of service protecting within individual slices. There is no need to wait for a specific slice congestion situation before triggering the overload control mechanism. Since slices are commanded slice-specifically, there is no need to borrow resources to/from other cells or a single slice, but borrowing may be possible in some implementations, if the slice in question indicates extra resources. As a summary, the examples allow slice flexible resource utilization with the service level agreement guarantee and customization, per a slice, intra-slice flow sorting policies, when resources are to be released by a slice. Since resources are released slice-specifically, flows are removed also based on the slice they belong to, thereby allowing monitoring resource utilization by all slices (tenants).

The blocks and related functions described above by means of <FIG> are in no absolute chronological order, and some of them may be performed simultaneously or in an order differing from the given one. Other functions can also be executed between them or within them and/or other rules applied or selected. Some of the blocks or part of the blocks can also be left out or replaced by a corresponding block or part of the block.

<FIG> illustrates an apparatus <NUM> comprising a communication controller <NUM> such as at least one processor or processing circuitry, and at least one memory <NUM> including a computer program code (software, algorithm) ALG. <NUM>, wherein the at least one memory and the computer program code (software, algorithm) are configured, with the at least one processor, to cause the respective apparatus to carry out any one of the embodiments, examples and implementations described above. The apparatus of <FIG> may be an electronic device.

Referring to <FIG>, the memory <NUM> may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory may comprise a configuration storage CONF. <NUM>, such as a configuration database, for at least storing (permanently or temporarily) one or more configurations and/or corresponding parameters/parameter values, for example the slice constraints and/or flow related information. The memory <NUM> may further store a data buffer for data waiting for transmission and/or data waiting to be decoded.

Referring to <FIG>, the apparatus <NUM> may further comprise a communication interface <NUM> comprising hardware and/or software for realizing communication connectivity according to one or more radio communication protocols. The communication interface <NUM> may provide the apparatus with radio communication capabilities in a wireless network. The communication interface may comprise standard well-known analog radio components such as an amplifier, filter, frequency-converter and circuitries, conversion circuitries transforming signals between analog and digital domains, and one or more antennas or antenna arrays comprising plurality of antennas. Digital signal processing regarding transmission and/or reception of signals may be performed in a communication controller <NUM>.

The apparatus <NUM> may further comprise an application processor (not illustrated in <FIG>) executing one or more computer program applications that generate a need to transmit and/or receive data The application processor may execute computer programs forming the primary function of the apparatus.

The communication controller <NUM> may comprise one or more slice radio overload control (SROC) mechanism <NUM> configured to perform resource releasing and/or overload detecting according to any one of the embodiments/examples/implementations described above.

As used in this application, the term 'circuitry' refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of circuits and soft-ware (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s)/software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. The term 'circuitry' would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile device or a similar integrated circuit in a sensor, a cellular network device, or another network device.

In an embodiment, at least some of the processes described in connection with <FIG> may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. The apparatus may comprise separate means for separate phases of a process, or means may perform several phases or the whole process. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments/examples/implementations described herein.

According to yet another embodiment, the apparatus carrying out the embodiments comprises a circuitry including at least one processor and at least one memory including computer program code. When activated, the circuitry causes the apparatus to perform at least some of the functionalities according to any one of the embodiments/examples/implementations of <FIG>, or operations thereof.

The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems (apparatuses) described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments/examples/implementations as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with <FIG> may be carried out by executing at least one portion of a computer program comprising corresponding instructions. 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, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium, for example. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art. In an embodiment, a computer-readable medium comprises said computer program. For example, the non-transitory medium may be a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least one of a first process and a second process, wherein the first process comprises the following: monitoring how two or more network slices use resources; determining, in response to the use not being within slice constraints, per a network slice, an amount of resources to be released by the network slice; and causing commanding network slices to release resources correspondingly, wherein the second process comprises the following: determining, in response to detecting that a command to release resources a first amount is received or that one or more of flows do not reach quality of service level of the flow, a second amount corresponding to resources missing to satisfy quality of service requirements of active flows; sorting, in response to having two or more flows, the flows to an order according to a predetermine sorting rule for flows; releasing resources flow by flow according to the order until enough resources are released.

Claim 1:
An apparatus (<NUM>,<NUM>) comprising means (<NUM>, <NUM>) for performing:
monitoring (<NUM>, <NUM>) how two or more network slices use resources;
characterized by:
determining (<NUM>, <NUM>), in response to the use not being within slice constraints, per a network slice, based at least on other network slices' violated minimum constraints, an amount of resources to be released by the network slice; and
causing (<NUM>, <NUM>) commanding network slices to release resources correspondingly.