SINGLE-SHOT TIMING EVENTS

Event lists for single-shot timing events in a timer pool are accessed by accessing a first level look-up table (123-1) having pointers (1-1) to second level look-up tables (123-2), which in turn have pointers (1-2) to event lists (123-2), an event list comprising timing events having the same expiration time.

TECHNICAL FIELD

Various example embodiments relate to wireless communications.

BACKGROUND

Wireless communication systems are under constant development. For example, network functions are increasingly implemented as virtualized network functions, in which the network functions are separated from hardware they run on by using virtual hardware abstraction implemented on hardware, for example computing platforms, for example. To further increase performance, offloading may be used.

SUMMARY

The independent claims define the scope, and different embodiments are defined in dependent claims.

According to an aspect there is provided an apparatus for managing timer pools and single-shot timing events within the timer pools, the apparatus comprising at least: means for accessing first level look-up-tables, a first level look-up table per a timer pool, the first level look-up table comprising for the timer pool a plurality of rows for first pointers to second level look-up tables; means for accessing, using the first pointers, the second level look-up tables, a second level look-up table comprising M or less rows for second pointers to event lists with expiration times, wherein an event list is associated with one expiration time, and comprises a plurality of single-shot timing events scheduled at the corresponding expiration time; and means for accessing, using the second pointers, the event lists to add or cancel single-shot timing events in the event lists.

In at least some embodiments, the apparatus further comprises at least: means for receiving timer pool configuration information for one or more timer pools; means for determining, per a timer pool, based at least on configuration information received for the timer pool, parameter values for the timer pool, the parameter values including L, which is a maximum number of possible expiration times whose value is based on maximum timeout and resolution of the timer pool, N, which is a number of rows for first pointers in a first level look-up table for the timer pool, and M, wherein L, N and M are positive integers and L=MN; means for allocating from a memory, per a timer pool, memory space for a first level table with the N rows; and means for initializing, per a first level look-up table, second level look-up tables with M or less rows and event lists for the expiration times, an event list per an expiration time.

In at least some embodiments, the apparatus further comprises at least means for adding single-shot timing events to event lists using pointers in the first level tables and pointers in the second level look-up tables.

In at least some embodiments, the apparatus further comprises at least means for cancelling single-shot timing events from event lists using pointers in the first level tables and pointers in the second level look-up tables.

In at least some embodiments, the apparatus further comprises at least: means for receiving requests to add or cancel single-shot timing events, a request indicating a timer pool, a timing event and an expiration time; means for estimating, per a request, whether there is time to perform the request before the expiration time is met; and means for determining to perform the request when there is time to perform the request and not to perform the request when there is no time to perform the request.

In at least some embodiments, the apparatus further comprises at least means for uploading single-shot timing events from the event lists to processing queues, when an expiration time of the event list is met.

In at least some embodiments, the pointers are buffer pointers and the apparatus further comprises at least: means for allocating buffer pointers; and means for deallocating buffer pointers.

In at least some embodiments, the apparatus comprising at least one chip configured to provide said means.

In at least some embodiments, the first level look-up tables, the second level look-up tables and the expiration lists are stored to a memory that is external to said at least one chip.

In at least some embodiments, the apparatus comprises at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, provide the means.

According to an aspect there is provided a method for managing timer pools and single-shot timing events within the timer pools, the method comprising: accessing first level look-up-tables, a first level look-up table per a timer pool, the first level look-up table comprising for the timer pool a plurality of rows for pointers to second level look-up tables, wherein N is a positive integer whose value is based on maximum timeout and resolution of the timer pool; accessing the second level look-up tables, a second level look-up table comprising M or less rows for pointers to event lists with expiration times, wherein an event list is associated with one expiration time, and comprises a plurality of single-shot timing events scheduled at the corresponding expiration time; and accessing the event lists to add or cancel single-shot timing events in the event lists.

In at least some embodiments, the method further comprises: receiving timer pool configuration information for one or more timer pools; determining, per a timer pool, based at least on configuration information received for the timer pool, parameter values for the timer pool, the parameter values including N, which is a number of rows for first pointers in a first level look-up table for the timer pool, L, which is a maximum number of possible expiration times, and M, wherein N, L and M are positive integers and L=MN; allocating from a memory, per a timer pool, memory space for a first level table with the N rows; and initializing, per a first level look-up table, second level look-up tables with M or less rows and event lists for the expiration times, an event list per an expiration time.

In at least some embodiments, the method further comprises: receiving requests to add or cancel single-shot timing events, a request indicating a timer pool, a timing event and an expiration time; using pointers in the first level tables and pointers in the second level look-up tables to add or cancel single-shot timing events in the event lists.

According to an aspect there is provided a computer readable medium comprising instructions stored thereon for performing at least the following to manage timer pools and single-shot timing events within the timer pools: accessing first level look-up-tables, a first level look-up table per a timer pool, the first level look-up table comprising for the timer pool a plurality of rows for pointers to second level look-up tables; accessing the second level look-up tables, a second level look-up table comprising M or less rows for pointers to event lists with expiration times, wherein an event list is associated with one expiration time and comprises one or more single-shot timing events scheduled at said one expiration time; and accessing the event lists to add or cancel single-shot timing events in the event lists.

According to an aspect there is provided a non-transitory computer readable medium comprising instructions stored thereon for performing at least the following to manage timer pools and single-shot timing events within the timer pools: accessing first level look-up-tables, a first level look-up table per a timer pool, the first level look-up table comprising for the timer pool a plurality of rows for pointers to second level look-up tables; accessing the second level look-up tables, a second level look-up table comprising M or less rows for pointers to event lists with expiration times, wherein an event list is associated with one expiration time and comprises one or more single-shot timing events scheduled at said one expiration time; and accessing the event lists to add or cancel single-shot timing events in the event lists.

According to an aspect there is provided a computer program comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following to manage timer pools and single-shot timing events within the timer pools: accessing first level look-up-tables, a first level look-up table per a timer pool, the first level look-up table comprising for the timer pool a plurality of rows for pointers to second level look-up tables; accessing the second level look-up tables, a second level look-up table comprising M or less rows for pointers to event lists with expiration times, wherein an event list is associated with one expiration time and comprises one or more single-shot timing events scheduled at said one expiration time; and accessing the event lists to add or cancel single-shot timing events in the event lists.

According to an aspect there is provided a data structure for a timer pool providing L expiration times, the data structure for the timer pool comprising: a first level look-up table comprising N rows for pointers to second level look-up tables; second level look-up tables comprising, per a second level look-up table, M or less rows for pointers to event lists with expiration times, wherein L=NM; and event lists, an event list per an expiration time, comprising single-shot timing events with corresponding expiration time.

According to an aspect there is provided a memory storing at least data structures for timer pools, a data structure for a timer pool comprising: a first level look-up table comprising N rows for pointers to second level look-up tables; second level look-up tables comprising, per a second level look-up table, M or less rows for pointers to event lists with expiration times, wherein L=NM and L is the number of expiration times provided by the timer pool; and event lists (123-3), an event list per an expiration time, comprising single-shot timing events with corresponding expiration time.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

5G-Advanced, and beyond future wireless networks aim to support a large variety of services, use cases and industrial verticals, for example unmanned mobility with fully autonomous connected vehicles, other vehicle-to-everything (V2X) services, or smart environment, e.g. smart industry, smart power grid, or smart city, just to name few examples. To provide a variety of services with different requirements, such as enhanced mobile broadband, ultra-reliable low latency communication, massive machine type communication, wireless networks are envisaged to adopt network slicing, flexible decentralized and/or distributed computing systems and ubiquitous computing, with local spectrum licensing, spectrum sharing, infrastructure sharing, and intelligent automated management underpinned by mobile edge computing, artificial intelligence, for example machine learning, based tools, cloudification and blockchain technologies. For example, in the network slicing multiple independent and dedicated network slice instances may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.

6G (sixth generation) networks are expected to adopt flexible decentralized and/or distributed computing systems and architecture and ubiquitous computing, with local spectrum licensing, spectrum sharing, infrastructure sharing, and intelligent automated management underpinned by mobile edge computing, artificial intelligence, short-packet communication and blockchain technologies. Key features of 6G will include intelligent connected management and control functions, programmability, joint communication and sensing, reduction of energy footprint, trustworthy infrastructure, scalability and affordability. In addition to these, 6G is also targeting new use cases covering the integration of localization and sensing capabilities into system definition to unifying user experience across physical and digital worlds.

In 5G and beyond 5G, it is envisaged that hardware acceleration with corresponding abstraction models is used. The abstraction models are utilizing logical processing units that may run on computing platforms. The hardware on which the abstraction models can run may be commercial off-the-shelf platforms. To facilitate network functions running on different platforms, software frameworks, such as Open Data Plane (ODP) are envisaged to be used. The software frameworks manage timing related functionalities by using, for example, single-shot timing events, that may be called as single-shot timers, as event timers and timer pools. The timing related functionalities are envisaged to be offloaded to hardware accelerators, that are specialized processing units, for example by means of single-shot timing events associated with corresponding expiration times. Offloading of time management has two contradictory requirements. One of the requirements is fast search (small latency) within timing events stored, the fast search being achievable by data structures increasing memory usage. The other one of the requirements is small memory usage achievable by data structures increasing latency of search. InFIG.1a data structure that provides a balance between the two requirements is disclosed.

FIG.1illustrates an exemplified high-level network architecture100, only showing some details relating to offloading timing related operations, the more detailed implementation being irrelevant for the description of examples. The examples are described herein using principles and terminology of 5G and 5G-Advanced. A person skilled in the art may apply the solutions and examples to other communication systems, for example beyond 5G-Advanced, or communication system implementing similar principles and functionalities, possibly with different terms having corresponding meaning, but using some other than 5G technology.

Referring toFIG.1, disaggregated, virtualized and software-based components comprise device components101for device functionalities in device domain, access network components102for access network functionalities in access network domain, core network components103for core network functionalities in core network domain, data network components104for data network functionalities in data network domain.

A device component101may be any electrical device, or apparatus, connectable to an access network. A non-limiting list of examples of device components101comprises a user equipment, a smart phone, an internet of things device, an industrial internet of things device, a consumer internet of things device, an on-person device, a wearable device, such as a smart watch, a smart ring, an eHealth related device, a medical monitoring device, a sensor, such as pressure sensor, a humidity sensor, a thermometer, a motion sensor, an actuator, an accelerometer, etc., a surveillance camera, a vehicle, automated guided vehicles, autonomous connected vehicles etc.

An access network may be any kind of an access network, such as a cellular access network, for example 5G-Advanced network, a non-terrestrial network, a legacy cellular radio access network, or a non-cellular access network, for example a wireless local area network. To provide the wireless access, the access network comprises apparatuses, such as access devices, as access network components102. There are a wide variety of access devices, including different types of base stations, such as as eNBs, gNBs, split gNBs, transmission-reception points, network-controlled repeaters, nodes operationally coupled to one or more remote radio heads, satellites, donor nodes in integrated access and backhaul (IAB), fixed IAB nodes, mobile IAB nodes mounted on vehicles, for example, etc. At least some of the apparatuses in the access network may provide an abstraction platform to separate abstractions of network functions from the processing hardware.

The core network components103form one or more core networks. A core network may be based on a non-standalone core network, for example an LTE-based network, or a standalone access network, for example a 5G core network. However, it should be appreciated that the core network, and the core network components103, may use any technology that enable network services to be delivered between devices and data networks.

A data network may be any network, like the internet, an intranet, a wide area network, etc. Different remote monitoring and/or data collection services for different use cases may be reached via the data network and the data network components104.

An apparatus120illustrates an example of an apparatus (component) in the access network wherein the apparatus performs one or more network functions utilizing one or more applications that may use open data plane software platform, OPD SW,121for time management that is offloaded to a hardware, HW, accelerator122. It should be appreciated that implementation details to manage armed single-shot timers and corresponding timing events and data structure disclosed herein with any example may be used with other corresponding platforms, and/or by apparatuses in the core network.

Applications running on the open data plane software platform121measure and respond to passage of time by using timers. To offload the time management to the hardware accelerator122, the open data plane software platform121configures one or more timer pools, selects, per a timer pool, a clock source and enables the timer pools. Main parameters of a timer pool from the point of view of the open data plane software platform121are a timer pool identifier, resolution and maximum timeout. The maximum timeout may be configured using a parameter, whose value will be used with a value of the resolution time to compute a value of the maximum timeout. The parameter is called herein a timeout parameter. In an implementation, the open data plane software platform121may configure a further parameter for the timer pools, the further parameter being called herein a compression parameter. The open data plane software platform121may have one or more preconfigured values Y of the compression parameter, for example a value Y per a value X of the timeout parameter. When the one or more timer pools have been configured, the open data plane software platform121may add, i.e. arm, single-shot timers to the timer pools to schedule events, and if needed, to cancel them, for example, by transmitting corresponding function calls. A single-shot timer can be added to generate a timeout independently from other single-shot timers, and single-shot timers may be shared across multiple software threads. A single-shot timer is an entry in the second level look-up table123-2which is linked, via an event list, to one or more events, i.e. to a plurality of events, in the event list123-3. One may say that the single-shot timer has a form of an event, e.g. an open data plane event, and the single-shot timer is associated with an expiration time. In other words, a single-shot timer may be represented by a data structure that comprises an identifier, an expiration time, and an event, or more precisely a data structure representing the event. The event may be called a single-shot timing event, or shortly a timing event. When the single-shot timers expire they create timeouts, which serve as notifications of timer expiration to the applications running on the open data plane software platform121.

The hardware accelerator122receives function calls relating to single-shot timers (timing events) via one or more dedicated hardware interfaces (not illustrated inFIG.1), as is known in the art. The hardware accelerator122manages timer pools and timing events within the timer pools by accessing a memory123storing single-shot timer related information. A more detailed examples of hardware accelerator implementations, for example engines and sub-systems the hardware accelerator may comprise, are described below withFIG.2andFIG.3. The memory123may be an external memory or internal memory. The external memory may be external to one or more circuitries, or chips, implementing the hardware accelerator for the time management. For example, the external memory may be an on-chip memory or off-chip memory.

To optimize, or balance, memory size required and latency in searching, a two-level look-up table data structure is used. In the two-level look-up table data structure, or shortly two-level look-up table, the memory comprises, per a timer pool configured, in a first level of the look-up table a table123-1and in a second level a plurality of lists123-2(one illustrated inFIG.1), a list123-2in the second level of the look-up table comprising pointers to event lists123-3(one illustrated inFIG.1). In other words, the two-level look-up table for a timer pool comprises a first level table and second level look-up table(s). In an implementation, memory for first level tables123-1is allocated during configuration and the second level look-up tables123-2are implemented using buffer technology, including buffer pointers to the second level look-up tables. A buffer pointer points in the memory123to an area, or location, containing one or more entries (records) associated with an expiration time. The area may have a specific or configured size. However, it should be appreciated that in another implementation memory for the second level look-up tables123-2may be allocated during the configuration. The event lists123-3may be implemented using the buffer technology, including buffer pointers to the event lists, regardless how the second level look-up tables are implemented.

The values for resolution and maximum timeout configure the size of the timer pool. The size defines a maximum number L of expiration times usable for timing events. The number of the rows N in the first level table123-1is defined by the value X of the timeout parameter and the value Y of the compression parameter. As said above, the open data plane software platform121may configure the value Y. Another alternative include that the hardware accelerator122has one or more preconfigured values Y of the compression parameter, for example a value of the compression parameter per a value of the timeout parameter. The number of the rows M in the second level look-up table123-2is defined by the value Y of the compression parameter. The size of the first level look-up table123-1and the size of the second look-up table123-2may be freely chosen, optimal sizes being power of 2 sizes, providing an optimized structure. Based on a single-shot timers concept (equation 1 below) and the optimal sizes, following size dependencies for L, N and M and the parameters may be given:

L=NM(1)N=2X/2YM=2YMT=(2X-1)⁢RTwhereinL=maximum number of different expiration times in a timer poolN=number of rows in the first level table123-1M=(maximum) number of rows in the second level look-up table123-2X=value of time-out parameterY=value of compression parameterMT=value of maximum timeoutRT=value of resolution time

The parameter values X and RT may be used to calculate a duration of the timeout. For example, for a resolution time 100 nanoseconds and for the timeout parameter value X=20, the timeout may be 0.1049 seconds (100 nanosecond×220).

It should be appreciated that in the equation above it is assumed that the first possible expiration time is assumed to be zero, and hence the equation contains “−1”. Further, it should be noted that the maximum number of different expiration times is usually bigger than a maximum number of timing events that may be armed simultaneously.

In the first level table123-1, a row123-1acomprises a header and a pointer1-1to a second level look-up table123-2(Ext_Table). The size of the header may be 64 bits, the pointer may be a 64-bit pointer, the size of the row123-1amay thus be 128 bits or 16 bytes, and a space required to be allocated from the memory123for the first level table may be N×16 bytes, i.e. (2X/2Y×16 bytes). The header comprises bitmasks, link's pointer (i.e. memory address for the first level table), list's info (i.e. information on the first level table), etc., as is known in the art. The pointer1-1is a pointer to a start of the second level look-up table, comprising a set of M expiration times. A first row in the look-up table may comprise a pointer to a second level look-up table comprising first M expiration times, e.g. expiration times 0 to M-1, the next row comprising a pointer to expiration times M to 2M-1, etc.

For example, first three rows in the first level table123-1could be for following sets of M expiration times:

0×2Y×RT∼(1×2Y-1)×RT1×2Y×RT∼(2×2Y-1)×RT2×2Y×RT∼(3×2Y-1)×RTand the last two rows in the first level table123-1for following sets of M expiration times:

((2X/2Y)-2)×2Y×RT∼(((2X/2Y)-1)×2Y-1)×RT((2X/2Y)-1)×2Y×RT∼(((2X/2Y)-0)×2Y-1)×RTwherein× means multiplicationY=value of the compression parameterRT=value of resolution timeX=value of timeout parameter

The second level look-up table123-2is an expiration time list. The second level look-up table123-2comprises for the M expiration times, for an expiration time per a row123-2a,preferable in a form of an ordered list, pointers1-2to starts of event lists (Ev_List), a pointer1-2per a row to an event list having the expiration time of the row. The pointer1-2may be a 64-bit pointer, the size of the row123-2amay thus be 8 bytes and a maximum space required by the second level look-up table123-2may be M×8 bytes, i.e. 2Y×8 bytes. Using the above example of the first level table, the second level look-up table123-2supports 2Y, preferably ordered, expiration times with intervals of the resolution time.

For example, for a first row in the first level table123-1, pointers for following expiration times may be given in the first three rows of the second level look-up table123-2pointed to by said first row:0×RT1×RT2×RTand in the last two for following expiration times:(2Y−2)×RT(2Y−1)×RTwherein× means multiplicationY=value of the compression parameterRT=value of resolution time

An event list123-3comprises a header portion123-3bfollowed by one or more events123-3a,an event (event entry) per a row. The size of an event entry may be 256-bit or 32 bytes according to timing event entry content. The event list123-3may be implemented as linked lists having a maximum predetermined size. For example, an event list may comprise 32 rows, a row for a header and 31 rows for events. The header123-3bmay comprise a pointer to another event list for the same expiration time, which in turn may comprise a pointer to a further event list for the same expiration time, etc. However, herein such linked lists are interpreted to be a single event list with a single expiration time. The number of the event lists depends on how many events (single-shot timing events), or armed single-shot timers, have different expiration times, scheduled by the open data plane software platform121. If all events have the same expiration time, there will be one event list, if one or more events have a first expiration time and one or more events have a second expiration time, there will be two event lists, etc. The header123-3bmay further comprise bitmasks, link's pointer, list's info including, when the event list is a linked list, a pointer to the next list, etc., as is known in the art.

By organizing, as described above, the possible expiration times by groups of 2Yexpiration times with the two-level look up table structure having first level tables and second level look-up tables, it is possible to reduce memory size required compared to solutions using one-level look-up table solutions while keeping the searching complexity simple enough for hardware implementation, for example compared to searching complexity of a binary search tree structure.

Assuming that the number of timer pools is 64, and the timer pools have following configurations: the maximum number of armed single-shot timers simultaneously at any given time is 100 000, the resolution time is 100 nanoseconds, value of the timeout parameter X is 25, value of the compression parameter Y is 8, and an entry structure size (size of one row or entry) is 8 bytes, following comparisons for a worst case scenario can be made with the one-level look-up table comprising 2Xrows (i.e. a row per an expiration time) and with the binary tree structure having four memory pointers.

Searching latency, i.e. searching complexity O of an expiration time for 100 000 armed single-shot timers for all 64 timer pools:Two-level look-up table=0(2)One-level look-up table=0(1)Binary tree structure=0(17)

In the binary tree structure the complexity is 0(log2(maximum number of armed timers), and the binary tree structure may also need rebalancing which in the worst case may result to a searching complexity of 0(100 000).

As can be seen from the above comparison, the two-level look-up table implementation requires almost 63 times less memory space than the one-level look-up table with only 0(2) searching complexity, at least eight times less than the binary tree structure. In other words, the two-level look-up table use as less memory for the data structure as possible while providing fast enough search algorithm to find, for example, a first-to-expire single-shot timer record (i.e. one or more first-to expire events with the first-to-expire expiration time), or an armed single-shot timer record (an event in an event list) to be cancelled or removed, or a location where to add a new armed timer record (i.e. find an event list and a row whereto add an event).

By performing memory space calculations for different values of the timeout parameter X and with different values of the compression parameter Y per X, and assuming 64 timer pools, a maximum number of armed single-shot timers 100 000, maximum number of second level look-up tables 100 000 with a second level look-up table size 2Y×8 bytes, 100 000 event lists, an event list having a size of 1 000 bytes (32×32 bytes), following combinations provided the minimum required memory space:X=18, Y=4X=19, Y=5X=20, Y=5X=21, Y=6X=22, Y=6X=23, Y=7X=24, Y=7X=25, Y=8

FIG.2andFIG.3illustrate high-level views of examples of hardware accelerator architecture by showing a high-level view of entities in an event socket, which is a hardware accelerator for event management. In other words,FIG.2andFIG.3illustrate high-level views of examples of entities in an apparatus supporting hardware acceleration for timing, and describe examples of how to realize hardware-software offloading using the two-level look-up table for timing events. It should be appreciated that the hardware accelerator based on the example ofFIG.2or on the example ofFIG.3may comprise also other entities and elements not disclosed herein. Further, the examples, including entities listed, are non-limiting examples.

The hardware accelerator122may comprise or be comprised in, for example, one or more hardware apparatuses comprising different general purpose processors, or one or more other commercial off-the-shelf devices or platforms and application programming interfaces to implement the entities with corresponding functionality. A non-limiting list of hardware for hardware accelerators includes a central processing unit, a graphics processing unit, a data processing unit, a neural network processing unit, a field programmable gate array, a graphics processing unit based system-on-a-chip, a field programmable gate arrays based system-on-a-chips, a programmable application-specific integrated circuit, etc. The hardware may use one or more reusable logic units, also known as Intellectual Property (IP)-cores, which may have been watermarked for protecting the IP-cores authenticity. In IP-cores watermarking, the signature is represented by a Finite State Machine (FSM). Since all algorithms relating to single-shot timers can be implemented as FSM IP-core implementations, complex multistep usually used in software implementations can be avoided.

Referring toFIG.2, the hardware accelerator122may comprise an event timer (ET) subsystem221, a buffer manager (BM) subsystem222, a software (SW) side223, an event manager subsystem223, and a memory123storing for the two-level look up-tables a plurality of first level tables (1st levT)123-1, and a plurality of second level look-up tables (2nd levT)123-2, and a plurality of event lists123-3for timing events, as described in more detail withFIG.1. As described withFIG.1, the memory may be an external memory, for example an external memory to hardware implementing the event timer subsystem.

In the example ofFIG.2, an interactivity201between the event timer subsystem221and the memory may be a direct memory access read or write operation. Interactivities202between the event timer subsystem221and the buffer manager subsystem222relate to allocation and deallocation of buffer pointers, for example pointers to second level look-up tables123-2and/or pointers to event lists123-2. Interactivities203between the event timer subsystem221and the software side223provide an application programming interface (API) to arm or cancel timers. Interactivities204between the event timer subsystem221and the event manager subsystem204comprise expired events.

In the example ofFIG.2, the event timer subsystem221comprises a memory processing engine (core)221-1for managing different offloaded single-shot timer related operations including storing events in the memory123, using the buffer manager subsystem222, searching for armed single-shot timers, monitoring expiration times, forwarding events of expired times to the event manager subsystem224, etc. The memory processing engine221-1also maintains, per a timer pool, an internal counter that represents a current pool time in units of a clock selected by the open data plane software platform for the timer pool when the timer pool is created. The internal counter provides a reference clock value for monitoring the expiration times. The internal counter may be up to 64 bits. The event timer subsystem221comprises also a register bank221-2which comprises configuration information, shortly configurations, relating to the two-level look-up tables, internal engines and blocks, HW FIFOs, etc. as well as all status and errors of sub-blocks of the event timer are organized in the event timer's register bank221-2.

In the example ofFIG.2, the buffer manager subsystem222comprises an allocation engine222-1to allocate free buffer pointers for second level look-up tables123-2and for event lists123-3and a deallocation engine222-2to deallocate buffer pointers. For the allocation engine, any of following may be preconfigured or provided when a timer pool is created: the value of the parameter X, the value of the parameter Y, the size of an entry (size of a row) in the first level table, the size of an entry (size of a row) in the second level look-up table(s), and the size of an entry (size of a row) in the event list(s). The allocation engine222-1may be configured to allocate memory space for the first level table123-1when the timer pool is created, whereas memory space for the second level look-up tables and for the event lists may be allocated dynamically for expiration time(s), for example by a buffer manager unit for memory buffer pointer allocation and/or deallocation purposes, as is known in the art.

In the example ofFIG.2the software side223comprises three parallel hardware first-in-first-out (FIFO) lists223-1,223-2,223-3for each software thread per a timer pool, the lists providing a software interface. For example, to support 32 software threads and to have 64 timer pools, the software side comprises 3×32×64 FIFO lists. The FIFO lists may have a predetermined depth. The open data plane software platform may use two of the lists to write commands or requests to the lists to get answers/statuses relating to entries within a short time and one list for cancelling entries. One223-1of the lists may be for adding one by one a new expiration time, i.e. adding an entry to a second level look-up table. The list223-1may be called a software API1. The input to the list223-1may comprise an expiration time and a pointer to an event, both 64 bits long, for example. The pointer to the event is a pointer to a memory location of the event, or an event packet, in a memory used by the offloading entity to store events. In other words, the software API1is for the event timer to read events from the memory used by the offloading entity, so that the events read can be added to event lists. One223-2of the lists may be for adding to an expiration time an event package comprising one or more events. The list223-2may be called a software API2. An entry in the list223-2may be 64-bit long event, for example. One223-3of the lists may be for cancelling one by one an entry in an event list123-3in the memory, i.e. cancelling one event, and/or an entry in a second level look-up table123-2in the memory, i.e. cancelling one expiration time, resulting that events with the expiration time will be cancelled also.

In the example ofFIG.2, the event manager subsystem224comprises an event manager classifier engine224-1to receive events whose expiration time is expired to be processed by the open data plane software platform. The events having the same expiration time from one timer pool may be received one by one, the event manager classifier engine224-1forming an event queue of the events. The event queue may be called a destination event queue.

Referring toFIG.3, the hardware accelerator122comprises a timer unit TU320, for example in the event timer, and a memory123storing for the two-level look up-tables a plurality of first level tables (1st levT)123-1, and a plurality of second level look-up tables (2nd levT)123-2, and a plurality of event lists123-3for timing events, as described in more detail withFIG.1. As described withFIG.1, the memory may be an external memory, for example an external memory to hardware implementing the event timer subsystem.

In the example ofFIG.3, the interactivity201between the timer unit320and the memory may be a direct memory access read or write operation.

In the example ofFIG.3, the timer unit TU320may comprise one or more two level look-up table processing engines321, one or more preload engines322and one or more timer pool engines323.

The two level look-up table processing engines321may be used for managing and processing two level look-up tables data structures, i.e. the first level tables123-1and the second level look-up tables123-2, and the event lists123-3, to add or cancel one or more expiration times and/or timing event entries for single-shot timers (single-shot timing operations). The two level look-up table processing engine may also allocate and deallocate buffer pointers to the second level look-up tables123-2and/or to the event lists123-3. A two-level look-up table processing engine321may include a control unit, one or more read and write direct memory access blocks, one or more interconnect arbitration switches, etc.

The preload engines322may be used for preloading timing event entries and expiration times for the single-shot timers close to expiring. The preload engines322may be parallel preload engines. The preload engines322may also deallocate the buffer pointers. A preload engine may include a control unit, one or more read and write direct memory access engines for preloading or reading timing events and expiration times, one or more interconnect arbitration switches, etc.

The timer pool engines323may be used for monitoring expiration times and for transmitting timing event entries to be processed. The timer pool engines323may be parallel timer pool engines, and there may be a timer pool engine per a timer pool assigned to a software thread. A timer pool engine may be configured to compare a preloaded expiration time with a reference counter value, for example, to detect expiration of the time. The timer pool engine323may include a control unit, one or more first-in-first-out blocks for preloaded expiration times and timing events and expiration times, event message transmitting and control blocks, one or more interconnect arbitration switches, etc.

As shown inFIG.2andFIG.3, the hardware accelerator may be constructed based on different internal engines, which may be parallel engines, an engine being responsible for supporting one or more functions. In the examples ofFIG.4toFIG.10different example functionalities are described, without allocating the functionalities to specific engines, since it bears no significance which engine performs one or more of the functionalities. Further, for the sake of clarity of description, the examples uses one timer pool and one expiration time, without limiting the examples to such a solution. It is a straightforward process for one skilled in the art to apply the examples to a plurality of timer pools and to a plurality of expiration times. It should be also appreciated that some of the blocks may be run in parallel even though for the sake of clarity of description the blocks are described one by one in a non-limiting order.

Referring toFIG.4, when an apparatus comprising the hardware accelerator receives (block401) a timer pool configuration, parameters for the timer pool are determined (block402). For example, the timer pool configuration may comprise an identifier of the timer pool, indication of a clock source to be used with the timer pool and configuration information for timing events. The maximum number of simultaneously armed timers and/or the maximum number of buffer pointers may be reset to the hardware apparatus, for example based on processing and/or memory capacity, or one or both of them may be received in the configuration information, or the apparatus may be configured to calculate one or both of them based on memory usage, for example. In one implementation, the configuration information comprises a resolution value and a maximum timeout value, wherein determining the parameters comprises calculating a value X of the timeout parameter using equation 1, and obtaining from preconfigured (preset) information, for example, a value Y of the compression parameter, which value is associated with the value of the timeout parameter. In another implementation, the configuration information comprises a resolution value, a maximum timeout value, and a value Y of the compression parameter, wherein determining the parameters comprises calculating a value X of the timeout parameter using equation 1. In a still further implementation, the configuration information comprises a value X of the timeout parameter and a value Y of the compression parameter. Yet another implementation includes that the configuration information comprises a value X of the timeout parameter, wherein determining the parameters comprises obtaining from preconfigured information, for example, a value Y of the compression parameter, which value is associated with the value of the timeout parameter. In any of the implementations, determining (block402) the parameters may comprise determining values of M (maximum number of rows in a second level look-up table) and N (number of rows in the first level table).

Then in the illustrated examples, memory for a first level table is allocated (block403) and second level look-up tables and event lists are initialized (block404). The initialization may include initializations of buffer pools and initializations of buffer pointer pools for the lists.

Referring toFIG.5, when a request to add at least an event e1with an expiration time t1to a timer pool indicated is received (block500), a first level table in the memory is accessed (block501) for a pointer to a second level look-up table. In other words, the pointer to a second level look-up table comprising the expiration time is obtained by accessing the first level table in the memory. The pointer may be to the beginning of the second level look-up table. Then, using said pointer, the second level look-up table in the memory is accessed (block502) for a pointer to an event list with expiration time t1(t1event list). In other words, the pointer to an event list for the expiration time t1is obtained by accessing the second level look-up table in the memory. The pointer may be to the beginning of the t1event list. Then, using said pointer to the t1event list, the event e1is added (block503) to the t1event list. The event e1may added to be the last event in the list.

Referring toFIG.6, when it is detected (block601) that expiration time t1expires, events in the t1event list are processed (block602). For example, timeouts may be generated, a timeout per an event in the event list whose associated time expired. Referring toFIG.7, if a request to cancel the event e1with the expiration time t1from the timer pool indicated is received (block700), a first level table in the memory is accessed (block701) for a pointer to a second level look-up table. In other words, the pointer to a second level look-up table comprising the expiration time is obtained by accessing the first level table in the memory. The pointer may be to the beginning of the second level look-up table. Then, using said pointer, the second level look-up table in the memory is accessed (block702) for a pointer to an event list with expiration time t1(t1event list). In other words, the pointer to an event list for the expiration time t1is obtained by accessing the second level look-up table in the memory. The pointer may be to the beginning of the t1event list. Then, using said pointer to the t1event list, the event e1is removed (block703), or deleted, from the t1event list, for example by searching a matching event identifier, or event data structure, and when found, removing the event e1. Removing an event means that the event is cancelled.

FIG.8,FIG.9andFIG.10illustrate more detailed examples of adding, canceling and processing events, assuming an implementation with an upper limit for armed single-shot timers and taking into account processing time. The upper limit in the example means a maximum number of buffer pointers that can be allocated for a timer pool.

Referring toFIG.8, when a request to add at least an event e1with an expiration time t1to a timer pool indicated is received (block800), a time between current time and the expiration time is estimated (block801) in order to estimate whether there is enough time to add the event e1(i.e. to arm the single-shot timer). If there is enough time (block802: yes), it is checked (block803), whether a maximum number of buffer pointers have been used. If the maximum number, for example 100 000 buffer pointers, has not yet been used (block803: no), a first level table in the memory is accessed (block804) for a pointer to a second level look-up table comprising the expiration time t1. If the first level table does not contain (block805: no) a pointer to the second level look-up table comprising t1, a pointer to the second level look-up table is allocated (block806) and also added (block806) to the first level table for later use. Allocating a pointer to the second level look-up table may include reserving memory space for the whole second level look-up table (i.e. for M rows). Then, or if the first level table contained (block805: yes) the pointer to the second level look-up table, using said pointer, the second level look-up table in the memory is accessed (block807) for a pointer to an event list with the expiration time t1(t1event list). If the second level look-up table does not contain (block808: no) a pointer to the t1event list, a pointer to the t1event list is allocated (block809) and also added (block809) to the second level look-up table for later use. Then, or if the second level look-up table contained (block808: yes) the pointer to the t1event list, using said pointer to the t1event list, the event e1is added (block810) to the t1event list, and a response indicating that the event e1is added may be transmitted (block811) as a response to the request.

If there is not enough time (block802: no), or if the maximum number of buffers have been used (block803: yes), a response indicating that the event e1is not added may be transmitted (block812) as a response to the request.

In an implementation, in which there are maximum number of buffer pointers for second level look-up tables and a maximum number of buffer pointer for event lists, the checking in block803may be modified to first include checking in block805, and if a new pointer is needed, whether there are one or more free pointers for the second level look-up tables, and if there are, or if there is an existing pointer to a second level look-up table, to check whether there are free pointers for the event list, if needed.

Referring toFIG.9, when a request to cancel at least the event e1with the expiration time t1from the timer pool indicated is received (block900), a time between current time and the expiration time is estimated (block901) in order to estimate whether there is enough time to cancel the event e1. If there is enough time (block902: yes), a first level table in the memory is accessed (block903) for a pointer to a second level look-up table comprising the expiration time t1. Then, using said pointer, the second level look-up table in the memory is accessed (block904) for a pointer to an event list with the expiration time t1(t1event list). Using said pointer to the t1event list, the event e1is removed (block905), or deleted, from the t1event list, for example by searching a matching event identifier, or event data structure, and when found, removing the event e1.

If the t1event list comprised no other events, i.e. the event e1removed was the last, or only, event in the t1event list (block906: yes), the pointer to the t1event list is deallocated (block907) and the second level look-up table in the memory is accessed (block908) and the pointer that was deallocated is removed (block908) from the second level look-up table.

If the second level look-up table comprised no other pointers, i.e. the pointer removed was the last, or only, pointer in the second level look-up table (block909: yes), the pointer to the second level look-up table is deallocated (block910) and the first level table in the memory is accessed (block911) and the pointer that was deallocated in block910is removed (block911) from the first level table.

Then, or if the t1event list contains (block906: no) one or more events after the event e1is removed, or if the second level look-up table contains (block909: no) one or more pointers after the pointer to the t1event list is removed, a response indicating that the event e1is cancelled may be transmitted (block912) as a response to the request.

If there is not enough time (block902: no) a response indicating that the event e1is not cancelled may be transmitted (block913) as a response to the request.

Referring toFIG.10, when it is detected (block1000) that an expiration time is met, events in the t1event list are processed by transferring (block1001) the events one by one to a processing queue, to generate, for example, timeouts, a timeout per an event in an event list whose associated time expired. Using the example ofFIG.2, and assuming that many timing events (timing event entries) are attached to the expiration time (i.e., many single-shot timers are armed for the expiration time), and that the events are transferred one by one to the event manager's queue, and that the event manager and its next processing block after the event manager's queue need time to process and store the timing event entries, then the last timing event entry will be stored in the event manager queue with some delay after the expiration time expired. The delay (process and store delay) may be calculated by multiplying the number of timing events in the event list by a number of clock cycles for queuing and processing of one timing event. After emptying the event list in block1001, a pointer to the event list for the expiration time is deallocated (block1002). The second level look-up table in the memory is also accessed (block1003) and the pointer that was deallocated is removed (block1003) from the second level look-up table. Then, it is checked, whether the second level look-up table contains (block1004: no) one or more pointers after the pointer is removed in block1003.

If the second level look-up table comprised no other pointers, i.e. the pointer removed was the last, or only, pointer in the second level look-up table (block1004: yes), the pointer to the second level look-up table is deallocated (block1005) and the first level table in the memory is accessed (block1006) and the pointer that was deallocated in block1005is removed (block1006) from the first level table. The result of the process is (block1007) then that expired events are queued and the event list, and the second level look-up table are updated to be non-existing by releasing corresponding memory resources.

If the second level look-up table comprised other pointers (block1004: no), the result of the process is (block1007) that expired events are queued and the event list is updated to be non-existing by releasing corresponding memory resources.

The engines, blocks, and related functions described above by means ofFIG.1toFIG.10in 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 other information may be sent, and/or other rules applied. Some of the blocks or part of the blocks or one or more pieces of information can also be left out or replaced by a corresponding block or part of the block or one or more pieces of information.

FIG.11illustrates an apparatus1101according to some embodiments. The apparatus1101may be an apparatus, e.g. an electrical device, for offloaded timing management, i.e. for managing timer pools and single-shot timing events within the timer pools.FIG.12illustrates an apparatus that may implement distributed functionality of the apparatus illustrated inFIG.11.

The apparatus1101may comprise one or more communication control circuitries1120, such as at least one processor, and at least one memory1130, including one or more algorithms1131, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the apparatus to carry out any one of the exemplified functionalities, described above with any ofFIG.1toFIG.10. Said at least one memory1130may also comprise at least one database1132.

According to an embodiment, there is provided an apparatus for managing timer pools and single-shot timing events within the timer pools, the apparatus comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: access first level look-up-tables, a first level look-up table per a timer pool, the first level look-up table comprising for the timer pool a plurality of rows for first pointers to second level look-up tables, access, using the first pointers, the second level look-up tables, a second level look-up table comprising M or less rows for second pointers to event lists with expiration times wherein an event list is associated with one expiration time, and comprises a plurality of single-shot timing events scheduled at the corresponding expiration time; and access, using the second pointers, the event lists to add or cancel single-shot timing events in the event lists.

Referring toFIG.11, the one or more communication control circuitries1120of the apparatus1101comprise at least a two level look-up table (2L-LUT) circuitry1121which is configured to perform accessing the first level look-up tables, the second level look-up tables and event lists to perform the time management related functions, according to embodiments. To this end, the two level look-up table circuitry1121of the apparatus1101is configured to carry out at least some of the functionalities described above, e.g., by means ofFIG.1toFIG.10, using one or more individual circuitries.

Referring toFIG.11, the memory1130may 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.

Referring toFIG.11, the apparatus1101may further comprise different interfaces1110such as one or more communication interfaces (TX/RX) comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The one or more communication interfaces1110may enable connecting to the Internet and/or to a core network of a wireless communications network and/or to a radio access network and/or to other apparatuses within range of the apparatus. The one or more communication interface1110may provide the apparatus with communication capabilities to communicate in a cellular communication system and enable communication to different network nodes or elements. The one or more communication interfaces1110may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de) modulator, and encoder/decoder circuitries, controlled by the corresponding controlling units, and possibly one or more antennas.

In an embodiment, as shown inFIG.12, at least some of the functionalities of the apparatus ofFIG.11may be shared between two physically separate devices, forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes. Thus, the apparatus ofFIG.12, utilizing such shared architecture, may comprise a remote control unit RCU1220, such as a host computer or a server computer, operatively coupled (e.g. via a wireless or wired network) to a remote distributed unit RDU1222. In an embodiment, at least some of the described processes may be performed by the RCU1220. In an embodiment, the execution of at least some of the described processes may be shared among the RDU1222and the RCU1220.

Similar toFIG.11, the apparatus ofFIG.12may comprise one or more communication control circuitries (CNTL)1120, such as at least one processor, and at least one memory (MEM)1130, including one or more algorithms (PROG)1131, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the apparatus to carry out any one of the exemplified functionalities of the apparatus described above, e.g., by means ofFIG.1, andFIG.5toFIG.9, for example, by the network device, or access device.

In an embodiment, the RCU1220may generate a virtual network through which the RCU1220communicates with the RDU1222. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization may involve platform virtualization, often combined with resource virtualization. Network virtualization may be categorized as external virtual networking which combines many networks, or parts of networks, into the server computer or the host computer (e.g. to the RCU). External network virtualization is targeted to optimized network sharing. Another category is internal virtual networking which provides network-like functionality to the software containers on a single system. Virtual networking may also be used for testing the terminal device.

In an embodiment, the virtual network may provide flexible distribution of operations between the RDU and the RCU. In practice, any digital signal processing task may be performed in either the RDU or the RCU and the boundary where the responsibility is shifted between the RDU and the RCU may be selected according to implementation.

In a still further embodiment, the apparatus ofFIG.10may be implemented in similar way as the apparatus ofFIG.12.

As used in this application, the term ‘circuitry’ may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software (and/or firmware), such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software, including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus, such as a terminal device or an access node, to perform various functions, and (c) hardware circuit(s)) and processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g. firmware) for operation, but the software may not be present when it is not needed for operation. This definition of ‘circuitry’ applies to all uses of this term in this application, including any claims. As a further example, as used in this application, the term ‘circuitry’ also covers an implementation of merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term ‘circuitry’ also covers, for example and if applicable to the particular claim element, a baseband integrated circuit for an access node or a terminal device or other computing or network device.

In an embodiment, at least some of the processes described in connection withFIG.1toFIG.10may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. 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 ofFIG.1toFIG.10or operations thereof.

Embodiments and examples 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 functionalities described in connection withFIG.1toFIG.10may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be provided as a computer readable medium comprising program instructions stored thereon or as a non-transitory computer readable medium comprising program instructions stored thereon. 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. The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM). 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.