Configurable Protocol Engine

Abstract

A configurable protocol engine (CPE) capable of constructing (110) a desired protocol structure (112) according to the received configuration information. In addition, the CPE schedules the processing of received service primitives according to the priority levels thereof. The configuration information may include service requirements (102), indications of hardware and software resources (106, 108), and the required QoS (Quality of Service, 104) level. The CPE may be implemented as software, hardware, or as a combination of both.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

Hereinafter the invention is described in more detail by reference to the attached drawings, wherein

FIG. 1 discloses the CPE configuration process on a general level.

FIG. 2 illustrates the CPE's usability in relation to the common OSI model.

FIG. 3 depicts the CPE internals.

FIG. 4 discloses one option for protocol service categorization by utilizing the OSI model.

FIG. 5 depicts data flow inside the CPE upon receiving and processing data.

FIG. 6 is a CPE UML class diagram.

FIG. 7 is a CPE UML architecture diagram.

FIG. 8 is a CPE core UML architecture diagram.

FIG. 9 is a UML architecture diagram of the CPE scheduler.

FIG. 10 depicts one option for the function selection process in the CPE.

FIG. 11 visualises a video transmission system utilizing the CPE.

FIG. 12A is flow diagram of the method for constructing and managing a protocol with the CPE.

FIG. 12B further discloses the CPE configuration process in more detail.

FIG. 13 is a block diagram of a device capable of hosting the CPE.

DETAILED DESCRIPTION OF THE EMBODIMENT OF THE INVENTION

FIGS. 1-3 were already discussed in conjunction with the description of the summary of the invention.

FIG. 4 discloses, by way of example only, how typical protocol services may be categorized in relation to the OSI reference model. The protocol functions each of which realizes a simple protocol task are stored in the CPE function library. Whenever the CPE must be capable of providing protocol services that cover the most common services offered by the layers from 2 to 6 in the OSI model, the function library must include several protocol functions to carry out such services. Generally speaking, the protocol services can be divided into four categories according to which layer they are normally provided on.

The first category 408 of services is related to physical link services including link management and frame control. Also error detection services, radio management, and power save management are included in this category.

The second category 406, link protocol related services, includes data segmentation and reassembly services. Also flow control and error control services are present. The services in the second category 406 are normally provided by the upper part of the data link layer.

Network layer services form the third category 404. These are congestion control and routing related services. Also segmentation and flow control, as well as error control services are included. In the OSI reference model, such services are provided on the network and transport layers.

The fourth category 402, communication service related services, includes services concerning session management, data presentation, and data compression. These services are related to the session and presentation layers of the OSI model.

The protocol functions may then be selected to the CPE functions library by utilizing the knowledge about the most common services supported by communication protocols. Such functions may include

• parity bit calculation for calculating parity bit for the sent/received data,
• cyclic Redundancy Check (CRC) for calculating checksum for data using CRC,
• forward Error Correction (FEC) for implementing FEC as an error control method,
• automatic Repeat Request (ARQ) for implementing ARQ of damaged or lost packets,
• data retransmission for retransmitting data when requested,
• packet replication check for checking packet duplicates in case of packet replication,
• data encryption standard (DES) for encrypting/decrypting data,
• data re-sequencing for sequencing the data packets in the right order in case of unordered arrival of packets,
• data acknowledgement function for acknowledging the received data,
• sequence numbering for adding sequence number for data packets interpreting them at the receiving end,
• data segmentation for segmenting data packets to smaller packets/frames if needed,
• data reassembly for reassembling the segmented data, and
• power save for ordering the CPE utilizing device to go into power save mode on idle periods.

Next, the CPE top-level elements are described in more detail by referring first to FIG. 5 disclosing data flow through the CPE between the upper and lower protocol layers. In the figure, only a single scenario wherein data (˜service primitive) is received from the upper layer to be processed and finally delivered to the lower layer is illustrated with arrows for simplicity reasons. Configuration management 508 is described later in the text. When data arrives from the upper (or the lower) protocol layer, it passes through the instantiated CPE interface(s) 510 and enters the CPE core 506. Therein the data is placed into a data queue according to the priority of the data. Next, the data is retrieved from the queue and delivered to a protocol function 514 where it is processed. The core 506 handles the internal data traffic between the data queues and protocol functions 514, and the data is passed through a series of instantiated (filled in the figure) protocol functions 514 in a certain order. When the data arrives to a protocol function 514, the function processes the data and returns it back to the CPE core 506 that sends the data to the next protocol function 514. If the next protocol function 514 is busy handling other data, the data is stored to the data queues to be processed when the function 514 is available again. After the data has passed through all the needed protocol functions 514, it is placed into the outgoing data queue, from where it is sent to upper/lower protocol layer through an appropriate CPE interface 510 and SAP.

A UML (Unified Modeling Language) class diagram of the CPE is presented in FIG. 6 with relevant associations and compositions marked. As UML is nowadays a standard tool for describing software systems the average person skilled in the art is ought to be familiar with it. However, further information about the UML notation is available at the OMG (Object Management Group) homepage on the Internet [4] if needed. The CPE includes ProtocolInterfaces 602, ProtocolCore 604, ProtocolMIB 606, Functions 608, and ConfigurationManager 610 top-level classes, of which ProtocolInterfaces 602, Functions 608, and ProtocolMIB 606 classes must be realised according to the implemented protocol.

Correspondingly, a UML architecture diagram of the CPE is presented in FIG. 7. The CPE communicates with the environment through two ports. The user data port 702 (UserDataPort) is used by upper and lower layer protocol users. Both of these entities use data and management services of the particular protocol. The other port, management port 704 (UserMngPort) is used by the management user who configures and manages the CPE itself. The Core of CPE includes great majority of the CPE functionality, and is thus described in more detail below.

The controlling core is the nerve centre of the CPE. It contains most of the CPE functionality since it controls the execution of the assembled protocol and is responsible for reconfiguring the CPE in case of changes in the service requirements or in available resources. The core contains data queues for different priority class data and is responsible for initializing the data queues according to the configuration information. The core also handles the initialization of all internal processes, functions, and interfaces.

The core is divided into three sub-classes as depicted in the UML architecture diagram of FIG. 8. The Core configurator 804 is responsible for applying the CPE configuration, and it is controlled by the configuration manager through the management port. The configurator block 804 distributes the current configuration to other blocks by, for example, responding to the configuration inquiries. The CPE scheduler 802 schedules the processing of the primitives received from the interfaces and stores waiting primitives to the primitive queues 810. Data is then retrieved from the queues 806 at a right moment in accordance with e.g. the priority levels of data, and delivered to a proper protocol function. Finally, the core returns the processed data to the queues of outgoing data and from there to the CPE interfaces.

Internal architecture of the CPE scheduler is presented in the architecture diagram of FIG. 9. In addition to the scheduler sub-block 906 corresponding to the scheduler class, the CPE scheduler includes also three control sub-blocks, PrimitiveControl 902, QueueControl 904, and FunctionControl 908, to control communication with external blocks. The primitiveControl 902 receives primitives from the interfaces and forwards them to proper queues according to the priority thereof (indicated by the primitive), and vice versa. The QueueControl 904 handles the queues it contains (for example, instantiation and termination of Queue objects) and provides queue services to other blocks. The scheduler 906 sub-block selects primitives from the queues according to the scheduler algorithm that utilizes queue priorities and forwards primitives to the functions via the FunctionControl 908. The FunctionControl 908 handles function calls from the Scheduler 906 and forwards processed primitives back to the queues through the scheduler 906. A certain primitive may be delivered to a plurality of functions one at a time. The association between a certain primitive and a certain group of functions is specified in the FunctionControl 908 class as well as the proper order for their execution. Whenever a primitive is targeted to a function already in use, the primitive is returned back to the queue until the function becomes available again.

Considering the data flow during the scheduling phase, the CPE core receives primitives from the interfaces and they are stored in the queues with the help of primitive controller 902. There are separate queues 904 for different primitive types, which allows prioritising. When the CPE scheduler 906 is activated to process the primitives, the CPE scheduler algorithm selects the next queue to process. A primitive is received from the selected queue and the function controller 908 resolves the next function in the primitive processing sequence and calls the function. When the function (or a plurality of required functions respectively) finishes the processing, the primitive is stored back to the queue 904.

The CPE is configured through a configuration manager as mentioned before. The configuration manager is in this particular embodiment used only for the configuration and reconfiguration of the CPE thus its main responsibilities include, for example, reception of the configuration information from the CPE management user. The configuration manager analyses the configuration information and formulates necessary instructions for the CPE core about which functions need to be instantiated, which interfaces are required, and what kind of data queues have to be established. Information about the current configuration is stored in the MIB. This includes the information about the protocol functions included in the protocol assembly and the information about the available hardware and network resources. The information stored in the MIB is used at least by the CPE core.

The configuration information consists of several different elements: required protocol services and a required service level for each service, available hardware resources, parameters concerning the characteristics of the used network, information about the upper and lower protocol layers between which the CPE resides, and also about the desired QoS, which in the CPE refers to e.g. a number of data priority levels needed.

The protocol services required by the CPE user are listed in the configuration information. The list consists of one or more protocol services available in CPE. The protocol services can be offered by using a suitable set of CPE protocol functions introduced hereinbefore, for example. The required minimum service level (Qmin) for each service can be announced as an integer value from 1 to 5.

Information about the available hardware resources can be specified by various parameters as well: available physical memory, available processor power, and the battery power level in the physical device etc.

Also different parameters concerning the characteristics of the used network shall be defined: the available network bandwidth, Bit Error Rate (BER), the Maximum Transfer Unit (MTU) size, jitter for packet transfer in the network, and information about the used transfer medium. The last parameter can be used to advertise whether the network is wireless or wired.

Information about the surrounding protocol layers is stated in the configuration information with e.g. two parameters: the upper protocol layer and the lower protocol layer announcing the corresponding protocol layers in the OSI model.

QoS is supported in the CPE data delivery by, for example, dividing data into different priority classes. The last parameter in the configuration information states the number of desired priority levels for data.

One feasible option for the CPE configuration information is summarized in the following table 1. Value ranges and used units of the configuration parameters are also presented.

TABLE 1
Information Element       Description
List of required services The required protocol services presented as
and a required minimum    a list. The available protocol services are:
service level for each    Error detection
service                   Error control
                          Corruption control
                          Data retransmission
                          Packet replication control
                          Encryption & decryption
                          Ordered delivery of data
                          Flow control.
Available hardware        Parameters describing the available hardware
resources                 resources in the end system:
                          Processor power (integer value >0, Million
                          Instructions Per Second, MIPS)
                          Physical memory (integer value >0, KB)
Network characteristics   Parameters describing the characteristics of
                          the used network:
                          Network bandwidth (integer value >0, Kb/s)
                          BER (real value >0, no units)
                          MTU (integer value >0, octets)
Surrounding protocol      Numbers representing the corresponding OSI
layers                    layers for the protocol layers above and below
                          CPE.
                          Upper protocol layer (integer value 3-7, no
                          units)
QoS                       Desired QoS is expressed as a number defining
                          the desired priority level.
                          Priority levels (integer value 1-10, no units)

As seen from the above table, in this case the QoS and the associated priority level has been expressed as a simple numeric parameter having values between 1 and 10 for simplicity reasons. In practice, numerous QoS algorithms and definitions exist with a plurality of different parameters. Such alternative methods are similarly feasible in providing priority information to the CPE for further utilization. Correspondingly, “Surrounding protocol layers” element may be used for indicating also the used protocol version (IPv4 versus IPv6, for example) and other protocol or protocol layer specific information, not just the layer in which the surrounding protocols are located.

As mentioned earlier, the configuration and reconfiguration of CPE comprises delivering the configuration information to CPE and creating a protocol assembly according to that information. After that, the configured CPE is used for data transfer as a normal protocol.

After specifying the configuration information and delivering it to CPE the available hardware resources and the parameters concerning the used network are analyzed and maximum values for e.g. three cost factors are set. The cost factors are numerical values that present the relative influence on the load that the created protocol assembly puts on the available hardware resources and on the used network.

The three cost factors are defined for each function as follows: D for overhead traffic, P for processor power, and M for memory. All of those are described as an integer value from 1 to 10, with 1 corresponding to the lowest relative influence.

The factor D describes the relative amount of overhead traffic that is generated by the function in question. For example, data acknowledgement function generates overhead traffic by sending acknowledgement messages.

The factor P describes the relative level of processor power needed for executing the function. For example, encryption function puts relatively high load on the processor where as, for example, the execution of a parity bit calculation function requires less processor power.

The M factor describes the relative amount of physical memory needed if the function is included in the protocol assembly. For example, data retransmission function requires some kind of data buffering ability and that requires relatively high amount of physical memory.

In addition to the cost factors, a Q-value is defined for each function. It specifies the level of service the function is capable of providing. For example, an error detection service can be provided with a parity bit calculation function or with a CRC (Cyclic Redundancy Check) function. With CRC, more errors can be detected from the received data. Therefore the CRC function has a higher Q-value than the parity bit calculation function.

Each function contains e.g. six different parameters: name, three cost factors M, P, and D, the level of service Q, and finally the function dependencies specifying the other functions required in the protocol assembly with the one in question.

The selection of functions to implement the required services is done in the following manner for each of the services: The Qmin value of the service is compared to Q-value (Qi) of the functions capable of providing the service. Next, the cost factor values (Di, Pi, Mi) of the functions having

Qi≧Qmin  (1)

are compared to the maximum values for the three cost factors (Dmax, Pmax, Mmax), which describe the limit that should not be exceeded by any protocol function that is included in the created protocol assembly. The comparison is done by calculating the total difference

Ti=Dmax−Di+Pmax−Pi +Mmax−Mi  (2)

for the protocol functions satisfying (1). The function having the highest Ti is then selected to be included in the assembly. If the selected function requires also other functions to be included in the assembly to implement the service, the selection of these functions is done in the same manner.

FIG. 10 illustrates the above function selection process. In this example, a service can be implemented by including one of three functions, Function11002, Function21004, and Function31006, in the protocol assembly. First, levels of service factors (Q) are checked, and the Function11002 is dropped as being not able to provide an adequate service level. Then the cost difference (T) according to (2) is calculated on the basis of which function21004 is finally selected due to a larger difference.

A list of protocol functions needed to implement all the required services can be formed in the above-described manner. The configuration manager passes the list to the CPE core that instantiates the required protocol functions from the CPE function library. It is noted that also other methods can be applied in the function selection process if found useful. The above solution is only a simplistic example, being however quite feasible if more sophisticated solutions are not necessary.

In addition to the selection and instantiation of protocol functions, the needed interfaces and data queues are initialised. After this, the configuration is ready and CPE can be used for data transfer.

Further reverting to the CPE scheduling algorithm for a moment, as the configuration information defines the required services and the associated QoS values, the CPE scheduler may create a separate queue for each required QoS (priority) value/class, and in the most simple implementation, just handle/serve the various service primitives (or derivatives thereof, e.g. modified primitives with added/deleted data) placed into the queues by controlling the processing of the queues according to the related QoS value in decreasing order.

Priority as a concept, however, should be interpreted more broadly than just a single QoS parameter that defines a proper queue for a primitive. Instead, priority refers to a general importance of e.g. a service, a service primitive, or a group of services/primitives respectively, and therefore may actually affect the service requirements and service levels including both software and hardware aspects. Thus, a number of different priority factors may exist for a certain service/primitive. Then, for example, part of the priority information may indicate how the data associated with a certain priority should be secured/protected (e.g. channel coding, encryption) in addition to mere latency issues handled by the priority queues.

A need for adjusting the current CPE configuration may arise while using CPE for data transfer. The CPE user may need some additional protocol services or some services are not required any more. Such situation may be caused by the change in the available hardware or network resources, data priority levels or the other protocol layers surrounding the CPE. Because of the changes, a new set of configuration information must be specified. The CPE management user delivers this information to CPE and the (re)configuration is initiated. Before instantiating new protocol functions or interfaces, and creating new data queues based on the new configuration information, CPE is reset using either a soft or hard reset request. After this, the reconfiguration process goes through the same phases as the boot-time configuration of the CPE presented hereinbefore. If only minor changes are needed, a supplementary configuration update message may be specified in order to alter/insert/delete a certain service in the otherwise still applicable existing configuration, for example.

As one possible use case of the invention, a sketch of a video transmission system is presented in FIG. 11. Real-time video streaming services are becoming more and more popular and can even be utilized by the modern mobile hand-held devices such as mobile terminals. Therefore, it's not an unusual scenario to occur in which a video server system 1102 encodes 1106 and transmits coded video data to a device that can be located either at the end of some fixed or wireless connection respectively. For example, the case-specific far-end client that can be e.g. a mobile terminal 1112, a PDA/laptop 1114, or a personal (desktop) computer 1116, may bear wireless connectivity means like GSM, WLAN (Wireless Local Area Network) or Bluetooth radio transceiver, or interfacing means for wire transmission like an Ethernet adapter.

Traditionally oriented approach in aforesaid cases for supporting different data transmission techniques in the server system 1102 has been the installation of additional protocols/several parallel protocol stacks and/or a plurality of specific interface cards providing the necessary transmission technique specific transceivers and/or supplementary protocols to the server device. Thereupon, the resulting arrangement has surely not been optimised in relation to memory consumption, configurability, or adaptivity issues etc. For real-time video streaming, a protocol stack that is transparent from the application's viewpoint would be beneficial as the coder could then directly control e.g. retransmissions and bit error protection. As varying channel conditions like noise, fading effects, and congestion, typically cause problems to data transmission; these factors should be taken into account upon transferring video data. Advantageously, e.g. used video coding, ciphering, and protection (channel coding and error concealment, for example) methods should be separately adapted to different connection types even during a connection due to changed channel conditions or some other factor. It's now obvious that the CPE 1110 could be used to construct a transparent adaptive protocol (stack) to overcome the above dynamic scenarios as described hereinbefore. Moreover, the CPE may be configured to take care of functionalities otherwise handled by the application itself. The encoder 1106 can provide the CPE 1110 initial configuration information in order to set up the necessary interfaces, to instantiate proper functions, and to organize the scheduling of different video service primitives with a plurality of queues; the CPE 1110 is acting as a flexible VCP (Video Control Protocol) 1104 from there on. Instead of otherwise inevitably quite complex protocol structure with several vertical (and possibly horizontal) layers a single CPE entity 1110 may be thus configured to provide at least most if not all services/functionalities necessary for reliable, transparent and fast video transmission. This feature is highlighted in the figure by representing the CPE as an object with single input/output arrows and a dotted feedback arrow describing the various internal connections and processing chains. Likewise, the client devices 1112, 1114, and 1116 may utilize the CPE for data (including signalling) reception and transmission, and be that way enabled to connect to a variety of services over different protocol arrangements without redundancy introduced by parallel protocol stacks. Situations may occur in which the server can be fully packed with different partly overlapping software and hardware solutions without problems but the same processing, memory, and maybe even physical space resources (e.g. in small-sized terminals) do not exist in the client side, and the CPE may be used to cut down unnecessary processing and memory usage, for example. The client device may bear a plurality of physical connecting means (multiple or adaptive transceiver arrangements, network adapter) and then utilize the CPE to provide flexibly configurable upper protocol layer(s) for successful service reception.

Thus, the interface 1108 for actual physical (protocol) layer concerning both the server and the client devices can be carried out by the functionalities both in the CPE and in various physical interface adapters, or by embedding necessary hardware means to the CPE module, or just by letting the separate physical interface(s) 1108 to fully take care of the low-level transmission over the physical interface.

A method of the invention for configuring and constructing a protocol by utilizing the CPE concept is described with the help of FIGS. 12A and 12B, the former of which disclosing the CPE internal flow diagram upon receiving a service primitive/configuration information and the latter disclosing the few events taken during the CPE configuration process in more detail.

In step 1202, the method execution is ramped-up, e.g. the necessary hardware is configured, related software is loaded to the memory of the executing device, and various parameters are set to their initialisation values. Upon receiving data entity either through the user or management SAP 1204 and corresponding interfaces, a proper execution path is selected. If the incoming data is a standard service primitive, its type is determined in step 1206 meaning the service identifier is extracted from the primitive by the CPE core (primitive control block) in order to place it to a proper queue (handled by the queue control block) that is done in step 1208. The primitive is not processed until the primitives with higher priority (or with equal priority but received earlier thus having a higher position (i.e. primitive at the top to be processed next) in the queue) have been served 1210, this being taken care of by the scheduler algorithm, after which the function control block drives the primitive data through required functions in step 1212. Then the processed data is placed in a proper outgoing queue 1214 to be delivered to the adjacent protocol layer in step 1220. The method is ended or re-started in phase 1222. In case of configuration information that has been defined by the management user and delivered to the CPE, the configuration manager first analyses the information by, for example, calculating the aforesaid cost factors for function selection etc in order to define 1216 the actual CPE configuration. The CPE configuration is taken into use by delivering necessary instructions for instantiating suitable functions and for creating required interfaces and primitive queues to the protocol core 1218. The CPE core then adapts to the newly received configuration.

In FIG. 12B the adaptation phase 1218 is further illustrated via a three-step process: interface configuration 1224, queue/scheduler configuration 1226, and function configuration (˜selection) 1228. The execution order of the presented steps is not a critical issue though.

FIG. 13 depicts basic components of a device like a mobile terminal or a computer capable of processing, storing, and transferring data in accordance with the invention. Memory 1304, comprised of one or more physical memory chips, includes necessary CPE code 1316, e.g. in a form of a computer program/application, and necessary data (and/or necessary free data space) like the CPE configuration 1312 and a number of queues 1314 for the primitives. A processing unit 1302 is required for the actual execution of the code 1316, albeit at least part of the CPE functionality can be carried out with specialized hardware 1318, for example. Display 1306 and keypad 1310 are optional components for providing necessary device control and data visualization means (˜user interface) to the users. Data transfer means 1308, e.g. a radio transceiver, a serial/parallel bus, or a network adapter are required for handling actual physical level data (including standard service primitives and configuration information) exchange with other devices. The code 1316 for the execution of the proposed engine can be stored and delivered on a carrier medium like a floppy, a CD or a memory card.

Thus, the CPE may be constructed as software, hardware or a combination of both. Such hardware may include microprocessors, microcontrollers, programmable logic chips and various circuit arrangements. In addition, the CPE can be realized as a separate module that is connected to the existing system. The module may act between different system components or as an intermediate entity between two different systems.

The configuration information acting as a CPE configuration source can be delivered to the CPE manager as presented hereinbefore to be cultivated into an actual (final) CPE configuration by the manager and to be taken into use by the CPE core. However, the CPE configuration can also be explicitly constructed and possibly verified (by utilizing predefined configuration test software that matches the configuration to the specifications determining allowed parameter combinations, for example) by the managing or some other external entity to be only delivered to the CPE for direct utilization without further calculations. Likewise, new functions may be added to the function library by utilizing the network connections. They must, however, follow the general rules defined for admissible functions in the CPE, and either the entity that is about to provide the functions or the CPE engine itself may utilize various self-test programs in order to verify proper composition of the constructed/received functions before transmission/adoption.

The scope of the invention can be found in the following claims. However, utilized devices, method steps, configuration information, protocol internal structure, message and data structures etc may vary depending on the scenario, still converging to the basic ideas of this invention. For example, it is clear that the invention can be utilized in many different systems, not only in connection with the OSI model that was mentioned and used as a starting point for modifications in this text only due to its evident popularity in communication systems in general. Moreover, it is noted that the numeric values and numeric ranges used in the text are only exemplary and surely not the only ones applicable to exploitation in the CPE.

REFERENCES

[1] Peterson Larry L., Davie Bruce S.: Computer Networks: A Systems Approach, 3rd Edition, Morgan Kaufman 2003, ISBN 155860832X

[2] Siebert Matthias: Design of a generic Protocol Stack for an Adaptive Terminal, Karlsruhe Workshop on Software Radios 2000 (http://www.comnets.rwth-aachen.de/publications/alpha.html)

[3] Calvert K. L, Kravets R. H., Krupczak R. D: An extensible End-to-End Protocol and Framework, College of Computing, Georgia Institute of Technology 1995

[4] UML Resource Page on the Internet (http://www.omg.org/uml/), OMG 2003

Claims

1. A configurable protocol engine (CPE) for configuring and constructing a communication protocol comprising means for receiving service primitives,means for receiving configuration information,means for managing the CPE configuration on the basis of the configuration information,means for controlling and scheduling at least part of internal processing in the CPE on the basis of the CPE configuration,means for interfacing an upper and lower protocol layer on the basis of the CPE configuration, anda number of functions for processing data in accordance with the CPE configuration.

2. The configurable protocol engine of claim 1, arranged to select said number of functions on the basis of the CPE configuration from a plurality of functions, said plurality of functions comprising an equal or larger number of functions than said number of functions.

3. The configurable protocol engine of claim 1, arranged to receive and process the configuration information during the CPE start-up or at run-time.

4. The configurable protocol engine of claim 1, arranged to construct said CPE configuration on the basis of at least one of the following: service requirements, required QoS (Quality of Service), hardware resources, and network resources.

5. The configurable protocol engine of claim 1, arranged to configure said means for interfacing an upper and lower protocol layer on the basis of received configuration information.

6. The configurable protocol engine of claim 1, arranged to receive one or more functions from an external entity to be included in said number of functions.

7. The configurable protocol engine of claim 1, arranged to select a function to said number of functions on the basis of the service level provided by the function or of at least one cost factor related to said function.

8. The configurable protocol engine of claim 1, arranged to apply scheduling to the received service primitives.

9. The configurable protocol engine of claim 1, arranged to perform scheduling by maintaining a number of queues for the service primitives, said queues served on the basis of their priority, and said primitives placed into the queues on the basis of their priority.

10. The configurable protocol engine of claim 1, wherein the received configuration information explicitly defines the CPE configuration.

11. The configurable protocol engine of claim 1, wherein the received configuration information is a source for constructing the CPE configuration.

12. The configurable protocol engine of claim 1 that is software, hardware, or a combination of both.

13. A method for configuring a configurable protocol engine (CPE) in order to construct a communication protocol, said method having the steps of receiving configuration information,defining the CPE configuration on the basis of said configuration information, andadapting the CPE to the defined CPE configuration, whereby at least one action is performed, said action selected from the group of: an interface towards an external entity is implemented, a queue for a service primitive is implemented, and a function to be used for processing data included in a service primitive is determined.

14. The method of claim 13, wherein the CPE configuration is defined on the basis of at least one of the following: service requirements, required QoS (Quality of Service), hardware resources, and network resources.

15. The method of claim 13, wherein after configuring the CPE the received service primitives are scheduled on the basis of their priority classification by placing a received service primitive or a derivative thereof into a queue with corresponding priority classification, and by serving said queue according to the priority classification thereof.

16. The method of claim 13, wherein the function is determined by selecting the function from a plurality of functions on the basis of the CPE configuration, or by receiving the function or an indication thereof from an external entity.

17. A computer program for implementing at least part of a configurable protocol engine (CPE) for constructing a protocol, said computer program comprising code means to define and manage the CPE configuration on the basis of available configuration information,to schedule processing of received service primitives on the basis of the CPE configuration, andto provide a number of functions for processing data included in the service primitives in accordance with the CPE configuration.

18. The computer program of claim 17, wherein said code means to schedule are configured to maintain a number of queues for the service primitives or derivatives thereof, said code means to schedule further configured to serve the primitives or derivatives thereof on the basis of their priority, said primitives placed into the queues on the basis of their priority.

19. A carrier medium carrying the computer executable program of claim 17.

20. An electronic device for implementing a configurable protocol engine (CPE) capable of receiving and processing service primitives, said device comprising processing and memory means for processing and storing instructions and data, and data transfer means for transferring data, said device arranged to receive configuration information, to manage the CPE configuration on the basis of the configuration information, to schedule at least part of the internal processing within the CPE on the basis of the CPE configuration, and to process received service primitives in accordance with the CPE configuration.

21. The electronic device of claim 20, further arranged to interface an upper and lower protocol layer on the basis of the CPE configuration.

22. The electronic device of claim 20, further arranged to select a number of functions from a plurality of functions in accordance with the CPE configuration in order to implement a protocol.

23. The electronic device of claim 20, further arranged to perform the scheduling by maintaining a number of queues with different priorities for the service primitives or derivatives thereof, and by serving the primitives or derivatives thereof on the basis of their priority, said primitives placed into the queues on the basis of their priority.

24. The electronic device of claim 23, arranged to utilize separate queues for each primitive type.

25. The electronic device of claim 2024, further arranged to place a primitive retrieved from a queue back to the queue if the function required by the primitive is already in use.

26. The electronic device of claim 20 that is substantially a wireless communication device or a computer.