MXPA01008593A - Simultaneous setup of ppp on a um and rm interface - Google Patents

Simultaneous setup of ppp on a um and rm interface

Info

Publication number
MXPA01008593A
MXPA01008593A MXPA/A/2001/008593A MXPA01008593A MXPA01008593A MX PA01008593 A MXPA01008593 A MX PA01008593A MX PA01008593 A MXPA01008593 A MX PA01008593A MX PA01008593 A MXPA01008593 A MX PA01008593A
Authority
MX
Mexico
Prior art keywords
configuration
packet
interface
recognition
wireless communication
Prior art date
Application number
MXPA/A/2001/008593A
Other languages
Spanish (es)
Inventor
Lioy Marcello
Mischal Abrol
Original Assignee
Qualcomm Incorporated
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 Qualcomm Incorporated filed Critical Qualcomm Incorporated
Publication of MXPA01008593A publication Critical patent/MXPA01008593A/en

Links

Abstract

A method and a wireless communication device (MT2) (104) for simultaneously negotiating LCP or IPCP configuration options over both the Rm and the Um interfaces. When the MT2 device (104) receives either an LCP or an IPCP Configure-Request packet over one of the Rm or the Um interfaces, the MT2 device parses the requested configuration options (S310, S510) and determines whether the requested options are supported (S320, S320) by the MT2 device. If the requested options are supported, the MT2 device saves a Configure-Request ID (S360, S560), included in the Configure-Request packet, and frames the Configure-Request packet in a PPP frame for transmission on the other of the Rm or the Um interfaces. If any of the requested configuration options are not supported by the MT2 device, the MT2 device creates a Configure-Reject packet (S330, S530), including the unsupported options, and frames the Configure-Reject packet in a PPP frame for transmission over the interface through which it received the Configure-Requestpacket.

Description

SIMULT.ANEA PROVISION OF PPP ON AN UM AND RM INTERFACE 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 establishing a Point-to-Point Protocol (PPP) link between a terminal equipment (TE2) and a base station / center interworking (IWC) function. mobile switching (BS / MSC) through a wireless communication device.
II. Description of the Related Art Interconnection, that is, the connection of individual local area networks (LANs), has quickly 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) that provides a standard method for transporting multiple protocol datagrams over point-to-point links, and is further described in Request for Com ent (RFC) 1661 ,.
Simpson, Editor, dated July 1994 incorporated herein for reference. PPP includes three main components: 1. a method to encapsulate multiple protocol datagrams; 2. a Link Control Protocol (LCP) to establish, configure, and test a data link connection; and 3. a family of Network Control Protocols (NCP) to establish and configure different network level protocols. FIGURE 1 illustrates a high-level block diagram of a wireless data communication system in which a mobile terminal 102 (device TE2) communicates with an interconnection function 108 (IWF) by a wireless communication system that includes a wireless communication device 104 (MT2) and Base Station / Mobile Switching Center 106 (BS / MSC). As used in this MT2, it may refer to a telephone or a combination of a telephone and a PCM CIA card. In FIGURE 1, the IWF 108 serves as the access point to the Internet. The IWF 108 is coupled and often co-located with the BS / MSC 106, which may be a conventional wireless base station, as is known in the art. Device 102 of TE2 is coupled to device 104 of MT2, which is in wireless communication with BS / MSC 106 and IWF 108. Many protocols exist which allow data communication between device 102 of TE2 and IWF 108. For example, the Association of the Telecommunications Industry (TIA) / Electronic Industries Association (EIA) Interim Standard IS-707.5, entitled "Data Service Options for Wideband Spread Spectrum Systems: Packet Data Services", published in February 1998, and which is incorporated herein by reference, defines requirements for the support of packet data transmission in broadband propagated spectrum systems TIA / EI IS-95, which may be a part of BS / MSC 106 and the IF 108. IS-707.5 also provides the requirements for the communication protocols in the links between the TE2 device 102 and the MT2 device 104 (the Rm interface), between the MT2 device 104 and the BS / MSC 106 ( the I interface Um), and between the BS / MSC 106 and the IWF 108 (the L interface). Referring now to FIGURE 2, a diagram of the protocol stacks in each entity of the IS-707.5 relay model is shown. FIGURE 2 corresponds approximately to Figure 1.4.2.2-1 of IS-707.5. To the far left of the figure is a protocol stack, shown in conventional vertical format showing the protocol levels that run on the TE2 device 102 (for example, the mobile terminal, the portable or pocket computer). The protocol stack of TE2 is illustrated as being logically connected to the protocol stack of the MT2 device 104 and the BS / MSC 106 over the interface Rm. The MT2 device 104, illustrated as being logically connected to the BS / MSC protocol stack 106 over the Um interface the BS / MSC protocol stack 106 in turn is illustrated as being logically connected to the IWF protocol stack 108 over the interface L. As an example of the operation of the protocols of Figure 2, Protocol 106 of Point-to-Point Protocol (PPPR) encodes packets from higher-level protocols 202, 204 and transmits them through the Rm interface that uses the EIA-232 protocol 208 to the EIA-232 compatible port in the MT2 device that runs the EIA-232 210 protocol. The EIA-232 protocol 210 in the MT2 device receives the packets and passes them to the PPPR protocol 205. The PPPR protocol 205 unbinds the packets encapsulated in the PPP frames and typically, when a data connection is up, it passes the packets to the PPPu protocol 215, which racks the packets into PPP frames for transmission to a PPP pair. located in the IWF (108). Radio Link Protocol 212 (RLP) and IS-95 protocol 214, which are well known in the art, are used to transmit packets that are encapsulated in PPP frames, to BS / MSC 106 over the Um interface. The RLP protocol 212 is defined in IS-707.5, entitled "Data Service Options for Wideband Spread Spectrum Systems: Packet Data Services", in February 1998, incorporated herein by reference, and the IS-95 protocol is defined in IS-95 mentioned in the above. A complementary RLP protocol 316 and the IS-95 protocol 218 in the BS / MSC 106 passes the packets to the relay level protocol 220 for transmission through the L interface to the relay level protocol 228. The PPPu protocol 226 then unbundles the received packets and passes them to the network level protocols 225, which will pass them to the higher level protocols 221 and send them to the Internet. As described in RFC 1661, the LCP Packages comprise a Configuration Request, a Configuration Recognition, a Negative Configuration Recognition, and a Configuration Rejection. The format of these packages is well known and described in RFC 1661. The Configuration Request package is used to negotiate the configuration options. All configuration options are always negotiated simultaneously.
The Configuration Recognition packet is transmitted if each configuration option in a received Configuration Request packet is recognized and all values are acceptable. The Negative Recognition package Configuration is sent in response to a Configuration Request package when the required configuration options are recognized, although some of the values are not acceptable. The Options field of the Configuration Negative Reconnaissance package is filled only with the unacceptable configuration options from the Configuration Request package. Note that all configuration options are always recognized simultaneously. The Configuration Rejection package is sent when a received Configuration Request includes configuration options that are not recognized or accepted for negotiation. The Configuration Rejection options field contains only the non-accepted configuration options of the Configuration Request. The following comprises the well-known configuration options, described in RFC 1661, and defined for the PPP LCP protocol. 1. Maximum Reception Unit 2. Authentication Protocol. 3. Quality Protocol. 4. Magic Number 5. Protocol Field Compression. 6. Compression of Control Field and Direction. 7. MRP-ASYNCHRONO Control Character The Internet Protocol Control Protocol (IPCP) is a network control protocol responsible for configuring, enabling, and disabling Internet Protocol (IP) modules at both ends of the PPP link. The IPCP is described in Request for Comment (RFC) 1332, "The PPP Internet Protocol Control Protocol (IPCP)", G. McGregor Merit, May 1992, incorporated herein by reference. The IPCP configuration options include: 1. IP addresses; 2. IP Compression Protocol; and 3. IP address. The IPCP uses the same option negotiation mechanism as the Link Control Protocol (LCP). The LCP and IPCP configuration option negotiations occur separately for both the Rm interface and the Um interface. That is, the negotiation of LCP or IPCP configuration option on one of the Rm and Um interfaces is separated from the negotiation of the LCP or IPCP configuration option on the other of the Rm and Um interfaces. Therefore, the wireless communication device (MT2) must separately negotiate the configuration options on the Rm and Um interfaces. The configuration option negotiation separated by the MT2 over the Rm and Um interfaces causes the MT2 device configuration option negotiation mechanism to be unnecessarily complex and cause the configuration option negotiations on both interfaces to be unnecessarily large.
SUMMARY OF THE INVENTION The present invention is a method and a wireless communication device (MT2) for simultaneously negotiating the configuration options of LCP or IPCP on both interfaces of Rm and Um. When the MT2 device receives any LCP or IPCP Configuration Request packets on one of the Rm and Um interfaces, the MT2 device analyzes the required configuration options and determines if the required options are supported by the MT2 device. If the required options are supported, the MT2 device saves a Configuration Request ID, including a Configuration Request packet, and racks the Configuration Request packet into a PPP frame for transmission of another of the Rm interfaces and Um. If any of the required configuration options are not supported by the MT2 device, the MT2 device creates a Configuration Rejection packet, which includes the unsupported options, and racks the Configuration Rejection packet into a PPP frame for the transmission over the interface through which the Configuration Request package is received, and the original request is discarded. In this way, a simple and fast mechanism is provided to simultaneously negotiate the configuration options in both Rm and Um interfaces.
BRIEF DESCRIPTION OF THE DRAWINGS These and other advantages will become more apparent from the detailed description of the preferred embodiments together with the following drawings: Figure 1 illustrates a high-level block diagram of a wireless data communication device in the which a terminal device is connected to a network, such as the Internet, by a wireless communication device; Figure 2 is a diagram of the protocol stacks of each entity; Figure 3 is a flow chart showing the processing that occurs when the MT2 device receives a Configuration Request packet over the Rm interface; Figure 4 is a flow chart showing the processing that occurs when the MT2 device receives a Configuration Recognition packet over the Rm interface; Figure 5 is a flow chart showing the processing that occurs when the MT2 device receives a Configuration Request packet over the Um interface; and Figure 6 is a flow chart showing the processing that occurs when the MT2 device receives a Configuration Recognition packet over the Um interface.
DETAILED DESCRIPTION OF THE PREFERRED MODALITIES As is known in the art, in order to establish communications over a point-to-point link, the Link Control Protocol (LCP) packets to establish the configuration and test the data link connection must exchange over each PPP link, that is, the interfaces of Rm and Um. Any non-negotiated option uses a predefined omission value, as specified by RFC 1661.
Similarly, IPCP packets to negotiate and configure IPCP configuration options must be exchanged over the interfaces of Rm and Um.
Any non-negotiated option uses a predefined omission value, as specified by RFC 1332. As described in RFC 1661, the LCP Packages comprise a Configuration Request, a Configuration Recognition, a Negative Configuration Recognition, and a Rejection of configuration. The format of these packets is well known and described in RFC 1661. Since the mechanism for negotiating IPCP configuration options is identical to the mechanism for negotiating LCP configuration options, the following detailed description applies to both LCP and IPCP. In a conventional system, configuration option negotiations occur separately for both the Rm interface and the Um interface. As described in RFC 1661 and RFC 1332, the Configuration Request package contains a list of the options that are required and the Configuration Recognition package contains a list of the options that the sender is aware of. Figure 3 explains the processing that occurs when a LCP Configuration Request or IPCP packet is received by the MT2 device over the Rm interface. Step S310 is performed to analyze the configuration options required in the Configuration Request package. In step S320, each of the options is checked to determine if it is supported by the MT2 device. If any of the options are not supported, step S330 is performed to create a Configuration Rejection package for bad options. In step S340 the Configuration Request packet is discarded. In step S350 it is sent to the PPP frame for the Rm interface, which will subsequently cause the Configuration Rejection packet to be encapsulated in a PPP frame for transmission over the Rm interface. If step S320 determines that all required options are supported by the MT2 device, then step S360 is performed to store a Configuration Request ID, included in the Configuration Request packet. Step S370 is then performed to pass the Configuration Request packet to the PPP frame for encapsulation in a PPP frame for transmission over the Um interface. Figure 4 explains the processing that occurs when a Configuration Recognition packet is received by the MT2 device over the Rm interface. In step S410 an ID in the Configuration Recognition package is compared to the Configuration Request ID. If the IDs match, then step S420 is performed to save the configuration options included in the Configuration Recognition package. Step S430 is performed to pass the Configuration Recognition packet to the PPP frame for the Um interface, which will subsequently cause the Configuration Recognition packet to be encapsulated in a PPP frame and transmitted over the Um interface. If step S410 determines that the ID in the Configuration Recognition packet does not match the Configuration Request ID, then step S430 is performed to pass the Configuration Recognition packet to the PPP frame for the Um interface, which it will subsequently cause the Configuration Recognition packet to be encapsulated in a PPP frame and transmitted over the Um. In other words, the configuration options are not saved when the ID in the Configuration Recognition package does not match the Configuration Request ID. Figure 5 shows the processing that is performed when a Configuration Request packet is received on the Um interface. Figure 5 is analogous to Figure 3 showing the processing that occurs when a Configuration Request packet is received over the Rm interface. Step S510 is performed to analyze the configuration options required in the Configuration Request package. In step S520, each of the options is checked to determine if it is supported by the MT2 device. If some of the operations are not supported, step S530 is performed to create a Configuration Rejection packet for bad options. In step S540, the Configuration Request packet is discarded. In step S550, the Configuration Rejection packet is sent to the PPP frame for the Rm interface, which will encapsulate the packet in a PPP frame for transmission in the Rm interface. If step S520 determines that all required options are supported by the MT2 device, then step S560 is performed to store a Configuration Request ID, included in the Configuration Request packet. Step S570 is then performed to pass the Configuration Request packet to the PPP frame for the Um interface, which encapsulates the packet in the PPP frame for transmission on the Um interface. Figure 6 shows the processing that occurs when a Configuration Recognition packet is received over the Um interface. The Figure is analogous to Figure 4 which shows the processing that occurs when a Configuration Recognition packet is received over the Rm interface. In step S610, an ID in the Configuration Recognition packet is compared to the Configuration Request ID. If the IDs match, then S620 is performed to save the configuration options included in the Configuration Recognition package. Step S630 is performed to pass the Configuration Recognition packet to the PPP frame for the Um interface, which will subsequently cause the Configuration Recognition packet to be encapsulated in a PPP frame and transmitted over the Rm interface. If step S610 determines that the ID in the Configuration Recognition packet does not match the Configuration Request ID, then step S630 is performed to pass the Configuration Recognition packet to the PPP frame for the Rm interface, which it will subsequently cause the Configuration Recognition packet to be encapsulated in a PPP frame and transmitted over the Rm interface. In other words, the configuration options are not saved when the ID in the Configuration Recognition package does not match the Configuration Request ID.
Any other configuration negotiation packet received in one of the interfaces of Rm and Um will be passed through the device of MT2 and will transmit in the other of the interfaces of Rm and Um. Figure 7 shows examples of the LCP configuration negotiations. At 70, the TE2 device sends a LCP Configuration Request packet over the Rm interface to the MT2 device. At 72, the MT2 receives the LCP Configuration Request packet, determines that the MT2 device does not support all the required configuration options of the LCP Configuration Request packet and generates and sends a LCP Configuration Reject packet, indicating the bad options, on the Rm interface. At 74, the TE2 generates a request packet from LCP configuration on the Rm interface. At 76, the MT2 device receives the LCP Configuration Request packet, analyzes the configuration options, determines that the configuration options are supported by the MT2 device, saves the Configuration Request ID of the Configuration Request packet. LCP, frames the LCP Configuration Request packet in the PPP frame and transmits the PPP frame over the Um interface. At 78, the IF analyzes the LCP Configuration Request packet, determines which part of the required options are bad, and sends a LCP Configuration Rejection packet, which includes the bad options to the MT2 device on the Um interface. . At 80, the MT2 device receives the LCP Configuration Rejection packet, determines that the received packet is not a LCP Configuration Request packet or a LCP Configuration Recognition packet and the MT2 device transmits the Reject packet of LCP Configuration on the Rm interface to the TE2 device. At 82, the TE2 device generates a LCP Configuration Request packet on the Rra interface to the MT2 device. At 84, the MT2 device analyzes the configuration options included in the LCP Configuration Request packet, determines that the MT2 device supports all configuration options, encapsulates the Configuration Request packet in a PPP frame, and transmits the PPP frame over the Um interface to the IWF. At 86, the IWF determines that it may prefer to negotiate other values of the required options and the IWF generates and transmits a Negative Recognition package of LCP configuration indicating the desired option values. At 88, the MT2 device receives the Negative Recognition of the LCP configuration, determines that the received packet is not an LCP Configuration Request packet or a LCP Configuration Recognition packet, and the MT2 device transmits the Negative Reconnaissance of the LCP configuration, encapsulated in a PPP frame, over the Rm interface to the TE2 device. The above examples of Figure 7 use the PPP LCP protocol, however, the IPCP protocol can also be used since the configuration negotiation mechanism is identical to the LCP protocol. For example, an IPCP Configuration Request can be used instead of a LCP Configuration Request; an IPCP Configuration Rejection can be used instead of a LCP Configuration Rejection, a Negative Acknowledgment of IPCP Configuration can be used instead of a Negative Acknowledgment of LCP configuration, ..., etc. One skilled in the art can also understand that any of the aforementioned LCP or IPCP configuration negotiation packets can be transmitted over the Rm interface or the Um interface. While the invention has been described together with what is currently considered to be the preferred embodiment, it will be understood that the invention is not limited to the described modality, on the contrary, it is intended to cover several modifications and equivalent arrangements within the spirit and scope of the appended claims.

Claims (24)

  1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and therefore the property described in the following claims is claimed as property. 1. A method for simultaneously establishing a PPP link between a wireless communication device and an interconnect (IF) function on a Um interface, and between the wireless communication device a TE2 device on the Rm interface, the method is characterized in that it comprises: receiving in the wireless communication device, a Configuration Request packet over the Rm interface; determine whether all configuration options included in the Configuration Request packet are supported by the wireless communication device; create and send a Rejection package of Configuration when the determination determines that at least one of the configuration options included in the Configuration Request packet is not supported by the wireless communication device; hatch the Configuration Request packet into a PPP frame and transmit the PPP frame over the Um interface, when the determination determines that all configuration options in the Configuration Request packet are supported.
  2. 2. The method according to claim 1, characterized in that it further comprises: storing in a memory, a request ID of Configuration, included in the Configuration Request package, when the determination determines that all configuration options in the Configuration Request package are supported.
  3. 3. The method of compliance with the claim 1, characterized in that it further comprises: receiving a Configuration Recognition packet on the Um interface; hatch the Configuration Request packet in the PPP frame and send the PPP frame that includes the Configuration Recognition packet over the Rm interface.
  4. 4. The method of compliance with the claim 2, characterized in that it also comprises: receiving a Recognition package of Configuration over the Rm interface; and plot the Configuration Recognition package in the PPP frame and send the PPP frame that includes the Configuration Recognition package over the Um interface.
  5. 5. The method according to claim 2, characterized in that it further comprises: determining whether the ID included in the Configuration Recognition package matches the Configuration Request ID stored in the memory; and save the values of all options included in the Configuration Recognition packet when the determination determines that the ID in the Configuration Recognition packet matches the Configuration Request ID stored in memory.
  6. 6. A method for simultaneously establishing a PPP link between a wireless communication device and an interconnecting function (IWF) over a Um interface, and between the wireless communication device and a TE2 device over an Rm interface, the method is characterized in that it comprises: receiving in the wireless communication device, a Configuration Request packet over the Rm interface; determine whether all configuration options included in the Configuration Request packet are supported by the wireless communication device; create and send a Configuration Rejection packet when the determination determines that at least one of the configuration options included in the Configuration Request packet is not supported by the wireless communication device; store in a memory, a Request ID of Configuration, included in the Configuration Request package, when the determination determines that all configuration options in the Request for Configuration package Settings are supported; forming the Request for Configuration packet in a PPP frame and transmitting the PPP frame in the Um interface, when the determination determines that all the configuration options in the PPP packet Settings are supported; receive a Configuration Recognition package over the Um interface; determine if the ID included in the package Configuration Recognition matches the Configuration Request ID stored in the memory; save the values of all the options included in the Configuration Request package when the determination determines that the ID in the package Configuration Recognition matches the ID of Configuration request stored in memory; and plot the Configuration Recognition package in the PPP frame and send the PPP frame that includes the Configuration Recognition package over the Um interface.
  7. 7. A method of simultaneously establishing a PPP link between a wireless communication device and an interconnecting function (IWC) over a Um interface, and between the wireless communication device and a TE2 device over a Um interface, the method is characterized in that it comprises: receiving in the wireless communication device, a Configuration Request packet over the Rm interface; determine whether all configuration options included in the Configuration Request packet are supported by the wireless communication device; create and send a Rejection package of Configuration when the determination determines that at least one of the configuration options included in the Configuration Request packet are not supported by the wireless communication device; hatch the Configuration Request packet in a PPP frame and transmit the PPP frame over the Rm interface, when the determination determines that all configuration options in the Configuration Request packet are supported.
  8. 8. The method in accordance with the claim 7, characterized in that it further comprises: storing in a memory, a Request ID of Configuration, included in the Configuration Request package, when the determination determines that all configuration options in the Request for Configuration package Settings are supported.
  9. 9. The method of compliance with the claim 8, characterized in that it also comprises: receiving a Recognition package of Configuration over the Rm interface; plot the Configuration Recognition package in the PPP frame and send the PPP frame that includes the Configuration Recognition package over the Um interface.
  10. 10. The method according to claim 8, further comprising: receiving a Configuration Recognition packet over the Rm interface; hatching the Recognition package Configuration in the PPP frame and send the PPP frame that includes the Configuration Recognition package over the Um interface. The method according to claim 10, characterized in that it further comprises: determining whether the ID included in the Configuration Recognition package matches the Configuration Request ID stored in the memory; Save the values of all the options included in the Configuration Recognition package when the determination determines that the ID in the Configuration Recognition package matches the ID of the configuration. Configuration request stored in memory. 12. A method of simultaneously establishing a PPP link between a wireless communication device and an interconnection function (IWC) over a Um interface, and between the wireless communication device and a TE2 device over an Rm interface, the method is characterized in that it comprises: receiving in the wireless communication device, a Configuration Request packet over the Um interface; determine whether all configuration options included in the Configuration Request packet are supported by the wireless communication device; create and send a Rejection package of Configuration when the determination determines that at least one of the configuration options included in the Configuration Request packet is not supported by the wireless communication device; store in a memory, a Request ID of Configuration, included in the Petition for Configuration, when the determination determines that all configuration options in the Configuration Request package are supported; hatch the Configuration Request packet in a PPP frame and transmit the PPP frame over the Rm interface, when the determination determines that all configuration options in the Configuration Request packet are supported; receive a Configuration Recognition package over the Rm interface; determine whether the ID included in the Configuration Recognition package matches the Configuration Request ID stored in the memory; save the values of all options included in the Configuration Recognition packet when the determination determines that the ID in the Configuration Recognition packet matches the Configuration Request ID stored in the memory; plot the Configuration Recognition package in the PPP frame and send the PPP frame that includes the Configuration Recognition package over the Um interface. 13. A wireless communication device capable of simultaneously establishing a PPP link to an interconnecting function (IWC) on a Um interface, and between the wireless communication device and a TE2 device on an Rm interface, the method is characterized in that comprises: means for receiving a Configuration Request packet on the Rm interface; means for determining whether all of the configuration options included in the Configuration Request packet are supported by the wireless communication device; means to create and send a Configuration Rejection packet when the determination determines that at least one of the configuration options included in the Configuration Request packet is not supported by the wireless communication device; and means for plotting the Configuration Request packet in a PPP frame and for transmitting the PPP frame on the Um interface, when the determination determines that all configuration options in the Configuration Request packet are supported. 14. The wireless communication device according to claim 13, characterized in that it further comprises: means for storing in a memory, a Configuration Request ID, included in the package of Configuration Request, when the determination determines that all configuration options in the Configuration Request package are supported. 15. The wireless communication device according to claim 13, further comprising: means for receiving a Configuration Recognition packet on the Um interface; means to hatch the Configuration Recognition packet in the PPP frame and to send the PPP frame that includes the Configuration Recognition packet over the Rm interface. 16. The wireless communication device according to claim 15, further comprising: means for receiving a Configuration Recognition packet on the Um interface; means to hatch the Configuration Recognition packet in the PPP frame and to send the PPP frame that includes the Configuration Recognition packet over the Rm interface. The wireless communication device according to claim 16, characterized in that it further comprises: means for determining whether the ID included in the Configuration Recognition packet matches the Configuration Request ID stored in the memory; and means to store the values of all the options included in the Recognition package of Configuration when the determination determines that the ID in the Configuration Recognition package matches the Configuration Request ID stored in the memory. 18. A wireless communication device capable of simultaneously establishing a PPP link to an interconnect function (IC) on a Um interface, and between the wireless communication device and a TE2 device on an Rm interface, the method is characterized in that it comprises: means for receiving a Configuration Request packet on the Rm interface; means for determining whether all of the configuration options included in the Configuration Request packet are supported by the wireless communication device; means to create and send a Configuration Rejection packet when the determination determines that at least one of the configuration options included in the Configuration Request packet is not supported by the wireless communication device; and means for storing in a memory, an ID of Configuration Request, included in the Configuration Request package, when the determination determines that all configuration options in the Configuration Request package are supported; means for hatching the Request for configuration packet in a PPP frame and for transmitting the PPP frame on the Ura interface, when the determination determines that all configuration options in the Configuration Request packet are supported; means for receiving a Configuration Recognition packet on the Um interface; means for determining whether an ID included in the Configuration Recognition package matches the Configuration Request ID stored in the memory; means to store the values of all the options included in the Configuration Recognition packet when the determination determines that the ID in the Configuration Recognition packet matches the Configuration Request ID stored in the memory; and means for plotting the Configuration Recognition packet in the PPP frame and for sending the PPP frame that includes the Configuration Recognition packet over the Rm interface. 19. A wireless communication device capable of simultaneously establishing a PPP link to an interconnect function (IWC) over a Um interface, and between the wireless communication device and a TE2 device over an Rm interface, the method is characterized in that it comprises: means for receiving a request packet from Configuration over the Um interface; means for determining whether all of the configuration options included in the Configuration Request packet are supported by the wireless communication device; means to create and send a Configuration Rejection packet when the determination determines that at least one of the configuration options included in the Configuration Request packet is not supported by the wireless communication device; and means for plotting the Request for configuration packet in a PPP frame and for transmitting the PPP frame on the Rm interface, when the determination determines that all configuration options in the Configuration Request packet are supported. 20. The wireless communication device according to claim 19, characterized in that it further comprises: means for storing in a memory, an ID of Configuration Request, included in the Configuration Request package, when the determination determines that all configuration options in the Configuration Request package are supported. 21. The wireless communication device according to claim 20, characterized in that it further comprises: means for receiving a Configuration Recognition packet over the Rm interface; means to hatch the Configuration Recognition packet in the PPP frame and to send the PPP frame that includes the Configuration Recognition packet over the Um interface. 22. The wireless communication device according to claim 20, characterized in that it further comprises: means for receiving a Configuration Recognition packet on the Um interface; and means for plotting the Configuration Recognition packet in the PPP frame and for sending the PPP frame that includes the Configuration Recognition packet over the Rm interface. The wireless communication device according to claim 22, characterized in that it further comprises: means for determining whether an ID included in the Configuration Recognition packet matches the Configuration Request ID stored in the memory; and means to store the values of all the options included in the Recognition package of Configuration when the determination determines that the ID in the Configuration Recognition package matches the Configuration Request ID stored in the memory. 24. A wireless communication device capable of simultaneously establishing a PPP link to an interconnect function (IWC) over a Um interface, and between the wireless communication device and a TE2 device over an Rm interface, the method is characterized in that it comprises: means for receiving a Configuration Request packet on the Um interface; means for determining whether all of the configuration options included in the Configuration Request packet are supported by the wireless communication device; means to create and send a Configuration Rejection packet when the determination determines that at least one of the configuration options included in the Configuration Request packet is not supported by the wireless communication device; means for storing in a memory, a Configuration Request ID, included in the package of Configuration Request, when the determination determines that all configuration options in the Configuration Request package are supported; means for plotting the Request for configuration packet in a PPP frame and for transmitting the PPP frame on the Rm interface, when the determination determines that all configuration options in the Configuration Request packet are supported; means for receiving a Configuration Recognition packet over the Rm interface; means for determining whether an ID included in the Configuration Recognition packet matches the Configuration Request ID stored in the memory; means to store the values of all the options included in the Configuration Recognition packet when the determination determines that the ID in the Configuration Recognition packet matches the Configuration Request ID stored in the memory; and means for plotting the Configuration Recognition packet in the PPP frame and for sending the PPP frame including the Configuration Recognition packet over the Um interface.
MXPA/A/2001/008593A 1999-02-24 2001-08-24 Simultaneous setup of ppp on a um and rm interface MXPA01008593A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09256118 1999-02-24

Publications (1)

Publication Number Publication Date
MXPA01008593A true MXPA01008593A (en) 2002-05-09

Family

ID=

Similar Documents

Publication Publication Date Title
CA2364269C (en) Simultaneous setup of ppp on a um and rm interface
KR100748814B1 (en) Method of avoiding ppp time-outs during ipcp negotiations
MXPA02005523A (en) Method and apparatus for authentication in a wireless telecommunications system.
KR100633204B1 (en) Independant synchronisation of ppp links on um and rm interfaces
US6625164B1 (en) Selectively framing and unframing PPP packets depending on negotiated options on the Um and Rm interfaces
CA2379126C (en) Method and apparatus for avoiding data loss during a ppp renegotiation on a um interface
CN117440533A (en) Method and device for connecting Wi-Fi module to cloud and intelligent device
CN1934832B (en) Packet data serving node and communication method using the same
MXPA01008593A (en) Simultaneous setup of ppp on a um and rm interface
US7903675B2 (en) Method and apparatus for setting up point-to-point protocol link between terminal equipment and interworking function
KR20070073379A (en) System for setuping point-to-point protocol