CA2279667C - A mobile point-to-point protocol - Google Patents

A mobile point-to-point protocol Download PDF

Info

Publication number
CA2279667C
CA2279667C CA002279667A CA2279667A CA2279667C CA 2279667 C CA2279667 C CA 2279667C CA 002279667 A CA002279667 A CA 002279667A CA 2279667 A CA2279667 A CA 2279667A CA 2279667 C CA2279667 C CA 2279667C
Authority
CA
Canada
Prior art keywords
packet
server
packet server
point
lac
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Fee Related
Application number
CA002279667A
Other languages
French (fr)
Other versions
CA2279667A1 (en
Inventor
Mooi C. Chuah
Girish Rai
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia of America Corp
Original Assignee
Lucent Technologies Inc
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 Lucent Technologies Inc filed Critical Lucent Technologies Inc
Publication of CA2279667A1 publication Critical patent/CA2279667A1/en
Application granted granted Critical
Publication of CA2279667C publication Critical patent/CA2279667C/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478—Provisions for broadband connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5665—Interaction of ATM with other protocols
    • H04L2012/5667—IP over ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/36—Modification of an existing route due to handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14—Backbone network devices

Abstract

Apparatus for transferring packet data incorporates a "hand-off" feature that allows the transfer of an existing PPP connection from one packet server to another packet server. Such a hand-off control message or call continue transaction can be initiated by any of the servers involved in the transactions. For instance, assume an initial arrangement where a point-to-point call is set up and in progress between a user and a private network via a first packet server (e.g., a first Serving LAC) and a second packet server (e.g., an Anchor LAC). If, for example, the user moves out of the region served by the first packet server into a region served by a third packet server (e.g., a second Serving LAC), then a hand-off control message transaction, according to the invention, is initiated. Either the second Serving LAC or the Anchor LAC may initiate the call continue transaction. Alternatively, radius servers respectively associated with the packet servers may be employed to perform the call continue transaction.
Furthermore, assuming that a communication path is not yet established between the second packet server (e.g., Anchor LAC) and the third packet server (e.g., the second Serving LAC), a communication path (e.g., tunnel) set-up control message transaction may be performed concurrent with the call continue transaction. Still further, at least one packet server (e.g., the Anchor LAC) monitors state variables associated with the packet servers (e.g., the second Serving LAC and the private network) from which it receives packet data.

Description

A Mobile Point-to-Point Protocol Field of the Invention This invention relates generally to communications and, more particularly, to packet communications systems.
Background of the Invention One use of the Internet as a communications vehicle is as an enhanced data back-bone for coupling together workgroups to provide what is referred to as a "virtual private network" (VPN). One application of a VPN is in a corporate environment such that employees, e.g., at home, can remotely access, via the Internet, corporate data networks. A VPN provides security, and authentication, for a remote user to join a closed user group notwithstanding the use of public facilities. In effect, the use of a VPN provides a WAN-like vehicle to the corporation and its employees.
(Although the corporate network could also provide direct remote access, e.g., a user dials directly into the corporate network, there are economic advantages to the use of a VPN.) To provide a VPN, tunneling protocols are used such as the "Point-to-Point Tunneling protocol" (PPTP) and the "Layer 2 Forwarding" (L2F) protocol.
Generally speaking, a tunnel protocol enables the creation of a private data stream via a public network by placing one packet inside of another. In the context of a VPN, an IP packet is placed inside another IP packet. In an attempt to develop an industry standard, the Internet Engineering Task Force (IETF) is developing the "Layer 2 Tunneling Protocol"
(L2TP), which is a hybrid of the PPTP and L2F protocols (e.g., see K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W.
Verthein; Layer Two Tunneling Protocol "L2TP "; Internet draft, March, 1998).
For a remote user, a typical form of access to a VPN is via a "plain-old-telephone service" (POTS) connection to an "Internet service provider" (ISP) that provides the VPN
service. For example, a user incorporates an analog modem into a personal computer, or equivalent, and has a customer account with a particular ISP, referred to herein as the "home" ISP. (It is also assumed that the user's personal computer is properly configured to support one of the above-mentioned tunneling protocols). The user accesses the VPN by simply making a data call to the home ISP, e.g., dialing a telephone number associated with the "home" ISP and then "logging in" to the VPN.
Summary of the Invention Access to an ISP is via a network access server (NAS). We have realized that in a Personal Communications Service (PCS) wireless environment the above-described tunneling protocols do not allow a remote user, on an existing call, to change the NAS that is providing access to a VPN. As such, the user's physical mobility may disconnect, or drop, the user from the existing VPN connection.
In accordance with one aspect of the invention, an apparatus comprising packet equipment configured to be responsive to a hand-off notification associated with an existing wireless data call be transmitting a message signal to a packet server, the message signal including a communication path set-up request and a continue call request for establishing a communication path with the packet server for the existing wireless data call.
In an embodiment of the invention, three new hand-off control messages are defined for use with the packet servers, namely: (i) Continued Call Request, (ii) Continued Call Reply, and (iii) Continued Call Connect. These three new control messages comprise a L2TP control message header, message identifier (e.g., continued call request, etc.), and a number of fields. As a result, the user does not have to terminate the current PPP connection and then re-establish a new PPP connection.
Advantageously, such a hand-off control message or call continue transaction can be initiated by any of the servers involved in the hand-off scenario. For instance, assume an initial arrangement where a point-to-point call is set up and in progress between a user and a private network via a first packet server (e.g., a first Serving LAC) and a second packet server (e.g., an Anchor LAC). If, for example, the user moves out of the region served by the first packet server into a region served by a third packet server (e.g., a second Serving LAC), then a hand-off control message transaction, according to the invention, is initiated. In accordance with the invention, the second Serving LAC may initiate the call continue transaction or the Anchor LAC may initiate the call continue transaction. Alternatively, in accordance with another aspect of the invention, radius servers respectively associated with the packet servers may be employed to perform the call continue transaction.
In another aspect of the invention, assuming that a communication path is not yet established between the second packet server (e.g., Anchor LAC) and the third packet server (e.g., the second Serving LAC), a communication path (e.g., tunnel) set-up control message transaction may be performed concurrent with the call continue transaction.
Further, in yet another aspect of the invention, at least one packet server (e.g., the Anchor LAC) monitors state variables associated with the packet servers (e.g., the second Serving LAC and the private network) from which it receives packet data.
In accordance with one aspect of the present invention there is provided apparatus comprising: packet equipment configured to be responsive to a hand-off notification associated with an existing wireless data call associated with a pont-to-pint protocol connection by transmitting a message signal to a packet server, the message signal including a communication path set-up request and a continue call request for establishing, in accordance with a tunneling protocol, a communication path with the packet server for the existing wireless data call.

3a In accordance with another aspect of the present invention there is provided a method for use in a packet server comprising the steps o~ receiving a hand-off notification for a wireless call associated with a point-to-point protocol connection to a first packet server; transmitting a message signal to a second packet server including a communication path set-up request and a continue call request for establishing, in accordance with a tunneling protocol, a communication path with the second packet server; and completing the hand-off for the wireless call by subsequently transmitting packets to the second packet server such that the wireless call is not dropped.
In accordance with yet another aspect of the present invention there is provided a method for use in a packet server comprising the steps o~ establishing a point-to-point protocol connection with a first packet server and a second packet server;
monitoring state variables associated with packet data transmitted between the first packet server and the second packet server; and storing an n-tuple state variable set wherein n/2 state variables are associated with the first packet server and n/2 state variables are associated with the second packet server.
In accordance with still yet another aspect of the present invention there is provided apparatus comprising: packet equipment configured to: (i) participate in a point-to-point protocol connection with a first packet server and a second packet server;
(ii) monitor state variables associated with packet data transmitted between the first packet server and the second packet server; and (iii) store an n-tuple state variable set wherein n/2 state variables are associated with the first packet server and n/2 state variables are associated with the second packet server.
Brief Description of the Drawings FIG. 1 shows a communications system in accordance with the principles of the invention;

3b FIGS. 2 - 3 show flow charts of illustrative methods for use in the communications system of FIG. 1;
FIG. 4 shows an illustrative multi-hop message flow;
FIGs. 5 - 7 show illustrative control message transactions;

Chuan 18-14 4 FIG. 8 shows another embodiment of a communications system in accordance with the principles of the invention;
FIG. 9 shows an illustrative hand-off message flow;
FIG. 10 shows a' flow chart of an illustrative method for use ~~v f:he communications system of FIG. 8;
FIG. 11 shows illustrative control message transactions;
FIG. 12 shows another embodiment of a communications system in accordance with the principles of the invention;
FIG. 13 shows an illustrative hand-off message flow;
FIG. 14 shows a flow chart of an illustrative method for use in the communications system of FIG. 12;
FIG. 1 S shows illustrative control message transactions;
FIG. 16 shows an illustrative high level block diagram of Network Access Server; and FIGS. 17 - 18 show illustrative control message transactions for outgoing calls.
FIG. 19 shows alternative illustrative control message transactions;
-' E
FIG. 20 shows further alternative illustrative control message transacations;
FIG. 21 shows still father alternative illustrative control message transactions;
FIG. 22 shows an embodiment employing radius servers for performing a control message transaction; and FIG . 23 shows another embodiment employing radius servers for performing a control message transaction.

Chuan 18-14 5 Detailed Description It is to be appreciated that, for ease of reference, the following detailed description is divided into three topical sections: multi-hop point-to-point protc~m mobile point-to-point protocol; and payload message overviews and congestion control for mL2TP.
Multi-Hop Point-to-Point Protocol FIG. 1 shows an illustrative communications system 100 in accordance with the principles of the invention. Other than the inventive concept, the elements a.:~, ~~cii-known and will not be described in detail. For example, personal computer (PC) includes data communications equipment (not shown) for dial-up access through public-switched-network (PSTN) 110 to ISP B for establishing an Internet connection.
Likewise, the solid lines between elements of communications system 100 are representative of well-known communications facilities between the respective endpoints, e.g., the connection between PC 110 and PSTN 110 is representative of a local loop connection, the connection between ISP B and Internet 120 is supported by asynchronous transfer mode (ATM) over a synchronous optical network (SONET), etc.
Further, its assumed that the reader is familiar with the above-mentioned L2TP
protocol.
As can be observed from FIG. 1, communications system 100 comprises two ISPs: ISP A, represented by ISP A Network, and ISP B, represented by ISP B '.
~.; . ; ~i.
The ISP B Network comprises Network Access Server (NAS) 115, which includes a point-of presence (POP) router (not shown) as known in the art, a local network 120, and a router 125. Similarly, the ISP A Network comprises NAS 155, a local network 160, and a router 165. It is assumed that ISP A provides a VPN service for remotely located employees to access an illustrative Corporate Network via Network Server (NS) 135, which provides, among other functions, a routing and firewall capability.
('The Corporate network is assumed to be, e.g., a collection of local area networks (not shown) suitably protected behind NS 135.

Chuan 18-14 We have observed that a remote user may, even if only temporarily, be located in a portion of the country that is not served by ISP A but is, instead, served by ISf Further, ISP A may desire to extend such VPN coverage to other areas.
Therefore, and in accordance with the principles of the invention, a remote user is allowed to ac~~ss a VPN via a visiting, or serv'i'ng, ISP in addition to their home, or anchor, ISP. (,~'-' ° ;',F}
it is assumed that ISP A and ISP B are different service providers, this is not necessary to the inventive concept, e.g., they could just be separate networks w~
ISP.) Thus, a user (not shown) located at PC lU5 can access the corporate network while, e.g., roaming, about the country.
At this point, the following definitions are assumed:
mL2TP - the L2TP protocol as defined in K. Hamzeh, T. Kolar, M.
Littlewood, G. Singh Pall, J.Taarud, A. J. Valencia, W. Verthein; Layer Two Tunneling Protocol "L2TP' ; Internet draft, March, 1998; plus modifrcations as described herein;.
LAC - mL2TP Access Control, i.e., an NAS that supports mL2TP;
LNS - a NS that supports mL2TP;
Anchor LAC - a LAC that supports tunneling to the LNS for providing a VPN Service; and Serving LAC - a LAC that supports rtunneling to the Anchor LAC.
These definitions are used to simplify an illustrative description of the iriv~otive concept. As such, and as those in the art will realize, the inventive concept is not so limited and can be applied to any tunneling protocol and associated processing equipment.
In accordance with the inventive concept, the ISP A network illustrates an Anchor LAC 155 and the ISP B network illustrates a Serving LAC 115. As described further below, and in accordance with the principles of the invention, communications Chuan 18-14 system 100 of FIG. 1 provides a multi-hop tunnel. The example of FIG. 1 illustrates a two-hop tunnel. One hop is from the ISP B Network to the ISP A Network and the other hop is from the ISP A Network to the Corporate Network.
Reference should nQw be made to FIG. 2, which shows an illustrative high-level flow chart of a method in accordance with the principles of the invention. (It is presumed that Serving LAC 115 and the other respective servers are ~a~~r~t.a«
programmed to carry out the below-described methods using cu~'~.~...~,.~;~:~.
programming techniques, which, as such, will not be described herein.) In step 20'x. the remote user initiates a PPP (Point-to-Point Protocol) connection to ISP B via PSTN 110.
In step 210, Serving LAC 115 partially authenticates the user (e.g., using a preu~efined "username" and "password") and accepts the connection (represented by dotted line 1 of FIG. 1). (Alternatively, DNIS (dialed number identification service), CLID
(calling line identification), or other equivalent forms of identification could be used.) Obviously, if Serving LAC 115 can not authenticate the user, the connection is not 1 S accepted (this step is not shown).
As background, and as known in the art, when a remote user wishes to establish a new PPP session, PC 110 initiates a PPP LCP (Link Control Protocol) Config Request to the Serving LAC. The Serving LAC completes both the PPP LCP and PPP
PAP/CHAP phases, as known in the art, with the user's equipment before initiating any communication with the Anchor LAC in accordance with the inventive concept.
(I°~,r secure Conduits, the IETF has defined two pi-~~ocols for security over PPP
connections - the Password Authentication Protocol ( PAP) and the Challenge-Handshake Authentication Protocol (CHAP) (e.g., see IETF Request for Comment (RFC) 1334, "PPP Authentication Protocols").
In step 215, Serving LAC 115 determines is the remote user desires f ~~
VPN service. This selection could, e.g., be directly associated with particular "usernames" and/or be associated with a separate request from the user, e.g., via a pop-up "HyperText Transport Protocol" (http) form provided by Serving LAC 115.) 11 the remote user does not request a virtual dial-up service, Serving LAC 115 provides Chuan 18-14 g standard Internet access is step 220. However, if the remote user desires to use a VPN, then Serving LAC 115 identifies as associated Anchor LAC in step 225 (dea: s ibed below).
Serving LAC 115 Mores a VPN table that a priori associates, e.g., a use~-'~
identification with a particular Anchor LAC. A portion of such a table is shown below in Table One. In this example, the remote user associated with PC 110 is assert9~ted with Anchor LAC ISPA.com, i.e., Anchor LAC 1 S5.
Table 1 User Identification Anchor LAC
username ISPA.com It should be noted that equivalent structures, or operations, could be used, such as simply maintaining a list of fields formatted as "username@ISPA.com," where the portion after the "@" symbol indicates the Anchor LAC. Alternatively, ISP B
may maintain a database mapping users to services. In the case of a virtual-dial-up, i.e., an identification of the remote user as being associated with a VPN service, the mapping further identifies the Anchor LAC. Alternatively, the Serving LAC can utilize a Radius Access Request/Response transaction with its local Radius Server for this task, as known in the art.
In step 230, Serving LAC 11 S checks td see if a tunnel exists between itself and Anchor LAC 155. As such, Serving LAC 115 maintains a table, as illustrated in Table Two, below, of current tunnels, represented by a tunnel identification (Tid) value, associated call identifiers (Cid) of calls currently using that tunnel, and the associated Anchor LAC If address.
Table 2 TidCid Anchor LAC IP Address 2 5 h.'.k.l Chuan 18-14 9 If no tunnel connection currently exists between the Serving LAC and the Anchor LAC, then a tunnel is initiated by Serving LAC 115 to the Anchor LAC in step 235 (described below). Once a tunnel exists between the Serving LAC and the Awr'i-->F-LAC, Serving LAC 115, in step 240, allocates a new Cid, updates Table Two, any!
initiates a session with Anchor LAC 155 by forwarding a VPN request to Anchor ~ =~C' 155 via local network 120, router 125, Internet 130, router 165, and local network 160 (described further below). In this request, Serving LAC 115 conveys user a=' ~n information to Anchor LAC 155.
Turning now to FIG. 3, Anchor LAC 1 SS receives the request in step 305. In step 310, Anchor LAC 1 SS also performs authentication of the remote user (e.g., using a predefined "username" and "password" as noted above) and accepts the connection (represented by dotted line 2 of FIG. 1). (Alternatively, like the Serving LAC, DNIS, CLID, or other equivalent forms of identification could be used.) If Anchor can not authenticate the user, the connection is not accepted (this step is not shown). In this case, Serving LAC 115 similarly must convey an error message back t« ~v=
remote user (not shown).
Anchor LAC 155 stores a VPN table that a priori associates, e.g., a user's identification with a particular LNS. A portion of such a table is shown below in Table Three. In this example, the remote user associated with PC 110 is associated with Li~IS
135, represented by IP address g.h.i.j.
Table 3 -~!
User Identification LNS
username g.h.i.j Similar.to Serving LAC 115, it should be noted that equivalent structures, or operations, could be used. For example, the Anchor LAC may also perform this function via Radius Access Request/Response messages with a Home Radius Server. In step 315, Anchor LAC 155 checks if this is a valid VPN request using Table Three. If Chuan 18-14 10 this is not a valid request, Anchor LAC 155 denies the request in step 320. If this is a valid request, Anchor LAC 155 identifies the associated LNS from Table Three in ste,~
325.
It is assumed that tl~e Anchor LAC maintains the following connection table for each direction of communication for each established VPN session with a remote user:
Table 4 Serving Serving LAC LNS LNS U.~~er A,csigned LAC

' Connection Tid Cid IP Address Tid Cid IP AddressIP Address #

5 2 5 d.e.f.g 1 3 g.h.i.j a.b.c.d Anchor LAC associates with each VPN session a connection number. In addition, this connection number is mapped to the respective user. This table lists, by connection number, the Serving LAC IP Address (with associated tunnel ID and Call ID
values for that hop), and the associated LNS IP Address (with associated tunnel ID and Call 117 values for that associated hop). In step 330, Anchor LAC 155 establishes the VPN session (performs an authentication check, etc.). (Again, if LNS 135 should deny the VPN request (e.g., because of no authentication of the remote user or no capacity), appropriate error messages are generated by the Anchor LAC and the Serving LAC.) Other than the inventive concept, the VPN session with LNS 135 is established as in the prior art. For example, and in accordance with the principles of the invenvi~c~, _.
establishing a new VPN session Anchor LAC 155 allocates a new Cid and updates Table 4, e.g., adds a new connection. This last connection is represented by dotted line 3 of FIG. 1.
At this point, the connectivity is a point-to-point PPP session whose endpoints are the remote user's networking application on one end, as represented by PC
105, and the termination of this connectivity into LNS 135 PPP support on the other. It sh~~~l~ 1~
noted that accounting, if necessary, can be performed at the Serving LAC, the Anchor Chuan 18-14 11 LAC, as well as the LNS, i.e., each element may count packets, octets and connection start and stop times.
In support of the above-described multi-hop virtual dial up service, a form c ~' t!°
L2TP (mL2TP) protocol i$ used and described further below. As in L2TP, there are t S two parallel components of mL2TP operating over a given tunnel: control message;>
between each LAC-LNS pair, and payload packets between the same LAC-LNS pair.
The latter are used to transport mL2TP encapsulated PPP packets for usd ins between the LAC-LNS pair. As in L2TP, the Nr (Next Received) and Ns (Next Sent) ' fields are always present in control messages and are optionally present in payload packets. The control messages and payload messages use different sequencL ~~:
states. For the above-mentioned LAC/LNS pair scenario, there are no changes to the L2TP draft protocol definition as far as the maintenance and usage of (Nr, Ns) is concerned.
However, as between the connection between the Serving LAC and the Anchor LAC, the Anchor LAC merely monitors the (Nr, Ns) values sent by the Serving LAC.
That is, and in accordance with the inventive concept, the Anchor LAC simply re-transmits the values received from the Serving LAC to the LNS. In addition, the Anchor LAC now updates its (State Received, State Sent) values (Sr, Ss), with the corresponding (Nr, Ns) values it has observed from the packets sent by the Serving LAC. Since there will, undoubtedly, be packet losses between the Serving LAC
and the Anchor LAC; the Ss (Sr) value at the Anchor )r,AC may be smaller (smaller) than the Ss (Sr) value at the Serving LAC. In addition, the Anchor LAC maintains two sets of (Sr, Ss) variables, one for the Serving LAC/Anchor LAC control connection and the orrier for the Anchor LAC/LNS control connection.
Before PPP tunneling can occur, in accordance with the inventive concept, between the Serving LAC, the Anchor LAC, and the LNS, control messages must be exchanged between them. Control messages are exchanged over the same tunnel -~~dr~r~r~
will be subsequently used to forward payload data once mL2TP call control and management information have been passed (described below).

Chuan 18-14 12 In accordance with the inventive concept, additional Attribute Value Pairs (AVP)s (described below) are defined for use in the L2TP control messages (hence becoming mL2TP control messages). These additional AVPs are for supporting the multi-hop features and call transfer features described above. As defined in L2TP, AVPs are used to further specify control signaling.
As noted above, for the above-described LAC/LNS pair case, there is no ~b~n~e to the procedure described in the above-mentioned L2TP draft. As such, only .;~
hop case, requires additional procedures, described below.
An illustrative mufti-hop message flow is shown in FIG. 4. As can be observed from FIG. 4, a tunnel (identified by a Tid value) and a call (identified by a Cid value) are established between the Serving LAC and the Anchor LAC. Similarly, a ~u..Y.el and a call are established between the Anchor LAC and the LNS. As shown in FIG. 4, the inventive concept requires the Serving LAC establish a tunnel to the Anchor LAC. In the context of this invention, the Serving LAC treats the Anchor LAC as an LNS
and L2TP procedures are used to initially set up the tunnel.
Once a tunnel has been established, a number of control message transactions occur in order to set up a PPP session in accordance with the principles of the invention.
These are illustrated in FIGs. 5 - 7. In these FIGs., only the relevant fields are shown for the various control messages. Note, if the tunnel-id and call-id for the tunnel between the Serving LAC and the Anchor LAC are different from those values for the tunnel between the Anchor LAC and LNS, the~Anchor LAC modifies the relevant fields in the packet headers before relaying them in either direction.
As shown in FIG. 5, the Serving LAC first sends a Start-Control-Connect-Request Message (SCCRQ) message (as defined in L2TP) to the Anchor LAC to configure the tunnel between them. Upon receipt of this message, the Anchor LAC
then responds with an Start-Control-Connect-Reply Message (SCCRP) (this, :
.~~~b~r~, subsequent to any above-described authentication). The Serving LAC confirms with a Start-Control-Connection-Connect (SCCCN) message to the Anchor LAC.

Chuan 18-14 13 Following the start control connection message exchanges shown in FIG. 5, the Serving LAC sends an Incoming-Call-Request (ICRQ) message to the Anchor LAC as shown in FIG. 6. The Incoming-Call-Request message contains sufficient user data ,gyred credentials to enable the Anchor LAC to identify the LNS.
As noted earlier, if no tunnel exists between the Anchor LAC and the LNS, the Anchor LAC first initiates the SCCR, SCCRP, SCCCN message exchanges ~F~lth ~~~
LNS as defined in L2TP. Once the tunnel exists, an unused slot within the ~,4..:_~,~, :, Cid, is allocated by the Anchor LAC. At this point, and in accordance with the principles of the invention, the Anchor LAC relays the ICRQ message (from the Serving LAC) to notify the LNS of this new dial-up session. As shown in FICi~.
~ t~:~
Anchor LAC modifies the ICRQ message accordingly before relaying it to the T
FTC
The modified fields are indicated by a "*", e.g., the assigned call ID. The Anchor LAC
also adds a hidden AVP to inform LNS what receive window size it can support.
(Note that with the additional hop, the Anchor LAC records the maximum window size 1 S negotiated for both the control/payload connections. Also, the window size for the control connection between the Serving LAC and Anchor LAC may be different from that of the control connection between the Anchor LAC and LNS and buffering may be required. To eliminate additional buffering and sequence number monitoring, the Anchor LAC optionally adds an AVP to inform the LNS what receive window size for the payload session the Anchor LAC can support in the Anchor LAC-Serving LAC
direction. As a result, the LNS will include only appropriate receive window size values in its ICRP reply and hence only one window size for the payload session in the LNS-Anchor LAC-Serving LAC direction.
As noted earlier, the LNS either accepts the connection or rejects it.
Rejections MUST include a result condition and MAY include an error indication. In either case, the LNS sends an Incoming-Call-Reply (ICRP) message to the Anchor LAC as shown in FIG. 6. The Anchor LAC then modifies the ICRP message appropriately anE? :~
-it to the Serving LAC in accordance with the invention (again, modified fields are indicated by an "*" in FIG. 6). Since the packet processing delay (PPD) field received from the LNS only includes the processing delay at the LNS, the Anchor LAC add to Chuan 18-14 14 this value the processing delay at its own node. Then, the ICRQ message is relayed to the Serving LAC.
In response, the Serving LAC sends an Incoming-Call-Connected (ICCN) message to the Anchor LAS as shown in FIG. 7. Inside this message, the Serving I ~~' passes all the LCP Config Request information as well as the Proxy Authentication Information. That is, the Serving LAC is forwarding the results of the LCP
Config Request/Ack, PPP PAP/CHAP performed with the user's equipment. The Anchor LAC
modifies the PPD field of the received ICCN message before relaying it to the I.NS.
Currently, no use is made the tx connect speed and rx connect speed.) Although not shown, and in accordance with the invention, the Anchor LAC also relays ali ttie ~et-Link-Info, Hello and Wan-Error-Notify messages defined in L2TP. (It Shn~~1~ hP
observed that the description above illustrates the concept of mufti-hop packet tunnel.
For example, FIG. 1 represents a 2-hop packet tunnel.
It should be observed that the mufti-hop mL2TP tunnels described above occur exclusively at the frame layer. As such, actual policies of address management by the LNS are irrelevant to the above-described Virtual dial-up service since, for all purposes of the PPP protocol handling, the remote user appears to have connected at the LNS.
Mobile Point-to-Point Protocol Turning now to FIG. 8, another embodiment of the inventive concept is shown.
FIG. 8 is similar to FIG. 1. Other than the inventive concept, the elements are well-known and will not be described in detail. Like numbers indicate like functions and will not be further described except where necessary.
In FIG. 8, PC 805 includes data communications equipment (not shown) for establishing wireless access through Personal Communications Service (PCS) wireless network 810 to the Internet. PCS Wireless services are known in the art and will not be described in detail. PCS wireless network 810 comprises a plurality of mobile switching centers as represented by elements 815 and 820. Each switching center Chuan 18-14 15 serves a geographical area (not shown). It is assumed that elements 815 and include an NAS, e.g., Serving LACs similar to Serving LAC 115 of FIG. 1.
Initially, it is assumed that the remote user establishes a VPN session to the corporate network using the above-described mufti-hop technique. In particular, the remote user is io a geographical area such tha'tt this initial connection is routed through element ~~ 5 ~~~;
connections 814 and 816. In the context of a wireless PCS application, the initial PPP
connection is between element 815 and PC 805. Although shown as a pare ~f the switching elements for simplicity, the NAS functions could also be performed in separate pieces of equipment. Similarly, the other elements such as a local network and router are not shown for simplicity.
We have realized that in a wireless environment tunneling protocols; such as L2TP, do not allow a remote user to change the existing PPP connection from one switching element to another. For example, assuming for the moment that FIG. 8 does not embody the inventive concept, when the remote user roams, e.g., to a geographical area served by element 820 (and hence a different NAS) the user's communication session is handed-off to element 820 as known in the art. However, the existing PPP
connection - and hence the VPN session - is dropped and must be re-established since, as noted, there is no ability to transfer existing PPP connections from one NAS to another. In this context, the communications system of FIG. 8 overcomes this problem.
Therefore, and in accordance with the invention, an NAS or LAC incorporates a "hand-ofd' feature that allows the existing NAS to hand-off an existing PPP
connection to another NAS. In accordance with this feature, 3 new control messages are defined, namely: (i) Continued Call Request, (ii) Continued Call Reply, and (iii) Continued Call Connect. As a result of the above, the user does not have to terminate the current PPP
connection and then re-establish a new PPP connection. These 3 new control messages comprise a L2TP control message header, message identifier (e.g., continued call request, etc.), and a number of fields (described below).
In accordance with the inventive concept, an illustrative hand-off message flow is shown in FIG. 9. As can be observed from FLG. 9, a tunnel (identified by a Tid Chuan 18-14 16 value) and a call (identified by a Cid value) are initially established between element 815, which includes a Serving LAC, and the Anchor LAC. Similarly, a tunnel and a call are established between the Anchor LAC and the LNS. (A method for establishing this initial VPN session was described above.) As shown in FIG. 9, the inventive concept allows the existing Serving LAC to transfer the existing PPP conn~:
new Serving LAC, as represented by element 820.
Reference should now be made to FIG. 10, which is an illustrative flew ~;"dart of a method for use in providing a "hand-off feature." As noted, it is assumed that a ~~'N
' session exists between PC 805 and the Corporate network via element 815, which includes a Serving LAC, and Anchor LAC 155. In accordance with the inventive concept, PCS wireless network 810 adds to the existing call state variables additional variables indicating the presence (or lack thereof) of a PPP connection for each wireless call, and if a PPP connection exists, PPP connection information that includes the Anchor LAC identification, e.g., the IP address of the Anchor LAC.
In step 405 of FIG. 10, PCS wireless network 810 detects the need for a hand-off because PC 805 has moved from the geographical area served by element 815 to another geographical area, e.g., the area served by element 820, which includes another Serving LAC. In step 410, PCS Wireless system provides element 820 with notification of the impending hand-off. (The methods) used by a wireless system to detect aru prosecute a hand-off are known in the art and not relevant to the inventive concept. As such, they will not be described herein and -are represented by signaling path 811 of FIG. 8.) Since the call state information now includes a PPP session indicator and ~ ~'"' call information, the new Serving LAC (of element 820) identifies the Anchor LAC in step 415. In step 420, the new Serving LAC (of element 820) checks to see if there is an existing tunnel between itself and the identified Anchor LAC, here Anchor LAC
155.
If no tunnel exists, the new Serving LAC first establishes a tunnel (as describc;d earlier) in step 425. Then, and in accordance with the inventive concept, the new Serving LAC sends a Continued-Call-Request (CCRQ) message to the Anchor LAC in Chuan 18-14 1~
step 430. This CCRQ message includes the user's name associated with the existing PPP connection, the Tid and Cid values to be used for the transferred (new) PPP
session.
In step 435, the Anchor LAC recovers the user's name from the received CCRQ
message and uses this information to determine the LNS and IP address of the old Serving LAC, e.g., from a connection table represented by Table Four, above (this recovered information could also include the respective User Datagram Protocol (UDP) port number). In this step, the Anchor LAC sends a Call-Disconnect-Notify message ' (e.g., see L2TP) to the old Serving LAC and also identifies in, e.g., Table Four, above, the existing call variables associated with this PPP connection to the remote user, su~r~
as old tunnel-id, and old call-id. On the other hand, if the Anchor LAC should reject the Continued-Call-Request, the Serving LAC either sends a signal back to the user so that the existing PPP session can be torn down and a new PPP session can be initiated or the PPP session is simply dropped (steps not shown) .
In step 440, the Anchor LAC replies with a Continued-Call-Reply (CCRP) message with an appropriate Receive Window Size. The CCRP message includes information on the current Nr and Ns values. In step 445, the Anchor LAC
updates its connection table, e.g., Table 4, above, by replacing the entries for the Tid, Cid, and Serving LAC IP address fields (identified in step 435), with the new call information for' the existing PPP connection. In step 450, the new Serving LAC stores the Nr, Ns, into its Sr, Ss, vah~es and also stores the receive iwindow size from the received CCRP
message, if necessary, and sends a Continued-Call-Connect (CCCN) message to the Anchor LAC, which completes the hand-off.
In support of the above-described hand-off feature for a PPP protocol, FIG. 11 illustrates the above-mentioned new control message transactions in accordance with the principles of the invention. As shown in FIG. 11, a CCRQ message is sent to the identified Anchor LAC.
In this embodiment, a CCRQ message preferably comprises the following fields:

Chuan 18-14 1 g -Assigned Cid, - Call Serial No., - Bearer Type, - Physical Cannel ID, - Dialed No., - Dialing No., - Sub-Address, - Anchor LAC, - Challenge, - User AVP, - User's name, and - User's MIN/phone.
The Anchor LAC field presumes that this information is available during the hand-off. Alternatively, if the hand-off process does not provide information about the Anchor LAC to the New Serving LAC, the hand-off process must then provide enough user information to the New Serving LAC so that the New Serving LAC can search for the Anchor LAC information using help from a Foreign Radius Server as known in the art. That is, the New Serving LAC enquires about the Anchor LAC from a Home Radius Server via Radius Access/Response messages.
The User AVP information includes user information (such at the user's name) and other user credentials, e.g. mufti-hop virtual dial up service, user's identity (MIN), service provider's phone number etc.
Subsequent to the CCRQ message, the Anchor LAC sends a Call-Disconnect-Notify message to the old Serving LAC. Then, the Anchor LAC replies with Continued-Call Reply (CCRP) message that includes the current Sr, Ss values that it maintains.

Chuan 18-14 19 In this embodiment, a CCRP message preferably comprises the following fields:
- Assigned Cid, - Call Serial No.
- Result-Code, - Receive Window Size, - PPD, - Sequence No. AVP: Nr, Ns, - ACCM AVP, - Last Sent LCP Config. Request, - Last Rcv LCP Config. Request, - Challenge, and - Challenge Response.
Finally, the new Serving LAC replies with a Continued-Call Connect (CCCN) message. In this embodiment, a CCCN message preferably comprises the following fields:
- Connect Speed, - Framing Type, Modified Window Size AVP, - PPD, and - Challenge Response.
An alternative embodiment with respect to the control message transactions according to the invention is shown in FIG. 19. In such an embodiment, the hand-off control messages (CCRQ, CCRP, and CCCN) are advantageously combined T~et~ rh tunnel configuration (establishment) control messages (SCCRQ, SCCRP, and SCCCN) and are, respectively, concurrently transmitted between LACs. In this manner, transfer latency between the New Serving LAC and the anchor LAC is significantly improved.

Chuan 18-14 20 In this case, it is assumed that an existing PPP connection or session is already in progress between, for example, PC 805, Serving LAC 815, Anchor LAC 155 and NS
13 5 (FIG. 8). Then, in accordance with the mobility of the user, the PC 805 mo~ey;~ Per the coverage region of another serving LAC, e.g., Serving LAC 820. As mentioned, use of conventional methodology would result in the PPP connection being dropped ~1F:., requiring that the call be re-established. However, according to the invention, the call is handed-off to the new Serving LAC without interruption from the perspect~ '' ~-h~~
user. In the previous embodiment, assuming that a tunnel does not already exrst between the new ServingLAC and the Anchor LAC, the process for establishi~-':
,:
tunnel, for example, as illustrated in FIG. S, must be performed prior to the hand-off message exchange, for example, as illustrated in FIG. 11. However, in accordance with the embodiment illustrated in FIG. 19, the tunnel establishment process and hand-off process are performed concurrently. Advantageously, the latency associated with the communications between the new Serving LAC and the Anchor LAC is significantly reduce.
Tus, in order to concurrently perform tunnel establishment and call hand-off, the new Serving LAC (e.g., 820 in FIG. 8) attaches the SCCRQ message to the CCRQ
message before it sends the CCRQ message to the Anchor LAC. Then, as described above, the Anchor LAC uses the user's information to determine the old Tid value, old Cid value, and old IP/CTDP port and sends a Call-Disconnect-Notify (CDN) message to the old Serving LAC. Then, the Anchor LAC replies to the new Serving LAC ~;e~~
2 ~ ':' SCCRP message appended to the CCRP rri~ssage, Lastly, the new Serving LAC
transmits the combined CCCN and SCCCN messages to the Anchor LAC. It is to be appreciated that while the tunnel establishment control messages are appended to the hand-off control messages, the individual functions and information contained therein, as described above in detail, remain unchanged.
Also, while FIG. 19 shows certain fields as comprising the hand-off contra!
messages, such messages may contain the same or similar fields as shown in the messages shown in FIG. 11. In addition, it is to be appreciated that any of the fields shown in the context of FIGs 19, 20 and 21 with respect to CCRQ, CCRP, and CCCN, Chuan 18-14 21 may be present in the same messages of FIG. 11, and vice versa. Also, since these embodiments are illustrative in nature, none of the messages described herein are necessarily limited to the fields shown.
It is to be appreciated that the term "AVP" refers to Attribute Value Pairs, as ;~
known in PPP operations. Such AVPs are information contained in particular fields of the messages which provide the recipient equipment with relevant information.
For example, Window Size AVP and Modified Window Size AVP are fields 'which respectively indicate to the recipient the window capacity of the sender and a ' notification to modify the window size. Also, ALCM AVP refers to an Asynchronous Control Character Map AVP. This is a four octet bit map that enables/disables character escapes for 32 ASCII control characters in range 00(hex) to iF(hex).
Further, the Sequence No. AVP is the field used to transmit the state variables, Nr and Ns, between servers. Still further, the fields referred to as "Last Sent LCP (Link Control Protocol) Config. Request" and "Last Rcv LCP (Link Control Protocol) Config.
Request" are LCP options that are negotiated between servers during an LCP
phase associated with the set-up of a PPP session, as is known in the art.
Referring now to FIG. 20, a further alternative embodiment for performing the hand-off control message transaction is shown. In such an embodiment, it is to be appreciated that the Anchor LAC advantageously initiates the hand-off control message transaction with the new Serving LAC, rather than the new Serving LAC. That is, with respect to the 'arrangement illustrated in FIGS 8; and 9, rather than the new serving LAC
820 initiating the hand-off control message transaction, the Anchor Lac initiates the transaction, once it receives an indication from the PCS 810 (via a wireless link layer) that the PC 805 has moved from the region covered by the Serving LAC 81 S to the region covered by the Serving LAC 820. Thus, as shown in FIG. 20, the Anchor LAC
transmits the CCRQ message to the new Serving LAC, the new Serving LAC returns the CCRP message, and the Anchor LAC replies with the CCCN message. It is to '~:~w appreciated that the information contained in each message, and functions thereof, are similar to that discussed previously and, therefore, will not be repeated here. However, it may be noted that because the Anchor LAC initiates the transactions in FIG.
20, the Chuan 18-14 22 fields in the CCRQ message of FIG. 20, sent by the Anchor LAC, are similar to the fields in the CCRP message in FIG. 19, sent by the Anchor LAC. This is due to the fact that the Anchor LAC has this information and sends it to the Serving LAC
regardless of who initiates the transaction.
Also, it is to be appreciated that, as in the embodiment shown with rest FIG. 19, the tunnel establishement control message transaction may also be initiated by the Anchor LAC and, thus, the control message, SCCRQ, SCCRP, and SCCC:w, ~~ay respectively combined and concurrently transmitted with the hand-off control messages, CCRQ, CCRP and CCCN.
Turning now to FIG. 12, another embodiment of the inventive concept is shown, in the context of transferring an existing PPP connection from one NAS to ,:~
,other NAS, where the old NAS has a connection to the LNS. In this example, there is no Serving LAC per se, but simply, e.g., an Anchor LAC that is directly supporting an existing PPP connection. FIG. 12 is similar to FIG. 8. Other than the inventive concept, the elements are well-known and will not be described in detail. Like numbers indicate like functions and will not be further described except where necessary.
In FIG. 12, PC 805 includes data communications equipment (not shown) for establishing wireless access through Personal Communications Service (PCS) wireless network 910 to the Internet. PCS Wireless services are known in the art and will not be described in detail. PCS wireless network 910 comprises a plurality of mobile switching centers as represented by elements° 875 and 880. Each switching center serves a geographical area (not shown). It is assumed that elements 875 and 88~, include an NAS, e.g., LACs similar to Anchor LAC 115 of FIG. 1. Initially, it is assumed that the remote user establishes a VPN session to the corporate network as known in the art using, e.g., that portion of L2TP. In particular, the remote user is in a geographical area such that this initial connection is routed through element 875 via connections 874 and 876 to LNS 935. In the context of a wireless PCS
application, the initial PPP connection is between element 875 and PC 805. Although shown as a part of' the switching elements for simplicity, the NAS functions could also be performed in Chuan 18-14 23 separate pieces of equipment. Similarly, the other elements such as a local network and router are not shown for simplicity.
In this embodiment, the same hand-off procedure is carried out ~:;n iia'.
LAC/LNS pair except that the above-described CCRQ, CCRP, CCCN messages are S exchanged between the new LAC and LNS. In accordance with the inventive concept, an illustrative hand-off message flow is shown in FIG. 13. As can be observed from FIG. 13, a tunnel (identified by a Tid value) and a call (identified by a Cid value;; are initially established between element 875, which includes a LAC, and LNS 935.
As ' shown in FIG. 13, the inventive concept allows the existing LAC to transfer the existing PPP connection to a new LAC, as represented by element 880.
Reference should now be made to FIG. 14, which is an illustrative flow cln:.;:r ~:
a method for use in providing a "hand-off feature." As noted, it is assumed that a VPN
session exists between PC 805 and the Corporate network via element 875, which includes a LAC. In accordance with the inventive concept, PCS wireless network adds to the existing call state variables additional variables indicating the presence (or lack thereof) of a PPP connection for each wireless call, and if a PPP
connection exists, PPP connection information that includes the LNS identification, e.g., the IP
address of the LNS.
In step 505 of FIG. 14, PCS wireless network 910 detects the need for a hand-off because PC 805 has moved from the geographical area served by element 81 another geographical area, e.g., the area served 'by element 880, which includes another LAC. In step 510, PCS Wireless system provides element 880 with notification of the impending hand-ofd (The methods) used by a wireless system to detect and prosecute a hand-off are known in the art and not relevant to the inventive concept. As such, they will not be described herein and are represented by signaling path 911 of FIG.
12.) Since the call state information now includes a PPP session indicator and PPP
call information, the new LAC (of element 880) identifies the LNS in step S 15. In step X20, the new LAC (of element 880) checks to see if there is an existing tunnel between its~=l F
and the identified LNS, here LNS 935.

Chuan 18-14 24 If no tunnel exists, the new LAC first establishes a tunnel (as described earlier) in step 525. Then, and in accordance with the inventive concept, the new LAC
sends a Continued-Call-Request (CCRQ) message to the LNS in step 530. This CCR_O
message includes the user's name associated with the existing PPP connection, tl~e ~ :~
and Cid values to be used fnr the transferred (new) PPP session.
In step 535, the LNS recovers the user's name from the received CCRQ message and uses this information to determine the IP address of the old LAC (this ;
information could also include the respective User Datagram Protocol (UDP) port number). In this step, the LNS sends a Call-Disconnect-Notify message (e.g., see L2TP) to the old LAC and also identifies in, e.g., a connection table similar r.;~ ~,iac shown in Table Four, above, but sans the Serving LAC information etc., the existing call variables associated with this PPP connection to the remote user, such as old tunnel-id, and old call-id. On the other hand, if the LNS should reject the Continued-Call-Request, the new LAC either sends a signal back to the user so that the existing PPP session can be torn down and a new PPP session can be initiated or the PPP
session is simply dropped (steps not shown) .
In step 540, the LNS replies with a Continued-Call-Reply (CCRP) message with an appropriate Receive Window Size. The CCRP message includes information on the current Nr and Ns values. In step 545, the LNS updates its connection table by replacing the entries for the Tid, Cid, and LAC IP address fields (identified in step ''3 ~l, with the new-call information for the existinga PPP connection. In step 550, the new LAC updates the Nr, Ns, and receive window size from the received CCRP
message, if necessary, and sends a Continued-Call-Connect (CCCN) message to the LNS, which completes the hand-ofd In support of the above-described hand-off feature for a PPP protocol, FIG. 15 illustrates the above-mentioned new control message transactions in accordance with the principles of the invention. As shown in FIG. 15, a CCRQ message is sent to the identified LNS. Alternatively, if the hand-off process does not provide information about the LNS to the new LAC, the hand-off process must then provide enough user Chuan 18-14 25 information to the new LAC so that the new LAC can search for the LNS
information using help from a Foreign Radius Server as known in the art. That is, the new LAC
enquires about the LNS from a Home Radius Server via Radius Access/Response messages. Subsequent to the CCRQ message, the LNS sends a Call-Disconnect-Notify message to the old LAC. Then, the LNS replies with a Continued-Call Repl_, message that includes the current Sr, Ss values that it maintains. Finally, the new LAC
replies with a Continued-Call Connect (CCCN) message.
As described above, a PPP connection is transferred from one NAS to ar~~:rfher ' NAS. In support of the newly defined messages, additional call states are defined for the respective NAS as illustrated in Tables 5 and 6, below.
Table 5 - New LAC (or NAS) Call State ~~ Event Action New State idle hand-off notificationSend CCRQ wait-CCRP-reply wait-CCRP-replyReceive CCRP, Clean-up idle not acce ted, wait-CCRP-replyReceive CCRP, Send CCCN established, acce ted, As can be observed, the additional, or~ new, call state for mL2TP associated with the new LAC (or NAS) for a continued call is the wait-CCRP-reply state.
Referring now to FIG. 21, still a further alternative embodiment for performing the hand-off control message transaction is shown. In such an embodiment, it is to be appreciated that the LNS initiates the hand-off control message transaction with the new Serving LAC, rather than the new Serving LAC. That is, with respect to the arrangement illustrated in FIGS 12 and 13, rather than the new serving LAC 880 initiating the hand-off control message transaction, the LNS initiates the transaction, once it receives an indication from the PCS 910 (via a wireless link layer) that the PC

Chuan 18-14 26 805 has moved from the region covered by the Serving LAC 875 to the region covered by the Serving LAC 880. Thus, as shown in FIG. 21, the LNS transmits the CC;RQ
message to the new Serving LAC, the new Serving LAC returns the CCRP message, and the LNS replies with the CCCN message. It is to be appreciated that the information contained in each message, and functions thereof, are similar to th~.~
was discussed previously and, therefore will not be repeated here. Also, it appreciated that, as in the embodiment shown with respect to FIG. 19, the tunnel establishment control message transaction may also be initiated by the LNS
and, thus, the control messages, SCCRQ, SCCRP, and SCCCN, may be respectively cc~x~~~l~ee5hc.d and concurrently transmitted with the hand-off control messages, CCRQ, CCRP.
and CCCN.
Referring now to FIGs 22 and 23, respective alternative embodiments for performing a hand-off control message transaction, according to the invention, uy employing radius servers are shown. Particularly, FIG. 22 shows an arrangement similar to the arrangement shown in FIGs 8 and 9, while FIG 23 shows an arrangement similar to the arrangement shown in FIGs 12 and 13. As previously mentioned radius servers, as are known in the art, may be used by the other servers (e.g., Serving LAC, Anchor LAC, LNS) employed in the communication path to assist in identifying and/or confirming particular information necessary for performing communication functions.
For instance, as mentioned, a radius server operatively coupled to a Serving LAC may contain a database which associates a particular user with a particular Anchor LAC. In this way, the Serving LAC consults with ~ its radius server to determine such information. Likewise, the Anchor LAC may consult a radius server (1-iutu~~, operatively coupled thereto, to determine similar information pertaining to a user and the LNS with which he is associated.
However, according to the invention, the radius servers may be advantageously utilized to also . perform a hand-off control message transaction therbetween.
That is, rather than a Serving LAC and an Anchor LAC or a Serving LAC and an LNS
performing the transaction, respective radius servers operatively coupled thereto and to one another are used to transfer these control messages. In such case, the Serving LAC, Chuan 18-14 27 Anchor LAC, and LNS are merely tasked with performing any additional processing caused by these messages.
FIG. 22 shows such an arrangement int he context of a hand-off ou « if'P
connection from and old Serving LAC 815 to a new Serving LAC 820 with respect trt the Anchor LAC. A radius server 822, associated with the new Serving LAC R2n communication with a radius server 824, associated with the Anchor LAC. Thus, according to the invention, when a hand-off notification is received from the PCS 8 i (FIG. 8), the radius servers 822 and 824 directly transfer the control messages, CCRQ, ' CCRP, and CCCN, therebetween. In accordance with the invention, either radius server may initiate the transfer.
Similarly, FIG. 23 shows such an arrangement in the context of a hand-off of a PPP connection from an old Serving LAC 875 to a new Serving LAC 880 with respect to the LNS 935. A radius server 922, associated with the new Serving LAC 880, is in communication with a radius server 924, associated with the LNS. Thus, according to the invention, when a hand-ofd notification is received from the PCS 910 (FIG.
12), the radius servers 922 and 924 directly transfer the control messages, CCRQ, CCRP, and CCCN, therebetween. In accordance with the invention, either radius server may initiate the transfer.
Payload Message Overviews and Co~estion Control or mL2TP
With respect to payload messages for~~mL2TP, the Serving LAC and the LNS
follow L2TP procedures. The Anchor LAC swaps the Tid and Cid for the payload packets. The Anchor LAC also monitors the (Nr, Ns) values sent by the Serving LAC.
(It should be noted that since there may be packet losses between the Serving LAC and the Anchor LAC, it is expected that both the Sr and Ss values at the Anchor LAC may be lagging behind those values maintained at the Serving LAC.) The Anchor LAC
does not change the {Nr, Ns) of the payload packets in either directions. The Anchor lva"~~~' only makes use of its own Sr, Ss values when it receives a Continued-Call Request message from a new Serving LAC.

Chuan 18-14 2g With respect to congestion control, the L2TP requirements on when to abide t~
receive window size, when to send NrINs, and when to send an ACK apply to mL2TP.
In addition, mL2TP also has the following additional requirements for the Serving LAC
and the Anchor LAC.
S The Anchor LAC is required to monitor the (Nr, Ns) value sent by the Servin~f LAC. The Anchor LAC should include the (Sr, Ss) value it maintains in the Continued-Call-Reply message when it replies to the Continued-Call-Connect message it c ~~:.'iv~;
from a Serving LAC. Since a network between the Serving LAC and an Anchor LAC
is lossy, the Sr value maintained by an Anchor LAC may be lagging behind the Serving LAC.
The following is a detailed description of the payload processing ml ~., associated with mL2TP, as affected by the mufti-hop point-to-point protocol of the invention. As mentioned, for the mufti-hop scenario, the Anchor LAC performs the swappin gof the Tid and Cid values for the payload packets. In addition, the Anchor 1 S LAC maintains a 4 tuple state variable ( Sr ~ , Ss' , Sr ', Ss' ) for nL2TP payload packets.
The Anchor LAC stores the (Nr, Ns) value sent by the Serving LAC in (Sr' , Sss ) and the (Nr, Ns) values from the LNS in (Sr'~, Ss' ).
Note that since there may be packet losses and/or delay between the serving lAC
and the Anchor LAC, it is expected that Srs <Sr and Sss <Ss, where Sr and Ss are the state variables maintained at the serving LAC. Similarly, since there are also packet losses and/or delays between the Anchor LAC and LNS, it is expected that ,~r ' < S'r and Ss' < Ss , where Sr and Ss are the state variables maintained at the LNS.
It is to be appreciated that the Anchor LAC will not change the (Nr, Ns) values of the payload packets in either direction. Three example are given below to illustrate how state variable monitoring according to the invention operates.
The first monitoring example is with respect to the case where the communication scenario converts from the one-hop to a two-hop arrangement. It is to be understood that a one-hop arrangement includes, for example, communication links Chuan 18-14 29 between a PC, an Anchor LAC, and an LNS. A two-hop arrangement includes, for example, communication links between a PC, a Serving LAC, an Anchor LAC, and an LNS. If the Anchor LAC previously maintains a two tuple state variable for a PPP
session and receives a CCRQ message, then the Anchor LAC knows that it needs to convert from a one-hop session to a two-hop session. The Anchor LAC first sets Nr =
Sr and Ms = Ss in the CCRP message using its current two tuple state variable, (Sr, Ss).
Then, the Anchor LAC changes the state variables into four typle, setting Sr S
= Sr .
Ss'' = Ss , Sr ' = x, and Sr ' = x . When the Anchor LAC receives the first packet from the LNS after the handover, it updates the Ss' and Sr' variables with the observed (Nr, Ns) values. For example, assume the old LAC has Ss = 13 and Sr = 6, and the LNS ~~
Ss = 7 and Sr = 10. The Old LAC, which is now the Anchor LAC, sets Nr = Sr and Ns = Ss in the CCRP message. After the handover, the new Serving LAC has Ss = 13 and Sr = 6, the LNS has Ss = 7+ and Sr = 10+~ and the Anchor LAC (old LAC) has Sss =13 , Sr' = 6 , Ss' = 7 +~ and Sr ' =10 +, It is to be appreciated that the plus sign (+) at the end of certain values means that the value could be larger, depending on whether the sequence numbers are being updated during the hand-off process.
The second monitoring example is with respect to the case where the communication scenario converts from a two-hop to a one-hop arrangement.
Again, it is to be understood that a one-hop arrangement includes, for example, communication links between a PC, an Anchor LAC, and an LNS, while a two-hop arrangement includes, for example, communication links between a PC, a Serving LAC, an Anchor LAC, and an LNS. If the Anchor LAC receives indication that a two-hop PPP
session is turned into a one-hop session (e.g., receiving a link layer handover message rather than a mL2TP CCRQ message), the Anchor LAC turns the four tuple state variable into a two tuple state variable and sets Ss = Sss and Sr = Ss' . For example, assume the new Serving LAC has Ss = 13 and Sr = 5, the LNS has Ss = 7 and Sr = 10, and the Anchor LAC has Sss =12, Srs = 4, Ss' = 6, and Sr' = 9 . Then, after conversion from the two-hop to the one-hop arrangement, the Anchor LAC has Ss = 12 and Sr = 6 and the LNS has Ss =7+ and Sr = 10+.

Chuan 18-14 30 The third monitoring example is with respect to the case where the communication scenario converts from a two-hop to another two-hop arrangement, for example, as shown in FIG. 9. If the Anchor LAC receives a CCRQ message and the PPP session is already a two-hop session, then the Anchor LAC knows that there is a change of Serving LACs. 'The Anchor LAC then sets Nr = SsL and Ns = Sss in the CCRP message. The Anchor LAC also updates Sr' to Sr' = SsL . For example, assume the old Serving LAC has SS = 13 and Sr = S, the LNS has Ss = 7 and Sr =
10, and the Anchor LAC has Sss =12, Srs = 4, SsL = 6, and SrL = 9 . Then, the Ancor LAC sets Ns = Sss and Nr = Ss' in the CCRP message sent to the new Serving LAC.
After the handover, the new Serving LAC has Ss = 12 and Sr = 6, the LNS has Ss ~7+
and Sr = 10+~ and the Anchor LAS has Sss =12, Sr' = 4, SsL = 6+, and Sr L = 9 +
In addition, the Serving LAC implements a full receiver rather than a simple receiver, as referred to in the art. This requirement is to prevent the new Serving LAC
from passing out-of sequence or duplicate packets to upper layers when there is a 1 S change of Serving LAC during the lifetime of a PPP session.
Turning briefly to FIG. 16, a high level block diagram of a representative NAS
is shown. An NAS is a stored-program-control based processor architecture and includes processor 650, memory 660 for storing program instructions and data, e.g., the above-mentioned connection tables, etc., and communications interfaces) 665 for coupling to one or more communication facilities as represented by path 666.
The foregoing merely illustrates the principles of the invention and it will ,4.;
be appreciated that those skilled in the art will be able to devise numerous alternative arrangements which, although not explicitly described herein, embody the principles of the invention and are within its spirit and scope. For example, although the inventive concept was described in the context of a Serving NAS initiating the establishment of a mufti-hop tunnel for incoming calls, the inventive concept is equally applicable to, ~.~ ~ , the LNS initiating the establishment of a mufti-hop sequence for outgoing calls. Such modifications are straightforward and will not be described herein as illustrated by

Claims (43)

Claims:
1. Apparatus comprising:
packet equipment configured to be responsive to a hand-off notification associated with an existing wireless data call associated with a point-to-point protocol connection by transmitting a message signal to a packet server, the message signal including a communication path set-up request and a continue call request for establishing, in accordance with a tunneling protocol, a communication path with the packet server for the existing wireless data call.
2. The apparatus of Claim 1, wherein the packet equipment is a network access server.
3. The apparatus of Claim 1, wherein the packet equipment is configured for receiving a message signal from the packet server, the message signal being responsive to the communication path set-up request and the continue call request.
4. The apparatus of Claim 3, wherein the packet equipment is configured for transmitting a second message signal to the packet server, the second message signal being responsive to the message signal received from the packet server.
5. Apparatus comprising:
packet equipment configured to permit an existing wireless point-to-point protocol connection with a first packet server to be transferred to a second packet server, the packet equipment initiating the transfer in response to a hand-off notification associated with the existing point-to-point protocol connection, the packet equipment being further configured for establishing a tunnel to the second packet server to convey packets from a source which previously conveyed packets over a tunnel established between the first packet server and the packet equipment.
6. The apparatus of Claim 5, wherein the packet equipment is configured to be responsive to signaling received from the second packet server.
7. The apparatus of Claim 6, wherein the packet equipment is configured for transmitting signal responsive to the signaling received from the second packet server.
8. The apparatus of Claim 5, wherein the packets are encapsulated in another packet.
9. The apparatus of Claim 5, wherein the packet equipment is configured for transmitting a message signal to the second packet server, the message signal including a communication path set-up request and a continue call request for establishing a communication path with the second packet server for the existing point-to-point connections.
10. Apparatus comprising:
packet equipment associated with a first radius server and configured to be responsive to a hand-off notification associated with an existing wireless data call of a point-to-point protocol connection by transmitting a message signal to packet equipment associated with a second radius server, the message signal including a continue call request for establishing, in accordance with a tunneling protocol, a communication path between a first packet server operatively coupled to the first radius server and a second packet server operatively coupled to the second radius server.
11. The apparatus of Claim 10, wherein the packet equipment associated with the first radius server is configured for receiving a message signal from the packet equipment associated with the second radius server, the message signal being responsive to the continue call request.
12. The apparatus of Claim 11, wherein the packet equipment associated with the first radius server is configured for transmitting a second message signal to the packet equipment associated with the second radius server, the second message signal being responsive to the message signal received from the packet equipment associated with the second radius server.
13. Apparatus comprising:
packet equipment which is configured to participate in a communication session through a point-to-point protocol (PPP) connection with a first packet server and a second packet server established in accordance with a tunneling protocol and to monitor sequence number state variables associated with packet data transmitted between the first packet server and the second packet server so as to maintain the communication session, including packet order, in the presence of a change in the PPP
connection without a need to reestablish the PPP connection.
14. The apparatus of Claim 13, wherein a tunnel protocol is used to establish the point-to-point connection.
15. The apparatus of Claim 13, wherein the packet equipment stores a state variable set including a predetermined number of state variables wherein one half of the state variables are associated with the first packet server and the other half of the state variables are associated with the second packet server.
16. The apparatus of Claim 13, wherein the first packet server is a private network.
17. The apparatus of Claim 16, wherein the second packet server is coupled to a source such that a multi-hop communication path is established between the source and the private network.
18. Apparatus for transferring packet data comprising:
a packet server configured for maintaining a wireless point-to-point protocol connection established with a first packet server, transmitting a message signal which includes a continue connection request to a second packet server in response to receipt of a hand-off notification, transmitting a message signal to the first packet server which includes notification that the point-to-point protocol connection between the packet server and the first packet server is to be disconnected, and transferring the point-to-point protocol connection to the second packet server, wherein point-to-point protocol connections between the servers are established according to a tunneling protocol.
19. Apparatus for transferring packet data comprising:
a packet server configured for maintaining a wireless point-to-point protocol connection established with a first packet server, receiving a message signal which includes a connection set-up request and a continue connection request from a second packet server in response to receipt of a hand-off notification, transmitting a message signal to the first packet server which includes notification that the point-to-point protocol connection between the packet server and the first packet server is to be disconnected, and transferring the point-to-point protocol connection to the second packet server, wherein point-to-point protocol connections between the servers are established according to a tunneling protocol.
20. A method for use in a packet server comprising the steps of:
receiving a hand-off notification for a wireless call associated with a point-to-point protocol connection to a first packet server;
transmitting a message signal to a second packet server including a communication path set-up request and a continue call request for establishing, in accordance with a tunneling protocol, a communication path with the second packet server; and completing the hand-off for the wireless call by subsequently transmitting packets to the second packet server such that the wireless call is not dropped.
21. The method of Claim 20, further comprising the step of receiving a message signal from the second packet server, the message signal being responsive to the communication path set-up request and the continue call request.
22. The method of Claim 21, further comprising the step of transmitting a second message signal to the second packet server, the second message signal being responsive to the message signal received from the second packet server.
23. A method for use in a packet server comprising the steps of:
establishing a wireless call associated with a point-to-point protocol connection to a first packet server for communicating packets with the first packet server;
transmitting a continue call request signal, in response to a hand-off notification signal associated with the call, to a second packet server;
transferring the call to the second packet server such that packets are now communicated with the second packet server;
wherein communication between servers is established according to a tunneling protocol.
24. The method of Claim 23, further comprising the step of receiving a message signal from the second packet server, the message signal being responsive to the continue call request signal.
25. The method of Claim 24, further comprising the step of transmitting a second signal to the second packet server, the second signal being responsive to the message signal received from the second packet server.
26. A method for use in a packet server comprising the steps of:
receiving a hand-off notification for a wireless call associated with a point-to-point protocol connection to a first packet server;
directing a radius server, operatively coupled to the packet server, to transmit a message signal to a radius server, operatively coupled to a second packet server, the message signal including a continue call request for establishing a communication path, in accordance with a tunneling protocol, with the second packet server; and completing the hand-off for the wireless call by subsequently transmitting packets to the second packet server such that the wireless call is not dropped.
27. A method for use in a packet server comprising the steps of:
establishing a communication session through a point-to-point protocol (PPP) connection with a first packet server and a second packet server in accordance with a tunneling protocol; and monitoring sequence number state variables associated with packet data transmitted between the first packet server and the second packet server so as to maintain the communication session, including packet order, in the presence of a change in the PPP connection without a need to reestablish the PPP connection.
28. The method of Claim 27, wherein a tunnel protocol is used to establish the point-to-point connection.
29. The method of Claim 27, further comprising the step of storing a state variable set including a predetermined number of state variables wherein one half of the state variables are associated with the first packet server and the other half of the state variables are associated with the second packet server.
30. A method for use in a packet server comprising the steps of:
establishing a point-to-point protocol connection with a first packet server and a second packet server;
monitoring state variables associated with packet data transmitted between the first packet server and the second packet server; and storing an n-tuple state variable set wherein n/2 state variables are associated with the first packet server and n/2 state variables are associated with the second packet server.
31. The method of Claim 30, wherein a tunnel protocol is used to establish the point-to-point protocol connection.
32. Apparatus comprising:
packet equipment configured to: (i) participate in a point-to-point protocol connection with a first packet server and a second packet server; (ii) monitor state variables associated with packet data transmitted between the first packet server and the second packet server; and (iii) store an n-tuple state variable set wherein n/2 state variables are associated with the first packet server and n/2 state variables are associated with the second packet server.
33. The apparatus of Claim 32, wherein a tunnel protocol is used to establish the point-to-point protocol connection.
34. The apparatus of Claim 32, wherein the first packet server is a private network.
35. The apparatus of Claim 32, wherein the second packet server is coupled to a source such that a multi-hop communication path is established between the source and the private network.
36. The apparatus of Claim 13, wherein the change in the PPP connection includes the removal of the second packet server.
37. The apparatus of Claim 13, wherein the change in the PPP connection includes the replacement of the second packet server with a third packet server.
38. The method of Claim 27, wherein the change in the PPP connection includes the removal of the second packet server.
39. The method of Claim 27, wherein the change in the PPP connection includes the replacement of the second packet server with a third packet server.
40. Apparatus comprising:
packet equipment which is configured to participate in a communication session through a point-to-point protocol (PPP) connection with a source and at least one packet server established in accordance with a tunneling protocol and to monitor sequence number state variables associated with packet data transmitted between itself and the at least one packet server so as to maintain the communication session, including packet order, in the presence of a change in the PPP connection without a need to reestablish the PPP connection.
41. The apparatus of Claim 40, wherein the change in the PPP connection includes the addition of a second packet server between the source and the packet equipment.
42. A method for use in a packet server comprising the steps of:
establishing a communication session through a point-to-point protocol (PPP) connection with a source and at least one packet server in accordance with a tunneling protocol; and monitoring sequence number state variables associated with packet data transmitted between itself and the at least one packet server so as to maintain the communication session, including packet order, in the presence of a change in the PPP
connection without a need to reestablish the PPP connection.
43. The method of Claim 42, wherein the change in the PPP connection includes the addition of a second packet server between the source and the packet equipment.
CA002279667A 1998-09-09 1999-08-05 A mobile point-to-point protocol Expired - Fee Related CA2279667C (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/150,403 US6496491B2 (en) 1998-05-08 1998-09-09 Mobile point-to-point protocol
US09/150,403 1998-09-09

Publications (2)

Publication Number Publication Date
CA2279667A1 CA2279667A1 (en) 2000-03-09
CA2279667C true CA2279667C (en) 2004-10-05

Family

ID=22534366

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002279667A Expired - Fee Related CA2279667C (en) 1998-09-09 1999-08-05 A mobile point-to-point protocol

Country Status (5)

Country Link
US (2) US6496491B2 (en)
EP (2) EP1549006B1 (en)
JP (2) JP3613453B2 (en)
CA (1) CA2279667C (en)
DE (1) DE69941885D1 (en)

Families Citing this family (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8606851B2 (en) 1995-06-06 2013-12-10 Wayport, Inc. Method and apparatus for geographic-based communications service
US5835061A (en) 1995-06-06 1998-11-10 Wayport, Inc. Method and apparatus for geographic-based communications service
US7136645B2 (en) * 1998-10-09 2006-11-14 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7778260B2 (en) 1998-10-09 2010-08-17 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US8060656B2 (en) 1998-10-09 2011-11-15 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US8078727B2 (en) 1998-10-09 2011-12-13 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US6502135B1 (en) 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US10511573B2 (en) 1998-10-30 2019-12-17 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US7418504B2 (en) 1998-10-30 2008-08-26 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US6839759B2 (en) 1998-10-30 2005-01-04 Science Applications International Corp. Method for establishing secure communication link between computers of virtual private network without user entering any cryptographic information
ES2760905T3 (en) 1998-10-30 2020-05-18 Virnetx Inc An agile network protocol for secure communications with assured system availability
EP1059777A4 (en) * 1998-12-28 2003-01-15 Ntt Docomo Inc Communication control system, communication method, server device, terminal, relay device, and communication system
US7882247B2 (en) 1999-06-11 2011-02-01 Netmotion Wireless, Inc. Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
US6694437B1 (en) * 1999-06-22 2004-02-17 Institute For Information Technology System and method for on-demand access concentrator for virtual private networks
SG119208A1 (en) * 1999-09-21 2006-02-28 Ntt Docomo Inc Data conversion apparatus signal data conversion method dce gateway and communication apparatus
EP1093255B1 (en) * 1999-10-14 2009-12-16 Alcatel Lucent Method for connecting a first user-terminal to a second user-terminal, related devices and related software modules
US8463231B1 (en) 1999-11-02 2013-06-11 Nvidia Corporation Use of radius in UMTS to perform accounting functions
US6865169B1 (en) 1999-11-02 2005-03-08 Ipwireless, Inc. Cellular wireless internet access system using spread spectrum and internet protocol
US8117291B1 (en) * 1999-11-02 2012-02-14 Wireless Technology Solutions Llc Use of internet web technology to register wireless access customers
WO2001037517A2 (en) * 1999-11-03 2001-05-25 Wayport, Inc. Distributed network communication system which enables multiple network providers to use a common distributed network infrastructure
US7197017B1 (en) * 2000-01-04 2007-03-27 Qualcomm, Incorporated Method and apparatus for channel optimization during point-to-point protocol (PPP) session requests
US7190687B1 (en) * 2000-01-04 2007-03-13 Qualcomm Incorporated Method and apparatus for requesting point-to-point protocol (PPP) instances from a packet data services network
US7130629B1 (en) 2000-03-08 2006-10-31 Cisco Technology, Inc. Enabling services for multiple sessions using a single mobile node
US20020022483A1 (en) * 2000-04-18 2002-02-21 Wayport, Inc. Distributed network communication system which allows multiple wireless service providers to share a common network infrastructure
WO2001099457A1 (en) * 2000-06-20 2001-12-27 Nokia Networks Oy A method for performing a mobile user terminal route update in a telecommunication network operated based on the internet protocol
DE10034687A1 (en) * 2000-07-17 2002-02-07 Siemens Ag Method and transmission device for a communication system for transmitting data using a point-to-point protocol (SCTP)
US7123587B1 (en) * 2000-11-22 2006-10-17 Nortel Networks Limited System, device and method for limiting tunnel traffic in an information communication network
US7152238B1 (en) * 2000-12-29 2006-12-19 Cisco Technology, Inc. Enabling mobility for point to point protocol (PPP) users using a node that does not support mobility
US7054291B2 (en) * 2001-01-22 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Method of and system for mobile station abbreviated point-to-point protocol negotiation
US7046646B2 (en) * 2001-01-29 2006-05-16 Ipr Licensing, Inc. Method and apparatus for simple PPP handoff for mobile users
US6947400B2 (en) * 2001-01-31 2005-09-20 Ipr Licensing, Inc. Achieving PPP mobility via the mobile IP infrastructure
JP4686875B2 (en) * 2001-03-01 2011-05-25 パナソニック株式会社 Data communication device
DE10111493B4 (en) * 2001-03-09 2005-05-25 Siemens Ag Method and device for setting up a connection between a mobile terminal and a network server via a mobile radio network and another network (Internet)
US20020141420A1 (en) * 2001-03-30 2002-10-03 Sugiarto Basuki Afandi Throttling control system and method
US8028083B2 (en) * 2001-04-30 2011-09-27 Activcard Ireland, Limited Method and system for remote activation and management of personal security devices
US7339908B2 (en) * 2001-07-31 2008-03-04 Arraycomm, Llc. System and related methods to facilitate delivery of enhanced data services in a mobile wireless communications environment
US7036143B1 (en) 2001-09-19 2006-04-25 Cisco Technology, Inc. Methods and apparatus for virtual private network based mobility
US7471661B1 (en) 2002-02-20 2008-12-30 Cisco Technology, Inc. Methods and apparatus for supporting proxy mobile IP registration in a wireless local area network
US7536720B2 (en) * 2002-05-07 2009-05-19 Nortel Networks Limited Method and apparatus for accelerating CPE-based VPN transmissions over a wireless network
KR100440061B1 (en) * 2002-05-17 2004-07-14 엘지전자 주식회사 Method For Relaying RADIUS Message In The Packet Data Network
US20030233580A1 (en) * 2002-05-29 2003-12-18 Keeler James D. Authorization and authentication of user access to a distributed network communication system with roaming features
US7457289B2 (en) * 2002-12-16 2008-11-25 Cisco Technology, Inc. Inter-proxy communication protocol for mobile IP
US7362742B1 (en) 2003-01-28 2008-04-22 Cisco Technology, Inc. Methods and apparatus for synchronizing subnet mapping tables
EP1457939A1 (en) * 2003-03-12 2004-09-15 Siemens Aktiengesellschaft Method for transferring payment transaction information
US7505432B2 (en) 2003-04-28 2009-03-17 Cisco Technology, Inc. Methods and apparatus for securing proxy Mobile IP
US7024687B2 (en) * 2003-05-21 2006-04-04 Cisco Technology, Inc. System and method for providing end to end authentication in a network environment
US7698384B2 (en) * 2003-06-26 2010-04-13 International Business Machines Corporation Information collecting system for providing connection information to an application in an IP network
KR20050036521A (en) * 2003-10-16 2005-04-20 삼성전자주식회사 Seamless handover method in fh-ofdm based mobile communication system
US20050261970A1 (en) 2004-05-21 2005-11-24 Wayport, Inc. Method for providing wireless services
CA2570093A1 (en) * 2004-06-10 2005-12-29 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7447188B1 (en) 2004-06-22 2008-11-04 Cisco Technology, Inc. Methods and apparatus for supporting mobile IP proxy registration in a system implementing mulitple VLANs
TWI262683B (en) * 2005-02-04 2006-09-21 Ind Tech Res Inst A method, a wireless server, a mobile device, and a system for handing over, from a wireless server to another wireless server, in a connection between a mobile device in a foreign intranet network, and an intranet network
US7583662B1 (en) * 2005-04-12 2009-09-01 Tp Lab, Inc. Voice virtual private network
US8108525B2 (en) * 2006-08-03 2012-01-31 Citrix Systems, Inc. Systems and methods for managing a plurality of user sessions in a virtual private network environment
SE531960C2 (en) * 2007-01-26 2009-09-15 Smartrefill I Helsingborg Ab Method of securely executing a payment transaction
US9998956B2 (en) 2007-02-12 2018-06-12 Sigram Schindler Beteiligungsgesellschaft Mbh Managed handover process
US8761009B2 (en) * 2007-02-12 2014-06-24 Sigram Schindler Beteiligungsgesellschaft Mbh Managed handover process
US8261327B2 (en) 2007-07-12 2012-09-04 Wayport, Inc. Device-specific authorization at distributed locations
US8132247B2 (en) 2007-08-03 2012-03-06 Citrix Systems, Inc. Systems and methods for authorizing a client in an SSL VPN session failover environment
JP5281644B2 (en) 2007-09-07 2013-09-04 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Method and apparatus for enabling a nomadic terminal to access a home network on a layer 2 level
FR2922669B1 (en) * 2007-10-22 2020-10-09 Oberthur Card Syst Sa PORTABLE ELECTRONIC DEVICE FOR THE EXCHANGE OF VALUES AND PROCESS FOR IMPLEMENTING SUCH A DEVICE
CN101426004A (en) * 2007-10-29 2009-05-06 华为技术有限公司 Three layer conversation access method, system and equipment
US8923806B2 (en) 2008-03-14 2014-12-30 William J. Johnson System and method for presenting application data by data processing system(s) in a vicinity
US8634796B2 (en) 2008-03-14 2014-01-21 William J. Johnson System and method for location based exchanges of data facilitating distributed location applications
US8761751B2 (en) 2008-03-14 2014-06-24 William J. Johnson System and method for targeting data processing system(s) with data
US8566839B2 (en) 2008-03-14 2013-10-22 William J. Johnson System and method for automated content presentation objects
US8639267B2 (en) 2008-03-14 2014-01-28 William J. Johnson System and method for location based exchanges of data facilitating distributed locational applications
US8600341B2 (en) 2008-03-14 2013-12-03 William J. Johnson System and method for location based exchanges of data facilitating distributed locational applications
CN102804906A (en) 2009-06-19 2012-11-28 捷讯研究有限公司 Mechanisms For Data Handling During A Relay Handover With S1 Termination At Relay
WO2010148356A1 (en) 2009-06-19 2010-12-23 Research In Motion Limited Mechanisms for data handling during a relay handover with s1 termination at evolved universal terrestrial radio access network access node
US8406192B2 (en) * 2009-10-02 2013-03-26 Research In Motion Limited Handover mechanisms with synchronous PDCP protocol under various relay architectures
US8804596B2 (en) 2009-10-02 2014-08-12 Blackberry Limited Architecture for termination at access device
US8687590B2 (en) 2009-10-02 2014-04-01 Blackberry Limited System and method for handover between relays
CA2879180A1 (en) 2012-03-07 2013-09-12 Snap Trends, Inc. Methods and systems of aggregating information of social networks based on geographical locations via a network
CN103718640B (en) * 2012-08-02 2018-04-10 华为技术有限公司 Control and the processing method and control device, forwarding unit of the lower agreement of forwarding decoupling
CN103716901B (en) * 2012-09-28 2017-07-28 联发科技（新加坡）私人有限公司 Method, system and the relevant device connected between equipment
US9596271B2 (en) * 2012-10-10 2017-03-14 International Business Machines Corporation Dynamic virtual private network
US9477991B2 (en) 2013-08-27 2016-10-25 Snap Trends, Inc. Methods and systems of aggregating information of geographic context regions of social networks based on geographical locations via a network
US9894489B2 (en) 2013-09-30 2018-02-13 William J. Johnson System and method for situational proximity observation alerting privileged recipients
US9930597B2 (en) 2013-10-30 2018-03-27 Idac Holdings, Inc. Coordinated packet data network change for selected internet protocol traffic offload

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557745A (en) * 1990-09-04 1996-09-17 Digital Equipment Corporation Method for supporting foreign protocols across backbone network by combining and transmitting list of destinations that support second protocol in first and second areas to the third area
GB9100389D0 (en) * 1991-01-09 1991-02-20 Digital Equipment Corp Method and apparatus for transparently bridging traffic across wide area networks
US5327424A (en) * 1992-04-07 1994-07-05 Digital Equipment Corporation Automatically configuring parallel bridge numbers
US6006090A (en) * 1993-04-28 1999-12-21 Proxim, Inc. Providing roaming capability for mobile computers in a standard network
US5796727A (en) 1993-04-30 1998-08-18 International Business Machines Corporation Wide-area wireless lan access
US5325362A (en) 1993-09-29 1994-06-28 Sun Microsystems, Inc. Scalable and efficient intra-domain tunneling mobile-IP scheme
JPH07123174A (en) * 1993-10-21 1995-05-12 Fujitsu Ltd Communication method for line exchange network and communication controller
US6301242B1 (en) * 1998-07-24 2001-10-09 Xircom Wireless, Inc. Communication system with fast control traffic
CA2148384C (en) * 1994-06-27 2003-03-18 Charles Clifford Hallock Methods for performing intelligent network services with an isdn network terminator located at a subscriber's premise
JP3250129B2 (en) 1994-07-29 2002-01-28 日本電信電話株式会社 Packet service uninterrupted handover method
US5521963A (en) * 1994-09-08 1996-05-28 Siemens Stromberg-Carlson System and method for using integrated services digital networks (ISDN) and the call appearance call handling (CACH) feature of electronic key telephone service (EKTS) technology for mobile systems
US5680552A (en) * 1994-09-20 1997-10-21 Lucent Technologies Inc. Gateway system for interconnecting different data communication networks
GB9508696D0 (en) * 1995-04-28 1995-06-14 At & T Corp Method for connecting roaming stations in a source routed bridged local area network
US5978679A (en) * 1996-02-23 1999-11-02 Qualcomm Inc. Coexisting GSM and CDMA wireless telecommunications networks
US5940381A (en) * 1996-03-14 1999-08-17 Motorola, Inc. Asynchronous transfer mode radio communications system with handoff and method of operation
US5918019A (en) * 1996-07-29 1999-06-29 Cisco Technology, Inc. Virtual dial-up protocol for network communication
US6061650A (en) * 1996-09-10 2000-05-09 Nortel Networks Corporation Method and apparatus for transparently providing mobile network functionality
US5889958A (en) * 1996-12-20 1999-03-30 Livingston Enterprises, Inc. Network access control system and process
US6137791A (en) * 1997-03-25 2000-10-24 Ericsson Telefon Ab L M Communicating packet data with a mobile station roaming within an incompatible mobile network
US6026085A (en) * 1997-04-08 2000-02-15 3Com Corporation Architecture to support a single system image across multiple network access servers
FI109503B (en) 1997-04-15 2002-08-15 Nokia Corp Prevention of packet loss during handover in a packet-based telecommunications network and handover procedure
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
US6400722B1 (en) * 1997-10-14 2002-06-04 Lucent Technologies Inc. Optimum routing system
US6665718B1 (en) 1997-10-14 2003-12-16 Lucent Technologies Inc. Mobility management system
US5949773A (en) * 1998-03-31 1999-09-07 Motorola, Inc. Method for transferring a data signal in a wireless communications system
US6373828B1 (en) * 1998-06-26 2002-04-16 Motorola, Inc. Method and apparatus for completing a handover between wireless communication systems
US6449722B1 (en) * 1998-07-08 2002-09-10 Intel Corporation System and method for maintaining a virtual connection to a network node

Also Published As

Publication number Publication date
JP4546173B2 (en) 2010-09-15
JP2005045791A (en) 2005-02-17
DE69941885D1 (en) 2010-02-25
CA2279667A1 (en) 2000-03-09
JP2000115250A (en) 2000-04-21
US6496491B2 (en) 2002-12-17
EP0986222B1 (en) 2010-01-06
EP1549006B1 (en) 2011-10-19
EP0986222A3 (en) 2004-02-04
EP1549006A1 (en) 2005-06-29
US6917600B1 (en) 2005-07-12
US20020006132A1 (en) 2002-01-17
EP0986222A2 (en) 2000-03-15
JP3613453B2 (en) 2005-01-26

Similar Documents

Publication Publication Date Title
CA2279667C (en) A mobile point-to-point protocol
US6449272B1 (en) Multi-hop point-to-point protocol
US6801509B1 (en) Mobile point-to-point protocol
JP3515983B2 (en) Network access methods, including direct wireless access to the Internet
US8077719B2 (en) Packet switching apparatus
US7843884B2 (en) Achieving PPP mobility via the mobile IP infrastructure
US6973088B2 (en) PPP link negotiation in mobile IP systems
JPH11275154A (en) Message distribution sequence
JPH11289353A (en) Accounting system for network
JPH11252183A (en) Method for making point-to-point protocol in &#39;ethernet&#39; (trademark) frame into capsule
JP2000022758A (en) Interworking function selection system in network
JPH11275155A (en) Message in network and communications system
JPH11275156A (en) Communication using pier-to-pier protocol server
JPH11331276A (en) Registration method for network
WO2008055773A1 (en) Method, network element and communication system for optimized selection of an agent entity as well as modules of the network element
JP3692083B2 (en) Communication device with dial-up function
WO2006038268A1 (en) Access service network system, access device, l2tp tunnel line concentrator and home agent, and access service providing method
EP3355522B1 (en) Access aggregation system and bonding client

Legal Events

Date Code Title Description
EEER Examination request
MKLA Lapsed