Virtual address translation to support wireless access to data networks

In a telephony communication system, mobile devices request access to packet-based networks using network access requests that identify access point names associated with the networks. The mobile devices and an operator network providing access to the networks support the use of virtual access point names within network access requests. These virtual access point names need not correspond to any existing networks. Rather, network access requests incorporating virtual access point names indicate actually requested access point names within other fields of the network access requests.

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to wireless access to data networks and, more particularly, to virtual address translation to support wireless access to data networks.

BACKGROUND OF THE INVENTION

As wireless devices become increasingly sophisticated, protocols and network equipment have evolved to support enhanced services, such as packet-based communications with data networks. However, portions of the telephony infrastructure remain reliant upon outdated protocols and equipment that are ill-prepared to handle the dynamic and rapid pace of today's networks. For example, the home location register (HLR) governs, in part, the ability of wireless devices to access packet-based networks. However, because of the ever-changing array of available data networks, it can be extremely difficult to maintain home location registers properly configured.

SUMMARY OF THE INVENTION

In accordance with the present invention, techniques for virtual address translation to support wireless access to data networks are provided. According to particular embodiments, the system provides a virtual addressing scheme to minimize impacts on home location register (HLR) configuration.

According to a particular embodiment, a method for processing network access requests for mobile devices receives a network access request for establishment of a communication link for data communications for a mobile device, with the network access request including a requested network field and a pass-through field. The method determines a requested network from text in the pass-through field, sets the requested network field to the requested network, and determines a gateway linking to the requested network. The method then forwards the network access request to the gateway.

Embodiments of the invention provide various technical advantages. By configuring an HLR to accept one or more virtual network addresses, the system limits configuration changes to the HLR. By embedding actual network addresses within pass-through fields of network access requests, the system allows dynamic equipment, such as a virtual address translation module or a gateway generalized packet radio service (GPRS) serving node (GGSN), to handle processing of network access requests. This enables administrators of network equipment to focus configuration efforts upon more sophisticated and protocol aware elements, which allows networks to more appropriately reflect the dynamic nature of today's communication systems.

Moreover, the system may include a module that handles translation of virtual addresses to actually requested addresses. If desired, this module can be included in systems that otherwise would not support virtual address requests. Thus, this module can supplement the capabilities of a network to support network access requests generated using virtual addressing.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1illustrates a communication system, indicated generally at10, that includes mobile devices12, a radio access network14, an operator network16, and data networks, such as internet18and intranets20. In general, elements of system10support wireless communications and access of mobile devices12to data services provided by the data networks. To access data networks, mobile devices12generate network access requests that identify requested networks using, for example, access point names (APNs) assigned to the networks. According to particular embodiments, elements of system10are configured to support access to networks based on network access requests that identify virtual networks. These requests use pass-through fields within the network access requests to indicate actual networks to which access is requested.

Mobile devices12support wireless communications and provide packet-based access to data networks. Mobile devices12may be, for example, mobile phones, personal digital assistance, wireless enabled computers, or any other suitable device for providing wireless access to data networks. According to particular embodiments, mobile devices12support generalized packet radio service (GPRS) access to voice and data services. Mobile devices12access data networks using wireless communications supported by radio access network14. To access data networks, mobile devices12generate network access requests that identify access point names of the requested data networks. Typical network access requests further include other information, such as a user identifier, password, and mobile device identifier.

Radio access network (RAN)14supports wireless access of mobile devices12to voice and/or data services. Thus, RAN14represents any suitable collection and arrangement of components, such as radio transceivers and support infrastructure, that link mobile devices12to operator network16. Operator network16links RAN14to one or more data networks, such as internet18and intranets20. Data networks, such as internet18and intranets20, represent any suitable networks providing network services to accessing devices, such as mobile devices12. These network services include the communication of information such as voice, video, and data using packet-based protocols.

In the embodiment illustrated, operator network16includes a serving node22linking to RAN14and gateways24linking to various data networks. In addition, operator network16includes domain name servers (DNS)26and27, a home location register (HLR)28, a dynamic host configuration protocol (DHCP) server30, and a radius server32. HLR28provides traditional home location register features for operator network16. DHCP server30enables dynamic assignment of IP addresses to requesting devices. Radius server32provides for authorization and authentication of users. Domain name servers26and27map domain names to internet protocol (IP) addresses and return these addresses in response to appropriate requests. For example, in response to a request identifying a particular access point name, domain name server26returns a list of IP addresses for gateways24providing access to the identified access point name. While illustrated as including two domain name servers, system10may include any number of domain name servers each serving different groups of elements.

Serving node22links to RAN14and handles initial processing of network access requests received from mobile devices12. For example, according to particular embodiments, operator network16supports GPRS protocols, and serving node22acts as a serving GPRS support node (SGSN). Upon receiving a network access request from one of mobile devices12, serving node22accesses HLR28to verify the request. For example, serving node22may identify an access point name from the request and access HLR28to determine whether the indicated access point name identifies a valid network. Thus, the configuration of HLR28can control whether or not mobile devices12may access particular networks.

To provide generic access through HLR28to data networks, HLR28is configured to recognize one or more virtual networks. For example, HLR28may be configured to recognize virtual access point names such as “internet” or “intranet.” These virtual networks need not correspond to any actual networks reachable through operator network16, but rather provide static configurations within HLR28that can minimize the need for configuration changes to HLR28and shift the burden of access request processing to other elements within operator network16.

Upon receiving appropriate verification from HLR28, serving node22accesses domain name server26to determine an IP address associated with the access point name identified in the network access request. In response to this request, domain name server26returns one or more IP address matching to the access point name in the domain name request. Within operator network16, gateways24provide access to various data networks identified by access point names. Thus, domain name server26is configured to return IP addresses of gateways24in response to domain name requests that identify networks accessible through gateways24.

However, some or all gateways24may be unable to process network access requests that identify virtual access point names. To handle translation of these virtual network access requests, system10include a virtual address translation module34. So that serving node22forwards the request appropriately, domain name server26is configured to match virtual access point names to the IP address for virtual address translation module34. Therefore, when serving node22requests the IP address for reaching a virtual access point name, domain name server26returns the address of virtual address translation module34. For example, in response to a domain name request requesting an IP address associated with the access point name “internet,” domain name server26return the IP address for virtual address translation module34. Thus, domain name server26is configured to recognize virtual networks and return the IP address for virtual address translation module34in response to domain name requests identifying virtual networks. However, because some gateways24may support processing of virtual network access requests, domain name server26may map some portion of virtual addresses to specific gateways24. Therefore, domain name server26may map only some virtual addresses to virtual address translation module34.

According to other embodiments, virtual address translation module34handles both virtual and traditional network access requests. That is, virtual address translation module34can forward network access requests to appropriate gateways24regardless of whether the requests indicate virtual or actual access point names. Thus, domain name server26may map some or all actual access point names to the IP address for virtual address translation module34.

Upon receiving an IP address from domain name server26, serving node22forwards the network access request to the identified IP address. As a part of this process, serving node22may reformat and/or supplement the request with additional information. For example, according to particular embodiments, serving node22uses the information from an access request received from mobile device12to generate a create packet data protocol (PDP) context request. Regardless of the exact format, the access request generated by serving node22includes the access point name and other information, such as a user identifier, password, and other information received from mobile device12. After performing appropriate formatting or processing of the information from mobile device12, serving node22forwards the network access request to the IP address identified by domain name server26. For some or all access point names, this results in serving node22forwarding the network access request to virtual address translation module34.

Upon receiving a network access request, virtual address translation module34identifies an actually requested access point name, modifies the request if appropriate, and forwards the modified request to the appropriate gateway24. To perform its functions, virtual address translation module34includes any suitable combination and arrangement of hardware and/or controlling logic. Moreover, system10contemplates virtual address translation module34residing within any appropriate element. For example, virtual address translation module34may be a separate module installed within system10to provide translation of virtual network access requests. Alternatively, one of gateways24may include some or all of the functionality of virtual address translation module34. By providing virtual address translation module34, system10provides support for virtual network access requests without requiring that all other elements, such as all gateways24, have an awareness of this type of request. That is, virtual address translation module34modifies network access requests identifying virtual addresses to identify the actually requested networks and then forwards the requests to appropriate gateways24.

Gateways24link operator network16to data networks and, along with serving nodes22, provide mobile devices12access to these data networks. In the embodiment illustrated, gateways24link with data networks, such as internet18and intranet20. However, while each gateway24is shown linking to a single network, each gateway24may link with multiple networks, and multiple gateways24may link to the same network. As previously discussed, these networks or portions of these networks are identified by access point names, which, for example, can be names defined or assigned by standards organizations to uniquely identify IP networks.

During operation, gateways24provide access to data networks in response to network access requests forwarded by serving node22. For example, after appropriately processing a network access request from serving node22, gateway24and serving node22may form a communication link to transport packets across operator network16. This communication link then serves as a transport mechanism for packets between mobile device12and the data network. According to particular embodiments, gateway24and serving node22form this communication link using GPRS tunneling protocol (GTP) to form a tunnel. Gateway24uses this GTP tunnel to insure that packets are communicated to and from serving node22currently acting as the attachment point for mobile device12. Thus, if mobile device12moves to an area served by a different serving node22, gateway24can reattach the tunnel to the new serving node22.

Before forming a communication link for mobile device12, gateway24processes the network access request received from serving node22. This processing includes steps such as authentication, authorization and address assignment. To aid with this processing, gateway24may access DHCP server30and radius server32. For example, gateway24may use DHCP server30to dynamically allocate an IP address to identify mobile device12during a communication session.

Radius server32provides authentication and authorization services. In response to an authentication and authorization request that identifies a user, password and requested network, radius32indicates whether the user is authorized and authenticated. For example, using the user identifier and password, radius server32can authenticate the identity of the user. Using the user identifier and requested network, radius server32can determine whether the user is authorized to access that network.

Upon receiving a network access request, gateway24uses DHCP server30and/or radius server32to process the request and determine whether mobile device12should be granted access to the requested network. In providing mobile devices12access to data networks, gateways24maintain routing information for these mobile devices12. As previously discussed, this routing information enables gateway24to tunnel packets to appropriate serving nodes22for each attached mobile device12. Thus, during operation, gateway24acts as the termination point for the mobile portion of communications between mobile devices12and data networks. That is, devices within data networks communicating with mobile devices12need not have any awareness of the mobile nature of mobile devices12.

To gain access to data networks, mobile device12generates and communicates a network access request to operator network16. This request includes fields identifying information including the requested network and a user identifier. Mobile device12generates the request using stored information and/or information provided by a user. For example, through a graphical user interface, a user may provide a user identifier, such as Bob, and specify a network to access, such as Cisco.com. In response to such a request, mobile device12may generate a network access request that identifies an access point name of Cisco.com and a user identifier of Bob. However, as previously discussed, for such a request to be appropriately processed by operator network16, HLR28should be configured to recognize the indicated access point name (in this example, Cisco.com). And since the range of potential access point names is vast and dynamic, the configuration and upkeep of antiquated HLR systems can prove difficult.

Therefore, mobile device12supports network access requests using virtual access point names. To generate a “virtual” network access request, mobile device12uses a virtual access point name as the indicated access point name and includes the actually requested access point name within another field of the network access request. For example, using the previous values, in the access point name field, mobile device12uses a value of intranet, and as the user identifier, mobile device12uses a value of Bob@Cisco.com. Thus, the network access request requests access to the virtual access point name of intranet while incorporating the actually requested access point name within another field of the request. Therefore, within this description, the term virtual network access request refers to any suitable message requesting access to a virtual access point name.

In the example given, mobile device12incorporates the actually requested access point name within the user identifier. This field is selected because, with respect to HLR28and serving node22, this is a pass-through field. That is, the user identifier field does not affect the operation of HLR28or serving node22. Moreover, serving node22passes the value of the user identifier field through in the network access request forwarded on to gateway24or virtual address translation module34. Therefore, the user identifier value set by mobile device12passes to gateway24or virtual address translation module34without affecting the operation of serving node22or HLR28, and can thus include any suitable information generated by mobile device12for interpretation by virtual address translation module34. However, while in the example given, mobile device12includes the actually requested access point name in the user identifier value, system10contemplates mobile device12incorporating this actually requested access point name within any suitable pass-through field of the network access request. That is, network access requests from mobile devices12may include a number of different pass-through fields, and system10contemplates mobile devices12and virtual address translation module34using any one of these pass-through fields in which to indicate actually requested access point names.

After generating the network access request, mobile device12communicates the request to operator network16. Within operator network16, serving node22receives and processes the network access request. As previously discussed, serving node processes the request through communications with HLR28that identify the access point name from the request. That is, serving node22access HLR28with the indicated access point name, regardless of whether the access point name is virtual or not. Thus, for a network access request indicating a virtual access point name, serving node22verifies the virtual access point name using HLR28. If HLR28is appropriately configured to validate the virtual access point name, HLR28will respond to serving node22that the request is valid. Therefore, HLR28need not reflect the actual access point name identified in the request, thus reducing the need for frequent maintenance and reconfiguration of HLR28.

After receiving validation from HLR28, serving node22determines the appropriate destination to receive a forwarded version of the network access request. To identify this destination, serving node22accesses domain name server26using the network identified within the access point name field of the network access request. Once again, serving node22uses the indicated access point name, regardless of whether it is virtual or not. Thus, for the request that identifies a virtual access point name, serving node22accesses domain name server26using this virtual access point name. In response to a domain name look-up request identifying a virtual access point name, domain name server26returns the IP address of virtual address translation module34. Therefore, to support virtual access point names, both HLR28and domain name server26should be configured to recognize and respond appropriately to virtual access point names. However, serving node22need not have any awareness of the existence or distinction provided by virtual access point names.

After determining an IP address to which to forward the network access request, serving node22forwards the request to the identified destination. As previously discussed, serving node22may reformat the network access request received from mobile device12to conform to protocols expected by gateway24. According to particular embodiments, whether or not reformatting takes place, the information reflected in pass-through fields remains unchanged. Thus, given the example values above, the user identifier value in the network access request forwarded will include a value of Bob@Cisco.com. Thus, serving node22may unwittingly pass through the access point name requested by mobile device12for processing by virtual address translation module34.

Upon receiving a network access request, virtual address translation module34determines whether the request indicates a virtual access point name. If not, virtual address translation module34simply forwards the request to the appropriate gateway24. However, if the request indicates a virtual access point name, virtual address translation module34identifies an actually requested access point name, modifies the request, and forwards the modified request to the appropriate gateway24. To determine the actually requested access point name, virtual address translation module34analyzes information in fields not typically used to identify the requested network.

For example, given the example network access request above, virtual address translation module34parses the user identifier field to determine the portion indicating the user identifier and the portion indicating the actual access point name requested. In this example, virtual address translation module34uses the @ sign as a delimiter to parse the user identifier value of Bob and the access point name of Cisco.com. Virtual address translation module34then modifies the network access request to remove the virtual network. For example, virtual address translation module34may set the user identifier field to Bob and the access point name field to Cisco.com. Therefore, the information in the modified request appears as if mobile device12had created the request without using a virtual address.

After modifying the request, virtual address translation module34forwards the modified request to an appropriate one of gateways24. To determine which gateway24to receive the request, virtual address translation module34communicates a domain name request to domain name server27and identifies the requested network within the domain name request. For virtual network access requests, the requested network is the value parsed from the pass-through field. For other requests, the requested network is simply the value from the access point name field. In response to the domain name request, domain name server27returns IP addresses for one or more gateways24that link to the identified network. Virtual address translation module34selects one of these addresses and forwards the network access request to the selected address.

To forward the request, virtual address translation module34modifies the header of the network access request so that the destination address identifies the selected IP address for gateway24. According to particular embodiments, virtual address translation module34leaves the source address in the header untouched, so that the network access request appears to have been sent by serving node22. In this manner, virtual address translation module34forwards gateway24a network access request that does not include virtual addressing and appears as if generated by serving node22. This permits gateway24to process the request and respond directly to serving node22without further communications with virtual address translation module34.

Upon receiving a network access request, gateway24processes the request as discussed above. For example, gateway24may authenticate and/or authorize the request, determine an IP address to dynamically assign to mobile device12, and perform other processing as appropriate. If the request is validated, gateway24forms a communication link with serving node22, for example, by forming a GTP tunnel with serving node22. Serving node22and gateway24then use this communication link to transport packets across operator network16for communications between mobile device12and the requested network. Therefore, whether receiving a network access request from serving node22or virtual address translation module34, gateway24may perform similar processing of the request.

FIG. 2illustrates a particular embodiment of mobile device12that includes a user interface50, a wireless interface52, a processor54and a memory56. In general, mobile device12provides wireless services, including packet-based services, using wireless interface52. Mobile device12provides access to remote data networks by generating network access requests and supports the use of virtual access point names within generated network access requests.

User interface50provides for interactions with users of mobile device12. For example, user interface50may include a display, keypad and/or other suitable elements for presenting information to and receiving information from users. Wireless interface52supports wireless communications between mobile device12and other communications equipment, such as base transceiver stations. Processor54controls the management and operation of mobile device12. For example, processor54may include one or more microprocessors, programmed logic devices, or other suitable elements for controlling the operation of mobile device12.

Mobile device12also includes memory56, which in the embodiment illustrated includes code58, configuration information60, a user request62, and a virtual access point name64. Code58includes software and/or other appropriate controlling logic for use by elements of mobile device12, such as processor54. Configuration information60includes start-up, operating, and other suitable settings and configurations for use by mobile device12. For example, configuration information60may indicate whether or not to enable virtual access point names when communicating with certain operator networks16. User request62includes information, pre-specified and/or provided by a user, for generating a network access request. For example, user request62may include a user identifier, password, and a requested access point name, in addition to other suitable information. Virtual access point name64includes a value for use by mobile device12in generating virtual network access requests. Virtual access point name64includes a value recognizable by gateways24as indicating a virtual network. Moreover, virtual access point name64corresponds to a value configured in HLR28and domain name server26.

During operation, mobile device12generates network access requests and communicates these requests through operator network16using wireless interface52. Mobile device12may generate these network access requests in response to commands received from a user through user interface50. For example, through a web browser, dialog box, or other suitable interface, a user may provide a user identifier, password, and requested access point name. However, some or all of this information may be pre-configured within memory56by the user, manufacturer, and/or administrator. In response to the request, processor54builds a network access request using information provided by the user and information from memory56. In building the network access request, mobile device12may determine whether the use of a virtual access point name is appropriate. For example, mobile device12may access configuration information60to determine whether virtual access point names are supported by operator network16providing service to mobile device12.

If the use of a virtual access point name is appropriate, mobile device12builds the network access request using virtual access point name64. As previously discussed, mobile device12builds the virtual network access request by inserting virtual access point name64within the requested access point name field of the network access request. To include the actually requested access point name, processor54builds a pass-through string for insertion into a pass-through field of the network access request. For example, processor54may build an @ sign delimited string that indicates both the user identifier and the actually requested access point name and insert this string into the user identifier field of the network access request. As previously discussed, this enables gateway24to parse and interpret the different portions of the user identifier field. However, the use of the user identifier field is given only as an example, and system10contemplates mobile device12using any suitable pass-through field within a network access request in which to incorporate an actually requested access point name. Similarly, the pass-through field may be delimited by any suitable character.

While the embodiment illustrated and the preceding description focus on a particular embodiment of mobile device12that includes specific elements, system10contemplates mobile device12having any suitable combination and arrangement of elements for providing wireless packet-based services and accessing remote networks using virtual network access request. Thus, the modules and functionalities described may be combined, separated or otherwise distributed among any suitable functional components. For example, mobile device12may include a wireless telephone coupled to a mobile computer such that the mobile computer accesses packet-based services wirelessly using the mobile telephone. System10further contemplates mobile device12implementing some or all of the functionalities described using logic encoded in media, such as software or programmed logic devices.

FIG. 3is a block diagram illustrating exemplary functional components for virtual address translation module34that include an interface80, a processor82, and a memory84. In general, virtual address translation module34provides interpretation and modification of network access requests that identify virtual networks. During operation, virtual address translation module34receives network access requests identifying virtual networks, modifies these requests to identify actually requested networks, and forwards the requests to appropriate gateways24.

Interface80links virtual address translation module34to other equipment within operator network16. For example, using operator network interface80, virtual address translation module34may communicate with serving node22, domain name server26, gateways24, and other appropriate elements within operator network16. Processor82controls the operation and management of elements within virtual address translation module34. For example, processor82may include one or more microprocessors, programmed logic devices, or other appropriate controlling elements.

Memory84represents any suitable combination and arrangement of local and/or remote storage devices for use by virtual address translation module34to maintain and access information during operation. In the embodiment illustrated, memory84maintains virtual access point name (VAPN) information86and code88. Code88represents software and/or other appropriate controlling logic for use by elements of virtual address translation module34, such as processor82, during operation. For example, code88may include routines for processing network access requests. VAPN information86includes information identifying virtual access point names that may be used to indicate virtual network access requests. Virtual address translation module34may use VAPN information86to determine those network access requests that appropriately indicate a virtual access point name.

However, while illustrated as maintaining particular data, system10contemplates virtual address translation module34maintaining any suitable information. For example, virtual address translation module34need not store VAPN information86. Instead of using this explicit information, virtual address translation module34may rely on the value of the pass-through field for received requests. For example, to determine whether a request identifies a virtual access point name, virtual address translation module34may determine whether the pass-through field includes the delimiter used to separate the pass-through value from the actually requested access point name. If so, virtual address translation module34can assume that the access point name field indicates a virtual access point name.

During operation, virtual address translation module34interprets and modifies network access requests that identify virtual networks. Upon receiving a network access request, virtual address translation module34determines whether the request includes a virtual access point name. According to particular embodiments, virtual address translation module34looks for a delimiter in the pass-through field, as described above. According to other embodiments, virtual address translation module34accesses VAPN information86to determine whether the request indicates a virtual network.

If the network access request identifies a virtual access point name, virtual address translation module34identifies an actually requested access point name within the request, modifies the request, and forwards the modified request to the one of gateways24. As previously discussed, virtual address translation module34determines the actually requested network by analyzing information in fields not typically identifying the requested network. For example, if the actually requested network is embedded in the user identifier, virtual address translation module34parses the user identifier field to determine the portion indicating the user identifier and the portion indicating the actual access point name requested. Virtual address translation module34then modifies the network access request to indicate the actually requested network in the appropriate field.

Virtual address translation module34then forwards the request to an appropriate one of gateways24. As previously discussed, virtual address translation module34accesses domain name server27using the actually requested network to determine IP addresses for one or more gateways24linking to the requested network. Virtual address translation module34selects one of these addresses, modifies the header of the request to indicate the selected IP address, and forwards the network access request to the selected address. Therefore, virtual address translation module34interprets and modifies virtual network access requests to enable system10to support these virtual requests without requiring elements to have an awareness of this support. For example, in the embodiment described, gateways24and serving node22need not have an awareness of the support for virtual access point names.

However, while the embodiment illustrated and the preceding description focus on a particular embodiment of virtual address translation module34that includes specific elements, system10contemplates virtual address translation module34having any suitable combination and arrangement of elements for processing network access requests that identify virtual access point names. Therefore, the modules and functionalities described may be combined, separated, or otherwise distributed among any suitable functional components, and some or all of the functionalities of virtual address translation module34may be formed by logic encoded in media, such as software and programmed logic devices.

FIG. 4is a flowchart illustrating a method for generating a network access request that potentially includes a virtual access point name. The following text describes the operation of the method with respect to mobile device12. Mobile device12determines a user identifier and password at step100. For example, mobile device12may present a log-in dialog using user interface50and receive input from a user. Alternatively, mobile device12may access memory56to determine pre-configured user identifier and password information. Mobile device12determines the requested access point name at step102. Similar to the determination of the user identifier and password, mobile device12may use information maintained within memory56and/or interaction with a user through user interface50. Mobile device12determines whether virtual access point name requests are enabled at step104. If not, mobile device12generates a conventional network access request at step106.

However, if virtual access point name requests are enabled, mobile device12determines a virtual access point name at step108. For example, mobile device12may access virtual access point name64maintained within memory56. At steps110through116, mobile device12builds a virtual network access request. Mobile device12first generates the network access request at step110and then sets the access point name field equal to the virtual access point name value at step112. Mobile device12builds a pass-through string at step114. This pass-through string includes the actually requested access point name and potentially includes other information typically communicated in a pass-through field. For example, as previously discussed, mobile device12may build a string that includes both the user identifier and the actually requested access point name for communication in the user identifier field. Mobile device12sets the pass-through field equal to the pass-through string at step116.

After generating a conventional network access request or a virtual network access request, mobile device12communicates the request to serving node22of operator network16at step118. Mobile device12then awaits a response from operator network16at steps120and122. At step120, mobile device12determines whether a response has been received, and at step122, mobile device12determines whether the request has timed out. If the request has timed out, mobile device12may indicate an error at step124and complete processing of the network access request. If a response is received and the response affirms the connection at step126, mobile device12establishes a packet-based communication session at step128. This enables the exchange of any suitable packet-based data between mobile device12and the remote network identified by the actually requested access point name.

Thus, the flowchart and preceding description outline the operation of mobile device12in generating a conventional or virtual network access request. However, the flowchart and accompanying description illustrate only an exemplary method of operation, and system10contemplates mobile devices12using any suitable techniques and elements for generating network access requests that incorporate virtual access point names. Therefore, many of the steps in this flowchart may take place simultaneously and/or in different orders than as shown. In addition, mobile device12may use methods with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate.

FIG. 5is a flowchart illustrating a method for virtual address translation module34to handle received network access requests. Virtual address translation module34receives a network access request from serving node22at step150. Virtual address translation module34then determines whether the request includes a virtual access point name at step152. For example, as previously discussed, virtual address translation module34may detect whether or not the pass-through field includes a delimiter used for separating a pass-through value from an actually requested access point name.

If the request is not for a virtual access point name, virtual address translation module34determines the requested access point name from the access point name field at step154. However, if the request identifies a virtual network, virtual address translation module34parses the pass-through field from the network access request to determine the actually requested access point name at step156. After determining the actual access point name requested, virtual address translation module34modifies fields in the request using the determined information at step158. For example, after parsing a user identifier and access point name from a user identifier field, virtual address translation module34replaces the user identifier field with the determined user identifier and replaces the access point name field with the determined access point name.

At steps160and162, virtual address translation module34determines an IP address for gateway24providing access to the requested access point name. For example, virtual address translation module34may communicate a domain name request at step160and receive a response from domain name server27at step162. Using the received address, virtual address translation module34modifies the header of the network access request at step164. That is, virtual address translation module34replaces the destination IP address in the header with the determined IP address for gateway24. Virtual address translation module34forwards the modified network access request to gateway24at step166.

Thus, the flowchart and preceding description outline the operation of virtual address translation module34in handling virtual network access requests. However, the flowchart and accompanying description illustrate only an exemplary method of operation, and system10contemplates virtual address translation module34using any suitable techniques and elements for processing network access requests. Therefore, many of the steps in this flowchart may take place simultaneously and/or in different orders that as shown. In addition, virtual address translation module34may use methods with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate.

Although the present invention has been described in several embodiments, a myriad of changes and modifications may be suggested to one skilled in the art, and it is intended that the present invention encompass such changes and modifications as fall within the scope of the present appended claims.