## 3 A Service-Less Multicast Architecture for Distance Learning
### EI Enabled Multicast Architecture
To achieve this, we propose user end (UE) caching which will be helpful in three scenarios: **(a)** if a cluster member is not attending the multicast stream in live mode, the stream data will be cached locally at UE if the user is connected, **(b)** in case the cluster member is not connected to the cellular network, community detection (a user from the same cluster) will be used to select a member lying in close vicinity. In case the user requests the stream later lying within the selected cache, then D2D mechanisms will be used to deliver the content, and **(c)** in case the cluster member is not connected to the cellular network, and is a geo-outlier with limited connectivity, a D2D relay network will be considered to deliver the stream. We assume that the traffic is uni-directional due to the multicast nature. This means that, in the case of distance learning, most of the streaming traffic is directed from the source (instructor) to the destinations (students). The video can be cached at the edge as long as the cache is not full. The content removal policy that we consider is the Least Recently Used (LRU) cache replacement policy [27]. The access date of the video is updated as soon as the video is accessed by any user. Therefore, when the available storage is consumed, then the video with the least recent access date will be removed. In this way, the removed video will be one that no user has accessed for long, which depicts that this video is no longer a popular or required video. The Algorithm for the proposed solution is presented in Algorithm 1. The detailed algorithm of a cold start step to create UE and content provider proxies can be found in our previous work [26] and presented as follows. Evolved Multimedia Broadcast Multicast Services (eMBMS) is the standard service for multicast in 4G and 5G networks. eMBMS is based on a services-oriented delivery architecture, which means, if a service needs to be multicast, then the service will be announced prior. However, in crowdsourced live video streaming, the mobile network operator cannot announce a service in real time. Ref. [26] discusses the solution to this problem with a technique termed as EdgeCast. The EdgeCast is comprised of three major modules: (a) Request monitoring and multicast/unicast session initiation module, (b) content provider proxy module (CP-Proxy), and (c) user equipment proxy module (UE-Proxy). As multiple viewers watch a live video stream from the content provider at the same time, the stream monitor module analyzes every video request routing through the core network. On arrival of the request, the monitor module looks for an entry of the requested video in its tables. If found, the number of total viewers for the corresponding video is incremented by \(1\); otherwise, a new  
Figure 2: The concept of multi-cast, machine learning, and distance learning. record is inserted and the video is streamed in a unicast fashion. Next, the requested video is searched in another table that contains the information of the videos being streamed to all eNB cells. If the entry is found in any of the records, the number of viewers of that video in that specific cell is incremented by 1, a new service ID is generated, the service ID, video tag, eNB cell ID, and lastly the multicast address is generated and the status of the requested video is set to multicast in the corresponding tables. If the eNB cell for the requested video is not found in the tables, then a new entry is created and the status of the requested video is set to unicast. The process is repeated in reverse order when a viewer leaves a video session and the feasibility of the multicast session is checked.