PROTOTYPE¶

Our test-bed consists of a LTE basestation (or eNodeB), openEPC software EPC [23], Madwiﬁ-based WiFi APs and Linux laptops as clients with both Verizon Pantech LTE dongles [24] and Broadcom WiFi cards (see Figure 5). The eNodeB is a 3GPP Release 9 compliant LTE small cell on the 700 MHz band. Considerable effort, involving code modiﬁcations to the openEPC components, was spent to integrate the eNodeB (closed-source) with the EPC to ensure interoperability with commercially available LTE clients (closed-source). Our EPC network [23] consists of MME, HSS, PCRF for control plane and S-GW and PDN-GW for data plane functions. In addition, the Internet gateway provides connectivity to the Internet and includes key functions such as NAT and DNS.

The LTE clients are Pantech USB dongles with USIM cards programmed with the appropriate identiﬁcation name and secret code to connect with the eNodeB. Since the eNodeB and the clients communicate on Verizon’s licensed band, we use custom built frequency converters. These convert the frequency in both downlink and uplink from 700 MHz to 2.6 GHz, where we have an experimental license to conduct over the air experiments.

我们的测试平台由一个LTE基站（或eNodeB）、openEPC软件实现的EPC [23]、基于Madwifi的WiFi AP以及作为客户端的Linux笔记本电脑组成，客户端配备了Verizon Pantech LTE数据卡[24]和Broadcom WiFi网卡（参见图5）。该eNodeB是一个符合3GPP Release 9标准的、工作在700 MHz频段的LTE小型基站。我们投入了大量精力，包括对openEPC组件进行代码修改，以将（闭源的）eNodeB与EPC集成，确保其能与市售的（闭源的）LTE客户端互操作。我们的EPC网络[23]包括用于控制平面的MME、HSS、PCRF以及用于数据平面的S-GW和PDN-GW。此外，互联网网关提供到互联网的连接，并包含NAT和DNS等关键功能。

LTE客户端是Pantech USB数据卡，其USIM卡已编程写入相应的识别名和密钥，以便与eNodeB连接。由于eNodeB和客户端在Verizon的授权频段上通信，我们使用了定制的频率转换器。这些转换器在下行链路和上行链路中都将频率从700 MHz转换为2.6 GHz，我们拥有在该频段进行无线实验的实验许可证。

Network: We implemented ATOM on the Internet gateway that connects directly to the PDN-gateway. NIA is implemented within the Click modular router using C++, while the ISS-control is a standalone C++ application. NIA periodically gathers the following information from ISS (a) number of user ﬂows active on LTE basestation and WiFi APs, (b) current interface used by each ﬂow (c) weights of application ﬂows and (d) link-layer or PHY rate of each ﬂow. A control logic component is also implemented within the WiFi gateway that provides information about active user ﬂows over the WiFi APs and the link-layer rate of each WiFi user (collected from the APs) to the ISS-control. Once NIA has all the information in an epoch, it executes the algorithm to assign the network interface to each ﬂow and sends a message to the ISS-control with information about all user ﬂows that need to be switched to a new interface. The prototype also includes two Squid [25] HTTP proxies in the network side for both LTE and WiFi networks.

我们在直接连接到PDN网关的互联网网关上实现了ATOM。NIA在Click模块化路由器中使用C++实现，而ISS控制（ISS-control）是一个独立的C++应用程序。NIA周期性地从ISS收集以下信息：(a) LTE基站和WiFi AP上活跃的用户流数量，(b) 每个流当前使用的接口，(c) 应用流的权重，以及 (d) 每个流的链路层或PHY速率。一个控制逻辑组件也实现在WiFi网关内，它向ISS控制提供关于WiFi AP上活跃用户流的信息以及每个WiFi用户的链路层速率（从AP收集）。一旦NIA在一个周期内获得所有信息，它就执行算法为每个流分配网络接口，并向ISS控制发送一条消息，其中包含所有需要切换到新接口的用户流的信息。该原型还在网络侧为LTE和WiFi网络各部署了两个Squid [25] HTTP代理。

Client Device: We implement ISS-control within the Shrpx based HTTP proxy module [26] that runs as a user-space process. The Chrome browser is conﬁgured using the PAC (Proxy Auto Conﬁguration) ﬁle to use the Shrpx proxy as the default proxy for all applications. Hence, all HTTP requests from Chrome are made to the Shrpx proxy. Initially when the device comes online, the ISScontrol establishes a persistent TCP connection and registers using a unique ID with the ISS-control on the network side. When a new application ﬂow is initiated, the Shrpx proxy always connects using the WiFi network if available. We now explain the steps involved when the interface of a particular ﬂow is moved from WiFi to LTE.

我们在基于Shrpx的HTTP代理模块[26]中实现了ISS控制，该模块作为一个用户空间进程运行。Chrome浏览器通过PAC（代理自动配置）文件配置为使用Shrpx代理作为所有应用程序的默认代理。因此，所有来自Chrome的HTTP请求都被发送到Shrpx代理。设备首次上线时，ISS控制会建立一个持久的TCP连接，并使用唯一ID向网络侧的ISS控制注册。当一个新的应用程序流启动时，如果WiFi网络可用，Shrpx代理总是通过WiFi网络连接。我们现在解释当特定流的接口从WiFi移动到LTE时所涉及的步骤。

In the case of HTTP-based download ﬂows, the following steps are involved:

(a) Upon the initiation of a new connection from the browser, the shrpx proxy initiates a TCP connection to the Squid proxy on the LTE network through the WiFi interface.

(b) Upon receiving a command from the ISS-control to switch the network interface from WiFi to LTE, the Shrpx proxy establishes a new TCP connection with the same Squid Proxy through the LTE network.

(c) The Squid proxy then terminates the previous TCP connections over WiFi, before sending HTTP data over the LTE network to ensure seamless continuity of the HTTP session.

对于基于HTTP的下载流，涉及以下步骤：

(a) 当浏览器发起新连接时， shrpx代理通过WiFi接口向LTE网络上的Squid代理发起一个TCP连接

(b) 当收到来自ISS控制的将网络接口从WiFi切换到LTE的命令后，Shrpx代理通过LTE网络与同一个Squid代理建立一个新的TCP连接

(c) 然后，Squid代理在通过LTE网络发送HTTP数据之前，终止之前在WiFi上的TCP连接，以确保HTTP会话的无缝连续性

In the case of HTTP-based video streaming or browsing ﬂows, the following steps are involved: (a) Upon the initiation of a new connection from the browser, the shrpx proxy initiates a TCP connection to the Squid proxy on the WiFi network through the WiFi interface avoiding backhauling trafﬁc through the LTE network. (b) Upon receiving a command from the ISS-control to switch the network interface from WiFi to LTE, the Shrpx proxy establishes a new TCP connection with a Squid Proxy on the LTE network through the LTE interface. (c) The Shrpx proxy then forwards all HTTP requests for subsequent objects from the browser to the Squid prpxy through the LTE network. (d) The Shrpx proxy breaks the TCP connections with the Squid proxy over the WiFi network after all the pending HTTP requests have been downloaded. For both trafﬁc types, the same procedure is repeated when a connection has to be switched to WiFi from LTE.

对于基于HTTP的视频流或浏览流，涉及以下步骤：

(a) 当浏览器发起新连接时， shrpx代理通过WiFi接口向WiFi网络上的Squid代理发起一个TCP连接，从而避免了流量通过LTE网络的回传

(b) 当收到来自ISS控制的将网络接口从WiFi切换到LTE的命令后，Shrpx代理通过LTE接口与LTE网络上的一个Squid代理建立一个新的TCP连接

(c) 然后，Shrpx代理将来自浏览器的所有后续对象的HTTP请求通过LTE网络转发给Squid代理

(d) 在所有待处理的HTTP请求都下载完毕后，Shrpx代理断开与WiFi网络上Squid代理的TCP连接

对于这两种流量类型，当连接需要从LTE切换到WiFi时，重复相同的过程

Currently, we employ SPDY [27] as the protocol between Shrpx and the Squid proxies. Although the network (both LTE and WiFi) proxies are not required for HTTP-based video streaming or Web browsing trafﬁc types, they are employed in our prototype since Shrpx is currently not designed to connect to multiple servers. Since most Web servers require multiple simultaneous TCP connections, Shrpx is conﬁgured to relay the HTTP requests to the respective Squid proxy based on the current network interface used by the device. An important aspect of our implementation is that it can be readily deployed by instrumenting existing mobile protocols and is completely standards compatible.

In summary, ATOM executes as follows: (i) User ﬂows always initiate the connection from WiFi if available and register with the ISS in the network; (ii) NIA executes periodically to select interfaces for all active user ﬂows and (iii) NIA sends a command to the ISS including user ﬂows with new interface information.

目前，我们在Shrpx和Squid代理之间采用SPDY [27]作为协议。尽管基于HTTP的视频流或Web浏览流量类型不需要网络侧代理（LTE和WiFi的），但在我们的原型中部署了它们，因为Shrpx目前未设计为连接到多个服务器。由于大多数Web服务器需要多个并发TCP连接，Shrpx被配置为根据设备当前使用的网络接口将HTTP请求中继到相应的Squid代理。我们实现的一个重要方面是它可以通过调整现有的移动协议来轻松部署，并且完全兼容标准。

总结来说，ATOM的执行过程如下：(i) 用户流在可用时总是从WiFi发起连接，并向网络中的ISS注册；(ii) NIA周期性执行以选择所有活动用户流的接口；以及 (iii) NIA向ISS发送命令，其中包括带有新接口信息的用户流。