Fakhreddine Ababsa
email: fakhreddine.ababsa@ensam.eu

Junhui He
email: junhui.he@ensea.fr

Jean-Remy Chardonnet
email: jean-remy.chardonnet@ensam.eu

Combining HoloLens and Leap-Motion for Free Hand-Based 3D Interaction in MR Environments

Keywords: Mixed reality, Calibration, Natural interaction

The ability to interact with virtual objects using gestures would allow users to improve their experience in Mixed Reality (MR) environments, especially when they use AR headsets. Today, MR head-mounted displays like the HoloLens integrate hand gesture based interaction allowing users to take actions in MR environments. However, the proposed interactions remain limited. In this paper, we propose to combine a Leap Motion Controller (LMC) with a HoloLens in order to improve gesture interaction with virtual objects. Two main issues are presented: an interactive calibration procedure for the coupled HoloLens-LMC device and an intuitive hand-based interaction approach using LMC data in the HoloLens environment. A set of first experiments was carried out to evaluate the accuracy and the usability of the proposed approach.

Introduction

Since a couple of years, both augmented reality (AR) hardware and applications became convincing and widespread in many fields, for example in medicine [START_REF] Aruanno | Hololens-based mixed reality experiences for subjects with alzheimer's disease[END_REF], education, and industry. Microsoft, Facebook and Apple have shown their interest in AR applications, believing in the viability of this technology. Following this trend, the HoloLens headmounted device, which was released by Microsoft in 2016, is one of the leading MR devices. Features include drawing holograms in the user's field of view and enabling interaction with real-world environments. One of its worthwhile features is its own custom holographic processing unit (HPU), which allows complex calculations to be embedded. However, interaction techniques are limited. It proposes two hand gestures only: air tap and bloom. It cannot track precise information about the position of the hands or identify other hand gestures. On the other hand, the Leap Motion Controller (LMC) is a peripheral device dedicated to high accuracy hand tracking. Originally released in July 2013, its goal was to provide an alternative to the traditional mouse and keyboard by proposing free-hand interaction. Its size is quite small, making it possible to be used in combination for example with head-mounted displays in virtual reality. To fill the shortcomings of the HoloLens in terms of interaction, we coupled the LMC to the HoloLens to provide hand tracking data to the HoloLens and create enriched gesture-based interaction in mixed reality. Note that other headsets used for Virtual reality offer already an integration with LMC, such as Oculus. In our case, we developed a communication tool between the two devices to enable data transfer, then we focused on the hand tracking part. As the HoloLens and the LMC have different coordinate systems, it is important to calibrate the coupled device in order to project the 3D points collected by the LMC on the coordinate system of the HoloLens. As long as the spatial configuration of the two devices does not change, the calibration process does not need to be repeated. In this paper, we propose a 3D point based calibration approach in order to achieve more complex and natural 3D interaction. In addition, to collect data, we propose a semiautomatic procedure involving the user without constraining his/her movements. Only the LMC and the HoloLens are used to detect the spatial position of the hand. The entire calibration process uses the user's fingers as a reference and does not require any other instruments. Therefore, the main contribution of this paper is to provide an interactive calibration procedure for the coupled HoloLens-LMC device. Our approach uses the virtual object rendering done by the HoloLens to collect 3D point coordinates from both the HoloLens and the LMC. Based on the calibration results, several demos using free hands to interact with virtual objects are presented. We carried out a set of first experiments to evaluate the accuracy and the usability of the proposed approach.

Related Works

Free hand-based 3D interaction is a topic well explored for many years. Lyons [START_REF] Lyons | System and method for permitting three-dimensional navigation through a virtual reality environment using camera-based gesture inputs[END_REF] proposed camera-based gesture inputs for three dimensional navigation through a virtual reality environment. In [START_REF] Benko | Miragetable: freehand interaction on a projected augmented reality tabletop[END_REF] the authors showed that the physical interaction between virtual and real objects improves user experience and thus enhances the feeling of the presence of virtual contents in the real world. Ens et al. [START_REF] Ens | Counterpoint: exploring mixed-scale gesture interaction for AR applications[END_REF] proposed a mixed-scale gesture interaction technique, which interleaves micro-gestures with larger gestures for computer interaction. Their idea is to create a design space for applying micro-gestures within a greater gestural lexicon in order to adapt the interaction to the task performed by the user. Several input modes are often combined in order to overcome the problems related to the variability of gesture interaction. For instance, using a Leap Motion controller (LMC) allows accurate recognition of natural gestures. Thus, Khademi et al. [START_REF] Khademi | Free-hand interaction with leap motion controller for stroke rehabilitation[END_REF] suggested freehand interaction to rehabilitate patients with stroke; they modified the Fruit Ninja game to use the LMC hand tracking data, enabling patients with arm and hand weakness to practice rehabilitation. Blaha and Gupta built a virtual reality game displayed on an Oculus Rift head-mounted display and coupled with an LMC to help people with amblyopia restore vision in their amblyopic eye [START_REF] Blaha | Diplopia: a virtual reality game designed to help amblyopics[END_REF].

Most of the developed applications using an LMC are proposed in virtual reality, while MR environments suffer from a lack of applications using an LMC, because of equipment limitations. Furthermore, gesture recognition is almost never used in applications involving the HoloLens. Garon et al. [START_REF] Garon | Real-time high resolution 3d data on the hololens[END_REF] identified the lack of high quality depth data as greatly restricting the HoloLens's potential as a research tool. They mounted a separate depth camera on top of the HoloLens, connected it to a stick computer, which was then used to stream the depth data wirelessly to the HoloLens. Several frameworks propose combining a HoloLens with a Kinect to enable multi-person collaboration on 3D objects in an MR environment. The HoloLens 1 are used so that all participants can view the same 3D objects in real time, while the Kinects are used to expand the available gesture interactions with custom gestures. But still, current research on the HoloLens usually adds a depth sensor on it to get more information. In fact, the LMC can also get data about depth, but it can provide more personalized gestures in mixed reality. In this frame, Köhler proposed a combination of the HoloLens and the LMC [START_REF] Köhler | Integration of a leap motion controller with the hololens to enable improved gesture interactions[END_REF] which is very close to what we present here. However, the way he manages the data is different from our approach. He used the data collected by the LMC and analyzed the photos taken by the HoloLens to transform the 3D coordinates of the hand into 2D coordinates in the HoloLens screen using Perspective-n-Point, a well-known problem to estimate the distance between a set of n 3D points and their projection on a 2D plane [START_REF] Carceroni | Numerical methods for model-based pose recovery[END_REF]. His work provides the possibility to create new gestures. However, he only gets 2D coordinates of the hand and loses 3D information, therefore 3D interaction cannot be achieved.

Communication Between the HoloLens and the LMC

The current version of the LMC needs to be physically connected to a computer using a USB cable to provide enough power to infrared LEDs and to enable fast enough data transfer. For the HoloLens, the only physical ports are a 3.5 mm audio jack and a Micro-USB 2.0 port. Unfortunately, only use the Micro-USB port can currently to install and debug applications, charge, and access the Device Portal. Therefore, the built-in processing unit of the HoloLens cannot be used directly with the LMC and a separate computer is needed to allow the LMC to stream data wirelessly to the HoloLens. As shown in Fig. 1, the LMC was attached on top of the HoloLens using some sticky paste. The LMC was not fixed vertically but with an angle of 45°to enable gesture tracking within the field of view of the HoloLens and to track the hands at the chin or chest level. The inclination of the LMC allows thus better covering this area. To exchange data between the LMC and the HoloLens, the UDP protocol was chosen due to its lightness and high speed. Figure 2 shows the architecture of the developed communication tool, with an external computer as a medium to transfer and process data between the LMC and the HoloLens. In practice, HoloLens works as a server and the PC as a client. Initially, the HoloLens IP address is determined and then used by the client to send its first message to the server. The server in turn retrieves the client's IP address, allowing client-server communication. In our implementation, the LMC SDK is used to capture the fingertips' position at each frame. As long as a new frame is generated, it will be sent to the server (HoloLens). On the client side, the messages are received/sent in different threads. This allows the client to listen to the channel while sending a message. Similarly, on the server side a unity event is invoked to reply to the message sent by the client. This architecture allows synchronized and real-time communication between the LMC and the HoloLens.

Calibration Procedure

The main idea of the calibration procedure is to get the coordinates of the same points in different coordinate systems. After careful consideration, we choose fingertips of one hand as the detecting points because fingertips are easy to access from the LMC. The second hand is used to click on the hololens controller once the alignment between the finger and the marker point is completed. This triggers the recording of data. Indeed, fingers can move flexibly and be detected easily by the LMC. The entire calibration process is summarized as follows and will be detailed in the next subsections:

1. Detect the position of a fingertip and get the coordinates from the LMC. 2. Attach a virtual plane to a real plane (either a desk or a wall). 3. Coincide the fingertip with marked points on the plane. 4. The HoloLens records the coordinates of the marked points and the LMC records the fingertip simultaneously. Send the two coordinates to the computer.

5. After collecting a set of points, analyze the data and compute the rigid transformation. 6. Use the computed transformation to change the coordinates of the LMC points in the HoloLens coordinate frame and display in the HoloLens. Compare the error between the virtual and the real points.

3D Points Collection

As shown in Fig. 3, to collect 3D points, we developed a simple application on Unity3D where we display a calibration plane with six small balls embedded (what we called above the marked points). The data collected from the LMC is displayed in the middle of the plane. The whole plane is attached with a "Taptoplace" function. The HoloLens provides spatial mapping allowing to understand the environment. Users can use the cursor to tap on the plane to move it according to the surroundings (see Fig. 4). The virtual plane must be placed according to the real world, so that it can help users accurately determining the position of their fingertip. According to the principle of camera projection, the HoloLens will project threedimensional objects on a two-dimensional screen in front of the user's eyes. Hence, some points with different 3D coordinates will have the same 2D coordinates on the screen.

We need to use a real object because in this way we can compute the exact spatial coordinate by querying the depth information given by the coordinate in the Z-axis direction. Two buttons are displayed on the plane. The button on the right is a "change button": clicking on it will change the rotation of the calibration plane from horizontal to vertical and vice-versa.

The aim of this button is to make the plane compatible with both vertical and horizontal surfaces in the real world.

Once the user fixes the virtual plane according to the real world as shown in Fig. 5 (in this case we attached it to a computer screen), the HoloLens creates a spatial anchor in the world coordinate frame. Therefore, the user can get the relative position between the HoloLens camera and the virtual plane in real time. The button on the middle is a "send button". Clicking on it will allow the HoloLens to send data for calibration. After the first tap, one marked point (blue ball) will turn red. The user positions one fingertip, for example the thumb, on this point (see Fig. 6). If he/she clicks on the send button, both the coordinates of the ball from the HoloLens and the coordinates of the fingertip from the LMC will be sent to the computer. Another ball on the plane will then become red. This operation is done for each point. To help clicking on the buttons, a cursor always appears in the middle of the field of view and can be moved by moving the head. Clicks are performed using the HoloLens built-in clicker, not to affect point collection by the LMC.

Calibration Approach

Once data collection is complete, we get two points clouds in two different frames (see Fig. 7). The first one is collected by the HoloLens, we name it the "reference point cloud", while the second one is collected by the LMC, we name it the "source point cloud". The relationship between these two point clouds is given by: ⎛

⎝ H x H y H z ⎞ ⎠ = R • ⎛ ⎝ L x L y L z ⎞ ⎠ + t (1)
The transformation matrix is composed of two parts: a Translation vector (t) and a Rotation matrix (R). The problem is to find the transformation matrix between both point clouds, knowing that the point clouds should be aligned. Several algorithms have been proposed in past work. In our case, we compared two algorithms. We will not focus on specific mathematical calculation, we will only briefly introduce their principle here. Please note that the first paragraph of a section or subsection is not indented. The first paragraphs that follows a table, figure, equation etc. does not have an indent, either. Subsequent paragraphs, however, are indented.

The first method is the Umeyama algorithm [START_REF] Umeyama | Least-squares estimation of transformation parameters between two point patterns[END_REF]. We denote the reference points as {H i } and the source points as

{L i }, i = 1, 2, • • • , n.
The problem is to find the similarity transformation parameters (R and t) giving the minimum value of the mean squared error ε 2 (R, t) of these two point clouds:

ε 2 (R, t) = 1 n • n i=1 ||H i -(R.L i + t)|| 2 (2)
However, we soon discovered that this algorithm causes large errors. In fact, with this method, the result is obtained through many mathematical transformations due to the coordinate matrices {H i } and {L i }. This method requires that the point's coordinates be very accurate. It only works when the two coordinate groups can be perfectly matched. Since the coordinates are collected manually, errors obviously occur that must be taken into account in the transformation calculation. Another choice to align two point clouds is the Iterative Closest Point (ICP) algorithm [START_REF] Zhang | Iterative point matching for registration of free-form curves and surfaces[END_REF]. The principle of this algorithm is to find the closest points of the source point cloud in the reference point cloud. The whole algorithm is performed by multiple iterations, in which the points with larger errors are excluded. The algorithm steps are:

1. Find the closest points of the source point cloud (collected by the LMC), match them in the reference cloud (collected by the HoloLens). 2. Use a root mean square metric minimization technique to estimate a transform matrix, which will best align each source point to its match, found in the previous step. This step may also involve rejecting outliers prior to alignment. 3. Transform the source points using the obtained transformation matrix and repeat the steps until a defined threshold is reached.

This algorithm has some limitations. First, in order to match the source cloud to the reference cloud, we should know approximately the position of the reference cloud. Otherwise, finding the nearest point will be impacted. It means that before applying the algorithm, the source cloud should be transformed as close as possible to the reference cloud. Because of the arrangement of the two reference frames as shown in Fig. 8, we have to preprocess the source point coordinates (L i ) so that they are closer to the reference coordinates (H i ). The solution is to apply a rotation matrix:

After preprocessing, we get L i :

L i = r • L i ( 4
)
L i can be considered then as the new source point cloud, it only needs to be rotated with a relatively small angle to be aligned with the reference point cloud. The new transformation matrix R , t can be found using the ICP algorithm, where:

H i = R • L i + t = R • r.L i (5)
The second limitation of ICP is a practical one. Indeed, when the number of 3D points increases, the probability of errors becomes greater. The best solution is then to limit the number of points and ensure that most of them are on different planes with different depths according to the Z axis. Figure 9 gives an example of twelve reference points, which are located approximately in the same plane.

Fig. 9. Example of collected points

One point that is a little bit far from the others is displayed and is considered as wrong. In the current collection process, we can collect multiple points at a fixed distance, then change the distance between the HoloLens and the virtual object (just move the head closer to the virtual plane) to continue collecting points.

Calibration Results

First, we compared the results of our method with the naïve approach that uses raw LMC data without taking calibration into account. The finger positions provided by the LMC and projected into the HoloLens reference frame are far away and do not match the real hand. This baseline error measurement clearly shows the need of a space coordinates transformation and quantify on the initial mismatch magnitude. Figures ( 10-a) and (10b) show the results obtained by the Umeyama and the ICP algorithms when processing the same data set. With Umeyama, we get a mean error of 0.0869 m while with ICP we get a mean error of 0.0189 m. It can be seen that because of some errors while collecting the data, there are two points that have a large deviation. ICP can limit their impact, while Umeyama is easily affected with a larger estimation error.

Error Analysis

After calibration, we used the obtained transformation matrix to mark the hand position in the HoloLens screen. We represent the fingertips of the index finger and the thumb by two red balls. As shown in Fig. 11, there are misalignment errors, especially when the hand is not parallel to the vertical plane. However, we have improved previous existing works like [START_REF] Köhler | Integration of a leap motion controller with the hololens to enable improved gesture interactions[END_REF] where the translation error reported by the author is roughly a 4.5 cm along the z-axis; while our approach gives an error of about 1.8 cm. In our case the main factor affecting the registration accuracy is human behavior. All the points are collected manually and using the user's fingertips as reference. During this process, deviations are unavoidable. The spatial mapping provided by the HoloLens also presents deviation compared to the real environment, especially when the interaction distance is close. This error cannot be ignored. The accuracy limits of the LMC can be another reason. According to past work, the LMC cannot reach a theoretical accuracy of 0.01 mm in real conditions, but a high precision (an overall average accuracy of 0.7 mm) for gesture-based interaction is still possible [START_REF] Weichert | Analysis of the accuracy and robustness of the leap motion controller[END_REF].

Free-Hand Interaction

To demonstrate the feasibility of natural interactions in MR environment using LMC data, we implemented intuitive hand-based interaction techniques in the HoloLens environment. These interactions are not proposed for given scenarios, but are chosen to explore simple interaction metaphors allowing virtual object manipulation. The aim is to quickly set up a user evaluation to test the proposed method's ease-of-use. We thus used the 3D coordinates of the fingertips and the center point of the left hand to define three manipulation techniques:

Select by touch: When the index finger collides with the virtual cube in the HoloLens coordinates frame, the cube is selected, and its color changes to green (see Fig. 12). Translate: To move the selected object, the thumb and index finger of the hand must touch each other. To drop the object it simply needs to separate the two fingers.

Rotate:

The selected virtual object is rotated according to the 3D rotation of the left hand (Fig. 13). For that, we use the coordinates of the five detected fingertips and the center of the hand to estimate the plane corresponding to the palm of the hand. Finally, the normal to this plane is computed, which defines the 3D rotation applied to the virtual object when the hand rotates. In order to evaluate the usability of our free-hand interaction approach, we carried out different pre-experiences. We defined the interaction space above a 120 cm × 80 cm table. The user sat in front of the table wearing a HoloLens. An LMC mounted on the front of the HoloLens, facing down, allows the detection of the user's hands in his vision field.

We showed the user four virtual cubes in the AR scene with different sizes and depths (Fig. 14). The considered sizes are, respectively: 0.1 m, 0.05 m, 0.025 m and 0.01 m. We asked the user to select the different cubes in turn using his index finger, move them around and place them on the table. We found that the interaction with the three largest cubes is done correctly. However, when trying to touch the smallest one, we face difficulties, which is quite normal; as the positioning of the cube in the HoloLens mixed reality environment has a theoretical error in the range between 0.01 m and 0.02 m.

The second experiment consisted in selecting a cube and rotating it in all directions using the Rotate interaction metaphor. We found that the user could rotate the virtual object placed on his hand in a natural and intuitive way. This is explained by the fact that the user performs a physical gesture in accordance with the direct manipulation done on the virtual object. Indeed, the mental load of users is reduced when their gestures reflect real-world metaphors that allow them to use the most intuitive gestures they desire. Finally, a qualitative evaluation was carried out. Its purpose was to compare the ease and comfort of use between the proposed approaches and the baseline scheme (HoloLens integrated interaction). We have found that overall the interactions that we propose are less tiring and require less effort and concentration, they can be repeated several times over a long period without generating handling errors or hand fatigue. This is not the case with the baseline scheme.

Discussion

The HoloLens has its own process without using external devices, which provides a stable and fast AR rendering experience. Its spatial mapping is the basis for our calibration procedure. From the results we got, it can be concluded that the combination of the two devices can provide enhanced results in terms of free-hand interaction in MR environments. However, this study has also allowed us to identify some difficulties:

1. According to the official documentation on the HoloLens, the best distance interval to display AR objects in the HoloLens is between 1.25 m and 5 m. When a user wants to use his/her hand to interact, the operating area is always limited to 1.25 m. 2. The field of view of the HoloLens is not very large. It is hard to show many contents in a close range. In other words, the range of activity of the hand is very small. Moreover, the HoloLens screen consists in two separated screens which are located in front of the left and right eyes. When observing close-range objects, it can be difficult for users to combine the projections of both screens due to the change of the focal length of the eyes, which causes severe ghosting. 3. The performance of the HoloLens spatial mapping at close range is not very stable, misjudgments or instability occur frequently. Although the physical location of the LMC relative to the HoloLens is fixed, due to individual differences of user's 'eyes, calibration needs to be performed for each user.

Conclusion

In this study, we introduced free-hand interaction in mixed reality environments combining a HoloLens and an LMC. Two main issues have been solved. The first one concerns the real-time 3D points acquisition from the two devices. For that, we attached a virtual plane with several balls used as reference points to a real object. This idea allowed us to acquire 3D points in the HoloLens reference frame and their corresponding points in the LMC reference frame. The second issue is calibration. We used the ICP algorithm to compute the transformation matrix between both frames. The obtained registration error is about 1 cm, which is quite acceptable to realize basic interaction. Finally, first experiments carried out proved the viability of the proposed free-hand interactions and their interest to improve the sensation of presence in MR environments. Future work will include improvement of the accuracy of our solution by using additional depth sensors like a Kinect. Another interesting possibility would be to implement the whole 3D model of the hand in the HoloLens environment in order to develop more complex and natural free-hand interactions.

Fig. 1 .

 1 Fig. 1. The LMC is attached on the top of the HoloLens and connected to a computer

Fig. 2 .

 2 Fig. 2. Communication architecture between the HoloLens and the LMC

Fig. 3 .

 3 Fig. 3. Calibration plane

Fig. 4 .

 4 Fig. 4. "Taptoplace" according to the spatial mapping

Fig. 5 .

 5 Fig. 5. Changing the rotation of the plane and attaching it to a physical surface (Color figure online)

Fig. 6 .

 6 Fig. 6. 3D points acquisition from HoloLens and LMC (Color figure online)

Fig. 7 .

 7 Fig. 7. The points cloud defined in the HoloLens end LMC reference frames

Fig. 8 .

 8 Fig. 8. HoloLens and LMC coordinate reference systems

Fig. 10 .

 10 Fig. 10. Calibration results obtained with (a) Umeyama and (b) ICP algorithms

Fig. 11 .

 11 Fig. 11. Registration errors (Color figure online)

Fig. 12 .

 12 Fig. 12. Select and move a virtual cube with free hand (Color figure online)

Fig. 13 .

 13 Fig. 13. Rotate a plane according to the rotation of the hand

Fig. 14 .

 14 Fig. 14. The usability evaluation


Mamoutou Diarra
email: mamoutou.diarra@inria.fr

Thierry Turletti
email: thierry.turletti@inria.fr

Walid Dabbous
email: walid.dabbous@inria.fr

Amine Ismail
email: amine.ismail@ekinops.com

Cross-layer Loss Discrimination Algorithms for MEC in 4G networks

Keywords: CCA, LDA, LTE, MEC, RNIS, QUIC, RAN, AMC, CQI, TBS

Traditional loss-based Congestion Control Algorithms (CCAs) suffer from performance issues over wireless networks mostly because they fail to distinguish wireless random losses from congestion losses. Different loss discrimination algorithms have been proposed to tackle this issue but they are not efficient for 4G networks since they do not consider the impact of various link layer mechanisms such as adaptive modulation and coding and retransmission techniques on congestion in LTE Radio Access Networks (RANs). We propose MELD (MEC-based Edge Loss Discrimination), a novel server-side loss discrimination mechanism that leverages recent advancements in Multi-access Edge Computing (MEC) services to discriminate packet losses based on real-time RAN statistics. Our approach collects the relevant radio information via MEC's Radio Network Information Service and uses it to correctly distinguish random losses from congestion losses. Our experimental study made with the QUIC transport protocol shows over 80% higher goodput when MELD is used with New Reno and 8% higher goodput when used with Cubic.

I. INTRODUCTION

Most of today's download data flows are controlled by lossbased congestion control algorithms (CCAs) that consider any packet loss as a congestion signal. The default behavior of such congestion control algorithms once being notified of a packet loss is to decrease their sending rate by reducing the current window size (e.g., RENO, Cubic). Although such a technique is appropriate when losses are caused by congestion, it degrades performance in case of random errors caused by lossy wireless links [START_REF] Park | Analyzing effect of loss differentiation algorithms on improving TCP performance[END_REF]. Therefore, in order to avoid unnecessary rate throttling, loss discrimination algorithms (LDAs) have been proposed to help transport layer protocols distinguish (random) wireless losses from congestion losses in wireless networks, and especially for WiFi networks [START_REF] Park | Analyzing effect of loss differentiation algorithms on improving TCP performance[END_REF], [START_REF] Peng | TCP Veno: TCP enhancement for transmission over wireless access networks[END_REF] However, proposed techniques used by existing LDAs are not efficient in LTE (Long Term Evolution) networks mainly because of different mechanisms used in the radio access network (RAN). Indeed, most LDA approaches proposed in the literature either rely on RTT increase or buffer occupancy measurements in order to differentiate losses. These two techniques are not accurate in LTE for the following reasons: first, detecting a loss at link layer requires at least 8ms in LTE FDD (Frequency Division Duplexing) and another 8ms for the retransmission. Meanwhile in WiFi, link layer loss detection is almost immediate (i.e., within a few µs) and retransmission may take similar time depending on the number of connected stations. Based on that, it is clear that RTT variations during link error losses are more significant in LTE, which doesn't necessarily mean congestion. Second, unlike wireless access points, LTE base stations (eNBs) are generally provisioned with large buffers in order to accommodate rapid changes in link capacity and to compensate for the additional processing time per UE. Therefore, those buffers must be appropriately filled in order to reach optimal link utilization. In that case, relying only on buffer occupancy to infer congestion losses can lead to link under-utilization. Furthermore, unlike Ethernetbased networks where a transport layer packet data unit (PDU) is directly encapsulated in a single link layer PDU (except in cases involving IP fragmentation), the LTE link layer subdivides the layer-4 PDU in several transport blocks whose size depends on the actual radio conditions (encoded in the Channel Quality Indicator (CQI)) and on the number of allocated radio resources. As indicated in 3GPP TR 36.912 [START_REF] Gpp | Feasibility study for further advancements for e-utra (lteadvanced) (rel. 16)[END_REF] (see Figure 1), only one transport block can be sent per transmission time interval (TTI), i.e., every millisecond, and since each transmission is controlled by an independent Hybrid Automatic Repeat Request (HARQ) process, the number of transport blocks that can be sent without interruption (i.e., without waiting for an HARQ ACK or NACK) depends on the total number of HARQ processes. Based on that, it becomes Consequently, a large mismatch in size between transport blocks and layer-4 PDU and/or retransmissions at lower layers can lead to congestion in the RAN. The challenge in this context is to highlight to what extent the involved radio information, mainly CQI and TBS can be used in order to infer congestion losses. Retrieving and making such radio information available to upper layers require either additional services at the base station (eNB) or modifications in the UE. The latter approach is used by recently proposed crosslayer CCAs such as PBE-CC [START_REF] Xie | PBE-CC: congestion control via endpoint-centric, physicallayer bandwidth measurements[END_REF] or CQIC [START_REF] Zhong | Performance evaluation of cqic and tcp bbr in mobile network[END_REF] that rely on client-side radio measurements to adjust their sending rate. Although these approaches guarantee higher link utilization, they also introduce computational overhead and additional power consumption at the UE. Instead, our solution doesn't involve the end user but rather relies on ETSI Multi-access Edge Computing (MEC) [START_REF] Etsi | Multi-access edge computing (mec); radio network information api[END_REF] concepts to collect radio information. Using MEC, applications deployed at the edge can subscribe to a set of MEC services, one of them being the Radio Network Information Service (RNIS) which allows the applications to receive real-time radio information.

In this paper, we highlight to what extent specific information transmitted over LTE RAN, such as CQI and TBS can be used as relevant indicators of congestion in the access network. We leverage the aforementioned radio information at the transport layer by proposing MELD, a new loss notification mechanism for reliable transport protocols. Our proposed approach comes in two variants, MELD-DE (for Download Enhancement) and MELD-ME (for Mixed flows Enhancement). The former discriminates losses and focuses on maximizing goodput while the latter attempts to maintain fairness between short and long flows of the same UE. The two variants are designed for edge delivery scenarios such as short and large file download from servers located at the edge of the network (i.e., close to the RAN). At a basic level, MELD discriminates losses observed at the transport layer by leveraging up-to-date link layer information. For that, it relies on FlexRAN [START_REF] Foukas | FlexRAN: A Flexible and Programmable Platform for Software-Defined Radio Access Networks[END_REF], a software defined RAN platform (SD-RAN) that implements RNIS to collect relevant RAN information. Our proposed approach could help improve the performance of any loss-based CCAs regardless of the underlying transport protocol (e.g., TCP or QUIC). In this paper, we rely on QUIC as the transport protocol because it is more resilient to random losses and high RTT variations that are common in wireless networks [START_REF] Wolsing | A performance perspective on web optimized protocol stacks: Tcp+tls+http/2 vs. quic[END_REF], [START_REF] Langley | The QUIC Transport Protocol: Design and Internet-Scale Deployment[END_REF]. We implemented our solution with one of the most complete implementation of IETF QUIC [START_REF] Piraux | Observing the evolution of quic implementations[END_REF] called picoquic [START_REF] Huitema | picoquic[END_REF] and evaluate its performance with controlled experiments done in the R2lab wireless testbed 1 .

The remainder of this paper is organized as follows. Section II presents the building blocks of our approach by exposing the impact of LTE RAN mechanisms on reliable transport layer protocols before introducing RNIS and highlighting the reasons why it is relevant in the proposed scheme. Section III explores the related work and highlights their limitations. Section IV introduces our proposed MELD scheme and outlines the basic concepts of its design and implementation. Section V presents and interprets the results of our experiments. Finally, we summarize our contributions and future research directions in Section VI.

II. BACKGROUND

In this section, we first give an overview of some relevant LTE FDD radio access parameters and highlight the transport layer issues they introduce. Then we provide a brief overview of a particular MEC service that can be used to mitigate those 1 R2lab Testbed: http://r2lab.inria.fr issues, namely the RNIS, which inspired us to propose the MELD approach.

A. LTE RAN and L4 issues

Recent papers and experiments [START_REF] Huang | An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance[END_REF], [START_REF] Robert | Behaviour of common tcp variants over lte[END_REF] show that most reliable transport layer protocols experience throughput degradation and rate throttling over LTE networks. This phenomenon is mainly due to misinterpretations of some LTE radio access techniques and mechanisms by transport layer protocols (e.g., TCP, QUIC). The most important ones are:

Link adaptation and channel coding: Because of fast varying radio conditions, the base station selects for each user equipment (UE), the adequate modulation and coding scheme (MCS) depending on the reported downlink CQI. Hence TCP and QUIC cannot adapt to fast varying link capacity.

Retransmissions at lower layers: In LTE, besides the forward error correction performed by channel coding, some retransmission techniques are used in Radio Link Control (RLC) and Medium Access Control (MAC) layers, respectively Automatic Repeat Request (ARQ) and Hybrid Automatic Repeat Request (HARQ). ARQ at RLC layer allows retransmissions of missing blocks due to residual HARQ errors (e.g., due to misinterpreted NACKs or retry threshold reached) when using the Acknowledge Mode (AM). These retransmissions are interpreted at the transport layer as RTT increase or bufferbloat signals.

Resource allocation and transport block size: At a basic level, LTE RAN resources are organized in term of physical resource blocks (PRBs). Typically, a PRB lasts one slot (0.5ms) and is composed of 12 sub-carriers, each of which composed of 7 Resource Elements (i.e., 7 symbols). A PRB is the smallest unit of resources that can be allocated to a UE (User Equipment) and it is always allocated in pairs (i.e., 1ms for 2 consecutive slots). The transport block corresponds to the number of bits transmitted per TTI (Transmission Time Interval i.e., 1ms for LTE), hence its size, called Transport Block Size (TBS), depends both on the number of allocated PRBs and on the modulation scheme (e.g., BPSK, 16QAM, etc.). A large difference between TBS and transport layer segment size (MSS) can lead to several retransmissions and/or congestion.

Large buffers: In order to hide packet losses and retransmissions at the physical layer and to accommodate the varying network conditions, LTE networks are generally provisioned with extremely large buffers (e.g., in-flight bytes larger than 1200kB in [START_REF] Huang | An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance[END_REF]), which can penalize short flows in presence of bufferbloat.

B. RNIS as a Service

As specified in ETSI MEC standards [START_REF] Etsi | Multi-access edge computing (mec); radio network information api[END_REF], RNIS provides real-time radio network related information to mobile edge applications. The MEC applications that subscribed to this service can then leverage up-to-date information to dynamically adapt their behaviors to the current RAN conditions. The use of RNIS in an as-a-service manner has been evaluated in [START_REF] Sagar | Exposing radio network information in a MEC-in-NFV environment: the RNISaaS concept[END_REF], with an implementation of a publish-subscribe scheme based on RabbitMQ that is suitable for real-time use-cases. For instance, using a similar approach, the ETSI RAVEN POC [START_REF] Sabella | A Hierarchical MEC Architecture: Experimenting the RAVEN Use-Case[END_REF] showcased a video optimization MEC application that dynamically adjusts the quality of the video streams according to the radio conditions of the users. Similarly, our MELD plugin allows picoquic to exploit relevant radio information (i.e., CQI, TBS and TxQueue length) in order to differentiate at the transport layer congestion losses from random transmission losses. Unlike other LDAs proposed in the literature, our solution takes into account the inherent characteristics of LTE RAN as inputs in the decision-making process.

III. RELATED WORK

As observed by Junxian Huang et al. in [START_REF] Huang | An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance[END_REF], more than 12% of TCP flows in traces collected from a commercial LTE network experience undesired slow start due to the loss of a single packet. More precisely, they identified that retransmission timeout (RTO) expired due to several ARQ/HARQ retransmissions or bufferbloat, and proposed a solution to update the RTO upon receipt of duplicate ACKs. However, with such a solution, the detection of real congestion may be delayed since TCP cannot distinguish between congestion and random losses with duplicate ACKs.

In the literature, several LDAs [START_REF] Varma | Internet congestion control[END_REF], [START_REF] Fu | TCP Veno: TCP enhancement for transmission over wireless access networks[END_REF], [START_REF] Xu | TCP-Jersey for wireless communications[END_REF] have been proposed in order to detect random losses in wireless networks. Samaraweera suggests NCPLD [START_REF] Samaraweera | Non-congestion packet loss detection for TCP error recovery using wireless links[END_REF], a non-congestion packet loss detection scheme that implicitly identifies the type of packet loss using the variation of delay experienced by TCP packets. TCP Veno [START_REF] Peng | TCP Veno: TCP enhancement for transmission over wireless access networks[END_REF], [START_REF] Park | Analyzing effect of loss differentiation algorithms on improving TCP performance[END_REF], proposed by Fu et al. estimates the number N of excess packets in the bottleneck buffer. In case of packet loss, Veno declares random loss if N ă 3. LDA EQ [START_REF] Park | Analyzing effect of loss differentiation algorithms on improving TCP performance[END_REF], similar to TCP Veno, estimates queue usage using information available to TCP. In case of packet loss, congestion is declared when the estimated queue usage is larger than a certain threshold. Ben-Jye Chang and Yi-Hsuan Li proposed a cross-layer-based adaptive TCP algorithm for 4G networks [START_REF] Chang | Cross-layer-based adaptive tcp algorithm in 4g packet service lte-advanced relaying communications[END_REF]. Their approach detects bottleneck location by analyzing client-side cross-layer radio information included in TCP ACKs and discriminates losses based on bottleneck buffer occupancy estimated via delay variation measurements. However, their solution doesn't show significant performance gain under low loss rates (i.e., ď 1%), which is the most frequent case in commercial LTE networks [START_REF] Chen | Measuring cellular networks: Characterizing 3g, 4g, and path diversity[END_REF].

Just like NCPLD, TCP Veno or LDA EQ most LDAs (e.g., West, JTCP, RELDS [START_REF] Park | Analyzing effect of loss differentiation algorithms on improving TCP performance[END_REF]) are either based on RTT variations or on an indication about queue usage. In a LTE context, these two techniques are not appropriate since the RTT varies with TBS and radio conditions (CQI) and queue length can also grow due to retransmissions at lower layers.

Other alternatives to loss-based could be model-based CCAs based on available bandwidth estimation (ABE), which reduce their window size in a more intelligent fashion in case of random losses. The most recent algorithm in this category is BBR [START_REF] Cardwell | Bbr: Congestion-based congestion control[END_REF], which targets an operation point where a Bandwidth Delay Product (BDP) worth of data in flight is maintained while keeping bottleneck buffers empty (i.e., with minimal delays). Although Google claims that BBR is 2700 times faster than CUBIC on fixed networks under 1% loss [START_REF]congestion control comes to gcp your internet just got faster[END_REF], authors in [START_REF] Li | TCP CUBIC versus BBR on the Highway[END_REF], [START_REF] Claypool | BBR: An Implementation of Bottleneck Bandwidth and Round-trip Time Congestion Control for ns-3[END_REF] demonstrate that the two CCAs have similar performance over LTE links. Indeed, algorithms that limit queue occupancy can be effective against bufferbloat but they are not optimal in LTE networks for which buffering is required to take advantage of fast variations in link capacity. Therefore, as suggested by Feng Li and al. [START_REF] Li | TCP CUBIC versus BBR on the Highway[END_REF] a tuning in such CCAs might be needed in order to keep buffers appropriately filled in LTE networks. Although recently proposed client-centric CCAs such as PBE-CC [START_REF] Xie | PBE-CC: congestion control via endpoint-centric, physicallayer bandwidth measurements[END_REF] or CQIC [START_REF] Zhong | Performance evaluation of cqic and tcp bbr in mobile network[END_REF] can overcome BBR limitations in LTE and adapt to fast variations in link capacity by measuring the available bandwidth in the RAN, they require client-side modifications and introduce additional energy consumption in the UE.

Solutions involving Active Queue Management (AQM) techniques are also proposed in the literature to help mitigate bufferbloat. However, the analysis in [START_REF] Varma | Internet congestion control[END_REF] suggests that the most appropriate buffer management scheme to use depends on the application. For instance, CoDel (Controlled Delay) is mostly effective when the application needs both throughput and low latency (already achieved by BBR).

In summary, there is not any solution available in the literature to accurately discriminate random losses while taking into account the ever-changing nature of LTE radio link capacity. In this paper we aim to demonstrate that this problem can be mitigated by correctly interpreting the values of certain RAN information at the transport layer, namely, CQI, TBS and per UE transmission queue (TxQueue) length at the base station. Such a server-side cross-layer approach is only possible in MEC scenarios where the end-server is deployed at the edge.

IV. LOSS DISCRIMINATION VIA RADIO NETWORK INFORMATION SERVICE

In this section, we first highlight the correlation between radio information mentioned in previous sections and LTE loss differentiation. Then we describe the design and implementation of our proposed solution based on the analysis of RAN information.

A. Radio information as congestion signal

In LTE, each UE sends (periodically or not) a Channel Status Information (CSI) report that takes at least 8ms to reach the base station as indicated in 3GPP TR 36.912. The CSI report includes the UE computed CQI value that corresponds to a predefined MCS at the base station side. As illustrated in [START_REF] Khirallah | Design of Bandwidth and Energy Efficient Video Broadcasting Services over LTE/LTE-A[END_REF], a low CQI value indicates a low SINR, hence less bits per symbol in the modulation. CQI, therefore, has a direct influence on the transport block size, regardless of the number of allocated PRBs. So, the number of transport blocks required to transmit a single transport layer PDU highly depends on the CQI value. Consequently, this number must be less than or equal to the number of HARQ processes in order to send the whole PDU without interruption, thus minimizing the risk of bufferbloat at the BS (high buffering) and eventual RTO expiration. Let S TB be the optimal size of transport blocks so that a transport layer PDU can be transmitted without interruption, T PDU the size of transport layer PDU (TCP or QUIC) and N HARQ , the number of HARQ processes. In that case, at least one transport layer PDU is transmitted without interruption (i.e., within HARQ RTT) only if: TBS ě S TB where:

S T B = T PDU N HARQ (1)
Thus, a TBS value less than S TB is likely to introduce queuing delay and congestion. To put it another way, packet losses during low TBS state (i.e., low CQI and/or small number of PRBs assigned to UE) have high probability to cause congestion in the radio network. Conversely, packet losses occurring during high TBS state (i.e., high CQI and/or sufficient number of PRBs assigned to UE) can be attributed to fast random fluctuations of the SINR. Mapping between CQI and MCS is vendor-specific [START_REF] Roman | An accurate approximation of resource request distributions in millimeter wave 3gpp new radio systems[END_REF], once this mapping is performed and the number of allocated PRB is known, the corresponding TBS can be retrieved from Table 7.1.7.2.1-1 in [START_REF] Gpp | Lte evolved universal terrestrial radio access (e-utra); physical layer procedures[END_REF]. However, even with the right TBS, checking only Equation 1 for loss discrimination can penalize short flows since long flows will keep increasing their window size as long as the base station send buffer is not filled. On the other hand, some buffering is necessary to accommodate rapid changes in transport block size and to compensate mismatch between arrival and sending rate at the base station. Therefore, in order to maintain fairness between different possible data flows of the same UE, it is necessary to make sure that the send queue allocated to the UE at the BS does not exceed the optimal threshold Q th . This threshold must be large enough in order to guarantee full link utilization in case of favorable radio conditions. For that reason, let S TBm be the maximum TBS under the current allocated PRBs (at CQI=15), the BS send queue size for a given UE must satisfy the following:

S queue ě Q th ě S TBm ˚NHARQ (2)
Enforcing Equations 1 and 2 guarantees optimal link utilization, lower RTT for short flows and accurate congestion detection in case of packet losses. In the subsequent section, we describe MELD, a LDA scheme implemented on top of picoquic that checks the two aforementioned conditions after collecting the required radio information.

B. Loss differentiation in MELD

In this section, we introduce MELD, a novel LTE-friendly LDA based on picoquic and the FlexRAN. At a basic level, MELD listens to RAN information through FlexRAN in order to decide whether a lost packet should be retransmitted silently or reported to the congestion controller. As illustrated in Figure 2, we use a local LTE environment based on Open Air Interface (OAI) and FlexRAN.

1) Design and Implementation: MELD is built on top of picoquic on the server side, the client does not require any modification. Similar to the model described in [START_REF] Sagar | Exposing radio network information in a MEC-in-NFV environment: the RNISaaS concept[END_REF], [START_REF] Foukas | FlexRAN: A Flexible and Programmable Platform for Software-Defined Radio Access Networks[END_REF], the FlexRAN controller gets real-time RAN statistics from the FlexRAN agent every millisecond via the control channel. The relevant RAN information is then retrieved by a Python process and published on an Advanced Message Queuing Protocol (AMQP) topic as illustrated in Figure 2. The picoquic server deployed at the MEC host then uses a separate thread to subscribe to the topic in order to receive real-time changes from FlexRAN agent. Basically, AMQP requires two main components to work at the server, namely a message broker and a publisher. The publisher in our case is our Python process that retrieves the relevant RAN data from the controller and the broker is a rabbitmq container that broadcasts the published message to the subscribed applications. Once the picoquic server receives the radio information (CQI, MCS, TBS, Txqueue length) via AMQP, it computes the TBS threshold (S TB ) and the queue threshold (Q th ) in case of packet loss(es). Then it decides whether it should notify the CCA or just retransmit the lost packet(s) silently. This process is actually enforced by modifying the picoquic loss notification logic. Note that S TB is the value of TBS guaranteeing the transmission of one transport layer PDU without interruption; an example mapping between CQI, MCS and TBS is given in Table II in the case of 25 allocated PRBs.

2) Overhead of FlexRAN notifications: In order to use all the available bandwidth for user traffic, we dedicate a separate control channel for FlexRAN. Our approach based on analysis of up-to-date radio information requires FlexRAN agent (collocated with the eNodeB) to report RAN statistics to the controller (in the MEC host) every TTI (i.e., every ms).

Authors in [START_REF] Foukas | FlexRAN: A Flexible and Programmable Platform for Software-Defined Radio Access Networks[END_REF] conclude that the network overhead introduced by such continuous agent-controller communication mode increases with the number of UEs and experiments show that it can reach up to 100 Mbps for 50 UEs.

3) MELD LDA: Our MELD loss discrimination algorithm is invoked at each packet loss event. As illustrated in Algorithm 1, TBS th and Q th are computed using the downlink CQI (dlcqi), the downlink TBS (dltbs), the length of the BS per UE send queue (txQueueLen) the number of allocated PRBs (nprb), the number of HARQ processes (nharq) and the size of the transport layer PDU (stpdu) downlink sending queue size (txQueueSize) collected via FlexRAN. In case of loss, the congestion controller is notified when TBS is less than TBS th (which could result from a low CQI or a decrease in the number of allocated PRBs) and when the sending queue at the BS (txQueue) exceeds Q th . The latter condition prevents large bufferbloat and guarantees fairness between short and long flows. In all other cases, the packet is silently retransmitted, i.e., with a high CQI value or/and sufficient PRBs.

V. EXPERIMENTATION AND RESULTS

To evaluate the performance of our approach, we rely on an edge delivery application based on MELD. Table I describes the characteristics of our experimentation setup on the R2lab wireless testbed. We generate controlled interference in the RAN using an Additive White Gaussian Noise (AWGN) generator that introduces 0.8% random packet loss [START_REF] Chen | Measuring cellular networks: Characterizing 3g, 4g, and path diversity[END_REF]. We analyze the introduced packet loss rate profile on continuous ICMP ping traffic sent at 560kbps, (10 runs of 120 seconds), see Figure 3. The loss distribution suggests that packets lost with this controlled interference are mostly due to fast variations of the SINR between CSI reports, which are known for hindering AMC performance [START_REF] Sassioui | Harq and amc: Friends or foes?[END_REF]. During all the following experiments, we use the same level of interference and evaluate the performance of a 20MB file download over the 15Mbps radio link.

We repeat each test 10 times in order to account for the variability of link capacity. We first evaluate the global goodput using a loss discrimination algorithm based only on TBS, as suggested by Equation 1; then we analyze the proposed MELD algorithm. Figures 456show the different test results with a 90% confidence interval. In this first experiment, we take the decision to notify lost packets to CCAs only based on the transport block size (MELD-DE). The mapping between CQI, MCS and TBS is performed using values from Table II We assume that the channel quality is very poor or the UE is not assigned enough resources when the selected MCS corresponds to a TBS less than S TB . Since N HARQ is equal to 8 and the maximum QUIC datagram size is set to 1440 Bytes, the optimal size of transport blocks (S TB ) must be greater or equal to 180 Bytes (1440 bits) in order to validate Equation 1. In other words, CCA is notified of the loss and congestion window reduction is applied whenever TBS<180 B. The test results with NewReno using the TBS threshold show a sig-nificant performance gain. As illustrated in Figure 4, a 131% increase in goodput is observed, mostly due to the fact that the congestion window is not halved in case of random losses. On the other hand, the same experimentation with Cubic does not double the goodput. We only observe 9% performance gain over the legacy version (see Figure 4). Since Cubic already uses an aggressive growth function, the use of LDA increases the link utilization to a near optimal value. The difference in download time can be observed in Figure 5. Results show that flows under MELD-DE have shorter duration because they exploit more bandwidth. However, regarding the RTT increase (see Figure 5), we can observe significant RTT increase mainly due to buffering. The large RTT increase implies that MELD-DE doesn't take queue length into account.

B. TBS and queue length-based loss discrimination

This experiment evaluates the MELD-ME algorithm, proposed in Section IV, in terms of average goodput and RTT increase. The results show for New Reno, over 80% increase in goodput (see Figure 4) when compared to legacy picoquic. As expected, taking queue length into account to prevent RTT increases negatively affects the global throughput. As illustrated in Figures 4 and6, MELD-ME prevents large RTT increase (bufferbloat) for NewReno and Cubic at the cost of slightly lower goodput. On the other hand, with Cubic, although a 8% increase is observed in the goodput, the measured RTTs are above legacy Cubic RTTs during the whole connection. Such a behavior was expected since Cubic growth function is more aggressive than NewReno Additive Increase Multiplicative Decrease (AIMD). As shown in the test results, for both CCAs, the RTT is kept under a lower value which was not the case with MELD-DE. This behavior confirms the efficiency of Equation 2 which allows MELD-ME to be fair to short flows even when the UE is in ideal radio conditions (i.e., with CQI=15).

As shown in the different results, MELD-DE outperforms MELD-ME in term of goodput but struggles to maintain a reasonable RTT increase for short flows. On the other hand, MELD-ME exhibits lower RTT increase and fairness at the cost of slightly lower performance.

VI. CONCLUSION

In this paper we demonstrate that certain information transmitted over LTE Radio Access Network, such as Channel Quality Indicator (CQI) and Transport Block Size (TBS) can be exploited as relevant congestion signals at the transport layer. To the best of our knowledge, our proposed MELD scheme is the first loss discrimination algorithm for LTE that exploits such information to proactively discriminate packet losses. Our performance evaluation using MELD-DE and MELD-ME LDAs show significant improvement for lossbased congestion controllers. MELD-DE is adapted for sheer download scenarios where RTT increase and fairness to short flows can be ignored. On the other hand MELD-ME can be used in mixed scenarios (i.e., when a UE is downloading short and long flows at the same time) since it improves the goodput while minimizing RTT increase. Our proposed algorithms are implemented as plugins integrated into picoquic. The code and explanation of all the necessary steps to reproduce our results can be retrieved at [START_REF] Diarra | MELD[END_REF]. We hope this paper paves the way for future work on leveraging MEC services to improve transport layer protocols performance in mobile networks. While the MELD approach has been proposed for LTE, we believe that it could also be exploited in 5G networks with potential minor changes.

Fig. 1 :

 1 Fig. 1: RAN latency introduced by HARQ RTT and processing times at eNB and UE for LTE-FDD.

Fig. 2 :

 2 Fig. 2: MELD experimentation setup.

Algorithm 1 : 3 T 4 QthÐ 6 N 13 N

 134613 MELD LDA logic Result: NotifyCCA 1 N otif yCCA Ð T RU E; 2 if Pktloss then BSth Ð ComputeT bsT hreshpdltbs, nharq, stpduq; ComputeQT hreshpnprb, dlcqi, dltbsq; 5 if (dltbs ěTBSth) && (txQueueLen ěQth) then otif yCCA Ð 0; /* Retransmit lost packets silently */

Fig. 3 :Fig. 4 :

 34 Fig. 3: Burst loss occurrences

Fig. 6 :

 6 Fig. 5: RTT for MELD-DE vs legacy QUIC

TABLE I :

 I OAI Experimentation setup characteristics.

	Parameters	Values
	LTE BW	5MHz
	# of PRBs	25
	E2E RTT	55ms
	L4 protocol	QUIC
	Max TBS	2292 Bytes
	Link Capac.	15 Mbps

TABLE II

 II

						: Measured
					CQI values and TBS for
					25 PRBs.
					CQI	MCS	TBS
					index	(Bytes)
					15	28	2292
					14	28	1980
					13	28	1764
					12	28	1572
					11	28	1239
	1	2	3 burst (#)	4	6

  which correspond to values reported by FlexRAN in our local setup.