University of Goettingen (Jacopo De Benedetto, Mayutan Arumaithurai, Xiaoming Fu), KDDI (Atsuhi Tagami, Kazuaki Ueda) and University of Rome (Giulio Rossi, Andrea Detti) created a demo for participating in CEBIT. The demo is called “e360: Panoramic Video Streaming via Edge-Computing and Future Internet”. 360-degree panoramic video streaming are becoming very popular, due to the affordable price of cameras and the natural experience given by specific visors like smartphones. The 360-degree video is also related to IoT and Industry 4.0, like security surveillance, equipment inspection and monitoring. The quantity of data produced by a panoramic video is far more superior to normal video, so more than in the past an optimization on the data transmission is required, particularly in the multicast-scenario when more than one client consumes the same stream at the same time. The demo aims to demonstrate how the use of futuristic communication such as ICN solutions comprising of edge computing and future Internet (FI) optimize the network utilization and how much panoramic video streaming can benefit from it. Our demo was showcased in the Niedersachsen booth in Hall 16 and booth 17. This turned out to be a very sucesseful event for ICN2020 and let good dissemination of the project. Our booth was visited by Herr Björn Thümler, Niedersächsen Minister for science and culture and article was published about our exhibit in the newspaper.

Click: ICN2020 CEBIT

In the past years various ICN testbeds were proposed but, except some notable cases, the overall result is to obtain a closed environment and limited scenarios.

ICN2020 project efforts are not in the direction of proposing yet another testbed but instead to provide a platform as open as possible, enabling the possibility to interconnecting and federate existing testbeds, regardless of the specific ICN implementation or the software/hardware available.

The key tool for this ambitious goal is GÈANT Testbed Service (we already talked about GTS in a previous post).

The key features that makes GTS suitable for federated testbeds are:

• complete control on the virtual machine deployed;
• possibility to access external resources via “External Domain Port” resources.

The current efforts in the direction of a federated testbeds takes in consideration two of the main ICN Testbeds actually deployed, the NDN testbed (primarily in the US but with several nodes deployed all over the world too) and the CUTEi testbed (deployed in Japan and a few more countries ). Using GTS two primarly goals are intended to achieve by the ICN2020 project:

• extend CUTEi testbed’s coverage, especially in Europe;
• interconnect CUTEi nodes with NDN Testbed nodes, implementing special gateway inside GTS when needed.

Some demonstrations were already held to show the effectiveness of ICN deployments on the GTS service and the possibility of testbed’s federation:

• ICN personalized global-scale testbed using GTS (ACM ICN17, demo session)
• Interconnection of testbeds to enable better testing (ICNRG meeting, September 2017, Berlin)

References:

• GTS: https://www.geant.org/Services/Connectivity_and_network/GTS/
• NDN Testbed: https://named-data.net/ndn-testbed/
• CUTEi Testbed: Hitoshi Asaeda, Ruidong Li, and Nakjung Choi, “Container-Based Unified Testbed for Information-Centric Networking”, IEEE Network, Vol.28, No.6, pp.60-66, November 2014.

For further updates, follow ICN2020 project on twitter and/or facebook.

Abstract:

Maintaining communication and information sharing in a disaster situation is a challenging task. A typical consequence of a natural disaster is that communication networks get fragmented. Consequently, information published in one fragment is no longer reachable by users in the other fragments. A number of approaches have been proposed to facilitate information retention in the network, most of them reactive, e.g. using data mules. In this paper we propose proactive measures to share information within the network before it becomes fragmented using Information-Centric Networking (ICN). We have developed a system, using the Content-Centric Networking (CCN) protocol, which proactively replicates content across different parts of the network by taking into account how the network will potentially fragment in the future. We demonstrate the
content replication aspect of this system using 16 virtual CCN nodes distributed over 5 potential fragments called ”Communities”

Issue

An issue of delivering video streaming is how to deliver the best video to users with various network qualities. Currently, the publisher provides videos with various quality, and each user selects the optimum video quality. For example, YouTube offers 7 levels of video quality.(As of Oct. 2017)

However the variety of contents can affect negatively the cache hit ratio. For example, when there are 3 video quality levels and each user requests different video quality, the benefit of the in-network cache is null (see Fig.1). To cope this problem, the bitrate selection technique for fairness was proposed. But we will show other approach for tiny PC.

Adaptive Frame-rate Video Streaming

A video is a sequence of continuous images called as “frames”. The adaptive frame rate control method is to change the number of frames to be displayed per second (see Fig.2). In particular, each frame has a unique “name” on ICN. Consumers decide the requesting frame according to their own network quality. Even if each consumer’s frame rate is different, they utilize in-network cache because they require the same “frame”.

The advantages of this method are as follows:

• Utilizing in-network cache
• Producer need only image compression, does not need video compression
• Producer compresses only required frame

This advantages reduces Producer’s processing and transferring load, thus we can deliver the 360-degree panoramic video by the tiny PC (Raspberry Pi).

Sequence Number Estimation

A usual video streaming sequentially requests segments of consecutive numbers. However the above video streaming scheme requires to discretely request the frame number. To cope with this, we estimate the frame number as follows (see Fig.3):

1. Consumer requests Metadata at Base Time
2. Producer replies Metadata including the current frame number (m) and frame interval
3. When Consumer requests a frame, it estimates the frame number at which the request packet will arrive at Producer based on Base Time and Metadata
4. To adjust clock gap and skew, Consumer requests Metadata with a certain interval

This estimation scheme is simple but operates normally.

Conclusion

In-network cache is a feature of ICN, but how to utilize it is one of the challenges. Since the current approach on IP-based architecture is not always optimal, when we design an application, it is important to think how to benefit from ICN’s features, and this work is a concrete example of how to do it.