INTERFACE SWITCHING SERVICE

TL;DR

(1) 核心优势：

ISS利用HTTP视频/浏览由多个GET请求组成的特性。当需要切换接口时，后续的GET请求可以通过新接口上的新TCP连接发起，而HTTP协议支持并行TCP连接

(2) 核心机制：

基于 “在网HTTP代理” and “设备HTTP代理”，将大多数video/web流直接从device端分流，而不需要进行走 “核心网关 + IP切换”

The goal of the ISS framework is to provide a service to the NIA to enable dynamically switching the interface of user flows to ensure effective traffic management. Every T seconds, based on the decisions made by the NIA, the ISS switches the network for the appropriate user flows. The fundamental problem in providing seamless connectivity across networks is maintaining the end-toend TCP connection since the IP address of the user changes. While standards bodies such as 3GPP adopt the approach of maintaining the same IP address by anchoring all the traffic through a common gateway, ISS takes a different, yet seamless and low-overhead approach for HTTP-based traffic flows based on two key observations: (i) Mobile operators are resisting tight integration of the data planes of their LTE and WiFi networks to avoid significant increase in backhauling costs for the WiFi traffic (as discussed in Section 2). (ii) HTTP is the dominant mobile protocol (over 90% traffic carried over HTTP [21]). More importantly, HTTP-based video traffic accounts for more than 60% of the total bytes carried on mobile networks and is expected to increase to more than 75% [22, 13]. Although UDP protocol is more suited for video streaming, HTTP/TCP protocol has been employed widely to leverage existing benefits of HTTP, namely caching, CDNs, traversal through NAT, content naming etc. Keeping the above mentioned observations in mind, ISS intelligently leverages certain characteristics of HTTP-based video streaming and web-browsing (discussed below) to design a switching service that switches network interface of flows without anchoring the connection through a single gateway, thereby avoiding backhauling of WiFi traffic through the LTE core network. Please note that although ISS takes a different approach from the 3GPP standard based approaches like I-WLAN, it is a complementary solution and can be deployed as an overlay over existing I-WLAN deployments. This ensures that backhauling can be avoided for atleast HTTP-based flows using ISS, while remaining flows are backhauled using I-WLAN to ensure dynamic interface switching. Given that bulk of the internet traffic is HTTP based including video flows, ISS provides significant cost savings for the operators by avoiding backhauling HTTP flows.

ISS框架的目标是为NIA提供一种服务，以实现用户流接口的动态切换，从而确保有效的流量管理。每隔T秒，基于NIA做出的决策，ISS会为相应的用户流切换网络。在跨网络提供无缝连接时，根本问题在于维持端到端的TCP连接，因为用户的IP地址会发生变化。虽然诸如3GPP等标准组织采用通过将所有流量锚定在同一网关来维持相同IP地址的方法，但ISS针对基于HTTP的流量采用了另一种不同但同样无缝且低开销的方法，这基于两个关键观察：(i) 移动运营商抵制其LTE和WiFi网络数据平面的紧密集成，以避免WiFi流量回传成本的显著增加（如第二节所述）。(ii) HTTP是主要的移动协议（超过90%的流量通过HTTP承载[21]）。更重要的是，基于HTTP的视频流量占移动网络总字节数的60%以上，并预计将增加到75%以上[22, 13]。 尽管UDP协议更适合视频流，但HTTP/TCP协议已被广泛采用，以利用HTTP现有的优势，即缓存、CDN、NAT穿越、内容命名等。

考虑到上述观察，ISS智能地利用了基于HTTP的视频流和网页浏览的某些特性（下文讨论），设计了一种切换服务， 该服务可以在不通过单一网关锚定连接的情况下切换流的网络接口，从而避免了WiFi流量通过LTE核心网的回传。

Tip

(1) "尽管UDP协议更适合视频流，但HTTP/TCP协议已被广泛采用，以利用HTTP现有的优势，即缓存、CDN、NAT穿越、内容命名等"

(2) ATOM 是 I-WLAN 的补充机制，它可以建立在 I-WLAN 的基础上。因此分流按照需求，既可以走 ATOM，也可以走 I-WLAN

请注意，尽管ISS采用的方法与基于3GPP标准的方法（如I-WLAN）不同，但它 是一个补充性解决方案，可以作为覆盖层部署在现有的I-WLAN部署之上。这确保了至少基于HTTP的流可以使用ISS避免回传，而其余流则使用I-WLAN进行回传以确保动态接口切换。

鉴于包括视频流在内的大部分互联网流量都是基于HTTP的，ISS通过避免HTTP流的回传，为运营商节省了显著的成本。

Quick Primer on HTTP: Traditionally HTTP-based videos used to be treated as file downloads. However, with recent advance-ments, two popular schemes have emerged: (i) HTTP progressive download (PD): In this scheme, video players typically request the video in byte ranges instead of downloading the whole file. HTTP-PD was introduced for video pacing i.e., the client requests chunks of videos at a download rate that matches the playing rate and avoids wasting bandwidth in case the user quits the player before the video ends. HTTP-PD also allows users to seek to a later point in the video. (ii) Dynamically adaptive streaming over HTTP (DASH): The design of DASH [17] is aligned with HTTP-PD, however it allows the player to request different encoded versions of the video ensuring adaptability to network conditions. The original video is encoded into multiple bit-rates and divided into segments or chunks that typically contain 4-10 seconds of video. First, the player downloads a file containing the URL for each chunk for every encoded version of the video. The player sends HTTP-GET requests to the server to download the chunk of the appropriate bit-rate according to measured TCP throughput. Similarly, browsing traffic typically consists of several relatively small sized objects (e.g., html, images etc.) and each object is requested by an individual HTTP-GET request.

传统上，基于HTTP的视频被视为文件下载。然而，随着近期的发展，出现了两种流行的方案：

(i) HTTP渐进式下载 (HTTP progressive download, PD)：

在此方案中，视频播放器通常以字节范围请求视频，而不是下载整个文件。引入HTTP-PD是为了实现视频调步，即客户端以与播放速率匹配的下载速率请求视频块，并在用户于视频结束前退出播放器的情况下避免浪费带宽。HTTP-PD还允许用户跳转到视频的后续时间点。

(ii) 基于HTTP的动态自适应流媒体 (Dynamically adaptive streaming over HTTP, DASH)：

DASH [17]的设计与HTTP-PD一致，但它允许播放器请求视频的不同编码版本，以确保对网络条件的适应性。原始视频被编码为多种比特率，并分割成通常包含4-10秒视频的段或块。

首先，播放器下载一个文件，其中包含视频每个编码版本对应每个块的URL。其次播放器向服务器发送HTTP-GET请求，以根据测得的TCP吞吐量下载适当比特率的块。类似地，浏览流量通常由若干相对较小的对象（例如html、图像等）组成，每个对象都通过单独的HTTP-GET请求进行请求。

Leveraging HTTP: The ISS framework leverages the above characteristics of HTTP-based video streaming and browsing wherein the content within a session is downloaded using multiple HTTP GET requests over time. Specifically, when the interface or network of these flows have to be switched, subsequent HTTP-GET requests of these flows can be performed over the new interface. Although, typically HTTP-GET requests are multiplexed over existing TCP connections, sending HTTP requests over multiple TCP connections in parallel is supported by HTTP. Hence, the subsequent HTTP-GET requests are made over one or more TCP connections that are set up over the new interface or network. Although this applies only to HTTP-based video streaming and browsing flows, these traffic flows do not need to be backhauled to the LTE network, thereby saving significant costs for the operator. This is especially important, given that video traffic accounts for a sizeable portion of the total bytes carried by mobile networks and web traffic is the most popular traffic type.

ISS框架利用了上述基于HTTP的视频流和浏览的特性，即会话中的内容随时间推移通过多个HTTP GET请求下载。具体而言， 当这些流的接口或网络必须切换时，这些流后续的HTTP-GET请求可以通过新的接口执行。 尽管HTTP-GET请求通常在现有的TCP连接上进行多路复用，但 HTTP支持通过多个TCP连接并行发送HTTP请求。

因此，后续的HTTP-GET请求是通过在新接口或网络上建立的一个或多个TCP连接发出的。尽管这仅适用于基于HTTP的视频流和Web浏览流，但这些流量无需回传到LTE网络，从而为运营商节省了大量成本。考虑到视频流量占移动网络承载总字节数的相当大一部分，并且Web流量是最流行的流量类型，这一点尤为重要。

Design of ISS

ISS is designed using HTTP proxies in the LTE network and a HTTP proxy at the mobile device to enable seamless interface switching on existing mobile networks as shown in Figure 4. The applications and the browser on the mobile device are configured to use the HTTP proxy on the device, which ensures that the HTTP requests are sent over the appropriate interface. In other words, all HTTP traffic generated from the device is routed through the HTTP proxy on the device. The HTTP proxy is a light-weight user-space program that is capable of proxying the HTTP request from the application or the browser to either the network proxy or directly to the content servers. The HTTP proxy listens for commands to switch interfaces from the Control Logic on the device. Similarly, on the LTE network-side the ISS framework consists of a HTTP Proxy and a Control Logic. The Control Logic exposes an interface for the NIA to send commands for switching the network interfaces of user flows based on the output of the algorithm. The networkside Control Logic maintains a persistent TCP connection with the Control Logic on every device through the LTE network to relay the commands from the NIA to the appropriate devices as shown in Figure 4. The HTTP Proxy within the LTE network is employed for HTTP traffic that excludes video streaming and browsing to ensure seamless switching for other types of traffic. Most mobile operators already deploy HTTP proxies for optimizations and caching purposes. ISS switches the user flows based on the traffic type:

如图4所示，ISS通过 在LTE网络中使用HTTP代理 和 在移动设备上使用一个HTTP代理 来设计，以在现有移动网络上实现无缝接口切换。

移动设备上的应用程序和浏览器被配置为使用设备上的HTTP代理，这确保了HTTP请求通过适当的接口发送。换言之，从设备生成的所有HTTP流量都通过设备上的HTTP代理路由。该HTTP代理是一个轻量级的用户空间程序，能够将来自应用程序或浏览器的HTTP请求代理到网络侧代理或直接代理到内容服务器。HTTP代理侦听来自设备上控制逻辑的切换接口命令。

类似地，在LTE网络侧，ISS框架包含一个HTTP代理和一个控制逻辑。控制逻辑为NIA提供一个接口，以便NIA根据算法的输出发送切换用户流网络接口的命令。网络侧控制逻辑通过LTE网络与每个设备上的控制逻辑维持一个持久的TCP连接，以将来自NIA的命令中继到相应的设备，如图4所示。LTE网络内的HTTP代理用于处理不包括视频流和浏览的HTTP流量，以确保其他类型流量的无缝切换。大多数移动运营商已经部署了HTTP代理以进行优化和缓存。ISS根据流量类型切换用户流：

1. HTTP-based downloads: These flows include downloading of medium to large files (e.g., Dropbox), software updates etc. To ensure that such flows are seamlessly switched between LTE and WiFi, they are always routed through the in-network HTTP proxy as shown in Figure 4. Routing HTTP traffic through the same proxy for both LTE and WiFi ensures that the flow is anchored at a single server and hence the interface switching at the device is transparent to the content servers. Specifically upon instruction to switch interfaces from the ISS, the HTTP proxy on the device sets up a TCP connection with the in-network proxy using the new interface. The in-network proxy tears down the TCP connection over the current interface before sending data over the new TCP connection to keep the HTTP session alive.

这些流包括中到大型文件的下载（例如Dropbox）、软件更新等。为确保此类流在LTE和WiFi之间无缝切换，它们始终通过网络内HTTP代理路由，如图4所示。通过同一代理路由LTE和WiFi的HTTP流量可确保流锚定在单个服务器上，因此设备端的接口切换对内容服务器是透明的。具体而言，在收到来自ISS的切换接口指令后，设备上的HTTP代理会使用新接口与网络内代理建立TCP连接。网络内代理在通过新的TCP连接发送数据之前会拆除当前接口上的TCP连接，以保持HTTP会话的活动状态。

2. HTTP-based video streaming and browsing: Unlike the previous traffic type, these flows are not routed through the in-network HTTP proxy as shown in Figure 4. After receiving a command from the control logic to switch the network interface for a specific web session, the HTTP proxy on the device simply requests the subsequent objects from the new interface, while continuing to receive existing objects from the current interface. In a similar fashion, for video flows, the HTTP proxy on the device simply requests the subsequent video chunks from the new interface.

与前一种流量类型不同，这些流不通过网络内HTTP代理路由，如图4所示。在从控制逻辑接收到切换特定Web会话网络接口的命令后，设备上的HTTP代理仅从新接口请求后续对象，同时继续从当前接口接收现有对象。以类似的方式，对于视频流，设备上的HTTP代理仅从新接口请求后续的视频块。

By leveraging HTTP proxies, ATOM realizes a seamless interface switching service that can be readily deployed. Further, with video traffic not requiring an in-network HTTP proxy, ATOM avoids backhauling the bulk of the traffic (being video) from the core network. Although, we can avoid backhauling of HTTP-based download flows using HTTP byte-range manipulation at the proxy on the device, we avoid HTTP header modifications to ensure a simple design and proper operation across different platforms and applications.

通过利用HTTP代理，ATOM实现了一种可轻松部署的无Seamless接口切换服务。此外，由于视频流量不需要网络内HTTP代理，ATOM避免了将大部分流量（即视频）从核心网回传。尽管我们可以通过在设备代理上使用HTTP字节范围操作来避免基于HTTP的下载流的回传，但我们避免修改HTTP头部以确保设计的简洁性以及在不同平台和应用程序间的正常操作。

3. Non HTTP-traffic: ATOM resorts to using standards-based approaches such as I-WLAN to support seamless switching for non-HTTP traffic. Hence, these flows will need to be backhauled through the mobile core network.

ATOM采用基于标准的方法（如I-WLAN）来支持非HTTP流量的无缝切换。因此，这些流将需要通过移动核心网进行回传。