HK1043451B - Header compression in real time services - Google Patents

Description

Header compression in real-time services

Technical Field

The present invention relates to data transmission and in particular to a method for transmitting data packets from a compressor to a decompressor, said data packets comprising a header with header data fields, a number of header data fields being kept constant during data transmission being stored in the decompressor. The method comprises the following steps: transmitting from the compressor and receiving at the decompressor a data packet comprising information about one or more header data fields that change during the data transfer; and decompressing the header using the stored header data fields and the received information about the one or more header data fields that changed during the data transfer. The invention also relates to an access network element implementing the inventive method.

Background

Real-time traffic constitutes an emerging set of technologies that enable voice, data, and video to cooperate over packet-switched networks. With the standardization of packet switched radio systems, there is also an increasing interest in providing real-time services over wireless networks. Many protocols are used in real-time services to accomplish packet transmission. This results in large protocol overhead and causes inefficient bandwidth usage. The transmission of large headers means a wasteful use of capacity due to the limited transmission rate in wireless systems.

To overcome the problem of large headers, various header compression schemes have been introduced. The publication "Compressing IP/UDP/RTP heads for Low-Speed Serial Links" written by S.Casner and V.Jacobson in Internet Engineering Task Force, INTERNET-DRAFT, DRAFT-ietf-avt-crtp-05.txt, 7.1998, proposes an effective title compression algorithm that can reduce the size of a title by a factor of two. The proposed header compression is based on the fact that some bytes in IP, UDP and RTP headers remain unchanged during the lifetime of the connection. After sending the uncompressed header, these fields may be omitted from subsequent compressed headers. Also, differential encoding is used on the ever-changing fields to reduce their size. In RTP headers, the difference between packets is often constant and therefore the second step difference is also zero. By keeping the uncompressed header and the first order difference in the dialog state shared between the compressor and decompressor, it is mainly necessary to mean that the second order difference between consecutive packets is zero. It is also suggested that the compressor implementation may maintain state for multiple dialog contexts (contexts). The use of a hash function to index a table of stored dialog contexts for certain predefined fields, and the inclusion of a dialog context identifier in the compressed packet will enable the decompressor to directly index the table of stored dialog contexts.

Real-time traffic severely limits transmission delay and therefore normal retransmission procedures (e.g. in the transmission control protocol TCP, which is typically used for IP packet transmission) are generally not applicable. Thus, the link in real-time traffic is actually considered a simplex link. In the prior art document, a periodic update scheme is proposed for simplex links. Once a decompressor detects an error in a packet stream, it discards all packets in that packet stream and will not restart decompression until a periodically sent uncompressed header (update header) is received, which means that all packets before the next update packet are lost after a transmission error. In a transmission link in which errors occur less frequently, this has no great influence on the transmission throughput. However, this effect is disruptive when high risk links with multiple transmission errors are involved, which is especially true for wireless transmission.

Wireless Networks 3(1997)375-387, J.C. Balzer AG, science publishers, by Mikael Degermark, Mathias Engan, Bjorn Nordgren and Stephen Pink, the publication "Low-load TCP/IP header compression for Wireless Networks" which addresses the simplex and lossy link problems. In the proposed system, the compressor sends a full header and a compressed identifier, which is a small unique number that is also transmitted with the compressed header. This full header is stored by the decompressor as a compressed state. This compression identifier in the compressed header is used to find the appropriate compression state for decompression. To overcome the incorrect decompression due to inconsistent compression states, some other mechanism is introduced. The compression status of each version is associated with the generation of a number representation in a header that is transmitted with a full header that installs or updates that compression status and is compressed with it. Thus, the decompressor can detect when its compression state is outdated by comparing its generation to that in the compressed header. Moreover, in order to avoid long periods of packet discard when full headers are lost and on the other hand to obtain as high a compression rate as possible, the compressor starts with a short interval between full headers and the update interval is incremented exponentially with each update until a steady state update period is reached (slow start of compression). A trade-off for moderate some header compression is also suggested.

While the use of compression state generation facilitates easier detection of inconsistent compression states, packets are lost until the full header is populated with the correct compression state. The slow start of compression helps to find a convenient compromise between compression rate and acceptable recovery time, but in difficult transmission conditions, compression rate is compromised and the advantages of header compression are compromised.

Disclosure of Invention

Now a method and a network element implementing the method have been invented, with which these problems can be avoided or their impact can be reduced.

According to one aspect of the invention, there is provided a method for transmitting a data packet from a compressor to a decompressor, the data packet comprising a header having header data fields, a number of header data fields being stored in the decompressor constant during data transmission. The method comprises the following steps: transmitting from the compressor and receiving at the decompressor a data packet comprising information about one or more header data fields that change during the data transfer; the header is decompressed using the stored header data fields and the received information about the one or more header data fields that changed during the data transfer. The method is characterized in that: transmitting from a compressor and receiving at a decompressor a compression value for a header data field, the compression value identifying a data packet in a compressed sequence; maintaining in the decompressor context data comprising information for correlating received compressed values with corresponding compressed sequences, the information being updated in dependence of the received compressed values; and using the compressed value and information of the corresponding compressed sequence to map the compressed value into a decompressed header data field.

The advantage of the invention is based on the fact that most fields in the network layer packet remain constant during the whole session. The network layer in this context refers to the packet data network level protocol layer, e.g. to the IP, UDP and RTP protocols. Moreover, it is recognized that: the variation of the fields from packet to packet is predictable. Such fields are sent in compressed form to the decompressor. Based on prior knowledge of the expected changes, the decompressor will generate and maintain context data that is updated with information of packets received in the decompressor. The compressed data is unambiguously mapped to changes in the decompressed values in a set of consecutive data packets (i.e. the compressed sequence). In the context data, information about one or more compressed sequences is maintained, which information provides a way to correlate the received compressed data with the correct compressed sequence. The use of the received compressed data with the corresponding context data held in the decompressor enables the compressed data to be unambiguously mapped to the full packet header on the decompressor side during the entire session. Preferably, data packets conveying information that is not correctly related to any one compressed sequence of context data held in the decompressor have been filtered out at the compressor side.

The compression in the inventive method is increased compared to earlier solutions, since also the ever changing fields related to the identification of packets can be compressed. Transmission errors will still only affect the transmission of a single packet and problems in the transmission of one packet will not propagate to subsequent packets. The scheme of updating the entire header information can be designed to occur at longer time intervals, or can be abandoned altogether.

In particular, the present invention provides a method for processing data packets, comprising: receiving a data packet comprising an ordinal (ordinal) indicating the order of this packet in a series of transmitted packets; comparing the ordinal number of the received packet with an earlier stored comparison ordinal number; in response to a difference between the ordinal number of the received packet and the compared ordinal number exceeding a predetermined limit, initiating an error function; in response to the difference between the ordinal number of the received packet and the compared ordinal number being less than a predetermined limit, initiating a header compression algorithm; in response to the ordinal number of the received packet being greater than the comparison ordinal number and the difference between the ordinal number of the received packet and the comparison ordinal number being less than a predetermined limit, the ordinal number of the received packet is stored as the comparison ordinal number.

According to another aspect of the invention, there is provided an access network element comprising: means for transmitting a data packet to a decompressor, the data packet including a header having a header data field; means for compressing the header by excluding from transmission header data fields that remain constant during data transfer; means for sending a data packet to the decompressor comprising information about one or more header data fields that change during the data transfer; the method is characterized in that: means for transmitting a compressed value identifying a header data field associated with a data packet in a compressed sequence, the compressed value being formed using a first number of least significant bits of the header data field.

According to another aspect of the invention, there is provided an access network element comprising: means for receiving a data packet, the data packet including a header having a header data field; means for storing header data packets that remain constant during data transmission; means for receiving a compressed data packet comprising information about one or more header data fields that change during data transmission; means for decompressing the compressed data packet using the stored header data fields and the received information about the one or more header data fields that changed during the data transfer; the method is characterized in that: means for receiving, in the data packet, a compression value identifying the data packet in the compressed sequence, the compression value being a first number of least significant bits of the header data field; means for maintaining context data comprising information for correlating received compression values with corresponding compression sequences, the information being updated in accordance with the received compression values; means for using the compressed value and information of the corresponding compressed sequence to map the compressed value to a header data field in the decompressed data packet.

Drawings

For a better understanding of the present invention and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

fig. 1 shows the accumulation of header overhead for different layers in the transmission of a voice frame 10 over a wireless IP connection;

figure 2 shows some functional elements of a GPRS network and the associated protocol structure;

FIG. 3 shows fields of network layer RTP, UDP and IP headers;

fig. 4 shows the functionality in a receiving entity according to the invention;

FIG. 5 illustrates the format of a compressed header used in one embodiment of the present invention;

fig. 6 shows a method of the invention in which an abbrevved time stamp is used

The steps of the example;

FIG. 7 shows an example of a filtering algorithm according to the present invention;

FIG. 8 shows the format of SNDCP SN-UNITDATA PDUs;

FIG. 9 shows an alternative embodiment; and

fig. 10 shows the blocks in a mobile station according to the invention which are responsible for the different functions.

Detailed Description

The invention will be described using an embodiment of the General Packet Radio System (GPRS) in which an ITU-T voice encoder g.723.1, internet protocol version 4 and ETSI, all of which are generally common to those skilled in the art, are used. It should be noted that: for all these systems, parallel or corresponding techniques exist and will be further referred to. Accordingly, the scope of protection is not limited by the details of the protocols used in the following description. The method described herein can also be applied in fixed networks, but the problem is more pronounced in wireless communications, in this example using such a structure.

Fig. 1 shows the accumulation of header overhead for different layers in the transmission of a voice frame 10 over a wireless IP connection. The shaded boxes represent the header, while the white boxes represent the payload in the data frame. First, a speech frame 10 is encapsulated into a real-time protocol (RTP) packet 11 that is placed into a User Data Protocol (UDP) packet 12 and also into an Internet Protocol (IP) packet 13. The IP packets 13 are also encapsulated with a sub-network dependent convergence protocol (SNDCP)14 and a logical link control protocol (LLC) into LLC blocks 15, which blocks 15 are divided into a suitable number of RLC blocks, each containing a separate header. As can be appreciated, the cumulative overhead is very large. When using the G723.1 encoder, the protocol overhead in the IP layer is already 40 bytes and the bandwidth usage is about 33%. This situation is made worse by the fact that the protocol header of the wireless link still generates additional overhead.

In this embodiment, header compression and header decompression is done in the access network specific protocol layer (in this case the SNDCP layer). Figure 2 shows some functional elements of a GPRS network and the associated protocol structure. GPRS is logically implemented as a general GSM architecture with two network elements, namely a Gateway GPRS Support Node (GGSN) and a Serving GPRS Support Node (SGSN). The GGSN is the first packet data network access point in a GSM network that supports GPRS. Data packets whose PDP address (packet data protocol, e.g. IP or x.25) represents a GPRS subscriber are routed to the GGSN. The GGSN provides the information needed to route these data packets to the current access point SGSN of this user. The GGSN may query the location data of the subscriber from the GSM Home Location Register (HLR). An SGSN is an access point serving a Mobile Station (MS). For GPRS connections, the SGSN establishes mobility management functions towards the MS and PDP functions towards the packet data network in order to route these data packets towards the GGSN. The SGSN and GGSN can be integrated in the same physical node or can be located in separate nodes.

The access network SNDC function provides the network layer with a service for transferring a minimum amount of data between the SGSN and the MS using different compression techniques. GPRS provides procedures implemented in conjunction with service negotiation so that the MS agrees with the SGSN on the compression algorithm to be used in the session. In the method of the invention it is proposed that the header part, which remains constant, is stored in the SNDCP entity. Next, the structure and content of the network layer protocol header are studied in more detail.

In fig. 3, the fields of network layer RTP, UDP and IP headers are shown. Considering RTP, field 310 indicates the version of RTP used and does not change during the session. The field 311 comprises padding bits and does not change unless additional padding bits are included at the end of the header, e.g. for encryption algorithm purposes at the application layer. The field 312 indicates whether a fixed title is followed by a title extension and will not change during the session. The field 313 corresponds to the CSRC count required for multiplexing purposes, e.g. to indicate how many users constitute this payload. In many cases, this value will remain constant throughout the session. The field 315 represents the payload type and is constant for one type of data. In general, the constituent source and the synchronization source remain constant during transmission over the air interface, and thus field 318 will remain constant.

The field 314 includes a flag bit that is selectable to mark a significant event in the packet stream (e.g., the beginning of a speech burst or the last packet in a video frame). If the flag bit 314 is used, it needs to be sent in the compressed header. The field 316 representing the sequence number and the field 317 representing the timestamp will vary for all RTP packets.

Considering UDP, the field 321 representing the source port number and the field 322 representing the destination port number are used to separate different data flows related to the same application. For example, data and control information of the RTP layer can be communicated to different ports, i.e., different payload types can use different UDP port pairs. These fields will remain constant as long as the same type of data is being sent. The field 323 indicating the length of the UDP packet remains constant as long as the length of the RTP packet therein remains constant. In case the UDP length is changed during the whole session (video transmission), the length of this packet must be sent in a compressed header. The field 324 corresponds to a UDP checksum and is used to detect errors in transmission. This field does not have to be sent over a transmission link with a strong error protection mechanism or means to detect transmission errors (e.g., lower protocol layer checksums). In this embodiment, the SNDCP decompression function can, for example, calculate a checksum of the decompressed field and use the calculated checksum in decompressing the packet.

Considering IP, as long as a voice frame encoded at a constant bit rate is transmitted, it is assumed that a field 331 indicating the IP version, a field 332 indicating the header length, a field 333 indicating the service type, and a field 334 indicating the total packet length are kept constant. As long as segmentation is not used, it can be assumed that the field 336 representing these flags remains constant. The field 337 including the 13-bit fragmentation offset and the field 339 indicating the protocol are assumed to remain constant. The field 338 indicating the validity time and the field 340 indicating the checksum can be defined using SNDCP functions. During data transfer, the IP source and destination will remain constant and therefore it is assumed that the fields 341 and 342 representing the source IP address and destination IP address, respectively, remain constant. The identification field 335 is used primarily for IP packet fragmentation. This field need not be sent if fragmentation is not used. If fragmentation is used, SNDCP should first reconstruct this packet before compressing it.

Fields that are assumed to remain constant most of the time are combined into a set of unchanged fields. In this embodiment and in conjunction with speech frames from a constant bit rate encoder, this set would include the following fields: 310. 311, 312, 313, 315, 318, 321, 322, 331, 332, 333, 334, 335, 336, 337, 338, 339, 341, 342, 343. These fields will constitute the compression state maintained at least at the receiving (decompression) end of the link.

As described above, further, for the unchanged fields, a second set of fields whose contents can be derived from the received information can be omitted in the compressed header. Such fields have no effect on compression. Such fields are in the described embodiment fields 324 and 340 that include a checksum for checking the validity of the packet. These sums can be calculated from the decompressed data fields in the decompressor. The validity of these packets can be determined using a checksum of a lower level (e.g., access network level data unit).

The scheme according to the invention for managing the fields that vary for each packet is represented in general form in fig. 4, in which the functions in the receiving entity, in this embodiment the SGSN (also the decompressor) are represented. From the dialog, setup information (e.g., full header) needed for the compression state is received in the decompressor. To ensure that the correct compression state is used, a confirmation procedure can be included in the session setup signaling. In step 40, the compression state SoC is stored in the decompressor. In step 41 a dialog context is started in the decompressor comprising one or more context values Cj each related to a certain compression sequence. A packet is received from the sending entity, which in this case is the MS (also the compressor) (step 42). This packet includes a compressed data field Dcom. In case more than one context value (j > 1 maximum) is maintained, a set of decision rules for relating the received Dcom to the corresponding context value Cj is defined. A decision rule Dm matching the received Dcom is determined (step 43) and a decompressed value Dfu11 is derived from the value of the received Idcom and the determined context value Cm of Dm (step 44). One or more context values Cm are not updated or updated (step 45) to maintain this context data, depending on the expected evolution of the fields. This procedure is performed on new packets throughout the data transfer session.

The change fields sent in this embodiment are field 316 representing the RTP sequence number, field 317 representing the RTP timestamp, and field 335 representing the IP identification. The prior art delta coding (see previously transmitted packets) scheme can be suggested due to the recognition of the fact that the increments in these fields generally remain constant throughout the session. However, to avoid the problems described earlier, each network layer packet that is compressed is provided with a separate identification.

In the first embodiment, the header field is compressed into a thumbnail field and transmitted over the link. The length of this abbreviated field is selected to provide for the transmission of information that facilitates the correct identification of this packet during the compression sequence (i.e., an interval that is generally shorter than this conversation). The combination of short-term identification provided by the abbreviated field with longer-term context maintained in the decompressor provides consistent identification of packets throughout the data transfer session and thus enables explicit mapping of compressed header fields to full header fields throughout the data transfer session.

As one example of such an arrangement, a case of abbreviating the time stamp is described. Fig. 5 shows the format of a compressed header used in this embodiment. The field 51 indicates the type T of the compressed packet. If T ═ 0, the last octet 56 is not included and the last 6 bits 53 of the first octet are set to zero for other purposes, e.g. for a CRC check or for an abbreviated time stamp. If T ═ 1, the compressed header should include length octets, and bits 53 and the last octet 56 are used to indicate the length of the RTP payload. This length information is needed for bit streams, such as video bit streams, where the packet length can vary. The field 52 represents the flag bit of the RTP header as previously described. The abbreviated timestamp in this embodiment is a 16-bit field representing the 16 least significant bits of the RTP timestamp. The context data comprises the 16 most significant bits of the RTP timestamp and will remain at least on the decompressor side of the link.

The flow chart of fig. 6 represents the steps of an embodiment of the method of the present invention in which abbreviated time stamps are used. At step 61, the compressed state is received, as in this case the full time stamp TSfu11 is received at the beginning of the session. At the start of the dialog, context data is initialized, in this case TSmem1 includes the 16 least significant bits of the original timestamp and TSmem2 includes the 16 most significant bits of the original timestamp (step 62). In step 63 a new abbreviated time stamp of the 16 least significant bits of the time stamp transmitting the new compressed network layer data packet is received, TSabb, and this new abbreviated time stamp is compared with the value stored in the decompressor, TSmem 1. As will be appreciated later, the value of TSmem1 will include the 16 least significant bits of the largest timestamp received so far.

If the new abbreviated time stamp TSabb is larger than the stored value TSmem1, it is also checked whether this new abbreviated time stamp TSabb is larger than the sum of the stored value TSmem1 and the predefined value Δ. The value delta represents the largest change that can be interpreted as the least significant bit due to some expected phenomenon such as silence, a lost packet, or a packet arriving in a slightly wrong order. When the number of representations with the 16 least significant bits of this time stamp reaches a maximum, it is reset and starts again from the minimum value (compressed sequence). When a packet arrives late at the compressor, it is possible that the stored value TSmem1 has been wrapped around (wrap around) and therefore the value of the received abbreviated time stamp TSabb is significantly greater than TSmem 1. By defining an appropriate delta value, such a situation can be detected in the received packet stream. If the received abbreviated time stamp TSabb is greater than TSmem1 but not too great (less than Δ), the time stamp can be reconstructed using the 16 most significant bits stored in the value TSmem2 and combining this with the 16 least significant bits received from the compressor (step 64). The received abbreviated time stamp TSabb is the largest abbreviated time stamp received so far and is thus stored in TSmem 1. If the received abbreviated time stamp TSabb is greater than TSmem1 and the difference is greater than Δ, then it is assumed that the late-arriving TSabb and TSmem1 have been wrapped around. For these cases, another context data value TSmem3 is maintained in the context data for the previous compressed sequence. TSmem3 includes the previous stored value of TSmem 2. The reconstruction of the time stamp is now done with the 16 most significant bits stored in the value Tsmem3 and this is combined with the 16 least significant bits received from the compressor. The values of TSmem1, TSmem2, and TSmem3 are not updated.

If the value of the received abbreviated time stamp TSabb is less than the stored value TSmem1, it is checked whether the difference is greater than Δ. If this is the case, the abbreviated time stamp including the 16 least significant bits of this time stamp reaches a maximum, i.e., is wrapped around, and the stored value TSmem2 is incremented to the next possible value (step 67). After this, the time stamp can be reconstructed and the stored value TSmem1 can be updated as described with steps 64 and 65. For example, consider a case where the stored timestamp value is TSmem1 FF (hex), TSmem2 02FF (hex), Δ 0FFF (hex) and the received abbreviated timestamp value is TSabb 02FF (hex). Now the abbreviated time stamp value 000A is less than the stored time stamp value FF, the difference is greater than Δ and therefore the 16 most significant bits 02FF of TSmem2 must be updated with the 1-value 0300. The resulting timestamp value would thus be 0300000 a. If the difference is less than Δ, it indicates that the packet belongs to the current sequence, but it has a delayed arrival. In such a case, the time stamp can be reconstructed using the 16 most significant bits stored in the value TSmem2 and combined with the abbreviated time stamp TSabb received from the compressor. This value TSmem1 is not updated since this is not the largest abbreviated timestamp received so far. This procedure will be performed as soon as other new packets arrive.

This same idea can also be applied to other fields. For example, the entire sequence number of the RTP header is checked. If the original sequence number (in binary form) is 00010000, 00010001, 00010010, the abbreviated sequence number sent to the decompressor is 0000, 0001, 0010. Context data comprising at least the current most significant bits is maintained in the decompressor. With the same type of decision rule, the compressed data can be correlated with the compressed sequence in the decompressor and mapped to the full header field.

Other types of relationships between the compressed data and the increments used in the decompressor are also possible. For example, knowing that the timestamp can vary 240 for each packet, the increment of 1 in the compressor can be mapped to the increment of 240 in the decompressor, where (compressed value → decompressed timestamp):

0001 → 2400010 → 4800011 → 7200100 → 960, and so on.

As shown, the context content is updated based on the information in the received thumbnail field. The degree of the thumbnail (i.e., the number of bits used to represent the thumbnail field) has an effect on the rate at which the context information in the decompressor is updated. For example, the shorter the compression sequence, the more frequently the timestamp value TSmem2 storing the most significant bits of the timestamp must be updated. Even though some packets may be lost or their order may vary slightly, the validity comparison as described above is responsible for correctly regenerating this data. In a wireless connection, losing a long sequence of packets typically results in the dropping of an ongoing call. Thus, it is also possible to maintain consistent context information with a reasonable amount of compression in the decompressor as long as the connection is maintained. For example, with 6 bits it is possible to distinguish 64 packets. It is not possible to lose 64 consecutive packets while still maintaining the connection and therefore the inventive method will also be performed as long as the connection can be maintained.

For packets that may interfere with compression, e.g. packets that arrive very late at the compressor and thus may disturb the order in which the compression information is updated, it is preferable to provide another function in the compressor. Receiving a delayed packet in which the field to be abbreviated is detected to be at risk of causing an error in the compressed information will result in a corrective action already on the compressor side. Such packets may be discarded together, for example. For example, a packet arriving late but belonging to a previous compressed sequence can be recovered using the context value TSmem3, as described in connection with fig. 6. Packets belonging to a compressed sequence preceding the previous compressed sequence will no longer be correctly reproduced and therefore such packets are preferably already managed in the compressor. The flow chart of fig. 7 represents one example of such a filtering algorithm that can be added to the inventive method on the compressor side to manage a situation with many delayed packets.

At step 71 the entire timestamp of the first received packet is stored. When a new packet is received (step 72), its timestamp TSnew is read (step 73) and the difference between the stored timestamp TS and the new timestamp TSnew is calculated (step 74). If this difference D is greater than some predetermined value Dmax, the compressor will consider this packet to be too delayed and start corrective action (step 75). Such an action is for example sending the full field without sending the abbreviated field and including instructing the decompressor not to update this context data. Such action could also be simply discarding such a delayed packet. This will be a natural action in combination with real-time data packets, since packets arriving very late are in any case useless for the application and can therefore be discarded at the compressor side. If this difference D is not greater than Dmax, the time stamp TS is compressed according to the method of the invention. If the difference is greater than zero, it indicates that the packet arrives slightly delayed. Preferably, the stored value TS represents the maximum value of the time stamp transmitted so far, and therefore the value of the stored time stamp is not updated. If this difference D is less than zero, the value of the storage time stamp is updated (step 77). This procedure will be performed for each packet during the entire session.

In some cases the identification data can be compressed to a minimum in the compressed header and the compressed sequence will still span the entire conversation. Such embodiments include a mapping between fields of network layer and access network layer protocols. Network layer refers in this context to a packet data network level protocol layer, referred to in the illustrated embodiment as the IP, UDP and RTP protocols. The access network in this context refers to the access network specific protocol layers and is responsible for the compression and decompression functions, in this case SNDCP. The Packet Data Unit (PDU) of SNDCP contains an integer number of octets, a header portion and a data portion. Two different SN-PDU formats are defined, SN-DATA PDU for acknowledged DATA transfer and SN-UNITDATA PDU for unacknowledged DATA transfer. Fig. 8 shows the format of SNDCP SN-UNITDATA PDU used in unacknowledged transmission for GPRS. The SN-UNITDATA PDU includes a field N-PDU number 81 which is a running number that is incremented throughout the session.

A mapping between the network layer data packets and the data packets of the protocol layer responsible for compression can be generated. In this embodiment herein, a mapping between SNDCP SN-UNITDATA PDU field N-PDU number and RTP sequence number, IP identification and RTP timestamp is shown. The values in the RTP sequence number field 316 and the IP identification field 335 are typically increased by a value that is constant throughout the session when the N-PDU number is incremented by 1. Also, there is a codec for which the difference between subsequent RTP timestamps is constant. With hexadecimal representation, the following mapping is valid for the case where this difference is F0 and the increment of the RTP sequence number is 1 and for the case where the IP identification is 0100:

N-PDU No. 5

RTP sequence number 16C5

RTP time stamp 02FFBFEF

IP identification E7E6

Number N-PDU ═ 6

RTP sequence number 16C6

RTP timestamp 02FFC0DF

IP identification E8E6

N-PDU No. 7

RTP sequence number 16C7

RTP timestamp 02FFC1DF

IP identification E9E6

Although a constant increment is used here, the mapping can also be implemented in several other ways. For example, a mapping function between the access network layer protocol and the network layer protocol header field can be established. Also, depending on the application, a mapping between the access network layer protocol and other fields of the network layer protocol can be utilized. The context data in the decompressor comprises information required for mapping the access network layer protocol field to the network layer protocol field. The comparison step of the method shown in fig. 4 will include a simple validity check of the contents of the access network layer field. This context data preferably remains constant and thus requires no updating (see: step 45).

An alternative embodiment, shown in fig. 9, is suggested for network layer packets where the possibility exists that no change field changes during the session. Again, this embodiment is described with an example in which the sending entity is a MS and the receiving entity is an SGSN. In connection with the session establishment, the compressed state is stored in the ms (socc) and sgsn (socd) (step 91). Upon receiving a packet sent to the SGSN from the voice codec (step 9), it is checked (step 93) whether there is any change in the no-change field and the field of the compression status of the header to be compressed. If no change is detected, the header is compressed (step 94) and the compressed packet is sent to the decompressor (step 95) as previously described. However, upon detecting the change, the new SNDCP function will extract only the unchanged fields of the change from the new header (step 96), update these fields to the stored compressed state (step 97), send the values to the SGSN (step 98) and update these values to the compressed state also stored in the SGSN (step 98). The transmission of such information can be done with an acknowledged mode or strong error protection.

Any combination of these embodiments can be used in the compression/decompression algorithm. Next, an example of the use of the method of the present invention is given. Table 1 shows fields in the full header corresponding to the network layer protocols IP, UDP, IP. The shaded fields correspond to fields that remain constant throughout the dialog, while the white fields represent fields that may change during the dialog.

TABLE 1 examples of IP, UDP and RTP headers

It is assumed that this is the first RTP/IP/UDP header received in the SNDCP compressor. The values shown here are in hexadecimal format and a row has 4 octets. The first 5 rows (20 octets) represent IP headers. The next two rows are octets of UDP headers and the last 3 rows represent RTP headers, which together form a typical RTP/UDP/IP header (40 bytes). The SNDCP compressor should copy these values and send the entire header to the corresponding SNDCP unit.

Table 2 shows subsequent headers received with the compressor.

TABLE 2 Next IP/UDP/RTP header

Fields other than the stored values are indicated by shading in tables 1 and 2, and include

16-bit identification field of IP header:

from E7E6 to E8E6

16-bit header checksum of IP header:

from 63DC to 62DC

16-bit UDP checksum:

from AF5E to D440

Sequence number of RTP header:

from 16C5 to 16C6

Time-stamping of RTP header:

from 02FFBFEF to 02FFC0DF

The other fields remain the same. Now, the following compressed titles are generated according to the invention:

TABLE 3 compressed headers

Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
								T＝0	M＝0	0	0	0	0	0	0
1	1	0	0	0	0	0	0
								1	1	0	1	1	1	1	1

The format of the compressed header is the same as described in connection with fig. 5 and is represented in binary form. Since the length of the packet is not changed, the 7 th bit of the first octet is 0, the flag bit is 0, and the remaining bits in the first octet are 0 in this case. The next 2 octets contain an abbreviated time stamp (hexadecimal C0 DF). The SNDCP packets including the compressed header and the RTP payload are sent to a decompressor.

The entire time stamp is reproduced from the abbreviated time stamp value as previously described in connection with fig. 6. The N-PDU number of the SNDCP packet should be used as an offset to derive the sequence number of the RTP header and the 16-bit identification number of the IP header from the last full header. This algorithm correlates between the RTP sequence number and the N-PDU number of the SNDCP packet when the decompressor receives the first packet, which includes the entire header. In this case, the sequence number would be 16C5 and the N-PDU number is assumed to be x. When sending a compressed header, the SN-UNITDATA N-PDU number is y, which means that the difference between the N-PDUs is y-x and that number should be added to the stored sequence number.

As an example of a network element implementing the method described herein, a mobile terminal of a mobile communication system is described. The structure of the mobile terminal according to the present invention is a conventional mobile terminal that has been known to those skilled in the art for a long time so far. Referring to fig. 10, the central processing unit 101 controls the blocks responsible for the different functions of the mobile station: a memory (MEM)102, a radio frequency block (RF)103, a User Interface (UI)104, and an Interface Unit (IU) 105. The CPU is typically implemented using one or more functionally interactive microprocessors. This memory preferably comprises ROM (read only memory), RAM (random access memory) and is typically supplemented by memory with a SIM subscriber identity module. According to its program, the microprocessor uses the RF block 103 for sending and receiving messages on the radio path. The communication with the user is managed using the UI 104, which UI 104 typically includes a speaker, a display, and a keyboard. The interface unit 105 is a link to data processing entities and this unit 105 is controlled by the CPU 101. The data processing entity 101 may be an integrated data processor or an external data processing device.

Fig. 10 also shows the functional modules of the data processing entity TE according to the invention. The terminal equipment TE may be, for example, a personal computer or a workstation in an office environment as is known from the prior art. The TE may also be an integral part of the MS (e.g., smartphone) that shares elements such as UI and CPU with the MS. Conversely, the MS may be integrated in the TE (e.g., magnetic card telephone). It is recognized that even though two separate blocks are shown in fig. 10, the implication is not limited to this structure.

The TE roughly comprises an interface unit IU 107 corresponding to the MS to control the interface to this MS. This also includes a user interface UI 108 for receiving user instructions and outputting information to the user, a memory MEM 109 for storing application SW APP 110 and application related data, and a processor CPU 111 for controlling the operation of this TE and for completing these application programs.

There are several ways to connect the mobile station MS with the data processing entity, which are well known to the person skilled in the art. One approach is to interconnect the devices by an interface unit IU that includes a wired connection, an appropriate interconnect interface (e.g., serial port), and supplement with appropriate interface software in the CPU that controls the operation of the interface unit IU. Another approach is to utilize a wireless connection in the infrared wavelength range or to use a low power radio frequency transceiver unit. The new solution of MS integration in TE also provides a very feasible platform for the system according to the invention. When a user wants to access a packet data network with TE, the processor CPU 111 retrieves the packet data access application SW APP 110 from the memory MEM 109 according to instructions from the user input device. This application is processed in packet form in the CPU 111 and, once the application related information needs to be sent, the packet is delivered to the MS via the IU 107.

In a first embodiment, the compression and decompression functions are implemented in the SNDCP layer of the protocol stack of the mobile terminal. In the embodiment shown here, the units related to the SNDCP function are the units already described in the MS part. In the uplink direction, the MS acts as a compressor, while in the downlink the MS acts as a decompressor. The values for the compression and decompression operations are stored in the memory 102 of the MS. Compression is performed in the central unit 111 and transferred to the RF unit 102 for transmission to the SGSN via the BS. The compressed packets are received by the RF unit from the SGSN and passed to the CPU 111 for decompression. The decompressed packets are transferred to the TE through the interface units 105 and 107.

While the invention has been shown and described with respect to the preferred embodiments, those skilled in the art will recognize that changes may be made to the preferred embodiments without departing from the scope of the invention as hereinafter claimed. For example, GPRS or corresponding services (GPRS derivates) will also be implemented in the future for other mobile telecommunication systems. The third generation WCDMA (wideband code division multiple access) standard has a structure close to GPRS and includes a layer L3CE of SNDCP corresponding to GPRS. Such a layer for employing the functionality of the present invention is the SNDCF layer of CDMA 2000. It is also possible to apply the invention in fixed networks. Thus, the possibilities of implementing and using the invention are only restricted by the enclosed claims.

Claims (19)

1. A method for transferring a data packet from a compressor (MS) to a decompressor (SGSN), said data packet comprising a header with header data fields, a plurality of header data fields being stored in the decompressor (SGSN) which are kept constant during the data transfer, the method comprising:

transmitting from the compressor and receiving at the decompressor a data packet comprising information about one or more header data fields that change during the data transfer;

decompressing the header using the stored header data fields and the received information about the one or more header data fields that changed during the data transfer;

the method is characterized in that:

transmitting from the compressor and receiving at the decompressor a compression value for the header data field, the compression value identifying the data packets in the compressed sequence and being formed using a first number of least significant bits in the header data field;

maintaining in the decompressor context data comprising information for correlating the received compressed values with corresponding compressed sequences, the information being updated in accordance with the received compressed values;

the compressed value and information of the corresponding compressed sequence are used to map the compressed value into a decompressed header data field.

2. A method according to claim 1, characterized in that the compressed sequence comprises a set of consecutive data packets which can be distinguished from each other by the resolution provided by the compressed values.

3. A method according to claim 1 or 2, characterized in that the header is an RTP/UDP/IP header and the data field is one of the following: IP identification, RTP sequence number, RTP timestamp.

4. A method as claimed in claim 3, characterized in that the context data comprises at least a second number of most significant bits in the data field.

5. A method according to claim 1, characterized in that the compressor and decompressor are network elements of an access network to an IP packet data network.

6. A method according to claim 5, characterized in that the compressor and decompressor are network elements of a radio access network to an IP packet data network.

7. A method according to claim 6, characterized in that the compressor and decompressor are network elements of a GPRS-enabled mobile communication network.

8. A method according to claim 7, characterized in that the compression and decompression functions are implemented in the SNDCP layer of GPRS.

9. The method of claim 1, wherein said compressed value consists of said first number of least significant bits in the header data field.

10. A method according to claim 1, characterized in that after the session has been established, said compressed value relating only to the changed header data field is transmitted from the compressor and received at the decompressor, said compressed value consisting of said first number of least significant bits in the header data field.

11. An access network element (MS), comprising:

means (101, 103) for transmitting a data packet to a decompressor (SGSN), said data packet comprising a header with a header data field;

means (101, 103) for compressing the header by excluding from transmission header data fields that remain constant during data transfer;

means (101, 103) for sending a data packet to the decompressor comprising information about one or more header data fields that change during the data transfer;

the method is characterized in that:

means (101, 103) for transmitting a compression value identifying a header data field associated with a data packet in a compressed sequence, the compression value being formed using a first number of least significant bits in the header data field.

12. The access data network element according to claim 11, characterized by:

-means (101, 103) for receiving a data packet comprising an ordinal number, said ordinal number representing the order of this packet in a series of transmitted packets;

means (101, 103) for comparing the ordinal number of the received packet with an earlier stored ordinal number;

means (101, 103) for initiating an error function as a response to a difference between the ordinal number of the received packet and the compared ordinal number exceeding a predetermined limit;

means (101, 103) for initiating a header compression algorithm in response to the difference between the ordinal number of the received packet and the compared ordinal number being less than a predetermined limit;

means (101, 103) for storing the ordinal number of the received packet as the comparison ordinal number in response to the ordinal number of the received packet being greater than the comparison ordinal number.

13. An access network element according to claim 11, characterized in that the element is a mobile terminal of a mobile communication network.

14. An access network element according to claim 11, characterized in that the element is an SGSN of a GPRS enabled mobile communication network.

15. The access network element according to claim 11, characterised in that said compressed value consists of said first number of least significant bits in the header data field.

16. An access network element (MS), comprising:

means (101, 103) for receiving a data packet, the data packet comprising a header having a header data field;

-means (101, 102) for storing header data fields that remain constant during data transmission;

means (101, 103) for receiving a compressed data packet comprising information about one or more header data fields that change during data transmission;

means (101) for decompressing the compressed data packet using the stored header data fields and the received information about the one or more header data fields that changed during the data transfer;

the method is characterized in that:

means (101, 103) for receiving in a data packet a compression value identifying the data packet in a compressed sequence, the compression value being a first number of least significant bits in the header data field;

means (101, 102) for maintaining context data comprising information for correlating received compression values with corresponding compression sequences, said information being updated in dependence of the received compression values;

means (101, 102) for using the compressed value and information of the corresponding compressed sequence for mapping the compressed value to header data fields in the decompressed data packet.

17. An access network element according to claim 16, characterised in that the element is a mobile terminal of a mobile communication network.

18. An access network element according to claim 16, characterized in that the element is an SGSN of a GPRS enabled mobile communication network.

19. The access network element according to claim 16, characterised in that said compressed value consists of said first number of least significant bits in the header data field.