Get the posters about the Touristic City testbed here.
Please have a look at the summary of the event in Turin from May 22-24, 2019.
The Touristic City testbed represents a use case of future advanced multimedia and entertainment services in an environment such as a touristic attraction (museum, historical palace, etc.), particularly suitable for this type of services. More in detail, the testbed deals with the provisioning of interactive VR content to the end-users visiting the touristic place. To provide an attractive and immersive user experience, such types of applications require the deployment of dedicated slices able to deliver content at high speed and low delays, coupled with the provision from the infrastructure side of the necessary elasticity to exploit and adjust to the available computing and network resources according to the specific needs.
The testbed will be deployed in the touristic city of Turin, where a consistent number of visitors are present throughout the year. The specific location chosen for the testbed deployment is Palazzo Madama, one of the most representative monumental buildings of Piedmont, located downtown Turin. Today, Palazzo Madama houses the Museum of Ancient Art, whose collections include more than 70,000 works dating from the Middle Ages to the Baroque: paintings, sculptures, illuminated manuscripts, ceramics and porcelain, gold and silverware, furniture and fabrics that bear witness to the richness and complexity production of ten centuries of Italian and European art.
The ultimate goal of the touristic city testbed is to improve the user experience of the tourists visiting Palazzo Madama. By providing tourists with VR applications they will be able to get more insights about the history and other information of the building in an interactive manner. Given the specific requirements of this type of applications in terms of throughput and latency, this functionality could not be offered without 5G functions developed by 5G-MoNArch such as: (i) network slicing in order to provide the custom requirements needed for VR, (ii) MEC in order to satisfy the latency requirements of haptic communications, and (iii) resource elasticity in order to satisfy all these requirements in an efficient manner.
One of the main features evaluated in the testbed is the deployment of different slices tailored to specific requirements. For example, in the context of the VR application mentioned above, a network slice may be dedicated to the media content transfer while another latency-efficient slice to the interaction with the VR world and other users through, for example, haptic and/or voice communications. Additionally, further slices may be created in support of other services/applications (e.g. eMBB type) that may coexist with the slices used to provide the VR application.
Palazzo Madama in downtown Turin, Italy
Use case
An illustration of the general use case of the touristic city testbed is depicted below. The general use case is a multi-user real-time virtual guide of one of the several representative rooms of Palazzo Madama, where a 360° video camera will be placed to provide a real-time video stream of the room. In a separate location in the public area of the museum the actual testbed will be physically deployed and will be accessible the end-users. Based on the results of an on-site visit, the museum exit in front of the bookshop turns out to be the most appropriate place, since it is in a good location to showcase the testbed to the visitors that have just finished the visit of Palazzo Madama. Furthermore, visitors that will be interested just into experiencing the testbed can access this area. In this location, one user (the visitor) will be connected via a 5G radio interface and will interact with a second user (in the role of a tour guide) connected through a normal Ethernet connection. Both users will utilise Oculus Rift VR headsets plus Oculus touch controllers to control virtual avatars that will appear in the real-time 360° environment, captured by the 360° video camera in the representative room. The scenario will involve direct voice communication between the two users (VoIP) as well as coordinated cooperative control of 3D scanned representations of cultural artefacts in the representative room. To provide a very immersive experience, the users will be able also to move in the virtual environment through physical movements in the testbed deployment location (a 3 square metres area will be required for each user for an optimal space coverage).
Use case illustration
The system will work as a client-server system utilising 2 slices: 1 slice will carry the 360° video stream from the representative room, while the second slice will handle all other client-server communication (VoIP, multi-user interaction, 3D model registration and control, etc). A 3rd slice related to eMBB traffic type (i.e., download of a 4K video) could be dynamically added to better demonstrate the benefits of the elasticity.
The general use case described above well adapts to the demonstration of the orchestration-driven elasticity and slice-aware elasticity innovations. This leads to the following specific use cases:
Technology case 1 – Enhanced touristic experience using orchestration-driven elasticity
For the orchestration-driven elasticity, starting from a situation in which the NFs related to the two slices of the live users are running on the edge Cloud, it is possible to imagine an NF’s reallocation acting through a controlled resource restriction. For example, it would be possible to emulate a mobile edge computing (MEC) service appearing on the Edge Cloud impacting the performances of the two VR slices (the URLLC it is foreseen to be the most impacted). On this basis, an orchestration-driven elasticity algorithm acts to move to the the NFs related to the 360° video slice to the Central Cloud, freeing resources on the Edge Clouds in order to meet again the requirements to run the NFs of the URLLC slice for the user interaction. More specific, this specific use case will involve the following functionality:
- Two network slices will be setup for VR, one for very low latency services and another one for services that are not so latency constrained.
- An orchestrator will be employed to allocate NFs at the most appropriate location for the service being provided.
- MEC will be employed to provide haptic communications with very tight delay constraints – the corresponding NF will be placed at the Edge Cloud very close to the user.
- In case of lack of resources, e.g., due to additional traffic in the network, orchestration-driven resource elasticity algorithms will be triggered to re-orchestrate NFs, satisfying the above constraint of MEC functions.
Technology case 2 – Enhanced touristic experience in an overloaded network with eMBB traffic using slice-aware elasticity
For the slice-aware elasticity, a third slice related to an eMBB traffic type (for example, an additional video streaming) could be added in parallel to the VR application (first and second slice). According to the video resolution and the coding rate of the video stream, a certain amount of the computation and/or radio resource will be needed for a smooth playback, thus impacting on the VR application. Through a cross-slice resource allocation algorithm as described in Section 2.1 it would be possible to reallocate accordingly the resources in order to accommodate both services while guaranteeing a satisfactory user experience. More specific, this specific use case will involve the following functionality:
- Two network slices will be setup for VR and one network slice for video streaming.
- A cross-slice resource allocation algorithm will be employed to decide on the resource allocation for different slices.
- Upon lack of resources, the algorithm will be triggered to reallocate resources from the video streaming slice to the VR slice which is more-resource constrained.
The above described methodologies to demonstrate the elasticity concepts are not necessarily intended to be implemented at the same time. It will be most practical to have a step-by-step approach, where the testbed evolves according to the user feedbacks as well as the results of the KPIs analysis. Moreover, the described methodologies may be re-defined during the course of the project depending on the progress of the hardware and software implementations and interworking aspects.