Multiplex communications – Data flow congestion prevention or control
Reexamination Certificate
1999-07-14
2002-10-08
Hsu, Alpus H. (Department: 2665)
Multiplex communications
Data flow congestion prevention or control
C370S236000
Reexamination Certificate
active
06463034
ABSTRACT:
BACKGROUND OF THE INVENTION
I. Field of the Invention
The present invention relates to the field of wireless data services. More particularly, the present invention relates to a novel and improved method and system for preventing data loss during a Point-to-Point Protocol (PPP) renegotiation over a U
m
interface between a wireless communication device (MT
2
) and a base station/mobile switching center (BS/MSC).
II. Description of Related Art
Internetworking, i.e., the connection of individual local area networks (LANs), has rapidly become very popular. The infrastructure and associated protocols commonly referred to as the “Internet” have become well known and widely used. A well known protocol for providing access to the Internet is the Point-to-Point Protocol (PPP) which provides a standard method for transporting multi-protocol datagrams over point-to-point, and is further described in Request for Comment (RFC) 1661, W. Simpson, Editor, dated July 1994, herein incorporated by reference.
PPP includes three main components:
1. a method of encapsulating multi-protocol datagrams;
2. a Link Control Protocol (LCP) for establishing, configuring, and testing a data link connection; and
3. a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
FIG. 1
illustrates a high-level block diagram of a wireless data communication system in which a mobile terminal (TE
2
device)
102
communicates with an interworking function (IWF)
108
via a wireless communication system which includes a wireless communication device (MT
2
)
104
and Base Station/Mobile Switching Center (BS/MSC)
106
. In
FIG. 1
, the IWF
108
serves as the access point to the Internet. IWF
108
is coupled to, and often co-located with BS/MSC
106
, which may be a conventional wireless base station, as is known in the art. TE
2
device
102
is coupled to MT
2
device
104
, which is in wireless communication with BS/MSC
106
and IWF
108
.
Many protocols exist which allow data communication between the TE
2
device
102
and the IWF
108
. For example, Telecommunications Industry Association (TIA)/Electronics Industries Association (EIA) Interim Standard IS-707.5, entitled “Data Service Options for Wideband Spread Spectrum Systems: Packet Data Services,” published February 1998, and herein incorporated by reference, defines requirements for support of packet data transmission capability on TIA/EIA IS-95 wideband spread spectrum systems, of which BS/MSC
106
and IWF
108
may be a part. IS-707.5 also provides the requirements for communication protocols on the links between the TE
2
device
102
and the MT
2
device
104
(the R
m
interface), between the MT
2
device
104
and the BS/MSC
106
(the U
m
interface), and between the BS/MSC
106
and the IWF
108
(the L interface).
Referring now to
FIG. 2
, a diagram of the protocol stacks in each entity of the IS-707.5 Relay Model is shown.
FIG. 2
corresponds roughly to FIG.
1
.
4
.
2
.
2
-
1
of IS-707.5. At the far left of the figure is a protocol stack, shown in conventional vertical format, showing the protocol layers running on the TE
2
device
102
(e.g., the mobile terminal, laptop or palmtop computer). The TE
2
protocol stack is illustrated as being logically connected to the MT
2
device
104
protocol stack over the R
m
, interface. The MT
2
device
104
, is illustrated as being logically connected to the BS/MSC
106
protocol stack over the U
m
interface. The BS/MSC
106
protocol stack is, in turn, illustrated as being logically connected to the IWF
108
protocol stack over the L interface.
As an example of the operation of the protocols of
FIG. 2
, the Point to Point Protocol (PPP
R
) protocol
206
encodes packets from the upper layer protocols
202
,
204
and transmits them across the R
m
interface using the EIA-232 protocol
208
to the EIA-232-compatible port on the MT
2
device running the EIA-232 protocol
210
. In addition to using the EIA-232 protocol, other protocols may also be used, e.g. USB/IRDA/Bluetooth may be used. The EIA-232 protocol
210
on the MT
2
device, receives the packets and passes them to the PPP
R
protocol
205
. The PPP
R
protocol
205
unframes the packets encapsulated in PPP frames and typically, when a data connection is up, passes the packets to PPP
U
protocol
215
, which frames the packets in PPP frames for transmission to a PPP peer located in the IWF (
108
). The Radio Link Protocol (RLP)
212
and IS-95 protocol
214
, both of which are well known in the art, are used to transmit the packets, which are encapsulated in PPP frames, to the BS/MSC
106
over the U
m
interface. RLP is a family of radio link protocols. The RLP protocol
212
is defined in IS-707.2, entitled “Data Service Options for Wideband Spread Spectrum Systems: Radio Link Protocol”, February 1998, herein incorporated by reference, and the IS-95 protocol is defined in IS-95 mentioned above. A complementary RLP protocol
216
and IS-95 protocol
218
in the BS/MSC
106
pass the packets to the relay layer protocol
220
for transmission across the L interface to relay layer protocol
228
. PPP
U
protocol
226
then unframes the received packets and passes them to the network layer protocols
225
, which in turn passes them to upper layer protocols
221
. As is well known to those skilled in the art, instead of using the RLP protocol, the RLP
2
protocol could be used. It is defined in Telecommunications Industry Association (TIA)/Electronics Industries Association (EIA) Interim Standard IS-707A.8, entitled “Data Service Options for Spread Spectrum Systems: Radio Link Protocol Type
2
,” published April 1999. Other RLP protocols which may be used are RLP3 and RLP for CDMA2000.
As described in RFC 1661, the LCP Packets comprise a Configure-Request, a Configure-Ack, a Configure-Nak, and a Configure-Reject. The format of these packets is well known and described in RFC 1661.
The Configure-Request packet is used to negotiate configuration options. All configuration options are always negotiated simultaneously.
The Configuration-Ack packet is transmitted if every configuration option in a received Configuration-Request packet is recognizable and all values are acceptable.
The Configure-Nak packet is sent in response to a Configuration-Request packet when the requested configuration options are recognizable, but some of the values are not acceptable. The Options field of the Configure-Nak packet are filled only with the unacceptable configuration options from the Configure-Request packet. Note that all configuration options are always Nak'd simultaneously.
The Configure-Reject packet is sent when a received Configure-Request includes configuration options that are unrecognizable or are not acceptable for negotiation. The options field of the Configure-Reject contains only the unacceptable configuration options from the Configure-Request.
The following comprises the well-known configuration options, described in RFC 1661, and defined for the PPP LCP protocol:
1. Maximum-Receive-Unit
2. Authentication-Protocol
3. Quality-Protocol
4. Magic-Number
5. Protocol-Field-Compression
6. Address-and-Control-Field-Compression
Internet Protocol Control Protocol (IPCP) is a network control protocol responsible for configuring, enabling, and disabling Internet Protocol (IP) modules on both ends of the PPP link. IPCP is described in Request for Comment (RFC)
1332
, “The PPP Internet Protocol Control Protocol (IPCP)”, G. McGregor Merit, May 1992, herein incorporated by reference. IPCP configuration options include:
1. IP-Addresses;
2. IP-Compression-Protocol; and
3. IP-Address
IPCP uses the same option negotiation mechanism as the Link Control Protocol (LCP).
LCP and IPCP Configuration option negotiations occur separately for both the R
m
interface and the U
m
interface. That is, LCP or IPCP configuration option negotiation over one of the R
m
and U
m
interfaces is separate from LCP or IPCP configuration option negotiation over the other of the R
m
and U
m
interfaces. Therefore, the wire
Abrol Nischal
Lioy Marcello
Brown Challos D.
Hsu Alpus H.
Nguyen Toan
Pappes George C.
Qualcomm Incorporated
LandOfFree
Method and apparatus for avoiding data loss during a PPP... 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 and apparatus for avoiding data loss during a PPP..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for avoiding data loss during a PPP... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2929923