TRAFFIC DEPENDENT DATA COMPRESSION CONTROL
The present invention relates to control of data compression. Particularly, the present invention relates to using N.42bis compression in the SGSΝ node of a GPRS only when it provides a desired effect.
TECHNICAL FIELD
Improvement in SGSN for the SNDCP protocol layer, i.e., the GPRS Gb interface between MS and SGSN.
THE PROBLEM AREA
SGSN serves many Mobile Stations, MS (subscribers) at the same time. Each MS can have none or several pdp-contexts activated. Each pdp-context might have enabled the data compression algorithm V.42bis. N.42bis is a very demanding function CPU wise. In GPRS the N42bis is placed within SΝDCP layer in the SGSΝ and MS. The SGSΝ processor capacity within SΝDCP layer might be the bottleneck in the transmission plane, ref. Figure 1.
N42bis consumes processor capacity even if compression efficiency is low. In order to avoid waste of SGSΝ CPU power, it is important to deactivate N42bis when the effect is low. Figure 1 shows the SΝDCP protocol in its correct environment within the GPRS and shows the protocol stack used for payload (e.g., IP-packets).
As an example, the compression efficiency is low for pre-compressed traffic such as images (e.g., the "jpeg" and "GIF" picture formats) or compressed files (e.g., "zip" file- format). Note that compression of already compressed data will produce larger output than input.
In a GPRS communication system, a PDP-context typically can operate in two modes; unacknowledged or acknowledged. These two modes affect how the data compression algorithm N.42bis operates. In acknowledged mode, N.42bis operates as intended when the N42.bis standard was settled, i.e., a compression tree is trained to do better and better compression for each processed Ν-PDU (typically IP-packets). In unacknowledged mode, the compression tree is reset after each Ν-PDU. Therefore, the
N42bis efficiency in unacknowledged mode is dependent of both PDU length and the nature ofthe data within the Ν-PDU.
KNOWN SOLUTIONS
Generally, in an existing exemplary GPRS system, after activation of data compression N.42bis, traffic is always sent to the N.42bis function in SGSΝ, also when compression has no significant data reduction effect. This is according to the standardised N.42bis handling in accordance with the standard GSM 04.65, "Subnet Dependent Convergence Protocol (SΝDCP)", version 6.7.0 Release 1997, Feb 2000. To identify the location of a N.42bis function or means carrying out data compression in a known exemplary GPRS system, reference is made to the accompanying figure 2.
US 5.550.881 describes a solution allowing end-users (typically mobile phones, laptops etc.) to call a modem-pool (i.e., line-switched data communication). Transmission-time is reduced in order to occupy the remote modem as short as possible, giving the customer the opportunity to save money, and giving the internet service provider, who is owner ofthe modem pool, the opportunity to provide service to more customers per installed and available modem. The solution according to US 5.550.881 considers a complete data-file as an object that shall be transmitted. Accordingly, a prerequisite for the solution according to US5.550.881 is that the file system of data to be transported is available to the compression control means, or to the means controlling the choice of modulation on the transmission medium, which may be feasible in a solution extending to the end-user system, such as for example a end-user computer holding the data to be transferred.
However, the file system ofthe end-user typically is not available to a modem pool providing data compression.
GPRS is a packet-switched system where it is desirable to reduce data unit compression resource usage in a node, such as for example the CPU-load in SGSΝ or in a mobile station. Transmission time may however remain unchanged.
In a GPRS system, an SGSΝ can in certain respects be considered to be like an modem- pool, but access to the original filename, the file type and the file size is not available.
Instead, the data transported is seen as a stream of data bytes contained in packet data units.
PROBLEMS WITH KNOWN SOLUTIONS
In existing solutions compression / decompression operates regardless of compression / decompression efficiency, and uses system resources, such as for example processor capacity, which could be freed for other purposes if the resource usage effects of inefficient compression are mitigated.
OBJECTS OF THE INVENTION
It is an object ofthe invention to provide a solution in a telecommunication system to improve data compression resource usage efficiency.
It is a further object ofthe invention to provide a solution in a telecommunication system to improve data compression resource usage efficiency independent of a file system holding data to be communicated.
BRIEF DISCLOSURE OF THE INVENTION
The present invention provides method and arrangement for evaluating packet data unit size, compression effect and time between handling long packet data units for a specific packet data unit connection, and, depending on the evaluation result, provides routing of packet data units to pass or bypass a data compressor/decompressor while ordering a compression negotiator to negotiate compression activation or deactivation.
Features ofthe invention are recited in the accompanying independent patent claims 1 - 4, 8 - 11 and 15 - 22.
Other advantageous features ofthe invention are recited in the accompanying dependent patent claims 5 - 7, 12 - 14 and 23 - 25.
Other features ofthe invention will become apparent from the present disclosure.
The invention particularly realtes to, and is located in, the "SNDCP entity" according to its definition in the SNDCP 3 GPP standard. In this respect, it should be noted that one SNDCP entity exist for each PDP-context, identified with NS API number. Accordingly, one mobile station/subcriber can have up to eleven SNDCP entities. There is an one to one relationship between SNDCP-enitity and PDP-context.
In fig. 4, page 19 of ETSI TS 101 297 V8.0.0 (2000-02) the various "internal layers", or "sub-layers" ofthe SNDCP layer are identifiable. In the aforementioned figure 4, a "sub-layer" comprising the "data compressor" is consistent with the "Data compression sublayer" ofthe accompanying fig. 4 ofthe present disclosure, while "segmentation" and other provisions are to be found in the "lower sub-layer within SNDCP", and "Control compressor" entities are to be found in "Upper sub-layer within SNDCP". In other words, the three sub-layers thereby defined together make up an SNDCP-entity. Accordingly, the present invention relates to the "Data compression sub-layer" as defined herein.
Another term introduced here to more clearly explain the present invention is the term "XID negotiator". This term is, however, nothing more than new term assigned to the same functionality already described in the SNDCP standard, although it is not very well explained there. Section 5.2, "Service", of ETSI TS 101 297 V8.0.0 (2000-02) (SNDCP standard) gives a simple description of XID negotiator which briefly may be referred by "Negotiation ofthe XID parameters between peer SNDCP entities using XID exchange". XID-negotiator provides the SN-XID service primitives to the SNDCP users (see Table 1 "SNDCP layer service primitives" in SNDCP standars). According to this standard, it is the SNDCP user who decides to start an XID-negotiation in order to turn on (or off) header or data compression. Negotiation ofthe XID parameters between peer SNDCP entities use XID exchange.
In a solution according to the invention, the Rx/Tx Monitor is capable of deciding (and can be allowed to decide) when to start XID negotation, without there being a need for interaction with its related SNDCP user. In other words, an SNDCP user might belive that data compression is activated (with use of XID), although it actually may have been turned off temporarly by the Rx/Tx Monitor, e.g. because the data compression did not give the desired effect in the view ofthe Rx/Tx monitor ofthe invention.
In the following description ofthe invention the terms "compression on signal" and "compression off signal" are useseful in explanation ofthe invention. These signals, as employed by in the invention, are related to compression negotiation by: i. Tx (or Rx) Monitor sends to XID negotiator the signal "compression on". This is the same as service primitive SN-XID.Request (requested SNDCP XID parameters to enable data comp.) ii. Tx (or Rx) Monitor receives from XID negotiator the signal "compression on". This is the same as service primitive SN-XID.Confirm (negotiated SNDCP parameters to enable data comp.) iii. Tx (or Rx) Monitor sends to XID negotiator the signal "compression off. This is the same as service primitive SN-XID.Request (requested SNDCP XID parameters to disable data comp.) iv. Tx (or Rx) Monitor receives from XID negotiator the signal "compression off. This is the same as service primitive SN-XID.Confirm (negotiated SNDCP parameters to disable data comp.)
Furthermore, in the explanation ofthe invention, the term "Header Compression" is useful, altough the above-referenced standard uses the term "Control Compressor", which in fact are similar functions.
BRIEF DESCRIPTION OF THE DRAWINGS.
Figure 1 is a schematic transmission plane illustration of a protocol stack arrangement in a digital GPRS communication arrangement; Figure 2 is a schematic illustration indicating the location of data compression entities in a SNDCP layer of an exemplary GPRS system;
Figure 3 is a state diagram illustrating the operational states and associated state transitions of a solution according to the invention;
Figure 4 is a schematic illustration of a compression providing SNDCP layer of an exemplary GPRS system including the invention;
Figure 5 is a flow chart illustrating the operation ofthe invention operating with transmit data in a compression mode state;
Figure 6 is a flow chart illustrating the operation ofthe invention operating with transmit data in a non-compression mode state; Figure 7 is a flow chart illustrating the operation ofthe invention operating with transmit data in a compression bypass mode state;
Figure 8 is a flow chart illustrating the operation ofthe invention operating with transmit data in a non-compression bypass mode state;
Figure 9 is a flow chart illustrating the operation ofthe invention operating with receive data in a compression mode state; Figure 10 is a flow chart illustrating the operation ofthe invention operating with receive data in a non-compression mode state;
Figure 11 is a flow chart illustrating the operation ofthe invention operating with receive data in a non-compression bypass mode state;
Figure 12 is a flow chart illustrating the operation ofthe invention operating with receive data in a compression bypass mode state;
Figure 13 is a block schematic drawing depicting an embodiment of an TX monitor part according to the invention;
Figure 14 is a block schematic drawing depicting an embodiment of an RX monitor part according to the invention, and Figure 15 is a schematic drawing illustrating the concept of "sub layers" on basis of fig.
4 ofthe SNDCP standard.
DETAILED DESCRIPTION OF EMBODIMENTS.
In the following, the invention will be explained with reference to the accompanying drawings, and in part by way of example, referring to a typical GPRS telecommunication system.
Firstly, referring to figure 4 depicting a data compression sub-layer within a SNDCP layer of a node, a Tx Compression Monitor, as well as a Rx Compression Monitor, according to the invention is shown. The term Monitor as used herein refers to the invention, serving to monitor compression effect, to effect data unit routing through the SNDCP layer when appropriate, and to control compression operation. In the example of figure 4, illustrating an arrangement according to the invention operating in a serving network node, such as for example a SGSN node of a GPRS system, the Tx
Compression Monitor is shown to handle compression control in the transmit (Tx) direction. Similarly, the Rx Compression Monitor handles compression control in the receive direction with respect to a packet data unit (PDU) received from peer entity.
Referring to figure 3, a compression monitor according to the invention generally may operate in one of four different modes - (1) Non-compression bypass mode;
- (2) Compression mode;
(3) Compression bypass mode; or
(4) Non-compression mode.
Generally, in the bypass modes (1) and (3), compression effect or other relationship between a data unit input and output is not considered. Generally, in the remaining modes (2) and (4) compression effect or other relationship between a data unit input and output is considered for compression control. Depending on implementation, the monitor ofthe invention may include further operational modes.
In the following, and with reference to the accompanying figures 3 and 4, the operating modes ofthe invention will be explained in general terms.
In the non-compression bypass mode (1), the monitor facilitates forwarding of payload data packets at its input (10,15) through its associated layer to the output (11,14) without compression effect. The non-compression bypass mode (1) is entered when no compression has been negotiated and the time between long data units has exceeded a predefined threshold. The monitor will remain operating in non-compression bypass mode (1) until data compression is negotiated by a compression negotiator, such as for example a XID-negotiator in a GPRS implementation using V.42bis, possibly for a specific PDP-context & direction. The non-compression bypass mode can be considered to be a waiting state while the compression arrangements settles.
In the compression mode (2), the monitor the monitor facilitates forwarding of payload data packets at its input (10,15) to a compressor (or decompressor) input (17,20), and forwarding of compressed (or decompressed) payload data packets at the compressor (decompressor) output (18,19) to an output (11,14). Also, the monitor evaluates the number of a payload data packet with apparently no compression effect, for example by comparing an N-PDU, before and after data compression, and counting the number of consecutive such data packets If many consecutive payload packets, e.g. N-PDUs, for one and the same PDP-context do not generate smaller compressed packets through compression, then a negotiation is initiated aimed at negotiating away compression. The Compression Mode (2) ofthe monitor is entered when the data compression has been agreed by communicating nodes. As an example, the Monitor enters this mode after a XID negotiation of data compression has been completed, which is indicated by a signal (21 ,22) on the connection to the XID-negotiator
In the compression bypass mode (3), the monitor facilitates forwarding of payload data packets at its input (10, 15) to the compressor (or decompressor) input (17, 20) and forwarding of compressed (or decompressed) payload data packets to its output (11, 14). The compression bypass mode is entered when the monitor in a previous compression mode has determined that compression does not provide the desired effect. The monitor will remain operating in compression bypass mode until data compression is negotiated away by a compression negotiator, such as for example a XID-negotiator in a GPRS implementation using V.42bis, possibly for a specific PDP-context & direction. The compression bypass mode can be considered to be a waiting state while the compression arrangements settles.
In the non-compression mode (4), the monitor facilitates forwarding of payload data packets at its input (10, 15) through its associated layer to its output (11, 14), without compression effect. Also, the monitor determines the length of a payload packet and records the time of receiving payload data having a length reaching a threshold. When the interval between consecutive long payload data packets reaches a threshold, the monitor initiates a data compression negotiation.
As can be seen from figure 4, in a system providing bidirectional compression, two monitors (12, 13) according to the invention being arranged in a SNDCP layer to handle receive and transmit data units, respectively, can operate independently of each other. For example, one monitor can be in a compression mode while the other may be, for example, in a non-compression mode.
Acknowledged and unacknowledged mode PDP contexts are both in the same way.
Referring to figure 1, in an exemplary GPRS system, the XID negotiator negotiating compression associated with a SNDCP entity communicates with a peer SNDCP entity at the other side ofthe Gb-interface.
In the following, and with reference to the accompanying drawings of figures 5 - 12, the operating modes ofthe invention will be explained in more detail, also considering the invention adapted to and operating with handling of data units being transmitted from a peer node as well as data units being received from a peer node.
Referring to figure 5 using GPRS terminology, in the following a monitor according to the invention operating in a compression mode in an exemplary GPRS system, and handling data units being transmitted, is explained next.
Al : When the XID-negotiator has agreed upon start of data compression for this direction, the XID negotiator orders the Tx Monitor to enter Compression Mode.
Entering compression mode is also by transition decision in a previous mode.
A2: Waiting for, and receiving a data unit (N-PDU) on the input.
A3: After receiving the N-PDU, the length ofthe N-PDU is determined and stored in a variable "Length-In"; Sending the N-PDU is sent to the data-compressor.
A4: Waiting for and receiving the (compressed) data unit (N-PDU') from the data compressor. The length of N-PDU' is determined and stored in the variable "Length- out".
A5: Determining compression effect by determining if Length-Out is smaller than Length-In.
A6: If not smaller, then a "Consecutive Counter" is stepped up by one.
A7: Determining if the Consecutive Counter has reached a threshold. (The setting of this threshold must be configurable, a typical preferred value may be 10, i.e., 10 consecutive N-PDUs that produced no compression.) A8: Resetting the Consecutive Counter (to zero)
A9: Forwarding the N-PDU' to the output, and looping to A2.
A10 : Forwarding the N-PDU' to the output.
Al 1 : Ordering the XID-negotiator to disable the data compression, and monitor transit to compression bypass mode.
Referring to figure 6 using GPRS terminology, in the following a monitor according to the invention operating in a non-compression mode in an exemplary GPRS system and handling data units being transmitted is explained next.
B 1 : When the XID-negotiation has agreed upon termination of data compression for this direction, the XID negotiator orders the Tx Monitor to enter non-compression Mode. Entering non-compression mode is also achieved by a transition decision in a previous mode. B2: Storing the current time as time of receiving a previous data unit (N-PDU) having a length reaching a predefined length threshold.
B3: Waiting for, and receiving an N-PDU on the input.
B4: Determining if the length ofthe received N-PDU and finding if the length is larger than (i.e. reaches) a predefined length threshold.
B5: If larger, determining if the period between the time of receiving current N-PDU and the time of receiving previous N-PDU having a length larger than (i.e. reaching) the predefined length threshold reaches a predefined period threshold. (As an example, if a long N-PDU shall be sent and the period (e.g. "y" minutes) since last long N-PDU was handled is large enough to reach or exceed a predefined period limit, a new attempt to do compression is initiated. (This logic has been selected such that new type of traffic may have started to flow (e.g. another TCP-session), which is not already compressed by the end-application. The limit value for the variable "y" can typically be set to 3 minutes, which will in worst case cause an activation deactivation of data compression 20 times per hour per pdp-context & direction.)
B6: If period not reaches threshold, store time of receiving current N-PDU time as time of receiving a previous N-PDU having a length reaching a predefined length threshold. B7: If period reaches threshold, forwarding the received N-PDU to the output. B8: Forwarding the received N-PDU to the output, and looping back to B3. B9: Ordering the XID-negotiator to enable data compression, and monitor transit to non-compression bypass mode.
Referring to figure 7 using GPRS terminology, in the following a monitor according to the invention operating in a compression bypass mode in an exemplary GPRS system, and handling data units being transmitted, is explained next.
A12: The monitor to enter compression bypass mode upon a transition to this mode initiated by a previous mode.
A13 : Waiting for, and receiving an input as a data unit (N-PDU) on the data unit input or a compression-off signal from the XID-negotiator.
A 14: Determining if the input is a compression-off signal.
A15: Forwarding a received N-PDU to the compressor. A16: Waiting for, and receiving the (compressed) data unit (N-PDU') from the data compressor.
A9: Forwarding the N-PDU' to the output, and looping back to A13.
A 17: Ordering monitor transition to non-compression mode.
Referring to figure 8 using GPRS terminology, in the following a monitor according to the invention operating in a non-compression bypass mode in an exemplary GPRS system, and handling data units being transmitted, is explained next.
BIO: The monitor enters non-compression bypass mode upon a transition to this mode initiated by a previous mode.
B 11 : Waiting for, and receiving an input as a data unit (N-PDU) on the data unit input or a compression-on signal from the XID-negotiator. B12: Determining if the input is a compression-on signal. B8: Forwarding a received N-PDU to the output, and looping back to Bl 1. B 13 : Ordering monitor transition to compression mode.
Referring to figure 9 using GPRS terminology, in the following a monitor according to the invention operating in a compression mode in an exemplary GPRS system, and handling data units being received, is explained next.
Cl : When the XID-negotiator has agreed upon start of data compression for this direction, the XID negotiator orders the Tx Monitor to enter Compression Mode.
Entering compression mode is also by transition decision in a previous mode.
C2: Waiting for, and receiving a data unit (N-PDU') on the input.
C3: After receiving the N-PDU', the length ofthe N-PDU' is determined and stored in a variable "Length-In"; the N-PDU' is sent to the data compressor. C4: Waiting for and receiving the (decompressed) data unit (N-PDU) from the data compressor; The length of N-PDU is determined and stored in the variable "Length- out".
C5: Determining compression effect by determining if Length-Out is larger than
Length-In. C6: If not larger, then a "Consecutive Counter" is stepped up by one.
C7: Determining if the Consecutive Counter has reached a threshold. (The setting of this threshold must be configurable, a typical preferred value may be 10, i.e., 10 consecutive N-PDUs that produced no compression.)
C8: Resetting the Consecutive Counter (to zero) C9: Forwarding the N-PDU to the output, and looping back to C2.
CIO : Forwarding the N-PDU' to the output.
Cl 1 : Ordering the XID-negotiator to disable the data compression, and monitor transit to compression bypass mode.
Referring to figure 10 using GPRS terminology, in the following a monitor according to the invention operating in a non-compression mode in an exemplary GPRS system, and handling data units being received, is explained next.
Dl : When the XID-negotiation has agreed upon termination of data compression for this direction, the XID negotiator orders the monitor to enter non-compression Mode.
D2: Storing the current time as time of receiving a previous data unit (N-PDU) having a length reaching a predefined length threshold.
D3 : Waiting for, and receiving an N-PDU on the input.
D4: Determining if the length ofthe received N-PDU and finding if the length is larger than (i.e. reaches) a predefined length threshold.
D5: If larger, determining if the period between the time of receiving current N-PDU and the time of receiving previous N-PDU having a length larger than (i.e. reaching) the predefined length threshold reaches a predefined period threshold. (As an example, if a long N-PDU shall be sent and the period (e.g. "y" minutes) since last long N-PDU was handled is large enough to reach or exceed a predefined period limit, a new attempt to do compression is initiated. (This logic has been selected such that new type of traffic may have started to flow (e.g. another TCP-session), which is not already compressed by the end-application. The limit value for the variable "y" can typically be set to 3 minutes, which will in worst case cause an activation/deactivation of data compression
20 times per hour per pdp-context & direction.)
D6: If period not reaches threshold, store time of receiving current N-PDU time as time of receiving a previous N-PDU having a length reaching the predefined length threshold.
D7: If period reaches threshold, forwarding the received N-PDU to the output.
D8: Forwarding the received N-PDU to the output, and looping back to D3.
D9: Ordering the XID-negotiator to enable data compression, and monitor transit to non-compression bypass mode.
Referring to figure 11 using GPRS terminology, in the following a monitor according to the invention operating in a non-compression bypass mode in an exemplary GPRS system, and handling data units being received, is explained next.
C12: The monitor enters non-compression bypass mode upon a transition to this mode initiated by a previous mode.
C13: Waiting for, and receiving an input as a data unit (N-PDU) on the data unit input or a compression-on signal from the XID-negotiator. C 14 : Determining if the input is a compression-on signal .
C9: Forwarding a received N-PDU to the output, and looping back to C13. C15: Ordering monitor transition to compression mode.
Referring to figure 12 using GPRS terminology, in the following a monitor according to the invention operating in a compression bypass mode in an exemplary GPRS system, and handling data units being received, is explained next.
D10: The monitor enters compression bypass mode upon a transition to this mode initiated by a previous mode.
Dl 1 : Waiting for, and receiving an input as a data unit (N-PDU') on the data unit input or a compression-off signal from the XID-negotiator. D 12 : Determining if the input is a compression-off signal.
D13: Forwarding a received N-PDU' to the compressor.
D14: Waiting for, and receiving the (decompressed) data unit (N-PDU) from the data compressor.
D8: Forwarding the N-PDU to the output, and looping back to Dl 1. D 15 : Ordering monitor transition to non-compression mode.
In the above examples used herein to explain the invention, operation ofthe Rx (receive) and Tx (transmit) compression monitors ofthe invention have been explained including operational control aspects of payload data packet flow through a sub-layer of an exemplary SNDCP layer. Packet flow control may, however, be accomplished by other mechanisms external and as a complement to the compression monitor ofthe invention. Accordingly, possibly also depending on the compression scheme employed, a basic compression monitor ofthe invention may comprise those parts ofthe particular compression monitor relating to monitoring compression efficiency and controlling monitor operational mode as well as any means or methods required to communicate status and/or commands with respect to a compression negotiator in respect of a mode change.
ADVANTAGES
This method will deactivate data compression when it gives no effect. Also a method to turn on again the data compression is specified.
In a GPRS system, a method or an arrangement implementing the invention will avoid toggling on/off of the data compression at a high rate for a specific pdp-context, thus avoiding excessive XID-signalling.
Furthermore, the same method can be employed for a PDP-context in unacknowledged mode as well as acknowledged mode.
According to yet a further aspect ofthe invention, no standardisation is required in order to implement the invention.
BROADENING
The present invention is not exclusively tied to a specific ETSI release ofthe standards. Reference has been made to Release 97 ofthe GPRS standard, but the invention is also applicable to later releases where data compression is standardised.
The method is also applicable. for the MS, not only for SGSN or similar network nodes.
The invention is also applicable to other technologies where the compression entity does not know the type of data being transported. Typically examples of such technologies are modem-pools and routers.
IMPLEMENTATION EXAMPLES.
In accordance with the detailed description above ofthe present invention, an embodiment ofthe invention may comprise an TX Monitor per SNDCP entity constituted by the following components as illustrated by the accompanying figure 13: • A control program (100) which implements the logic stated in fig. 5, 6, 7 and 8 in the Invention
• A data register (101) holding the current state, i.e., shall the control program going to execute figure 5, 6, 7 or 8 when next input arrives?
• A "Consecutive Counter" (102) data register • A "Threshold data" register (103), holding an constant
• A buffer register (104), holding N-PDU
• A "Length-In" (105) data register
• A buffer register (106), holding N-PDU'
• A "Length-Out" (107) data register • A "receive-time-long-N-PDU" (108) data register
• A "larger than x-bytes" (109) register, holding a constant
• A "longer than y minutes since last long N-PDU received" (110) register, holding a constant
• Access to system clock (111) which gives current time.
• A Switch (112) which sends N-PDU to the Data Compressor or to (113)
• A Concentrator (113), which feeds output from (112) and (106) into one output to a lower sub-layer.
Other embodiments ofthe TX monitor could be assembled based on the explanation of the invention provided herein. The functioning ofthe TX monitor embodiment of figure
13 is as explained earlier.
In accordance with the detailed description above ofthe present invention, an embodiment ofthe invention may comprise an RX Monitor per SNDCP entity, constituted by the following components as illustrated by the accompanying figure 14:
A control program (200) which implements the logic stated in fig. 9, 10, 11 and
12 in the Invention
A data register (201) holding the current state, i.e., shall the control program going to execute figure 9, 10, 11 or 12 when next input arrives?
A "Consecutive Counter" (202) data register
A "Threshold data register" (203), holding a constant
A buffer register (204), holding N-PDU
A "Length-In" (205) data register
A buffer register (206), holding N-PDU' or N-PDU receved from a lower sublayer
A "Length-Out" (207) data register
A "receive-time-long-N-PDU" (208) data register
A "larger than x-bytes" (209) data register, holding a constant
A "longer than y minutes since last long N-PDU received" (210) register, holding a constant
Access to system clock (211), which gives current time.
A Switch which (211) sends N-PDU' to the Data Compressor or to (213)
A Concentrator (213), which feeds output from (204) and (212) into one output to an upper sub-layer. Other embodiments ofthe RX monitor could be assembeled based on the explanation of the invention provided herein. The functioning ofthe RX monitor embodiment of fig.
14 is as explained earlier.
APPENDIX :
Definitions, terms and acronyms
SNDCP Sub-network dependence convergence protocol (ref. ETSI TS 101 297, V8.0.0 (2000-03))
SNDCP management entity The SNDCP management entity handles communication with SM sub-layer and controls the operation ofthe SNDCP entity.
SNDCP entity The SNDCP entity handles the service functions provided by the SNDCP layer. The SNDCP entity is temporary logical link identity specific.
PDP Packet Data Protocol
PDU Protocol Data Unit
NSAPI Netwwork Service Access Point Identifier