Incorporating Proxy Services into Wide Area Cellular IP Networks Zhimei Jiang, Li Fung Chang, Byoung Jo J. Kim, and Kin K. Leung AT&T Labs Research 100 Schulz Drive Red Bank, NJ. 07724 fjiang,lifung,macsbug,[email protected] October 21, 1999

Abstract Performance enhancing proxies have drawn considerable interests from the network community as an eective approach to improve user experience in cellular networks. However, previous research has been focusing on the design of proxy servers as well as the functions that these servers provide. In this paper, we study the placement of proxy servers, especially the approach of incorporating proxies into cellular networks, which allows better, faster, and more secure proxy services. We discuss various factors that must be considered when placing proxies inside cellular networks, including the information requirements of the proxies, the network requirements for supporting the proxy functions, and mobility management. Using GPRS as an example, we lay out a procedure for adding proxies into data transmission path in cellular networks.

1 Introduction The past decade witnessed the incredible growth of the Internet that has never before happened to any other technologies. In the meantime, wireless communication has also become an indispensable part of many people's daily life, but often in the simple forms of cellular phones or pagers. With the development of the 3rd generation wireless networks, which promises higher speed and more convenient data access, wireless data services are expected to gain popularity very rapidly and become more sophisticated. Future wireless data services will allow mobile users to access the Internet or data in their home/oce whenever and wherever they need, and using whatever devices they prefer. Although the basic wireless network infrastructure for advanced wireless data services might be in place in the near future, many challenges remain ahead as to how to realize true anywhere, anytime, any device services with high eciency over wireless data networks. One of these challenges is that most of the existing protocols and applications on the Internet are designed for wired networks. As a result, many of them do not work properly or eciently on wireless networks where radio channels have dierent characteristics and devices vary greatly in size and capability. Take web browsing as an example. Most of the web pages on the Internet nowadays have complex layouts and delicate graphics, which are targeted for viewing on PCs or laptops. If the pages are viewed from devices with limited display capability, such as Palm PDAs, the results are mostly unsatisfactory and sometimes may not be viewable at all. Therefore, mechanism needs to be developed to improve the performance of accessing the Internet using either conventional or portable devices in cellular networks. 1

One possible approach is to modify applications, protocols, and other related components for the wireless environment, which can be a very slow and costly process. An alternative approach is to make use of performance enhancing proxies [8, 17, 29]. In this case, mobile users communicate with the performance enhancing proxies which in turn exchange information with the destination servers on behalf of the mobile users. At the proxy, information from the original server is converted to make it suitable for the wireless environment, while at the same time taking into account of user's preference and the characteristics of the device in use. For the web browsing example mentioned above, proxies can reorganize the layout of web pages and shrink images to t into the small display of PDA devices, which reduces bandwidth consumption at the same time. Based on user's preference, proxies can also eliminate graphics completely. Recent development in mark-up languages, including XHTML (Extensible HTML) and XML (Extensible Markup Language), will make this type of transformations more eective [9, 31]. Another advantage of using performance enhancing proxies is that, proxy servers can perform channel adaptation for certain data streams. With channel adaptation the performance of audio and video applications can be signi cantly improved [13, 21, 24].

1.1 Why proxies within cellular IP networks? BS - Base Station BS

..

BS

PS

Proxy Server

PS PS

MS

PS

Access Router

Cellular IP Network

Access Router BS



Gateway Router PS PS Gateway Router

PS



PS

PS Public Internet Backbone server

 Existing proxy services use proxies outside of the cellular IP network  New architecture places proxies within the cellular IP network

Figure 1: General architecture of a cellular IP network with proxy servers. Figure 1 depicts the general architecture of a wide area cellular network connected to the public Internet. For simplicity, we assume the entire cellular network is IP-based . The cellular IP network consists of three key components: gateway routers, access routers, and base stations. Base stations communicate directly with mobile terminals via wireless links. A number of closely located base stations may form a subnet and are connected to the rest of the cellular network through an access router. Gateway routers serve as bridges between the cellular IP network and the Internet backbone. Packets from an Internet server to a mobile user travel through the public Internet and enter the cellular network via a gateway 

Ideas presented in this paper are still valid even if the network is not entirely IP-based.

2

router. Once in the cellular network, they are routed to an appropriate access router, then to the base station that are serving the mobile station (MS), and nally to the mobile station via wireless links. Currently, there are already a variety of proxy services commercially available that are tailored specifically for certain wireless devices or access networks. However, as will be described in section 2, all the existing services place proxy servers outside wireless networks (indicated by the proxy marked with 1 in Figure 1). An advantage of this approach is that the wireless network does not need to be aware of the existence of these proxies, thus simplifying the network design and maintenance, and also separating wireless network from proxy services. However, because the proxies are located outside the wireless network, the performance is often compromised by the long latency between mobile user, proxy server, and original data server. For instance, proxies that aim at reducing web page loading times through image distillation may make actual downloading slower if a mobile user has to use a proxy server located far away in the wired network. Although the latency problem presumably can be alleviated by distributing the proxies at multiple places on the Internet and by con guring mobile devices to always use the closest proxy available, functions that require fast access to channel conditions may never perform well with this architecture. In addition, proxies outside wireless networks have only limited access to information about the networks and the users due to security concern and non-existence of convenient interfaces to wireless networks, thus limiting their ability to perform many functions eciently. For example, proxies outside wireless networks may not have sucient information about the channel conditions and the QoS classes that mobile users have negotiated with the wireless access network. As a result, they can not ensure that their services are conformed to the QoS requirement while maintaining ecient bandwidth usage. Furthermore, for applications such as streaming audio and video, which may require channel information to perform rate adaptation for ecient transmission over wireless links, the latency of accessing channel conditions from outside wireless networks can result in poor adaptations. The amount of trac generated for updating channel state can also be signi cant, thus increasing the likelihood of network congestion. This is particularly true at the gateway routers, where trac from many base stations are aggregated. In light of the high latency, trac overhead, and security problem in the existing proxy service model, a clear alternative is to bring the proxy servers closer to the mobile users by placing them inside the cellular network (indicated by the proxies marked with 2 in Figure 1). In this case, proxies have easier access to information regarding wireless links and users' service pro les, and the wireless network no longer needs to send any sensitive information outside its network, resulting in better, faster, and more secure proxy services. In this paper, we address issues that need to be considered when incorporating performance enhancing proxies into wide area wireless IP networks, and discuss the advantages and disadvantages of several dierent approaches. The rest of the paper is organized as follows. In section 2, we summarize various performance-enhancing proxy functions that may be implemented for wireless data users. We also describe several commercially available proxy services and the main functions they provide. In section 3, we discuss several key issues that must be considered in order to incorporate proxy servers into a general wireless IP network. The problem is examined from the perspective of both proxies and networks. Using GPRS (General Packet Radio Service) as an example, in section 4, we demonstrate in detail the potential approaches to add proxy capabilities into cellular networks, followed by a conclusion in section 5. 3

2 Proxy functions and existing proxy services 2.1 Functions of performance enhancing proxies for wireless users Application Proxy

Data Application Multimedia Application

caching,

prefetching

content transformation ( e.g. customization, adaptation, compression ) application protocol translation ( e.g. HTML<->HDML )

protocol translation ( e.g. TCP<->WTP, UDP<->WDP ) Transport Proxy

TCP performance enhancement ( e.g. split connection, snoop protocol ) compression ( payload and header compression ), header suppression

Table 1: Performance enhancing proxy functions for wide area wireless networks. Table 1 lists various proxy functions that can be used to improve the experience of mobile users in cellular wireless networks. Some of these functions operate at the application level, so the proxy servers need to understand the context of speci c applications; others operate at the transport layer or below and only need to deal with individual packets, without knowledge of how the applications work [8]. At the application level, proxy servers support primarily two types of network applications: (1) Data applications, such as email and web browsing, which only have loose constraints on the delay of data delivery; and (2) Multimedia applications, such as streaming or real-time audio and video, which typically require their data to be delivered within certain rigid time-limit. For both types of applications, a proxy server may cache requested information so that future requests for the same information can be served faster with the cached data [2, 28]. Proxy servers may also go one step further to prefetch the information that might be requested in the near future [23]. Caching and prefetching become even more important when contents need to be transformed before being delivered to the mobile user, since both techniques allow data to be pre-processed thus hiding the processing time from the user. For instance, image distillation may be performed on cached/prefetched images so that the resulting images are ready to be sent immediately to mobile users upon request. Content transformation covers a broad range of operations that proxies may perform. The key idea is to convert data, which are downloaded from a remote server that is unaware of the special needs of mobile devices, to a format that is more suitable to the mobile user, based on device characteristics, link conditions, and QoS requirements, etc. For text, content transformation often means converting rich text or postscript data to simple markup language or plain text; or sending only the dierence between two versions whenever the user requests for an update of certain information [6, 7, 16]. For images and video, content transformation involves operations such as reducing image size and color depth, removing high frequency information, or transcoding which is to encode images/video frames with another coding scheme [1, 7, 16, 20]. Data compression is also a type of content transformation in which data from the original server are assembled at the proxy, compressed based on the nature of the data, and then re-packetized before sending to the mobile users [12]. It is often desirable to make content transformation adaptive to channel conditions to achieve the best possible quality for a given channel. 4

Another type of application level proxy function, application level protocol translation, allows devices and servers that do not support a common protocol to exchange information through the proxy server. For instance, when a user wants to access web servers through a cell phone, proxies can translate web pages written in HTML to languages such as WML (Wireless Markup Language), the markup language de ned in WAP (Wireless Application Protocols), so that data can be displayed properly [39]. Due to the widespread use of TCP on the Internet, most of the proxy functions at the transport and network layer are targeted at the TCP/IP protocols. For instance, one of the basic functions is to perform payload or TCP/IP header compression on individual packets [8, 12, 14]. In addition, many proxy functions have been proposed to improve the performance of TCP over slow and lossy wireless links. They either split a TCP connection into two connections at the proxy, thus shielding the problematic wireless link from the server, or use the snoop protocol, which maintains a single end-to-end TCP connection but intercepts the acknowledgments from mobile users and performs loss recovery locally at the wireless link [3, 4, 5, 25]. For devices that do not support TCP, TCP connections may be ended at the proxy server, while the proxy server conveys the data to mobile devices using protocols that are supported by the devices. An example of such cases is a proxy that acts as a mediator between web servers that accept TCP/IP packets, and mobile devices which use WDP (Wireless Data Protocol), the transport layer protocol speci ed in WAP.

2.2 Existing and forthcoming services for wireless data users Although research on performance enhancing proxies started only a few years ago, some approaches, such as caching, have already been widely deployed. Commercial services that are tailored speci cally to wireless network users have also started to emerge. Table 2 lists several such services together with the functions they provide. Services

Primary Functions

AT&T PocketNet

Protocol translation for cell phones

Project Panama

Markup language translation for a variety of devices

Proxinet GoAmerica

General content transformation for Palm Pilot Data compression for CDPD users

MobilLogic & Wireless Compression, simple content trasformation, Knowledge mobile-optimization for MS-exchange servers

Table 2: Key functions of existing and forthcoming proxy services. AT&T PocketNet [34]: PocketNet is one the earliest mobile-speci c services that allow limited web-like browsing using cell phones. With PocketNet service, CDPD-enabled wireless phones connect to a proxy server that in turn connects to content providers who serve specially designed contents (driving directions, weather, stock, sport scores, etc.) written in HDML (Handheld Devices Markup Language). HDML, which has now become the basis of WML, relies on the \Card and Deck" concept designed to work well on very small displays such as 4 line by 12 character display [39]. 5

Project Panama [36]: Oracle's Project Panama aims at enabling easy access to general web content from a variety of devices. The company claims that their proxy is capable of transforming existing Internet content to a general XML format and then generating desired device-speci c output. Examples of the makeup languages supported are HTML, WML, HDML, TTML (Tagged Text Markup Language), and VoxML (Voice Markup Language). This project is currently at service trial stage. ProxiNet [37]: ProxiNet service is a result of Transend/TopGun WingMan Project at Berkeley, where various aspects of transcoding web contents and other le formats for handheld mobile devices are explored [17]. The service is currently available through a server farm located in California. Using the highavailability, low-cost server cluster architecture developed in another Berkeley project that eventually became Inktomi Internet search engine, the proxy servers of ProxiNet perform dynamic image distillation, reformatting/splitting of web pages, and other HTML tag transforms for viewing on displays commonly found on Palm or WindowsCE handheld devices (about 200*200 resolution). The reformatted and distilled pages are described in a proprietary format and transferred over TCP to handheld devices. Users of handheld devices must install a special lightweight client software. ProxiNet service allows a variety of \regular" web pages to be viewed on handhelds. However, some pages may not be viewable, and some pages are very dicult to navigate even if viewable. ProxiNet transcoding does not adapt to the available bandwidth. GoAmerica [32]: GoAmerica is designed for laptop computers with CDPD modems. A proxy server with or without special client software on laptops intercepts all the trac to and from mobile users and compresses the payloads. In addition, it uses modi ed TCP/IP and/or removes ineciencies in protocols of popular enterprise email and productivity applications such as MicroSoft Exchange. The performance improvement varies for dierent applications. MobileLogic and WirelessKnowledge [35, 40]: MobileLogic provides general proxy functions such as compression, image color reduction, and caching. However, their services also emphasize secure access of corporate data using VPN (Virtual Private Network) technologies. In addition, they provide mobileoptimized access to MicroSoft Exchange group-ware. MobileLogic recently joined the Wireless Knowledge Integrators Alliance Program, which started as a joint venture of Qualcomm and MicroSoft. Although the service oered by Wireless Knowledge has not been revealed, it is expected to be similar to MobileLogic. The service bridges between mobile networks and corporate networks where users' Exchange servers are located. It claims to handle many dierent mobile networks and devices, and initially provides a form of outsourcing of corporate mobile access to company intra-nets. In summary, the existing proxy services rely on proxies outside of cellular networks and perform content transformation based only on certain xed assumptions on devices and channel conditions. There is no adaptation, such as device or channel adaptation, associated with these services. Adaption is essential for improving user experience in cellular networks. For example, with low bandwidth and small display, the proxy needs to perform content transformation aggressively to reduce the delay and to utilize the screen more eciently. Whereas with higher bandwidth and larger screen, the proxy can aord to send more information to the user so that the content will appear better on the screen. On the other hand, adaptation will increase the demand for information about various aspects of the system, such as channel conditions and device capabilities. This makes the existing service model less attractive because of the latency, trac 6

overhead, and security problems described previously. In the rest of this paper, we discuss a more ecient approach which places proxies inside wireless networks.

3 Design considerations for placing proxies into cellular IP networks There are a number of issues that need to be considered when incorporating proxy services inside the cellular IP network shown in Figure 1. As we will demonstrate in this section, many of these issues depend heavily on where the proxy services are located. There are two dierent aspects regarding the location of a proxy server. The rst is its physical location in terms of the distance from the proxy to other key components of the network. Speci cally, inside a cellular IP network, proxy servers can be placed (1) close to a gateway router where there are likely to be a high concentration of trac, (2) close to an access router where trac from a number of base stations in its subnet is aggregated, or (3) close to a base station which only handles trac for a single cell. The second aspect of the location refers to the location of the proxy on the routing path between a base station and a gateway router, meaning at which point the proxy is accessed by packets. Speci cally, a proxy server may be accessed between a gateway router and an access router, or between an access router and a base station, as illustrated in Figure 2. Three routes which include proxies on the data path are highlighted in the gure. Note that Figure 2 does not represent the actual physical locations of the proxies. For instance, the proxy between the base station and the access router on route (1) in the gure can be physically close to or even co-located with either of them. Packet Data Network Cellular IP Network

Gateway Router 



‘ Proxy Server

Proxy Server



‘

Access Router

Access Router 

 PS

‘ PS

PS

 BS

BS . . .

BS - Base Station,

BS

BS

PS ‘ BS . . . BS

PS - Proxy Server

Figure 2: Illustration of locations of proxies on the routing path between base station and gateway router. A proxy server may support one or multiple proxy functions. Dierent proxy functions may be placed at dierent proxy servers depending on the application requirements, network and server capacity, and mobility, etc. We now discuss these issues in detail. 7

3.1 Information required to support proxy functions Device Information

QoS Information

Physical

screen size and color depth, processing ability, memory, power

Functional

protocols, language, character set, encoding scheme, version number

User Subscribed QoS Application / Flow Requirement

best effort / with QoS guarantees, peak rate, average rate, maximum delay, average delay, packet loss probability

Channel Information

throughput, throughput variation, hand-off, error statatistics

User Preference

transformation or customization scheme, range of acceptable QoS, QoS degradation path

Network Information

address, protocol

Other Information

billing method

Table 3: Information required to support proxy functions. In order to support the proxy functions described in section 2 eciently, proxy servers need to obtain current information about the cellular network where the proxy services are oered, as well as the requirements and characteristics of mobile users as summarized in Table 3. Speci cally, proxy servers may need to know what commitments that the mobile network has made in terms of service quality (e.g. user's QoS pro le), what network performance can currently be supported by the network (e.g. current channel conditions), what users actually need for their current applications (e.g. application requirements and user preference), and what functions the devices can support (e.g. device capabilities). These information is used by proxy to perform various functions. For example, content transformation proxies may transform data based upon the capability of the user devices, the current channel conditions, as well as the user's preference. Other information such as billing method may also aect the transformation decision. For instance, users paying by bytes are likely to be more conservative in using the bandwidth than those paying at at rates. In order to determine the best location for a proxy function, we need to consider whether the information needed for performing the function can be obtained conveniently. In general, by placing proxies within the cellular network, they should be able to get more complete information at a faster speed than proxy servers outside of the network. However, the exact location, namely whether it is close to the base station, the access router, or the gateway router, can still make a big dierence in some cases. If prompt reaction to channel condition changes is required by the application, such as adaptive video transmission, the location of the proxy function must be chosen such that the speed of obtaining channel conditions is adequate for achieving the desired performance. Some functions work more eciently when located at certain places due to the nature of the functions. 8

For example, if IP header compression is done at a gateway or an access router, the modi ed packets will need to be encapsulated before being sent to a base station and then de-capsulated before being delivered over the air, whereas the system would be much more ecient if compression is done at base stations.

3.2 Network and server requirements for supporting proxy functions An issue related to information requirements of proxies is the amount of trac generated from exchanging information between a proxy server and other components of the network in order to support the proxy functions. Some information, such as device characteristics, normally does not change within one session, thus only needs to be obtained once for each session. Others, especially channel conditions, may require continuous monitoring and frequent updates. Moreover, depending on the requirements of individual applications, information update may be needed at dierent frequencies. In general, relatively long time averaging of link throughput may be sucient for most data applications, while multimedia applications might require frequent update on detailed channel conditions in order to take full advantage of the available bandwidth during periods with good channel conditions, and to reduce performance degradations when channel conditions deteriorate. If a proxy server is located too far away from a base station and detailed channel information is required, there could be a signi cant amount of trac between the base station and the proxy server, thus increasing the likelihood of congestion over the network path. As far as channel information is concerned, the base station is the best location to obtain such information, while placing proxies close to gateway routers introduces the largest amount of trac across the network. In the latter case, in order to reduce the amount of channel update trac, the period between updates must be prolonged. As a result, the application may be using information that is already obsolete, thus causing a serious negative eect on its performance. In addition to network capacity, proxy server capacity and scalability also need to be considered for the placement of proxy functions in a cellular mobile network. The more users a proxy server has to support, the more powerful it must be, to avoid becoming a performance bottleneck of the system. The scalability issue of a web transcoding service is studied in [16].

3.3 Impact of user mobility As a mobile user moves around, he/she may be handed o from one base station to another. Whenever the user enters a new cell, as part of the hand-o procedure, the location information in various components of the cellular IP network may need to be updated so that future packets for the user can be delivered correctly. We assume the system adopts a two-tier mobility management scheme. Namely, mobile IP is used between user's home network and the current cellular network; and a separate wireless IP protocol is used within the cellular network [11, 22, 27]. We only consider mobility within a cellular network in this paper. For simplicity, we also assume within one session a mobile station communicates with outside servers through a single gateway router. Packets arriving at the gateway routers are forwarded to the Care of Address (CoA) of the mobile station (MS), from where they are delivered to their target MS. The CoA of an MS can be either the address of its base station, or the address of the access router to which the base station is connected. The selection of CoA involves trade-os in system eciency in terms of mobility 9

update and packet forwarding. When the CoA of an MS is the address of its base station, each time the MS moves to another cell, the gateway router has to be informed during the hand-o to allow future packets to be forwarded directly to the new base station from the gateway router. However, since the gateway router typically covers a very large area (there might be only 2-3 gateway routers for a big city), this approach may increase hand-o delays. If the CoA of the MS is the address of the access router, as long as the MS remains within the coverage area of the same access router, only the access router needs to be informed of the cell change. The gateway router is updated only when the MS moves to the service area of another access router. Although the hand-o procedure is simpler for this scheme, it requires the access router to perform address translation or encapsulation to deliver the packets to the base station currently serving the MS. When proxy servers are added into the cellular IP network, they may also need to be updated with the new location during a hand-o. The nal decision depends on the location of the proxy server on the routing path between the base station and the gateway router as illustrated in Figure 2, as well as certain characteristics of the proxy function. Table 3 summarizes whether a proxy should be informed of the cell change in various hand-o scenarios. It turns out that, as shown in Table 3, a proxy may not need to be informed of the cell change only if all of the following three conditions hold: (1) the CoA of the mobile station is the access router, (2) the proxy is accessed between the access router and the gateway router, and (3) the cell change is within the coverage area of the same access router. However, if any base station speci c information is required by the proxy function, location update becomes necessary regardless of the exact location of the proxy, so that the proxy can continue to obtain the information from the new base station. This implies that even if all three conditions described above are met, the proxy server still needs to be informed during a hand-o, as long as the proxy function requires channel information to operate properly.

Proxy Location CoA

Intra-AR Service Area Cell Change

Inter-AR Service Area Cell Change

Between Between BS and AR AR and GR

Between Between BS and AR AR and GR

Base-Station

Yes

Yes

Yes

Yes

Access Router

Yes

No

Yes

Yes

BS - Base Station,

AR - Access Router,

GR - Gateway Router

Figure 3: Proxy update requirement for dierent proxy locations, selections of CoA, and types of cell change. Just like a user might move to the service area of dierent access routers during a session, at some point, a user might move out of the service area of a proxy server. The proxy server then needs to forward the entire session pro le, including information for performing various proxy functions as well as the status of the on-going transactions, to the new proxy so that the new proxy may continue to provide the same service to the user. The related routers must also be updated so that future packets can be delivered to the new proxy server. Section 4 will present a detailed call ow of this procedure in the context of GPRS. To transfer the session pro le from one proxy server to another may introduce substantial delay and 10

overhead to the hand-o procedure. The proxy functions must be carefully designed to carry out the transition eciently. Clearly, the closer the proxy is associated with individual base stations, the more likely that such transitions may occur. Therefore, the placement of the proxy functions must take into consideration of the overhead involved with mobility update procedures.

3.4 Location of the proxy functions The discussions above show that the placement of a proxy function should consider the information requirements of the proxy function, its bandwidth and processing requirements, as well as mobility management. If a proxy is placed close to the gateway router, it has to be powerful enough to handle the high concentration of trac from all the base stations it covers. Because of the relatively long distance to individual cells, it is not convenient to collect and react to channel condition changes from such proxies. On the other hand, since a mobile user will remain in the coverage area of the proxy within one session despite handos, there is no need of moving the status of proxy functions to another proxy. If a proxy is placed close to the access router, it has relatively easier access to the device and channel information. However, the status of the proxy functions may need to be transferred when a user moves to the coverage area of another access router to avoid triangular routing. Such proxies may still not be close enough to base stations to react promptly to fast changing channel conditions, which can be a problem for some real-time applications. Proxies close to base stations enjoy most convenient access to the channel information. However, only functions with small execution footprints may be placed here, as inter-cell hand-os may frequently require current proxy session states to be moved to another proxy. Let us now consider several proxy functions listed in Table 1 and try to place them inside a cellular IP network based on the preceeding discussions. Caching and prefetching: The problem of how and where to keep cache or prefetch servers in a network is relatively well studied. The major issue is the trade-o between low access latency by locating them closer to the edge of a network and high hit rates by locating them deeper inside the network where more trac is accessible. Similar issues exist for the placement of cache/prefetch proxies in mobile networks. For a small network, these proxies can be located near gateway routers where all user data owing to the Internet are aggregated to yield high hit rates. The access latency may not be a big issue for such small networks. As the size of a cellular IP network increases, these servers may need to be moved close to access routers to yield lower access latency, yet they can still maintain reasonable hit rates due to the larger size of the network. Hierarchical caching may be used to improve hit rates in this case. It is unlikely that these proxy servers are placed in base stations, since the hit rates there will be very low due to the smaller size of user population served by a single proxy. Content transformation: The placement of content transformation proxies depends on the speci c functions the proxies perform. In particular, for content transformation proxies that only aim to serve dierent device capabilities, trade-os similar to caching/prefetching proxy placement can be made. This is because, device speci c transformations need not be dynamic within a single session, and the transformation results can be cached and shared among similar types of devices. However, proxies that perform content transformation/adaptation based on channel conditions may need to be placed at base stations if the transformation/adaptation is highly dynamic, such as adaptive video/audio streaming. If the required 11

frequency of channel condition updates is reasonably low, these proxy servers can be placed at access routers, since they can tolerate higher latency for channel condition updates and the resulting channel update trac is low. Quantitative results for individual functions are needed to determine the best location for speci c proxies. However, it is unlikely that this type of proxies can be placed near gateway routers for a large network due to latency and trac overhead. Application protocol translation/optimization, application level compression: The scalability of servers and adaptivity to channel conditions should be considered for these functions, similarly to the content transformation proxies. Transport level proxies: As we mentioned previously, it is more ecient to place header compression and suppression proxies at base stations to avoid extra tunneling overhead. For transport protocol translation and TCP performance enhancing proxies, since they don't require any information regarding channel conditions directly, it is preferable to place them close to access routers to reduce the location update overhead during handos. Putting them close to gateway routers should be avoided, as it may pose a very high system requirements at gateway routers.

3.5 Other issues - service discovery, security, and reliability The following are several other issues that need to be considered in order to support proxy functions eciently within cellular networks. Service discovery: Depending on whether the mobile station is aware of the existence of the proxies, proxy services can be transparent or non-transparent. In the transparent case, an MS sends out requests as usual. The network, however, is con gured to recognize the needs for proxy services and forward the requests to an appropriate proxy, instead of sending them directly to the destination server. In the nontransparent case, the MS speci cally indicates in its requests the proxy it would like to use, and the network simply forward the requests to the proxy. For both transparent and non-transparent cases, the network needs to provide methods for discovering the location, including IP address or domain name and other con guration information, of a proxy server which provides the requested services. Recent development in automatic service discovery mechanisms, such as SLP (service location protocol) and Jini, should enable such support in the near future [19, 33]. Depending on the mode of the proxy services, i.e. transparent or non-transparent, either the corresponding network component or the MS will execute the service discovery protocol to locate an appropriate proxy server. Security: Security is one of the most important issues in the system design. As we pointed out previously, by placing proxies within cellular networks, the system no longer needs to send any sensitive information outside its networks, resulting in more secure services for mobile users. Regardless of the location of a proxy, authentication and authorization should always be carried out before the proxy service starts. This is to ensure that the user is eligible for the services and the proxy is authorized to process users public and/or private data. Reliability: Reliability should also be built into the design of proxy servers. In particular, some proxy services can be designed so that even if a proxy server fails, currently on-going data ows which have been assisted by the proxy can be continued without the proxy, probably with degraded performance. Trans12

parent header compression or image distillation services are examples of such services. More preferably, the network can automatically locate another proxy to take over a failing server. Other issues, such as cost, may also play a role in determining where a proxy should be placed. Detail discussions on these issues are beyond the scope of this paper. Having studied how to determine the appropriate locations for dierent proxies, we lay out detail procedures for incorporating proxies into a GPRS network in the next section.

4 Incorporating proxies into GPRS networks General packet radio service (GPRS) is a new packet data service introduced in the GSM phase 2 standard [10, 30]. It consists of a packet wireless access network and an IP-based backbone, and is designed to provide access to packet data networks such as the public Internet and X.25. GPRS supports QoS negotiation for dierent service classes. Subscriber QoS pro les include information such as precedence (high, normal or low priority), delay, reliability (in terms of probability of data loss, mis-sequence, corruption, etc.), and throughput (maximum bit rate, mean bit rate). This pro le may be used by proxies for content transformation and adaptation. The basic GPRS wireless access network oers payload bit rates ranging from 9 to 21.4kbps per time slot, while the Enhanced GPRS wireless access technology, i.e. EDGE, will provide bit rates ranging from 9.8 kbps to about 62 kbps per slot. A user may also occupy multiple time slots at the same time to achieve even higher rates. With the increased link capacity, a larger range of applications and devices may be supported. Proxies will play an important role in ful lling a wide variety of user's needs. In this section, we use GPRS as an example to illustrate how to incorporate performance enhancing proxies into cellular IP networks. Figure 4 shows the logical architecture of GPRS. Two important network entities are the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). In general, one GGSN supports several SGSNs, and one SGSN supports several base stations. SGSN and GGSN correspond to the access router and gateway router in the general wireless IP network shown in Figure 1 respectively. In the following, we describe brie y of the GPRS components that may be aected by adding proxy seversy .

4.1 GPRS overview In GPRS, SGSN keeps track of the locations of individual MSs and performs security functions as well as access control. GGSN, which is connected with SGSNs via an IP-based GPRS backbone network, provides interworking with external packet-switched networks. GGSN contains the routing information to the point of SGSN for the current GPRS users, which means in mobility management, the CoA of an MS is the address of its SGSN. Unlike the general wireless IP network shown in Figure 1, in GPRS, only the backbone connecting GGSNs and SGSNs is IP-based. Base Station Subsystem (BSS), which does not support IP, communicates with its SGSN through a specially designed protocol. In addition, the packet data network, to which the GPRS functions that are not directly related to proxy service are simpli ed in our discussion. Please refer to [30] for a complete description of GPRS. y

13

MSC/VLR

MS

SGSN

BSS

HLR

SGSN

GGSN

Packet Data Network

GGSN

Signaling Interface

Other PLMN

Signaling and Data Transfer Interface

(Public Land Mobile Network)

Figure 4: GPRS Logical Architecture. wireless network is connected through GGSN, does not have to be IP-based either. To forward both IP and non-IP packets between themselves, SGSN and GGSN encapsulate packets using a special protocol called the GPRS Tunneling Protocol (GTP), which operates on top of the TCP/IP protocols supported by GPRS backbone. The interface between SGSN and MSC/VLR (Mobile Service Center/Visitor Location Register) is to enable MSC/VLR to send voice paging messages to SGSN, and to have SGSN page the users if users subscribe to both GPRS and GSM services. The interface between GGSN and HLR (Home Location Register) is for the GGSN to request subscribers location information from the HLR if needed.

1) PDP context

An important concept in GPRS is called PDP (Packet Data Protocol) context. The PDP contexts at SGSN and GGSN, which are established during the PDP context activation process, contain routing information for forwarding packets between GGSN and MS, and between SGSN and public data network respectively. PDP context activation can be initiated by MS or by the network. When an MS wants to activate access to the public data network, it needs to inform the network to activate a PDP context. Figure 5 illustrates the corresponding PDP context activation procedure. Basically, the MS sends a PDP context activation request to the SGSN, which then sends a Create PDP Context Request to the aected GGSN. After processing the request, the GGSN creates a PDP context for this ow and replies with a Create PDP Context Response message to the SGSN. The SGSN then nishes the creation of its copy of PDP context and returns an Activate PDP Context Accept message to the MS if the request succeeds.

2) Mobility management

GPRS has a comprehensive mobility management scheme. A major part of it deals with the routing area update during a cell change. When a GPRS-attached MS enters a new cell, if it remains in the service area of the same SGSN, then only the SGSN is updated. Otherwise, in addition to SGSN, the PDP context at the GGSN is also updated. Figure 6 shows the step by step procedure of an inter-SGSN routing area update. The inter-SGSN routing area update proceeds as follows. When an MS detects that it is in a new routing area, it starts the routing area update procedure by sending a Routing Area Update Request 14

06

%66

6*61

**61

 $FWLYDWH 3'3 &RQWH[W 5HT

 6HFXULW\ IXQFWLRQ  &UHDWH 3'3 &RQWH[W 5HT

 &UHDWH 3'3 &RQWH[W 5HVS

 $FWLYDWH 3'3 &RQWH[W $FFHSW

Figure 5: PDP context activation procedure. to the new SGSN (1). The new SGSN then sends SGSN Context Request to the old SGSN to obtain information regarding the MS such as its PDP context. The old SGSN responds with SGSN Context Response which includes the information SGSN requested (2). Security functions may be executed (3). The new SGSN then returns an SGSN Context Acknowledgment message to the old SGSN (4). From this point on, the old SGSN may tunnel packets destined to this MS to the new SGSN (5). The new SGSN sends an Update PDP Context Request, which includes the new SGSN address and the QoS negotiated, to the GGSNs concerned. The GGSNs update their PDP context elds and return Update PDP Context Response (6). The new SGSN also informs the HLR of the change of SGSN by sending Update Location message to the HLR (7). The HLR then cancels the location with the old SGSN (8) and informs the new SGSN the subscription data of the MS (9). If everything proceeds successfully, the HLR acknowledges the Update Location by sending Update Location Ack to the new SGSN (10). The new SGSN constructs the PDP context for the MS and then responds to the MS with Routing Area Update Accept (11). The MS completes the routing area update procedure by acknowledging the new SGSN with a routing Area Update Complete (12). The routing area update request may be rejected in the middle of the procedure due to regional subscription or roaming restrictions. A reject is returned to the MS with an appropriate cause. Cell changes may also trigger update of MSC/VLR. The procedure is very similar to the one described above. We will not repeat the details here.

4.2 Adding proxies to GPRS In principle, proxies may be placed close to base stations, access routers, or gateway routers. However, since base stations are not IP capable in the current GPRS, it is very dicult to place proxy functions at base stations or between base station and SGSN without any major modi cations to the GPRS architecture. In the rest of this section, we focus on how to support proxy functions between SGSN and GGSN with minor modi cations to the GPRS architecture. When a proxy function is located between an SGSN and a GGSN, from the SGSN's point of view, the proxy server acts similarly to a GGSN; while from the GGSN's point of view, it acts like an SGSN. The main GPRS components that may be aected by adding proxy servers are routing, which is controlled by PDP context, and mobility management. We now discuss these two issues as follows. 15

%66

06

1HZB6*61

2OGB6*61

**61

+/5

 5$ 8SGDWH 5HT  6*61 &RQWH[W 5HT  6*61 &RQWH[W 5HVS  6HFXULW\ IXQFWLRQ

 6*61 &RQWH[W $FN  )RUZDUG SDFNHWV

 8SGDWH 3'3 &RQWH[W 5HT  8SGDWH 3'3 &RQWH[W 5HVS  8SGDWH ORFDWLRQ  &DQFHO /RFDWLRQ  &DQFHO /RFDWLRQ $FN

 ,QVHUW 6XEVFULEHU 'DWD  ,QVHUW 6XEVFULEHU 'DWD $FN

 8SGDWH /RFDWLRQ $FN

 5$ 8SGDWH $FFHSW  5$ 8SGDWH &RPSOHWH

Figure 6: Inter-SGSN routing area update procedure.

1) PDP context and routing

In GPRS, several PDP contexts may be created for a single MS to support ows with dierent QoS requirements. As described previously, the PDP contexts at SGSN and GGSN contain routing information for forwarding packets between the two. To support proxies between SGSN and GGSN, the scope of the PDP context needs to be slightly expanded to allow packets to be forwarded to entities other than SGSN and GGSN. In particular, for ows that need to go through a particular proxy, a PDP context may be created so that the corresponding SGSN and GGSN will send packets to the proxy server instead of to each other directly. In addition, the proxy server also creates a copy of the PDP context during the PDP context activation procedure, which contains the addresses of the SGSN and GGSN that are serving the mobile station. After processing the data, the proxy will forward the resulting packets to either the GGSN for outgoing packets or the SGSN for incoming packets. Figure 7 illustrates the modi ed PDP context creation procedure for supporting proxy server. The only dierence from the standard procedure shown in Figure 5 is that the SGSN sends an Activate Proxy Request to the proxy server which in turn sends a Create PDP Context Request to GGSN. The responses follow the same path, namely from GGSN to proxy and then to SGSN. The address of the proxy server is either given in the Activate PDP Context Request from the mobile station (non-transparent mode), or determined by SGSN based on the type of

ow the PDP context is going to support (transparent mode), as described in section 3.5.

16

06

%66

6*61

3UR[\

**61

 $FWLYDWH 3'3 &RQWH[W 5HT

 6HFXULW\ IXQFWLRQ  $FWLYDWH 3UR[\ 5HT  &UHDWH 3'3 &RQWH[W 5HT

 &UHDWH 3'3 &RQWH[W 5HVS  $FWLYDWH 3UR[\ 5HVS

 $FWLYDWH 3'3 &RQWH[W $FFHSW

Figure 7: PDP context activation procedure with proxy supports.

2) Mobility update

The mobility update procedure also needs to be changed accordingly. With proxies between SGSNs and GGSNs, there are three levels of mobility update (1) intra-SGSN, hence intra-proxy, (2) inter-SGSN, but intra-proxy, and (3) inter-SGSN and inter-proxy. The rst scenario is the simplest, in which the MS stays within the service area of an SGSN after a cell change. The proxy does not need to be informed unless the proxy function requires information that is speci c to the base station. If, as the result of a cell change, the MS has just moved into the service area of another SGSN but is still covered by the same proxy server (scenario 2), the proxy server should be informed about the change. The mobility update procedure in this case is very similar to that shown in Figure 6 except for Step 6. Instead of updating the PDP context at GGSN, Step 6 should update the proxy context at the proxy server. The most complex scenario of mobility update occurs when the MS moves out of the service areas of both SGSN and proxy (scenario 3). The mobility update procedure for this case is depicted in Figure 8. Step 1-5 and 7-12, which involve updating SGSN and HLR, are very similar to that shown in Figure 6. We will not repeat them here. Instead, we will focus on the steps related to the proxy only (Step 6.1-6.7). Once it is discovered that the MS has moved into the service area of a new proxy server, SGSN sends a Proxy Context Request to the new proxy. The proxy discovery is carried out by SGSN for transparent proxy services, or by MS for non-transparent proxy services. In the latter case, the MS will include information regarding the new proxy server in its Routing Area Update message to SGSN (Step 1). Upon receiving the Proxy Context Request, the old proxy responds with a Proxy Context Response message which includes con guration information for the proxy functions, execution status, PDP context, etc. The new proxy returns a proxy Context Acknowledgment message to the old proxy, which then starts to tunnel the buered or new packets to the new proxy. The new proxy sends GGSN an Update PDP Context Request with the address of the new proxy. The GGSN updates its PDP context elds and returns an Update PDP Context Response message. The new proxy then nishes the proxy update portion of the mobility update procedure by sending a Proxy Update Accept message to the new SGSN. The discussions above show that the GPRS standard can be easily expanded slightly to support proxies. If future GPRS is to extend IP support to base stations, similar procedure may be adopted to add proxies at base stations or between SGSN and base stations. 17

06

%66

1HZB6*61 2OGB6*61 1HZB3UR[\

2OGB3UR[\

**61 Same as step 1-5 in Figure 6

 3UR[\ XSGDWH 5HT





3UR[\ &RQWH[W 5HT



3UR[\ &RQWH[W 5HVS



3UR[\ &RQWH[W $FN



)RUZDUG SDFNHWV



8SGDWH 3'3 &RQWH[W 5HT



8SGDWH 3'3 &RQWH[W 5HVS

3UR[\ XSGDWH DFFHSW

Same as step 7-12 in Figure 6

Figure 8: GPRS mobility update procedure with proxy support.

5 Summary and future work The latest development of wireless technologies has broadened the scope of wireless data services tremendously. Performance enhancing proxy is a promising technique to improve user's experience with wireless data services by making information delivered to the user adaptive to devices, channel conditions, as well as user preferences. However, the performance of existing proxy services is limited by their service model in which proxies are located outside the wireless network and may even be very far away from mobile users. This paper studies an alternative approach which enables better, faster, and more secure proxy services by incorporating proxies into cellular networks. In particular, we examine issues that must be considered to determine how and where to place various proxy functions within cellular networks as well as their impacts on the system design. It turns out that the nal decision involves balancing trade-os between a number of factors including what information the proxy requires, the latency requirement for obtaining required information, the amount of extra trac it generates, and mobility management, etc. We also illustrate how to add proxy support into GPRS by making only minor modi cations to the PDP context creation and mobility update procedures. Some of the techniques for incorporating proxy functions into cellular networks are already in a relatively mature stage. One example of that is automatic service discovery. Others, especially mobile information gathering API (Application Programming Interface), which allows the proxy to obtain information about devices, channel conditions, etc., are still in its infancy. The transition of proxy function status between proxy servers, which might be invoked when a user moves out of the service area of a proxy, is another challenging problem. The solution should try to minimize the impact of the transition on the application performance. Further research in these areas will ultimately determine how successful the proxy services will be.

18

References [1] E. Amir, S. McCanne, and H. Zhang, \An application level video gateway," Proceedings of ACM Multimedia '95, Nov. 1995. [2] M. Baentsch, L. Baum, G. Molter, S. Rothkugel, and P. Sturm, \World Wide Web caching: the application-level view of the Internet," IEEE Communications Magazine, June 1997, pp. 170-78. [3] H. Balakrishnan, S. Seshan, E. Amir, and R. H. Katz, \Improving TCP/IP Performance over Wireless Networks," Proceedings of 1st ACM Conf. on Mobile Computing and Networking, Nov. 1995, pp. 2-11. [4] H. Balakrishnan, V. Padmanabhan, S. Seshan, and R. H. Katz, \A comparison of mechanisms for improving TCP performance over wireless links," IEEE/ACM Transactions on Networking, vol.5, no.6, Dec. 1997, pp.756-69. [5] A. V. Bakre and B. R. Badrinath, \Implementation and performance evaluation of Indirect TCP," IEEE Transactions on Computers, vol.46, no.3, Mar. 1997, pp.260-78. [6] G. Banga, F. Douglis, and M. Rabinovich, \Optimistic deltas for WWW latency reduction," Proceedings of the USENIX 1997 Technical Conference, Anaheim, January 1997. [7] H. Bharadvaj, A. Joshi, and S. Auephanwiriyakul, \An active transcoding proxy to support mobile web access," Proceedings of 7th IEEE Symposium on Reliable Distributed Systems, Oct. 1998, pp. 118-23. [8] J. Border, M. Kojo, J. Griner, and G. Montenegro, \Performance enhancing proxies," Internet-draft, http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pilc-pep-00.txt, June 1999. [9] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, \Extensible Markup Language (XML) 1.0 speci cation", Feb. 1998, http://www.w3.org/TR/REC-xml [10] J. Cai and D. Goodman, \General packet radio service in GSM," IEEE Communications Magazine, Oct. 1997, pp. 122-31. [11] A. T. Campbell, J. Gomez, and A. G. Valko, \An overview of Cellular IP," Proceedings of 1st IEEE Wireless Communications and Networking Conference, Sep. 1999. [12] C. Chi, J. Deng, and Y.H. Lim, \Compression Proxy Server: Design and Implementation," Proceedings of 2nd USENIX Symposium on Internet Technologies and Systems, Oct. 1999. [13] C. Chien, M. B. Srivastava, R. Jain, P. Lettieri, V. Aggarwal, and R. Sternowski, \Adaptive radio for multimedia wireless links," IEEE Journal on Selected Areas in Communications, vol.17, no.5, May 1999, pp. 793-813. [14] M. Degermark, B. Nordgren, and S. Pink, \IP header compression," http://www.ietf.org/rfc/rfc2507.txt, IETF RFC 2507, Feb. 1999. 19

[15] R. Floyd, B. Housel, and C. Tait, \Mobile Web access using eNetwork Web Express," IEEE Communications Magazine, vol.5, no.5, Oct. 1998, pp. 47-52. [16] A. Fox, S. D. Gribble, Y. Chawathe, and A. E. Brewer, \Adapting to network and client variation using infrastructural proxies: lessons and perspectives," IEEE Personal Communications Magazine, vol.5, no.4, Aug. 1998, pp. 10-19. [17] A. Fox, I. Goldberg, S. D. Gribble, D. C. Lee, A. Polito, and E. A. Brewer, \Experience with Top Gun Wingman, a proxy-based graphical Web browser for the USR PalmPilot," Proceedings of IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing, Lake District, UK, Sept. 1998. [18] A. Furuskar, M. Frodigh, H. Olofsson, J. Skold, \System performance of EDGE, a proposal for enhanced data rates in existing digital cellular systems," VTC '98, Ottawa, Canada, 18-21 May 1998, pp. 1284-9. [19] E. Guttman, C. Perkins, J. Veizades, and M. Day, \Service Location Protocol, Version 2," IETF, RFC2608, June 1999, http://www.ietf.org/rfc/rfc2608.txt. [20] R. Han, P. Bhagwat, R. LaMaire, T. Mummert, V. Perret, and J. Rubas, \Dynamic adaptation in an image transcoding proxy for mobile Web browsing," IEEE Personal Communications Magazine, vol.5, no.6, Dec. 1998 pp. 8-17, [21] C. Y. Hsu, A. Ortega, and M. Khansari, \Rate control for robust video transmission over burst-error wireless channels," IEEE Journal on Selected Areas in Communications, vol.17, no.5, May 1999, pp. 756-73. [22] R. Jain, T. Raleigh, D. Yang, L. F. Chang, C. Gra, M. Bereschinsky, and M. Patel, \Enhancing survivability of mobile Internet access using mobile IP with location registers," Proceedings of INFOCOM'99, March, 1999, pp. 3-11. [23] Z. Jiang and L. Kleinrock, \Web prefetching in a mobile environment," IEEE Personal Communications Magazine, vol.5, no.5, Oct. 1998, pp. 25-34. [24] Z. Jiang and L. Kleinrock, \Adaptive Transmission of Smoothed Video Over a Wireless Channel," accepted to JPDC sepecial issue Wireless Mobile Communications and Computing. [25] D. A. Maltz and P. Bhagwat, \TCP Splicing for application layer proxy performance," Technical Report RC 21139 IBM, available from http://www.cs.cmu.edu/d~maltz. [26] J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, and A. V. Ho, \Delta encoding in HTTP," Internet-draft, http://www.ietf.cnri.reston.va.us/internet-drafts/draft-mogul-http-delta01.txt, Feb. 1999. [27] R. Ramjee, T. La Porta, S. Thuel, and K. Varadhan, \IP micro-mobility support using HAWAII," Internet-draft, http://search.ietf.org/internet-drafts/draft-ramjee-micro-mobility-hawaii-00.txt, Feb. 1999. 20

[28] S. Sen, J. Rexford, and D. Towsley, \Proxy pre x caching for multimedia streams," Proceedings of INFOCOM'99, March 1999, pp. 1310-19. [29] B. Zenel and D. Duchamp, \General purpose proxies: solved and unsolved problems," Proceedings of The Sixth Workshop on Hot Topics in Operating Systems, May 1997, pp. 87-92. [30] ETSI, \Digital cellular telecommunications system (Phase 2+), General Packet Radio Service(GPRS), service description," v6.3.1, 1999. [31] \XHTML 1.0: The Extensible HyperText Markup Language, A reformulation of HTML 4.0 in XML 1.0,"Aug. 99, http://www.w3.org/TR/xhtml1/. [32] GoAmerica Homepage, http://www.goamerica.net/. [33] Jini(tm) Technology White Papers & Other Documentation, http://www.sun.com/jini/whitepapers/. [34] AT&T PocketNet Homepage, http://www.attws.com/personal/pocketnet/index.html. [35] MobileLogic Homepage, http://www.wiretel.com/. [36] Oracle Project Panama Homepage, http://www.oracle.com/mobile/panama/. [37] ProxiNet Homepage, http://www.proxinet.com/products n serv/. [38] Unwired Planet Homepage, http://www.uplanet.com/. [39] WAP Forum Speci cations, http://www.wapforum.org/what/technical.htm. [40] Wireless Knowledge Homepage, http://www.wirelessknowledge.com/.

21