HK1051275B - Method and apparatus for channel optimization during point-to-point protocol (ppp) session requests - Google Patents

Description

Method and apparatus for optimizing a channel during a session request of a point-to-point protocol (PPP)

Technical Field

The present invention relates to the field of communications, and more particularly, to a method and apparatus for optimizing a channel during a session request of a point-to-point protocol.

Background

With the increasing popularity of wireless communication and internet applications, a product and service market combining the two has emerged. There has been a continuing need for various methods and systems for allowing wireless telephone or end-users to access e-mail, web pages, and other network resources. Since information on the internet is organized in discrete packets, these services are often referred to as "packet data services".

Among the different types of wireless communication systems used to provide wireless packet data services, there is a Code Division Multiple Access (CDMA) system. The use of CDMA modulation techniques is one of several techniques that facilitate communication systems in which a large number of system users are present. Framing and transmission of Internet Protocol (IP) data over CDMA wireless networks IS well known in the art and IS described in the TIA/EIA/IS-707-a document entitled "data service selection for spread spectrum systems," herein referred to as IS-707.

Other multiple access communication system techniques, such as Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), and AM modulation schemes such as Amplitude Companded Single Sideband (ACSSB) modulation, are known in the art. These technologies have been standardized to facilitate interoperation between devices produced by different companies. CDMA communication systems have been standardized in the united states by the telecommunications industry association's TIA/EIA/IS-95-B document entitled "mobile station-base station compatibility standard in dual-mode wideband spread spectrum cellular systems," referred to herein as IS-95.

The international telecommunications union has recently required proposals to deliver planned methods of providing high-rate data and high-quality voice services over wireless communication channels. The telecommunications industry association published a first recommendation entitled "cdma 2000 ITU RTT candidate proposal," referred to herein as cdma 2000. The European Telecommunications standards institute has published a second recommendation entitled "ETSI UMTS Terrestrial Radio Access (UTRA) ITU-R RTT candidate proposal," namely "wideband CDMA," referred to herein as W-CDMA. Tg 8/1 filed a third proposal entitled "UWC-136 candidate proposal," referred to herein as EDGE. The contents of these proposals are open records and are well known in the art.

Several standards have been developed by the Internet Engineering Task Force (IETF) to facilitate mobile packet data services using the internet. Mobile IP is one such standard designed to allow devices with IP addresses to exchange data with the internet while physically traveling through the network (or networks). Mobile IP is described in detail in the IETF Internet protocol draft (RFC) entitled "IP mobility support," which is incorporated herein by reference.

Some other IETF standards propose some of the techniques mentioned in the references named above. The Point-to-Point protocol (PPP) is well known in the art and is described in IETF RFC 1661 entitled "Point-to-Point protocol (PPP)" published at 7 of 1994, and is referred to herein as PPP. PPP includes a Link Control Protocol (LCP) and several Network Control Protocols (NCPs) for establishing and configuring different network layer protocols over one PPP link. The Internet Protocol Control Protocol (IPCP) is such an NCP, well known in the art and described in IETF RFC 1332 entitled "PPP Internet Protocol Control Protocol (IPCP)" published in 1992, 5, and referred to herein as IPCP. Extensions to LCP are well known in the art and are described in IETF RFC 1570 entitled "PPP LCP extensions" published in 1/1994, and are referred to herein as LCP.

A mobile station, such as a cellular or PCS phone with an internet connection, typically sends packet data over the network by establishing a PPP connection (or PPP instance, or PPP session) with a Packet Data Serving Node (PDSN). The mobile station transmits data packets across an RF interface, such as a CDMA interface, to the base station or a packet control function. The base station or packet control function and PDSN establish the PPP instance. More than one such PPP instance may be established at a time (e.g., if a connection is required for both a telephone and a laptop). According to the particular PPP instance, packets are routed within the IP network from a Foreign Agent (FA) to a Home Agent (HA) of the PDSN. Packets sent to the mobile station are routed from the HA to the FA of the PDSN via the IP network, from the FA of the PDSN to the base station or packet control function via the PPP instance, and from the base station or packet control function to the mobile station via the RF interface.

When a mobile station leaves the vicinity of one PDSN and enters the vicinity of another PDSN, it sends an origination message. If the mobile station is in a data-call state, initiating the origination message requires reconnecting or establishing the associated PPP instance. Otherwise, the origination message informs the new PDSN about the new location of the mobile station. In any event, any packets destined for the mobile station will be routed to the old PDSN because the mobile station has not established a PPP instance with the new PDSN. Therefore, packets destined for the mobile station will be lost. Thus, there is a need for a way to inform the PDSN of the number and identity of PPP instances to be established for a newly arriving mobile station. There is also a need for a method to inform the PDSN about the number and identity of PPP instances that need to be established in order to optimize the use of Air Interface (Air Interface) and Radio Access Network (RAN) PDSN Interface (RPI) communication channel resources.

Summary of The Invention

The present invention is directed to a method for notifying a PDSN regarding the number and identity of PPP instances that need to be established in order to optimize the use of Air Interface (Air Interface) and Radio Access Network (RAN) PDSN Interface (RPI) communication channel resources. Accordingly, in one aspect of the invention there is provided a method for notifying a packet data service network of an idle state network connection of a mobile station when the mobile station moves from a first infrastructure element of the packet data service network to a second infrastructure element of the packet data service network. The method advantageously includes the step of transmitting a message from the mobile station including a plurality of idle state network connections associated with the mobile station and an identification list corresponding to the idle state network connections.

In another aspect of the invention, a mobile station is provided that is configured to notify a packet data service network of an idle state network connection of the mobile station when the mobile station moves from a first infrastructure element of the packet data service network to a second infrastructure element of the packet data service network. The mobile station advantageously includes an antenna; a processor coupled to the antenna; and a processor-readable medium accessible to the processor and containing a set of instructions executable by the processor to modulate and transmit from the mobile station a message containing a plurality of idle state network connections associated with the mobile station and an identification list corresponding to the idle state network connections.

In another aspect of the invention, a mobile station is provided that is configured to notify a packet data service network of an idle state network connection of the mobile station when the mobile station moves from a first infrastructure element of the packet data service network to a second infrastructure element of the packet data service network. The mobile station advantageously includes a device configured to transmit a message from the mobile station including a plurality of idle state network connections associated with the mobile station and an identification list corresponding to the idle state network connections.

In another aspect of the invention, a mobile station is provided that is configured to notify a packet data service network of an idle state network connection of the mobile station when the mobile station moves from a first infrastructure element of the packet data service network to a second infrastructure element of the packet data service network. The mobile station advantageously includes means configured for transmitting a message from the mobile station including a plurality of idle state network connections associated with the mobile station and an identification list corresponding to the idle state network connections.

In another aspect of the invention, a method is provided for optimizing RPI communication channel resources in a communication network when a mobile station moves from a first infrastructure element of a packet data serving network to a second infrastructure element of the packet data serving network. The method advantageously comprises the steps of: a message is sent from a packet control operation, or base station, containing a plurality of idle state network connections for the mobile station and a reduced list of identifications corresponding to the idle state network connections.

In another aspect of the invention, a method is provided for simplifying Packet Control Function (Packet Control Function) network element functionality when a mobile station moves from a first infrastructure element of a Packet data service network to a second infrastructure element of the Packet data service network. The method advantageously comprises the steps of: a reduced entry PPP connection table is maintained.

In another aspect of the invention, a method is provided for optimizing air interface traffic channel resources in a communication network when a mobile station moves from a first infrastructure element of a packet data service network to a second infrastructure element of the packet data service network. The method advantageously comprises the steps of: a message is sent from the mobile station containing a plurality of idle state network connections associated with the mobile station and enhancement information corresponding to the idle state network connections.

Brief Description of Drawings

Fig. 1 is a block diagram of a wireless communication system configured for packet data network switching.

Fig. 2 is a block diagram of a Packet Data Serving Node (PDSN).

Fig. 3A is a block diagram of two PDSNs coupled to Radio Access Networks (RANs) in which a Mobile Station (MS) moves into the vicinity of a second PDSN without establishing a new instance of PPP, fig. 3B is a block diagram of two PDSNs coupled to RANs in which an MS moves into the vicinity of a second PDSN and establishes a new instance of PPP, and fig. 3C is a block diagram of two PDSNs coupled to RANs in which the optimization results of the air interface and RPI channels are shown.

Fig. 4 is a flow chart illustrating the method steps for a mobile station to inform the PDSN of the number and identity of PPP instances that the PDSN requires to establish.

Detailed description of the preferred embodiments

In one embodiment, a wireless communication system 100 for packet data network switching includes elements as shown in fig. 1. A Mobile Station (MS)102 is advantageously capable of operating one or more wireless packet data protocols. In one embodiment, MS 102 is a wireless telephone running an IP-based web browser program. In one embodiment, MS 102 is not connected to any external device, such as a laptop computer. In an alternative embodiment, MS 102 IS a wireless telephone that IS connected to an external device and uses network layer R as described in IS-707_mInterface protocol option (Network Layer R)_mInterface protocol Option). In addition toIn an alternative preferred embodiment, MS 102 IS a wireless telephone connected to an external device and uses the Relay layer R as described in IS-707 above_mInterface protocol option (Relay Layer R)_mInterface Protocol Option).

In one particular embodiment, MS 102 communicates with Internet Protocol (IP) protocol network 104 by communicating wirelessly with Radio Access Network (RAN) 106. The MS 102 generates an IP packet to the IP network 104 and encapsulates the IP packet into a data frame that is sent to a packet data serving node (PSDN) 108. In a preferred embodiment, the IP packets are encapsulated using a Point-to-Point protocol (PPP), and the resulting PPP byte stream is sent over a Code Division Multiple Access (CDMA) network using a Radio Link Protocol (RLP).

MS 102 sends the data frames to RAN106 by modulating the data frames and transmitting the data frames via antenna 110. The data frames are received by RAN106 via antenna 112. The RAN106 sends the received data frame to the PSDN108 where IP packets are opened from the received data frame. After the PSDN opens an IP packet from the data stream, the PSDN108 routes the IP packet to the IP network 104. PSDN108, in turn, is also capable of transmitting encapsulated data frames to MS 102 via RAN 106.

In one embodiment, to authenticate MS 102, PDSN 108 is coupled to a Remote Authentication Dial In User Service (RADIUS) server 114. To support the mobile IP protocol, the PDSN 108 is also coupled to an internal Agent (HA) 116. The HA 116 advantageously should include an entity that can authenticate the MS 102 and grant the MS 102 an IP address when using mobile IP. Those skilled in the art will appreciate that RADIUS server 114 may be replaced with a DIAMETER server or any other authentication, authorization, accounting (AAA) server.

In one embodiment, MS 102 generates IP packets and PDSN 108 is coupled to IP network 104. Those skilled in the art will recognize that alternative embodiments may use formats and protocols other than IP. Additionally, PDSN 108 may be coupled to a network that employs protocols other than IP.

In one embodiment, RAN106 and MS 102 communicate with each other using wireless spread spectrum techniques. In one particular embodiment, CDMA multiplexing may be used to wirelessly transmit data, as described in U.S. patent nos. 5103459 and 4901307, which are assigned to the assignee of the present invention and are incorporated herein by reference in their entirety. Those skilled in the art will appreciate that the methods and techniques described herein may be used in conjunction with a number of alternative modulation techniques, including TDMA, CDMA2000, W-CDMA, and EDGE, among others.

In one embodiment, the MS 102 is capable of running RLP, PPP, Challenge Handshake Authentication Protocol (CHAP), Mobile IP, and the like. In one particular embodiment, the RAN106 communicates with the MS 102 using RLP. In one embodiment, PDSN 108 supports PPP functions including Link Control Protocol (LCP), CHAP, and PPP Internet Protocol Control Protocol (IPCP). In one embodiment, PDSN 108, RADIUS server 114, and HA 116 are physically located in different physical devices. In an alternative embodiment, one or more of such entities may be located within the same physical device.

In one embodiment, as shown in fig. 2, the PDSN 200 includes a control processor 202, a network packet switch 204, an IP network interface 206, and a RAN interface 208. The IP network interface 206 is coupled to the network packet switch 204. The network packet switch 204 is coupled to the control processor 202 and the RAN interface 208. RAN interface 208 receives data packets from a RAN (not shown). RAN interface 208 receives the packet via a physical interface. In one embodiment, the physical interface is T3, a standard digital telecommunications interface with a 45Mbps transmission rate. The physical T3 interface may be replaced with a T1 interface, an ethernet interface, or any other physical interface for data network switching.

The RAN interface 208 passes the received data packet to the network packet switch 204. In an exemplary embodiment, the connection between the network packet switch 204 and the RAN interface 208 comprises a memory bus connection (memory bus connection). The connection between the RAN interface 208 and the network packet switch 204 may be ethernet or any other different communication link known in the art. The RAN interface 208 is advantageously also capable of receiving data packets from the network packet switch 204 and sending packets to the RAN over the same connection.

Network packet switch 204 is advantageously a configurable switch capable of routing packets between different interfaces. In one embodiment, the network packet switch 204 is configured such that all packets received from the RAN interface 208 and the IP network interface 206 are routed to the control processor 202. In an alternative embodiment, network packet switch 204 is configured to pass a subset of data frames received from RAN interface 208 to IP network interface 206 and pass a remaining subset of data frames received from RAN interface 208 to control processor 202. In one embodiment, the network packet switch 204 passes the data packets to the control processor 202 over a shared memory bus connection. The connection between the RAN interface 208 and the network packet switch 204 may be ethernet or any other different communication link known in the art. The network packet switch 204 is coupled to the RAN interface 208 and the IP network interface 206, and those skilled in the art will appreciate that the network packet switch 204 may be coupled to fewer or more interfaces. In one embodiment, network packet switch 204 is coupled to a single network interface that is coupled to an IP network (not shown) and to the RAN. In an alternative embodiment, the network packet switch 204 is integrated on the control processor 202 such that the control processor 202 can communicate directly with the network interface.

Control processor 202 and RAN interface 208 exchange packets when a connection with an MS (not shown) is required. After control processor 202 receives the packet indicating the requirement to establish a connection with the MS, control processor 202 negotiates a PPP session procedure with the MS. To negotiate the PPP session, control processor 202 generates PPP frames, sends the PPP frames to RAN interface 208, and then interprets responses from the MS received from RAN interface 208. The frame types generated by control processor 202 include LCP frames, IPCP frames, and CHAP frames. The MS may be authenticated according to the method described in U.S. patent application entitled "method and apparatus for authentication in a wireless telecommunications system" filed 1999, 12/3, which has not been assigned a serial number, which is assigned to the assignee of the present invention and is hereby incorporated by reference in its entirety.

Control processor 202 generates data packets for exchange with an AAA server (not shown) and a mobile IP home agent (not shown). In addition, control processor 202 encapsulates and reassembles IP packets for each established PPP session process. Those skilled in the art will appreciate that the control processor 202 may be implemented using Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), Digital Signal Processors (DSPs), one or more microprocessors, Application Specific Integrated Circuits (ASICs), or any other device capable of performing the PDSN functions described above.

In one embodiment, the data packets are passed to the network packet switch 204, which in turn passes the data packets to the IP network interface 206 for delivery to the IP network. The IP network interface 206 transmits packets through one physical interface. In one embodiment, the physical interface is T3, a standard digital telecommunications interface with a 45Mbps transmission rate. The physical T3 interface may be replaced with a T1 interface, an ethernet interface, or any other physical interface for data networking. The IP network interface 206 is advantageously also able to receive data packets over the same physical interface.

As shown in fig. 3A, an MS300 sends packet data over an IP network (not shown) by establishing a PPP instance 302 with a PDSN 304. MS300 sends data packets to a packet control function or base station (PCF/BS)306 via an RF interface, such as a CDMA interface. PCF/BS 306 establishes PPP instance 302 with PDSN 304. Another PPP instance 308 may also be established at the same time (e.g., a connection is required for each of the telephone and laptop). Depending on the particular PPP instances 302, 308, the data packets are routed from the PDSN 304 to an HA (not shown) via an IP network (not shown). Data packets sent to MS300 are routed from PCF/BS 306 to PDSN 304 through the IP network, from PDSN 304 to PCF/BS 306 through PPP instances 302, 308, and from PCF/BS 306 to MS300 through the RF interface. PCF/BS 306 includes a PCF/BS table 310. PCF/BS table 310 includes a list of MS identities (MS _ IDs), service reference identities (SR _ IDs), and RAN-to-PDSN interface (R-P) identities (R-P IDs). PDSN 304 includes a PDSN table 312. PDSN table 312 includes a list of IP addresses, MS IDs, srids, and R-P IDs. The PDSN 304 may serve multiple PCF/BSs 306, but for simplicity only one PCF/BS 306 is shown coupled to the PDSN 304.

When the MS300 is idle (e.g., not in the process of a telephone call), the MS300 sends a short data burst as a PPP data frame. Each such PPP data frame includes an SR _ ID that identifies which of the PPP instances 302, 308 the PPP frame was sent to. The PPP frame may encapsulate other protocols as will be appreciated by those skilled in the art. In an exemplary embodiment, the PPP frame encapsulates a Transmission Control Protocol (TCP) frame and indicates the protocol of the encapsulated TCP frame. The TCP frame encapsulates an IP frame and indicates the protocol of the IP frame. The IP frame encapsulates a frame, such as an RLP frame, and also includes a source header and a final header. The RLP frame may also encapsulate a data frame configured as IS-95B.

When the MS300 leaves the vicinity of the PDSN 304 and enters the vicinity of another PDSN 314, the MS300 will send an origination message. If the MS300 is in a data call process, the call process is "handed off" from the first PCF/BS 306 to a second PCF/BS 316 coupled to a second PDSN 314. An exemplary handoff procedure is described in U.S. patent No. 5267261, which is assigned to the assignee of the present invention and is hereby incorporated by reference in its entirety. The MS300 then sends an origination message informing the second PDSN 324 of its new location and requesting that the PPP instance corresponding to the call process be established or reconnected. Otherwise, the PPP instances 302, 308 are in an idle state and the MS300 completes an idle handoff and then sends an origination message informing the second PDSN 324 of the new location of the MS 300. Those skilled in the art will appreciate that the second PDSN 314 may also serve multiple PCFs/BSs 316, but for convenience only one PCF/BS 316 is shown coupled to the PDSN 314.

Although the network has been informed about the new location of MS300, MS300 still requires that these two new PPP instances be initialized (because MS300 has two idle srids corresponding to idle PPP service instances 302, 308). The new PCF/BS 316 and PDSN 306 do not list SR _ IDs or R _ P IDs because the two necessary PPP instances have not yet been established. Thus, packets destined for the MS300 will be routed to the first PDSN 304 because no PPP instance is established between the MS300 and the new PDSN 314. Consequently, data packets destined for the MS300 will be lost.

In one embodiment, as shown in fig. 3B, an MS318 moves from the vicinity of a first PDSN320 and a corresponding PCF/BS 322 to the vicinity of a second PDSN 324 and a corresponding PCF/BS 326 and informs the second PDSN 324 of the number and identity of PPP instances that must be established. The first PDSN320 has established two PPP instances 328, 330 between the PDSN320 and the PCF/BS 322, both of which are idle (i.e., not being used to send traffic channel data). The different connections and addresses established are included in the respective tables 332, 334 of PDSN320 and PCF/BS 322. The number (two) and identity of the newly required PPP instances 336, 338 should advantageously be included in the origination message sent by the MS 318. For simplicity, only one PCF/BS is shown serving different PDSNs 320, 324, but it is understood that multiple PCFs/BSs may serve each PDSN320, 324. The origination message advantageously includes a data ready to send (DRS) flag bit that may be set to 0 to inform PDSN 324 of the identity and total number of packet services in the idle state, thus allowing PDSN 324 to establish PPP instances 336, 338 and the required R _ P link between PDSN 324 and PCF/BS 326. If a data call is in progress, the MS318 sets the DRS flag to 1 and requests reconnection or establishment of an instance 328, 330 corresponding to the call. If not in the process of a call, the MS318 sets the DRS flag to 0 and reports the SR _ IDs (SR _ IDs 1 and 2) for all instances 328, 330 of idle PPP service associated with the MS 318. PCF/BS 326 then sends a message to PDSN 324 including the SR _ IDs and MS _ ID list. PDSN 324 establishes two PPP instances 336, 338 and two (the number of srids reported by MS 318) R-P connections. PDSN 324 and PCF/BS 326 then update their respective tables 340, 342. Thus, the idle SR _ IDs list informs the PDSN 324 how many PPP instances 336, 338 to initialize, and gives the PCF/BS 326 enough information to update its R-P/SR _ ID table 342.

In one embodiment, as shown in fig. 3C, when an MS 366 moves into the vicinity of PDSN356 corresponding to PCF/BS364, the use of RPI channel 370 is optimized by reducing the information included in messages sent by a PCF/BS364 to PDSN 356. This reduction in information is accomplished by removing the SR IDs list from the message and connection table 352 maintained by the PDSN 356. Instead of representing packets associated with a new MS 366 corresponding to different PPP instances 372, 374 with SR _ IDs, PCF/BS364 uses the subscription pipe number 33, 54 of the RPI communication pipe to associate the packets to the PPP instances 372, 374. PCF/BS364 may associate MS 366 packet with the smallest SR _ ID with the lowest number data pipe and continue this association with the ascending number. In addition to optimizing the use of the RPI channel, the PDSN also simplifies its functionality by not maintaining SR _ ID information.

In another embodiment, as shown in fig. 3C, the role of air interface 368 is optimized by reserving air interface traffic channel communications when PDSN356 is not required for agent advertisement. The agent advertisement refers to an HA advertisement of a new FA IP address by a new FA (not shown in the figure). When an MS 366 moves into the vicinity of the new PDSN356, the MS FA must also move to the new PDSN356 so that packets originating from the HA (not shown) can reach the new PDSN 356. When the MS 366 changes FAs, the new FA informs the HA to stop directing packets for the MS 366 to the old FA, but to direct them to the new FA. Proxy advertisement occurs when an MS 366 moves to a new PCF/BS (or RAN) 364. When MS 366 enters a new PACKET ZONE, the MS sends an initial message containing the PACKET ZONE ID to PDSN356 corresponding to the new PCF/BS 364. The agent advertisement triggers mobile IP re-registration and PPP re-negotiation on a traffic channel. However, multiple PCF/BSs may be associated with the same PDSN356, and if MS 366 only changes the packet zone without changing the PDSN, mobile IP re-registration and PPP re-negotiation is not required. If the MS 366 moves from one PCF/BS to another PCF/BS corresponding to the same PDSN356, the PPP attachment point and FA address will not change.

The use of the air interface traffic channel is optimized by adding the old PACKET ZONE ID information to the MS origination message if the MS 366 only changes PCF/BS and not PDSN. The new PCF/BS364 sends the old PACKET ZONE ID information to the corresponding PDSN 356. The PDSN356 then determines whether the MS 356 has moved from a RAN or PCF/BS364 that is also connected to the PDSN 356. If the old RAN or PCF/BC 364 is also connected to the PDSN356, the PDSN356 will not generate a proxy announcement using the traffic channel because the MS PPP session has already been established. Including the old packet zone information in the MS origination message optimizes traffic channel usage, allowing the PDSN356 to decide whether it is necessary to use the traffic channel to renegotiate PPP.

In the case where the old PCF/BS and the new PCF/BS are connected to the same PDSN as they are (not shown), the new PCF/BS informs the PDSN of the original connection, allowing the new PCF/BS to establish a connection with the already existing PPP session.

In one embodiment, when an MS (not shown) leaves the vicinity of a PDSN (not shown) and enters the vicinity of a neighboring PDSN (not shown), it will perform the method steps as shown in fig. 4. The MS determines whether it has reached a new PDSN in step 400. If the MS does not reach a new PDSN, the MS will return to step 400. On the other hand, if the MS reaches a new PDSN, the MS proceeds to step 402. In step 402, the MS determines whether it is engaged in a data call. If the MS is engaged in a data call, the MS proceeds to step 404. On the other hand, if the MS is not engaged in a data call, the MS proceeds to step 408.

In step 404, the MS performs a handover process. The MS then proceeds to step 406. In step 406, the MS sends an origination message to the new PDSN informing of its own location. The DRS flag bit in the origination message is set to 1 and the MS requires reconnecting or establishing the PPP instance corresponding to the data call. In step 408, the MS performs an idle handoff process. The MS then proceeds to step 410. In step 410, the MS sends an origination message to the new PDSN informing of its own location. The DRS flag bit in the origination message is set to 0 and the number of PPP instances that the MS is going to establish (corresponding to the number of idle PPP instances for that MS), and the srid corresponding to each such PPP instance, are included in the message.

Thus, a new and improved method and apparatus for optimizing a channel during a PPP session request has been described. Those of skill in the art would appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The skilled person will appreciate the interchangeability of hardware and software under these circumstances, and how best to implement the described functionality for each particular application. By way of example, the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete logic gates (discrete gates) or transistor logic discrete hardware elements such as registers and FIFO, a processor executing a set of firmware instructions, any conventional programmable software module and a processor, or any combination thereof. The processor may advantageously be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The software modules may be stored in RAM memory, flash memory, ROM memory, registers, hard disk, a removable hard disk, a CD-ROM, or any other form of known storage medium. Those skilled in the art will further appreciate that the data, instructions, commands, information, signals, bits, symbols, and chips (chips) used in the foregoing description may advantageously be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Thus, the preferred embodiments of the present invention have been described and illustrated. However, it will be apparent to those of ordinary skill in the art that modifications may be made to the embodiments disclosed herein without departing from the spirit or scope of the invention. Accordingly, the invention is not limited except as by the following claims.

Claims (29)

1. A method of allocating radio access network packet data serving node interface communication channel resources in a communication network when a mobile station moves from a first infrastructure element to a second infrastructure element associated with a packet data serving node of the communication network, the method comprising the steps of:

a reduced list of idle network connections associated with the mobile station and identifiers associated with the idle network connections is transmitted from the second base unit.

2. The method of claim 1, wherein the list does not include a service request identification.

3. A method for simplifying packet control operation network element functionality when a mobile station moves from a first infrastructure element of a packet data services network to a second infrastructure element of the packet data services network, the method comprising the steps of:

a reduced entry peer-to-peer protocol connection table is maintained.

4. The method of claim 3, wherein the condensed entry does not include a service request identification.

5. A method of allocating air interface traffic channel resources in a communication network when a mobile station moves from a first infrastructure element of a packet data service network to a second infrastructure element of the packet data service network, the method comprising the steps of:

a message is sent from the mobile station containing a plurality of idle state network connections associated with the mobile station and including enhanced information associated with the idle state network connections.

6. The method of claim 5, wherein the enhancement information comprises packet zone identification information.

7. The method of claim 5, wherein the enhancement information is used to conserve traffic channel resources by simplifying a point-to-point protocol session negotiation procedure.

8. The method of claim 5, wherein the enhancement information is used to conserve traffic channel resources by simplifying an Internet protocol registration procedure.

9. A mobile station configured to notify a packet data service network of an idle state network connection of the mobile station when the mobile station moves from a first infrastructure element of the packet data service network to a second infrastructure element of the packet data service network, the mobile station comprising:

an antenna;

a processor coupled to the antenna; and

a processor readable medium accessible to the processor and containing a set of instructions executable by the processor to modulate and transmit from a mobile station a message containing a plurality of idle state network connections associated with the mobile station and an identification list corresponding to the idle state network connections.

10. The mobile station of claim 9, wherein the idle state network connection comprises a point-to-point protocol connection.

11. The mobile station of claim 9, wherein the first and second infrastructure elements comprise packet data serving nodes.

12. The mobile station of claim 9, wherein the identity does not include a service reference identity.

13. The mobile station of claim 9, wherein the message comprises an origination message including an indicator that indicates that the idle state network connection is in an idle state.

14. The mobile station of claim 9, wherein the message includes packet zone identification information.

15. A mobile station configured to notify a packet data service network of an idle state network connection of the mobile station when the mobile station moves from a first infrastructure element of the packet data service network to a second infrastructure element of the packet data service network, the mobile station comprising:

an apparatus configured to transmit a message from a mobile station including a plurality of idle state network connections associated with the mobile station and including a reduced list of identifiers associated with the idle state network connections.

16. The mobile station of claim 15, wherein the idle state network connection comprises a point-to-point protocol connection.

17. The mobile station of claim 15, wherein the first and second infrastructure elements comprise packet data serving nodes.

18. The mobile station of claim 15, wherein the identifier does not include a service reference identifier.

19. The mobile station of claim 15, wherein the message comprises an origination message including an indicator that indicates that the idle state network connection is in an idle state.

20. The mobile station of claim 15, wherein the message includes packet zone identification information.

21. A mobile station configured to notify a packet data service network of an idle state network connection of the mobile station when the mobile station moves from a first infrastructure element of the packet data service network to a second infrastructure element of the packet data service network, the mobile station comprising:

a device configured to transmit a message from a mobile station including a plurality of idle state network connections associated with the mobile station and including a reduced list of identities corresponding to the idle state network connections.

22. The mobile station of claim 15, wherein the idle state network connection comprises a point-to-point protocol connection.

23. The mobile station of claim 15, wherein the first and second infrastructure elements comprise packet data serving nodes.

24. The mobile station of claim 15, wherein the identifier does not include a service reference identifier.

25. The mobile station of claim 15, wherein the message comprises an origination message including an indicator that indicates that the idle state network connection is in an idle state.

26. The mobile station of claim 15, wherein the message includes packet zone identification information.

27. A packet data serving node configured to maintain a point-to-point protocol connection table for network connections in an idle state with respect to a mobile station when the mobile station moves from a first infrastructure element of a packet data serving network to a second infrastructure element of the packet data serving network, the packet data serving node comprising:

a radio access network packet data serving node channel interface;

a processor coupled to a radio access network packet data serving node channel interface; and

a processor readable medium is accessible to the processor and contains a set of instructions executable by the processor for updating network connection information regarding an idle state of the mobile station.

28. The packet data serving node of claim 27, wherein the maintained idle network connection information associated with the mobile station does not include a service reference identifier.

29. The mobile station of claim 27, the first and second infrastructure elements comprising packet data serving nodes.