FI112141B - Non-transparent data transfer in a mobile network - Google Patents

Non-transparent data transfer in a mobile network Download PDF

Info

Publication number
FI112141B
FI112141B FI20011699A FI20011699A FI112141B FI 112141 B FI112141 B FI 112141B FI 20011699 A FI20011699 A FI 20011699A FI 20011699 A FI20011699 A FI 20011699A FI 112141 B FI112141 B FI 112141B
Authority
FI
Finland
Prior art keywords
link protocol
rlp
l2r
data
frames
Prior art date
Application number
FI20011699A
Other languages
Finnish (fi)
Swedish (sv)
Other versions
FI20011699A0 (en
FI20011699A (en
Inventor
Jukka Ala-Vannesluoma
Original Assignee
Nokia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corp filed Critical Nokia Corp
Priority to FI20011699 priority Critical
Priority to FI20011699A priority patent/FI112141B/en
Publication of FI20011699A0 publication Critical patent/FI20011699A0/en
Publication of FI20011699A publication Critical patent/FI20011699A/en
Application granted granted Critical
Publication of FI112141B publication Critical patent/FI112141B/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic or resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic or resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • H04W28/14Flow control between communication endpoints using intermediate storage
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/08Protocols for interworking or protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/08Access restriction or access information delivery, e.g. discovery data delivery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24Transfer of terminal data
    • H04W8/245Transfer of terminal data from a network towards a terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02Data link layer protocols

Abstract

A method of managing buffer memory in data transmission in a mobile communication system, comprising a radio link protocol and a link protocol for realizing said data transmission, for which radio link protocol at least two different frames of fixed lengths are defined, the method comprising: initiating a Remap during data transmission on the radio link protocol layer between said frames; transmitting the radio link protocol frames being the object of the Remap from the transmission buffer to the link protocol layer; unpacking the data contained in said frames into a remap buffer on the link protocol layer; and transmitting said radio protocol layer frames from a transmission buffer of the radio link protocol layer to the link protocol layer in the opposite order compared with storing said frames in the transmission buffer.

Description

1112141

Non-transparent data transmission over a mobile network

Field of the Invention

The invention relates to radio systems and in particular to non-transparent data transmission in a mobile communication system.

Background of the Invention

Mobile communication systems generally refer to various types of communication systems that enable personal wireless data transmission when subscribers move within the system. A typical mobile communication system is a terrestrial public mobile network (PLMN) (Public Land Mobile 10 Network).

In second and third generation mobile communication systems, such as GSM (Global System for Mobile Communication) and UMTS (Universal Mobile Telecommunication System) respectively, speech and data are transmitted in digital form. In addition to traditional voice telephony, there are many other services available in digital mobile communication systems: short messages, fax, data transmission, etc. The services of mobile communication systems can generally be divided into telecommunication services and bearer service. A network service is a telecommunication service that provides the transmission of signals between user network interfaces. For example, modem services and various data services are network service 20 and. For example, circuit switched data I 1 'services using different data rates up to 14.4 kbit / s are defined in the GSM mobile communication network.

«T · 'In HSCSD (High Speed Circuit

Switched Data) is already reaching tens of kilobits per second. In telecommunications service, the network also provides terminal services. Important telecommunication: *: 25 services are voice, fax and video text services.

Network services are usually grouped by feature, such as asynchronous network services and synchronous network services. For each: v. within such a group there are a number of online services such as transparent service], (T) and non-transparent service (NT). In the Transparent service, the data to be transmitted I t 30 is unstructured and the transmission errors are corrected only by channel coding. No-! The data to be transmitted in the transparent service is structured into data packets, i.e., protocol data units (PDUs), and transmission errors are corrected using (in addition to channel code,: data) automatic retransmission protocols. For example, GSM

«I

, ··, the system uses two protocols for non-transparent data transfer,

• I

35 RLP (Radio Link Protocol) and L2R (Layer 2 2 112141) diol link protocols

Relay). Such link protocols are also commonly referred to as Link Access Control (LAC).

The L2R layer places the data to be transmitted in L2R frames, which are transmitted to the RLP layer for transmission. In the GSM system, the RLP-5 layer supports multiple data rates, i.e., practically several different channel codings. To implement different data rates, the RLP layer has two RLP frames of different sizes in which to transmit the data: a 240 bit and a 576 bit RLP frame. If necessary, the RLP frame to be used for the data transmission connection must be able to be switched to another frame size during data transmission, whereby both the sender-RLP and the receiver-RLP must be re-synchronized. This is typically done by the recipient RLP announcing the next RLP frame number to be received, in response to which the sender RLP extracts the user data transmitted after said RLP frame from the transmission buffer and places it in new, second-dimension RLP frames. Of course, data can be transmitted in both directions; from mobile to network and from mobile to mobile. Thus, both the mobile station and the network, the receiver RLP from the counterparty RLP sender for, which is next expected to be received RLP frame number.

There are three different versions of the RLP protocol, versions 0, 1 and 2.

All three versions are used in the GSM system, only version 2 when operating in the UMTS system only. The data packets provided by the L2R layer for transmission to the RLP layer may comprise user data, padding. and status information comprising information defining the status of the data transmission. control information. The length of the data packet provided by the L2R layer to the RLP layer depends on the channel coding currently in use. When using the RLP protocol. In age versions 0 or 1, the status information should be sent in each L2R layer *, / data packet, but in RLP version 2, status information is only sent when the * * '· · *' data transfer status changes in some way.

The problem with the above arrangement is that, when using RLP-: ': 30 Version 2, after a status update sent from the terminal, a resynchronization request is received from the network almost immediately requesting RLP frames transmitted prior to the status update to be retransmitted. In this case \. a situation occurs where the terminal has already transmitted status information, but the network then requests to retransmit RLP frames comprising 35 status information. In this case, there may be a significant delay in the updating of the status information to the network side, especially if the amount of data to be retransmitted is 3,112,141 and the status information is transmitted substantially in the last frames. In this case, if the status update concerns, for example, Data Carrier Detection (DCD), which is transmitted with too long a delay, the data transmission may be completely interrupted.

5 Brief Description of the Invention

An object of the invention is to provide an arrangement whereby the terminal and the network have the same up-to-date information on the status of the terminal. The objects of the invention are achieved by a method, a mobile communication system and a device belonging to a mobile communication system, such as a mobile station or a base station bat, characterized by what is stated in the independent claims.

Preferred embodiments of the invention are claimed in the dependent claims.

The invention is based on the fact that the L2R layer status information is transmitted whenever a change in the length of the RLP frame occurs on the RLP layer as a result of a change in channel coding. In this case, the L2R level status information is preferably transmitted whenever the RLP frame length changes, regardless of when the status was last changed.

When the channel coding is changed, the terminal and the network start the re-synchronization of the transmitted RLP frames, i.e. the so-called. Remap process ·;. ·. process. Then the terminal and the network begin to retransmit their RLP frame. ·; ·, Comprised of data that is sent to the other party as receipts last '. after the specified RLP frame. In this case, the broadcast memory is copied to the opposite side has informed as last as receipts after the RLP frame transmitted | 25 RLP frames for the L2R layer, which decompresses the data contained in the frames into a buffer memory, where the data is then matched to user data fields of RLP frames of different sizes, preferably with the L2R level status information always attached to the first RLP frame to be transmitted to the network. : '*': status was last changed.

; According to a preferred embodiment of the invention, the L2R layer is arranged to interpret the first RLP frame transferred from the RLP transmission memory to the L2R layer so that the Remap process is initiated. This, respectively

I

'·; · Indicates to the L2R layer that L2R status information should be attached to the first RLP frame of different size:::: after the Remap process.

: "*; An advantage of the method and system of the invention is that the terminal always obtains up-to-date information about each other's L2R, 112141 4 status, which improves the efficiency of the data transmission and protocol structure. Further, it can advantageously be ensured that a problem situation in which the counterparty has obsolete L2R status information cannot occur. An advantage of an advantageous embodiment of the invention is that it can be ensured that whenever the 5 RLP frames are collected in the buffer memory during the Remap process, the first new-length RLP frame to be transmitted to the counterparty includes L2R status information.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in greater detail in connection with preferred embodiments 10 with reference to the accompanying drawings, in which: Figure 1 is a block diagram showing the structure of a GSM system; Figure 2 illustrates protocols and adaptations required for non-transparent network services; Fig. 3 is a signaling diagram illustrating a prior art problem in transmitting non-transparent data; Fig. 4 is a signaling diagram showing a Remap process according to an embodiment of the invention; and Figure 5 illustrates, in a signaling diagram, a plurality of successive Remap processes in accordance with another embodiment of the invention.

... 20 Detailed Description of the Invention * · · • · ·

The invention will now be described, by way of example, of GSM. non-transparent data transmission in the system. However, the invention is not limited to the GSM system, but can be applied to any mobile communication system having a similar type of non-transmitting parent data transmission service. In particular, the invention is feasible in connection with a third generation (3G) UMTS mobile communication system when using the so-called. duplex mobile stations operating in both GSM and UMTS networks.

Figure 1 illustrates the structure of a GSM system. The GSM system comprises mobile stations (MS, Mobile Station) which are in radio communication with Base Transceiver Station (BTS). A plurality of BTSs are connected to a Base Station Controller (BSC), which: •: · · * controls the available radio frequencies and channels by the BSC.

. * ··. The base station controller BSC and the associated base stations BTS form a Base Station Sub-system (BSS). In turn, the BSCs communicate with the Mobile Services Switching Center (MSC), which takes care of the connection and routing of calls to the correct addresses. Two databases containing information on mobile subscribers are used for this purpose: the Home Subscriber Register (HLR), which contains information on all subscribers of the mobile network and the services they subscribe to, and the Visitor Location Register (VLR), which contains information on mobile subscribers within a MSC. . The mobile switching center MSC is typically implemented with a Transcoder / Rate Adaptation Unit (TRAU), i.e., an Interworking Function (IWF), which decompresses the data placed in the TRAU frames and converts the data rate and frame structure so that the data can be forwarded. The mobile services switching center MSC, in turn, communicates with other mobile switching centers and the public switched telephone network (PSTN) through the gateway mobile services switching center (GMSC) 15. For a more detailed description of the GSM system, reference is made to the ETSI / GSM specifications and to The GSM System for Mobile Communications, by M. Mouly and M. Pautet, Palaiseau, France, 1992, ISBN: 2-957190-07-7.

When a non-transparent GSM data-20 connection is established with the mobile station MS, the data to be transmitted is placed in RLP (Radio Link Protocol) frames. The RLP is a frame-structured, balanced (HDLC type, High Level Data Link Controlled T: rol) data transmission protocol in which error correction is based on the distorted frames of the retransmission request of the receiving party. Because responsibility. . ·. the accuracy of the data to be transmitted is applied to one protocol layer, avoiding heavy signaling between the different elements of the data transmission chain. to ensure linguistic integrity. In the GSM system, communication adapted to the RLP frames takes place between the mobile terminal MS and / or the terminal adaptation function TAF (Terminal Adaptation Function) MT * ··· * and typically the relay function IWF comprising the mobile switching center MSC.

Figure 30 illustrates some protocols and functions required for non-transparent network services. The non-transparent circuit switched connection between the terminal adapter TAF and the network adapter IWF over a GSM traffic channel comprises a plurality of protocol layers common to all these services. For example, · ·

There are various rate adaptation functions RA (RAT) such as RAT

35 terminal adapters between the TAF and the CCU (Channel Codec Unit) in the base station system BSS, between the RA1 CCU and the Network Adapter IWF between R 112141 6, the RAA (or RAA 'for a 14.4 kbit / s channel) CCU and the base station between the placed transcoder unit TRAU, and the RA2 transcoder unit TRAU and the Network Adapter IWF. In addition, IWF and TAF have higher level protocols that are service specific. In an asynchronous non-trans-5 parent network service, the IWF and the TAF must include L2R (Layer 2 Relay) and RLP (Radio Link Protocol) protocols, in addition to which the IWF needs a modem or a speed adapter in the direction of the fixed network. The interface between the IWF and, for example, the MODEM audio modem is in accordance with CCITT V.24 and is indicated in FIG. 2 by the symbol L2. This non-transparent configuration 10 is also used to access the Internet.

The L2R layer places the data to be transmitted from the application in the L2R frames, which are transmitted to the RLP layer for transmission. In the GSM system, the RLP layer supports multiple data rates, i.e., practically several different channel codings. To implement different data rates, the RLP layer has 15 RLP frames of two different sizes in which to transmit the data: a 240 bit and a 576 bit RLP frame. If necessary, the RLP frame used for the data link must be able to be switched to another frame size during data transmission, whereby both the sender RLP and the receiver RLP must be re-synchronized.

There are three different versions defined for the RLP protocol, versions 0, 1, and 2. 20 GSM systems use all three versions, only UMTS only runs version 2. L2R layer RLP layer: ';'; the data packets provided to it for transmission may comprise user data, fill data, and status information comprising information defining the status of the data transmission. The length of the data packet provided by the L2R layer to the RLP layer depends on the channel coding currently in use. The status information may include, for example, information that the terminal is ready to receive and transmit data (DTR, Data Terminal Ready), a data bearer has been detected and a data link exists ( DCD, Data Carrier Detect), or vuonohjausin- formation, which is used to control the counterparty the right to transmit data to examples 30 to indicate a situation in which the receiving buffer starts to fill up.

The mobile station MS and / or the data terminal MT associated therewith use a data application to form a user-defined UDP (Point-to-Point Protocol) PPP header field and the L2R-specific data described above. . The data thus generated is further fitted into * '·' · 35 RLP frames, which can thus be 240 or 576 bits. The 240-bit RLP frames comprise a 16-bit header field, a 200-bit user data field 7 112141 frames comprise a 16-bit header field, a 200-bit user data field, and a 24-bit Frame Check Sequence (FCS) for detecting bearer errors. Such a 240-bit RLP frame is used in versions 0, 1 and also in versions 2 if the frame is transmitting un numbered proto-5 collision control information (U-frame). On the other hand, if the Version 2 RLP frame transmits either only control information (S-frame) or control information (1 + S frame) associated with user information, the corresponding field lengths are 24 + 192 + 24 bits. In 576-bit RLP frames, the lengths of the header fields may vary between 16 and 24 bits, respectively, with the user data field length 10 being 536 or 528 bits, respectively. The frame focus FCS is always 24 bits long.

The data rate applied to 240 bit RLP frames is either 4.8 or 9.6 kbit / s. The 576-bit RLP frame uses 14.4 kbit / s data rate. The data rate adaptation RA described above is performed for this data such that data is transmitted over the radio interface formed by the mobile station MS / MT to the base station BTS, always according to GSM specifications, in a single traffic channel slot at a rate of 22.8 kbit / s.

In the HSCSD concept of the GSM system, the high speed data signal is divided into separate data streams, which are then transmitted over N subchannels (N li-20 kennel channel slots) at the radio interface. Once the data streams are divided, they are transported in the subchannels as if they were independent, until: T: they are combined again in IWF or MS. However, logically, these N sub-i 'i'; the kennel channels belong to the same HSCSD connection, i.e. form one. . ·. HSCSD traffic channel. This data stream splitting and merging is performed in RLP according to version 2, which is therefore common to all subchannels. Below this common RLP, each of the subchannels is subjected to the same rate adjustments RAT-RAA-RA2 shown in FIG. 2 for a single traffic * ·· 'channel, between MS / TAF and MSC / IWF. Thus, the HSCSD traffic channel according to the GSM recommendations uses a common RLP for different subchannels, although on a single subchannel the data rate may be at least 43.2 kbit / s and the total data; ; 64 kbit / s.

Thus, the data rate of the traffic channel may vary according to the different channel codings and the number of HSCSD sub-traffic channels used, at least 4.8, 9.6, 14.4, 28.8 and 43.2 kbit / s. This channel coding and the RLP frame to be used must be interchangeable during data transmission. In this case, both the sender-RLP and the receiver-RLP need to be re-synchronized (remap).

In versions 0 and 1 of the RLP protocol, L2R level status information is transmitted in each RLP frame, which is 5 suboptimal for data transmission efficiency. In version 2, the L2R layer status information is transmitted in the RLP frame only when the status has changed on the L2R layer. This may cause a problem with RLP Version 2 data transmission when the network attempts to change the channel encoding used almost immediately after the status update sent from the terminal. This creates state-10 ones, where, almost immediately after the status update transmitted from the terminal, a resynchronization request is received from the network requesting RLP frames transmitted prior to the status update to be retransmitted at another frame length. This creates a situation where the terminal has sent new status information, but the network then requests to retransmit 15 RLP frames containing the old status information. If the terminal status does not subsequently change and the terminal thus does not send status information, incorrect information about the terminal status will remain on the network, which typically causes interruptions in data transmission before the status is updated again and in some cases may result in data interruption.

One such problem situation is illustrated below with reference to Fig. 3. Fig. 3 shows the data transmission between the L2R layer of the terminal: 'j' and the L2R layer of the base station. Initially, data transmission takes place in both directions: the terminal transmits to the network only user data packets (300) having the sequence number M1, and the network sends to the terminal only user data packets (302) having the sequence number N1. Terminal-. li recognizes the need to activate L2R-level flow control, which can typically * »« ♦ »occur, for example, when the receive buffer is full, and sends a data packet

I I

'·· (304, sequence number M2), which, in addition to the user data, includes a status update indicating that flow control must be activated. The network responds to this and stops transmitting L2R-level data packets to the terminal (306). The terminal continues transmitting user data packets (308, sequence number M3). For some time ,·! after this, the terminal transmits a data packet (310, sequence number Mn), which includes, in addition to user data, a status update indicating that the L2R flow control 'τ' can be deactivated. However, substantially immediately thereafter, the network realizes the need for channel coding change (312, Remap), as a result of which the base station transmits to the terminal an RLP frame of a different size than previously used, which also includes information on the last frame number received by the base station. After acknowledgments, the terminal begins to retransmit from the transmission buffer those frames that were not received by the base station, whose data contained in the frames is thus adapted to a new frame length. In this case, the base station typically has not yet received the flow control deactivation message, but only receives it in the new frame length matched data, which arrives at the base station with considerable delay. During this delay, from the network point of view, the flow control is still activated and the network is not allowed to send L2R data packets to the terminal, although the terminal 10 has made considerable efforts in the past to deactivate the flow control. A similar problem also arises in the opposite situation, where the terminal attempts to send a flow control activation message but is received by the network with considerable delay. In this case, the problem is even more pronounced as the terminal tries to prevent the network from transmitting data packets, but because of the 15 delays, the network does not receive a status update in time and, in the worst case, transmits several data packets.

In the situation described above, the flow control activation from the terminal was used as an example. However, a similar problem situation can occur with any other status update, such as when sending a DTR or DCD message, or when a base station-enabled flow control is active. Particularly, the problem is exacerbated if the transmitted status update relates to the detection of a data bearer, i.e., a DCD message. Doing so may delay the DCD status update too long. . ·, Interruption of data transmission.

However, this problematic situation can be avoided by the method of the invention, wherein the L2R layer status information is transmitted whenever the RLP layer undergoes a change in the length of the RLP frame as a result of the channel encoding change. Hereby, the L2R level status information is preferably transmitted each time the RLP frame length changes, regardless of whether the status is changed or not. This way, both the terminal and the network are always kept up-to-date.

The procedure of the invention may be illustrated by the signaling diagram of Figure 4, which illustrates the invention in simplified form; 'According to the RLP layer, the change in the length of the RLP frame as a result of a change in channel coding, i.e. a so-called. Remap process. In the initial state scheme of Figure 4, data is transmitted in an RLP layer in 240-bit RLP frames. The channel 11212141 transducing exchange originates from the network side, whereby the network transmits a 576-bit, frame only (S-frame) of control information to the terminal (400). The terminal notices that the frame length has changed and responds to this with a REMAP_command frame (402), which comprises the sequence number of the next 5 frames expected by the terminal. The network, in turn, responds to this with a REMAP_response frame (404), which comprises the sequence number of the next frame expected by the network. Subsequently, both parties, the terminal and the network start to retransmit data included in their RLP frames, which is sent to the other party most recently reported as receipts RLP-10 after frame. The process works similarly for both RLPs / L2Rs, but this is described below only from the terminal side.

The terminal transmission memory is copied to the other party after the last sent to be received by reported by the RLP frame of 240-bit RLP frames, the L2R layer (406), which decodes the data frames comprised in particular 15 to a buffer memory (408, remap buffer). Thereafter, whenever the RLP layer is able to send frames, the data in the buffer is mapped to the user data fields (410, Remap) of the 576-bit RLP frames. These 576-bit RLP frames can then be associated with L2R-level signaling, whereby the first 576-bit RLP frame to be transmitted to the network is always associated with L2R-level status information (412), regardless of when the status was last changed. In this case, the network is immediately aware of the current: T: L2R status of the terminal. Similarly, the network informs the terminal about the L2R status of the network. However, the implementation described above must take into account:. . · That the data transmitted in RLP frames may include L2R and BREAK_BREAK and BREAK_ACK messages indicating the termination of data transmission and * * *. which should always be sent at the same point in the data as originally located.

I. / Thus, the procedure of the invention advantageously ensures that '···' both the terminal and the network always receive up-to-date information on each other's L2R status, which improves the efficiency of data transmission and protocol structure. 30 ta. Further, it can advantageously be ensured that a problem situation such as the one described above, in which the counterparty has obsolete L2R status information, cannot occur.

According to a preferred embodiment, the L2R layer is arranged to interpret the first RLP frame transferred from the RLP transmission memory to the L2R layer, so that the Remap process is initiated. Similarly, this indicates to the L2R layer that the L2R status information should be appended to the first "112141

To the 576-bit RLP frame after the remap process. Thus, it can easily be ensured that whenever the RLP frames are collected in the Remap buffer during the Remap process, the first new RLP frame to be sent to the counterparty includes an L2R status path 5to. It should be noted that although the Remap process in the above example is described as a frame length change from a 240 bit to a 576 bit frame, the process of the invention can also be implemented from the 576 bit to 240 bit frame.

If the channel encoding used changes very quickly, and the new Remap process has to be started before the previous Re-map process has cleared all the buffer memory, it may be a problem to store the RLP frames transmitted in the new Remap process in the buffer memory previously stored in the buffer memory. frames are not lost.

According to a preferred embodiment, this can be avoided by extracting from the RLP transmission memory the RLP frames that have been defined as being retransmitted into the remap buffer from the end, i.e. in the reverse order they are in the RLP transmission memory. The data comprised in these RLP frames is thus decompressed by the L2R layer and stored in the buffer memory 20 starting from the last available memory locations in the buffer memory. This ensures that even if the channel coding changes several times within a short period of time, the data to be transmitted from the buffer memory is not lost. Thereafter, whenever the RLP layer is able to transmit frames, the L2R. the layer extracts data from the buffer memory from the first 25 stored locations and adapts it to channel coding to determine the RLP frame • · ^. a. At the L2R level, transmission continues from the buffer memory as long as the stored data is available for transmission, after which transmission is continued from the L · R level '··' normal data buffer, which comprises user data coming from the application level. After the RLP frames that have been assigned from the RLP transmission memory for retransmission to the L2R layer buffer memory are decompressed, the RLP layer no longer needs to know whether the data to be transmitted is fed from the L2R layer buffer memory or normal data buffer to the RLP frames.

This embodiment can advantageously ensure that the chickens are ''; '' the change of flash encoding during data transmission works regardless of how fast the next change is performed after the previous change of channel coding.

! I

12 112141

Also, the means used to decompress data, preferably software, can be implemented more simply.

This embodiment will now be described in more detail with reference to FIG. 5. To illustrate the embodiment, in state-5 of FIG. 5, data transmission is only in the uplink direction (from terminal to network). Initially, the terminal transmits 240-bit RLP frames (500, 504, 508) comprising both user data and control information (1 + S frame) and having sequence numbers (NS) of 1, 2 and 3, respectively. transmission memory as shown in the figure. The network transmits to the terminal only 240 bit RLP frames (502, 506) comprising 10 control information (S frame). However, after the third transmitted RLP frame, the terminal receives from the network only a 576-bit RLP frame (510) comprising control information (S frame), which thus initiates the Remap process. The terminal transmits a 576-bit REMAP_command message to the network (512) to which the network responds with a RE-15 MAP_response message (514), which includes the determination that the terminal must retransmit information comprised of the three RLP frames transmitted above in 576-bit RLP frames.

The terminal RLP layer initiates transferring said three RLP frames from the transmission memory to the L2R layer by first transmitting the last transmitted RLP frame (NS = 3), from which the L2R layer decodes the data contained therein and stores the data in the last memory location (516). ). After this: T, the second last transmitted RLP frame (NS = 2) is transmitted, the data of which is stored in the last available buffer memory, i.e. here. pause to the second to last memory location (518). Finally, the first transmitted RLP frame (NS = 1) is transmitted, the data of which is again stored in the last available buffer memory, in this case the third last memory location (520). Next, the L2R layer adapts buffer data to the 576-bit RLP frame, appends the L2R status information as described above, and sends it to the network (522). Next, the \: 30 terminal receives from the network a 240 bit RLP frame (524) comprising only control information (S frame), which thus initiates a new Remap process.

·. The terminal transmits a 240-bit REMAP_command message to the network (526) for which the network responds with a REMAP_response message (528), which includes a specification that the terminal must send the 576-bit RLP frame transmitted above. 35 in the 240 bit RLP frames.

• »13 112141

Previously, the data stored in the buffer memory did not fit completely into the previously transmitted 576-bit RLP frame, so there is still non-retransmitted data in the last memory location of the buffer memory (530). The terminal RLP layer transfers said 576-bit RLP frame from the transmission memory to the L2R layer, from which the L2R layer decodes the data contained therein and stores the data in the last available memory locations in the buffer memory so that data is not overwritten on previously stored buffer data (532). The L2R layer then begins mapping data from the buffer memory to the 240-bit RLP frames, the first of which is associated with the L2R status path 10 as described above, which is transmitted with the RLP frame to the network (534).

It will be obvious to a person skilled in the art that as technology advances, the basic idea of the invention can be implemented in many different ways. The invention and its embodiments are thus not limited to the examples described above, but may vary within the scope of the claims.

• · · <· t • »*» * • · • · 1 · »* t * ·

Claims (11)

  1. A method for updating status information which is included in data transmission in a mobile communication system, which for carrying out said data transmission comprises radio link protocols (RLP) and link protocols (L2R), for which radio link protocols are defined at least two different frames of a specified length for data transmission and which link protocol is arranged to convey status information as a definer data transfer, characterized by the initiation of re-synchronization between said frames (remap) during data transmission in the radio link protocol layer (RLP), indication of the initiation of said re-synchronization for the L-link protocol for the link protocol. L2R) current status information in the frame of the radio link protocol (RLP) that is transmitted only after said re-synchronization. 15
  2. Method according to claim 1, characterized by transmitting the frames of the radio link protocol (RLP) which are intended for said re-synchronization from a transmission buffer in the radio link protocol layer to the link protocol layer (L2R) and unpacking the data as said frame includes a .
  3. 3. A method according to claim 2, characterized by indicating the initiation of said re-synchronization for the link sample: the tocol layer (L2R) by means of the first frame transmitted from said transmission buffer. ·: ··: 25
  4. Method according to claim 2 or 3, characterized by ·: ··· transferring said frames for the radio link protocol (RLP) from the transmission buffer in the radio link protocol layer to the link protocol layer (L2R) in the opposite order as compared to the storage of said frames in transmission storing the data in said frames in the buffer memory in the link protocol layer (L2R) starting from the last free memory location.
  5. Method according to any one of claims 2-4, characterized in: ': arrangement of the data in said buffer memory in radio link protocol frames used after said re-synchronization and' ► ··· 'continuation of the data transfer from the transmit memory in the link protocol 112141 layer (L2R) after the data in said buffer memory has been transmitted.
  6. A mobile communication system comprising a mobile station and a base station, both of which are adapted to use radio link protocols (RLP) and link protocols (L2R) in data transmission, for which radio link protocols have at least two different frames of a specified length defined for data transmission and link protocols are arranged to convey status information defining data transmission, characterized in that re-synchronization between said frames (remap) during data transmission is arranged to be initiated in the radio link protocol layer (RLP) in the data transfer between the mobile station and said station, where is indicated for the link protocol layer (L2R) and the current status information of the link protocol (L2R) is arranged to be transmitted in the frame of the radio link protocol (RLP) transmitted only after said re-synchronization.
  7. Mobile communication system according to claim 6, characterized in that the frames of the radio link protocol (RLP) which are intended for said re-synchronization are arranged to be transmitted from a transmission buffer in the radio link protocol layer to the link protocol layer (L2R) and which data is mentioned as mentioned : T; buffer memory in the link protocol layer (L2R). : J:
  8. Mobile communication system according to claim 7, characterized by; ; *; not that the initiation of said re-synchronization is arranged to be indicated t) it; for the link protocol layer (L2R) using the first frame transmitted from said transmission buffer.
  9. The mobile communication system of claim 7 or 8, characterized in that: said radio link protocol (RLP) frames are arranged to be transmitted from the transmission buffer in the radio link protocol layer to the link protocol layer:. (L2R) in the opposite order as compared to the storage of said frames in transmission '. ···. the buffer and data in said frames are arranged to be stored in the buffer memory in the link-'1 'protocol layer (L2R) beginning from the last free memory location. I I 19 112141
  10. Mobile communication system according to any one of claims 7-9, characterized in that the data in said buffer memory is arranged to be arranged in radio-link protocol frames used after said re-synchronization and the data transfer from the transmit memory is arranged to be continued from the transmit memory in the transmit memory 2 in the link memory. said buffer memory has been transmitted.
  11. 11. Device in a mobile communication system, such as a mobile station or a base station, which device is adapted to use radio link protocols (RLP) and link protocols (L2R) in data transmission, for which radio link protocols are determined at least two different frames of a specified length for data transmission and which link protocol is arranged to convey status information defining data transfer, characterized in that said data transfer device is arranged to initiate synchronization between said frames (remap) during data transmission in the radio link protocol layer (RLP), arranged to be indicated for the link protocol layer (L2R) of said device and the current status information of the link protocol (L2R) is arranged to be transmitted in the frame of the radio link protocol (RLP) transmitted first from said device after said re-synchronization. »1» * 11 4 »*» t M 1 I> 11 * · »a t i t» 1 I> I * *
FI20011699A 2001-08-23 2001-08-23 Non-transparent data transfer in a mobile network FI112141B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FI20011699 2001-08-23
FI20011699A FI112141B (en) 2001-08-23 2001-08-23 Non-transparent data transfer in a mobile network

Applications Claiming Priority (16)

Application Number Priority Date Filing Date Title
FI20011699A FI112141B (en) 2001-08-23 2001-08-23 Non-transparent data transfer in a mobile network
US10/225,434 US7609715B2 (en) 2001-08-23 2002-08-21 Non-transparent data transmission in a mobile network
AT06120870T AT454774T (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
JP2003524221A JP4188829B2 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in mobile networks
PCT/FI2002/000689 WO2003019898A1 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
CA 2456353 CA2456353C (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
EP06120870A EP1744504B1 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
CN 02816473 CN1545791B (en) 2001-08-23 2002-08-22 Mobile communication system, equipment and method for updating state information in data trasmission
DE2002615953 DE60215953T2 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
KR20047002416A KR100611176B1 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
BRPI0212109A BRPI0212109B1 (en) 2001-08-23 2002-08-22 method, apparatus and mobile communication system for updating the status information contained in the data transmission
DE2002635052 DE60235052D1 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
AT02753110T AT345005T (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
ES02753110T ES2274988T3 (en) 2001-08-23 2002-08-22 Transmission of tansparent data in a mobile network.
EP20020753110 EP1419635B1 (en) 2001-08-23 2002-08-22 Non-transparent data transmission in a mobile network
HK05102424A HK1069267A1 (en) 2001-08-23 2005-03-21 Mobile communication system, and apparatus and method of updating status information contained in data transmission

Publications (3)

Publication Number Publication Date
FI20011699A0 FI20011699A0 (en) 2001-08-23
FI20011699A FI20011699A (en) 2003-02-24
FI112141B true FI112141B (en) 2003-10-31

Family

ID=8561786

Family Applications (1)

Application Number Title Priority Date Filing Date
FI20011699A FI112141B (en) 2001-08-23 2001-08-23 Non-transparent data transfer in a mobile network

Country Status (13)

Country Link
US (1) US7609715B2 (en)
EP (2) EP1744504B1 (en)
JP (1) JP4188829B2 (en)
KR (1) KR100611176B1 (en)
CN (1) CN1545791B (en)
AT (2) AT345005T (en)
BR (1) BRPI0212109B1 (en)
CA (1) CA2456353C (en)
DE (2) DE60235052D1 (en)
ES (1) ES2274988T3 (en)
FI (1) FI112141B (en)
HK (1) HK1069267A1 (en)
WO (1) WO2003019898A1 (en)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9288713B2 (en) * 2005-01-31 2016-03-15 Google Technology Holdings LLC Method and apparatus for dynamically changing modes of a reliable transport protocol
WO2007084134A1 (en) * 2006-01-23 2007-07-26 Semiconductor Components Industries, L.L.C. Communication circuit and method therefor
US8310996B2 (en) * 2006-08-07 2012-11-13 Qualcomm Incorporated Conditional scheduling for asynchronous wireless communication
US9008002B2 (en) 2006-08-07 2015-04-14 Qualcomm Incorporated Conditional requests for asynchronous wireless communication
US8416762B2 (en) * 2006-08-07 2013-04-09 Qualcomm Incorporated Message exchange scheme for asynchronous wireless communication
US8737313B2 (en) * 2006-08-07 2014-05-27 Qualcomm Incorporated Transmit time segments for asynchronous wireless communication
US8340027B2 (en) * 2006-08-07 2012-12-25 Qualcomm Incorporated Monitor period for asynchronous wireless communication
CN101577673B (en) * 2008-05-09 2012-07-11 中兴通讯股份有限公司 Flow control processing method
CN101345709B (en) * 2008-08-18 2012-02-22 中兴通讯股份有限公司 Method for implementing non-transparent data traffic switch and a TD-SCDMA terminal
US8565197B2 (en) * 2010-08-24 2013-10-22 Blackberry Limited System and method for uplink data transfer in dynamic timeslot reduction

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI97927C (en) * 1995-05-09 1997-03-10 Nokia Telecommunications Oy A non-transparent data transmission in a digital communication system
FI955944A (en) * 1995-12-11 1997-06-12 Nokia Telecommunications Oy The rate adaptation method and the speed of the adapter
FI107364B (en) * 1998-05-11 2001-07-13 Nokia Networks Oy Non-transparent data transmission in a mobile telephone network
FI108824B (en) 1998-06-03 2002-03-28 Nokia Corp Data transfer procedures in a telecommunications system
JP3595690B2 (en) 1998-08-06 2004-12-02 富士通株式会社 Fixed-length data processor
US6985470B1 (en) * 1998-08-10 2006-01-10 Nokia Networks Oy Data transmission in a telecommunication system
FI982854A (en) * 1998-12-31 2000-07-01 Nokia Networks Oy Data transmission in a communication system
US6286076B1 (en) * 1999-01-05 2001-09-04 Sun Microsystems, Inc. High speed memory-based buffer and system and method for use thereof
KR20000075358A (en) 1999-05-27 2000-12-15 윤종용 Variable-length data transmitting and receiving apparatus in accordance with radio link protocol for a mobile telecommunication system and method thereof
KR100621232B1 (en) 1999-10-11 2006-09-13 노키아 코포레이션 Synchronization method and apparatus
SE519221C2 (en) 1999-12-17 2003-02-04 Ericsson Telefon Ab L M Non-transparent communication where only data frames detected as correct forwarded by the base station
US6414938B1 (en) 2000-02-14 2002-07-02 Motorola, Inc. Method and system for retransmitting data packets in a communication system having variable data rates

Also Published As

Publication number Publication date
DE60215953T2 (en) 2007-04-05
EP1744504B1 (en) 2010-01-06
DE60235052D1 (en) 2010-02-25
CN1545791B (en) 2010-05-05
AT454774T (en) 2010-01-15
HK1069267A1 (en) 2010-07-30
CA2456353C (en) 2009-11-03
KR20040027915A (en) 2004-04-01
EP1744504A1 (en) 2007-01-17
EP1419635A1 (en) 2004-05-19
FI112141B1 (en)
FI20011699D0 (en)
AT345005T (en) 2006-11-15
US7609715B2 (en) 2009-10-27
FI20011699A0 (en) 2001-08-23
ES2274988T3 (en) 2007-06-01
DE60215953D1 (en) 2006-12-21
KR100611176B1 (en) 2006-08-09
CA2456353A1 (en) 2003-03-06
JP2005501480A (en) 2005-01-13
BR0212109A (en) 2004-08-24
WO2003019898A1 (en) 2003-03-06
US20030039269A1 (en) 2003-02-27
JP4188829B2 (en) 2008-12-03
CN1545791A (en) 2004-11-10
FI20011699A (en) 2003-02-24
BRPI0212109B1 (en) 2016-03-01
EP1419635B1 (en) 2006-11-08

Similar Documents

Publication Publication Date Title
EP2259498B1 (en) Dual mode subscriber unit for short range, high rate and long range, lower rate data communications
KR101141649B1 (en) method of transmitting and receiving control information for enhanced uplink data channel
DE60102809T2 (en) Data package numbering in the packaged data transmission
EP1833189B1 (en) Method and apparatus for efficient data retransmission in a voice-over-data communication system
US8767673B2 (en) Transmitting messages in telecommunications system comprising a packet radio network
EP0988742B1 (en) Internet access for cellular networks
ES2316361T3 (en) Notice of package discharge for semifiable retransmission protocol.
CA2331546C (en) Data transmission over a communications link with variable transmission rates
US7848287B2 (en) Bi-directional RLC non-persistent mode for low delay services
CA2440814C (en) Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
ES2272691T3 (en) Reubication of the context information in the compression of headings.
FI101332B (en) Epäjatkuvalähetys multi-channel high-speed data transfer
EP1252787B1 (en) Method for operating a mobile radiotelephone network
JP4164365B2 (en) Technology for improving TCP performance over a wireless interface by providing a dual proxy device
US6996079B1 (en) Handover and interworking in radio system
EP1256241B2 (en) Method for transmitting messages in a telecommunication network
CA2236231C (en) Method and system for providing data communication with a mobile station
JP4842480B2 (en) Improvement of wireless communication line protocol to reduce data call setup time
RU2289204C2 (en) Method and system for mobile communications
EP1353483B1 (en) Data flow control between a base station and a mobile station
JP3842335B2 (en) Method and apparatus for using data service of first communication system from terminal apparatus of second communication system
CN1820443B (en) Transmission of data packets from a transmitter to a receiver
KR100492959B1 (en) Short message service server and method in private mobile network interworking with public land mobile network
FI116185B (en) downtime
RU2461147C2 (en) Method of processing radio protocol in mobile communication system and mobile communication transmitter

Legal Events

Date Code Title Description
MM Patent lapsed