WO2010109260A1 - A multistandard protocol stack with an access channel - Google Patents

Abstract

In current architectures it is not possible to customise a multistandard protocol stack across all layers of the OSI model. Therefore an architecture for centralizing communications standards in a generalist and flexible framework is disclosed. This architecture comprises at least a protocol entity- topped and/or bottomed by an adaptation layer; - at least an access channels enabling a unidirectional incoming access to a protocol entity or to an adaptation layer; - at least a micro-processing unit per protocol entity and associated thereto; - a channel scheduler; - a time manager; - a protocol stack manager.

Description

A MULTISTANDARD PROTOCOL STACK WITH AN ACCESS CHANNEL

FIELD OF THE INVENTION

The present invention relates generally to telecommunication field and more particularly to multistandard protocol stack management.

BACKGROUND OF THE INVENTION

Both wire and wireless telecommunication technologies have received particular worldwide attention during the last few years, leading to a daily development. In fact, new telecommunication systems and services emerge at a very fast pace. However, these systems evolve independently by specific interest and they are generally based on further evolution of earlier specific platforms or on wholly new ones, which may limit their interoperability spread. Hence, theirs closed and appropriated platforms do not bode well for their success.

Therefore, new generations of telecommunications systems should not focus only on new air-interfaces or data-rate increase, but also on different telecommunication technologies embracement. Then, the challenge consists in transitioning from specialized systems architectures to more flexible ones. Accordingly, new technologies trends are driven by the notion of providing multiple services, using a single mobile terminal. In particular, this concerns wireless communication, including short-range wireless connectivity (such as Bluetooth™, HiperLAN, Wireless LAN, Home

RF, WiFi and ZigBee) and Public Land Mobile Networks (PLMN) (such as

GSM, GPRS, W-CDMA and WiMAX).

Various solutions have been proposed to achieve the above challenge. These, mainly, include Multi-Radios Platform (MRP), Software Defined Radio (SDR) or more generally Open Wireless Architecture (OWA), and software framework based solutions.

In order to support multi-radio for commercial mobile communications,

MRP groups several separate radio transceivers into one mobile terminal leading to a system architecture having as many standards as processors

(CPU) and/or DSP and RF-IF interfaces. Each CPU has its own memory system, clock generator, Direct Memory Access (DMA), reset circuit, interrupt controller, debug support and interprocessor communications circuit. As examples, the WCDMA/WLAN/Bluetooth™ or WCDMA/OFDM/WLAN three-in-one products are already developed according to this approach. Multi-Radios Platform technologies have some drawbacks, e.g. :

the MRP work out is a bulky system which consumes much power; due to power and processing resources constraints, MRP is limited to a few number of radio standards (2 or 3).

OWA consists in adding reconfigurability to the digital processing by using parametrizable hardware (ASIC, FPGA) or by putting as much functionality as possible in the software. It mainly concerns the opening parameters, including inter alia frequency range, modulation type, and output power limitations, which may be set or altered by software. Hence, this approach, including SDR, spreads only over the lowest layer of the basic reference Open System Interconnection (OSI) model: the layer in which processing of RF, IF or baseband signal processing occurs.

As an example of software framework based approach, one can mention the Distrinet Protocol Stack framework (DiPS), (Sam Michiels et al, "Component Framework Technology for Adaptable and Manageable Protocol Stacks", 2003). The DiPS framework aims at developing a protocol stack concerning layers atop the IP layer. In this regard, it is based on multithreaded program which may be constrained by the hardware platform capacity.

Then, according to the proposed solutions, it is not possible to customize a multistandard protocol stack along the whole layers composing the OSI model within power consumption and hardware capacity constraints. In other words, up-to-date solutions

- do not offer a sufficient flexibility to be able to jointly build different standard protocol stacks by changing specific functionality inside a particular layer, wherever it is in the OSI model ; and/or - use a multithreaded or multi-processor hardware platform, which may be constrained by energy autonomy and portability of the handheld device.

It is an object of the present invention to provide methods developing multistandard protocol stacks covering all the layers of the OSI model.

Another object of the present invention is to provide methods for deploying a monothreaded real-time operating system managing multistandard protocol stacks.

Another object of the present invention is to provide methods for a software convergence of telecommunication standards.

Another object of the present invention is to provide methods enabling interaction between devices attached to networks using different telecommunication standards.

Another object of the present invention is to provide methods for developing a self-adaptable multistandard protocol stack.

Another object of the present invention is to provide methods for developing an optimized protocol stack.

Some embodiments provide methods for transiting from proprietary architecture to a more generalist and flexible wireless architecture system.

DESCRIPTION OF THE DRAWING

The objects, advantages and other features of the present invention will become more apparent from the following disclosure and claims. The following non-restrictive description of a preferred embodiment of the invention is given for the purpose of exemplification only with reference to the accompanying drawings in which:

- figure 1 is a block diagram illustrating protocol stack according to the OSI model ;

- figure 2 is a block diagram illustrating protocol stack according to the present invention ; - figure 3 is a block diagram illustrating some components of the multistandard protocol stack, highlighting the relationships among them;

- figure 4-8 are block diagrams showing different possible organization of some components within the multistandard protocol stack;

- figure 9 is a block diagram illustrating a preferred organization of a component within the multistandard protocol stack ;

- figure 10 is a block diagram illustrating protocol processing progress according to the present invention;

- figure 1 1 is a block diagram illustrating a non-limitative embodiment of a multistandard protocol stack conceived according to the present invention.

Similar graphical symbols refer to identical components throughout the drawings.

SUMMARY OF THE INVENTION

The present invention relates to methods for centralizing communications standards in a generalist and flexible framework, comprising:

- at least a protocol entity topped and/or bottomed by an adaptation layer ;

- at least an access channel enabling a unidirectional incoming access to a protocol entity or to an adaptation layer ;

- at least a micro-processing unit per protocol entity and associated thereto ;

- a channel scheduler ;

- a time manager ;

- a protocol stack manager.

The present invention further relates to an apparatus enabling communication systems interconnection, comprising:

- at least a protocol entity topped and/or bottomed by an adaptation layer ; - at least an access channel enabling a unidirectional incoming access to a protocol entity or to an adaptation layer ; at least a micro-processing unit per protocol entity and associated thereto; - a channel scheduler ;

- a time manager ;

- a protocol stack manager.

The present invention further relates to a computer program product implemented in a communication device enabling communication systems interconnection, comprising:

- the implementation of at least a protocol entity ;

- the implementation of at least an adaptation layer ;

- the implementation of at least a micro-processing unit per protocol entity and associated thereto; - the implementation of at least an access channel per protocol entity and associated thereto;

- the implementation of at least an access channel per adaptation layer and associated thereto ;

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

OSI model is a basic reference model, developed as a standard protocol stack to communicate within a telecommunication network. The OSI model 10, diagrammed in figure 1 , allows a circuit-based or packet- based network sensor node or user terminal to interact (connect to, locate, exchange data, execute interactive applications) with its compatible surrounding . Two slightly different ISO models exist in the literature, namely the 5-layers and 7-layers models. But as illustration of a preferred embodiment, the short ISO model 10 is used in the following description. This model comprises:

- an application layer 5, mainly, holding i) sensor management protocol (SMP) which is used, for example, for implementing rules for different purposes like data aggregation and clustering, authentication, key distribution and security in data communication, and turning sensor node on and off (to conserve energy), ii) task assignment and data advertisement protocol (TADAP) which is used for interest dissemination such as a triggering event or an availability announcement, and iii) sensor query and data dissemination protocol (SQDDP) which helps user application to issue queries, respond to queries and collect replies. One can also mentions, as a non-exhaustive list of protocols running over the application layer 5, File transfer Protocol (FTP), Dynamic Host Configuration Protocol (DHCP), Simple Mail Transfer Protocol (SMTP) ;

- a transport layer 4 responsible for end-to-end data delivery between a sender and a receiver with error control and for injected traffic, into the network, regulation. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are examples of the transport layer protocols ;

- a network layer 3 for data aggregation. It permits to select the next node towards the receiver that is reachable from the sender. As an example, the network layer protocols of the GSM protocol stack are used for the radio resource management (RR), for the mobility management (MM) and for the connection management (CM). In a packet-based network, the network layer 3 holds, for examples, the Internet Protocol (IP), Advanced Peer-to-Peer Networking (APPN) and Datagram Delivery Protocol (DDP) ;

- a data link layer 2 ensuring reliable point-to-point and point-to-multipoint connections in a communication network. It is responsible for data streams multiplexing, data frame detection, medium access (MAC protocols) and error control. Link Access Protocol on Channel D (LAPD), Link Access Protocol on channel Dm (LAPDm) and Message Transfer protocol (MTP) are three examples of data link layer protocols ;

- a physical layer 1 whose main task is the transport of data over a specific physical medium (radio or wire transmission). For examples, it is responsible for frequency selection, carrier frequency generation, signal detection, channel coding , power control, interleaving, modulation and data encryption.

A user terminal, or more generally a network sensor node connected to a circuit-mode or a packet-mode network, establishes a communication, within the network to which it is attached, via an appropriate standard protocol stack according to the above described OSI model 10.

According to the present invention , the conventional horizontal composition of the protocol stack is kept, no layer being distinguished; a new horizontal repartition of the protocol stack being adopted. With reference to figure 2, a protocol entity n may be inside a conventional layer, identical to a conventional layer or spreads over more than two adjacent conventional layers, lending to a possible total number of protocol entities different from the conventional layers number. A protocol entity is an interactive unitary task including one or more protocols or even sub-protocols. As non limitative examples, one can define a protocol entity n:

- covering the conventional 3^rd and 4^th layer. For example, TCP and IP protocols may be grouped in one protocol entity n, for a single purpose which is data transfer ;

- identical to a single protocol, such as I Pv4, I PX, UDP, TCP, FTP, HHTP, SS7, MAP, MAC;

- given by a sub-layer such as mobility management (MM) or radio resources management (RR) sub-layers lying in the 3^rd layer of the GSM protocol stack.

A protocol entity n designates the protocol entity of order n, providing a set of services to the protocol entity n+1 and using the services provided by the protocol entity n-1 . A protocol entity n is a conceptual structure (object-oriented concept) provided with:

- common mechanisms and data, shared by all protocol entities ;

- specific data for its content ; and

- protocol processing for its implementation.

As it is illustrated in figure 2, at a given level of the protocol stack, one can distinguish more than one protocol entity n.

The protocol entities stack, shown in figure 2, interacts with external protocols, such as drivers or specific protocols, via adaptation layers 22. Upper and lower adaptation layers 22 are software layers allowing the access to, respectively, the upper and the lower protocol entities of the protocol stack environment. The set of protocol entities are topped and/or bottomed by adaptation layers, as it is shown in figure 2.

An adaptation layer 22 is equivalent to an object-oriented container holding mechanisms and data common to all adaptation layers 22 and being made for acquiring concrete implementation of a given adaptation. A non- limitative example of such concrete implementation is the layer permitting UNIX/Linux applications a "socket" type access, so as to send or receive some protocol data units towards upper protocol entities of level 4 provided with a TCP/IP protocol layer.

A protocol entity n interfaces with vertically adjacent protocol entities through an access channel 21 . An access channel 21 enables a unidirectional incoming access to a protocol entity n or to an adaptation layer 22, whatever a downlink or an uplink access. In other words, a channel access 21 concerns only the fact of accessing to a protocol entity n or to an adaption layer 22. On the other hand, a pointer is used in the case of an outgoing access toward the vertically adjacent protocol entity or toward the vertically adjacent adaptation layer 22 via an access channel 21.

The access channel 21 is, in someway, equivalent to a sub-Service Access Point (sub-SAP), known in the basic reference ISO model.

The access channel 21 is a conceptual location at which one protocol entity n or one adaptation layer 22 can, exclusively, receive a service request (respectively a service response) from a protocol entity n+1

(respectively from a protocol entity n-1 ) or from an upper adaptation layer (respectively from a lower adaptation layer).

Referring now to figure 3, protocol entities linking, via access channels 21 , results in a protocol connection 31 . Known that access channels enable unidirectional accesses, two types of protocol connections 31 can be distinguished:

- a protocol connection in an uplink direction from an adaptation layer or a protocol entity to its next higher protocol entity or adaptation layer;

a protocol connection in a downlink direction from an adaptation layer or a protocol entity to its next lower protocol entity or adaptation layer.

Figure 3 illustrates a complementary pair of protocol connections 31 linking two protocol entities, respectively, n+1 and n-1 and passing through the protocol entity n. Protocol connections 31 of a complementary pair (uplink and downlink protocol connections) may be created independently and involve different protocol entities, according to each protocol specification.

A protocol connection is an object-oriented container provided with structures and data common to protocol connections and being able to hold content: a concrete implementation of shared protocol connections data.

Two modes of access channel 21 can be distinguished, namely:

- a connection-oriented mode, wherein the access channel 21 is associated to the protocol connection 31. In particular, the access channel 21 lifetime is the same as that of the protocol connection 31 ;

- a connectionless-mode, wherein the access channel 21 is associated to a protocol entity n or an adaptation layer 22 and represents the default link between two vertically adjacent protocol entities or vertically adjacent protocol entity and adaptation layer. The connectionless-mode access channel 21 is created at the start of the protocol entity n. Then, it has the same lifetime as that of its correspondent protocol entity. Nevertheless, some connectionless-mode access channel 21 may be temporally created (then destroyed), according to each protocol specification.

In a connection oriented mode, a protocol connection 31 comprises as many access channels 21 as protocol entities n plus adaptation layers minus 1 , in a downlink as in an uplink case.

With reference to figure 4, protocol entity n performs protocol data unit by means of enchained micro-processing units 41 . The latters are the fragmentations of protocols processing to be carried out by a protocol entity n. These micro-processing units 41 are short code sequences, programmed with common routines (functions, methods or procedures for examples) and whose execution cannot be interrupted. A micro-processing unit 41 must be designed and coded in such a way that it may be carried out as fast as possible, without time-consuming processing or active waiting time.

Micro-processing units 41 are obtained by a unitary decomposition of a protocol processing. As examples of micro-processing units 41 , one can mention: headers coding/decoding, errors correctors, fragmentation/reassembling, acknowledgment, multiplexing/demultiplexing.

A micro-processing unit 41 is an object-oriented container provided with mechanisms and data common to all micro-processing units and being configured to hold concrete implementation of an unitary protocol.

Micro-processing units 41 are organised into oriented graphs so as to achieve a protocol processing.

Figure 5 to 8 illustrate non-limitative examples of oriented graphs of micro-processing units 41 , respectively, a linear organization 51 , an organization with separation 61 -reunification 62, an organization with loop 71 , and an organization with jump 81 .

Micro-processing units 41 are carried out within a protocol entity n for a given channel access 22, or equivalently for a given protocol connection 31.

In order to access to the right data to process, a micro-processing unit 41 has to know at least the following information:

- the protocol data unit to treat ;

- the concrete implementation of the protocol entity n wherein the micro-processing is sited ; - the concrete implementation of the access channel 21 which is associated to the oriented graph comprising the micro-processing unit 41 ;

- the concrete implementation of the protocol connection 31 , if it exists, to which belongs the above access channel 21.

Preferably, micro-processing units 41 are sharable among a protocol entity n work, insofar as they are associated to access channels having the same concrete implementation. For this purpose, an oriented graph of micro-processing units may be replaced by an oriented graph of pointers 101 , wherein each pointer points to its correspondent micro-processing unit stored in a micro-processing units database 102, as it is shown in figure 9. Figure 9 illustrates an example of three oriented graphs of microprocessing units with different priorities (PM ₁ Pr2 and Pr3) and sharing micro-processing units stored in a database 102 in an easy accessible way.

It is to be noted that an access channel 21 may manage more than one oriented graph of pointers. In fact, when a protocol processing depends on the states of its protocol entity n, protocol connection 31 or access channel 21 , a plurality of oriented graphs of pointers may be associated to only one access channel 21.

An access channel 21 comprises a FIFO (first in first out) queue, representing an asynchronous means for the reception of incoming protocol data from a vertically adjacent (lower or upper) protocol entity or adaptation layer.

Additionally, an access channel 11 serves, for its protocol entity n and its protocol connection 31 , as a shared memory space which may be needed by the micro-processing units associated to the protocol entity n to carry out the protocol data unit processing.

A micro-processing unit sequencer is in charge of pointing towards the next micro-processing unit then calling the pointed micro-processing units comprised within an oriented graph. During the progress of a protocol data unit processing by a given oriented graph, each called microprocessing unit 41 indicates to the micro-processing unit sequencer the next micro-processing unit 41 within the oriented graph. The last microprocessing unit indicates to the micro-processing unit sequencer the end of the oriented graph. Hence, before that the micro-processing unit sequencer resumes sequencing action, it is informed about the progress within the oriented graph of protocol data unit processing.

All the information describing the progress of a protocol data unit processing within a protocol entity, such as the next micro-processing unit and its oriented graph, the access channel and the protocol connection, form a set of context information. This context information comprises essential information which permits to resume a previously suspended protocol data unit processing. Context information, temporally stored into their correspondent access channel 21 , is updated at the end of each execution of a micro-processing unit 41 .

In order to achieve a prioritized protocol data unit processing, access channels 21 are described at least by a calculable priority attribute which may vary in time.

Preferably, no priorities are assigned to micro-processing units 41 , neither to protocols entities or adaptation layers. Instead, a channel scheduler evaluates the access channels priorities.

In order to assure a fluent progress of protocol data processing, it is preferably to temporally store the following information into the access channel 21 :

- the current protocol data unit ;

- the current oriented graph of micro-processing units;

- the next micro-processing unit to be called, initialized with the first micro-processing unit of the current oriented graph

Preferably, different level of context information (first, second, third, etc.) are defined for a given access channel, in order to be able to preempt more than one progress of protocol data processing and which may be further resumed.

An access channel is described by a priority level, calculated dynamically. This priority is essential in order to manage priorities per protocol data stream vertically.

The channel scheduler sorts access channels according to their priorities. Subsequently, the channel scheduler indicates to the micro- processing units sequencer the access channel having the highest priority. If the processing of the protocol data unit cited in the FIFO output of the indicated access channel was previously suspended, the micro-processing unit sequencer uses the context information to resume the protocol data unit processing at the right position. Otherwise, the micro-processing units sequencer call the first micro-processing unit of the oriented graph associated to the protocol data unit. With reference to figure 10, the micro-processing units MPU 1 , MPU2 and MPU3 are successively linked to form a micro-processing unit graph associated to an access channel "X". After the call of the micro-processing unit MPU 1 , the micro-processing unit sequencer asks the channel scheduler if the access channel "X", currently concerned, has always the highest priority. According to the example shown in figure 10, the response is "False". Then, the protocol processing of access channel "X" is preempted and the micro-processing unit sequencer acts for an access channel "Y" having the highest priority. Suppose that the access channel "Y" remains the highest priority till the execution end of its micro-processing oriented graph and just after the access channel "X" regains the highest priority. Then, micro-processing units sequencer resumes with the second microprocessing unit MPU2 of the channel access "X", as it is shown in figure 10. Within this example, at the end of the MPU2 execution, the access channel "X" remains the highest priority. Subsequently, the execution of MPU3 and accordingly the end of the micro-processing units graph associated to the access channel "X".

The channel scheduler is in charge of calculating periodically the access channels priorities then indicates to the micro-processing unit sequencer the access channel which has the highest priority.

Preferably, the calculation of access channels priorities is made only if the channel scheduler notes a modification, such as:

- a protocol data unit incoming, within the access channels ;

- the end of protocol data unit lying in the FIFO of the current access channel 21 .

If the channel scheduler selects a new access channel, different from the current one, as it is considered having the highest priority according to predetermined priority criteria, the channel scheduler:

- points towards the protocol data sited in the output of the FIFO of this access channel ;

- updates context information sited in this access channel;

- calls the micro-processing unit sequencer. The calculation of access channels priorities, made by the channel scheduler, takes into consideration the quality of service (QoS) associated to the access channel 21 as well as the size of protocol data present in its FIFO queue.

A more precise access channel sorting according to their priorities may be obtained by taking into consideration others attributes concerning each protocol data sited in the FIFO queue; such as its time of coming in the queue or its importance.

In order to keep an updated calculation of access channels priorities, the channel scheduler examines, after each micro-processing execution end, the entire access channels linked to a protocol entity n, and in particular, it continuously checks theirs FIFO queues contents. In another embodiment, the channel scheduler reviews only active access channels whose FIFOs undergone a change so as to revaluate their priorities then reinsert them in a sorted list according to the priority of active access channels. The channel scheduler is informed, by the micro-processing units sequencer, about the execution end of protocol processing of an access channel 21.

An access channel is said to be active when its FI FO contains at least a protocol data unit.

When a protocol processing has to be cancelled or to be suspended by the sequencer, it is not possible to interrupt a micro-processing unit 41 .

I nstead, the micro-processing units sequencer has to wait for the execution end of the current micro-processing unit, then request the channel scheduler for the active access channel 21 having the highest priority.

Protocol connections 31 are supervised by a connection manager. The Connection manager is configured to maintain connection characteristics which may involve a plurality of protocols entities. The tasks of the connection manager comprise:

- create a protocol connection 31 when a protocol processing detects the requirement of a protocol connection establishment; - create an access channel 21 in a connection-oriented mode for each protocol entity n to be linked to a protocol connection 31 ;

- associate a quality of service (QoS) profile to a protocol connection 31 when its establishment is achieved ;

- destroy a protocol connection 31 as its access channels 21 in the case of a connection establishment failure/refuse or after a connection end/breakdown ;

- retrieve QoS parameters and protocol connections traffic counters (for maintenance, debugging and traceability reasons);

- initiate the traffic counter of a protocol connection 31 .

The software framework includes further a protocol stack manager able to manage more than one standard protocol stack. The tasks of the protocol stack manager comprise:

- create adaptation layers 22, protocols entities n and their access channels 21 (in connectionless-mode) ;

- associate a quality of service (QoS) profile to created access channel 21 (in connectionless-mode) ;

- link protocol entities n between them and with adaptation layers 22 by access channels 21 ;

- verify the compatibilities of linked components ;

- initialize/reinitialize adaptation layers 22, protocols entities n and access channels 21 ;

- configure adaptation layers 22, protocols entities n and access channels 21 ;

- Start/Stop the multistandard protocol stack ; adaptation layers 21 , protocols entities n and access channels 21 , - Verify the compatibility of a new adaptation layer 22 or of a new protocol entity n with other adaptation layers 22 and/or protocol entities n to which it may be connected;

- Add/replace an adaptation layer 22 or a protocol entity n;

- Identify the parameters, the connection counters and the traffic counters of adaptation layers 22 and protocols entities n (for debugging, traceability or maintenance reasons);

retrieve QoS parameters and traffic counters of access channels 21 (in connectionless-mode);

- reinitialize the traffic counters and/or the connection counters of adaptation layers 22 and protocols entities n ;

reinitialize the traffic counters of access channels 21 (in connectionless-mode)

The Qos profile, hereinbefore cited, comprises several QoS parameters, specifying protocol connections 31 and access channels 21 in connectionless-mode. These parameters comprise:

- the importance of a protocol connections 31 or an access channel 21 in the case of a signal degradation detected by lower layers;

- maximum time delay to pass through a protocol connection 31 or an access channel 21 ;

- data flow rate (constant, variable, non-constrained);

- statistical properties of data flow rate (e.g. maximum, minimum, mean, deviation) ;

- relative priority ; - action to be taken when a flow rate threshold is violated, such as close the access channel/protocol connection, generate/get rid of missing/surplus protocol data, or no action.

QoS parameters compete to facilitate the evaluation of access channels priorities so as to expedite the scheduler decision making (such as suspend the execution of micro-processing units of a given access channel 21 and serve another one). All the components hereinbefore cited are aligned with a time manager which is in charge of managing finely and efficiently delayed triggering alarms. For this reason, time manager is based on an internal structure comprising a timers Ring and hash Table.

Tasks of the time manager comprise:

- initiate the hash Table and timers Ring;

- activate a timer ;

- modify the period of an active timer ;

- deactivate an active timer ; - trigger an expired timer to the user.

Timers may be used by concrete implementations of protocol connections 31 , adaptation layers 21 and protocol entities n. In order to receive the timer expiration, these concrete implementations must indicate theirs origins, particularly their current access channel 21 .

Advantageously, the ring structure permits the time manager to manage efficiently a huge number of timers triggered by a unique cyclic event: a unitary tic (of fix period which constitutes the minimal period and the timer precision). The hash Table assists the timers Ring when a desired emplacement in the ring is already busy.

The presented software framework promotes a high extendibility, reusability, maintainability and interoperability that are current requirement on architecture design for telecommunications sensor nodes.

It must be noted that the software framework comprising the herein cited components is supported by a monothread execution code. In another embodiment, a multithread execution code may be also adopted by designing, for example, an additional thread per protocol connection.

The term "software framework", used herein, is intended to mean the organizational structure of components, their interrelationships, and principles and guidelines governing their design and evolution over time. Component is a generic term referring , here, to any computer program or library code intended to support execution of a task or service. Preferably, a protocol entities database, assembling a plurality of entities specified by different attributes (such as an identifier, a version, protocol stack managers with which is compatible, source code), may be developed. Equally, a database of micro-processing units, gathering micro- processing units specified, for example, by an identifier, a version, compatible sequencers, micro-processing unit types (coding, decoding, fragmentation, etc.) and the source code, may be developed.

Preferably, a database of adaptation layers 22 may be developed.

Each adaptation layer of the database may have the following characteristic: an adaptation layer identity, a version, versions of protocol stack managers with which the adaptation layer is compatible, the source code of the adaptation layer.

It is must also be noted that, preferably, a database of QoS profiles is developed. Each profile of this database is specified, for example, by: an identifier, a version, version and sub-version of channel schedulers with which the profile is compatible, characteristic of the profile.

The database approach for all the framework components facilitates ^' the reusability, the update, the test, or more generally the manipulation of these components.

The above generic software framework is based on unitary components (protocol entities n) that could be used by a plurality of tasks, thus reusable. Moreover, the framework uses a set of components within a same structure, thus maintenance and extension are easy, and interoperability is maximal.

It is to be noted that the term "object-oriented container" or

"container", as used herein in connection with the framework components or the like, is intended to mean a class of objects. Container classes are most often defined as parametrizable classes, with some parameter designating the class of the contained objects.

In order to reach a real-time operating system based on the present software framework, a particular attention must be accorded to the design of micro-processing unit graph and to the implementation of channel access, specifically, in regard to time-consuming processes and waiting time.

A micro-processing unit graph as well as the implementation of its correspondent access channel must take into account waiting times (caused by an acknowledgment requirement for example), in the following way:

- adding a state or a sub-state (waiting an acknowledgment for example) within the appropriate access channel or protocol entity;

- modifying the state or sub-state value from a micro-processing unit to activate the waiting time and end the protocol processing ; - adding or modifying a micro-processing unit graph which depends on the value of this state or sub-state in order to process the work and deactivate the waiting time by modifying the value of this state or sub-state.

When the protocol processing requires a time-consuming processing, it may be conceived a fragmentation step within the processing graph as well as within the access channel implementation in the following way:

- adding a state or a sub-state (data fragmentation for example) within the access channel or the protocol entity;

- providing the access channel or the protocol entity with the required • data for a time-consuming (current fragment number for example) ;

- modifying the state or sub-state value and initializing, from a microprocessing unit, the required data for a time-consuming processing ;

- adding or modifying the processing graph which depends on the value of the state or sub-state to execute a time-consuming processing then update the required data for a time-consuming processing .

With reference to figure 1 1 , a non-limitative multistandard protocol stack embodiment is given according to the present invention. This example comprises three standards; GSM, GPRS and TCP-UDP/IP standards.

Referring to the left hand side of figure 1 1 , the GSM-GPRS signaling protocols are implemented fn the protocol entities: Link Access Protocol on channel Dm (LAPDm), Radio Link Protocol (RLP), Radio Resource management for both GSM and GPRS (RR-GRR), Mobility Management for both GSM and GPRS (MM-GMM), Call Control (CC), Supplementary Service (SS) and Short Service Message (SMS).

The right hand side of figure 1 1 shows the TCP-UDP/IP/PPP protocols suite (IP/PPP, UDP and TCP protocol entity implementations).

The multistandard protocol stack shown in figure 1 1 comprises further the GPRS standard. The GPRS is implemented in protocols entities comprised within the second and third level among the five vertically disposed levels: Radio Link Control (RLC)/medium access (MAC) and Sub Network Dependent Convergence Protocol (SNDCP) protocol entity implementations. SNDCP protocol entity implementation may be also used within another standard (X.25 and IP for example).

The TCP-UDP/IP/PPP protocols suite permits to transmit data:

- in a circuit mode communication such as with the GSM standard via the RLP₁ IP/PPP and UDP protocol entity implementations; and - in a packet mode communication such as with the GPRS standard via

RLC/MAC, Logical Link Control (LLC), SNDCP, IP/PPP and TCP protocol entity implementations.

The shown multistandard protocol stack, cited as an example, mainly uses access channels in a connectionless-mode:

- access channel in the ascending direction: one access channel per transmitter which permits the protocol entity or the adaptation layer to distinguish the required processing ;

- access channels in the descending direction : only one access channel per protocol entity.

Protocol connections are used above the TCP protocol entity, as it is shown in figure 1 1 , establishing two bidirectional TCP connections.

As an example of protocols entities interactions, the RR-GRR protocol entity implementation exchange data with the LAPDm protocol entity implementation (GSM circuit-mode signaling) and with the RLC/MAC protocol entity implementation ( GPRS packet-mode signaling). As these exchanged data are of different format and for different purpose, the RR- GRR protocol entity implementation receives these data with different access channel, as it is shown in figure 11 , in order to be carried out by different micro-processing unit. In addition, the RR-GRR protocol entity implementation communicates data to the MM-GMM protocol entity implementation.

It is to be reminded that the embodiment given in the figure 11 is for the purposes of example only. The present invention permits the implementation of a plurality of standards in a more optimized manner.

It is to be noted that the real-time characteristic, used herein in connection with an operating system build according to the hereinbefore described framework is intended to mean a system in which the respect of its temporal constraints to execute an operation is also important as the result.

In connection with the standard OSI model, one can mention that the use of protocol entities, instead of layers, permits to exploit the communality between protocols, especially those share common practices or take in a certain purpose achievement.

At this time, it is noteworthy to mention that such software framework is independent of any implementation technique and language. In addition, it concerns packet-based, circuit-based, as well as duplex networks.

Claims

1 . A method for centralizing communications standards in a generalist and flexible framework, comprising:

- at least a protocol entity (n-1 , n,n+1 ) topped and/or bottomed by an adaptation layer (22);

- at least an access channels (21 ) enabling a unidirectional incoming access to a protocol entity (n) or to an adaptation layer (22) ;

- at least a micro-processing unit (41 ) per protocol entity and associated thereto; - a channel scheduler ;

- a time manager ;

- a protocol stack manager.

2. The method of claim 1 , wherein micro-processing units are organized in oriented graphs.

3. The method of any one of claims 1 to 2, wherein a micro-processing unit sequencer permits to:

- point towards the next micro-processing unit within an oriented graph of micro-processing units ;

- call the pointed micro-processing unit ; - request, from the channel scheduler, the access channel having the highest priority.

4. The method of claim 1 , wherein an access channel, associated to a protocol entity or to an adaptation layer, comprises:

- a FIFO queue receiving protocol data unit ; - a shared memory to the protocol entity ;

5. The method of any one of claims 1 to 4, wherein protocol entities connection via access channels forms a protocol connection (31 ).

6. The method of any one of claims 1 to 5, wherein a channel scheduler schedules the access channel, or equivalently the protocol connection, according to their priority.

7. The method of any one of claims 1 to 6, wherein the channel scheduler evaluates the priorities of access channels.

8. The method of any one of claims 1 to 7, wherein no priority is affected to protocol processing unit.

9. The method of any one of claims 1 to 7, wherein no priority is affected to protocol entities or to adaptation layers.

10. The method of any one of claims 1 and 7, wherein priority criteria of access channels comprise the quality of service.

1 1 . The method of any one of claims 1 to 10, wherein context information, stored in the access channel, is updated after each execution end of a micro-processing unit (41 ), belonging to a micro-processing graph which is associated to an access channel (21 ).

12. The method of claim 1 , wherein service request and service response are vertically trafficked throughout the framework.

13. The method of any one of claim 1 to 12, wherein protocol connections (31 ) are supervised by a connection manager configured to maintain connection characteristics.

14. The method of claim 1 , wherein the time manager comprises a timer Ring and hash Table.

15. The method of claim 1 , wherein the protocol stack manager tasks comprise:

- configure adaptation layers (22), protocol entities (n-1 ,n,n+1 ) and access channels (21 ) ; - link protocol entities between them and with adaptation layers by access channels ;

- verify the compatibilities of linked components ;

- create adaptation layers (22), protocols entities and their access channels (21 ) ; - start/stop a protocol stack.

16. An apparatus enabling communication systems interconnection, comprising:

- at least a protocol entity (n-1 ,n, n + 1 ) topped and/or bottomed by a an adaptation layer (22); - at least an access channel (21 ) enabling a unidirectional incoming access to a protocol entity (n) or to an adaptation layer (22) ;

- at least a micro-processing unit (41 ) per protocol entity and associated thereto;

- a channel scheduler ; - a time manager ;

- a protocol stack manager.

17. The apparatus of claim 16, wherein protocol entities connection via access channels forms a protocol connection (31 ).

18. A computer program product implemented in a communication device enabling communication systems interconnection, comprising:

- the implementation of at least a protocol entity ;

- the implementation of at least an adaptation layer ;

- the implementation of at least a micro-processing unit per protocol entity and associated thereto;

- the implementation of at least an access channel per protocol entity and associated thereto;

- the implementation of at least an access channel per adaptation layer and associated thereto.

19. The computer program product of claim 18, wherein protocol entities connection via access channels forms a protocol connection.