NO315920B1 - Traffic-dependent control of data compression - Google Patents

Description

The present invention relates to the management of data compaction. In particular, the present invention relates to the use of V.42bis compression in the SGSN node in a GPRS system, only when it produces a desired effect.

The invention thus relates to an improvement in the SGSN for the SNDCP protocol layer, i.e. the GPRS Gb interface between an MS and the SGSN.

SGSN serves many mobile stations, MS (subscribers) simultaneously. Each MS can have no or more pdp contexts enabled. Each pdp context may have an active data compression algorithm in accordance with V.42bis. V.42bis is a very demanding function with regard to the central processing unit (CPU). In GPRS, V.42bis is placed in the SNDCP layer in the SGSN and MS. The SGSN processor capacity in the SNDCP layer can be the bottleneck in the transmission plane, which will appear from the accompanying figure 1. V.42bis consumes processor capacity even though the compression effect is low. To avoid wasting CPU power in SGSN, it is important to disable V.42bis compression when the impact is low. Figure 1 shows the SNDCP protocol in its proper environment in GPRS, and shows the protocol stack that was used for the payload (eg IP packets).

For example, compression efficiency is low for pre-compressed traffic such as images (such as the "jpeg" and GIF image formats) or for compressed files (such as the "zip" file format). Note that compressing already compressed data will result in more output than input.

In a GPRS communication system, a PDP context can usually work in two modes, unacknowledged mode or acknowledged mode. These two modes affect the behavior of the V.42bis data compression algorithm. In verified mode, V.42bis works as intended at the time the V.42bis standard was established, ie a compression tree is trained to perform progressively better compression for each processed N-PDU (typically IP packets). In unacknowledged mode, the compression step is reset after each N-PDU. Therefore, the V.42bis efficiency in unconfirmed mode depends on both the PDU length and the characteristics of the data contained in the N-PDU.

In an existing GPRS system example, the traffic is generally always sent to the V.42bis function in the SGSN after activating data compression according to V.42bis, even when the compression does not have a significant data reduction effect. This conforms to the standardized V.42bis handling in accordance with the standard GSM 04.65 entitled "Subnet Dependent Convergence Protocol (SNDCP)", version 6.7.0, issue 1997, February 2000. To identify the location of a V.42bis function or device that performs data compression in a known GPRS system example, reference is made to the accompanying figure 2.

Known technology in the area of the invention can also be found in the publication ETSI TS 101 297 V8.0.0 (2000-03), which for the present invention forms a background standard that describes SGSN and SNDCP on the basis of document GSM 04.65, version 8.0.0. The publication describes the standard with the SNDCP layers, transfer of pdp context or "peer-to-peer" traffic with compression algorithms in confirmed mode and unconfirmed mode. It describes the negotiation of compression units with the XLD parameter.

Patent publication US 5,550,881 describes a solution that enables end users (typically mobile phones, laptops, etc.) to call a modem pool (ie by line-switched data connection). The transmission time is reduced to load the remote modem as little as possible, which gives the customer the opportunity to save money, and which gives the Internet service provider who owns the modem pool the opportunity to offer the service to more customers for each installed and available modem. The solution set forth in US 5,550,881 considers a complete data file as an object to be transferred. Consequently, a prerequisite for the solution stated in US 5,550,881 is that the file system for the data to be transported is available to the compression control device, or to the device that controls the choice of modulation on the transmission medium, which may be possible to implement in a solution that is extended to include the end-user system, such as, for example, a computer at the end-user that holds the data to be transferred.

However, the file system at the end user is usually not accessible to the modem collection that provides the data compression.

GPRS is a packet-switched system where it is desirable to reduce the data unit compression's resource consumption in a node, such as, for example, the CPU load in the SGSN or in a mobile station. However, the transmission time may remain unchanged.

In a GPRS system, an SGSN can in some respects be considered equivalent to a modem pool, but access to the data file's original name, file type and file size is not obtainable. Instead, the data to be transported appears as a stream of data words contained in packet data units.

In existing solutions, compression/decompression works without regard to the efficiency of the compression/decompression and consumes system resources, such as, for example, compressor capacity, which could otherwise be released for other purposes if the resource consumption effects resulting from inefficient compression can be reduced.

One purpose of the present invention is to provide a solution in a telecommunications system to improve the resource consumption efficiency of data compression.

A further purpose of the present invention is to provide a solution in a telecommunications system to improve resource consumption efficiency by data compression which does not depend on a file system that accommodates the data to be communicated.

The present invention provides a method and arrangement for evaluating the packet data unit size, compression efficiency, and time between handling long packet data units for a particular packet data unit connection and, depending on the evaluation result, provides routing of packet data units to pass through or bypass a data compressor/decompressor, a compression negotiator is ordered to negotiate compression activation or

- deactivation.

The features of the invention are reproduced in the accompanying independent patent claims 1-4, 8-11 and 15-22.

Other advantageous features of the invention are reproduced in the accompanying non-independent patent claims 5-7, 12-14 and 23-25.

Other features of the invention will emerge from the present description of the invention.

The invention particularly relates to, and is located in, the "SNDCP entity" in accordance with the definition found in the SNDCP 3GPP standard. In this context, note that there exists an SNDCP entity for each PDP context, identified by the NSAPI number.

Accordingly, a mobile station/subscriber can have up to eleven SNDCP entities. A one-to-one relationship exists between an SNDCP entity and a PDP context.

In Figure 4 on page 19 of the publication ETSI TS 101 297 V8.0.0(2000-02), the various "internal layers", or "sub-layers" in the SNDCP layer can be identified. In the aforementioned Figure 4, a "sub-layer" including the "data compressor" is consistent with the "data compression sub-layer" in this specification's accompanying Figure 4b, while "segmentation" and other functions can be found in the "lower sub-layers of SNDCP", and "control compressor"- entities can be found in "the upper sub-layers of the SNDCP". In other words, the three sub-layers that are thereby defined together form an SNDCP entity. Accordingly, the present invention particularly relates to the "data compression layer" as defined therein.

Another term introduced herein to more clearly explain the present invention is the term "XID Dealer". However, this term is nothing more than a new expression for the same functionality that is already described in the SNDCP standard, although it is not particularly well explained there. In section 5.2, headed "Service", in the document ETSI TS 101 297 V8.0.0 (2000-02) (the SNDCP standard) a simple description of an XID negotiator is given which can be briefly referred to as "negotiation of the XID parameters between interoperating SNDCP entities using XID exchange". The XID reseller provides the SN-XID service primitives to SNDCP users (see Table 1 headed "SNDCP layer service primitives" in the SNDCP standard). According to this standard, it is the SNDCP user who decides to initiate an XID negotiation to enable (or disable) header compression or data compression. Negotiation of the XID parameters between cooperating SNDCP entities uses XID exchange.

In a solution in accordance with the present invention, the Rx/Tx monitor is able to decide (and can be authorized to decide) when XID negotiation should be started, without the need for interaction with its related SNDCP user. In other words, an SNDCP user may think that data compression is enabled (using the XID), when in fact it may have been temporarily turned off by the Rx/Tx monitor, for example, because the data compression did not have the desired effect seen from the invention's RX/Tx monitor.

In the following description of the present invention, the terms "compression-on-signal" and "compression-off-signal" are useful in explaining the present invention. These signals, as they are utilized in the invention, are linked to compression negotiation by: i. The Tx (or Rx) monitor sends to the XID negotiator the "compression-on" signal. This is the same as the service root "SN-XID.Request" (requested

SNDCP XE) parameters to turn on data compression).

ii. The Tx (or Rx) monitor receives from the XID negotiator the "compression-on" signal. This is the same as the service root word "SN-XID.Confirm" (negotiated

SNDCP parameters to turn on data compression).

iii. The Tx (or Rx) monitor sends the XID dealer the "compression-off" signal. This is the same as the service root "SN-XID.Request" (requested

SNDCP XID parameters to turn off data compression).

iv. The Tx (or Rx) monitor receives from the XID negotiator the "compression-off" signal. This is the same as the service root word "SN-XID.Confirm" (negotiated SNDCP parameters to turn off data confirmation).

In explaining the present invention, the term 'Tiode compression' is also useful, even though the standard referred to above uses the term 'control compressor', which in reality are equivalent functions.

The present invention is explained with reference to the accompanying drawings where: Fig. 1 is a schematic transmission plan illustration of a protocol stack arrangement in

a digital GPRS communication arrangement,

fig. 2a is a schematic illustration indicating the location of data compression entities in an SNDCP layer in an example GPRS system;

fig. 2b is a detailed schematic representation of the sub-layers of an SNDCP layer, to

identification of sublayers that are of interest to the present invention,

fig. 3 is a state diagram illustrating the operating states and associated state transitions in a solution in accordance with the present invention,

fig. 4 is a schematic illustration of a compression providing SNDCP layer i

a GPRS system example incorporating the present invention,

fig. 5 is a flowchart illustrating operation of the invention in operation

broadcast data in a compression mode state,

fig. 6 is a flowchart illustrating operation of the present invention in action

with broadcast data in a non-compression mode state,

fig. 7 is a flowchart illustrating operation of the present invention in action

with broadcast data in a compression "bypass" mode state,

fig. 8 is a flowchart illustrating operation of the present invention in action

with broadcast data in a non-compression "bypass" mode state)

fig. 9 is a flowchart illustrating operation of the present invention in action

with receive data in a compression mode state,

fig. 10 is a flowchart illustrating operation of the present invention in action

with receive data in a non-compression mode state,

fig. 11 is a flowchart illustrating operation of the present invention in action

with receive data in a non-compression ``bypass'' mode state,

fig. 12 is a flowchart illustrating operation of the present invention in action

with receive data in a compression "bypass" mode state,

fig. 13 is a block schematic drawing depicting an embodiment of a Tx monitor part in accordance with the present invention, and

fig. 14 is a block schematic drawing depicting one embodiment of an Rx monitor part in accordance with the present invention.

In what follows, the invention will be explained with reference to the accompanying drawings, and partly by means of examples, with reference to a common GPRS telecommunications system.

First, referring to Figure 4a, which depicts a data compression sub-layer in an SNDCP layer in a node, a Tx compression monitor as well as an Rx compression monitor in accordance with the invention are shown. The term "monitor" as used herein refers to the invention, which serves to monitor the compression effect, to effect data unit routing through the SNDCP layer when found correct, and to control the operation of compression. In the example shown in Figure 4a, which illustrates an arrangement in accordance with the present invention in operation in a serving network node, such as, for example, an SGSN node in a GPRS system, the Tx compression monitor is shown to handle compression management in the transmit (Tx) direction. Similarly, the Rx compression monitor handles compression control in the receive direction with respect to packet data units (PDUs) received from the cooperating entity.

With reference to Figure 3, a compression monitor according to the present invention can work in one of four modes:

- (1) Non-compression "bypass" mode,

(2) compression mode,

- (3) compression 'T3ypass' mode, or

- (4) non-compression mode.

In the two "bypass" modes (1) and (3), compression effects or other relationships between a data unit input and output are generally not taken into account. In the remaining modes (2) and (4), compression control or other conditions between a data unit input and output are taken into account for compression control. Depending on the implementation, the monitor of the invention may include additional operating modes.

In what follows, and with reference to the attached figures 3 and 4a, the operating modes of the invention will be explained in general terms.

In non-compression "bypass" mode (1), the monitor facilitates the forwarding of payload data packets on its input (10, 15) through its associated layers to the output (11, 14) without compression effect. A transition to non-compression "bypass" mode (1) is made when no compression has been negotiated and the time between long data units has exceeded a predetermined threshold. The monitor will remain operating in non-compression 'T3ypass' mode (1) until data compression is negotiated by a compression negotiator, such as an XID negotiator in a GPRS implementation using V.42bis, optionally for a particular PDP context and direction The non-compression "bypass" mode can be thought of as a wait state while the compression arrangements are decided.

In compression mode (2), the monitor facilitates forwarding of payload data packets on its input (10,15) to an input (17,20) of a compressor (or decompressor), and forwarding of compressed (or decompressed) payload data packets on an output ( 18,19) on the compressor (or decompressor) to an output (11,14). The monitor also assesses the number of payload data packets without any visible compression effect, for example by comparing an N-PDU before and after data compression, and by counting the number of consecutive such data packets. If many consecutive payload data packets, i.e. N-PDUs, for one and the same PDP context do not produce less compressed packets through compression, then a negotiation aimed at renegotiating the compression is initiated. A transition to the monitor's compression mode (2) is made when the data compression has been agreed upon by the communicating nodes. For example, the monitor transitions to this mode after an XID negotiation for data compression has been completed, which is indicated by a signal (21,22) on the connection to the XID negotiator.

In compression "bypass" mode (3), the monitor facilitates forwarding of payload data packets on its input (10,15) to an input (17,20) of the compressor (or decompressor) and forwarding of compressed (or decompressed) payload data packets to its output (11,14). The transition to compression "bypass" mode is made when the monitor in a previous compression mode has determined that compression is not having the desired effect. The monitor will remain operating in compression "bypass" mode until data compression is negotiated away by a compression negotiator, such as an XID negotiator in a GPRS implementation using V.42bis, optionally for a particular PDP context and direction. Compression 'T3ypass' mode can be considered a wait state while the compression arrangements are decided.

In non-compression mode (4), the monitor facilitates the forwarding of payload data packets on its input (10,15) through its associated layers to its output (11,14), with no compression effect. In addition, the monitor determines the length of the payload data packet and records the time of reception of a payload data packet with a length that reaches a threshold. When the interval between consecutive long payload data packets reaches a threshold, the monitor initiates a compression negotiation.

As can be seen from figure 4a, in a system for providing bidirectional compression, two monitors (12,13) in accordance with the present invention which are arranged in an SNDCP layer to handle receiving data units and sending data units respectively can work independently of each other. For example, one monitor may be in a compression mode, while the other may be in a non-compression mode.

PDP contexts for authenticated mode and unauthenticated mode are both the same.

Referring to Figure 1, in a GPRS system example, the XID negotiator negotiating compression associated with an SNDCP entity communicates with a cooperating SNDCP entity on the other side of the Gb interface.

In what follows, and with reference to the accompanying drawings with Figures 5-12, the invention's operating modes will be explained in more detail, where the invention is also considered adapted to and in operation with the handling of data units sent from a cooperating node as well as data units received from a cooperating node.

With reference to figure 5 and using GPRS terminology, a monitor in accordance with the present invention which works in a compression mode in a GPRS system example, and which handles data units which are sent out, is first explained in the following.

Al: Once the XID negotiator has agreed to begin data compression for this direction, the XID negotiator commands the Tx monitor to go into compression mode. The transition to compression mode is also made by a transition decision in a previous mode.

A2: While waiting for, and while receiving a data unit (N-PDU) on the input.

A3: After receiving the N-PDU, the length of the N-PDU is determined and stored in a variable "length-in"; 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 the N-PDU is determined and stored in the "length-out" variable.

A5: Determining the compression effect by determining whether length-out is less than length-in.

A6: If not less, a "consecutive counter" is incremented by one.

A7: Determination of whether the consecutive counter has reached a threshold. (The setting of this threshold must be configurable, a typical preferred value might be 10, for example 10 consecutive N-PDUs that did not provide any compression).

A8: Resetting the consecutive counter (to zero).

A9: Forwarding of N-PDU<1> to the output, and loop to A2.

A10: Forwarding of N-PDU' to the output.

Al 1: Ordering the XID dealer to turn off data compression, and the monitor transitions to compression "bypass" mode.

With reference to Figure 6 and using GPRS terminology, a monitor in accordance with the present invention which operates in a non-compression mode in a GPRS system example and which handles data units being transmitted will be explained in the following.

Bl: When the XLD negotiation has agreed to end the data compression for this direction, the XID negotiator orders the Tx monitor to transition to non-compression mode. Transition to non-compression mode is also achieved by a transition decision in a previous mode.

B2: Storage of the current point as the time of reception of a preceding data unit (N-PDU) with a length reaching a predetermined length threshold.

B3: Waiting for and receiving an N-PDU at the input.

B4: Determining the length of the received N-PDU and deciding whether the length is greater than (ie it reaches) a predetermined length threshold.

BS: If greater, determination of whether the period between the time of receipt of the current N-PDU and the time of receipt of a preceding N-PDU with a length greater than (ie, when) the predetermined length threshold reaches a predetermined period threshold. For example, if a long N-PDU is to be sent and the period (eg "y" minutes) since the last long N-PDU was handled is large enough to reach or exceed a predetermined period limit, another attempt to perform compression is made. (This logic has been chosen so that new type of traffic may have started to flow (for example, another TCP session), which is not already compressed by the end application. The timeout value can typically be set to 3 minutes, which in the worst case will cause an activation /disabling data compression 20 times per hour for each PDP context and direction).

B6: If the period does not reach the threshold, store the time of reception of the current N-PDU time as the time of reception of a preceding N-PDU with a length reaching a predetermined length threshold.

B7: If the period reaches a threshold, forwarding the received N-PDU to the output.

B8: Forwarding of the received N-PDU to the output, and in a loop back to B3. B9: Ordering the XID dealer to turn on data compression, and the monitor transitions to non-compression "bypass" mode.

Referring to Figure 7 and using GPRS terminology, a monitor in accordance with the present invention in a compression "bypass" mode in a GPRS system example and handling data units being transmitted is explained hereinafter .

Al 2: The monitor transitions to compression "bypass" mode after a transition to this mode initiated by a preceding mode.

A13: Waiting for and receiving an input such as a data unit (N-PDU) on the data unit input or a compress-off signal from the XID dealer.

Al4: Determination of whether the input is a compression-off signal.

Al5: Forwarding of a received N-PDU to the compressor.

Al 6: Waiting for and receiving the (compressed) data unit (N-PDU') from the data compressor.

A9: Forwarding of N-PDU* to the output, and in a loop back to Al 3. ;Al 7: Command of monitor transition to non-compression mode. Referring now to Figure 8 and using GPRS terminology, a monitor in accordance with the present invention operating in a non-compression "bypass" mode in a GPRS system example and handling data devices which is sent out is explained in what follows. ;B10: The monitor transitions to non-compression "bypass" mode after a transition to this mode is initiated by a preceding mode. ;Car: Waiting for and receiving an input such as a data unit (N-PDU) on the data unit input or a compression-on signal from the XID dealer. ;Bl2: Determination of whether the input is a compression-on signal. ;B8: Forwarding of a received N-PDU to the output, and in a loop back to Bl 1. B13: Ordering monitor transition to compression mode. Referring to Figure 9 and using GPRS terminology, a monitor in accordance with the present invention operating in a compression mode in a GPRS system example, and handling data units being received, is explained in the following. ;Cl: When the XID negotiator has agreed to begin data compression for this direction, the XID negotiator commands the Tx monitor to transition to compression mode. Transition to compression mode is also done by transition decision in a previous mode. ;C2: Waiting for and receiving a data unit (N-PDU') at the input. ;C3: After receiving the N-PDU', the length of the N-PDU' is determined and stored in a variable "length-in"; 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 the N-PDU is determined and stored in the "length-out" variable. C5: Determination of compression effect by determining whether length-out is greater than length-in. ;C6: If not greater, then a "consecutive counter" is incremented by one. ;Cl: Determination of whether the consecutive counter has reached a threshold. (The setting of this threshold must be configurable, a typical preferred value might be 10, ie 10 consecutive N-PDUs that did not provide any compression). ;C8: Reset of the consecutive counter (to zero). ;C9: Forwarding of N-PDU to the output, and in a loop back to C2. ;CIO: Forwarding of N-PDU' to the output. ;Cl 1: Ordering the XID dealer to turn off data compression, and the monitor transitions to compression "bypass" mode. ;Referring to Figure 10 and using GPRS terminology, a monitor in accordance with the present invention operating in a non-compression mode in a GPRS system example, and handling data units being received, is explained in the following subsequently. ;Dl: When the XID negotiation has agreed to end data compression for this direction, the XID negotiator orders the monitor to transition to non-compression mode. ;D2: Storage of the current point as the time of reception of a preceding data unit (N-PDU) with a length that reaches a predetermined length threshold. ;D3: Waiting for and receiving an N-PDU on the input. ;D4: Determining the length of the received N-PDU and examining whether the length is greater than (ie when) a predetermined length threshold. ;D5: If greater, determination of whether the period between the time of receipt of the current N-PDU and the time of receipt of a previous N-PDU with a length greater than (ie, which reaches) the predetermined length threshold reaches a predetermined period threshold . For example, if a long N-PDU is to be sent and the period (eg "y" minutes) since the last long N-PDU was handled is large enough to reach or exceed a predetermined period limit, another attempt to perform compression is initiated. (This logic has been chosen so that a new type of traffic may have started to flow (for example another TCP session), which is not already compressed by the end application. The timeout value for the variable "y" can typically be set to 3 minutes, as in the worst case can cause an enable/disable data compression 20 times per hour for each pdp context and direction). ;D6: If the period does not reach the threshold, storing the time of receiving the current N-PDU as the time of receiving a preceding N-PDU with a length that reaches the predetermined length threshold. ;D7: If the period reaches the threshold, forwarding of the received N-PDU to the output. D8: Forwarding of the received N-PDU to the output, and in a loop back to D3. D9: Ordering the XID dealer to turn on data compression, and monitor transition to non-compression "bypass" mode. ;Referring to Figure 11 and using GPRS terminology, a monitor in accordance with the present invention operating in a non-compression "bypass" mode in a GPRS system example, and handling data devices which is received, explained below. ;C12: The monitor transitions to non-compression "bypass" mode after a transition to this mode is initiated by a preceding mode. ;C13: Waiting for and receiving an input such as a data unit (N-PDU) on the data unit input or a compression-on signal from the XID dealer. ;Cl4: Determination of whether the input is a compression-on signal. ;C9: Forwarding of a received N-PDU to the output, and in a loop back to Cl3. Cl5: Ordering monitor transition to compression mode. Referring to Figure 12 and using GPRS terminology, a monitor in accordance with the present invention operating in a compression '*bypass'' mode in an example GPRS system, and handling data units received , explained in what follows.

D10: The monitor transitions to compression 'T3ypass' mode after a transition to this mode is initiated by a preceding mode.

Dl 1: Waiting for and receiving an input such as a data unit (N-PDU') on the data unit input or a compress-off signal from the XID dealer.

D12: Determining whether the input is a compress-off signal.

D13: Forwarding of a received N-PDU' to the compressor.

D14: Waiting for and receiving the (decompressed) data unit (N-PDU) from the data compressor.

D8: Forwarding of N-PDU to the output, and in a loop back to Dl 1.

Dl5: Ordering monitor transition to non-compression mode.

In the above examples used herein to explain the invention, operation of the Rx (receive) and Tx (transmit) compression monitors of the invention has been explained by including operational control aspects of the payload data packet stream through a sub-layer of an example SNDCP layer. Packet flow control can, however, be achieved by means of other mechanisms that are external and as a complement to the compression monitor of the present invention. Accordingly, possibly also depending on the compression scheme used, a basic compression monitor in accordance with the present invention may include those parts of the particular compression monitor concerned with monitoring compression efficiency and controlling the monitor operating mode, as well as any means or method that is necessary to communicate state and/or commands with respect to a compression negotiator regarding a mode change.

In the following, advantages of the present invention are indicated.

The methods of the invention will disable data compression when it is ineffective. A procedure for turning data compression back on is also described.

In a GPRS system, a method or arrangement implementing the invention will avoid data compression being turned on and off at a high rate for a particular PDP context, thus avoiding excessive XID signaling.

The same procedure can also be used for a PDP context in unconfirmed mode as well as confirmed mode.

In accordance with a further aspect of the invention, no standardization is necessary to implement the invention.

The following describes how the present invention can be extended.

The present invention is not exclusively linked to a specific ETSI edition of the standards. Reference has been made to edition 97 of the GPRS standard, but the invention is also applicable to later editions where data compression is standardised.

The procedure is also valid for the MS, and not only for the SGSN or corresponding network nodes.

The invention can also be applied to other technologies where the compression entity does not know the type of data to be transported. Typical examples of such technologies are modem pools and routers.

In the following, an implementation example of the present invention is described.

In accordance with the detailed description given above of the present invention, an embodiment of the invention may include a Tx monitor for each SNDCP entity, and is made up of the following components as illustrated by means of the attached Figure 13: • A control program (100) which implements the logic indicated in figures 5, 6, 7 and 8 of the invention. • A data register (101) that holds the current state, ie, should the control program perform what is shown in figure 5,6,7 or 8 when the next input arrives?

A "consecutive counter" (102) data register.

A "threshold data" register (103), which holds a constant.

A buffer register (104), which holds the N-PDU.

A "length-in" data register (105).

A buffer register (106), which holds N-PDU'.

A "length-out" data register (107).

A "receive-time-long-N-PDU" data register (108).

A "greater-than-x-word" register (109), which holds a constant.

A "longer-than-y-minutes-since-last-long-N-PDU-received" register (110), which

holds a constant.

Access to the system clock (111) which gives the current time.

A switch (112) that sends the N-PDU to the data compressor or to (113).

A concentrate (113), which feeds output from (112) and (106) into an output to a lower sublayer.

Other embodiments of the TX monitor may be constructed based on the explanation of the invention provided herein. The operation of the TX monitor embodiment in Figure 13 is as explained earlier.

In accordance with the detailed description above of the present invention, an embodiment of the invention may include an RX monitor for each SNDCP entity, and is made up of the following components as illustrated by means of the accompanying Figure 14: • A control program (200) which implements the logic shown in Figures 9, 10, 11 and 12 of the invention. • A data register (201) that holds the current state, i.e. should the control program do what is shown in Figures 9, 10, 11 or 12 when the next input arrives?

A "consecutive counter" data register (202).

A "threshold data register" (203), which holds a constant.

A buffer register (204), which holds the N-PDU.

A "length-in" data register (205).

A buffer register (206), which holds N-PDU' or N-PDU received from a lower

sub team.

A "length-out" data register (207).

A "receive-time-long-N-PDU" data register (208).

A "greater-than-x-word" data register (209), which holds a constant.

A "longer-than-y-minutes-since-last-long-N-PDU-received" register (210), which

holds a constant.

Access to system clock (211), which gives the current time.

A switch which (211) sends the N-PDU' to the data compressor or to (213).

A concentrator (213), which feeds output from (204) and (212) into an output to a higher layer.

Other embodiments of the RX monitor may be devised based on the explanation of the present invention provided herein. The operation of the RX monitor embodiment shown in Figure 14 is as previously explained.

APPENDIX:

Definitions, terms and acronyms

Claims (25)

1. Control arrangement in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression vendor-controlled send direction data compressor device operating in a non-compression mode in an SNDCP data compression sub-layer at a service node of the system, which send direction data compressor device is arranged to receive, on a compressor input, payload data packets from a higher SNDCP sublayer and outputting, on a compressor output, compressed payload data packets to a lower SNDCP sublayer, characterized by means for determining and storing the time of receipt of a payload data packet with a length reaching a predetermined length threshold, and means for commanding the compression negotiator to negotiate activation of transmit direction data compression when a time interval between consecutive stored times of reception reaches a predetermined time interval threshold. 2. Control arrangement in a Subnetwork Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression vendor controlled receive direction data compressor device operating in a non-compression mode in an SNDCP data compression sublayer at a service node, which receive direction data compressor device is arranged to receive, on a compressor input, compressed payload data packets from a lower-lying SNDCP sub-layer and issuing, on a compressor output, payload data packets to a higher-lying SNDCP sub-layer, characterized by means for determining and storing the time of receipt of a payload data packet of a length reaching a predetermined length threshold, and means for commanding the compression negotiator to negotiate activation of receive direction data compression when a time interval between consecutive stored times of reception reaches a predetermined time interval threshold. 3. Control arrangement in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression vendor-controlled send direction data compressor device operating in a compression mode in an SNDCP data compression sublayer at a server node, which send direction data compressor device is arranged to receive, on a compressor input, payload data packets from an upper SNDCP sublayer and outputting, on a compressor output, compressed payload data packets to a lower SNDCP sublayer, characterized by means for determining a count value for the number of consecutive payload data packets with a (post-compression) length at the compressor output equal to or greater than a (precompression) length of the compressor input, and means for ordering the compression negotiator to negotiate deactivation of transmit direction data compression when the count value reaches a predetermined threshold. 4. Control arrangement in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression vendor-controlled receive direction data compressor device operating in a compression mode in an SNDCP data compression sublayer at a server node, which receive direction data compression device is arranged to receive, on a compressor input, compressed payload data packets from a lower-lying SNDCP sub-layer and issuing, at a compressor output, payload data packets to a higher-lying SNDCP sub-layer, characterized by means for determining a count value for the number of consecutive payload data packets with a (post-compression) length at the compressor output equal to or less than a (pre-compression) length of the compressor output, and means for ordering the compression negotiator to negotiate deactivation of receive direction data compression when the count value reaches a predetermined threshold. 5. Control arrangement as stated in any one of claims 1-4, characterized in that the data compression device is a V.42bis data compressor. 6. Management arrangement as stated in claim 5, characterized in that the compression dealer is an XID dealer. 7. Control arrangement as specified in claim 6, characterized in that the payload data package is an N-PDU. 8. Method in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for enabling data compression in a compression dealer-controlled transmit direction data compressor device operating in a non-compression mode in an SNDCP data compression sub-layer at a server node in the system, characterized in that for payload data packets received by the transmitter direction data compressor from a higher SNDCP sublayer, determining and storing the time of receipt of a payload data packet with a length reaching a predetermined length threshold, and commanding the compression negotiator to negotiate activation of transmit direction data compression when a time interval between consecutive stored reception times reaches a predetermined time interval threshold. 9. Method in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for enabling data compression in a compression dealer controlled receive direction data compressor device operating in a non-compression mode in a SNDCP data compression sub-layer at a server node in the system, characterized by, for payload data packets received by the receive direction data compressor from a lower-lying SNDCP layer, determining and storing the time of receipt of a payload data packet with a length reaching a predetermined length threshold, and commanding a compression negotiator to negotiate activation of receive direction data compression when a time interval between consecutive stored reception times reaches a predetermined time interval threshold. 10. Method in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for deactivating data compression in a compression dealer-controlled transmit direction data compressor device operating in a compression mode in a SNDCP data compression sub-layer at a server node in the system, characterized by for payload data packets from a higher SNDCP sublayer to be received by the transmitter data compressor, determining a count value for the number of consecutive payload data packets with a compressor output (post-compression) length equal to or greater than a compressor input (pre-compression) length, and commanding the compression negotiator to negotiate deactivation of transmit direction data compression when the count value reaches a predetermined threshold. 11. Method in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for deactivating data compression in a compression dealer controlled receive direction data compressor device operating in a compression mode in a SNDCP data compression sub-layer at a server node in the system, characterized by for payload data packets received by the receive direction data compressor from a lower-lying SNDCP sublayer, determining a count value for the number of consecutive payload data packets with a compressor output (post-compression) length equal to or less than a compressor input (pre-compression) length, and commanding the compression negotiator to negotiate deactivation of receive direction data compression when the count value reaches a predetermined threshold. 12. Method as stated in any one of claims 8-11, characterized in that the data compression device is a V.42bis data compressor. 13. Method as stated in claim 12, characterized in that the compression dealer is an XID dealer. 14. Method as stated in claim 13, characterized in that the payload data package is an N-PDU. 15. Data compression controller in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression vendor controlled data compressor, which data compression controller has a first input, a first output connected to a data compressor input, a second input connected to a data compressor output, a second output, and a management connection to the data compression dealer, characterized by that the data compression controller is responsive to a compression state signal from the data compression vendor and arranged to operate in one of several modes, where: Upon receipt of a compression-on control signal or after being arranged to transition thereto, the data compression controller operates in a first ("compression-on" ") mode with execution of the steps: a) to reset a counter, b) to receive on the first data input a data unit, c) to determine and to store a first length as the data unit length, d) to forward the data unit to the compressor input, e) receiving the compressed data unit from the compressor output, f) determining and storing a second length as the compressed data unit length, g) comparing the first length with the second length, and gl) if the second length is less than the first length, resets the counter, forwards the compressed data unit to the other output and to repeat steps b) through g), otherwise g2) incrementing the counter, h) comparing the counter with a predetermined threshold, and hl) if the counter has not reached the predetermined threshold, forwarding the compressed data unit to the second output and repeating steps b) through g), otherwise h2) forwarding the compressed data unit to the second output, sending a signal commanding the compression negotiator to negotiate decompression of data compression and causing the data compression controller to transition to a second mode of operation. 16. Data compression controller in a Subnetwork Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression vendor-controlled data compressor, which data compression controller has a first input for receiving a data unit, a first output connected to a data compressor input, a second input connected to a data compressor output , a second output, and a control connection to the data compression dealer, characterized by that the data compression controller is controllable through a compression state signal from the data compression dealer and arranged to operate in one of several modes, wherein: after a transition to a second mode of operation, the data compression controller operates in the second (compression 'T)ypass') mode to perform the steps: a) receiving as a control input a compression-off signal from the compression dealer or on the first input a data unit, b) determining the input type, and bl) if the control input is a compression-off signal, the data compression controller is caused to make a transition to a third operating mode, otherwise b2) forwarding the data unit to the compressor input, and receiving the compressed data unit from the compressor output, and forwarding the compressed data unit to the second output and repeating steps a) through b). 17. Data compression controller in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression dealer-controlled data compressor, which data compression controller has a first input for receiving a data unit, a first output connected to a data compressor input, a second input connected to a data compressor output , a second output, and a control connection to the data compression dealer, characterized by that the data compression controller is controllable through a compression state signal from the data compression dealer and is arranged to operate in one of several modes, where: upon receipt of a compression-off control signal or by being caused to transition thereto, the data compression controller operates in a third (not -compression mode to perform the steps: a) to store the current time as the time of reception of a preceding data unit with a length reaching a predetermined threshold, b) to receive on the first input a data unit and to determine the time of reception of the data unit; c) determining the length of the data unit as a first length, d) comparing the first length with the predetermined length threshold, and dl) if the first length reaches the length threshold, then e) determining the time interval between the time of receipt of the data unit and the time of reception of a preceding data unit with a length that reaches the length threshold, and el) if the time slot reaches a predetermined time slot threshold, then forwarding the data unit to the second output, sending a signal commanding the compression negotiator to negotiate deactivation of receive direction data compression and causing the data compression controller to transition to a fourth mode of operation, otherwise e2) to store the time of reception of the data unit as the time of reception of the preceding data unit, and forward the data unit to the second output and to repeat steps a) to c), otherwise d2) to forward the data unit to the second output and to repeat steps b) to d). 18. Data compression controller in a Subnetwork Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression dealer controlled data compressor, which data compression controller has a first input for receiving a data unit, a first output connected to a data compressor input, a second input connected to a data compressor output , a second output, and a connection to the data compression dealer, characterized by that the data compression controller is controllable through a compression state signal from the data compression vendor and arranged to operate in one of several modes, wherein: After a transition to a fourth mode of operation, the controller operates in the fourth ("non-compression bypass") mode to perform the steps : a) To receive as a control input a compression-on signal from the compression dealer or on the first input a data unit, b) to determine the input type, and bl) if the control input is a compression-on signal, then the data compression controller is arranged to transition to a first working mode, otherwise b2) to forward the data unit to the second output and to repeat steps a) to b). 19. Data compression controller in a subnetwork dependent convergence protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression dealer controlled data decompressor, which data compression controller has a first input for receiving a data unit, a first output connected to a data decompressor input, a second input connected to a data decompressor output , a second output, and a control connection to the data compression dealer, characterized in that the data compression controller is controllable through a compression state signal from the data compression dealer and arranged to operate in one of several modes, where: after receiving a compression-on control signal or having been caused to a transition thereto, the controller operates in a first ("compression") mode to perform the steps: a) to reset a counter, b) to receive on the first input a data unit, c) to determine and to store a first length which the length of the data unit, d) and further communicating the data unit to the decompressor input, e) receiving the decompressed data unit from the decompressor output, f) determining and storing a second length as the decompressed data unit length, g) comparing the first length to the second length, and gl) if the second length is greater than the first length, then to reset the counter, and forward the decompressed data unit to the second output and to repeat steps b) through g), otherwise, gl) incrementing the counter, and comparing the counter with a predetermined threshold, and hl) if the counter has not reached the predetermined threshold, then to forward the decompressed data unit to the second output and to repeat steps b) through g), otherwise hl) forwarding the decompressed data unit to the second output, sending a signal commanding the compression negotiator to negotiate decompression of the data compression and causing the controller to transition to a second mode of operation. 20. Data compression controller in a subnetwork dependent convergence protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression dealer controlled data decompressor, which data compression controller has a first input for receiving a data unit, a first output connected to a data decompressor input, a second input connected to a data decompressor output , a second output, and a control connection to the data compression dealer, characterized in that the data compression controller is controllable through a compression state signal from the data compression dealer and arranged to operate in one of several modes, wherein, after a transition to a second working mode, the data compression controller works in the second ("compression bypass") mode and performs the steps: a) receiving as a control input a compression-off signal from the compression dealer or on the first input a data unit, b) to determine the input type, and bl) if the control input is a compression-on signal, then arranging for the data compression controller to transition to a third working mode, otherwise b2) forwarding the data unit to the decompressor input, receiving the decompressed data unit from the decompressor output, forwarding the decompressed data unit to the other output and to repeat steps a) through b). 21. Data compression controller in a Sub-Network Dependent Convergence Protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression dealer controlled data decompressor, which data compression controller has a first input for receiving a data unit, a first output connected to a data decompressor input, a second input connected to a data decompressor output , a second output, and a control connection to the data compression dealer, characterized by that the data compression controller is controllable through a compression state signal from the data compression vendor and arranged to operate in one of several modes, wherein, upon receipt of a compression-off control signal or caused to make a transition thereto, the data compression controller operates in a third ("non-compression") mode to perform the steps of, a) storing the current time as the time of receipt of a preceding data unit with a length reaching a predetermined threshold, b) receiving on the first input a data unit and determining the time of receipt of the data unit, c) determining the length of the data unit as a first length, d) comparing the first length with a predetermined length threshold, and el) if the first length reaches the length threshold, then to determine the time interval between the time of reception of the data unit and the time of reception of a preceding data unit with a length that reaches the length threshold, and fl) if the time interval reaches a predetermined time space threshold, then to relaying the data unit to the second output, sending a signal commanding the compression negotiator to negotiate decompression of data compression and to effect for the controller a transition to a fourth operating mode, otherwise £2) to store the time of reception of the data unit as the time of reception of the preceding data unit, to forward the data unit to the second output and to repeat steps a) to c), else e2) to forward the data unit to the second output and to repeat steps b) even e2). 11. Data compression controller in a subnetwork dependent convergence protocol (SNDCP) layer in a GPRS or UMTS digital mobile telecommunications system for controlling a data compression dealer controlled data decompressor, which data compression controller has a first input for receiving a data unit, a first output connected to a data decompressor input, a second input connected to a data decompressor output , a second output, and a control connection to the data compression dealer, characterized in that the data compression controller is controllable through a compression state signal from the data compression dealer and arranged to work in one of several modes, where, after a transition to the fourth mode of operation, the data compression controller operates in the fourth ("non-compression bypass") mode to perform the steps, a) receiving as a control input a compression-on signal from the compression dealer or on the first input a data unit , b) to determine the input type, and bl) if the control input is a compression-on signal, then to cause the controller to transition to a first working mode, otherwise b2) to forward the data unit to the second output and to repeat steps a) to b). 23. Data compression controller as set forth in any one of claims 15-22, characterized in that the data compressor is a V.42bis data compressor or the data decompressor is a V.42bis data decompressor. 24. Data compression controller as set forth in claim 23, characterized in that the compression dealer is an XID dealer. 25. Data compression controller as stated in claim 24, characterized in that the payload data packet is an N-PDU.