Multiplex communications – Communication techniques for information carried in plural... – Adaptive
Reexamination Certificate
2000-05-19
2003-03-04
Yao, Kwang Bin (Department: 2662)
Multiplex communications
Communication techniques for information carried in plural...
Adaptive
C370S349000, C370S471000
Reexamination Certificate
active
06529525
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to end-to-end transmission of packet based data, and in particular, the present invention relates to a method for implementing an acknowledgement cycle in a packet-switched transport layer.
BACKGROUND OF THE INVENTION
Global System for Mobile Communications (GSM) General Packet Radio Service (GPRS) is intended to allow a service subscriber the ability to send and receive data in an end-to-end packet transfer mode without utilizing network resources in the circuit-switched mode. GPRS permits efficient use of radio and network resources when data transmission characteristics are i) packet based, ii) intermittent and non-periodic, iii) possibly frequent, with small transfers of data, e.g. less than 500 octets, or iv) possibly infrequent, with large transfers of data, e.g. more than several hundred kilobytes. User applications may include Internet browsers, electronic mail and so on.
When GPRS carries commonly-used, reliable stream-oriented transmission control protocol (TCP) over internet protocol (IP), it is necessary that data flows in both directions between a mobile station and a base station. Current GPRS related methods for implementing a packet-switched radio layer in a stream-oriented data transmission from a remote host on a network to the mobile station generally include a downlink setup period and a data transfer period in one direction, and an uplink setup period and an acknowledge data transfer period in the opposite direction.
FIG. 1
is a schematic diagram of a complete packet data transfer in terms of the relative time required for implementing a GPRS packet-switched radio layer. As illustrated in
FIG. 1
, a data transfer phase
102
of a complete data transfer
100
is of longer duration than a setup phase
104
and a teardown phase
106
. The complete packet data transfer
100
is generally referred to as a temporary block flow (TBF), and is the basic atomic unit of a packet data abstraction. It is understood that the amount of time for the setup of a temporary block flow for GPRS varies, and is dependent on channel conditions, radio resource availability, network congestion and so on. This is in contrast to a mechanism that GPRS utilizes to perform the teardown phase, which is basically a form of one-way countdown signaling piggybacked in the data blocks from the sender.
Assuming a fixed amount of overhead for the period required to perform the setup phase, the amount of real overhead required varies depending on the size of the data payload, and therefore the length of time required to transmit this payload. The percentage of temporary block flow setup overhead is inversely proportional to the size of the payload, so that, for example, as the size of the payload increases, the percentage of temporary block flow setup overhead decreases.
FIG. 2
is a data flow diagram of a stream-oriented data transmission from a remote host on a network to a mobile station. As illustrated in
FIG. 2
, stream-oriented A data transmitted from a remote host is first divided into transmission control protocol (TCP) packets and given an internet protocol (IP) address at transport and network layers
120
, and sent to a base station protocol control unit
122
as a TCP/IP packet
124
. Assuming the mobile station corresponding to the address is camped on the network in packet idle mode, a temporary block flow associated with a downlink setup period
126
is initiated by protocol control unit
122
, so that downlink setup period
126
ends once the associated temporary block flow is ready. The time required for downlink setup period
126
in known GPRS systems can take between 849 ms and 2643 ms.
Once downlink setup period
126
is completed, a temporary block flow containing radio link control blocks is sent from protocol control unit
122
to a GPRS/EDGE subsystem
128
during a data transmission period
130
. The time required for data transmission period
130
in known GPRS systems is approximately 618 ms when a CS-1 coding scheme is used, and approximately 420 ms when a CS-2 coding scheme is used.
GPRS/EDGE subsystem
128
sends all of the data blocks corresponding to the temporary block flow in a single data packet
132
to transport and networks layers
134
, which responds to receipt of single data packet
132
by issuing a transmission control protocol acknowledge message
136
. A temporary block flow associated with a uplink setup period
138
cannot be initiated until a radio link control timer of protocol control unit
122
has expired, corresponding to timer expiration period
140
. The temporary block flow associated with uplink setup period
138
is initiated by GPRS/EDGE subsystem
128
, so that uplink setup period
138
ends once the associated temporary block flow is ready. The time required for initial uplink setup period
138
in known GPRS systems can take between 320 ms and 480 ms.
Once uplink setup period
138
is completed, a temporary block flow containing radio link control blocks is sent from GPRS/EDGE subsystem
128
to protocol control unit
122
during a data transmission period
142
, and protocol control unit
122
sends all of the data blocks corresponding to the temporary block flow in a single data packet
144
to transport and networks layers
120
. Once single data packet
144
is received, a next TCP/IP packet
146
is sent, and the process is repeated. The time required for data transmission period
142
in known GPRS systems is approximately 60 ms when a CS-1 coding scheme is used, and approximately 37 ms when a CS-2 coding scheme is used.
As can be seen in
FIG. 2
, a total period expended for the transmission of a single TCP/IP user data packet is equal to the sum of downlink setup period
126
, data transmission period
130
, timer expiration period
140
, uplink setup period
138
and data transmission period
142
. The amount of time associated with uplink setup period
138
(320-480 ms) is much greater than data transmission period
142
associated with transmission control protocol acknowledge message
136
(60 ms in a CS-1 coding scheme and 37 ms in a CS-2 coding scheme), and since it is necessary that uplink set period
138
be repeated for each TCP/IP user data packet, a significant portion of time is expended during uplink setup period
138
relative to the associated transmission control protocol acknowledge message
136
. As a result, an artificially long round trip transit time is required for transmission control protocol acknowledge message
136
, corrupting GPRS performance when an acknowledged transport layer protocol is used.
Accordingly, what is needed is a method for reducing repeated setup times on the acknowledgement cycle and on the time required for transmission of a single transport layer temporary block flow.
REFERENCES:
patent: 5063562 (1991-11-01), Barzilai et al.
patent: 6038606 (2000-03-01), Brooks et al.
patent: 6058106 (2000-05-01), Cudak et al.
patent: 6108522 (2000-08-01), Blanke
patent: 6118775 (2000-09-01), Kari et al.
patent: 6151696 (2000-11-01), Miller et al.
patent: 6182246 (2001-01-01), Gregory et al.
patent: 6208620 (2001-03-01), Sen et al.
patent: 6230296 (2001-05-01), Hanko et al.
patent: 6259724 (2001-07-01), Esmailzadeh
patent: 6272117 (2001-08-01), Choi et al.
patent: 6272148 (2001-08-01), Takagi et al.
patent: 6282182 (2001-08-01), Pecen et al.
GSM 04.60, “Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station (MS)—Base Station System (BSS) interface; Radio Link Control/Medium Access Control (RLC/MAC) protocol,” (European Telecommunications Standards Institute (ETSI); European Standard (Telecommunications series)).
Dorsey Donald
Otting Marcia
Pecen Mark E.
Motorola Inc.
Nguyen Hanh
Vaas Randall S.
Yao Kwang Bin
LandOfFree
Method for supporting acknowledged transport layer protocols... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for supporting acknowledged transport layer protocols..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for supporting acknowledged transport layer protocols... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3038067