Method and apparatus for managing data services in a multi-processor computing environment

CROSS-REFERENCE

p-0002This application claims the benefit of U.S. Provisional Application Ser. No. 61/074,825, filed Jun. 23, 2008, and entitled “PROVIDING DATA SERVICES FOR AN EMBEDDED APPLICATIONS AND INTERNET CONNECTION SHARING (ICS) IN A MULTI-PROCESSOR HIGHER LEVEL OS ENVIRONMENT,” the entirety of which is incorporated herein by reference.

BACKGROUND

p-0003I. Field

p-0004The present disclosure relates generally to mobile computing, and more specifically to techniques for managing a shared network connection between one or more computing devices.

p-0005II. Background

p-0006Conventionally, dual-processor and/or other multi-processor environments for a mobile computing device (e.g., a personal digital assistant (PDA), smartphone, handheld computer, etc.) can include a modem processor responsible for air interface protocol operations and an application processor that runs the operating system of the device. Further, respective processors in such an environment can connect to peripherals and/or an external memory, which can be partitioned into three regions that correspond to the modem processor, the application processor, and inter-processor communication, respectively.

p-0007In order to accomplish various computing tasks, respective processors in a multi-processor mobile computing environment and/or memory regions with which the processors are associated can be configured to interact with each other. Thus, for example, an application running on a mobile computing device using an application processor can utilize wireless data connectivity provided by a modem processor. As another example, a mobile computing device can utilize data service sharing with another computing device that is connected or tethered to the mobile device via one or more interfaces. In such an example, the mobile computing device and the tethered device can utilize a common internet protocol (IP) address on the wireless data connection of the mobile device. Accordingly, the mobile device can be required to monitor uplink and downlink packet flows and perform network address translation (NAT) to direct appropriate data to the tethered device. Traditionally, such operations are performed at the mobile device by an application processor, such that all data packets have to be transferred to and from a modem memory region to an application memory region.

p-0008In light of the above examples, it can be appreciated that in both the embedded application case and the data service sharing case, a significant number of data copies are required between the modem and application processors of a mobile device for data processing and/or transfer. These data copies can generate excessive transactions on the system bus and external memory of a mobile device, increasing power consumption and CPU resource usage as well as increasing end-to-end delay. Accordingly, it would be desirable to implement multi-processor management techniques for a mobile computing device that mitigate at least the above shortcomings.

SUMMARY

p-0009The following presents a simplified summary of various aspects of the claimed subject matter in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements nor delineate the scope of such aspects. Its sole purpose is to present some concepts of the disclosed aspects in a simplified form as a prelude to the more detailed description that is presented later.

p-0010According to an aspect, a method is described herein. The method can comprise receiving one or more Network Address Translation (NAT) rules from an application processor; obtaining a packet on a coupled interface; attempting identification of a NAT rule received from the application processor that corresponds to the obtained packet; upon a successful identification attempt, translating the obtained packet according to an identified NAT rule and forwarding the translated packet to one or more translated packet destinations; and upon an unsuccessful identification attempt, forwarding the obtained packet to one or more packet processing destinations.

p-0011A second aspect relates to a mobile computing apparatus, which can comprise a memory that stores data relating to one or more NAT rules provided by an application processor. The mobile computing apparatus can further comprise at least one processor coupled to the memory that is disparate from the application processor, the at least one processor configured to receive a packet on a coupled interface, to attempt identification of a NAT rule corresponding to the received packet, to translate the received packet according to an identified NAT rule and forward the translated packet to at least one translated packet destination upon successful identification of a NAT rule, and to forward the received packet to at least one packet processing destination upon unsuccessful identification of a NAT rule.

p-0012According to a third aspect, an apparatus is described herein. The apparatus can comprise means for receiving respective NAT mapping rules from an associated application processor; means for identifying a packet obtained via an interface; means for attempting matching of the identified packet to a received NAT mapping rule; means for translating the identified packet according to a matching NAT mapping rule upon successful attempted matching; means for directing the translated packet to one or more translated packet destinations upon application of the matching NAT mapping rule; and means for directing the identified packet to one or more packet processing destinations upon unsuccessful attempted matching.

p-0013A fourth aspect described herein relates to an integrated circuit that executes machine-executable instructions. The instructions can comprise receiving respective NAT mapping rules from an associated application processor; identifying a packet obtained via an interface; attempting matching of the identified packet to respective NAT mapping rules; translating the identified packet according to a matching NAT mapping rule upon successful attempted matching; directing the translated packet to one or more translated packet destinations upon application of a matching NAT mapping rule; and directing the identified packet to one or more packet processing destinations upon unsuccessful attempted matching.

p-0014To the accomplishment of the foregoing and related ends, one or more aspects of the claimed subject matter comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative aspects of the claimed subject matter. These aspects are indicative, however, of but a few of the various ways in which the principles of the claimed subject matter can be employed. Further, the disclosed aspects are intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0015<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a system that facilitates efficient memory management in a multi-processor mobile computing environment in accordance with various aspects.

p-0016<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of an example system for sharing a network interface by way of a Network Address Translation (NAT) function including service to respective local processor(s) and/or tethered processor(s) in accordance with various aspects.

p-0017<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an example mobile computing architecture that can be utilized to implement network interface sharing.

p-0018<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates an example of a mobile computing architecture that can be utilized to facilitate advanced data service management associated with a network interface sharing session in accordance with various aspects.

p-0019<figref idrefs="DRAWINGS">FIGS. 5-6</figref> illustrate information flows associated with a network interface sharing session conducted by respective example multi-processor mobile computing implementations in accordance with various aspects.

p-0020<figref idrefs="DRAWINGS">FIGS. 7-9</figref> are flow diagrams of respective methodologies for managing data flows associated with a mobile computing device.

p-0021<figref idrefs="DRAWINGS">FIG. 10</figref> is a block diagram of an apparatus that facilitates data service management for a network interface sharing application.

p-0022<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates an example wireless communication system in which various aspects described herein can function.

p-0023<figref idrefs="DRAWINGS">FIG. 12</figref> is a block diagram of an example computing system that can be utilized to implement one or more aspects described herein.

DETAILED DESCRIPTION

p-0024Various aspects of the claimed subject matter are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects. It may be evident, however, that such aspect(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects.

p-0025As used in this application, the terms “component,” “module,” “system,” and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, an integrated circuit, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components can communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).

p-0026Furthermore, various aspects are described herein in connection with a wireless terminal and/or a base station. A wireless terminal can refer to a device providing voice and/or data connectivity to a user. A wireless terminal can be connected to a computing device such as a laptop computer or desktop computer, or it can be a self contained device such as a personal digital assistant (PDA). A wireless terminal can also be called a system, a subscriber unit, a subscriber station, mobile station, mobile, remote station, access point, remote terminal, access terminal, user terminal, user agent, user device, or user equipment (UE). A wireless terminal can be a subscriber station, wireless device, cellular telephone, PCS telephone, 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 other processing device connected to a wireless modem. A base station (e.g., access point or Evolved Node B (eNB)) can refer to a device in an access network that communicates over the air-interface, through one or more sectors, with wireless terminals. The base station can act as a router between the wireless terminal and the rest of the access network, which can include an Internet Protocol (IP) network, by converting received air-interface frames to IP packets. The base station also coordinates management of attributes for the air interface.

p-0027Moreover, various functions described herein can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can 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 can 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. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc (BD), where disks usually reproduce data magnetically and discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

p-0028Various techniques described herein can be used for various wireless communication systems, such as Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier FDMA (SC-FDMA) systems, and other such systems. The terms “system” and “network” are often used herein interchangeably. A CDMA system can implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, etc. UTRA includes Wideband-CDMA (W-CDMA) and other variants of CDMA. Additionally, CDMA2000 covers the IS-2000, IS-95 and IS-856 standards. A TDMA system can implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system can implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM®, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is an upcoming release that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP). Further, CDMA2000 and UMB are described in documents from an organization named “3rd Generation Partnership Project 2” (3GPP2).

p-0029Various aspects will be presented in terms of systems that can include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems can include additional devices, components, modules, etc. and/or can not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches can also be used.

p-0030Referring now to the drawings, <figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a system <b>100</b> that facilitates efficient memory management in a multi-processor mobile computing environment in accordance with various aspects described herein. In accordance with one aspect, system <b>100</b> can include a mobile device <b>120</b>, which can utilize an operating system (OS) such as BREW (Binary Runtime Environment for Wireless), Linux, Windows Mobile, or the like, to provide various communication and/or computing services. In one example, mobile device <b>120</b> can be constructed as a multi-processor device. More particularly, mobile device <b>120</b> can include a modem processor <b>122</b> that manages air interface protocol operations (e.g. by controlling a modem <b>123</b> and/or one or more other suitable components) with respect to communication with a core network <b>110</b>. Core network <b>110</b> can be, for example, a computing network or internetwork (e.g., the Internet), a wireless or cellular communication network utilizing any suitable wireless communication technology or combination thereof (e.g., UTRA, E-UTRA, UMTS, LTE, GSM, CDMA2000, UMB, Wi-Fi, WiMAX, etc.), or the like. In addition, mobile device <b>120</b> can include an application processor <b>124</b> (also referred to herein as an “apps processor”) that manages the operating system of mobile device <b>120</b> and/or respective applications running thereon.

p-0031In another example, modem processor <b>122</b> and application processor <b>124</b> can be connected to a shared memory <b>128</b>. By way of specific example, memory <b>128</b> can be partitioned into three regions, which can respectively correspond to modem processor <b>122</b>, application processor <b>124</b>, and inter-processor communication between processors <b>122</b> and <b>124</b> and/or other processors utilized by mobile device <b>120</b>. Additionally and/or alternatively, modem processor <b>122</b> and/or application processor <b>124</b> can be connected to one or more peripherals (not shown) via SDIO (secure digital input/output), Universal Serial Bus (USB), Bluetooth (BT), UART (universal asynchronous receiver/transmitter), and/or any other peripheral interface(s).

p-0032In accordance with one aspect, modem processor <b>122</b> and application processor <b>124</b> can cooperate to provide various services. As a first example, mobile device <b>120</b> can execute one or more embedded applications that utilize the wireless data connectivity provided by modem <b>123</b> for network-based or internet-based services. In such an example, modem <b>123</b> can process the air interface protocol and write respective packets associated with a downlink data flow to the modem region of memory <b>128</b>. Next, the respective packets can be copied to the shared region of memory <b>128</b>, where they can subsequently be copied by application processor <b>124</b> to the application region of memory <b>128</b>. Thus, it can be appreciated that at least three data movements can be required to process and transfer data packets between modem processor <b>122</b> and application processor <b>124</b> in the above example. Alternatively, a first region of memory <b>128</b> can be configured as readable and writable by modem processor <b>122</b> and readable only by application processor <b>124</b> for the downlink data path and/or vice versa. However, it can be appreciated that such a configuration can also require data copies or movements within memory <b>128</b>. By way of example, the downlink data path in such a configuration can require a first data movement from modem <b>123</b> to the modem region of memory <b>128</b> and a second data movement from the modem region of memory <b>128</b> to the application region of memory <b>128</b>.

p-0033As a second example, mobile device <b>120</b> can run one or more embedded applications in cooperation with a tethered computer <b>130</b> that is associated with mobile device <b>120</b> via a tethering link <b>132</b>. Tethered computer <b>130</b> can be any suitable computing device, such as a personal computer (PC), a laptop or tablet computer, a PDA, a smartphone, or the like. Further, a tethering link <b>132</b> utilized to connect tethered computer <b>130</b> to mobile device <b>120</b> can be a USB, Firewire, Wi-Fi, Bluetooth, and/or any other suitable interface(s). In such an example, mobile device <b>120</b> and tethered computer <b>130</b> can have disparate internal or private Internet Protocol (IP) addresses such that mobile device <b>120</b> can distinguish IP data flows directed to mobile device <b>120</b> and/or tethered computer <b>130</b> and forward corresponding packets accordingly. Additionally or alternatively, mobile device <b>120</b> and tethered computer <b>130</b> can share a common public IP address and/or other network address on the wireless data connection. In such an example, mobile device <b>120</b> can be configured to monitor uplink packet flows and translate internal addresses and/or ports to the appropriate outgoing addresses and/or ports, or vice versa, based on one or more network address translation (NAT) operations. Such operations are described in further detail infra.

p-0034In one example, NAT operations are performed by mobile device <b>120</b> using application processor <b>124</b> such that substantially all data packets are required to be transferred from the modem region of memory <b>128</b> to the application region of memory <b>128</b>. Thus, in a similar manner to the embedded application scenario described above, it can be appreciated that at least three data copies can be required between modem processor <b>122</b> and application processor <b>124</b> for data processing and transfer associated with a tethering session. More specifically, packets destined to tethered computer <b>130</b> can be required to be transferred to application processor <b>124</b> on the downlink direction due to the fact that the transport and network protocol layers, as well as NAT operations, are executed by application processor <b>124</b>. Further, for the uplink direction, it can be appreciated that packets coming from tethered computer <b>130</b> can be transferred to application processor <b>124</b> at mobile device <b>120</b> for protocol layer processing before the packets are forwarded to modem processor <b>122</b>. Performing excessive data copies in this manner can generate unnecessary transactions on the system bus and the external memory associated with mobile device <b>120</b>, which can increase power consumption, cost extra processor resources, increase end-to-end delay, and/or negatively affect user experience in one or more other manners.

p-0035To mitigate the above inefficiencies associated with conventional shared memory systems and/or other shortcomings, a mobile device <b>120</b> in system <b>100</b> can, in accordance with various aspects, include one or more peripheral modules <b>126</b>. In one example, peripheral module(s) <b>126</b> can be implemented as hardware, software, and/or other component(s) that are independent of modem processor <b>122</b> and application processor <b>124</b>, thereby facilitating expedited use of an associated memory <b>128</b>.

p-0036In accordance with one aspect, peripheral module(s) <b>126</b> can be leveraged by mobile device <b>120</b> to substantially reduce processing overhead associated with data movements between modem processor <b>122</b> and application processor <b>124</b>. By way of example, in the case of an embedded application resident on mobile device <b>120</b>, peripheral module(s) <b>126</b> can facilitate interaction between modem processor <b>122</b> and application processor <b>124</b> requiring only one data copy by reading packets from a modem region of memory <b>128</b> and writing to the application region of memory <b>128</b> after completion of any associated air interface protocols and/or IP/Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) operations.

p-0037As another example, in the case of data service sharing between mobile device <b>120</b> and tethered computer <b>130</b>, peripheral module(s) <b>126</b> can move respective packets destined for tethered computer <b>130</b> to a tethering link <b>132</b> (e.g., USB, Firewire, Bluetooth, etc.) by which mobile device <b>120</b> and tethered computer <b>130</b> are coupled directly without passing through application processor <b>124</b>. Accordingly, it can be appreciated that utilizing peripheral module(s) <b>126</b> in the manner can result in power savings, increased CPU (Central Processing Unit) resource efficiency, reduced packet latency, and/or other benefits. For example, in an absence of embedded application data, application processor <b>124</b> can be configured to fully inactivate for power savings such that only modem processor <b>122</b> is required to be active to process data for tethered computer <b>130</b>.

p-0038In a further example, peripheral module(s) <b>126</b> can be implemented as one or more dedicated ASICs (application specific integrated circuits) and/or other hardware components, such that operations that are demanding on bus bandwidth, processor resources, or the like (e.g., ciphering, checksum computation, etc.) can be grouped together and implemented in the dedicated peripheral module(s) <b>126</b>. As a result, data can be read a single time from memory <b>128</b>, upon which respective operations can be offloaded to a dedicated peripheral module <b>126</b> instead of stressing processors <b>122</b> and/or <b>124</b>.

p-0039In accordance with one aspect, peripheral module(s) <b>126</b> can be configured by modem processor <b>122</b> and/or any other suitable component(s) to facilitate one or more operations for network layer (e.g., IP) and/or transport layer (e.g. TCP/UDP) processing, such as IP filtering and packet forwarding, NAT translation, IP/TCP/UDP checksum validation and computation, or the like. Specific examples of these and other operations that can be performed by peripheral module(s) <b>126</b> are described in further detail infra.

p-0040In accordance with an additional aspect, peripheral module(s) <b>126</b> can be configured to have read and write access to sections of memory <b>128</b> associated with both modem processor <b>122</b> and application processor <b>124</b>. In one example, security protection for memory <b>128</b> can be maintained via a memory protection unit (MPU), which can implement memory access control across modem processor <b>122</b>, application processor <b>124</b>, and/or peripheral module(s) <b>126</b>.

p-0041Turning next to <figref idrefs="DRAWINGS">FIG. 2</figref>, a system <b>200</b> is illustrated on which an example tethering and network sharing procedure is conducted between a PC <b>210</b> and a mobile terminal <b>220</b>. It should be appreciated, however, that while system <b>200</b> illustrates an example network sharing procedure for a PC and a mobile terminal, any suitable computing devices could utilize tethering and/or network sharing in a similar manner to that illustrated by system <b>200</b>.

p-0042As system <b>200</b> illustrates, a mobile terminal <b>220</b> having access to the Internet <b>240</b> and/or another suitable network or internetwork via a connection to a wireless communication system through a base station <b>230</b> and/or another suitable entity can utilize network sharing to share access to Internet <b>240</b> with one or more tethered devices <b>210</b> (e.g., connected to mobile terminal <b>220</b> using USB, Wi-Fi, Bluetooth Personal Area Network (PAN), and/or any other suitable interface) through a private or local network <b>215</b>. In one example, mobile terminal <b>220</b> can utilize a tethering module <b>222</b> to coordinate communication to and/or from Internet <b>240</b> by all devices associated with local network <b>215</b> via a modem <b>224</b> and/or another suitable communication device.

p-0043In accordance with one aspect, mobile terminal <b>220</b> can further include a NAT module <b>226</b>, which can enable multiple host devices to access a wide area network (WAN) such as Internet <b>240</b> using a single network connection defined by a single public IP address. For example, within local network <b>215</b>, respective associated devices <b>210</b>-<b>220</b> can be assigned private IP addresses (e.g., 192.168.0.1, 192.168.0.2, etc.) that identify the respective devices on local network <b>215</b>, while mobile terminal <b>220</b> can utilize a public IP address (e.g., 157.x.y.z, where x, y, and z are integers between 0 and 255, etc.) for communication between local network <b>215</b> and Internet <b>240</b>. Thus, as shown in system <b>200</b>, NAT module <b>226</b> at mobile terminal <b>220</b> can enable communication between devices on local network <b>215</b> and base station <b>230</b> and/or Internet <b>240</b> by translating packets from a local {private IP address, port} pair to a WAN {public IP address, port} pair and vice versa. In one example, port translation can be performed in addition to or in place of IP address translation in order to prevent port collisions between devices using local network <b>215</b>. Additionally or alternatively, NAT module <b>226</b> can perform one or more operations on respective packets during translation, such as, for example, performing TCP and/or IP checksum adjustment within headers of respective packets to reflect any applicable IP address and/or port translations performed on the packets. In another example, NAT module <b>226</b> can be activated when a tethered data service is provided to one or more devices <b>210</b> via tethering module <b>222</b>.

p-0044In accordance with another aspect, mobile terminal <b>220</b> can be made NAT aware such that global ports that are in use are not assigned as ephemeral port values for new sockets using the global IP address associated with mobile terminal <b>220</b>. Similarly, mobile terminal <b>220</b> can form NAT mappings such that new NAT mappings avoid public ports that are in use by existing sockets using the global IP address associated with mobile terminal <b>220</b>.

p-0045In one example, a mobile computing device can manage communication of data and/or control information associated with a network interface sharing arrangement with one or more other devices as shown by system <b>300</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>. While some elements of system <b>300</b> as illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref> may be associated with various mobile computing implementations, it should be appreciated that the respective elements illustrated within system <b>300</b> are provided by way of specific, non-limiting example and that, unless explicitly stated otherwise, the claims are not intended to be limited to any specific implementation or combination thereof.

p-0046In one example, system <b>300</b> can be implemented by a mobile computing device and/or any other suitable computing device and can include an application processor <b>310</b>, a PC interface <b>340</b>, and a modem <b>350</b>, each of which can respectively share a system memory <b>330</b>. In accordance with one aspect, PC interface <b>340</b> can be utilized to couple one or more computing devices to a device implementing system <b>300</b> in association with a network interface sharing operation and/or any other suitable operation(s). PC interface <b>340</b> can be implemented via USB, Bluetooth, Firewire, and/or any other suitable interface type(s). In one example, PC interface <b>340</b> can be controlled by a PC interface driver <b>322</b> associated with application processor <b>310</b>.

p-0047In accordance with another aspect, modem <b>350</b> can be utilized to manage communication to and/or from a public communication network associated with system <b>300</b>. In one example, modem <b>350</b> can be controlled by a modem driver <b>324</b> associated with application processor <b>310</b>. Additionally or alternatively, a modem processor, a protocol processing driver, and/or other suitable control mechanism(s) can be provided within and/or in association with modem <b>350</b> to facilitate control of modem <b>350</b>.

p-0048In a further example, system <b>300</b> can include mechanisms for a tethered data connection between a mobile device associated with system <b>300</b> and a PC and/or other suitable computing device. In such an example, application processor <b>310</b> can serve as an intermediate node between a modem processor associated with modem <b>350</b> and a tethered computing device, such that the tethered device is the source and/or sink of various data and some or all remaining data is sourced and/or sinked at application processor <b>310</b>. To these ends, application processor <b>310</b> can include a NAT module <b>312</b>, which can allow both application processor <b>310</b> and a tethered device to share a common wireless connection through an associated modem processor. In one example, NAT module <b>312</b> can be implemented in software at application processor <b>310</b>. Additionally or alternatively, application processor can further include a TCP/IP module <b>314</b> to facilitate packet transport, framing, and/or any other suitable operation(s) required for communication of data between system <b>300</b> and an associated public network.

p-0049As application processor <b>310</b> in system <b>300</b> serves as an intermediate node between a tethered computing device and a public network, it can be observed that system <b>300</b> is configured to route all packets transmitted to and/or from the public network. These packets can correspond to, for example, Input and/or Output Endpoints (EPs). However, as shown by system <b>300</b>, even in the case that respective packets destined to and/or from the public network are not consumed by a device implementing system <b>300</b>, such packets can still be required to be routed through application processor <b>310</b> and PC interface <b>340</b> for header updates and/or other processing prior to communication of the packets. As a result, it can be appreciated that processing by application processor <b>310</b> can be required for substantially all packets coming in or out of an associated public network, which can lead to excessive strain on application processor <b>310</b>, power usage, and the like.

p-0050Accordingly, to mitigate at least the above described shortcomings, NAT translation and/or other packet processing operations can be offloaded from application processor <b>310</b> to one or more disparate modules, as illustrated by system <b>400</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>. In accordance with one aspect illustrated by <figref idrefs="DRAWINGS">FIG. 4</figref>, system <b>400</b> can include a smart peripheral subsystem (SPS) module <b>460</b>, which can include one or more processors and/or other appropriate component(s) for performing respective operations offloaded from application processor <b>310</b>.

p-0051In one example, SPS <b>460</b> can be coupled with a PC interface <b>340</b> associated with a tethered computing device (e.g., via an interface controller <b>442</b>), which can serve as NAT-enabled tethered network connection interface for the tethered computing device. Additionally or alternatively, SPS <b>460</b> can be coupled with a protocol processor <b>452</b> associated with modem <b>350</b> (e.g., via protocol controller <b>456</b>), a shared system memory <b>330</b> accessible to SPS <b>460</b> and application processor <b>310</b>, and/or any other suitable interface(s). Based on these associations, SPS <b>460</b> can perform one or more operations for respective packets communicated within a private network associated with system <b>400</b>. For example, upon detecting a packet, SPS <b>460</b> can perform NAT translation for the packet, identify one or more intended destinations of the packet, and route the packet to the corresponding destination adapter(s) with substantially minimal required interaction from application processor <b>310</b>.

p-0052Thus, by way of example, when an uplink (UL) packet arrives on PC interface <b>340</b>, SPS <b>460</b> can analyze the packet and identify whether the packet is intended for a packet processing destination, such as the device associated with application processor <b>310</b> or the like, or a translated packet destination, such as a WAN associated with modem <b>350</b> or the like. Upon identifying that the packet is intended for one or more translated packet destinations, SPS <b>460</b> can perform NAT translation and forward the packet directly to modem <b>350</b> and/or any other suitable destination(s) without requiring intervention from application processor <b>310</b>. Similarly, SPS <b>460</b> can perform NAT translation and direct forwarding to PC interface <b>340</b> and/or any other suitable translated packet destination for downlink (DL) packets arriving on modem <b>350</b> that are identified as destined for a tethered computing device associated with PC interface <b>340</b> or the like. By performing NAT translation and forwarding in this manner, it can be appreciated that SPS <b>460</b> can provide significant savings in processing power at application processor <b>310</b>, bus bandwidth associated with inter-processor communication between application processor and SPS <b>460</b>, and/or other performance criteria.

p-0053In accordance with another aspect, SPS <b>460</b> can perform NAT translation operations on respective packets based on one or more NAT rules that are provided to SPS <b>460</b> by application processor <b>310</b>. In one example, a set of NAT rules can be configured by a SPS driver <b>414</b> as a table of mappings from private IP address/port pairs to public IP address/port pairs or other suitable mappings. In another example, SPS driver <b>414</b> can set NAT rules based at least on instructions received from a NAT offload (OL) driver <b>412</b>.

p-0054In accordance with a further aspect, SPS driver can be configured to identify new connections made between applications on a private network associated with system <b>400</b> and a public network with which modem <b>350</b> is associated. Upon identification of a new connection, NAT OL driver <b>412</b> can act in cooperation with or independently of an OS associated with application processor <b>310</b> to set up a NAT translation rule for the new connection, which can subsequently be provided to SPS driver <b>414</b> to be relayed to SPS <b>460</b>. Additionally or alternatively, SPS driver <b>414</b> can be configured to identify that one or more connections corresponding to respective NAT rules are no longer being utilized, based on which SPS driver <b>414</b> can instruct removal of the corresponding NAT rules at SPS <b>460</b>. In one example, upon removal of a NAT rule at SPS <b>460</b>, SPS driver <b>414</b> can additionally be configured to pass status information to NAT OL driver <b>412</b> to indicate that the NAT rule is no longer being handled by SPS <b>460</b>.

p-0055As further illustrated in system <b>400</b>, SPS <b>460</b> can include respective components for processing respective packets in the UL direction and/or the DL direction. In the DL direction, a packet intended for a device connected through PC interface <b>340</b> can be initially processed by protocol processor <b>452</b>, which can perform filtering for the packet using a filtering block <b>454</b> and/or any other suitable operation(s) as directed by protocol controller <b>456</b>. Subsequently, rather than passing the packet to application processor <b>310</b> as illustrated in system <b>300</b>, the packet can be provided to SPS <b>460</b>.

p-0056Upon receipt of the packet at SPS <b>460</b>, a decision block <b>462</b> can determine whether one or more NAT rules configured by SPS driver <b>414</b> match a connection specified by the packet (e.g. as specified by a public IP address and/or port). If a matching rule is identified, NAT translation can be performed for the packet at NAT block <b>464</b> using the identified rule. Additionally or alternatively, Open Systems Interconnection (OSI) Layer 2 (L2) or link layer framing can be performed for the packet at L2 Packet block <b>466</b> and/or another suitable module. Otherwise, if a matching NAT rule is not discovered, decision block <b>462</b> can instead pass the packet to application processor <b>310</b> for processing. Subsequent to processing, SPS driver <b>414</b> and/or one or more other components associated with application processor <b>310</b> can optionally create a new NAT rule corresponding to the packet and facilitate installation of the created rule at SPS <b>460</b>. Based on the action taken by decision block <b>462</b>, a multiplexer (MUX) <b>468</b> can be utilized to pass the processed packet from the location at which processing was performed to PC interface <b>340</b> for forwarding on to the appropriate device.

p-0057Similarly, in the UL direction, a packet intended for a public network associated with modem <b>350</b> that is received at PC interface <b>340</b> can be provided to SPS <b>460</b>. Upon arrival at SPS <b>460</b>, L2 de-framing or parsing can be performed for the packet by L2 Parse block <b>472</b> and/or another suitable module, following which the packet can be routed through SPS <b>460</b> using a decision block <b>474</b>, NAT block <b>476</b>, and multiplexer <b>478</b> in a similar manner to that described above regarding decision block <b>462</b>, NAT block <b>464</b>, and multiplexer <b>468</b>. The processed UL packet can subsequently be provided to protocol processor <b>452</b>, from which the packet can be communicated by modem <b>350</b> to an associated public network.

p-0058In accordance with one aspect, SPS <b>460</b> can utilize one or more L2 Packet blocks <b>466</b>, L2 Parse blocks <b>472</b>, and/or any other suitable module(s) for conducting L2 framing and/or de-framing for respective packets processed by SPS <b>460</b>. In one example, L2 Packet block <b>466</b>, L2 Parse block <b>472</b>, and/or other similar blocks can be utilized to facilitate interoperability between link layer protocols associated with a network with which modem <b>350</b> communicates (e.g., a network utilizing CDMA, UMTS, WLAN, Bluetooth, etc.) and a tethering link corresponding to PC interface <b>340</b> (e.g., USB, Firewire, Wi-Fi, etc.) and higher-level network and transport layer protocols (e.g., OSI Layer 3 (L3) and/or Layer 4 (L4) protocols) associated with NAT translation.

p-0059Thus, in one example, L2 Parse block <b>472</b> can be utilized to perform L2 de-framing for respective packets received from PC interface <b>340</b> in order to enable various processing operations (e.g., NAT translation, TCP/IP checksum validation and computation, etc.) on network layer and/or transport layer information contained in the packets. Similarly, L2 Packet block <b>466</b> can be utilized to perform L2 framing on packets processed by blocks <b>462</b>-<b>464</b> or the like in order to facilitate use of the respective packets according to one or more link layer protocols associated with PC interface <b>340</b>. By performing packet parsing and/or encapsulation in this manner, it can be appreciated that substantially all functions related to processing of respective packets that correspond to known NAT relationships within <b>400</b> can be offloaded to SPS <b>460</b>, thereby enabling system <b>400</b> to achieve high data rates without incurring expense at application processor <b>310</b>.

p-0060Additionally or alternatively, while not shown in system <b>400</b>, OSI Layer 2 or link layer framing and de-framing could both be performed for uplink and/or downlink packets within SPS <b>460</b> by, for example, utilizing a L2 Parse block prior to decision block <b>462</b> and/or a L2 Packet block prior to multiplexer <b>478</b>. It can be appreciated that this could be done to enable expedited packet processing via SPS <b>460</b> for a system that utilizes heterogeneous L2 protocols at PC interface <b>340</b> and modem <b>350</b>. Thus, for example, a packet arriving at SPS <b>460</b> on the uplink or downlink can be de-framed at the link layer according to a first link layer protocol, processed on a network and/or transport layer level, and subsequently re-framed at the link layer according to a second, disparate link layer protocol.

p-0061In accordance with another aspect, system <b>400</b> can elect to pass respective packets to application processor <b>310</b> for processing instead of, or in addition to, offloading processing to SPS <b>460</b> based on various criteria. For example, system <b>400</b> illustrates that fragmented packets received by modem <b>350</b> on the downlink can be provided to modem driver <b>324</b> at application processor <b>310</b> for reassembly. Following reassembly, NAT translation and/or other operations on respective reassembled packets can be performed by application processor <b>310</b>, or alternatively modem driver <b>324</b> can offload the reassembled packets to SPS <b>460</b> for further processing.

p-0062As further illustrated by system <b>400</b>, respective packets originating at PC interface <b>340</b> and/or application processor <b>310</b> can additionally or alternatively be routed between application processor <b>310</b> and PC interface <b>340</b> without intervention from SPS <b>460</b>. Packets routed through application processor <b>310</b> can include, for example, packets corresponding to endpoints that are not related to SPS <b>460</b> or the NAT offload interface, such as control endpoints, endpoints associated with an interface disparate from the NAT offload interface (e.g., a Diagnostic (Diag) interface, a National Marine Electronics Association (NMEA) interface, etc.), or the like; packets corresponding to endpoints used for a NAT offload interface in the event that an application running on application processor <b>310</b> is communicating with an application running on a device associated with PC interface <b>340</b> without involvement of modem <b>350</b>; and/or any other suitable packet(s). In one example, upon forwarding of packets from PC interface <b>340</b> to application processor <b>310</b>, the forwarded packets can be processed by PC interface driver <b>322</b>, after which a multiplexer <b>422</b> and/or other suitable means can be utilized to selectively provide the processed packets back to PC interface <b>340</b> and/or to SPS <b>460</b> for further processing.

p-0063With regard to the above examples, it should be appreciated that fragmented packets, packets directly communicated between PC interface <b>340</b> and PC interface driver <b>322</b> as shown in system <b>400</b>, and/or any other packets communicated within system <b>400</b> need not be provided directly to application processor <b>310</b>. Alternatively, it can be appreciated that such packets could be provided to SPS <b>460</b> to facilitate some or all processing described above with regard to application processor <b>310</b>.

p-0064With reference next to <figref idrefs="DRAWINGS">FIGS. 5-6</figref>, respective diagrams <b>500</b>-<b>600</b> are provided that illustrate example flows of information between a modem processor <b>502</b> and an apps processor <b>504</b> that can be associated with a mobile computing device in accordance with various aspects. Turning first to system <b>500</b> in <figref idrefs="DRAWINGS">FIG. 5</figref>, respective Protocol Data Units (PDUs) located at a first PDU buffer <b>512</b> associated with modem processor <b>502</b> can be passed to a header processing block <b>514</b>, which can generate control information corresponding to the PDUs and submit generated control information to a protocol processor <b>518</b> in combination with the corresponding PDUs from PDU buffer <b>512</b>. Upon receiving respective PDUs, protocol processor <b>518</b> can perform one or more processing operations on the PDUs, such as Cyclic Redundancy Check (CRC) validation, deciphering, or the like. Protocol processor can then provide the processed PDUs to a second PDU buffer <b>520</b>, which in turn can forward the PDUs to a shared buffer <b>532</b> that is common to modem processor <b>502</b> and apps processor <b>504</b>.

p-0065Upon arrival of respective PDUs at shared buffer <b>532</b>, apps processor <b>504</b> can read the PDUs to one or more network interface buffers <b>542</b>, which can in turn forward the PDUs to a network interface driver <b>544</b>. In one example, network interface driver <b>544</b> can submit packets destined for the device associated with system <b>500</b> to one or more embedded data applications <b>546</b> resident on apps processor <b>504</b>. Additionally or alternatively, network interface driver <b>544</b> can provide one or more packets destined for a tethered computer device to an interface controller <b>548</b> (e.g., a USB controller, a Bluetooth controller, etc.) coupled to the tethered computer device.

p-0066As illustrated by system <b>500</b>, in order to facilitate a movement of data between modem processor <b>502</b> and apps processor <b>504</b>, three data movements are required—from protocol processor <b>518</b> to PDU buffer <b>520</b>, from PDU buffer <b>520</b> to shared buffer <b>532</b>, and from shared buffer <b>532</b> to network interface buffer(s) <b>542</b>. In addition, for a transfer of data between modem processor <b>502</b> and a tethered computer device, it can be appreciated that a fourth data movement can be required between network interface buffer(s) <b>542</b> and interface controller <b>548</b> via network interface driver <b>544</b>.

p-0067In view of the above, in accordance with one aspect, system <b>600</b> as illustrated in <figref idrefs="DRAWINGS">FIG. 6</figref> can be implemented to increase memory access efficiency, reduce loading of apps processor <b>504</b>, and/or to provide other benefits. As system <b>600</b> illustrates, modem processor <b>502</b> can provide respective PDUs to a protocol accelerator <b>612</b>, which can attempt to match received PDUs to static downlink NAT mappings. In one example, PDUs that do not match static mappings known to protocol accelerator <b>612</b> can be passed to one or network interface buffers <b>542</b>, which in turn can forward the PDUs to apps processor <b>504</b> for further processing. Apps processor <b>504</b> can subsequently provide control information corresponding to the PDUs to a NAT module <b>616</b>, which can configure one or more new NAT mappings based on the control information and forward the configured NAT mappings to a SPS processor <b>614</b>. Additionally or alternatively, respective PDUs for which static address/port mappings are found can be passed to SPS processor <b>614</b>, which can forward the PDUs to a tethered computer <b>618</b> through a corresponding tethering link. In one example, SPS processor <b>614</b> can further perform de-framing based on one or more link layer protocols (e.g., IEEE 802.3, IEEE 802.11, etc.), modification and/or addition of port or checksum information, and/or any other suitable operations on respective PDUs. In another example, SPS processor <b>614</b> can forward information related to NAT mappings no longer utilized, PDUs that do not match any known static NAT mappings, or the like to NAT module <b>616</b> for forwarding to apps processor <b>504</b>.

p-0068Accordingly, it can be appreciated that, for PDUs for which a DL mapping is present at protocol accelerator <b>612</b> and/or SPS processor <b>614</b>, a transfer from a modem processor <b>502</b> to a tethered computer <b>618</b> can be performed with fewer required memory accesses than that required by system <b>500</b>. Further, it can be observed that substantially no operations are required by apps processor <b>504</b> in such a case, thereby increasing the overall efficiency of apps processor <b>504</b> and system <b>600</b>.

p-0069Referring now to <figref idrefs="DRAWINGS">FIGS. 7-9</figref>, methodologies that can be performed in accordance with various aspects set forth herein are illustrated. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts can, in accordance with one or more aspects, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with one or more aspects.

p-0070With reference to <figref idrefs="DRAWINGS">FIG. 7</figref>, illustrated is a methodology <b>700</b> for managing data flows associated with a mobile computing device (e.g., mobile device <b>120</b>). It is to be appreciated that methodology <b>700</b> can be performed by, for example, a mobile computing device and/or one or more hardware or software components associated therewith (e.g., peripheral module(s) <b>126</b>) or any other appropriate computing device(s) or device component(s). Methodology <b>700</b> begins at block <b>702</b>, wherein a set of NAT rules is received from an application processor (e.g., application processor <b>124</b>). Next, at block <b>704</b>, a packet is received via a first coupled interface (e.g., an interface to modem <b>123</b> or a PC interface to tethered computer <b>130</b>). At block <b>706</b>, identification of a NAT rule from the rules received at block <b>702</b> that corresponds to the packet received at block <b>704</b> can then be attempted.

p-0071At block <b>708</b>, it is determined whether the attempted identification of a matching NAT rule at block <b>706</b> was successful. If identification was successful, methodology <b>700</b> can conclude by proceeding to block <b>710</b>, wherein the packet received at block <b>704</b> is translated using the NAT rule successfully identified at block <b>706</b>, and to block <b>712</b>, wherein the packet is passed to a second coupled interface (e.g., a modem interface in the case of a packet originating from a tethered computer or vice versa). In contrast, if identification at block <b>706</b> was unsuccessful, methodology can instead conclude by proceeding from block <b>708</b> to block <b>714</b>, wherein the packet received at block <b>704</b> is passed to the application processor.

p-0072<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates an example methodology <b>800</b> that can be utilized for managing downlink data associated with a mobile computing environment. Methodology <b>800</b> can be performed by, for example, a computing device (e.g., via one or more hardware components such as SPS <b>460</b> and its subcomponents) and/or any other suitable device. Methodology <b>800</b> begins at block <b>802</b>, wherein a set of NAT rules is received from an application processor (e.g., application processor <b>310</b> via SPS driver <b>414</b>). Next, at block <b>804</b>, a downlink packet is received from a modem subsystem interface (e.g., a protocol processor <b>452</b> associated with modem <b>350</b>). At block <b>806</b>, identification of a NAT rule received at block <b>802</b> that corresponds to the packet received at block <b>804</b> is then attempted (e.g., by a decision block <b>462</b>).

p-0073In accordance with one aspect, methodology <b>800</b> can branch at block <b>808</b> based on the result of the attempted identification at block <b>806</b>. For example, if a NAT rule is successfully identified at block <b>806</b>, methodology <b>800</b> can proceed from block <b>808</b> to block <b>810</b>, wherein the packet received at block <b>802</b> is translated using the identified NAT rule (e.g., by a NAT block <b>464</b>), and to block <b>812</b>, wherein Layer 2 framing is performed for the packet (e.g., by a L2 Packet block <b>466</b>). Methodology <b>800</b> can then conclude at block <b>818</b>, wherein the packet is forwarded (e.g., by MUX <b>468</b>) to a coupled interface (e.g., PC interface <b>340</b>) associated with a tethered computer.

p-0074Alternatively, if a NAT rule is not successfully identified at block <b>806</b>, methodology <b>800</b> can proceed from block <b>808</b> to block <b>814</b>, wherein the packet received at block <b>802</b> is forwarded to the application processor for further processing. Methodology <b>800</b> can then conclude from block <b>814</b> or can optionally proceed to block <b>816</b>, wherein the packet forwarded to the application processor at block <b>814</b> is received back from the application processor following processing. Upon completing the acts described at block <b>816</b>, methodology <b>800</b> can then conclude at block <b>818</b> as described above.

p-0075Turning to <figref idrefs="DRAWINGS">FIG. 9</figref>, a methodology <b>900</b> for managing uplink data associated with a mobile computing environment is illustrated. It is to be appreciated that methodology <b>900</b> can be performed by any suitable computing device(s) and/or subcomponent(s) related to a computing device. Methodology <b>900</b> begins at block <b>902</b>, wherein a set of NAT rules is received from an application processor. Next, at block <b>904</b>, an uplink packet is received from a coupled interface associated with a tethered computer. Layer 2 parsing can then be performed at block <b>906</b> (e.g., by a L2 Parse block <b>472</b>) for the packet received at block <b>904</b>, and identification of a NAT rule received at block <b>902</b> that corresponds to the packet received at block <b>1404</b> can subsequently be attempted at block <b>908</b> (e.g. by a decision block <b>474</b>).

p-0076As shown in <figref idrefs="DRAWINGS">FIG. 9</figref>, methodology <b>900</b> can branch at block <b>910</b> based on the result of the attempted identification at block <b>908</b>. Thus, upon successful identification of a NAT rule at block <b>908</b>, methodology <b>900</b> can proceed from block <b>910</b> to block <b>912</b>, wherein the packet received at block <b>902</b> is translated using the identified NAT rule (e.g. by a NAT block <b>476</b>). Methodology <b>900</b> can then conclude at block <b>914</b>, wherein the packet is forwarded (e.g. by MUX <b>478</b>) to a modem interface.

p-0077Alternatively, upon an unsuccessful attempt to identify a NAT rule at block <b>908</b>, methodology <b>900</b> can proceed from block <b>910</b> to block <b>916</b>, wherein the packet received at block <b>902</b> is forwarded to the application processor for further processing. Methodology <b>900</b> can conclude following the acts described at block <b>916</b> or can optionally proceed to block <b>918</b>, wherein the packet is returned from the application processor following processing. After completion of the acts described in block <b>918</b>, methodology <b>900</b> can then conclude at block <b>914</b> as described above.

p-0078<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates an apparatus <b>1000</b> that facilitates data service management for a network interface sharing application. It is to be appreciated that apparatus <b>1000</b> is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware). Apparatus <b>1000</b> can be implemented by any suitable computing device (e.g., mobile device <b>120</b>) and/or component(s) thereof (e.g., peripheral module(s) <b>126</b>) and can include a module <b>1002</b> for receiving NAT mapping rules from an associated apps processor, a module <b>1004</b> for identifying a packet obtained via a first interface, a module <b>1006</b> for attempting matching of the identified packet to respective received NAT mapping rules, a module <b>1008</b> for translating the packet according to a matching NAT mapping rule and directing the packet to a second interface upon successful attempted matching, and a module <b>1010</b> for directing the packet to the apps processor upon unsuccessful attempted matching.

p-0079Referring now to <figref idrefs="DRAWINGS">FIG. 11</figref>, an illustration of a wireless multiple-access communication system is provided in accordance with various aspects. In one example, an access point <b>1100</b> (AP) includes multiple antenna groups. As illustrated in <figref idrefs="DRAWINGS">FIG. 11</figref>, one antenna group can include antennas <b>1104</b> and <b>1106</b>, another can include antennas <b>1108</b> and <b>1110</b>, and another can include antennas <b>1112</b> and <b>1114</b>. While only two antennas are shown in <figref idrefs="DRAWINGS">FIG. 11</figref> for each antenna group, it should be appreciated that more or fewer antennas may be utilized for each antenna group. In another example, an access terminal <b>1116</b> can be in communication with antennas <b>1112</b> and <b>1114</b>, where antennas <b>1112</b> and <b>1114</b> transmit information to access terminal <b>1116</b> over forward link <b>1120</b> and receive information from access terminal <b>1116</b> over reverse link <b>1118</b>. Additionally and/or alternatively, access terminal <b>1122</b> can be in communication with antennas <b>1106</b> and <b>1108</b>, where antennas <b>1106</b> and <b>1108</b> transmit information to access terminal <b>1122</b> over forward link <b>1126</b> and receive information from access terminal <b>1122</b> over reverse link <b>1124</b>. In a further example, access terminals <b>1116</b> and/or <b>1122</b> can be coupled to respective computing devices and can operate to provide connectivity between the coupled computing devices and access point <b>1100</b> or a core network or internetwork with which access point <b>1100</b> is associated via one or more data service sharing techniques as generally described herein. In a frequency division duplex system, communication links <b>1118</b>, <b>1120</b>, <b>1124</b> and <b>1126</b> can use different frequency for communication. For example, forward link <b>1120</b> may use a different frequency then that used by reverse link <b>1118</b>.

p-0080Each group of antennas and/or the area in which they are designed to communicate can be referred to as a sector of the access point. In accordance with one aspect, antenna groups can be designed to communicate to access terminals in a sector of areas covered by access point <b>1100</b>. In communication over forward links <b>1120</b> and <b>1126</b>, the transmitting antennas of access point <b>1100</b> can utilize beamforming in order to improve the signal-to-noise ratio of forward links for the different access terminals <b>1111</b> and <b>1122</b>. Also, an access point using beamforming to transmit to access terminals scattered randomly through its coverage causes less interference to access terminals in neighboring cells than an access point transmitting through a single antenna to all its access terminals.

p-0081An access point, e.g., access point <b>1100</b>, can be a fixed station used for communicating with terminals and can also be referred to as a base station, an eNB, an access network, and/or other suitable terminology. In addition, an access terminal, e.g. an access terminal <b>1116</b> or <b>1122</b>, can also be referred to as a mobile terminal, user equipment, a wireless communication device, a terminal, a wireless terminal, and/or other appropriate terminology.

p-0082Turning to <figref idrefs="DRAWINGS">FIG. 12</figref>, an example computing system or operating environment in which various aspects described herein can be implemented is illustrated. One of ordinary skill in the art can appreciate that handheld, portable and other computing devices and computing objects of all kinds are contemplated for use in connection with the claimed subject matter, e.g., anywhere that a network can be desirably configured. Accordingly, the below general purpose computing system described below in <figref idrefs="DRAWINGS">FIG. 12</figref> is but one example of a computing system in which the claimed subject matter can be implemented.

p-0083As shown in <figref idrefs="DRAWINGS">FIG. 12</figref>, an example of a computing environment <b>1200</b> that can be utilized to implement various aspects described herein includes a general purpose computing device in the form of a computer <b>1210</b>. Components of computer <b>1210</b> can include, but are not limited to, one or more processing units <b>1220</b>, a system memory <b>1230</b>, and a system bus <b>1221</b> that couples various system components including system memory <b>1230</b> to processing unit(s) <b>1220</b>. System bus <b>1221</b> can be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.

p-0084In one example, system memory <b>1230</b> can be implemented using volatile and/or nonvolatile memory, such as read only memory (ROM) and/or random access memory (RAM). A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer <b>1210</b>, such as during start-up, can be stored in memory <b>1230</b>. Memory <b>1230</b> can also contain data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit <b>1220</b>. By way of non-limiting example, memory <b>1230</b> can also include an operating system, application programs, other program modules, and program data.

p-0085In addition, computer <b>1210</b> can include other computer storage media which can be removable or non-removable as well as volatile or nonvolatile. For example, computer <b>1210</b> can include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media; a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk; an optical disk drive that reads from or writes to a removable, nonvolatile optical disk such as a CD-ROM or other optical media; or the like. Other computer storage media that could be used include magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.

p-0086In a further example, a user can enter commands and information into the computer <b>1210</b> through input devices such as a keypad or keyboard; a pointing device such as a mouse, trackball, touch pad, touch screen, or the like; a microphone; a camera or optical sensor; and/or any other suitable input device. Input devices associated with computer <b>1210</b> can be connected to processing unit <b>1220</b> through input interface <b>1240</b>. Input interface <b>1240</b> can be implemented in any suitable manner, such as a parallel port, a universal serial bus (USB) port, or the like. Additionally or alternatively, a monitor, display screen, speaker, and/or any other suitable output device can be connected to system bus <b>1221</b> via output interface <b>1250</b>, which can in turn communicate with processing unit <b>1220</b>, system memory <b>1230</b>, and/or any other suitable components of computer <b>1210</b>.

p-0087In accordance with one aspect, computer <b>1210</b> can operate in a networked environment using logical connections to one or more other remote computers, such as remote computer <b>1270</b>. Remote computer <b>1270</b> can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and/or any other remote media consumption or transmission device, and can include any or all of the elements described above relative to computer <b>1210</b>. In one example, computer <b>1210</b> and remote computer <b>1270</b> can be coupled via a network or subnet <b>1271</b>. Additionally, computer <b>1210</b> can facilitate connection to remote computer <b>1270</b> and/or a communication network or internetwork via a network adapter <b>1260</b>. Accordingly, in the event that computer <b>1210</b> is associated with both a remote computer <b>1270</b> and the Internet, computer <b>1210</b> can utilize one or more techniques to enable remote computer <b>1270</b> to leverage its connection to the Internet as generally described above.

p-0088It is to be understood that the aspects described herein can be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When the systems and/or methods are implemented in software, firmware, middleware or microcode, program code or code segments, they can be stored in a machine-readable medium, such as a storage component. A code segment can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, etc.

p-0089For a software implementation, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes can be stored in memory units and executed by processors. The memory unit can be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

p-0090What has been described above includes examples of one or more aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further combinations and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim. Furthermore, the term “or” as used in either the detailed description or the claims is meant to be a “non-exclusive or.”