HK1189115B - Providing multiple levels of service for wireless communication - Google Patents

Description

Providing multi-level services for wireless communications

The application is a divisional application of Chinese patent application with application number 200980108635.0 (PCT/US 2009/036858) and the invention name of providing multi-level service for wireless communication.

Priority requirements according to 35U.S.C. § 119

The benefit and priority of commonly owned U.S. provisional patent application No.61/036,037 (filed on 12/3/2008, assigned attorney docket number 081105P1), U.S. provisional patent application No.61/091,675 (filed on 25/8/2008, assigned attorney docket number 082459P1), and U.S. provisional patent application No.61/115,430 (filed on 17/11/2008, assigned attorney docket number 090515P1), the disclosures of which are hereby incorporated by reference herein.

Technical Field

The present application relates generally to wireless communications and more particularly, but not exclusively, to improving communication performance.

Background

Wireless communication systems are widely deployed to provide various types of communication (e.g., voice, data, multimedia services, etc.) to multiple users. With the rapid increase in demand for high-rate and multimedia data services, there is a challenge to implement efficient and robust communication systems with enhanced performance.

To supplement conventional mobile phone network access points, small coverage access points (e.g., installed in a user's home) may be used to provide more robust indoor wireless coverage for the mobile unit. Such small-coverage access points are generally referred to as access point base stations, home node bs (nodebs), or femtocells (femtocells). Typically, such small-coverage access points are connected to the internet and the mobile operator's network via a DSL router or a cable modem.

In some wireless architectures, an access point is a layer 2 device that does not process internet protocol ("IP") packets routed to or from an access terminal. For example, on the reverse link, an access point may receive packets from an access terminal and forward the packets into the network via a protocol tunnel. Conversely, on the forward link, the access point may receive packets from the network via a protocol tunnel and transmit packets to the access terminal associated with the protocol tunnel. Thus, the end point of the protocol tunnel may be the first hop router (or a node on the far side of the first hop router). Likewise, any packet from the access terminal will traverse the route before being forwarded to its destination. Similarly, any packets destined for the access terminal will be routed through the end point device of the tunnel. However, when the first hop router is relatively far away from the access terminal, a less than optimal route may occur. Further, the access terminal may not be able to access the local service because the local service may not be visible to the first hop router (e.g., due to a firewall at the router associated with the local service). Accordingly, there is a need for improved routing techniques for wireless networks.

Disclosure of Invention

The following is a summary of example aspects of the disclosure. It should be understood that any reference herein to a term aspect may refer to one or more aspects of the present disclosure.

In a certain aspect, the present disclosure is directed to providing a local breakout (localbreatkout) to facilitate access to one or more local services. For example, a local breakout may be provided by a local access point and/or a local gateway to enable an access terminal to access one or more services that may be accessed via the local access point and/or the local gateway.

In a certain aspect, the present disclosure relates to providing multiple IP points of presence (e.g., points of attachment) for an access terminal. Here, each point of presence may correspond to a different service (e.g., a different level of service). For example, one point of presence may relate to a local service, while another point of presence may relate to a core network service. Thus, in some aspects, a service level may relate to a termination point of a packet in a network. In some aspects, an access terminal uses multiple IP points of presence to access services via associated access points, wherein the access terminal and access points communicate over a single air interface.

In a certain aspect, the disclosure relates to transmitting a packet in a manner that indicates a level of service associated with the packet. In this way, a node sending a packet over the air may indicate the termination point of the packet. In some aspects, the service level may indicate whether the packet is to be sent via a protocol tunnel and/or indicate an endpoint of the protocol tunnel used to route the packet. By way of example, an access terminal can identify a service level for a packet by specifying a particular flow over which the packet is to be transmitted, or by transmitting an appropriate identifier with the packet (e.g., in a header). The access point that received the packet over the air from the access terminal may then determine how to send the packet based on the identified service level (e.g., determine whether to send the packet via a tunnel and/or determine an endpoint).

In a certain aspect, the present disclosure relates to providing different mobility management functions and/or session management functions at different nodes in a system, whereby mobility and/or session management may be provided for a given node by different nodes for different services. For example, the network node may provide mobility and/or session management related to core network traffic, while the local node may provide mobility and/or session management related to local traffic at the local node.

In a certain aspect, the present disclosure is directed to an access terminal that supports multiple non-access stratum ("NAS") instances for establishing access to different services (e.g., local IP access, network IP access). For example, to communicate with a local mobility manager (e.g., which handles local mobility and session management), one or more NAS instances may be defined to facilitate access to local services; while in order to communicate with a network mobility manager (e.g., that handles core network mobility and session management), one or more other NAS instances may be defined to facilitate access to core network services.

In a certain aspect, the present disclosure relates to providing different types of paging for different types of traffic. For example, paging for local traffic may be managed by a local mobility manager, while paging for network traffic is managed by a network mobility manager.

In a certain aspect, the present disclosure relates to carrying messages over one protocol (e.g., S1) typically related to another protocol (e.g., S11). For example, S11 protocol messages sent between the serving gateway and the mobility manager to create a bearer (bearer) may be carried by the S1 protocol between the mobility manager and an access point co-located with the serving gateway.

Drawings

These and other exemplary aspects of the present disclosure will become apparent from the detailed description and the appended claims, and from the accompanying drawings, in which:

fig. 1 is a simplified block diagram of some example aspects of a wireless communication system for providing local breakout;

FIG. 2 is a flow diagram of some example aspects of operations performed to provide multiple points of presence;

FIG. 3 is a flow diagram of some example aspects of operations performed to identify points of presence for over-the-air packets;

FIG. 4 is a flow diagram of some example aspects of operations performed to determine a service level for an over-the-air packet;

FIG. 5 is a flow diagram of some example aspects of operations performed to provide distributed control management functionality;

FIG. 6 is a simplified block diagram of some example aspects of components of a wireless node employed to provide local breakout;

fig. 7 is a simplified block diagram of some example aspects of a wireless communication system for providing local breakout;

FIG. 8 is a simplified diagram of an example control plane protocol stack;

FIG. 9 is a simplified diagram of an example data plane protocol stack;

FIG. 10 is a simplified diagram illustrating an example attach call flow;

FIG. 11 is a simplified diagram illustrating an example triggered service request call flow;

FIG. 12 is a simplified diagram illustrating an example triggered service request call flow;

fig. 13 is a simplified block diagram of some example aspects of a wireless communication system for providing local breakout;

FIG. 14 is a simplified diagram illustrating an example attach call flow;

FIG. 15 is a simplified diagram illustrating an example attach call flow in which messages related to one protocol are carried over another protocol;

fig. 16 is a simplified block diagram of some example aspects of a wireless communication system for providing local breakout;

17A and 17B are simplified block diagrams of some example aspects of a wireless communication system employing multiple keys to support multiple links for local breakout;

18A and 18B are simplified block diagrams of some example aspects of a wireless communication system employing a single key to support multiple links for local breakout;

fig. 19 is a simplified diagram illustrating a coverage area for wireless communication;

FIG. 20 is a simplified diagram of a wireless communication system;

fig. 21 is a simplified diagram of a wireless communication system including a femto node;

FIG. 22 is a simplified block diagram of several exemplary aspects of a communications component; and

23-25 are simplified block diagrams of some example aspects of an apparatus to facilitate local breakout according to techniques taught herein.

In accordance with common practice, the various features shown in the drawings may not be drawn to scale. Accordingly, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. In addition, some of the drawings may be simplified for clarity. Accordingly, the drawings may not depict all of the components of a given apparatus (e.g., device) or method. Finally, the same reference numerals may be used throughout the specification and drawings to refer to the same features.

Detailed Description

Various aspects of the disclosure are described below. It should be apparent that the techniques taught herein may be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, such an apparatus may be implemented or such a method may be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. Furthermore, an aspect may comprise at least one element of a claim.

Fig. 1 illustrates several nodes in an example communication system 100 (e.g., a portion of a communication network). For purposes of illustration, aspects of the disclosure will be described in the context of one or more access terminals, access points, gateways, and network nodes communicating with each other. However, it should be recognized that the techniques taught herein may be applied to other types of devices or other similar devices that are referred to using other terms. For example, in various implementations, an access point can be referred to as or implemented as a base station, an access terminal can be referred to as or implemented as a user device, and so on.

System 100 includes access points that provide one or more services (e.g., network connections) for one or more access terminals that may be camped on or may be roaming in an associated geographic area. To reduce the complexity of fig. 1, only a single access point 102 and a single access terminal 104 are shown. Each access point in system 100 may communicate with one or more network nodes (e.g., first hop routers 106 and other network nodes 108) to facilitate wide area network connectivity. These network nodes may take various forms, such as one or more wireless and/or core network entities (e.g., mobility management entities, session reference network controllers, gateways, routers, or some other suitable network entity or entities), one or more communication nodes, and so forth.

System 100 includes various nodes that provide access to different services (e.g., different levels of service). In particular, the system 100 includes one or more nodes (e.g., local router 110 and gateway 112) for providing local breakout to one or more local services (e.g., at a visited network). For example, the local router 110 may enable the access terminal 104 to access one or more local services 114. Similarly, a gateway 112 (e.g., an edge gateway) may enable access terminals 104 to access one or more local services 116.

These local services may take various forms. For example, in some implementations, local services 114 may relate to services provided by a local network (e.g., by various entities on the same IP subnet controlled by local router 110). For example, such local network services may include access to a local printer, a local server, or some other entity. In some implementations, the local service 114 may include an internet connection. For example, the local router 110 may enable the access terminal 104 to access an internet connection provided by an internet service provider ("ISP") at a particular location (e.g., a user's home, an internet hotspot, etc.). In some implementations, the local service 116 may relate to a network-related service that is local in nature. For example, the local service 116 may relate to location (e.g., position) information that the access terminal 104 may use to obtain other services.

To facilitate local breakout, the access terminal 104 is provided with multiple IP points of presence ("POPs"). In connection with each point of presence, the access point 104 provides a respective IP interface (associated with an IP address) associated with a respective level of service. As such, the access terminal 104 may use a first IP address to access a first level of service (e.g., network services) and a second IP address to access a second level of service (e.g., local services). For example, one or more network points of presence 118 may be defined to enable access terminal 104 to communicate with first hop router 106 (e.g., a core network gateway) to obtain services via a core network (e.g., from a local network). Additionally, one or more network points of presence 120 may be defined to enable the access terminal 104 to communicate with local entities for accessing local services. For example, the access terminal 104 may use point of presence 120A to access the local service 114 and the access terminal 104 may use point of presence 120B to access the local service 116.

Exemplary local breakout related operations will now be discussed in more detail in conjunction with the flowcharts of FIGS. 2-5. For convenience, the operations of fig. 2-5 (or any other operations discussed or taught herein) may be described as being performed by specific components (e.g., components of system 100 and/or system 600 as described in fig. 6). However, it should be appreciated that these operations may be performed by other types of components, and may be performed using a different number of components. It should also be appreciated that one or more of the operations described herein may not be employed in a given implementation.

Referring first to fig. 2, several operations will be described that involve providing multiple points of presence for local breakout. Blocks 202 and 204 relate to providing points of presence for the access terminal 104. In different implementations, the point of presence may relate to different parameters. For example, in some implementations (e.g., LTE-based implementations), each point of presence may relate to a different access point name ("APN") associated with the bearer service. Thus, a first level of service (e.g., local service) may be associated with one APNID, while another level of service (e.g., core network service) may be associated with another APNID. In some implementations (e.g., UMB-based implementations), each point of presence may involve a different link id (linkid). Thus, a first level of service may be associated with one link ID and another level of service may be associated with another link ID.

As represented by block 202, a first point of presence is provided for a local service. Here, the access point 102 (e.g., in cooperation with the local router 110) may assign an IP address to the access terminal 104 that is to be used in routing local traffic to and from the access terminal 104. For example, an IP address may be assigned for accessing the local service 114 via the local router 110. Alternatively or additionally, an IP address may be assigned for accessing the local service 116 via the gateway 112. Thus, the access point 102 may use the local IP address to route packets between the access terminal 104 and the entity providing the local service.

As represented by block 204, a second point of presence is provided for the network service. In this case, the network (e.g., first hop router 106) may assign an IP address to access terminal 104 that is to be used in routing network traffic to access terminal 104 and in routing network traffic from access terminal 104. Thus, the access point 102 may use the IP address to route packets between the access terminal 104 and the entity providing the network service.

Block 206-. In particular, as will be described in greater detail in connection with fig. 7, in some implementations, control management functions for a given access terminal may be provided by different entities. For example, mobility management functions relating to local services may be provided by a local mobility manager (not shown in fig. 1). Conversely, mobility management functions relating to network services may be provided by a network mobility management entity (not shown in figure 1).

As represented by block 206, for local traffic, the local control manager may establish one or more flows and provide other session management functions. For example, a local mobility management entity ("MME") may establish one or more bearers to enable the access terminal 104 to communicate with a local service provider. To this end, the local MME may manage bearer establishment, quality of service ("QoS"), and IP addresses for local services.

As represented by block 208, the network control manager may also establish one or more flows for network traffic and provide other session management functions. For example, a network mobility management entity ("MME") may establish one or more bearers to enable the access terminal 104 to communicate with a network service provider. To this end, the network MME may manage bearer establishment, quality of service ("QoS"), and IP addresses for network services.

As represented by block 210, the local control manager may also manage paging and provide other mobility management functions for local traffic. For example, when local traffic is received from a local service provider (as at the access point 102), if the access terminal 104 is currently in a dormant mode (e.g., a low power consumption mode), a local mobility management entity ("MME") may cause the access point 102 to page the access terminal 104. Here, since traffic is associated with local services, the local MME may initiate paging only at access point 102 (and not any other nearby access points).

As represented by block 212, the network control manager may also manage paging and provide other mobility management functions for network traffic. For example, when network traffic is received (e.g., at first hop router 106), the access terminal 104 may be paged by a network mobility management entity ("MME") if the access terminal 104 is currently in a dormant mode. Here, since the received traffic may be normal network traffic, the network MME may initiate paging according to standard network paging rules. For example, the access terminal 104 may be paged through all access points associated with one or more tracking areas, one or more regions, etc., or the access terminal 104 may be paged according to distance-based paging rules or other types of paging rules.

Referring now to fig. 3 and 4, some operations involving identifying points of presence for local breakout are described. These operations may be employed, for example, to efficiently identify termination points of packets traveling over the air between an access terminal and an access point. For example, for an access point that receives a tunneled packet from an access terminal, it may be impractical or impossible to determine the IP destination of the packet. Accordingly, techniques for efficiently routing such packets are described.

Fig. 3 depicts these operations at a relatively high level. As represented by block 302 of fig. 3, initially, the node may identify a point of presence for an over-the-air packet to indicate a termination point of a protocol tunnel for the packet. The node may then send the packet based on the identified point of presence (block 304). These high-level operations may be performed at the access terminal and the access point, as described in more detail in fig. 4. For example, an access terminal may determine a point of presence for a packet to be transmitted and then transmit the packet over the air based on the determination. Conversely, the access point may determine a point of presence for a packet received over the air and then forward the packet based on the identified point of presence.

Referring now to fig. 4, as represented by blocks 402 and 404, different IP points of presence may be provided for an access terminal to enable the access terminal to access different levels of service. Here, each level of service may determine a different termination point in the network for the packet. In other words, the service level may indicate where in the network packets from the access terminal are going to come out. For example, the service level may indicate whether packets are to be tunneled (e.g., a local level service may indicate that no tunnel is present, while a core network level service may indicate that a tunnel is present). As another example, the service level may indicate that packets are to be sent via a tunnel terminated in the visited network and/or in the core gateway. As another example, the service level may indicate that the packet is to be sent via a tunnel terminated in the local network and/or in the core network gateway. It should be appreciated that the service level may be indicated in various ways (e.g., by numbers, by ASCII text, etc.).

As represented by block 406, when the access terminal needs to send packets over the air to the access point, the access terminal may identify a point of presence for the service. As discussed above, in some aspects, points of presence may relate to different levels of service (e.g., local traffic or network traffic). In some aspects, the point of presence indicates a PSN gateway at the end of the tunnel. Thus, in some aspects, a point of presence may be used to indicate the depth of the endpoint within the network (e.g., the endpoint may be located in a local network or a visited network).

In some implementations, different levels of service may be associated with different flows (e.g., associated with different quality of service parameters). For example, a first level of service may be associated with a first set of one or more flows, while a second level of service may be associated with a second set of one or more flows. Accordingly, the operations of block 406 may include: a particular flow for a given level of service over which over-the-air packets are to be sent is identified (e.g., by identifying flows from the respective group). In different implementations, these streams may take different forms. For example, in an LTE-based implementation, different groups of flows may involve different groups of data radio bearers ("DRBs").

In some implementations, different levels of service may be identified by using unique identifiers associated with each level of service. For example, when transmitting over the air, the identifier may be transmitted with the packet. Thus, in this case, the operations of block 402 may include: an identifier associated with a service level is determined for a packet to be transmitted over the air.

The access terminal then transmits traffic indicating the service level, as represented by block 408. As discussed above, in some implementations, this may include sending packets over the air via an appropriate flow. Conversely, in other implementations, this may include sending the appropriate identifier with the packet. In some implementations, the identifier may be sent via a packet header. For example, for a packet, a special packet header including an identifier may be inserted between an IP packet header and an air interface packet header (e.g., an RLP header).

The access point then receives the packet over the air, as represented by block 410. The access point may then determine a service level for the packet, as represented by block 412. For example, the access point may identify the service level by determining the flow on which the packet was sent or by reading an identifier sent with the packet.

As represented by block 414, the access point determines how to send the packet based on the determined service level. Based on the service level, the access point may determine a termination point (e.g., an endpoint) of the packet in the network. For example, as described above, the service level may indicate whether the packet is to be tunneled. If the packet is to be tunneled, the service level may indicate where the tunnel terminates (e.g., visited network, edge gateway, home network, core network gateway). In other words, in some aspects, the end point of the packet may correspond to a termination point of a protocol tunnel through which the packet is sent from the access terminal to another node (e.g., first hop router 106 or a home service provider in fig. 1). Accordingly, packets may be routed to a specified endpoint (e.g., associated with a network service or a local service) in a relatively efficient manner.

Referring now to fig. 5, some operations involving the use of distributed MMEs will be described. Blocks 502 and 504 relate to operations that may be performed in implementations in which some MME functionality is provided for an access terminal at one node and some MME functionality is provided for the access terminal at another node.

As represented by block 502, a first MME may be provided at a first node (e.g., a local node). For example, local MME functionality may be implemented at the access point, as will be described in more detail below in connection with fig. 7. For example, the local MME may provide bearer and paging management and other mobility and session management for local egress traffic to and from the access terminal.

As represented by block 504, a second MME may be provided at another node in the system. For example, core network MME functionality may be implemented at a core network node. For example, the network MME may provide bearer and paging management and other mobility and session management for core network traffic to and from the access terminal.

Blocks 506 and 508 relate to operations performed to support multiple control signaling instances to facilitate access to different services. For example, an access terminal may support multiple NAS instances for communicating with different MMEs at different nodes.

As represented by block 506, the access terminal communicates with the first MME (e.g., control plane traffic terminated at the MME) via first control signaling. For example, an access terminal may support a first NAS instance for communicating with a local MME to facilitate access to one or more local services.

The access terminal communicates with the second MME via second control signaling, as represented by block 508. For example, the access terminal can support a second NAS instance for communicating with a network MME to facilitate access to one or more network services.

In some aspects, NAS signaling is used for mobility management and session management. For example, mobility management may include managing mobility and managing paging for an access terminal. In addition, session management may include managing bearer establishment, QoS, and different IP addresses for the access terminal. Here, NAS signaling involves control plane messaging between an access terminal and a control manager (e.g., MME), and is distinct from the access stratum ("AS") between the access terminal and the associated access point controlling wireless access (e.g., a route established over the air interface for NAS signaling). At the same time, it should be appreciated that NAS signaling for all NAS instances can be routed over the same (i.e., common) air interface between the access terminal and the associated access point.

The access terminal may then access the first service and the second service via a common air interface, as represented by block 510. Here, access to the first service is supported by the first NAS instance and access to the second service is supported by the second NAS instance.

Fig. 6 depicts some components that may be employed in nodes such as access point 602 and access terminal 604 to provide functionality relating to local breakout as taught herein. It should be appreciated that the described components may also be incorporated into other nodes in a communication system. For example, other nodes in the system may include similar components to those described for access point 602 and access terminal 604 to provide similar functionality. In addition, a given node may contain one or more of the described components. For example, a node may contain multiple transceiver components that enable the node to operate on multiple frequencies and/or communicate via different technologies.

As shown in fig. 6, access point 602 and access terminal 604 may include respective transceivers 606 and 608 for communicating with each other and with other nodes. The transceiver 606 includes a transmitter 610 for transmitting signals (e.g., messages and packets) and a receiver 612 for receiving signals. Similarly, the transceiver 608 includes a transmitter 614 for transmitting signals and a receiver 616 for receiving signals.

Access point 602 and access terminal 604 include other components that may be used for local breakout operations as taught herein. For example, the access point 602 and the access terminal 604 may include respective point of presence controllers 618 and 620 for providing (e.g., defining and/or maintaining) multiple points of presence for accessing different services (e.g., local services and network services), as well as for providing other related functionality as taught herein. Access point 602 and access terminal 604 may include respective communication controllers 622 and 624 for sending and receiving traffic (e.g., traffic, messages, and packets indicating different levels of service), for accessing services, for determining how to send packets (e.g., via tunneling or not), and for providing other related functionality as taught herein. The access point 602 and the access terminal 604 may include respective control signal processors 626 and 628 for sending and/or receiving control signaling (e.g., to/from an MME), for supporting (e.g., using and/or defining) multiple NAS instances, and for providing other related functionality as taught herein. Access point 602 may include a service level determiner 630 for determining a service level, and for providing other related functionality as taught herein.

The techniques taught herein may be applicable to various communication systems. For example, the techniques described herein may be implemented in an ultra mobile broadband ("UMB") based system, a long term evolution ("LTE") based system, or some other type of communication system. For purposes of illustration, implementation details of some examples will be described in the context of an LTE-based communication system in the discussion that follows in conjunction with fig. 7-15. In addition, in the discussion that follows in connection with fig. 16-18B, implementation details of some examples will be described in the context of a UMB-based communication system. It should be appreciated that some or all of the components and/or operations discussed below may be incorporated into other types of communication systems.

Fig. 7 illustrates some nodes in an example communication system 700 that, for example, encompasses a portion of an LTE-based network that includes UMTS terrestrial radio access network ("UTRAN") components, gsm edge radio access network ("GERAN") components, and evolved packet core ("EPC") components. In this example, a user equipment ("UE") 702 communicates over the air with a home eNodeB ("HENB") 704 (and possibly other UTRAN network elements not shown).

To facilitate local breakout, a portion of the functionality that would conventionally be implemented in a network is implemented in the HENB 704. In particular, co-located with the HENB704 are a home serving gateway ("HSGW") 706, a home packet data network gateway ("HPGW") 708, and a home MME ("HMME") 710. For simplicity, these co-located components may be referred to herein as a local SGW, a local PGW, and a local MME, respectively. In addition, HENB704 and co-located components may be referred to herein as collectively comprising a femto node.

The system 700 employs various protocols to facilitate communications between the functional modules shown. For example, as indicated by line 713, HENB704 may communicate with MME712 (e.g., core network MME) via S1 protocol. As indicated by line 716, the HENB704 may communicate with the SGW714 (e.g., a network SGW) via the S1 protocol. As indicated by line 720, MME712 may communicate with a serving GPRS support node ("SGSN") 718 via the S3 protocol. MME712 may also communicate with home subscriber server ("HSS") 722 via an S6a protocol, as indicated by line 724. As indicated by line 726, SGW714 may communicate with other UTRAN components via the S12 protocol; as indicated by line 728, SGW714 may communicate with SGSN718 via the S4 protocol; as indicated by line 730, SGW714 may communicate with MME712 via S11 protocol; and as indicated by line 734, SGW714 may communicate with PSN gateway (e.g., network PGW)732 via S5 and S8 protocols. PGW732 may communicate with packet data network entities such as the internet and IP multimedia subsystem ("IMS") via SGi protocols, as indicated by lines 736 and 738, respectively. Meanwhile, a policy and charging rules function ("PCRF") 740 may communicate with the PGW732 via the Gx protocol, as indicated by line 742, and with the IMS via the Rx protocol, as indicated by line 744.

System 700 provides improved local breakout performance through the use of HSGW706, HPGW708, and HMME 710. As described below, in some aspects, this improved performance may relate to improved mobility management, bearer management, and paging management.

Fig. 7 illustrates routing of local traffic and network traffic via different SGW and PGW entities. Local egress traffic for UE702 is routed to/from a local service provider (not shown in fig. 7) via HENB704, HSGW706, and HPGW708, as represented by line 746. Conversely, network traffic (e.g., home routing traffic) may be routed to/from the packet data network via HENB704, SGW714, and PGW732, as represented by line 748.

To support local and network traffic, the UE may run multiple (e.g., two) partial protocol stacks, where the air interface between the UE and the associated HENB may be shared between the protocol stacks. For example, fig. 8 depicts a control plane protocol stack 800 illustrating that a UE may support multiple NAS instances (in this example, NAS802 and NAS 804). Additionally, fig. 9 depicts a data plane protocol stack 900 illustrating that a UE may support multiple applications (APPL902 and APPL904), where each application is associated with a different IP interface (e.g., corresponding to IP906 and IP 908).

Various provisions may be made at the UE for the data plane to support local traffic and network (e.g., home routing) traffic. As described below, in some implementations, a UE may not be allowed to connect to a HENB local egress unless the UA is accepted by the core network. Thus, if the core network does not authenticate the UE or if the backhaul does not work, the UE may not be able to use the local breakout service. Separate default bearers are established for the local egress path and the network path. From the UE's perspective, the local breakout traffic may simply look like another PDN. The UE knows that there are different sets of bearer channels on the data plane. A different point of presence (e.g., APN) distinguishes the local breakout PDN from the network (e.g., macro) PDN. In this way, the UE will use the appropriate bearers for the local breakout traffic and the network traffic, respectively. For example, the UE may send separate DHCP requests for local breakout traffic and network traffic, respectively.

Various provisions may be made at the UE for the control plane to support local and network traffic. For example, the UE may use an appropriate password when communicating with a network (macro) MME. In contrast, the UE may not use the password (or may use a null password) when communicating with the HMME.

The new service request may be encrypted between the UE and the MME. Here, the HENB may not be able to distinguish whether the request is directed to the HENB (for local breakout) or to the network. Accordingly, schemes such as those described above at fig. 3 and 4 may be employed herein.

In one implementation, a single NASSM layer is employed. Here, the UE may include a specific bit in the header to indicate whether the NAS message is directed to the HMME or the network MME. When the HENB receives the message, it routes the packet to the appropriate destination based on the bit. In this implementation, the UE may use different sequence numbers for messages related to HMME and network MME.

In another implementation, separate NAS signaling bearers are provided for communicating with the HMME and the network MME. Thus, the implementation includes separation of the NASSM layer. Here, the UE places the local breakout request and the network request on the appropriate NAS signaling bearer. When the HENB receives a message on a given NAS signaling bearer, the HENB routes the packet to the appropriate destination based on the bearer.

The system 700 may provide other local breakout functions similar to those discussed above in connection with fig. 1-6. For example, the HENB may assign an IP address for the UE for local breakout. In addition, the UE may be paged for local breakout traffic. Meanwhile, the HENB may support QoS for local breakout traffic. Each of these aspects of the local breakout will be discussed in turn.

Functions such as UEIP address allocation, DHCPv4 and DHCPv6 functions, and neighbor discovery as defined in RFC4861 may be employed to allocate IP addresses for UEs. To provide these functions, a reduced function HPGW may be provided at the HENB, as shown in fig. 7. Here, the HPGW may not support all of the functionality of a conventional PGW (e.g., as deployed in a core network), but may support the above functionality as well as any other functionality that may be desired.

Examples of functions that may be used to enable a UE to be paged for local breakout traffic are given below. Here, the SGW may buffer the packets (e.g., provide ECM-IDLE mode downlink packet buffering). Additionally, the SGW may support initiation of a network triggered service request procedure. Thus, the SGW may alert the relevant MME of the traffic occurrence.

In response to this warning, the MME may determine when and at which eNodeB the UE is to be paged. Thus, the MME may support UE reachability (e.g., including control and execution of paging retransmissions) in the ECM-IDLE state. Here, no NAS signaling is required for paging by the MME. Instead, the MME may simply inform the relevant eNodeB or enodebs (e.g., HENB) when to page the UE. The page is then broadcast by each eNodeB based on the UE's identifier (e.g., GUTI, T-IMSI, etc.).

In some implementations, mobility (e.g., service continuity) for local breakout traffic is not supported. In this case, for local breakout traffic, the UE may only be paged at the respective HENB that provides the local breakout. However, mobility can still be applied to anchor traffic (e.g., anchored in VPLMN or HPLMN). Such anchor traffic may be related to the core PGW or some other anchor PDN, for example. Here, the network MME may cause paging of the UE for anchor traffic at the HENB and macro cell in the current tracking area list for the UE.

To provide the SGW functionality described above, a simplified function HSGW may be provided at the HENB as shown in fig. 7. The HSGW may not support all of the functionality of a conventional SGW (e.g., as deployed in the core network), but may support the above functionality (e.g., providing an interface to the MME to support paging) as well as any other functionality that may be desired.

In some implementations, the MME functionality described above may be provided by including a simplified function HMME at the HENB as shown in fig. 7. That is, the system may employ distributed MME functionality, thereby providing functionality for different types of traffic at different entities in the system (e.g., HMME manages paging and bearers for local services, while network MME manages paging and bearers for network services). HMME may not support all of the functionality of a conventional MME (e.g., as deployed in a core network), but may support the above functionality as well as any other functionality that may be desired.

In other implementations, the MME functionality described above may be provided by using an S11 protocol interface (not shown in fig. 7) from the HSGW to the MME. That is, instead of using HMME as shown in fig. 7, the HSGW may communicate with the core network MME that provides all MME functionality. In some aspects, such implementations may include modifications to the S11 protocol, or may include changing an MME to support multiple SGWs to change the paging behavior of the MME.

Certain efficiencies may be achieved by using distributed MME functionality (e.g., between HMME and core network MME) because messages relating to local traffic may be routed from the HENB to the local MME rather than to the core network MME. In this way, the resulting architecture may avoid using one or more interfaces between the core MME and each HENB (e.g., the S11 interface between the MME and the HSGW). Furthermore, when there are a large number of HENBs in the system, the reduction in message traffic and workload at the core network associated with processing these messages can be significant.

Some examples of the functionality of the HENB employed for supporting local breakout traffic QoS are given below. In some cases, an uplink/downlink traffic flow template ("TFT") and a QoS class indicator ("QCI") are provided for each local egress bearer to support QoS functionality.

Some procedures may be employed to establish an EPS bearer with the HPGW. In one procedure, EPS bearers may be statically configured at the HPGW (e.g., for each HENB rather than for each UE). In another procedure, the STA interface to the HMME may be defined from AAA (access specific). This procedure may be a better choice in implementations where the HMME also authenticates the UE. In another procedure, the Gx interface to the HPGW is defined (dynamically).

Various types of functions may be implemented in the HPGW for supporting QoS for local egress traffic. For example, the HPGW may support packet-based filtering for each user. The HPGW may support transport level packet marking in the uplink. In addition, uplink ("UL") and downlink ("DL") rate policy formulation/formation and gating may be supported. Meanwhile, UL and DL bearer binding as defined in TS23.203 may be supported.

Various types of MME functionality may be provided for supporting QoS for local breakout traffic. For example, NAS signaling and bearer management functions (e.g., including dedicated bearer establishment) may be provided.

In implementations employing HMME (e.g., as shown in fig. 7), HMME may be used for NAS signaling. This means that the UE supports multiple MMENAS signaling instances. One method may include defining a second radio bearer for the henbme. The UE then selects the appropriate bearer based on which PDN is being used (e.g., for local traffic or network traffic). Using multiple bearers may include separate NAS security for each pair or may rely on RRC security.

In implementations that do not employ HMME, an S11 interface to the core network MME may be used in order to support QoS for local breakout traffic. Such implementation may include modifications to the S11 protocol, or may include changing the MME to support multiple SGWs in order to change the way bearers are established by the MME.

In addition to the above functions, other functions may be supported in conjunction with the local breakout. For example, PGW functions such as lawful interception and charging functions may be supported. Examples of charging functions include UL and DL service level charging and UL and DL service level gating as defined in TS 23.203. In addition, MME functionality such as tracking area list management may be supported. Here, the tracking area list for the local breakout may specify only the HENB that provides the local breakout.

Referring now to fig. 10-12, several examples of call flows that may be employed in system 700 will be described. In some implementations, the UE may send an indication to the access point to inform the access point that the UE is capable of receiving local services.

Fig. 10 depicts an example attach call flow. Initially, a UE communicates with a single core network MME (e.g., a macro MME) over a NAS. The UE sends an attach request to the HENB (e.g., to the femto node), and the request is forwarded by the HENB to the network MME. For example, the information provided in the attach request from the UE may include the IMSI or GUTI that can be used by the HENB to find the MME, the last visited tracking area identifier (if available), the UE network capabilities, PDN address allocation (IP version when an address is to be allocated), protocol configuration options, attach type, KSI, NAS sequence number, and NAS-MAC. In some cases, some of this information may be encrypted. However, the UE may need to send some clear text messages to enable the HENB to determine whether the UE can access the local breakout service.

Referring again to fig. 10, the UE communicates with the network MME in order to perform authentication and security operations. Here, the UE may be authenticated by the HSS (not shown in fig. 10).

In addition, a default bearer is established for the network. Here, the network MME sends a create default bearer request. The network SGW cooperates with the network PGW to create a bearer and replies with a create default bearer message.

Subsequently, the network MME sends an attach accept message to the HENB. For example, the information provided in the attach accept message may include APN, GUTI, PDN address information, TAI list, EPS bearer identity, session management configuration IE (e.g., including ULTFT), or call configuration options, KSI, NAS sequence number, NAS-MAC, and NAS security algorithms. Also, some of this information may be encrypted.

Subsequently, the HENB assists the HMME to establish a default bearer for the local breakout. For example, when the HENB receives an attach accept message from the network MME, the HENB may transmit an attach request to the HMME. Subsequently, a default bearer for the local breakout may be created through cooperation of the HMMW, the HSGW, and the HPGW. An RRC connection reconfiguration message may then be sent for local breakout and network traffic and the attach procedure is completed. As can be seen from the above, the UE maintains respective EPS bearers for the local breakout traffic and the network traffic.

At a later point in time, where a dedicated local breakout bearer is required, a suitable procedure may be employed. For example, the UE may signal a local egress using a particular NAS bit. The packet may be routed to the HMME. The HMME local signaling between the HMME and the HSGW establishes a new bearer. The HMME may communicate with the PCRF to learn local breakout policies for the UE.

Fig. 11 depicts an example UE triggered service request call flow. Here, the HENB may establish local breakout communications based on the information it acquires and maintains. For example, the GUTI of the UE may be known at the HENB. Depending on the service type (e.g., data or signaling), the MME may or may not activate the EPS bearer. In some implementations, the HMME may activate the local breakout EPS bearer only if the network EPS bearer is in an active state.

The UE sends a NAS service request message including, for example, GUTI, TMSI, service type, and other information. The HENB sends the NAS service request to the network MME. After authentication, an initial context is established. Radio bearers are established for the network and for the local breakout. Once the bearer is established, network data may be transmitted from the UE to the HENB, then from the HENB to the network SGW, and then to the network PGW. Local breakout data may be sent from the UE to the HENB, then from the HENB to the HSGW, and then to the HPGW.

Fig. 12 depicts an example HENB (e.g., femto node) triggered service request call flow. In implementations where a macro connection is required for authentication, a service request triggered by the HENB for local breakout may establish an EPS bearer with the network. However, this step may be avoided if the service request indicates that it is only for local breakout. In this case, the network MME may not activate any network EPS bearer.

When local data is present at the HPGW, the data is forwarded to the HSGW, and the HSGW informs the HMME that the local data has been received. This triggers paging at the HMME, whereby the HMME sends a message (e.g., a paging request) to the HENB to cause the HENB to page the UE. A UE triggered service request procedure may follow, after which data may be sent from the HSGW to the UE via the HENB.

The HENB may know the paging cycle information in advance. For example, paging DRX of the UE may be included in the paging message. In some implementations, DRX is included as an information element ("IE") in the UE context. Here, when the HENB gets the UE context, the HENB relays DRX to the HMME. In this implementation, the local breakout application may not be allowed to perform a tighter paging cycle. In other implementations, the HENB (e.g., femto node) and the macro cell may use different DRX (e.g., integer multiples). In this case, the UE will wake up at an appropriate period depending on the cell in which the UE is currently in an idle state. Here, the UE will be aware of multiple MME controls. In the case where the UE wakes up at a slower cycle, the UE will receive the page when the two cycles match.

The use of local breakout may have a relatively minimal impact on tracking area updates. For example, the HENB may advertise a single tracking area. That is, no separate tracking area may be defined for local breakout traffic. The UE may perform a tracking area update with the network MME. Here, the UE uses a network bearer and the related NAS messages are routed directly to the network MME. The HMME does not need to know the tracking area update. Instead, the HMME may page only local egress traffic and may page only at the relevant HENB.

Various provisions may be employed to handle local breakout connections when the UE is idle. In some implementations, the IP may be immediately switched off. In this way, all bearers will be torn down and the connection needs to be reconnected when the UE is present again. In other implementations, the IP address may be maintained (e.g., held for a defined period of time). Here, if the UE re-appears with the same GUTI (or S-TMSI), the UE will be able to continue using the existing bearer. Additionally, a trigger may be employed to confirm that the UE has detached from the HENB. For example, a defined number of missed pages may trigger the MME to tear down the bearer.

As described above, some implementations may not employ HMME. Some aspects of such a system will be discussed with reference to the system 1300 of fig. 13 (e.g., where illustrated modules may have similar functionality as the correspondingly-named modules in fig. 7). In this case, as represented by the dashed line 1302 in fig. 13, the HSGW may communicate with the core network via the S11 protocol. For example, the S11 message to be sent between the HSGW and the network MME may include create bearer (default or dedicated), delete bearer, update bearer, dedicated bearer deactivation, bearer resource allocation, bearer resource release, create forwarding tunnel, and other GTP-C messages (e.g., echo (echo)). In this case, the network-initiated service request is differentiated by the network MME as originating from the HSGW or originating from the network AGW. A request for local breakout initiated by the UE will pass from the UE to the HENB, then to the network MME, and finally to the HSGW. The HSGW sends a paging request (e.g., with an indication to page only at the HENB) to the network MME. Paging will pass from the HPGW to the HSGW, then to the network MME, and finally to the HENB.

In implementations that do not employ HMME, the home node supports two different reference points (S1 and S11). This results in more complexity at the HENB and supports, for example, GTP-C and eraap. To simplify the architecture, messages conventionally related to S11 may be carried through S1, in other words, some of the messages defined in S11 may be piggybacked by S1-MME signaling. For example, the message for creating a bearer, which would have been carried on S11 between the network MME and the HSGW, may be carried on S1 between the network MME and the HENB. Thus, in this case, the S11 interface may be eliminated.

Fig. 14 and 15 compare the attachment procedure for the local outlet in both cases with and without the S11 interface, respectively.

In fig. 14, the UE sends an attach request (e.g., including APNID) to the eNB, and the request is forwarded by the eNB to the MME. Subsequently, a default bearer is established for the network. Here, the MME sends a create default bearer request to the SGW, which forwards the request to the PGW. The PGW replies with a create default bearer message, which is forwarded to the MME through the SGW. Subsequently, the MME sends an attach accept message to the eNB. Subsequently, an RRC connection reconfiguration message may be sent and the attach procedure is complete.

In contrast, as represented by line 1502 in fig. 15, the MME sends an initial context setup request message and a create default bearer request message back to the HENB as a response to the attach request (e.g., including the APN value that triggered the new attach). The HENB then sends an initial context setup response message and a create default bearer response message back to the MME, as represented by line 1504. A similar approach may be used to establish subsequent dedicated bearers. Advantageously, the "S11" message represented by lines 1502 and 1504 is carried over the S1 connection (e.g., via line 1304 between HENB1306 and MME1308 in fig. 13).

Referring now to fig. 16-18B, example components and processes that may be employed in a communication system, such as a UMB network, to provide local breakout will be described. The local breakout allows the access terminal to access a local service that is visible under one of the devices on the path from the access terminal to its first-hop router. Two main forms of local outlets are shown in fig. 16: a local egress at an access gateway and a local egress at a femto node. It should be appreciated that the local services provided by a given node may take various forms and may differ from the particular services described in fig. 16 and discussed below.

In the system 1600 of fig. 16, an access terminal 1602 communicates over an air interface with a femto node 1604 (e.g., enhanced base station, eBS). System 1600 includes a router 1606 and an access gateway 1608 that provide local egress for one or more local services.

Once the access terminal 1602 is connected to the femto node 1604, a local breakout may be provided at the femto node. As represented by dashed line 1610, router 1606 may enable access terminal 1602 to access local services provided by one or more local network nodes 1612. For example, such local services may provide access to devices (e.g., printers) on the local network. The router 1606 may also enable the access terminal 1602 to access the internet 1616 (e.g., to access one or more web servers 1618), as represented by the dashed line 1614. In this manner, the access terminal 1602 can access the internet without going through the operator's core network.

Access gateway 1608 may enable access terminal 1602 to access one or more local services 1622, as represented by dashed line 1620. A local egress at the access gateway may be applicable when the first hop router for the access terminal 1602 is a local mobility agent 1624. Here, it may be desirable to provide certain local services (e.g., positioning) from the local access gateway, even when globally routed packets are communicated via the local mobility agent 1624.

Core network traffic may be routed from the access terminal 1602 to the local mobility agent 1624 (e.g., first hop router) via a protocol tunnel, as represented by dashed line 1626. From there, the traffic may be routed through the core network to communications node 1628. The complementary traffic flow will appear on the downlink.

To support local breakout, multiple link IDs may be provided between a given access terminal and the eBS. Here, each link ID may belong to a level corresponding to an entity that manages IP addresses at that level. For example, the level 2 link ID may correspond to a local mobility agent. The level 1 link ID may correspond to an access gateway. The level 0 link ID may correspond to a local router.

The application interface Specification ("AIS") supports providing location of multiple link IDs by an eBS to an access terminal. Each link ID corresponds to a different IP interface and assigns the access terminal a different IP address managed by the entity controlling the interface.

A link level to which packets transmitted over the air between an access terminal and an eBS belong is identified. As described above, both implementations may include identifying the flow for the packet, or sending an identifier with the packet.

In the first case, each packet belongs to a flow, and there may be a many-to-one mapping between flows and links. Thus, a link may have multiple flows, but a flow belongs to only a single link level. Thus, the link level may be implicitly determined from the flow ID.

In the second case, the packet may carry a special one-byte header placed between the IP header and the RLP header. The header may exclusively include the link level.

If AIS support for multiple links is provided as described above, several architectural options are available to provide local breakout. One architecture option includes using multiple GRE keys. Another architecture option includes using one GRE tunnel and multiple broadcast addresses.

FIGS. 17A and 17B illustrate an implementation employing two GRE keys. Here, the access gateway ("AGW") 1608 may provide one GRE key (e.g., GRE0) to the eBS1604 and bind the same key to any PMIP tunnel with the local mobility agent ("LMA") 1624. The key GRE0 may imply the following: if GRE0 is even, it is mapped to a level 1 address, and GRE0+1 is mapped to a level 2 address for the same user; if GRE0 is odd, it is mapped to a level 2 address and GRE0-1 is mapped to a level 1 address for the same user. The eBS1604 and the access gateway 1608 are configured to accept packets based on any of these GRE keys. There may be various provisions for providing two keys at the eBS 1604. For example, both keys may be sent to the eBS1604, or one key may be generated based on the other key sent to the eBS 1604.

Fig. 17A illustrates an example uplink traffic flow. Here, line 1702 represents the traffic flow tunneled between the eBS1604 and the access gateway 1608 using the first GRE key (GRE 0). For example, the traffic flow may involve a level 2 packet between an access terminal ("AT") 1602 and a local mobility agent 1624. In this way, the uplink packet can be sent to a correspondent node elsewhere on the internet. A line 1704 represents traffic flow tunneled between the eBS1604 and the access gateway 1608 using the second GRE key (GRE 1). As such, the traffic flow may involve level 1 packets between access terminal 1602 and access gateway 1608 (e.g., carrying local egress traffic supported by access gateway 1608). Line 1706 represents traffic flows that are not tunneled. For example, the traffic flow may involve a local egress packet between the access terminal 1602 and a local device on the same subnet as the eBS 1604. Fig. 17B illustrates a complementary traffic flow for the downlink.

At the eBS1604, the level 1 and level 2 packets can be identified by the link level to which the packets belong (on the reverse link) or by the GRE keys of their tunnels (on the forward link). The level 0 packets on the forward link are processed in different ways. For example, the eBS1604 may look at the destination address to determine the access terminal to which the packet is directed.

FIGS. 18A and 18B illustrate an implementation using one GRE key. Under this scenario, the level 0 packets (line 1806) are processed as described above, however, there is a single GRE tunnel 1808 between the access gateway 1608 and the eBS 1604. As such, packets arriving within the GRE tunnel 1808A are demultiplexed at the access gateway 1608 on the reverse link as represented in fig. 18A. Conversely, on the forward link as represented in FIG. 18B, packets arriving within the GRE tunnel 1808B are demultiplexed at the eBS 1604.

On the reverse link, the access gateway 1608 may demultiplex packets belonging to level 1 (line 1804) and level 2 (line 1802) by considering the source address of the packet and determining the link level based on the subnet. Similarly, on the forward link, the eBS1604 may look at the IP destination address of the packet to determine the link level to which the packet belongs based on the subnet.

However, this may cause a problem since broadcast packets belonging to the level 1 and the level 2 are transmitted to the same IP address. To address this issue, broadcast packets (e.g., RRP, RRQ, router solicitation and advertisement) of the level 1 egress protocol may be sent to different addresses. The DHCP packets may be demultiplexed using the client identifier option available in the protocol. Alternatively, the broadcast packet may be demultiplexed by looking inside the packet and using protocol specific information.

As described above, the local breakout scheme as taught herein may be used in a hybrid deployment that includes macro coverage (e.g., a large area cellular network such as a 3G network, typically referred to as a macro cellular network or a wide area network-WAN) and smaller coverage (e.g., a residential-based or building-based network environment, typically referred to as a local area network-LAN). Here, as an access terminal ("AT") moves through such a network, the access terminal may be served in some locations by access points that provide macro coverage and in other locations by access points that provide smaller area coverage. In some aspects, smaller area coverage may be used in order to provide incremental capacity growth, in-building coverage, and different services, all of which result in a more robust user experience.

Nodes that provide coverage over a relatively large area may be referred to as macro nodes, while nodes that provide coverage over a relatively small area (e.g., a residence) may be referred to as femto nodes. It should be appreciated that the techniques taught herein may be applied to nodes associated with other types of coverage areas. For example, a pico node (piconode) may provide coverage over an area that is smaller than a macro area and larger than a femto area (e.g., coverage within a commercial building). In various applications, other terminology may be used to refer to macro nodes, femto nodes, or other access point type nodes. For example, a macro node may be configured or referred to as an access node, base station, access point, eNodeB, macro cell, and so on. Meanwhile, a femto node may be configured as or referred to as a home nodeb, home eNodeB, access point base station, femto cell, and the like. In some implementations, a node may be associated with (e.g., divided into) one or more cells or sectors. A cell or sector associated with a macro, femto, or pico node may be referred to as a macro, femto, or pico cell, respectively. A simplified example of how a femto node may be deployed in a network is provided in fig. 19.

Fig. 19 illustrates an example of an overlay 1900 in which several tracking areas 1902 (or routing areas or location areas) are defined, each tracking area including several macro coverage areas 1904. Here, the coverage areas associated with the tracking areas 1902A, 1902B, and 1902C are depicted by thick lines, and the macro coverage area 1904 is represented by a hexagon. The tracking area 1902 also includes a femto coverage area 1906. In this example, each femto coverage area 1906 (e.g., femto coverage area 1906C) is depicted as being within a macro coverage area 1904 (e.g., macro coverage area 1904B). However, it should be appreciated that the femto coverage area 1906C may be partially within or outside the macro coverage area 1904. Meanwhile, one or more pico coverage areas (not shown) may be defined within one or more tracking areas 1902 or macro coverage areas 1904. It should be appreciated that there may be multiple femto coverage areas within a macro coverage area, either within or across the boundary with neighboring macro cells.

Fig. 20 illustrates aspects of a wireless communication system 2000 that includes a plurality of cells 2002, such as macrocells 2002A-2002G, each of which is served by a respective access point 2004 (e.g., access points 2004A-2004G). Thus, the macro cell 2002 may correspond to the macro coverage area 1904 of fig. 19. As shown in fig. 20, access terminals 2006 (e.g., access terminals 2006A-2006L) can be dispersed over time at various locations throughout the system. For example, each access terminal 2006 can communicate with one or more access points on a forward link ("FL") and/or a reverse link ("RL") at a given moment, depending on whether the access terminal 2006 is active and whether it is in soft handoff. The wireless communication system 2000 may provide service over a large geographic area. For example, the macro cells 2002A-2002G may cover several blocks of neighborhood or several square miles in a rural environment.

Fig. 21 is an example of a system 2100 that illustrates how one or more femto nodes can be deployed within a network environment (e.g., system 2000). System 2100 includes a plurality of femto nodes 2110 (e.g., femto nodes 2110A and 2110B) installed in a relatively small area coverage network environment (e.g., in one or more user residences 2130). Each femto node 2110 may be connected to a wide area network 2140 (e.g., the internet) and a mobile operator core network 2150 via a DSL router, cable modem, wireless link, or other connection means (not shown).

The owner of the femto node 2110 may subscribe to mobile services, such as 3G mobile services, provided through the mobile operator core network 2150. In addition, an access terminal 2120 may be capable of operating in macro environments as well as in smaller area coverage (e.g., residential) network environments. In other words, depending on the current location of the access terminal 2120, the access terminal 2120 may be served by a macro cell access point 2160 associated with the mobile operator core network 2150 or by any one of a set of femto nodes 2110 (e.g., femto nodes 2110A and 2110B residing within a respective user residence 2130). For example, when a user is outside his home, he may be served through a standard macro access point (e.g., access point 2160); and may be served by a femto node (e.g., node 2110A) when the user is near or at his home. Here, the femto node 2110 may be backward compatible with legacy access terminals 2120.

The node (e.g., femto node) may be restricted in some aspects. For example, a given femto node may only provide certain services to certain access terminals. In deployments with so-called restricted (or closed) affiliation, a given access terminal may be served only by the macro cellular mobile network and a defined set of femto nodes (e.g., femto node 2110 residing within a respective user residence 2130). In some implementations, a node may be restricted to not provide at least one of the following for at least one node: signaling, data access, registration, paging, or service.

In some aspects, a restricted femto node (which may also be referred to as a closed subscriber group home node B) is a node that provides service to a restricted access terminal provisioning set. The set may be expanded temporarily or permanently as desired. In some aspects, a closed subscriber group ("CSG") may be defined as a set of access points (e.g., femto nodes) that share a common access control list of access terminals. A channel on which all femto nodes (or all restricted femto nodes) within an area operate may be referred to as a femto channel.

As such, various relationships may exist between a given femto node and a given access terminal. For example, from the perspective of an access terminal, an open femto node may refer to a femto node that does not have restricted association (e.g., the femto node allows access to any access terminal). A restricted femto node may refer to a femto node that is restricted in some manner (e.g., restricted to association and/or registration). A home femto node may refer to a femto node to which an access terminal is authorized to access and operate on (e.g., provide permanent access for a defined set of one or more access terminals). A guest femto node may refer to a femto node on which an access terminal is temporarily authorized to access and operate. An unfamiliar femto node may refer to a femto node on which an access terminal is not authorized to access and operate except for possible emergency situations (e.g., 911 calls).

From a restricted femto node perspective, a home access terminal may refer to an access terminal that is authorized to access the restricted femto node (e.g., the access terminal has permanent access to the femto node). An incoming access terminal may refer to an access terminal that temporarily accesses a restricted femto node (e.g., restricted based on deadline, time of use, bytes, connection count, or some other criteria). An unfamiliar access terminal may refer to an access terminal that is not allowed to access a restricted femto node (e.g., an access terminal that does not have credentials or permission to register with the restricted femto node) except for emergency situations such as 911 calls.

For convenience, the disclosure herein describes various functionality in the context of a femto node. However, it should be appreciated that a pico node may provide the same or similar functionality for a larger coverage area. For example, a pico node may be restricted, a home pico node may be defined for a given access terminal, and so on.

A wireless multiple-access communication system may simultaneously support communication for multiple wireless access terminals. Each terminal may communicate with one or more access points via transmissions on the forward and reverse links. The forward link (or downlink) refers to the communication link from the access points to the terminals, and the reverse link (or uplink) refers to the communication link from the terminals to the access points. The communication link may be established via a single-input single-output system, a multiple-input multiple-output ("MIMO") system, or some other type of system.

MIMO systems employing multiple (N)_T) Transmitting antenna and a plurality of (N)_R) The receiving antenna is used for data transmission. May be composed of N_TA transmitting antenna and N_TMIMO channel composed of multiple receiving antennas is decomposed into N_SIndividual channels, which may also be referred to as spatial channels, where Ns ≦ min { N ≦_T,N_R}。N_SEach of the individual channels corresponds to a dimension. MIMO systems may provide improved performance (e.g., higher throughput and/or higher reliability) if the additional dimensionalities created by the multiple transmit and receive antennas are utilized.

MIMO systems may support time division multiplexing ("TDD") and frequency division multiplexing ("FDD"). In a TDD system, the forward and reverse link transmissions are on the same frequency region, so the reciprocity principle allows the estimation of the forward link channel from the reverse link channel. This enables the access point to extract transmit beamforming gain on the forward link when multiple antennas are available at the access point.

The techniques taught herein may be incorporated into a node (e.g., a device) that employs various components to communicate with at least one other node. FIG. 22 depicts several example components that may be used to facilitate communications between nodes. In particular, fig. 22 illustrates a wireless device 2210 (e.g., an access point) and a wireless device 2250 (e.g., an access terminal) of a MIMO system 2200. At the device 2210, traffic data for a number of data streams is provided from a data source 2212 to a transmit ("TX") data processor 2214.

In some aspects, each data stream is transmitted over a respective transmit antenna. TX data processor 2214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, MPSK, or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream can be determined by instructions performed by processor 2330. A data store 2232 may store program code, data, and other information used by the processor 2230 or other components of the device 2210.

The modulation symbols for all data streams are then provided to a TXMIMO processor 2220, which may further process the modulation symbols (e.g., forIn OFDM). The TXMIMO processor 2220 then passes N to_TOne modulation symbol stream is provided to N_TA transceiver ("XCVR") 2222A through 2222T. In some aspects, the TXMIMO processor 2220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Each transceiver 2222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. Subsequently, N from transceivers 2222A through 2222T_TThe modulated signals are respectively from N_TThe antennas 2224A through 2224T transmit.

At device 2250, the transmitted modulated signal is divided by N_RThe multiple antennas 2252A through 2252R receive and the received signal from each antenna 2252 is provided to a respective transceiver ("XCVR") 2254A through 2254R. Each transceiver 2254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.

Subsequently, a receive ("RX") data processor 2260 receives data from N_RN of transceiver 2254_RA stream of received symbols is processed based on a particular receiver processing technique to provide N_TA "detected" symbol stream. RX data processor 2260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor 2260 is complementary to that performed by TX mimo processor 2220 and TX data processor 2214 at device 2210.

A processor 2270 periodically determines which precoding matrix to use (discussed below). Processor 2270 formulates a reverse link message comprising a matrix index portion and a rank value portion. A data memory 2272 may store program code, data, and other information used by the processor 2270 or other components of the device 2250.

The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message is then processed by a TX data processor 2238, which also receives traffic data for some data streams from a data source 2236, modulated by a modulator 2280, conditioned by transceivers 2254A-2254R, and transmitted back to device 2210.

At device 2210, the modulated signals from device 2250 are received by antennas 2224, conditioned by transceivers 2222, demodulated by a demodulator ("DEMOD") 2240, and processed by a RX data processor 2242 to extract the reverse link message transmitted by device 2250. Processor 2230 then determines which pre-coding matrix to use for determining the beamforming weights then processes the extracted message.

FIG. 22 also illustrates that these communication components may include one or more components that perform local breakout related operations as taught herein. For example, the exit control component 2290 may cooperate with the processor 2230 and/or other components of the device 2210 to send/receive signals to/from another device (e.g., the device 2250) as taught herein. Similarly, the exit control component 2290 may cooperate with the processor 2270 and/or other components of the device 2250 to send/receive signals to/from another device (e.g., the device 2210). It is to be appreciated that the functionality of two or more of the described components can be provided by a single component for each of the devices 2210 and 2250. For example, a single treatment component may provide the functionality of the egress control component 2290 and the processor 2230, and a single treatment component may provide the functionality of the egress control component 2292 and the processor 2270.

The techniques taught herein may be incorporated into various types of communication systems and/or system components. In some aspects, it may be possible to share available system resources (e.g., by specifying one or more of)Bandwidth, transmit power, coding, interleaving, etc.) to support communication with multiple users. For example, the techniques taught herein may be applied to any one or combination of the following: code division multiple access ("CDMA") systems, multi-carrier CDMA ("MCCDMA"), wideband CDMA ("W-CDMA"), high speed packet access ("HSPA", "HSPA +") systems, time division multiple access ("TDMA") systems, frequency division multiple access ("FDMA") systems, single carrier FDMA ("SC-FDMA") systems, orthogonal frequency division multiple access ("OFDMA") systems, or other multiple access techniques. A wireless communication system employing techniques taught herein may be designed to implement one or more standards, such as IS-95, CDMA2000, IS-856, W-CDMA, TDSCDMA, and others. A CDMA network may implement a radio technology such as universal terrestrial radio access ("UTRA"), CDMA2000, or some other technology. UTRA includes W-CDMA and low chip rate ("LCR"). cdma2000 technology covers IS-2000, IS-95 and IS-856 standards. TDMA networks may implement wireless technologies such as global system for mobile communications ("GSM"). OFDMA networks may implement methods such as evolved UTRA ("E-UTRA"), IEEE802.11, IEEE802.16, IEEE802.20, and,Etc. wireless technologies. UTRA, E-UTRA and GSM are part of the Universal Mobile Telecommunications System ("UMTS"). The techniques taught herein may be implemented in 3GPP long term evolution ("LTE") systems, ultra mobile broadband ("UMB") systems, and other types of systems. LTE is a UMTS release using E-UTRA. While certain aspects of the disclosure may be described using 3GPP terminology, it will be understood that the techniques taught herein may be applied to 3GPP (Rel99, Rel5, Rel6, Rel7) techniques, as well as 3GPP2(1xRTT, 1xEV-DORelO, RevA, RevB) techniques, and other techniques.

The techniques taught herein may be incorporated into (e.g., implemented in or performed by) various apparatuses (e.g., nodes). In some aspects, a node (e.g., a wireless node) implemented in accordance with the techniques taught herein may include an access point or an access terminal.

For example, an access terminal may comprise, be implemented as, or referred to as user equipment, a subscriber station, a subscriber unit, a mobile station, a handset, a mobile node, a remote station, a remote terminal, a user agent, a user device, or some other terminology. In some implementations, an access terminal may comprise a cellular telephone, a cordless telephone, a session initiation protocol ("SIP") phone, a wireless local loop ("WLL") station, a personal digital assistant ("PDA"), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a portable communication device, a portable computing device (e.g., a personal digital assistant), an entertainment device (e.g., a music device, a video device, or a satellite radio), a global positioning system device, or any other suitable device for communicating via a wireless modem.

An access point may include, be implemented as, or be referred to as a node B, eNodeB, a radio network controller ("RNC"), a base station ("BS"), an eBS, a radio base station ("RBS"), a base station controller ("BSC"), a base transceiver station ("BTS"), a transceiver function ("TF"), a radio transceiver, a radio router, a basic service set ("BSs"), an extended service set ("ESS"), or some other similar terminology.

In some aspects, a node (e.g., an access point) may comprise an access node for a communication system. For example, such an access node may provide connectivity for or to a network (e.g., a wide area network such as the internet or a cellular network) via a wired or wireless communication link to the network. Thus, an access point may enable another node (e.g., an access terminal) to access a network or some other functionality. Additionally, it should be appreciated that one or both of the two nodes may be portable or, in some cases, relatively non-portable.

Further, it should be appreciated that a wireless node may be capable of sending and/or receiving information in a non-wireless manner (e.g., via a wired connection). As such, the receivers and transmitters discussed herein may include appropriate communication interface components (e.g., electrical or optical interface components) to communicate via a non-wireless medium.

The wireless nodes may communicate via one or more wireless communication links based on or supporting any suitable wireless communication technology. For example, in some aspects a wireless node may be associated with a network. In some aspects, the network may comprise a local area network or a wide area network. The wireless device may support or use, for example, one or more of the various wireless communication technologies, protocols, or standards discussed herein (e.g., CDMA, TDMA, OFDM, OFDMA, WiMAX, Wi-Fi, etc.). Similarly, the wireless node may point-support or use one or more of various corresponding modulation or multiplexing schemes. Accordingly, the wireless node may include appropriate components (e.g., air interfaces) to establish and communicate via one or more wireless communication links using the above-described or other wireless communication techniques. For example, a wireless node may include a wireless transceiver with associated transmitter and receiver components, which may include various components (e.g., signal generators and signal processors) that facilitate communications over a wireless modem.

In some aspects, the functionality described herein (e.g., with respect to one or more figures) may correspond to the functionality of a "module for … …" similarly specified in the appended claims. Referring to fig. 23-25, devices 2300, 2400, and 2500 are shown as a series of interrelated functional blocks. Here, for example, in at least some aspects, the point of presence providing module 2302 may correspond to a point of presence controller as discussed herein. For example, in at least some aspects, the traffic transmission module 2304 may correspond to a communications controller as discussed herein. For example, in at least some aspects, the messaging module 2306 may correspond to a communications controller as discussed herein. For example, in at least some aspects, the packet receiving module 2402 may correspond to a receiver as discussed herein. For example, in at least some aspects, service level determination module 2404 may correspond to a service level determiner as discussed herein. For example, in at least some aspects, the packet sending module 2406 may correspond to a communication controller as discussed herein. For example, in at least some aspects, the communication module 2502 may correspond to a control signal processor as discussed herein. For example, in at least some aspects, service access module 2504 may correspond to a communications controller as discussed herein.

The functionality of the modules of fig. 23-25 may be implemented in a variety of ways consistent with the techniques taught herein. In some aspects, the functionality of these modules may be implemented as one or more electronic components. In some aspects, the functions of these blocks may be implemented as a processing system including one or more processor components. In some aspects, for example, the functionality of these modules may be implemented using at least a portion of one or more integrated circuits (e.g., ASICs). As discussed herein, an integrated circuit may include a processor, software, other related components, or some combination thereof. The functionality of these modules may also be implemented in some other manner as taught herein. In some aspects, one or more of any of the dashed blocks in fig. 23-25 are optional.

It will be understood that any reference herein to elements using a designation such as "first", "second", etc., does not generally limit the number or order of such elements. Rather, these designations may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, reference to first and second elements does not mean that only two elements are employed there, or that the first element must somehow precede the second element. In addition, a set of elements can include one or more elements unless stated otherwise. In addition, as used in the specification or claims, a term in the form of "at least one of A, B or C" means "A or B or C or any combination of these elements".

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that any of the various illustrative logical blocks, modules, processors, units, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source code or some other technique), various forms of program or design code containing instructions (which may be referred to herein, for convenience, as "software" or a "software module"), or combinations of both. To clearly illustrate this interchangeability of hardware and software, 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. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), an access terminal, or an access point. The IC may include a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electronic components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions that reside within the IC, external to the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

It should be understood that any particular order or hierarchy of steps in any disclosed process is an example of an exemplary method. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Magnetic disk (disk) and optical disk (disc) as used herein include: compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks (disks) usually reproduce data magnetically, while discs (discs) reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. It should be appreciated that the computer-readable medium may be implemented in any suitable computer program product.

In view of the foregoing, in some aspects a first method of communication comprises: providing a first internet protocol point of presence to enable an access terminal to access a local service; providing a second internet protocol point of presence to enable the access terminal to access the network service; and transmitting traffic associated with the local service and traffic associated with the network service over a common air interface. In addition, in some aspects, at least one of the following may also be applied to the second communication method: the first internet protocol presence point is associated with a first access point name or a first internet protocol address, and the second internet protocol presence point is associated with a second access point name or a second internet protocol address; the local services include services provided via an access point communicating with the access terminal over a common air interface, and the network services include services provided via a first hop router for the access terminal; the access point is associated with an internet protocol subnet and the local service comprises a service provided by an entity associated with the internet protocol subnet; the local services include services provided via a gateway through which traffic from the access terminal flows to a first hop router for the access terminal, and the network services include services provided via the first hop router; the local service includes internet access provided via an access point communicating with the access terminal over a common air interface and does not provide internet access via a first hop router for the access terminal; the method further includes sending messages related to the first protocol via the second protocol to manage the sending of traffic related to the local service; the first protocol is related to communication between the mobility manager and the serving gateway, and the second protocol is related to communication between the mobility manager and the access point.

In some aspects, a second method of communication comprises: identifying an internet protocol point of presence for an over-the-air packet to indicate a termination point of a packet tunnel for the packet; and transmitting a packet based on the identified internet point of presence. In addition, in some aspects, at least one of the following may also be applied to the second communication method: identifying an internet protocol point of presence comprises determining, at an access point, an identifier to send with a packet, and sending the packet comprises forwarding the packet via a tunnel to a node identified based on the identifier; the identifier is sent via a header that resides between an internet protocol header and a radio link protocol header of the packet; wherein identifying the internet protocol point of presence comprises: defining an identifier of an internet protocol point of presence at an access terminal and transmitting the identifier with a packet; the identifier is sent via a header that resides between an internet protocol header and a radio link protocol header of the packet; identifying an internet protocol point of presence includes identifying, at an access point, a flow over which to send a packet, and sending the packet includes forwarding the packet via a tunnel to a node identified based on the flow; the flow is associated with a data radio bearer designated for local traffic; identifying an internet protocol point of presence includes: determining, at an access terminal, a flow related to an internet protocol point of presence and transmitting a packet via the determined flow; the flow is associated with a data radio bearer designated for local traffic; the identified internet protocol point of presence indicates whether the over-the-air packet is associated with a local service or a network service; the identified internet protocol point of presence indicates whether the over-the-air packet is associated with a local network or a visited network; the identified internet protocol point of presence indicates the relative depth within the network of the node associated with the termination point.

In some aspects, a third method of communication includes: communicating with a first mobility manager at a local node via first control signaling; communicating with a second mobility manager at another node via second control signaling; and accessing the first service based on the communication with the first mobility manager and accessing the second service based on the communication with the second mobility manager. In addition, in some aspects, at least one of the following may also be applied to the first communication method: the first control signaling is associated with a first non-access stratum instance supported by the access terminal and the second control signaling is associated with a second non-access stratum instance supported by the access terminal; the first control signaling is related to bearer management for the first service and the second control signaling is related to bearer management for the second service; the first control signaling is related to paging management for the first service and the second control signaling is related to paging management for the second service; the first and second control signaling enable different types of paging for different types of traffic; the local node comprises an access point for communicating over the air with an access terminal accessing the first service and the second service; the first service comprises a local service provided via the access point and the second service comprises a network service provided via a first hop router for the access terminal; the first service includes a local service provided via a gateway through which traffic from the access terminal flows to a first hop router for the access terminal, and the second service includes a network service provided via the first hop router.

In some aspects, functionality corresponding to one or more of the above-described aspects relating to the first, second and third communication methods may be implemented, for example, in an apparatus using the structures taught herein. Further, the computer program product may comprise means for causing a computer to provide functions corresponding to one or more of the above-described aspects relating to the first, second and third communication methods.

The previous description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the aspects shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (24)

1. A method of communication, comprising:

receiving a packet;

determining a service level associated with the packet, wherein determining the service level comprises: determining whether the packet is related to a local service or a network service, wherein a first internet protocol address is related to the local service and a second internet protocol address is associated with the network service; and

determining whether to send the packet via a protocol tunnel based on the determined service level.

2. The method of claim 1, wherein the service level indicates whether packets are to be tunneled.

3. The method of claim 1, wherein the service level indicates whether packets are to be tunneled via a protocol tunnel that terminates within at least one of the group consisting of a visited network and an edge gateway.

4. The method of claim 1, wherein the service level indicates whether packets are to be tunneled via a protocol tunnel that terminates within at least one of the group consisting of a local network and a core network gateway.

5. The method of claim 1, wherein the service level is further associated with an access point name.

6. The method of claim 1, wherein:

the packet is received at an access point that communicates over an air interface with an access terminal that transmitted the packet;

the local service comprises a service provided via the access point; and is

The network service includes a service provided via the protocol tunnel to a first hop router for the access terminal.

7. The method of claim 6, wherein:

the access point is associated with an internet protocol subnet; and is

The local service comprises a service provided by an entity associated with the internet protocol subnet.

8. The method of claim 1, wherein determining the service level comprises: an identifier transmitted with the packet is determined.

9. The method of claim 1, wherein determining the service level comprises: a flow over which the packet is transmitted is determined.

10. The method of claim 9, wherein the flow relates to a data radio bearer.

11. A communication device, comprising:

a receiver for receiving a packet;

a service level determiner to determine a service level associated with the packet, wherein determining the service level comprises: determining whether the packet is related to a local service or a network service, wherein a first internet protocol address is related to the local service and a second internet protocol address is associated with the network service; and

a communication controller to determine whether to transmit the packet via a protocol tunnel based on the determined service level.

12. The apparatus of claim 11, wherein the service level indicates whether packets are to be tunneled.

13. The apparatus of claim 11, wherein the service level indicates whether packets are to be tunneled via a protocol tunnel terminated within at least one of the group consisting of a visited network and an edge gateway.

14. The apparatus of claim 11, wherein the service level indicates whether packets are to be tunneled via a protocol tunnel terminated within at least one of the group consisting of a local network and a core network gateway.

15. The apparatus of claim 11, wherein the service level is further associated with an access point name.

16. The apparatus of claim 11, wherein determining the service level comprises: an identifier transmitted with the packet is determined.

17. The apparatus of claim 11, wherein determining the service level comprises: a flow over which the packet is transmitted is determined.

18. An apparatus for communication, comprising:

means for receiving a packet;

means for determining a service level associated with the packet, wherein determining the service level comprises: determining whether the packet is related to a local service or a network service, wherein a first internet protocol address is related to the local service and a second internet protocol address is associated with the network service; and

means for determining whether to send the packet via a protocol tunnel based on the determined service level.

19. The apparatus of claim 18, wherein the service level indicates whether packets are to be tunneled.

20. The apparatus of claim 18, wherein the service level indicates whether packets are to be tunneled via a protocol tunnel terminated within at least one of the group consisting of a visited network and an edge gateway.

21. The apparatus of claim 18, wherein the service level indicates whether packets are to be tunneled via a protocol tunnel terminated within at least one of the group consisting of a local network and a core network gateway.

22. The apparatus of claim 18, wherein the service level is further associated with an access point name.

23. The apparatus of claim 18, wherein determining the service level comprises: an identifier transmitted with the packet is determined.

24. The apparatus of claim 18, wherein determining the service level comprises: a flow over which the packet is transmitted is determined.