Processing chaining in virtualized networks

To dynamically allow chaining of logical processing units comprising endpoints, at least a type of an endpoint, and address information whereto connect the endpoint is configured, wherein the type of the endpoint is either a host port type or a logical processing unit type. During offloading from a central processing unit one or more functions to be performed by at least one further processing unit, the central processing unit is interacting with the one or more logical processing units via endpoints of the host port type and logical processing units are interacting via endpoints of the logical processing unit port type, the interaction using the address information.

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. The hardware that supports virtualization may be commercial off-the-shelf platforms. To further increase performance and reduce power consumption, some of the functions may be offloaded from a general central processing unit to one or more hardware accelerators, that are specialized processing units.

SUMMARY

According to an aspect there is provided an apparatus comprising at least one central processing unit; at least one further processing unit; at least one memory including computer program code, the at least one memory and computer program code being configured to, with the processing units, cause the apparatus at least to perform: querying from the at least one further processing unit, per a further processing unit, information relating to chaining possibilities of logical processing units in a pipeline abstraction instantiated, said information queried comprising at least a number of ports and per a port address information and information on a direction of the port; configuring, using said information, per a logical processing unit to be chained, per an endpoint representing a port in the logical processing unit, at least a type of the endpoint, and address information whereto connect the endpoint, wherein the type of the endpoint is either a host port type or a logical processing unit type; and offloading from the at least one central processing units one or more functions to be performed by one or more of the at least one further processing unit by interacting with the one or more logical processing units via endpoints of the host port type and by interacting between logical processing units via endpoints of the logical processing unit port type, the interaction using the address information.

In an embodiment, the instantiated pipeline abstraction associates endpoints with one or more supported interface types and wherein the at least one memory and computer program code configured to, with the processing units, cause the apparatus at least to perform: configuring, per an endpoint, an interface type to the endpoint based on the interface types in the instantiated pipeline abstraction.

In an embodiment, the at least one memory and computer program code are configured to, with the processing units, cause the apparatus at least to perform: allowing data insertion from the at least one central processing units via an endpoint having interface type supporting data to be inserted; and allowing data retrieval via an endpoint having interface type supporting data to be retrieved.

In embodiments, the at least one memory and computer program code are configured to, with the processing units, cause the apparatus at least to perform: determining, when a direction of an endpoint provides an ingress interface, the interface type from a group comprising at least a burst data queue interface type allowing data to be transferred in a block with configurable size, a streaming data interface type allowing data to be transferred in a fixed size and in a fixed interval, the size and the interval being configurable, and a timing/clocking interface type, allowing use of a timing signal with configurable frequency and duty cycle; determining, when a direction of an endpoint provides an egress interface, the interface type from a group comprising the burst data queue interface type, the streaming data interface type, the timing/clocking interface type and an asynchronous event/data queue with callback interface type allows transfer of data/event asynchronously when the data/event is available and includes a pre-registered callback function that is called when the data/event is available.

In embodiments, the at least one memory and computer program code are configured to, with the processing units, cause the apparatus at least to perform the configuring over an application programming interface.

In embodiments, the at least one memory and computer program code are configured to, with the processing units, cause the apparatus at least to perform, prior to instantiating the pipeline abstraction: checking, in response to receiving an instantiation request comprising a pipeline abstraction, implementation options for the pipeline abstraction; selecting, when two or more implementation options are found during the checking, one of the implementation options; and instantiating the pipeline abstraction using selected implementation option.

In embodiments, the at least one memory and computer program code are configured to, with the processing units, cause the apparatus at least to perform, prior to instantiating the pipeline abstraction: checking, in response to receiving an instantiation request comprising a pipeline abstraction, implementation options for the pipeline abstraction; causing forwarding, when two or more implementation options are found during the checking, the implementation options towards an apparatus wherefrom the pipeline abstraction originated; receiving information on a selected implementation option amongst the two or more implementation options; and instantiating the pipeline abstraction using the selected implementation option.

In embodiments, the pipeline abstraction represents the two or more implementation options in a uniform way.

In embodiments, the at least one memory and computer program code are configured to, with the processing units, cause the processing units to establish direct physical connections for the interaction.

According to an aspect there is provided a method comprising: querying from at least one further processing unit, per a further processing unit, information relating to chaining possibilities of logical processing units in a pipeline abstraction instantiated, said information queried comprising at least a number of ports and per a port address information and information on a direction of the port; configuring, using said information, per a logical processing unit to be chained, per an endpoint representing a port in the logical processing unit, at least a type of the endpoint, and address information whereto connect the endpoint, wherein the type of the endpoint is either a host port type or a logical processing unit type; and offloading from at least one central processing units one or more functions to be performed by one or more of the at least one further processing unit by interacting with the one or more logical processing units via endpoints of the host port type and by interacting between logical processing units via endpoints of the logical processing unit port type, the interaction using the address information.

In an embodiment, the method further comprises: configuring, per an endpoint, an interface type to the endpoint based on the interface types in the instantiated pipeline abstraction.

In an embodiment, the method further comprises: allowing data insertion from the at least one central processing units via an endpoint having interface type supporting data to be inserted; and allowing data retrieval via an endpoint having interface type supporting data to be retrieved.

According to an aspect there is provided a computer readable medium comprising program instructions stored thereon for performing at least following: querying from at least one further processing unit, per a further processing unit, information relating to chaining possibilities of logical processing units in a pipeline abstraction instantiated, said information queried comprising at least a number of ports and per a port address information and information on a direction of the port; configuring, using said information, per a logical processing unit to be chained, per an endpoint representing a port in the logical processing unit, at least a type of the endpoint, and address information whereto connect the endpoint, wherein the type of the endpoint is either a host port type or a logical processing unit type; and offloading from at least one central processing units one or more functions to be performed by one or more of the at least one further processing unit by interacting with the one or more logical processing units via endpoints of the host port type and by interacting between logical processing units via endpoints of the logical processing unit port type, the interaction using the address information.

In an embodiment, the computer readable medium is a non-transitory computer readable medium.

According to an aspect there is provided a computer program comprising instructions for performing at least following: querying from at least one further processing unit, per a further processing unit, information relating to chaining possibilities of logical processing units in a pipeline abstraction instantiated, said information queried comprising at least a number of ports and per a port address information and information on a direction of the port; configuring, using said information, per a logical processing unit to be chained, per an endpoint representing a port in the logical processing unit, at least a type of the endpoint, and address information whereto connect the endpoint, wherein the type of the endpoint is either a host port type or a logical processing unit type; and offloading from at least one central processing units one or more functions to be performed by one or more of the at least one further processing unit by interacting with the one or more logical processing units via endpoints of the host port type and by interacting between logical processing units via endpoints of the logical processing unit port type, the interaction using the address information.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

The embodiments are not, however, restricted to the system100given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties.

The example ofFIG.1shows a part of an exemplifying radio access network.

FIG.1shows user devices101,101′ configured to be in a wireless connection on one or more communication channels with a node102. The node102is further connected to a core network105. In one example, the node102may be an access node such as (e/g)NodeB providing or serving devices in a cell. In one example, the node102may be a non-3GPP access node. The physical link from a device to a (e/g)NodeB is called uplink or reverse link and the physical link from the (e/g)NodeB to the 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 etc. entity suitable for such a usage.

The user device (also called UE, user equipment, user terminal, terminal device, etc.) illustrates one type of an apparatus to which resources on the air interface are allocated and assigned, and thus any feature described herein with a user device may be implemented with a corresponding apparatus, such as a relay node. An example of such a relay node is a layer 3 relay (self-backhauling relay) towards the base station.

The user device typically refers to a device (e.g. a portable or non-portable computing device) that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (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. It should be appreciated that a device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A device may also be a device having capability to operate in Internet of Things (IoT) network which is a scenario in which objects are provided with the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction, e.g. to be used in smart power grids and connected vehicles. The user device may also utilise cloud. In some applications, a user device may comprise a user portable device with radio parts (such as a watch, earphones, eyeglasses, other wearable accessories or wearables) and the computation is carried out in the cloud. The device (or in some embodiments a layer 3 relay node) is configured to perform one or more of user equipment functionalities. The user device may also be called a subscriber unit, mobile station, remote terminal, access terminal, user terminal or user equipment (UE) just to mention but a few names or apparatuses.

FIG.2illustrates a high-level view of entities in a cloud architecture supporting hardware acceleration. Referring toFIG.2, the cloud architecture200comprises a service management and orchestration framework (SM0)210and an open cloud220, the open cloud220providing an abstraction platform to separate abstractions of network functions from the processing hardware230. It should be appreciated that the cloud architecture may comprise also other elements not disclosed herein.

For a hardware acceleration pipeline, the service management and orchestration framework210comprises one or more network function orchestrators (NFO)201. A network function orchestrator201is a functional entity to manage a plurality of network functions that provide network services and/or contribute to network services by providing one or more parts of network services. The network function orchestrator201comprises different functions, for example instantiation of network services, by means of which the network function orchestrator201can manage network functions. The network function orchestrator201has, per a network service to be instantiated, information about hardware accelerators within its processing pipeline for one or more network functions involved in the network service.

The open cloud220hosts cloudified network functions and comprises one or more accelerator pipeline management service APMS entities202and one or more hardware accelerator manager entities203. An accelerator pipeline management service entity202provides deployment management services, interacting over an interface221with one or more network function orchestration entities201and over an internal interface222with one or more hardware accelerator manager HAM entities203. A hardware accelerator manager entity203manages interaction over an interface223with the hardware accelerators230.

The hardware accelerator230may comprise, for example, one or more hardware apparatuses comprising different general purpose processors, or other commercial off-the-shelf devices or platforms and application programming interfaces between the devices and platforms. 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-chip, a programmable application-specific integrated circuit and a smartNIC, which is a programmable network adapter card with programmable accelerators and Ethernet connectivity.

In 5G and beyond 5G, it is envisaged that hardware acceleration with corresponding abstraction models is used with the edge cloud. The abstraction models are utilizing logical processing units to represent hardware accelerators to which some network functions, or one or more parts of network functions, may be offloaded.

FIG.3illustrates an example of a logical processing unit LPU300, or more precisely, basic building blocks of the logical processing unit300representing resources within an instance of a network device (hardware device) providing one or more services. It should be appreciated that one logical processing unit may represent a network device that comprises multiple subsystems. Using the basic building blocks it is possible to represent heterogenous types of a hardware accelerator in a uniform way, for example in a pipeline abstraction, examples of which are described below. Examples of heterogenous types include different implementations of a set of acceleration functions, and a same set of acceleration functions from different vendors, a set comprising one or more acceleration functions.

Referring toFIG.3, the logical processing unit300comprises one or more ingress interfaces301, one or more egress interfaces302and one or more accelerator functions303, and if there are two or more accelerator functions, connectivity between functions, or between two accelerator functions. The connectivity may be a static connectivity, which is predefined (configured) while an abstraction model is defined, or a semi-static connectivity, that is programmable (or reconfigurable, changeable) via an application programming interface, for example. An interface, be that an ingress interface301or an egress interface302, is associated with an endpoint type, the endpoint type being in the illustrated examples either a host port or a logical processing unit (LPU) port. The endpoint type provides a possibility to chain offloaded logical processing unit instances while allowing the main process to insert or retrieve data within a chain, as will be described in more detail withFIGS.8and9. The connectivity between different accelerator functions, if any exists, and/or the definitions301of the ingress interface(s) and/or the definitions302of the egress interface(s) may be static, i.e. configured while an abstraction model is defined, or semi-static, i.e. programmable via an application programming interface.

Further, the one or more supported interface types depend on the abstracted network device. An ingress interface may be configured to support a burst data queue interface type, or a streaming data interface type, or a timing/clocking interface type. An egress interface may be configured to support the burst data queue interface type, or the streaming data interface type, or the timing/clocking interface type, or an asynchronous event/data queue with callback interface type. The burst data queue interface type allows data to be transferred in a block with configurable size. The streaming data interface type allows data to be transferred in fixed size and in fixed interval, both size and interval being configurable. The timing/clocking interface type allows use of a timing signal with configurable frequency and duty cycle. The asynchronous event/data queue with callback allows transfer of data/event asynchronously when the data/event is available and includes a pre-registered callback function that is called when the data/event is available.

FIGS.4to6illustrate different examples of information exchange sequences of a pipeline instantiation on a management plane of hardware accelerators using the cloud architecture illustrated inFIG.2. The functionality may be triggered in response to a new hardware being added to the network, or a new deployment of a hardware, in order a network management system to discover capabilities of the new hardware or the new deployment, or a new service request being received.

Referring toFIG.4, the network function orchestrator NFO detects in block4-1need for a network service and provides in block4-1a description file, which contains a pipeline abstraction. The pipeline abstraction provides accelerator types and a sequence of accelerators. The description file may be, for example, in JSON (JavaScript Object Notation) format, or in YAML format. (YAML is a human-readable data-serialization language.) The NFO then requests (message4-2) a pipeline instantiation using an accelerator pipeline management service APMS. Message4-2may be an “Acceleration pipeline instantiation request”. The APMS checks in block4-3the validity of the request, i.e. the validity of the description file. If the description is invalid, an error is returned to the NFO. However, in the illustrated example it is assumed, that the description file is valid, and the APMS creates (message4-4) an instantiation request (o-cloud internal instantiation request) towards a hardware accelerator manager HAM. Message4-4may be an “Abstract pipeline request”. Upon receiving the request (message4-4), the HAM checks in block4-5its internal inventory, for example a memory in the HAM, for possible instantiation options. A non-limiting list of examples of instantiation options include various capabilities and predefined configurations of the underlying hardware accelerators. In other words, the HAM performs o-cloud internal pipeline mapping by finding out capabilities of the underlying hardware, for example support of providing input directly to another hardware accelerator, or have memory required for some accelerator function, and/or otherwise ensure that the logical structure of the pipeline can be deployed in the hardware. In other words, in block4-5discovery is allowed. In the illustrated example it is assumed that one option is found, and hence the HAM proceeds in block4-5with the instantiation, i.e. instantiates the pipeline. The HAM then returns, via the APMS (message4-6, message4-7) to the NFO a set of addresses for data insertion and/or for data retrieval on which addresses the NFO can operate. Message4-6and message4-7may be “Addresses of requested pipeline data insertion/retrieval points”.

If the HAM finds in block4-5no possible instantiation option, it does not proceed with the instantiation, but would inform via the APMS that the pipeline abstraction cannot be instantiated. In such a case, message4-6and message4-7may be “NACK of pipeline instantiation request”.

The information exchange illustrated inFIGS.5and6differ from the one illustrated inFIG.4in that the HAM, when checking the internal instantiation options founds more than one option.

Referring toFIG.5, blocks5-1and5-3correspond to blocks4-1and4-3described withFIG.4, and messages5-2and5-4corresponds to messages4-2and4-4described withFIG.4, and are not repeated in vain herein. The HAM checks in block5-5its internal inventory for possible instantiation options. Since in the illustrated example two or more instantiation options are found in block5-5, the HAM selects in block5-5one of the options, based on its internal policy. A nonlimiting list of internal policy includes minimizing overall energy consumption and maximizing performance. The HAM then proceeds in block5-5with the instantiation of the selected option, and returns, via the APMS (message5-6, message5-7) to the NFO a set of addresses for data insertion and/or for data retrieval on which addresses the NFO can operate. Messages5-6and5-7correspond to message4-6and4-7.

Referring toFIG.6, blocks6-1and6-3correspond to blocks4-1and4-3described withFIG.4, and messages6-2and6-4corresponds to messages4-2and4-4described withFIG.4, and are not repeated in vain herein. The HAM checks in block6-5its internal inventory for possible instantiation options. Since in the illustrated example two or more instantiation options are found in block6-5, the HAM forwards the options to the NFO via the APMS (messages6-6,6-7). Messages6-6and6-7may be “Alternative mapping options”. The NFO selects, using a policy specified in the NFO, in block6-8one of the options, and forwards information on the selected option via the AMPS (messages6-9,6-10) to the HAM. The policy may be one of the policies given above as examples. Messages6-9and6-10may be “Acknowledgement of preferred mapping”. Upon receiving the information on the selected option, the HAM instantiates in block6-11the selected option. The HAM then returns, via the APMS (message6-12, message6-13) to the NFO a set of addresses for data insertion and/or for data retrieval on which addresses the NFO can operate. Messages6-12and6-13may be “Addresses of preferred pipeline data insertion/retrieval points”.

FIG.7illustrates a functionality of a hardware apparatus, or more precisely, an application program running on the hardware apparatus. The functionality described in blocks702to704may be performed once the hardware accelerator manager has instantiated the pipeline abstraction, i.e. separately from functionality disclosed in block701.

Referring toFIG.7, an executable code is loaded in block701to the hardware apparatus via a management interface between the hardware accelerator manager and the hardware apparatus and instantiated in block701. The executable code may be a kernel code or a firmware executable code. The executable code is a low level code that defines available ports and acceleration functions, enabling capabilities of the hardware accelerator. It should be appreciated that the executable code may be loaded to the hardware apparatus and instantiated when needed, or loaded earlier, in which case it is stored to the hardware apparatus. When the executable code has been loaded and instantiated, the hardware apparatus queries in block702, via an application programming interface, for example via an acceleration adaptation layer interface (AALI), the number of ports, their identifiers, directions (egress or ingress) and possible port related configurations. For example, the application program may use in block702a generic query function call in the application programming interface. The hardware apparatus, (the application program running in the hardware apparatus), then configures, including changing configurations, if needed, in block703the processing chain of logical processing unit(s), by defining, per an endpoint (representing a port), its endpoint type, its interface type, and address information indicating with which port to connect, and by commanding to apply the configuration. The application program may use in block703one or more configuration entity calls in the application programming interface. The processing chain is then created by causing connecting ports in block704the ports based on the end-point types and address information in the configuration. For example, the application program may use in block704a generic connect command call in the application programming interface. In other words, a port is connected to an acceleration function within a logical processing unit, or to a port on another logical processing unit.

FIG.8illustrates an example of chained logical processing units, for example for a data flow, created and configured in a data plane processing, via the application programming interface, by the application program, as described withFIG.7.

Referring toFIG.8, three logical processing units821,822,823have been chained, the logical processing units having ingress points depicted above the logical processing units with uppercase letters EP for ingress endpoints, and egress endpoints depicted below the logical processing units with lowercase letters ep for egress endpoints, the endpoint type of host port being depicted by underlined letters and the endpoint type of logical processing unit port being depicted by italic letters.

Referring toFIG.8, a first logical processing unit821comprises three different acceleration functions AF1821-1, AF2821-2and AF3821-3connected together in series, according to predefined connectivity. Further, the first logical processing unit821has two ingress endpoints EP1811, EP2812, both being host ports meaning that a host application can insert data to a corresponding acceleration function. The first logical processing unit821has also two egress endpoints ep3831and ep4832, one831of which is a host port and another832is a logical processing unit port. This means that processed data may be retrieved from endpoint831, whereas the other endpoint832provides data to be inserted to an acceleration function in another interface.

A second logical processing unit822comprises two different acceleration functions AF4822-1and AF5822-2, connected together in series. Further, the second logical processing unit has in the illustrated example only one ingress endpoint EP4813, which is a logical processing unit port, inserting data outputted by the first logical processing unit. The second logical processing unit822has also two egress endpoints ep6833and ep7834, one833of which is a host port and another834is a logical processing unit port. This means that processed data may be retrieved from endpoint833, whereas the other endpoint834provides data to be inserted to an acceleration function in another interface.

A third logical processing unit823comprises one acceleration function AF6823-1. Further, the third logical processing unit has in the illustrated example only one ingress endpoint EP7814, which is a logical processing unit port, inserting data outputted by the second logical processing unit. The third logical processing unit823has also one egress endpoint ep9835which is a host port.

For example, assuming that interface types defined for the different endpoints are the burst data queue for the EP1, the timing/clocking interface for the EP2, the asynchronous data for the EP3and EP6and streaming data for the EP9, a host application could insert burst data over the EP1, and a timing signal over the EP2, and retrieve asynchronous data indicating alert over the EP3and EP6, and streaming output data over the EP9.

As can be seen from the illustrated example ofFIG.8, a logical processing unit may comprise one or more acceleration functions. Further, it should be appreciated that there may be one or more logical processing units, and there may be one or more chains of logical processing unit, a chain meaning that an egress endpoint of a logical processing unit is connected to an ingress endpoint of another logical processing unit, the chain starting with a logical processing unit having ingress endpoints of host port types only and ending with a logical processing unit having egress endpoints of host port types only.

It should be appreciated that the second logical processing unit, as well as the third logical processing unit may comprise more than one ingress endpoint, which may be of the host port type. In other words, there are no limitations to the number of endpoints and their type.

FIG.9illustrates hardware implementation principles of the example ofFIG.8. In other words, it depicts a functional illustration how software processes running on a host processing unit may offload the processing to one or more other processing units (hardware accelerators) using the definitions of the instantiated model.

Referring toFIG.9, the first logical processing unit821ofFIG.8is denoted by LPUa, and its acceleration functions are denoted by AF1821-1, AF2821-2, and AF3821-2. The second logical processing unit822ofFIG.8is denoted by LPUb, and its acceleration functions are denoted by AF4822-1and AF5822-2. The third logical processing unit823ofFIG.8is denoted by LPUc, and its acceleration function is denoted by AF6823-1.

In the example ofFIG.9, a multithreaded core is used. In the example it is assumed that there may be running a main process (parent process) and one or more child processes on a host processing unit. However, it should be appreciated that in another implementation there may be no child processes.

In other words, inFIG.9, a main process running on a host processing unit, for example a host central processing unit, is illustrated on line910-1and a child process running on the host processing unit is illustrated on line910-2. Further, in the illustrated example, there is a separate processing unit, for example a hardware accelerator, per an offloaded logical processing unit. However, it should be appreciated that two or more logical processing units may be offloaded to one hardware accelerator. In other words, two or more logical processing units may be representations (abstractions) of the one (same) acceleration hardware in two or more logical partitions. The process running on a hardware accelerator for the LPUa821is illustrated on line921, the process running on a hardware accelerator for the LPUb822is illustrated on line922and the process running on a hardware accelerator for the LPUc823is illustrated on line923. Further, in the illustrated example, different processes inserting (sending) data to or receiving (retrieving) data from offloaded logical processing units are depicted by functions denoted by F1911(sending data to two ingress endpoints within LPUa), F2912(retrieving data from one egress endpoint within LPUa), F3913(retrieving data from one egress endpoint within LPUb) and F4914(retrieving data from one egress endpoint within LPUc).

Connections, including direct physical connections, between different functions include “host to accelerator” connections901, “accelerator to host” connections902and “accelerator to accelerator” connections903, that were created (established) using a connect command in the example ofFIG.7, the connect command conveying the configuration to be used. The connect command hence instructs the processing units to transfer data to/from the host via direct memory access or to/from another processing unit. The connections904within a processing unit are preconfigured internal connections.

As can be seen from the example illustrated inFIG.9, data returns to the host processing unit only when the host processing unit is the recipient, thanks to the port type definitions and address information. In other words, there is no need to bounce data back and forth between the host processing domain and one or more accelerator domains. Hence, processing latency caused by bouncing the data back and forth is avoided. Further, a transfer of data consumes power, and by avoiding the bouncing power can be saved.

The packet processing pipelines within a function running on the host processing unit or within an offloaded logical processing unit may be represented as a P4target in an implementation in which a P4language is used to define the processing pipelines illustrated inFIG.9. By means of the P4language logical processing pipelines are determined, the logical processing pipelines being translatable into any programming language or configuration parameters, which a hardware accelerator supports, and can use to implement a corresponding processing pipeline.

FIG.10is a flowchart illustrating an example of interaction over the application programming interface, for example in an apparatus, between one or more main application processes running in the host processing unit and a hardware abstraction layer in view of the hardware abstraction layer.

Referring toFIG.10, a hardware accelerator platform is initialized in block1001. Block1001may include receiving an application programming interface, API, function “init_platform( )” without any information in the hardware abstraction layer and sending from the hardware abstraction layer an API function “init_platform_response( )” with a platform identifier.

Then entities are queried in block1002. Entities are hardware accelerator instances, i.e. logical processing unit instances that are configurable via the application programming interface. Block1002may include receiving an API function “query_platform( )” with a platform identifier in the hardware abstraction layer, the identifier being the one sent in block1001, and sending from the hardware abstraction layer an API function “query_platform_response( )” with information on a number of entities, and a list of entities disclosing, per an entity, for example entity identifier, type, state, etc. For example, using the example inFIGS.8and9, information on LPUa, LPUb and LPUc may be sent.

Entities that are used in the processing pipeline are in the illustrated example initialized in block1003. Block1003may include receiving for all entities, per an entity, an API function “init_entity( )” with corresponding entity identifier in the hardware abstraction layer and sending from the hardware abstraction layer an API function “init_entity_response( )” with information indicating whether initializing succeeded or failed.

The entities that were successfully initialized are queried in block1004. Block1004may include receiving for the entities, per an entity, an API function “query_entity( )” with corresponding entity identifier in the hardware abstraction layer and sending from the hardware abstraction layer an API function “query_entity_response( )” with information on number of ports, a list of ports disclosing, per a port, for example port identifier, direction (input/output, or ingress/egress, ports), etc., number of functions (acceleration functions), and a list of functions disclosing, per a function, for example a function identifier, type, etc. The query response indicates both preconfigured internal connections and configurable connections.

In the illustrated example, entities with which the process is continued, are selected, by the application process based on the query response. It should be appreciated that all entities may be selected. The selected entities are configured in block1005by determining the configurations and receiving them in the hardware abstraction layer. Block1005may include receiving for selected entities an API function “configure_entity( )” with command with parameters that are to be refreshed (ptr_parameters) in the hardware abstraction layer, performing the configuration, and sending from the hardware abstraction layer an API function “configure_entity_ack( )” indicating whether the configuration succeeded. In the illustrated example it is assumed that the configuration succeeds. For example, the result of the configuration may be the chain illustrated inFIG.8. The command with parameters may contain, for example, following: load_kernel, connect_ep, connect_port, setup_qos, setup_interface, etc., i.e. commands to realize a corresponding logical processing unit, or chains of logical processing units, the end result being a logical chain, for example such as illustrated inFIG.8. In the example command ep means end point, a connect command may be from an LPU to the host, from the host to an LPU, or from an LPU to another LPU, qos means quality of service, and interface means interface type (of the supported interface types). This also causes the underlying hardware accelerators to establish direct physical connections.

Then the selected, and configured, entities are committed in block1006. Block1006may include receiving, per an entity, an API function “commit_entity( )” with the entity identifier in the hardware abstraction layer and sending from the hardware abstraction layer an API function “commit_entity_response( )” with information on a state and one or more interface identifiers, etc. An interface identifier is an end point identifier for data insertion or data retrieval.

When the processing starts, selected entities are activated in block1007. Block1007may include receiving, per an entity, an API function “activate_entity( )” with the entity identifier, the one or more interface identifiers, function identifier(s), etc. in the hardware abstraction layer and sending from the hardware abstraction layer an API function “activate_entity_ack( )” indicating whether the activation succeeded. In the illustrated example it is assumed that the activation succeeds. A function identifier refers to an acceleration function that has been selected, and if there are two or more function identifiers, it indicates that the acceleration functions are connected (preconfigured) inside an LPU (entity).

Then sending data and/or retrieving data and/or pinging entity procedures are repeated in block1008until processing is completed. Block1008may include receiving API functions “send_data( )” with the entity identifier, the interface identifier, and ptr data buffer (refresh data buffer) with data to be inserted, “retrieve_data( )” with the entity identifier, the interface identifier, and ptr data buffer, and “ping_entity( )” with the entity identifier in the hardware abstraction layer, and sending from the hardware abstraction layer API functions “send_data_ack( )”, “retrieve_data_response( )” with data retrieved, “ping_entity_response( )” with state of the entity and “entity_callback( )” with the entity identifier, the interface identifier and parameters to be refreshed.

When processing is completed, activated entities are stopped in block1009and then released in block1010. Block1009may include, per an activated entity, receiving an API function “stop_entity( )” in the hardware abstraction layer and sending from the hardware abstraction layer an API function “stop_entity_ack( )”. Block1010may include, per an activated entity, receiving an API function “release_entity( )” in the hardware abstraction layer and sending from the hardware abstraction layer an API function “release_entity_ack( )”.

The blocks, related functions, and information exchanges described above by means ofFIGS.2to10are 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 other information may be transmitted. 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. Further, the different implementations described for a block may be freely combined with any of different implementations of another block.

FIG.11illustrates an apparatus1100configured to provide a piece of hardware in or for a virtualized radio access network. The apparatus1100may be an electronic devices, examples being listed above withFIGS.1and2. The apparatus comprises a host processing unit1110, for example a central processing unit complex or a host server, comprising at least the central processing unit (CPU)1111, such as at least one processor or processing circuitry, and at least one memory1112including a computer program code (software, algorithm), wherein the at least one memory and the computer program code (software, algorithm) are configured, with the at least one processor, to cause the apparatus to carry out any one of the embodiments, examples and implementations described above.

Referring toFIG.11, the memory1112may 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, for example for storing at least temporarily information on configurations of logical processing units. The memory1112may further store other data, such as a data buffer for data waiting to be processed.

The apparatus1100comprises hardware accelerator circuitries, depicted in the illustrated Figure with two hardware accelerator circuitries A-HW11121, A-HW21122. It should be appreciated that there may be any number of hardware accelerator circuitries. Different examples of hardware circuitries are listed above withFIG.2. Ports of two or more hardware accelerator circuitries may be communicatively coupled to each other to allow them to be connected over an interface1103if ports are configured to be connected. An interface1101between the host processing unit1110and the hardware accelerator circuitry1121,1122may be an PCIe interface, for example, the interface allowing configuration of logical processing unit chains, data retrieval and data insertion.

The apparatus1100further comprises a communication interface1130comprising hardware and/or software for realizing communication connectivity according to one or more wireless and/or wired communication protocols. The communication interface1130may provide the apparatus with radio communication capabilities with different apparatuses, as well as communication capabilities towards the core network.

In an embodiment, at least some of the functionalities of the apparatus ofFIG.1100may be shared between two physically separate apparatuses, forming one operational entity. Therefore, the apparatus1100may be seen to depict the operational entity comprising one or more physically separate apparatuses for executing at least some of the processes described above.

In an embodiment, at least some of the processes described in connection withFIGS.2to10may 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.

According to yet another embodiment, the apparatus carrying out the embodiments/examples 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 ofFIGS.2to10, 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, examples are listed above. 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 apparatuses (nodes) 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.

It will be obvious to a person skilled in the art that, as technology advances, the inventive concept may be implemented in various ways. The embodiments are not limited to the exemplary embodiments described above, but may vary within the scope of the claims. Therefore, all words and expressions should be interpreted broadly, and they are intended to illustrate, not to restrict, the exemplary embodiments.