KR20070103362A - Handoff support for networks with different link establishment protocols - Google Patents

Abstract

In a communication system where a roaming node attempts network access between different networks implemented with different network interface layer protocols, a handoff scheme is established so that the node can freely move between networks with a low level of interference to network access. . Before and at the beginning of the handoff, the node receives an indication of the handoff. The indication may be inserted in various forms such as a signal message indicating a change of the SID (system identifier), the NID (network identifier) or the PZID (packet zone identifier). Alternatively, the indication may be in the form of information directly included in the data packet sent to the roaming node prior to the handoff. Alternatively, the indication may be implemented as a distinguishable message pattern sent to a node where different message patterns may be sent by different networks supporting different network interface layer protocols.

Description

HANDOFF SUPPORTS FOR NETWORKS HAVING DIFFERENT LINK ESTABLISHMENT PROTOCOLS}

This patent application claims priority to US Provisional Application No. 60 / 614,215, filed Sep. 28, 2004, entitled "Methods and Devices for Handoff Supported Fast Link Establishment Protocol," which is assigned to the assignee and is herein filed. Is incorporated by reference in its entirety.

FIELD OF THE INVENTION The present invention relates generally to packet data communications, and more particularly to handoff support for networks with different link establishment protocols that often require execution before any packet data communications between networks.

The interconnection of networks allows quick access to information regardless of the geographical distance as a whole. 1 shows a simplified schematic diagram of a global network connection, generally referred to as the Internet, indicated by reference numeral 20. The Internet 20 is essentially a number of networks with different levels of hierarchy linked together. The Internet 20 operates under the Internet Protocol (IP) published by the Internet Engineering Task Force (IETF). Details of the IP can be found in Request For Comments (RFC) 791 published by the IETF.

The Internet 20 is connected to various individual networks, sometimes called Local Area Networks (LAN) or Wide Area Networks (WAN), depending on the network size. 1, some of these networks 22, 24, 26, 28 are shown.

Within each network 22, 24, 26, 28 there may be a variety of equipment in communication with each other. For example, to name a few, there are computers, printers, and servers, which are commonly called nodes. When a node communicates beyond its own network via the Internet 20, an IP address needs to be assigned to the node. The assignment of IP addresses can be manual or automatic. Manual assignment of the IP address may be performed by the network administrator, for example. More often, IP addresses are automatically assigned, for example, by dedicated servers in a LAN or WAN.

Give an example for explanation. Assume that node 30 of network 22 wants to send a data packet to another node 37 of network 24. Under IP each data packet needs to have a source address and a destination address. In this case, the source address is the address of the node 30 in the network 22. The destination address is the address of node 37 in network 24.

Often, inter-node communication is required prior to network access, such as access to other networks via the Internet 20. Here is another example for explanation. Assume that node 30 of network 22 is a laptop computer. Laptop computer node 30 does not have direct access to network 22. Nevertheless, the laptop computer node 30 may reach the NAS (network access server) 32 of the network 22 by some other means, for example by dialing a wired modem via a telephone line. In that case, the node 30 typically establishes a PPP (point-to-point protocol) session with the NAS (network access server) 32 of the network 22. The packet data communication established between node 30 and network 22 or any other networks via the Internet 2 will then be exchanged via wired modem and telephone line. If the modem transmits and receives signals continuously and asynchronously over a telephone line, the data packets exchanged over the telephone line must also be framed accordingly to make them suitable for serial and asynchronous modem links.

Advances in wireless technology allow nodes to move away from the originally registered network to other networks. For example, returning to FIG. 1, node 30 may be a wireless device such as a PDA (personal portable terminal), cellular phone or mobile computer instead of being permanently wired to network 22. The wireless node 30 may move beyond the boundaries of its home network 22. Thus, the node 30 may roam from its home network 22 to another network 28. In order to gain access to the network 28 or to connect to another network via the Internet 20, the node 30 also typically establishes a PPP session with the NAS 33 of the network 28. In this case, communication between the node 30 and the NAS 33 is via an air link. In addition, data packets exchanged over the air link must also be formatted to conform to the format negotiated during the PPP session between the node 30 and the NAS 33.

The size of the PPP is described in RFCs 1661 and 1662 published by the IETF. PPP is essentially a research and negotiation session between nodes, during which the nodes find out about capabilities and utilization from each other resource before any network traffic flow and eventually converge on a mutually acceptable set of parameter options. PPP is sometimes called "network interface layer protocol" because PPP sessions often need to be established before network access. However, other similar terms are also generally used, including "link establishment protocol" and "layer-2 protocol." Hereinafter, the terms "network interface layer protocol", "link establishment protocol" and "layer-2 protocol" are used interchangeably.

2 shows a sequential flow diagram of an example PPP communication session 34 in which node 30 of network 28 wishes to establish a communication link with NAS 33 to gain access to the Internet 20.

PPP has a number of protocol components. In the example PPP session shown in FIG. 2, the PPP has LCP (Link Control Protocol) 36, CHAP (Challenge / Handshake Authentication Protocol) 38, and IPCP (Internet Protocol Configuration Protocol) 40 as components.

First, upon completion of the physical link, i.e., if the node 30 and the NAS 33 can reach each other, for example at the hardware level, it is necessary to exit the LCP 36. The LCP 36 serves the purpose of establishing a basic communication link between the node 30 and the NAS 33. During the LCP 36, the node 30 and the NAS 33 exchange and negotiate essential communication parameter options with each other. The options include the maximum size of the data packet over the link, the parameters related to quality control, the high level data link control (HDLC) header field compression scheme used, and whether the peer is voluntarily authenticated.

The process for LCP 36 is more or less affected under handshake etiquette. First, the requesting party proposes one or more parameters by sending a configuration request message. If no parameter is recognized by the receiving side, the receiving side responds back with a configuration reject message. If the rejected parameter is fatal to the examined link, the requesting party must terminate the PPP session.

On the other hand, if the parameter is recognized but the option associated with the parameter is not acceptable, the responding party sends back a configuration Nak message. The requesting party may also terminate the PPP session or send another configuration request message with different options for the same parameters.

All parameters with related options must be negotiated and resolved in the manner described above. As shown in FIG. 2, several conference negotiations may be required. If the requesting party determines that all necessary parameters can be accepted by the responding party, the requesting party sends a final configuration Ack message to the responding party. If both sides sent a configuration Ack message, they transition to the acknowledge state.

To ensure that both sides are approved, approval should be carried out. One way to perform the authorization is to use another PPP component (CHAP) 38. In general, it is NAS 33 that initiates CHAP 38 to verify the identity of node 30. During CHAP 38, NAS 33 sends a message, called a message, to node 3. Under CHAP, there is a shared secret used with the challenge message used to compute the response message using a pre-consensus algorithm. The node 30 sends a response message generated by the secret algorithm to the NAS 33. The NAS 33 then compares the received response message with the message calculated by the NAS 33 itself. If there is a comparison, then node 30 is said to pass through CHAP 38 where NAS 33 sends a CHAP success message to node 30. Otherwise, a CHAP failure message is sent by the NAS 33.

Alternatively, the approval may be completed by passing PAP (Password Approval Protocol) instead of CHAP 38. In PAP, node 30 only sends the username and password to NAS 33 for verification. If verified, node 30 is said to pass PAP.

If node 30 requires IP access, information about the IP needs to be exchanged and negotiated again. For example, node 30 may, among other things, require the assignment of an IP address to access the Internet 20 (FIG. 1), depending on the IP. To accomplish this, negotiation and exchange of parameter options under IPCP 40 begins. In an example PPP session 34, node 30 initially requests an IP address 0.0.0.0 from NAS 33. In response, NAS 33 sends a configuration Nak message to suggest that node 30 uses IP address a.b.c.d. If allowed, node 30 confirms the use of IP address a.b.c.d by sending another message to NAS 33 for authorization.

Finally, if node 30 agrees to all parameters negotiated during IPCP 40, node 30 sends an acknowledgment message to NAS 33. The user data of the network access session is then exchanged. IP data packets of network traffic are encapsulated into PPP frames earlier with parameters negotiated during LCP 36.

At the end of network access, either the node 30 or NAS 33 sends a termination request message to the other side, which then responds with a termination Ack message and ends the communication session.

As can be seen from FIG. 2 and the above description, there are a number of messages exchanged between the node 30 and the NAS 33 during the PPP session 34. As such, significant time duration is involved. This is especially the case when the PPP session 34 is negotiated over a slow link with high data latency.

In order to expedite the initial link establishment process between node 30 and NAS 33, various protocols other than PPP have been proposed. An example of such a protocol is indicated in US patent application Ser. No. 11 / 193,068, filed Jul. 28, 2005, entitled "Establishing a Fast Link for Network Access." The '068 patent application assigned to the assignee herein is hereby incorporated by reference in its entirety. Hereinafter, any link establishment protocol other than PPP is referred to as non-PPP.

However, problems arise with communication systems in which some networks support non-PPP and others do not. The problem can also be doubled when mobile nodes roam around different networks with different link establishment protocols.

Give another example for explanation. Reference is now again made to FIG. 1. Assume that node 30 establishes a communication link with NAS 33 via a non-PPP session after moving to network 28. Thereafter, user data is exchanged between the node 30 and the NAS 33. It is also assumed that while exchanging user data, node 30 moves to another network, such as network 26. If network 26 is similar to network 28 in all respects of physical and protocol implementation, including network interface layer protocol implementations, a streamlined handoff scheme can be devised. After reaching the area of the network 26, the network 28 can take over the network 26 with a data processing task that can be handled through a packet data communication function held in advance.

However, networks 28 and 26 are often dissimilar in hardware and link layer implementations. For example, assume that network 28 supports not only PPP but also other non-PPP as a network interface layer protocol. On the other hand, the network 26 supports only PPP as a network interface layer protocol and does not support other protocols. In order to continue network access after moving from network 28 to network 26, the node then establishes that the established packet data communication is adapted to the established physical link between node 30 and NAS 35 in network 26. 30 first needs to establish another network interface layer protocol session with NAS 25 in network 26. If the node 30 is not suitable for smoothly invoking the conventional PPP required by the network 26, the node 30 may be completely excluded from network access.

Accordingly, there is a need to provide a reliable handoff process for moving nodes that attempt network access between different networks that support different network interface layer protocols.

In a communication system with multiple networks, nodes attempting to access the network in the communication system need to go through a handoff process that moves between networks. A special challenge arises when different networks are implemented with different network interface layer protocols. According to an exemplary embodiment of the present invention, a handoff scheme is implemented in which a node can roam between networks with less interference with network access. Prior to the handoff, the node receives an indication of the handoff. The indication may assume the form of a change in SID (system identifier), NID (network identifier) or PZID (packet zone identifier), or a combination thereof. Alternatively, the indication may be directly included in a data packet sent to the node during handoff. Alternatively, the indication may be in the form of a message pattern sent to a node where different message patterns are transmitted by different networks supporting different network interface layer protocols.

In accordance with one aspect of the present invention, a method for passing through a node attempting to access a network is disclosed. The method includes establishing a first network interface layer protocol with a serving node, receiving an indication for handoff, and establishing a second network interface layer protocol with a target node.

According to another aspect of the present invention, an apparatus having a hardware implementation for performing the steps of the method described above is disclosed.

According to yet another aspect of the present invention, a computer readable medium having computer readable instructions for executing the steps of the method described above is disclosed.

These and other features and advantages are apparent to those skilled in the art from the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals refer to like parts.

1 is a schematic diagram of a global network connection.

2 is a communication sequence diagram of a communication session of a conventional network interface layer protocol.

3 is a schematic diagram of nodes and networks included in a general embodiment of the present invention.

4 is a schematic diagram of nodes and networks included in an exemplary embodiment of the present invention supporting wireless technology.

5 is a schematic diagram illustrating a protocol stack in a layered order.

FIG. 6 is a communication sequence diagram of a communication session of an exemplary network interface layer protocol different from the conventional network interface layer protocol shown in FIG.

7 is a communication sequence diagram illustrating the steps involved in accordance with a first handoff scheme used in an exemplary embodiment of the present invention.

8 is a flowchart of a handoff method of the communication sequence diagram shown in FIG. 7.

9 is a communication sequence diagram illustrating the steps involved in accordance with a second handoff scheme used in an exemplary embodiment of the present invention.

10 is a schematic diagram of a data frame format used in the network interface layer protocol of FIGS. 2 and 6.

FIG. 11 is a flowchart of a handoff method of the communication sequence diagram shown in FIG. 9.

11A is a flowchart of the handoff method of the communication sequence diagram shown in FIG. 7.

12 is a communication sequence diagram illustrating the steps involved in accordance with a third handoff scheme used in an exemplary embodiment of the present invention.

FIG. 13 is a flowchart of a handoff method of the communication sequence diagram shown in FIG. 12.

14 is a schematic diagram of circuitry of a node attempting to access a network according to an exemplary embodiment.

15 is a communication sequence diagram illustrating the steps involved in taking a handoff to a target network while establishing a network interface layer protocol session with a serving network.

FIG. 16 is a flowchart of the handoff process described in the communication sequence diagram shown in FIG. 15.

The following description is presented to enable those skilled in the art to make and use the invention. For the sake of explanation, detailed items are mentioned in the following description. Those skilled in the art should recognize that the present invention may be practiced without the use of specific items. In other instances, well known structures and processes have not been described in detail so as not to obscure the description of the invention with unnecessary items. Thus, the present invention is not limited to the illustrated embodiments but is to be accorded the widest scope consistent with the principles and features disclosed herein.

3 shows a simplified schematic diagram of nodes and networks included in the general embodiment of the present invention. The communication system is indicated generally by the reference numeral 42, which includes the networks 45, 47 connected to the backbone network 49. Backbone network 49 may be an intranet or the Internet. There may be other networks connected to the backbone network 49, although not shown in FIG. 3 for brevity and clarity.

NAS (network access servers) 51 and 53 are connected to networks 45 and 47, respectively, which serve as gateways to any nodes attempting to access the network. In the system 42, assume that there is a node 55 looking for access of the network 45 or other networks through the backbone network 49. Node 55 does not have direct access to network 45 but communicates with NAS 51 via communication link 47. The communication setup between the node 55 and the NAS 51 is through a process called "link establishment".

Assume that node 55 is not limited to its original network, such as network 45, but can move to other networks, such as network 47.

In this case, when node 55 leaves network 45 and moves to network 57, to gain network access, node 55 likewise differs from NAS 51 of network 47 via another communication link. A link establishment session must be established.

The link 57 between the NAS 51 and the node 55 may be a link that assumes various forms. For example, the link 57 may be, to some extent, a wired link such as a conventional telephone wired connection, a coaxial cable link or an optical cable link. Moreover, the link 57 may also be a wireless link, such as an air interface, which may carry electromagnetic or acoustic signals, for example.

4 illustrates a more specific implementation of a communication system 42 that supports wireless technology. In this case, the whole system is generally indicated by the reference numeral 44. Wireless communication between nodes may be performed via a link in the form of an air interface, such as the air interface links 58 and 90 shown in FIG. In this embodiment, for consistency and simplicity of description, the network 44 is connected to 3GPP2 (3rd Generation Partnership Project 2), a consortium of several international standards organizations, including the TIA / EIA (Telecommunications Industry Association / Electronic Industry Association). It is described as supporting wireless technologies such as the cdma2000 standard published by.

In system 44, node 56 capable of roaming to other networks may be implemented in various forms, such as a PDA (personal digital assistant), a mobile computer or a cellular phone, to name just a few.

In the network 46, a PDSN (Packet Data Serving Node) 60 is implemented that functions as a NAS 52. Node 58 is in communication with PDSN 60 via a RAN (Radio Access Network), generally designated 62. The RAN 62 includes a BSC / PCF (base station controller / packet data control function) 64 connected to a number of BSs (base stations) 65A-65N.

Similarly, another network PDSN (Packet Data Serving Node) 66 is disposed in the network 48 that assumes the duties of another NAS 54. Any node that attempts network access communicates with the PDSN 66 via another RAN 68. The RAN 68 includes a BSC / PCF 70 connected to a number of BSs 72A-72M.

Networks 46 and 48 may process data packets carrying voice or data information. Structural details of the radio capability networks 46 and 48 can be found in a document published in February 2005 under the name "Interoperability Specification (IOS) for CDMA 2000 Access Network Interfaces" (TIA-2001-D) by 3GPP2. have.

Before describing the operational items of the communication system 42, it is first helpful to generally describe the processing of data packets during packet data communication through various protocol levels of different hierarchies and interrelationships.

In the field of network communications, protocols are layered according to the OSI (Open Systems Interconnection) model published by ISO (International Organization for Standardization) and ITU-T (International Telecommunication Union-Telecommunications Standards Sector). The goal is to facilitate multi-vendor device interoperability. That is, each level of the protocol hierarchy has its own specification. As such, as long as the specifications of a particular hierarchy level are met, product development at that level is certainly compatible with other products at other levels.

Assume that system 44 of FIG. 4 supports IP (Internet Protocol). 5 schematically shows a stack of protocols, generally referred to as "protocol stacks," in layered order, which is generally indicated by reference numeral 74. The IP protocol stack 74 is structured for the Internet Engineering Task Force (IETF) model, which is similar to the OSI model but not exactly the same. According to the IETF model, the IP protocol stack 74 has five layers starting from layer 1 to layer 5. Thus, data packets sent by nodes such as each node 56, 60, 66 shown in FIG. 4 must be processed via protocol 74. The stack of protocols 74 is configured in the node in software, hardware, or a combination thereof. Likewise, data packets received by the same node must be processed through the same protocol stack 74, but in reverse order.

Give an example for explanation. The data packet is processed to be sent from a node, for example node 56 (FIG. 4), which first assumes that the data packet is generated according to one of the protocols of the application layer, ie, layer 5. Layer 5 includes HTTP (Hyper Text Transfer Protocol), SMTP (Service Mail Transfer Protocol), FTP (File Transfer Protocol) and RTP (Real Time Transfer Protocol). It is also assumed that the data packet is the result of a Voice over Internet Protocol (VoIP) session. Thus, data packets must be formatted according to RTP at layer 5.

At layer 5, time-sensitive data packets, such as data packets originating from RTP, need to be processed in real time. Specifically, defective packets are not normally retransmitted, but instead simply omitted so as not to interfere with the transmission of other newly appearing data packets. Thus, RTP data packets are normally carried via UDP (User Data Packet Protocol) at Layer 4, the transport layer. Accordingly, data packets from layer 5 RTP must be formatted according to layer 4 UDP.

On the other hand, if the data packet originates from another layer 5 protocol, such as FTP, the data packet is normally sent over layer 4 TCP (transmission control protocol). Accurate delivery of data packets under TCP is of paramount importance. As such, defective packets may slow down the entire data transfer process but are always retransmitted.

After passing through this transport layer, Layer 4, data packets are added with information such as source and destination port numbers.

After passing through Layer 4, which is the transport layer, the data packet is sent to Layer 3, which is the network layer, for processing. In this particular case, the resulting data packet from layer 4 must also be formatted according to the IP, for example the source and destination addresses of the added data packet.

Note that for simplicity only the layer 3 IP is shown in FIG. 5. There are other protocols that perform additional functions on IP that are also present at Layer 3. An example is ICMP (Internet Control Message Protocol) for the purpose of sending error messages for undeliverable data packets.

Thereafter, the data packet should be framed to conform to whatever protocol is applied to layer 2, the link layer. The above-described PPP (point-to-point protocol) is classified as a layer 2 protocol. As mentioned above, other non-PPPs are used by networks that replace PPP as a network interface layer protocol.

The lowest layer of the protocol stack 74 of FIG. 5 is Layer 1, which is the physical layer, which relates to the physical implementation of data packet transmission. For example, if the communication link 57 in FIG. 3 is a conventional wired link, layer 1, which is a physical layer, is connected to the hardware circuits of both nodes 55 and 51 for driving signals through the wires constituting the link 57. FIG. Get involved. As another example, if the communication link 58 in FIG. 4 is an air interface, the physical layer, Layer 1, relates to air space and the hardware of the RAN 62 to send and receive signals through the air space.

Next, refer to FIG. 4 again. Regarding the data packet received by the exemplary node 56, the data packet must be processed through the same protocol stack 72 (FIG. 5), but in reverse order, ie, from layer 1 to layer 5.

In this example, assume that node 56 first attempts network access via PDSN 60. It is also assumed that node 56 has no direct access to network 46.

Conventionally, node 56 may first initiate a network access process by establishing a PPP session with PDSN 60. However, as noted above, other network interface layer protocols have been proposed to streamline the linking process prior to network access. One of these protocols is indicated in the '068 patent application as mentioned above.

In the following description, for ease of explanation, the protocol disclosed in the '068 patent application is described together with the operational description of the exemplary embodiments. It should be noted, however, that the practice of the invention should not be so limited or so limited. Network interface layer protocols other than those described in the '068 patent application can certainly be applied.

4, prior to any message exchange, the physical link 58 must be ready to carry the signal. In other words, Layer 1, the physical layer of node 56 and BS 65A, must first be physically present and established.

Once the physical layer is established, i.e., node 56 and PDSN 60 detect mutual mutual presence between each other via RAN 62, PDSN 60 immediately sends a first message to node 56. .

6 is a flow diagram illustrating a communication sequence of messages between node 56 and PDSN 60. The entire flow process is designated by reference numeral 75. Flow process 75 is described in detail in the '068 application but briefly summarized below.

PDSN 60 allows only network access of authorized nodes. The first message is sent by the PDSN 60 and is called a Sync message, indicated by reference numeral 76. Sync message 76 includes all possible authentication options to select for node 56. The options may include a challenge message under CHAP (Challenge Authentication Protocol), a password and username request as required by PAP (Password Authentication Protocol), and any other authentication protocol applicable.

Upon receipt of the Sync message 76, node 56 responds with a request message 78 as shown in FIG.

In request message 78, node 56 includes the required authentication information in response to the requests as described in Sync message 76. Node 56 also includes in request message 78 all parameter options needed to establish a link to node 56 for subsequent network access via PDSN 60. It does not matter whether the parameters with related options relate to link configuration, authentication or network access control. That is, instead of classifying the parameters according to the functionality of protocol components such as Link Control Protocol (LCP), Challenge Handshake Authentication Protocol (CHAP) and Internet Protocol Control Protocol (IPCP) as described above with respect to PPP, the request message 78 All parameters with options in () are included regardless of the function. More specifically, the parameters with options in the request message 78 are not only parameters for network access, such as IP address, DNS (Domain Name System) configuration and, if applicable, IP header compression protocol, but also a response to the challenge message, or If applicable, it may include link configuration parameters of the link 58, such as username and password, datagram size or HDLC (high level data link control) header field compression scheme.

The request message 78 is basically formatted with intentional redundancy with respect to the selection so that both nodes 56, 60 can have PDSN 60 select options supported by both nodes 56, 60. Quickly terminate the entire process of layer 2 links. Among various choices, the PDSN 60 may optionally select parameters with relevant options that are clearly supported for the purpose of shortening the overall link time by increasing the chances of a successful link.

As shown in FIG. 6, in response to the request message 78, the PDSN 60 sends a response message 80. In response message 80, PDSN 60 selects a variety of options. The response message 80 includes selected parameter options with relevant configuration values. Very often, the response message is the last message needed by the node 56 before initiating network traffic in the form of user data 82. At the end of network access, either node 56 or PDSN 60 sends a termination request message 84 to the other side, which then responds with a termination Ack message 86 and ends the communication session.

As can be seen, unlike other protocols, such as the PPP protocol described previously, the link process 75 involves substantially fewer message exchanges prior to the start of user data 82. Accordingly, link establishment of the link layer, ie layer 2, can thereby be completed more quickly.

In this example, while exchanging user data 82 with PDSN 60 of network 46, node 56 starts moving to another network, such as network 48. The travel path is indicated with reference numeral 88 as shown in FIG.

In this scenario, node 56 basically goes through a process commonly referred to as "handoff." More specifically, node 56 switches the side communicating from PDSN 60 via RAN 62 of network 46 to PDSN 66 via RAN 68 of network 48. According to this embodiment, before handoff, node 56 first needs to receive an indication of the handoff. Instructions for handoff may be represented in various forms that are implemented in various ways.

7 illustrates one such manner, generally indicated by reference numeral 92. Next, referring to FIG. 7 together with FIG. 4.

Prior to handoff, it is assumed that node 56 first experiences a non-PPP link session 94 with PDSN 60 via RAN 62 prior to any network access. Session 94 may be a link establishment process 75 as shown and described in FIG. 6. Non-PPP link establishment session 94 lasts for a period of time t1 to t4, for example.

During the non-PPP link session in period t2, PDSN 60 sends an LCP Configuration Request message 96, which is a PPP message. The reason is that PDSN 60 does not initially know whether node 56 supports conventional PPP or non-PPP. To increase the chance of linking node 56, both the Sync message 76 according to the link establishment process 75 (FIG. 6) and the LCP Configuration Request message 96 under PPP are sent. In this case, node 56 supports link establishment process 75. As such, network interface layer protocol session 94 is executed in accordance with link establishment process 75.

After the network interface layer protocol session 94 is successfully established, the user data 82 can then be exchanged in the t5 period. Assume that at this point node 56 leaves network 46 and begins to move towards network 48.

According to the cdma2000 standard, wireless capability networks, such as networks 46 and 48, constantly broadcast messages to confirm their identity. The broadcast message may be in the form of a "system parameter message" and may be in the form of an "extended system parameter message" sometimes carried over an F-BCCH (forward broadcast control channel), which is one of the forward control channels of the network. As such, a node, such as node 56, can always find its location by detecting broadcast messages from the network.

In the system parameter message, the SID (system identifier) and NID (network identifier) can be found above all. The SID is a number assigned to a specific wireless operator of the network, such as network 46 or 48. On the other hand, the NID is a number that uniquely identifies a particular network within a communication system, such as system 44.

The extended system parameter message includes a PZID (packet zone identifier) that identifies the coverage area of the PCF, such as the BSC / PCF 64 or 70 shown in FIG. If a communication system, such as system 44, supports High Speed Packet Data (HRPD), a code division multiple access (CDMA) based wireless data technology commonly known as 1xEV-DO, the subnet mask of another broadcast message called a "sector parameter message". And the subnet ID (identifier) instead of the PZID from the sector ID.

4 and 7, assume that node 56 receives a broadcast message from network 58 when node 56 reaches the area of network 58. First of all, a new NID appears from the broadcast message. The new NID is different from the previous counterpart. With the change of NID, node 56 knows that it has moved to another network. In this case, assume that network 48 does not support any non-PPP as its layer 2 protocol. As such, the PDSN 66 of the network 48 sends an LCP Configuration Request message 98. Node 56 then responds to LCP configuration request message 98. The reason can be justified that node 56 has entered a new network because of a change in NID, but so far no non-PPP messages such as Sync message 76 have been received. Instead, an LCP configuration request message 98 is received, which is a PPP message. Node 56 immediately knows that a newly arrived network, such as network 48, does not support any non-conventional Layer 2 protocol. This allows node 56 to quickly adapt itself to negotiate with PDSN 66 via PPP negotiation session 100 in the period t8. If successful, then user data 102 is exchanged in the t9 period as shown in FIG.

It should be noted that node 56 responds to LCP configuration request message 98 from network 48 in period t7 but not to LCP configuration request message 96 from network 46 in period t2. As described above, this is because node 56 knows the change in SID, NID or PZID in period t6 before period t7.

After successful execution of the PPP negotiation session 100, user data 102 may be established. At the end of user data 102, node 30 or NAS 33 may send a termination request message 104 to the other side, which then responds with termination Ack message 106 at t10 and t11 periods, respectively; End the communication session 92.

The relevant steps of the first handoff scheme according to this embodiment are shown in the flowchart of FIG. 8.

9 shows a second scheme, generally indicated at 108. Reference is made to FIG. 4 in conjunction with FIG. 9. As in the previous example, node 56 first passes link protocol session 94 prior to network access via serving PDSN 60. In addition, to secure a better opportunity to link node 56, LCP configuration request message 96 is sent by PDSN 60 during the period t2 as described previously. Upon successful execution of the non-PPP network interface layer protocol session 94, user data 92 is exchanged in the t4 period as shown in FIG. It is also assumed that during the flow of user data 82, node 56 leaves network 46 and begins to move towards network 48. In this example, node 56 receives an indication for handoff, which is different from the indication of the previous example.

Specifically, assume that node 56 receives another LCP configuration request message 110 in the t5 period as shown in FIG. 9 when node 56 reaches the area of network 48. At this time, the node 56, based on the different message IDs (identifiers) of the messages 110 and 96, as described later, the LCP configuration request message 110 for the t5 period and the LCP configuration request message 96 for the t2 period. Can be distinguished.

At this point, it is helpful to explain the data frame format of the PPP message.

10 is a schematic diagram of a data frame format used for PPP and with HDLC (high level data link control), such as framing.

The frame template for the data packet is generally indicated with reference 112, which is basically a packet template as specified under RFC 1662 for PPP. More specifically, data frame 112 includes flag field 114, address field 116, control field 118, protocol number field 120, data field 122, and FCS (frame check sequence) field 124. ).

To be backward compatible with PPP, most network interface layer protocols intended to replace PPP are designed in a frame format that is more or less similar to the frame format 112 for PPP. For example, the link protocol 75 disclosed in the '068 patent application shown in FIG. 6 may adopt a frame format similar to that of PPP.

Next, reference is made to FIG. 10.

The flag field 114 is one byte long and indicates the start of a data packet frame. The flag field 114 always represents the hexadecimal value of 7E and is the same value used in the link process 54 and PPP as required by RFC 1662.

The address field 116 is also one byte long and is always set to the hexadecimal value of FF as described in RFC 1662.

The control field 118 is one byte long and is fixed to a hexadecimal value of 03 as required by RFC 1662.

In the protocol number field 120, the value of this field indicates what the data packet 112 is. The protocol number field 120 is two bytes in length. For example, as specified in RFCs 1661 and 1662, LCP messages, such as the LCP Configuration Request message (Figure 2), each have a hexadecimal value of C021. In order to distinguish a PPP message from others, such as an LCP configuration request message or an LCP configuration Nak message (FIG. 2), another message ID is included in the data field 122 as described below. For other link protocols designed to replace PPP, such as the protocol 75 disclosed in the '068 application shown in FIG. 6, a different protocol number 120 is used to distinguish it from other PPP messages. For example, in the link process 75 shown in FIG. 6, the request message 78 or response message 80 used in the link process 75 (FIG. 6) is a unique protocol value that is different from any protocol value used in PPP. Has As such, it can be easily distinguished whether the data packet 112 is a PPP packet or a non-PPP packet.

The data field 122 has a payload length of zero or more bytes containing data or control information. For example, if the value of the protocol number field 120 is a value indicating that the data packet 112 is an LCP configuration request message 96 or 110 (FIG. 9), then the data field 122 is associated with each link 58 or 90. Includes all required communication parameter options related to establishment. In another example, if the value of the protocol number field 120 has a value indicating that the data packet 112 is user data 82 or 100 (FIG. 9), then the IP data packet generated from Layer 3 is a data field ( 122) completely encapsulated.

FCS field 124 is in the range of 2 to 4 bytes in length and includes basic codes such as CRC (cyclic redundancy code) for frame 112 to provide basic protection against errors in transmission.

Reference is again made to FIG. 9. As noted above, data field 122 is referred to as " code " under RFC 1661 and includes a message ID that distinguishes one PPP message type from others, such as between an LCP configuration request and an LCP configuration Ack message (FIG. 2). For example, a distinction may be made to message IDs within the same message type by attaching a sub-ID called "identifier" under RFC 1661. For example, LCP configuration request message 96 and LCP configuration request message 110 of process 108 shown in FIG. 9 may be implemented in different codes, or alternatively the same code but with different identifier characteristics of networks. As such, the network 48, 46 may transmit different LCP configuration messages 96, 110, respectively, by including different codes or identifiers inserted in the data field 122 of the data packet 112 (FIG. 10). Can be designed. Thus, in this example, when node 56 moves from network 46 to network 48, node 56 recognizes the LCP configuration request message as a different identifier from network 48 so that node 56 is in the area of network 48. It can be seen that it is within.

In the network 48, the node 56 does not receive a non-PPP message, but instead receives an LCP configuration request message 110, which is a PPP message and has an identifier different from that of the LCP configuration request message 96, but the node 56 knows that the network 48 does not support any non-PPP as its link establishment protocol. Quickly, node 56 adapts itself to respond to LCP configuration request message 110. Thereafter, the PPP negotiation 100 is executed as shown in FIG. The remaining process 108 is substantially similar to the process 92 shown in FIG. 7 described previously and does not repeat.

The relevant steps of the second handoff scheme according to this embodiment are shown in the flowchart of FIG.

Alternatively, a version / capacity identification packet may be inserted in the data field 122 of the data packet 112. Under the cdma2000 standard published by 3GPP2, a version / capacity identification packet may be included as specified in the document by 3GPP2 under the name “Wireless IP Network Standard” (TIA-835D). A version / capacity identification packet is basically a provider-specific packet that identifies the relevant information of a node's designated provider, such as node 56 or PDSN 60 or 66, as its name implies. Version / capacity identification packets are primarily exchanged in the LCP state of a PPP session. The purpose of exchanging version / capacity identification packets is to avoid unnecessary negotiation steps during the PPP session for features not supported by any node if the negotiating nodes specify their version and capacity early in the negotiation process.

By way of example, in a period t2, the node 56 of FIG. 9 receives an LCP configuration request message 96 having a version / capacity identification packet containing information that does not prohibit the use of any non-PPP, and thus a period of t3. Assume that node 56 does not immediately depend on the use of PPP for link establishment. Instead, node 56 continues the non-PPP link establishment process 94 in the period t3. On the other hand, if node 56 in period t5 receives an LCP configuration request message 110 with a version / capacity identification packet with information that only allows the use of PPP, node 56 receives the target node via PPP in period t6. Immediately adapt himself to negotiate with (66).

Alternatively, a separate version / capacity identification packet may be sent before the LCP configuration request message 96 or 110. Thus, for example, two messages may be sent by the target PDSN 66 in the t5 period. The first message is a version / capacity identification packet with provider specific information contained in the data field 122 of the data packet 112 (FIG. 10) as described above. The second message may be a regular LCP configuration request message, such as the first LCP configuration request message during the LCP negotiation phase 36 of the PPP session 34 shown in FIG. 2.

The relevant steps of the handoff scheme as just described are shown in the flow chart of FIG. 11A.

12 illustrates another handoff scheme, generally indicated at 130. Reference is made to FIG. 12 in conjunction with FIG. 4. As in the previous scheme, while in network 46, node 56 needs to go through a link establishment session 94 before network access. The LCP configuration request message 96 is also sent by the serving PDSN 60 of the network 46 during the t2 period during the session 94 as previously described to ensure a better opportunity to link the node 56. do. At this time, the LCP configuration request message 96 is sent between the other non-PPP messages of the link establishment session 94. Upon successful execution of the non-PPP network interface layer protocol session 94, user data 82 is exchanged in the t4 period as shown in FIG. 12 in a manner similar to that previously described. It is also assumed that while exchanging user data 82, node 56 leaves network 46 and begins roaming towards network 48.

When node 56 reaches the area of network 48, node 56 receives a number of LCP configuration request messages 132A-132N in the period t7, as shown in FIG. In this example, node 56 is based on the message transmission pattern and originated from LCP configuration request message 96 in network 46 in period t2 and LCP configuration request messages 132A-132N in network 48 in period t7. Can be distinguished. More specifically, in period t2, node 56 receives one LCP configuration message 96 among other non-PPP messages of link establishment session 94. Meanwhile, in the period t7, the node 56 receives a plurality of LCP configuration request messages 132A to 132N.

Thus, according to the reception pattern of the LCP configuration request message, node 56 knows whether the network in which it is currently located supports non-PPP. For example, node 56 may be programmed to respond only to a second consecutive LCP configuration request message. Thus, in this case, if node 56 receives LCP configuration request message 96 in period t2, node 56 waits for the next incoming message. If the next incoming message is not a repetition of the LCP configuration request message 96, the node 56 knows that the network 46 supports non-PPP other than PPP, and briefly the LCP configuration request message 96 in the period t2. Ignore and continue the non-PPP link session 94 as described above.

On the other hand, if node 56 receives, for example, two or more consecutive LCP configuration request messages 132A-132N during the t7 period, node 56 is the network to which the message is sent, in this case network 48 is PPP. It supports only and does not support other network interface layer protocols. The node 56 immediately relies on communication with the target PDSN 66 via the RAN 68 of the network 48 by PPP, as shown in FIG. 12. The remaining process 130 is substantially similar to the process 92 shown in FIG. 7 and FIG. 9 described previously, and thus will not be repeated.

It should be noted that the number of LCP configuration request messages 132A-132N that partition the response by node 56 depends on the configuration. For example, instead of initiating PPP negotiation 100 with the target PDSN 66 by the node 56 after the second LCP configuration request message 132B as described in the above example, the node 56 is configured to access the first i The PPP session 100 may well start after the LCP configuration request message 132i, where i is in the range of 2 to N and N is an integer greater than 2.

The relevant steps of the third handoff scheme according to this embodiment are shown in the flowchart of FIG.

14 schematically illustrates a portion of a hardware implementation of an apparatus, denoted by reference numeral 140, for example node 56 shown in FIG. 4, in accordance with an exemplary embodiment of the present invention. The device 140 may be configured and integrated in various forms such as a laptop computer, PDA or cellular phone, to name just a few.

Device 140 includes a central data bus 142 that couples the various circuits together. The circuit includes a CPU (central processing unit) or controller 144, a receiving circuit 146, a transmitting circuit 148, and a memory unit 150.

If device 140 is part of a wireless device, receive and transmit circuits 146 and 148 may be connected to RF (radio frequency) circuitry but are not shown in the figure. Receive circuit 146 processes and buffers the received signal prior to sending it to data bus 142. Meanwhile, the transmission circuit 148 processes and buffers data from the data bus 142 before sending it out of the device 140. The CPU / controller 144 performs data management functions of the data bus 142 and performs general data processing functions, including execution of instruction contents of the memory unit 140.

Instead of being individually arranged as shown in FIG. 14, the transmission circuit 148 and the reception circuit 146 may alternatively be part of the CPU / controller 144.

The memory unit 150 generally includes a set of instructions, indicated by reference numeral 152. In this embodiment, the instructions include, among other things, the protocol stack function 154, the link establishment client 156, the link handoff function 158, and the PPP function 160. The protocol stack function 154 executes a protocol stack similar to the stack 74 as previously shown and described in FIG. The link establishment client 156 includes a set of instructions for establishing one or more link processes in addition to a PPP link process such as the process 94 as shown in FIGS. 7, 9 and 12 above. PPP function 160 includes a set of instructions that cause device 140 to execute a PPP process. The link handoff function 158 includes a set of instructions for executing a handoff process, such as the processes 92, 108, 130 described and shown in the relevant figures of FIGS. 7-13. The PPP function 160 may be used independently of a network that supports both PPP or non-PPP link processes, or may be used as an alternate system if the network does not support other non-PPP link processes as described above. It may be.

In this embodiment, the memory unit 150 is a RAM (random access memory) circuit. Exemplary instructions 154, 156, 158, 160 are software routines or modules. The memory unit 150 may be coupled to other memory circuits (not shown), which may be of volatile type or of non-volatile type. Alternatively, memory unit 150 may comprise EEPROM (electrically erasable programmable read only memory), EPROM (electrically programmable read only memory), ROM (read only memory), ASIC (custom integrated circuit), magnetic disk, And other circuit types such as optical discs, and others known in the art.

Processes 92, 108, 130 as described and illustrated in FIGS. 7-13, 15, and 16 above may also be coded as computer readable instructions carried on any known computer readable medium. Be careful. In this specification and the appended claims, the term “computer readable medium” refers to any medium that participates in providing instructions to any process, such as the CPU / controller 144 shown and described in FIG. 14 for execution. . Such a medium may be of a storage type, or may have the form of a volatile or nonvolatile storage medium, for example, as described above in the description of the memory unit 150 of FIG. 14. Such a medium may also be of a transmission type and may include coaxial cables, copper wires, optical cables, and air interfaces carrying acoustic or electromagnetic waves capable of carrying signals readable by machines or computers.

Finally, the handoff procedure described in the embodiment is described as being executed during the exchange of user data 82 (see, for example, FIGS. 7, 9 and 12). This need not be true. Handoff may occur while node 56 is establishing a network interface layer protocol session 94. FIG. 15 shows a scenario in which the link process 92 as shown and described in FIG. 7 is highlighted, and some relevant steps are repeated for explanation. As shown, in the t4 period prior to the completion of the link establishment process 94, the node 56 is in the process of moving to the network 48, and detects a SID, NID, PZID or subnet ID change in the t4 period. As such, node 56 may not receive response message 80 from PDSN 60 of network 46 while on the move. However, if the node 56 receives the LCP configuration request message 98 during the t5 period, the node 56 knows that it is in the area of the network 48 and then starts the PPP negotiation process 100 in a manner similar to that described above. You can start immediately. Moreover, the same facts remain for the processes 108 and 130 shown and described in Figures 9 and 12, respectively. That is, the handoff process according to an exemplary embodiment of the present invention does not necessarily have to occur only during the user data exchange. In addition, system 44 has been described as supporting the cdma2000 standard. Other standards can also be explicitly applied. An example of other standards is WCDMA (Wideband Code Division Multiple Access) published by 3GPP (3rd Generation Partnership Project). In addition, in an exemplary embodiment the Layer 3 protocol is described as IP. IP may be another version, such as IPv4 (Internet Protocol Version 4) and IPv6 (Internet Protocol Version 6). Moreover, it should be noted that other layer 3 protocols may be equally applicable. For example, the Layer 3 protocol may be IPX (Internetworking Packet Switching Protocol), Apple-Talk, and other versions of various other network protocols. In addition, certain logical blocks, circuits, and algorithm steps described in connection with the embodiments may be implemented in hardware, software, firmware, or a combination thereof. It will be understood by those skilled in the art that these and other modifications in form and detail may be made without departing from the scope and spirit of the invention.

Claims (54)

A handoff method from a serving node to a target node in a communication system, Accessing the serving node via a first network interface layer protocol; Receiving an indication for the handoff; And Accessing the target node via a second network interface layer protocol. The method of claim 1, And receiving the indication comprises receiving a message having an identifier identifying the target node. The method of claim 1, And receiving the indication comprises receiving a data packet having a message identifier in the data field identifying the target node. The method of claim 1, And the step of receiving the indication comprises receiving a data packet having a version / capacity identification packet identifying the target node in a data field. The method of claim 1, And receiving the indication comprises receiving a plurality of request messages of the second network interface layer protocol from the target node. The method of claim 1, Exchanging user data with the serving node after accessing the serving node, wherein an indication of the handoff is received while exchanging the user data. The method of claim 1, And an indication of the handoff is received while accessing the serving node via the first network interface layer protocol. The method of claim 1, Accessing the serving node via the first network interface layer protocol comprises providing to the serving node a single message a set of parameter options for authentication, link configuration and network access. Way. A handoff method from a first node to a second node in a communication system supporting IP (Internet Protocol), Accessing the first node via a network interface layer protocol other than point-to-point protocol (PPP); Receiving an indication for the handoff; And Accessing the second node via the PPP. The method of claim 9, Accessing the first node via a network interface layer protocol other than the PPP includes providing the second node in one message with a set of parameter options for authentication, link configuration, and network access. Handoff method. The method of claim 9, The step of receiving an indication includes receiving a message having a message identifier identifying the second node, the message identifier being a NID (network identifier), a SID (system identifier), a PZID (packet) associated with the second node. And a subnet ID (subnet identifier). The method of claim 9, And receiving the indication comprises receiving a data packet including a code or identifier identifying the second node in a data field. The method of claim 9, And the step of receiving an indication comprises receiving a data packet including a version / capacity identification packet identifying the second node in a data field. The method of claim 9, And the step of receiving an indication comprises receiving a plurality of link control protocol (LCP) configuration request messages of the PPP from the second node. As a device of a communication system, Means for accessing a serving node of the communication system via a first network interface layer protocol; Means for receiving an indication for a handoff; And Means for accessing the target node via a second network interface layer protocol. The method of claim 15, And wherein the indication includes an identifier identifying the target node in a message. The method of claim 15, And the indication includes a message identifier identifying the target node in a data field of a data packet. The method of claim 15, And the indication comprises a version / capacity identification packet identifying the target node in a data field of a data packet. The method of claim 15, And the indication includes a plurality of request messages of the second network interface layer protocol from the target node. The method of claim 15, Means for accessing the serving node comprises means for providing the serving node with one message a set of parameter options for authentication, link configuration and network access. As a device of a communication system that supports IP (Internet Protocol), Means for accessing the first node via a network interface layer protocol other than PPP (Point-to-Point Protocol); Means for receiving an indication for a handoff; And Means for accessing a second node via the PPP. The method of claim 21, Means for accessing said first node comprises means for providing said second node in one message with a set of parameter options for authentication, link configuration, and network access. The method of claim 21, The indication includes a message having a message identifier identifying the second node, the message identifier being a NID (network identifier), a SID (system identifier), a PZID (packet zone identifier) and a subnet ID associated with the second node. Device of a communication system, characterized in that it is selected from the group consisting of (subnet identifier). The method of claim 21, Wherein the indication comprises a data packet having a code or identifier in the data field identifying the second node. The method of claim 21, And the indication comprises a data packet having a version / capacity identification packet in the data field identifying the second node. The method of claim 21, And the indication includes a plurality of link control protocol (LCP) configuration request messages of the PPP from the second node. As a device of a communication system, Computer readable instructions for accessing a serving node of the communication system via a first network interface layer protocol, receiving an indication for handoff, and accessing a target node of the communication system via a second network interface layer protocol. A memory unit comprising; And And a processor coupled to the memory unit to process the computer readable instructions. The method of claim 27, And wherein the indication comprises a message having an identifier identifying the target node. The method of claim 27, Wherein the indication comprises a data packet having a message identifier in the data field identifying the target node. The method of claim 27, And the indication comprises a data packet having a version / capacity identification packet identifying the target node in a data field. The method of claim 27, And the indication includes a plurality of request messages of the second network interface layer protocol from the target node. The method of claim 27, The memory unit further comprises computer readable instructions for exchanging user data with the serving node after accessing the serving node and initiating the handoff while the instruction is received during the exchanging user data. A device of a communication system, characterized in that. The method of claim 27, And the memory unit further comprises computer readable instructions for initiating the handoff while the indication is received while accessing the serving node via the first network interface layer protocol. The method of claim 27, And the memory unit further comprises computer readable instructions for providing, in one message, a set of parameter options for authentication, link configuration and network access while accessing the serving node. As a device of a communication system that supports IP (Internet Protocol), A memory unit including computer readable instructions for accessing a first node via a network interface layer protocol other than Point-to-Point Protocol (PPP), receiving an indication for handoff, and accessing a second node via the PPP ; And And a processor coupled to the memory unit to process the computer readable instructions. The method of claim 36, And the memory unit further comprises computer readable instructions for providing, in one message, a set of parameter options for authentication, link configuration and network access while accessing the second node. The method of claim 36, The indication includes a message having a message identifier identifying the second node, the message identifier being a NID (network identifier), a SID (system identifier), a PZID (packet zone identifier) and a subnet ID associated with the second node. Device of a communication system, characterized in that it is selected from the group consisting of (subnet identifier). The method of claim 36, Wherein the indication comprises a data packet having a code or identifier in the data field identifying the second node. The method of claim 36, And the indication comprises a data packet having a version / capacity identification packet in the data field identifying the second node. The method of claim 36, And the indication includes a plurality of link control protocol (LCP) configuration request messages of the PPP from the second node. A computer readable medium, Computer readable instructions for accessing a serving node of the communication system via a first network interface layer protocol; Computer readable instructions for receiving an indication for a handoff; And And computer readable instructions for accessing the target node via a second network interface layer protocol. The method of claim 42, And the indication comprises a message having a message identifier identifying the target node. The method of claim 42, And the indication comprises a data packet having a message identifier in the data field identifying the target node. The method of claim 42, The indication comprises a data packet having a version / capacity identification packet identifying the target node in a data field. The method of claim 42, And the indication comprises a plurality of request messages of the second network interface layer protocol from the target node. The method of claim 42, And further comprising computer readable instructions for exchanging user data with the serving node after accessing the serving node and initiating the handoff while the instruction is received during the exchanging user data. Readable Media. The method of claim 42, And computer readable instructions for initiating the handoff while the indication is received while accessing the serving node via the first network interface layer protocol. The method of claim 42, And computer readable instructions for providing, in one message, a set of parameter options for authentication, link configuration, and network access while accessing the serving node. A computer readable medium, Computer readable instructions for accessing the first node via a network interface layer protocol other than PPP (Point-to-Point Protocol); Computer readable instructions for receiving an indication for a handoff; And Computer readable instructions for accessing a second node via the PPP. 51. The method of claim 50, Computer readable instructions for providing, in one message, a set of parameter options for authentication, link configuration, and network access while accessing the second node. 51. The method of claim 50, The indication includes a message having a message identifier identifying the second node, the message identifier being a NID (network identifier), SID (system identifier), PZID (packet zone identifier) and subnet ID associated with the second node. (Subnet identifier). 51. The method of claim 50, And the indication comprises a data packet having a code or identifier in the data field identifying the second node. 51. The method of claim 50, And the indication comprises a data packet having a version / capacity identification packet in the data field identifying the second node. 51. The method of claim 50, The indication includes a plurality of link control protocol (LCP) configuration request messages of the PPP from the second node.

Images