DISCUSSIONS

Mobility: While ATOM works well for static and mobile clients at moderate (平缓的) speeds, clients with vehicular mobility may require additional support to use context information (e.g., speed) to ensure that such users are treated as LTE-only users to avoid unnecessary switching due to limited WiFi coverage.

Scalability: Since ATOM is designed to execute for every LTE cell independently, it can be scaled-up easily as LTE cells are added to the network. Typically in current LTE deployments, the coverage of macro, metro and small cells is greater than that of WiFi APs. Hence, considering each LTE cell in isolation ensures scalability without much compromise in performance. However, we envision (设想) that future cellular networks may be significantly more denser with smaller cell sizes resulting in overlapping coverage across several cells. It is an interesting avenue (大道) for future work to design a scalable system for such dense deployments to manages flows belonging to several LTE cells and WiFi APs.

Cellular networks have large number of cells and user flows, provisioning both CPU and storage (for state information) resources for ATOM instances to manage each LTE cell can be expensive. In practical deployments, operators could execute ATOM instances to manage only the subset of LTE cells that are loaded beyond a threshold. Moreover, the epoch time T can be increased to reduce processing overhead (say 1 minute) and ATOM can be executed as and when user flows arrive and/or depart.

Signaling Overhead: ATOM relies on feedback messages from the basestations and WiFi access points which introduces extra overhead on the network. In order to provide quantitative insights into the traffic overhead introduced by ATOM, we performed back of the envelope calculations. The feedback message contains the flows current IP address/port numbers, average transmission rate for that user on the LTE basestation and on the WiFi AP(s). Assuming two WiFi APs on average, these values can be composed in 10 bytes and an average of 50 active flows per LTE basestation, the feedback packet would be about 500 bytes per basestation. If we assume that a particular data center manages a network of about 1000 basestations and also an epoch time (T) of 10 seconds, the total data rate for feedback messages is around 400 Kbps. In the same network assuming an average user data traffic rate of 10 Mbps per basestation (typically peak rate of LTE basestations is about 60 Mbps), the total average user data traffic would be around 10 Gbps. Thus, the network overhead for ATOM under the above assumptions would amount to less than 0.05% of aggregate user data traffic. Excessive Switching: Although the execution time for ATOM will be in the order of several seconds in practice to ensure stability of the system, in certain highly dynamic scenarios, ATOM may cause certain flows to switch frequently between interfaces. However, excessive interface switching for a flow can be avoided by using a deterrence for flows based on the history of switches performed for that flow in the recent past.

Energy Consumption: Although we do not explicitly consider interface energy consumption in ATOM, the energy consumption could be easily incorporated in the utility framework. Depending on the interface, the energy cost can be added as a deterrent for using a particular interface. This can capture scenarios where clients with critical battery levels are assigned to a more energy-efficient interface even though that may not be the best interface in terms of throughput. However, since energy models are complex and depend on the energy consumption of other system components, we exclude it in the design of ATOM to ensure simplicity.

移动性 (Mobility)

尽管ATOM对于静态和中等（平缓）移动速度的客户端表现良好，但 对于车载等高速移动的客户端，可能需要额外的支持来利用上下文信息（例如速度），以确保此类用户被视为纯LTE用户 ，从而避免因WiFi覆盖范围有限而导致的不必要切换。

对于这类超高速场景，它可能某几个瞬间会经过wifi覆盖区，但很显然不应该将其切换连接上去。始终保持纯的LTE即可

可扩展性 (Scalability)

由于ATOM被设计为针对每个LTE小区独立执行，因此随着网络中LTE小区的增加，它可以轻松地进行纵向扩展。在当前的LTE部署中，宏蜂窝、微蜂窝和小型蜂窝的覆盖范围通常大于WiFi AP的覆盖范围。因此，独立考虑每个LTE小区可以在不过多牺牲性能的前提下确保可扩展性。然而，我们设想（envision） 未来的蜂窝网络可能会更加密集，小区尺寸更小，导致多个小区之间出现覆盖重叠。为这类密集部署设计一个可扩展的系统 ，以管理属于多个LTE小区和WiFi AP的流，是一个值得未来研究的有趣方向（avenue）。

蜂窝网络拥有大量的基站小区和用户流，为 管理每个LTE小区的ATOM实例配置CPU和存储（用于状态信息）资源可能会成本高昂 。在实际部署中，运营商可以仅针对负载超过某一阈值的部分LTE小区执行ATOM实例。此外，可以将周期时间T增加（例如，增加到1分钟）以减少处理开销，并且可以在用户流到达和/或离开时按需执行ATOM。

信令开销 (Signaling Overhead)

ATOM依赖于来自基站和WiFi接入点的反馈消息，这会给网络带来额外的开销。为了对ATOM引入的流量开销进行量化分析，我们进行了粗略估算。反馈消息包含流当前的IP地址/端口号、用户在LTE基站和WiFi AP上的平均传输速率。假设平均每个LTE基站有两个WiFi AP，这些值可以组合成10字节，每个LTE基站平均有50个活动流，则每个基站的反馈包约为500字节。如果我们假设一个特定的数据中心管理着大约1000个基站的网络，并且周期时间（T）为10秒，那么反馈消息的总数据速率约为400 Kbps。在同一网络中，假设每个基站的平均用户数据流量速率为10 Mbps（LTE基站的典型峰值速率约为60 Mbps），则总平均用户数据流量约为10 Gbps。因此，在上述假设下，ATOM的网络开销将不到聚合用户数据流量的0.05%。

过度切换 (Excessive Switching)

尽管在实践中ATOM的执行时间将在几秒钟的量级，以确保系统的稳定性，但在某些高度动态的场景中，ATOM可能会导致某些流在接口之间频繁切换。然而，可以通过 基于流在近期历史中执行的切换次数，对此类流使用一种抑制机制来避免过度接口切换 。

能耗 (Energy Consumption)

尽管我们没有在ATOM中明确考虑接口的能耗问题，但能耗可以很容易地整合到效用框架中。根据接口的不同，可以将能源成本作为使用特定接口的一种抑制因素添加进去。这可以涵盖这样的场景： 电池电量严重不足的客户端被分配到能效更高的接口，即使该接口在吞吐量方面可能不是最佳选择 。然而，由于能源模型复杂且依赖于其他系统组件的能耗，为了确保设计的简洁性，我们在ATOM的设计中排除了它。