Abstract:
A method, within a wireless communication system, and a wireless MT2 device which provide for the resynchronization of a PPP link on each one of a U m  and R m  interface without affecting the other of the U m  and R m  interface. When a handoff is performed, such that the communications of the mobile MT2 device is handed off to a new BS/MSC, the U m  interface will undergo PPP configuration renegotiation without causing the R m  interface also to undergo PPP configuration renegotiation. Similarly, when the R m  interface undergoes PPP configuration renegotiation, the U m  interface will not undergo PPP configuration renegotiation.

Description:
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 resynchronizing a Point-to-Point Protocol (PPP) link over a U m  interface between a wireless communication device (MT 2 ) and a base station/mobile switching center (BS/MSC) without affecting a R m  interface between the wireless communication device (MT 2 ) and a TE 2  device. 
     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, Network Working Group, W. Simpson, Editor, 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 may be a cellular phone), 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 . The present invention is not intended to be limited to a system that uses the EIA-232 protocol since, as is well known, other suitable protocols such as USB are also available. 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. The RLP protocol  212  is defined in Telecommunications Industry Association (TIA)/Electronics Industries Association (EIA) Interim Standard 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 sends them out on the Internet to the designation server. 
     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&#39;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)”, Network Working Group, 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 wireless communication device (MT 2 ) must separately negotiate configuration options over the R m  and U m  interfaces. 
     Because the wireless communication device (MT 2 ) is mobile, the wireless communication device (MT 2 ) may move to an area that is served by a different BS/MSC  106  or a different IWF  108 . When this happens, a handoff will occur, handing the MT 2  device over to the new BS/MSC  106  or a new IWF  108  for service. When a handoff occurs, the LCP and IPCP links must be renegotiated over the U m  interface, as discussed above. Because PPP negotiation for the R m  and U m  interfaces are independent, PPP renegotiation need only occur on the U m  interface. 
     Under some circumstances, the TE 2  device may initiate PPP renegotiation. However, it may be unnecessary to perform PPP renegotiation on the U m  interface when PPP renegotiation occurs on the R m  interface. 
     SUMMARY OF THE INVENTION 
     The invention is a method, within a wireless communication system, and an MT 2  device which provide for the resynchronization of a PPP link on one of a U m  and R m  interface without affecting the other of the U m  and R m  interface. 
     Thus, when a handoff is performed, such that the mobile MT 2  device is handed off to a new BS/MSC, the U m  interface may undergo PPP configuration renegotiation without causing the R m  interface also to undergo PPP configuration renegotiation. 
     Similarly, the R m  interface may undergo PPP configuration renegotiation without causing the U m  interface also to undergo PPP configuration renegotiation. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING 
     These and other advantages will become more apparent from the detailed description of the preferred embodiments along with the following drawings: 
     FIG. 1 illustrates a high-level block diagram of a wireless data communication system in which a terminal device connects to a network, such as the Internet, via a wireless communication device; 
     FIG. 2 is a diagram of the protocol stacks of each entity; 
     FIG. 3 is a state transition diagram which illustrates the state transitions for a first aspect of a preferred embodiment of the invention; 
     FIG. 4 illustrates the operation of the invention when the U m  interface is renegotiated; 
     FIG. 5 is a state transition diagram which illustrates the state transitions for a second aspect of a preferred embodiment of the invention; 
     FIG. 6 illustrates the operation of the invention when the R m  interface is renegotiated. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     As is known in the art, in order to establish communications over a point-to-point (PPP) link, Link Control Protocol (LCP) packets for establishing, configuring and testing the data link connection must be exchanged over each PPP link, i.e., the R m  and U m  interfaces. Any options not negotiated use a predefined default value, as specified by RFC 1661. 
     Similarly, IPCP packets for negotiating and configuring IPCP configuration options must be exchanged over the R m  and U m  interfaces. Any options not negotiated use a predefined default value, as specified by RFC 1332. 
     As described in RFC 1661 and RFC 1332, LCP Packets and IPCP 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 and RFC 1332, respectively. 
     Configuration option negotiations may occur separately for both the R m  interface and the U m  interface. As described in RFC 1661 and RFC 1332, the Configure-Request packet contains a list of the options being requested and the Configuration-Ack packet contains a list of the options which the sender is acknowledging. 
     In order to simplify processing and achieve greater efficiency of processing it is preferable that, as a result of renegotiating the PPP options, the newly negotiated options are the same as the PPP options used prior to renegotiation. However, this is not a requirement. In the event that the newly negotiated PPP options are not the same as the PPP options used prior to renegotiation, the MT 2  device would be required to perform additional processing such as described in copending patent application “Selectively Unframing and Framing PPP Packets Depending On Negotiated Options of the Um and Rm Interfaces”, inventors Marcello Lioy and Nish Abrol, assigned to the same assignee (attorney docket D1275). 
     Because the wireless communication (MT 2 ) device  104  is typically mobile, communications between the MT 2  device  104  and a BSC/MSC  106  will be handed off to another BSC/MSC  106 , as necessary depending on the location of the MT 2 . Handoff techniques are well known in the art. When a handoff occurs, the PPP U m  interface must be renegotiated. That is, the LCP and the IPCP configuration options must be renegotiated over the U m  interface. However, it is not necessary to renegotiate the PPP configuration options over the R m  interface when the U m  interface is renegotiated. 
     In the preferred embodiment, the MT 2  device will attempt to simultaneously negotiate both the R m  and the U m  interfaces by monitoring the received LCP and IPCP configuration request packets on one of the R m  and U m  interfaces, examining the LCP and IPCP configuration packets, and if the requested options are supported by the MT 2  device, transmitting the received LCP or IPCP configuration request packet on the other of the R m  and U m  interfaces. 
     FIG. 3 illustrates a state transition diagram of a first aspect of the invention. Initially, PPP is in the Out of Call state, shown at reference numeral  300 . When an LCP packet is received in the MT 2  device  104  from either the U m  or R m  interface, PPP enters the R m  and U m  PPP Initialization state, shown at reference numeral  310 . In this state, option negotiation occurs on both the R m  and U m  interfaces. When LCP configuration negotiations are complete, then IPCP configuration negotiations are performed. When IPCP negotiations are completed, PPP enters the PPP Up state, shown at reference numeral  320 . 
     While in the PPP Up state, if an LCP or IPCP Configure-Request packet is received on the R m  interface, PPP enters the R m  and U m  PPP Initialization state, and option negotiations take place on both the R m  and U m  interfaces. 
     While in the PPP Up state it may be necessary to renegotiate PPP over the U m  link. Indication that this is necessary may come in several forms; it could come from the cellular network, for example, in a CDMA network it could be indicated by a new packet zone ID or new SID/NID. It could also come in the form of an LCP configure request or an IPCP configure request. If the indication comes from the cellular network the U m  PPP in the phone can initiate the renegotiation, otherwise no special action needs to be taken. Upon receiving an indication that renegotiation is necessary the PPP Resync state is entered, shown at reference numeral  330 . In the PPP Resync state, the MT 2  device  104  will renegotiate the LCP and IPCP options. When IPCP option negotiations are completed, the PPP Up state is again reentered and data transfer may take place. 
     FIG. 4 provides an example of the operation of the present embodiment. After option negotiation is completed on both the R m  and U m  interfaces, data transfer may take place. At reference numeral  410 , the BSC/MSC  106  sends an LCP Configure-Request packet, over the U m  interface, to the MT 2  device  104 . At reference numeral  412 , the MT 2  device receives the LCP Configure-Request packet while in the PPP Up state, enters the PPP Resync state, and at reference numeral  414 , sends a LCP Configure-Ack packet. At reference numeral  416 , the MT 2  device sends a LCP Configure-Request packet and, at reference numeral  418 , the MT 2  device receives an LCP Configure-Ack packet from the BS/MSC  106 . At this point the LCP configuration options for both ends of the U m  interface have been successfully negotiated. Note that FIG. 4 would have to be modified if the MT 2  were to initiate the renegotiation. 
     At reference numeral  420 , the BS/MSC sends an IPCP Configure-Request packet to the MT 2  device. At reference numeral  422 , the MT 2  device receives the IPCP Configure-Request packet and, at reference numeral  424 , responds with an IPCP Configure-Ack packet. At reference numeral  426 , the MT 2  device sends an IPCP Configure-Request packet. At reference numeral  428 , the MT 2  device receives an IPCP Configure-Ack packet from the BS/MSC. At this point IPCP negotiations are complete and the MT 2  device enters the PPP Up state. Thus, the U m  interface has been renegotiated without affecting the R m  interface. 
     FIG. 5 illustrates a state transition diagram for a second aspect of the invention. LCP and IPCP option negotiations on one of the R m  and the Un interface do not affect the other of the R m  and U m  interface. 
     Initially, PPP starts at the Out of Call state, shown at reference numeral  500 . When an LCP Configure-Request packet is received on either the R m  or the U m  interface, then PPP enters the R m  and U m  PPP Initialization state, as shown at reference numeral  510 . When IPCP option negotiations are completed, PPP enters the PPP Up state, shown at reference numeral  520 . 
     When either an LCP or an IPCP Configure-Request packet are received over the R m  or the U m  interface while in the PPP Up state, then PPP enters the PPP Resync state, shown at reference numeral  530 . When IPCP completes option negotiation on the R m  or the U m  interface while in the PPP Resync state, then PPP enters the PPP Up state. 
     FIG. 6 shows a PPP option negotiation over the R m  interface not affecting the U m  interface. After option negotiation is completed on both the R m  and U m  interfaces, data transfer may take place. At reference numeral  610 , the TE 2   102  device sends an LCP Configure-Request packet, over the R m  interface, to the MT 2  device  104 . At reference numeral  612 , the MT 2  device receives the LCP Configure-Request packet while in the PPP Up state, enters the PPP Resync state, and at reference numeral  614 , sends a LCP Configure-Ack packet. At reference numeral  616 , the MT 2  device sends a LCP Configure-Request packet and, at reference numeral  618 , the MT 2  device receives an LCP Configure-Ack packet from the TE 2  device  102 . At this point the LCP configuration options for both ends of the R m  interface have been successfully negotiated. 
     At reference numeral  620 , the TE 2  device sends an IPCP Configure-Request packet to the MT 2  device. At reference numeral  622 , the MT 2  device receives the IPCP Configure-Request packet and, at reference numeral  624 , responds with an IPCP Configure-Ack packet. At reference numeral  626 , the MT 2  device sends an IPCP Configure-Request packet. At reference numeral  628 , the MT 2  device receives an IPCP Configure-Ack packet from the TE 2  device. At this point IPCP negotiations are complete and the MT 2  device enters the PPP Up state. Thus, the R m  interface options have been negotiated without affecting the U m  interface. 
     While this invention has been described in connection with what is presently considered to be the preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.