SaT5G (761413) D5.5 March 2020

D5.2 / D5.5Testbed Data Centre Equipment Installed,

Connected and Functionally Tested and Validated /Validation of 5G Control and User Plane

Harmonisation – Validation Setups and Test Results

Topic ICT-07-2017

Project Title Satellite and Terrestrial Network for 5G

Project Number 761413

Project Acronym SaT5G

Contractual Delivery Date Internal

Actual Delivery Date 2020-03-10

Contributing WP WP5

Project Start Date 2017-06-01

Project Duration 30 months

Dissemination Level Public

Editor UOULU

Contributors UOULU, TNO

SaT5G (761413) D5.5 March 2020

Page 2 of 30

Contributors

Name Organisation Contributions include

Tahir Ali Raza UOULU UOULU part

Harri Saarnisaari (HS) UOULU UOULU part, editor

Djurica, M. TNO TNO part

Keith Briggs BT internal review

Document History

Version Date Modifications Source

0.1 20/12/2019 initial draft HS

0.2 20/02/2020 for internal review HS

1.0 10/03/2020 final version HS

SaT5G (761413) D5.5 March 2020

Page 3 of 30

Table of Contents

List of Figures .................................................................................................................................... 4List of Tables ..................................................................................................................................... 5List of Acronyms ................................................................................................................................ 6Executive Summary ........................................................................................................................... 71 Introduction ................................................................................................................................ 82 Final UOULU testbed architecture............................................................................................... 9

2.1 Satellite access implementation ........................................................................................ 102.2 Backhaul network implementation .................................................................................... 16

3 Performance measurements ..................................................................................................... 184 Demonstration events ............................................................................................................... 21

4.1 MWC2019 ........................................................................................................................ 214.2 EuCNC 2019 .................................................................................................................... 214.3 Industry Day ..................................................................................................................... 22

5 Discussion of trial results .......................................................................................................... 236 Conclusions and recommendations .......................................................................................... 247 TNO testbed ............................................................................................................................. 25

7.1 DASH and DANE ............................................................................................................. 257.2 Traffic splitting mechanism ............................................................................................... 267.3 DANE architecture............................................................................................................ 267.4 TNO demo architecture .................................................................................................... 277.5 Demonstrations and results .............................................................................................. 29

8 References ............................................................................................................................... 30

SaT5G (761413) D5.5 March 2020

Page 4 of 30

List of Figures

Figure 1: UOULU testbed system architecture. .................................................................................. 9Figure 2: Architecture of satellite access network. The left-hand side at the lower row shows the radiochannel emulation implemented with two URSP radios and the right-hand size shows the EPC. ...... 11Figure 3: LTE UE attach procedure. ................................................................................................. 13Figure 4: Standard RACH process. .................................................................................................. 14Figure 5: Modified RACH process. ................................................................................................... 15Figure 6: Open air interface UE using HP Zbook & USRP. ............................................................... 16Figure 7: Nokia picocell eNB connected through satellite network. ................................................... 17Figure 8: CQI reporting and MCS assignment. ................................................................................. 18Figure 9. MWC demonstration setup. ............................................................................................... 21Figure 10: EuCNC 2019 demonstration architecture. ....................................................................... 22Figure 11: UOULU industry day setup. ............................................................................................. 22Figure 12: DANE in a multilink scenario. .......................................................................................... 26Figure 13: Pre-fetching anticipated segments. ................................................................................. 26Figure 14: DANE architecture. ......................................................................................................... 27Figure 15: TNO demonstrator setup. ................................................................................................ 28Figure 16: TNO demonstrator setup implementation ........................................................................ 29

SaT5G (761413) D5.5 March 2020

Page 5 of 30

List of Tables

Table 1: Identified problems and solutions. ...................................................................................... 11Table 2: TA command index value corresponding to link distance and required bits. ........................ 15Table 3: Terrestrial UE measured throughput and channel parameters. ........................................... 19Table 4: Satellite UE measured throughput and channel parameters................................................ 19

SaT5G (761413) D5.5 March 2020

Page 6 of 30

List of AcronymsAPI application interfaceCDN Content Delivery NetworkDANE DASH Aware Network ElementDASH Dynamic Adaptive Streaming over HTTPeNB LTE base stationEuCNC European Conference on Networks and CommunicationsFDD frequency division duplexgNB 5G base stationHARQ Hybrid automatic repeat requestHTTP Hypertext Transfer ProtocolLTE Long term evolutionMCS modulation and coding schemeMEC multi access edge computingDMP Media Presentation DescriptionMWC Mobile World CongressNR (5G) New RadioNTN Non terrestrial networkOAI Open air interfacePRACH physical random access channelRACH random access channelRAN radio access networkRAR random access responseSAND Server And Network enabled DASHSaT5G Satellite and Terrestrial Network for 5GSNR signal-to-noise ratioSDR software defined radioTA Timing AdvanceTNO NEDERLANDSE ORGANISATIE VOOR TOEGEPAST

NATUURWETENSCHAPPELIJK ONDERZOEK TNO, SaT5Gresearch partner

UE User EquipmentUPF user plane functionUoS University of Surrey, SaT5G research partnerUSRP Universal software radio peripheral (a software radio)WP Work Package5GIC 5G Innovation Centre (in UoS)5GTN 5G Test Network (in UOULU)

SaT5G (761413) D5.5 March 2020

Page 7 of 30

Executive SummaryA major part of the SaT5G project is the main demonstrations planned in the WP5, with contributionsfrom all project partners. Such presentations are focused on the WP4 studies, and the use casesidentified in WP2. From the integrated terrestrial satcom perspective, demonstrations in WP5 includeearly proof of concepts for 3GPP studies. The SaT5G demos provide insight into how satellitetechnology can be integrated in terrestrial networks, and can provide examples of use cases.

Integration can occur at two levels: either using existing and future satellite systems, or such thatsatellites adopt 5G NR signals. Both aspects are demonstrated in SaT5G.

WP5.5 contained two demonstrations, one by UOULU and one by TNO. The UOULU demonstrationbelongs to the SaT5G research pillar IV "Harmonisation of Satcom with 5G control and user plane",which was researched in WP4.4. The research outcome was that some changes are needed for 5G NRbefore it can be applied in satellite systems; that is, in full integration of satcom and 5G. Selectedfeatures were demonstrated in WP5.5. TNO demonstration is related to research pillar VI “Caching andmulticast for content and VNF distribution”, for which studies were done in WP4.6, and selected featuresdemonstrated in WP5.5. This deliverable presents these achievements. It combines two deliverables inone (D5.2 and D5.5), because in practice it turned out that D5.5 required D5.2 as an integral step, andit made sense to combine them. Two companion deliverables (D5.2/D5.3 and D5.2/D5.4) describe thepartner WP5 testbeds at University of Surrey and at Zodiac Inflight Innovations in Munich. All three ofthese deliverables feed into D5.6 that presents the testbed results and gives recommendations.

The UOULU demonstration actually covered both direct user access and backhaul use cases. Its corepart was the satellite access system that consist of i) NTN terminal, ii) base station, and iii) core network.In WP4.4 it was observed that uplink random access process needs modification before 5G NR can beapplied to satellite links which have a long delay, more than 1 ms. These changes were implemented,and their success measured. An emulated satellite link was used. This core part was then connectedto existing 5G Test Network in UOULU to show the backhaul case. Public demonstrations were held inMWC19, EuCNC19 and in the Industry Day of SaT5G project. In the latter, the core part was connectedto UoS 5GIC Testbed in a backhaul use case.

The TNO demonstration was related to caching using parallel backhauls, one being a satelliteconnection. Emulated satellite channel was used here too. The benefits were shown of usingsophisticated route-splitting algorithms to improve end-user experience at an edge equipped with multi-access edge computing (MEC) and virtualized user plane functions (UPFs). The methods applied wereDynamic Adaptive Streaming over HTTP (DASH) and DASH Aware Network Elements (DANEs). Publicdemonstrations were held at EuCNC19, at the Satcom Workshop organized by TNO in 2019, and inthe Industry Day of SaT5G project.

SaT5G (761413) D5.5 March 2020

Page 8 of 30

1 IntroductionThis deliverable summarizes two testbeds of Work Package 5.5 (WP5.5). One is “5G over satellite link”from UOULU, and the other is “Traffic splitting between terrestrial and satellite in caching”, by TNO. Thereason for two testbeds has a history. The aim was to have a common setup where TNO’s testbedcould be included into UOULU’s testbed or use it as satellite data channel. That would have created astronger demonstration. However, during discussions at the beginning of the project, it was observedthat the parties are using different building blocks that cannot be combined. In addition, limitedresources did not allow adopting similar blocks and at the end, it was decided to go on with two separatetestbeds.

In the SaT5G project, the aim was to have both research activities and demonstrations around researchpillars. This means that the research part in WP4 resulted in outcomes to demonstrations in WP5. TheUOULU demonstration belongs to research pillar IV "Harmonisation of Satcom with 5G control and userplane" whose research was in WP4.4. The outcome for the research was that changes are needed for5G NR before it can be applied in satellite systems, that is, in full integration of satcom and 5G. Selectedfeatures were demonstrated in WP5.5. TNO demonstration is related to research pillar VI “Caching andmulticast for content and VNF distribution”, for which studies were done in WP4.6, and selected featuresdemonstrated in WP5.5.

The remainder of this deliverable describes the work. Section 2-6 considers the UOULU demonstration,and Section 7 the TNO demonstration. In Section 2 we present the final architecture of the testbed,indicating how it has implemented the chosen modifications identified in the WP4.4. Section 3 outlinesthe tests and measurements carried out over the testbeds to validate the results and outcomes of thetestbeds. A brief and concise overview of the UOULU testbed’s public demonstration that took placeduring the project is detailed in Section 4. Section 5 discusses the results of the tests conducted andrecommendations for future developments and Section 6 concludes UOULU part. Section 7 introducesTNO demonstration principles, set-up, public demonstrations and main results.

This deliverable combines two deliverables in one (D5.2 and D5.5), because in practice it turned outthat D5.5 required D5.2 as an integral step, and it made sense to combine them. Although D5.2 wasoriginally listed as a ‘Confidential’ deliverable, upon review we decided that no sensitive material wasinvolved, and so the combined document is categorised as ‘Public’.

SaT5G (761413) D5.5 March 2020

Page 9 of 30

2 Final UOULU testbed architectureSaT5G has studied the integration of satellite and terrestrial network, in order to extend 5G services inunderserved areas, as well as compliment the terrestrial network in overloaded areas. Study Pillar IVfocuses on the testbed "Harmonizing satcom with 5G Control and User Plane". Its goal is to study how5G NR can be used in satellite links. Studies in WP4.4 showed that there some elements that have tobe modified in the 5G NR standard before NR can be applied for the satellite links. The uplink randomaccess process was selected as an item to be demonstrated.

The UOULU testbed inside SaT5G addresses two uses cases: i) direct user access and ii) indirectaccess where satellite connection provides a backhaul link for a terrestrial system. Figure 1 shows thearchitecture of the UOULU testbed.

Figure 1: UOULU testbed system architecture.

The testbed is made up of two parts. The core part (the green area in the figure) is a separate satellitesystem based on 5G NR, where the modifications described in WP4.4 related to SaT5G are made. Ifthis is used as a standalone system, it demonstrates the use case with direct user access. If this corepart is connected to existing 5G test network (5GTN) within UOOLU (yellow part), it demonstrates theindirect access use case.

The UOULU testbed is based on an existing 5GTN testbed [1]. Indeed, the SaT5G testbed is anadditional block to the 5GTN that can be used also after the project to emulate satellite access. The5GTN consists of real user devices, IoT devices, macro (outdoor) and small (indoor) base stations aswell as a 5G core network, LTE core network, and modifiable core network based on OpenEPC core.The 5GTN is a stand-alone network that provides its users with a state-of-the-art test platform, wherevarious parties can join in for evaluating their 5G prototypes and designs, e.g. in the application area.The 5GTN is both on and around the university campus as an outdoor extension. In addition, parts areavailable in Oulu University Hospital to check 5G potential smart hospital applications and 5G in factory4.0 design is tested in a Nokia plant. Furthermore, other additional 5G test sites are all interconnectedacross Finland. There are tens of user devices (with hundreds being a goal) that are used in certainareas of the campus to monitor and measure network performance as well as a large IoT sensorpopulation. 5GTN has grown quickly and is now integrated with the 5G-NR (non-standalone version)and the 5G core network from Nokia.

In the core part, the NTN terminal corresponds to a UE in the terrestrial set-up and the NTN gNBcorresponds a gNB, respectively. The satellite core in Figure 1 is needed to manage the NTN terminalconnection to the NTN gNB. In real life, the satellite core and the 5G core could be same (as was donein the testbed), but this naturally depends on who is operating satellite and terrestrial parts and cancores be combined. The satellite link was emulated using URSP radios. The backhaul case was themain case, and consequently the single path channel was emulated since with highly directionalantennas the satellite channel is a single path channel.

The core part was implemented using Open Air Interface (OAI) software and USRP radios. Initially, OAILTE software was used since 5G NR was not available. In particular, the frequency division duplex(FDD) mode was used since that is used in satellite systems. The purpose was to update to 5G NRonce it will be available. Later on, it appeared that 5G NR software will not be available during theproject and, correspondingly, the testbed used LTE at all times.

SaT5G (761413) D5.5 March 2020

Page 10 of 30

Since the unavailability of 5G NR software was identified as a risk, it was decided that of many changesfor 5G NR observed in WP4.4, we should select those that are similar in LTE and 5G NR. In this waythe demonstration results can be seen to be valid also for 5G NR.

Further details will be given later, but here we mention briefly the aspects that have been shown. It wasfound in WP4.4 that the uplink random access process has to be modified before the satellite links canbe applied to 5G NR. The changes considered here are related to the guard interval after a random-access signal (PRACH), measurement and transmission of a timing advance value, and timer valuesassociated with the operation.

We demonstrated that delays which reach the maximum LTE cell size (100 km) cannot be connectedwithout adjustments. Indeed, this is the minimum required delay for satellite channel emulator for ademonstrator like this. It was then demonstrated that it is possible with the modifications. It has alsobeen shown that this modified device can be used for the terrestrial network as a backhaul. In addition,the terrestrial and satellite version (that is, with and without the modification) throughput was measuredunder equal conditions. Since the demonstration was about MAC layer problems, satellite channelnonlinearities were not included in the emulated satellite channel. These nonlinearity effects are studiedin WP4.4, where physical layer simulations are handled.

In what follows more details are given followed by results in separate sections.

2.1 Satellite access implementationThe satellite network of UOULU Testbed shown in Figure 2 consists of a satellite UE or NTN terminal,a base station or NTN gNB’ associated with a satellite or a ground station and a satellite core. The NTNterminal connects to the NTN gNB through an emulated satellite link. The emulated satellite connectionis implemented using the Python API of GNU radio and two USRP software defined radios (SDRs). Theterminal and gNB’ is based on OAI, whereas the core is the modifiable version of OpenEPC. In thebackhaul scenario, the satellite network is used as a plug-and-play system, which is installed betweenthe 5GTN gNB and 5GTN core network. In other words, the traffic of the gNB is routed through the userplane of the satellite access network. The other parts of the satellite core are needed to allow the NTNterminal to connect to the NTN gNB.

SaT5G (761413) D5.5 March 2020

Page 11 of 30

Figure 2: Architecture of satellite access network. The left-hand side at the lower row shows the radiochannel emulation implemented with two URSP radios and the right-hand size shows the EPC.

The testbed's objective is to demonstrate some bottleneck solutions found in the WP4.4 report. Error!Reference source not found. lists the defined problems that may arise as a result of very high orvarying delays in propagation between the consumer equipment and the satellite [2].

Table 1: Identified problems and solutions.

Process Problem SolutionRACH PROCESS The unpredictable latency

of the contention-basedrandom access procedurecan be significant if multipleNTN terminals havecollided due to the selectionof the same preamble.

The contention-free randomaccess procedure can be adopted(for fixed NTN terminals,e.g:gNBs), where each NTNterminal is allocated a dedicatedpreamble.

Guard interval Max cell size: 300 km.Vertical distance betweenthe transmitter and receiverassumed negligible.Required guard intervalmuch larger than themaximum guard intervaldesigned for 5 NR.

1.position information (by GNSS)of all NTN terminal available atthe SAT. Guard interval will beobtained from the differencebetween the NTN terminal withthe shortest link distance to theNTN terminal with the longest linkdistance.

SaT5G (761413) D5.5 March 2020

Page 12 of 30

2.Obtain a minimum commondelay value. Guard interval will bederived from the differentialdistance or the beam size in thecase of multiple spot beams.3. Use “always on” RACHconfiguration

PRACH configuration(formats and randomaccess opportunities)

Frequency of initiating theRACH process

Due to the long duration tocomplete a RACH process,frequency of initiation cansignificantly affectperformance. NTN terminaldisconnects anytime in idlemode.

1.Extend inactivity time beforeNTN terminal switches to idlemode.2.Use network traffic pattern topredict how often an NTNterminal switches to idle mode.3.NTN terminal always inconnected mode until a new NTNterminal request initial access.Hence, selection of NTNterminals to switch to idle modewill be based on length ofinactivity time.

RACH Timers andParameters:ra-ResponseWindow Max. value: 10 ms. The

time period for the ra-response window to beginis less than the propagationdelay experienced.

Propagation delay/minimumcommon delay should be takeninto account.

ra-ContentionResolutionTimer

Max. value: 64 ms Propagation delay/minimumcommon delay should be takeninto account.

TA command index rangein RAR

Max TA index value is3846, which corresponds to300km link distance at15kHz sub carrier spacing.

1.TA index range can beincreased. However, additionalbits will be required.2.Minimum common delay can betaken into account, such thatdifferential distance is used inderiving the max. TA values.3. Divide the main beam intovirtual beams with max. size ofeach virtual beam not greaterthan 300 km.

TA command index rangein MAC CETA Update timer Minimum value not suitable

to cope with the largepropagation delay variationthat can occur in LEO/MEOSAT.

1.Reduce the timeAlignmentTimerto accommodate the large orbitspeed of SAT.2.Update of the TA can be doneat the NTN terminal using theprior knowledge of the orbit speedand direction of the SAT.

RAR field length RAR field too small toaccommodate satellite link

Increase RAR size on the octetbasis to support SAT linkdistance.

SaT5G (761413) D5.5 March 2020

Page 13 of 30

distances. Octet alignmentshould be preserved.

Figure 3 indicates the steps involved in an LTE UE's attachment procedure that is very similar in 5GNR. In the UE's connection method, both LTE UE and NR UE have the same random access operation[3].

Figure 3: LTE UE attach procedure.

Depending on the channel bandwidth under consideration, the emulated satellite connection addsadditional latency in the range of tens of milliseconds. As stipulated in the 3GPP standard, the maximumpermissible distance between the UE and RAN is 300 km corresponding to a maximum delay of 1 ms.However, in the case of satellite RAN, the one-way delay in propagation can vary from 2 ms to 260 ms.Due to the large delay in propagation, the random access protocol fails when a standard UE attemptsto communicate via satellite link.

SaT5G (761413) D5.5 March 2020

Page 14 of 30

Figure 4: Standard RACH process.

The guard interval, cyclic prefix, TA and other timers are not built with very high propagation delay inmind. Figure 4 shows the RACH mechanism including required messages and timers. The satelliteconnection emulated in UOULU testbed raises the propagation delay between UE and eNB toapproximately 14 ms. Therefore, the UE fails to link to eNB with the satellite connection as the random-access answer never reaches UE in time, and the UE begins to retransmit the preamble over and overagain. In order to overcome this, we changed the OAI UE and OAI eNB to cope with the up to 14 mslong delay. The adjustment included changing the value of TA in the RAR, the duration of the RARresponse window, and the timer for MAC dispute resolution. We used the preamble configuration index14 for the guard interval, which gave UE the freedom to transmit PRACH in any subframe or frame.Figure 5 shows the updated RACH cycle.

SaT5G (761413) D5.5 March 2020

Page 15 of 30

Figure 5: Modified RACH process.

Figure 5 shows closer look at points which were demonstrated. In the process shown in Figure 5, wemodified the timing advance (TA) value calculation and transmission. The TA value is the first timingcorrection which is sent by the network to the UE for the uplink to be synchronized. The TA value isestimated from the distance between the UE and the eNB. The TA value is measured periodically andupdated if the UE is moving. The TA value estimation performed initially is based on the PRACHtransmission by the UE and the TA is transmitted in the random access response (RAR) to UE. In RAR,there are 12 bits (in 5G) reserved which are used for the transmission of the TA, which corresponds toa value range of 0 to 3846 that can be transmitted to the UE with step size of 1. The maximum value ofthe TA implies the maximum distance that the UE can receive the RAR, but for satellite case theestimated value is much higher. To transmit the much higher value, additional bits are assigned in theRAR depending on the propagation delay. Table 2 is derived from the WP4 document [2], which liststhe additional bits needed for the transmission of TA for different satellite cases.

Table 2: TA command index value corresponding to link distance and required bits.

satellite nadir (km) NTN: 100 (km) TA field length(required bits)

GEO 35786 40586 519501 19MEO 10000 14018 179444 18LEO 1500 3647 46695 16LEO 600 1932 24733 15

In UOULU testbed, delay is approximately 14 ms. For this reason, the MAC CE bits register in RARwas modified to allocate 16 bits for the TA transmission. Furthermore, the UE MAC layer was configuredto adjust its transmission timing according to the extended TA in RAR.

The RAR window timer is a time window configured in the UE, which is crucial during the random accessprocess. The usual maximum RAR window size is 12 ms and it implies that after the PRACHtransmission by the UE, the UE waits only for 12 ms to receive a reply from the network. If this windowexpires before receiving any reply, the UE just restarts the random access process and rejects anymessage received afterwards. The RAR window was extended in UOULU Testbed to 60 ms to copewith the higher delay and establish connectivity over the satellite link.

For the random access process to be successful and avoid unnecessary restart, the MAC contentionresolution timer also needs to be modified. This timer is activated when UE transmits msg3 afterreceiving a RAR response. The maximum value for this timer as described in the standard can be upto 64 ms as during this time the network determines if the same PRACH preamble is not been used bymore than one UE to access the network. Therefore, this value has to be large enough to avoid

SaT5G (761413) D5.5 March 2020

Page 16 of 30

preamble collisions. For the UOULU testbed, we increased to value to 128 ms and verified the randomaccess completion.

2.2 Backhaul network implementationAs discussed in the architecture of the testbed, the UOULU testbed also shows NR in a backhaul modeover the satellite link. Here, the satellite access network is used as a backhaul to UOULU’s 5 G testnetwork (5GTN). In this part of the testbed, a commercial Nokia base station is connected via theemulated satellite access network to the core network of the 5GTN. A safe end-to-end VPN tunnelbetween the NTN terminal and the core of the 5GTN network is designed. Furthermore, the commercialbase station is connected to commercial smartphones using the 5GTN sim cards.

Figure 6: Open air interface UE using HP Zbook & USRP.

The NTN terminal is implemented using the open air interface UE application and USRP devicedepicted in the Figure 6. The Nokia base station is connected using the GigE ethernet ports on the basestation and the PC running the NTN terminal application. A L2TP tunnel is created between MME of the5GTN core network and NTN terminal to provide a secure connection and route for the s1 traffic of thebase station. The base station is a Nokia picocell eNB operating at band 7 and shown in Figure 7. TheopenEPC is used as a core network of 5GTN for this demonstration.

SaT5G (761413) D5.5 March 2020

Page 17 of 30

Figure 7: Nokia picocell eNB connected through satellite network.

SaT5G (761413) D5.5 March 2020

Page 18 of 30

3 Performance measurementsWe performed throughput and network latency tests to verify the performance of UOULU testbed setup.We modified the resource allocation process in the OAI eNB and UE in order to get a fair comparisonbetween the terrestrial setup and the NTN setup so that the data transmission in the uplink and downlinkuses the same resources for both the satellite and terrestrial case. In the satellite case the introducedmodifications were used along with satellite delay whereas in the terrestrial case the unmodified systemwas used without satellite delay. In addition, for both cases, the channel parameters and the pathbudget were made identical to create similar operating environment for both cases.

Figure 8: CQI reporting and MCS assignment.

Figure 8 illustrates the standard procedure used to adapt modulation and coding both downlink anduplink according to the standard. In order to have a fair comparison between the terrestrial and satellitemode in the testbed, the modulation and coding should be the same. Slight differences in received SNRmay cause a change in used modulation and/or coding scheme. Therefore, we had to bypass thestandard process and force the system use a certain modulation and coding irrespective of channelquality. This was implemented so that independent of UE’s channel quality information (CQI) the OAIeNB always set the desired modulation and coding scheme (MCS).

Another requirement to make conditions fair, was to set equal received power (SNR). Since the satellitedelay was implemented using delay properties of URSP radio , there was additional attenuation in thesatellite mode. Correspondingly, additional attenuation had to be added in the terrestrial mode. Thetotal attenuation had some consequences to the testbed flexibility. Since the maximum TX power ofused USRP radios was quite low, the links ended to have a rather low received power. The low receivedmaximum power limited the capability of varying modulation and coding scheme in the tests, that is,higher order modulations could not be used. We tried to overcome this situation by using other newerUSRP radios, but it appeared that the OAI code with them was not very stable. We succeeded in makingthe needed modifications and connect UE and eNB, but the connection breaks were so frequent thatwe were not able to measure performance as with the originally used USRP radios.

The actual channel values, used modulation and results are reported next. Since the uplink RACHprocess was modified, the uplink capacity (the number of resource blocks) was changed in order to seewhether modified RACH has higher impact at lower available bandwidth. The maximum channelbandwidth with the used USRP is 20 MHz, equivalent to 100 resource blocks. This was used in thedownlink. In the uplink, 50, 25 or 10 resource blocks were allocated to the UE/NTN terminal.

The results for the terrestrial case are shown in Table 3 and in the satellite case in Table 4. The uplinkthroughput difference between the terrestrial case and the satellite are small. The satellite uplinkthroughput is 88%, 90% and 88% of that of the terrestrial one for the 50, 25 and 10 resource blocks,respectively. Obviously, the available uplink bandwidth does not affect the results. One reason for thethroughput reduction in the satellite case is that more resources are reserved for the random access

SaT5G (761413) D5.5 March 2020

Page 19 of 30

process which has frequent reserved slots in the frame structure. Another, more significant reason isthat also HARQ process is affected by long satellite delay. Due to the low available SNR we were notable to test HARQ on/off feature as originally planned, since without HARQ the link became veryunstable (too many packet errors).

Table 3: Terrestrial UE measured throughput and channel parameters.

TerrestrialParameterUplink N_RB 50 25 10RSSI [dBm] -80.4 -80.8 -80.8rsrp [dBm] -101.8 -102.6 -102.64Transmission mode 1 1 1Pathloss PL 95 95 95CQI 10 10 10Qm 2 2 2Downlink N_PRB 100 100 100I_TBS Uplink 10 10 10I_TBS Downlink 9 9 9TBS downlink=17568 15840 15840 15840TBS uplink=8760 8760 4392 1736

MeasurementsDownlink [Mbps] 12.1 12.1 12.1Uplink [Mbps] 4.82 3.52 1.12

Theoretical maximum

Downplink [Mbps] 17.568 17.568 17.568Uplink [Mbps] 8.760 4.392 1.736

(=TBS*1000)

Table 4: Satellite UE measured throughput and channel parameters.

SatelliteParameterUplink N_RB 50 25 10RSSI [dBm] -81.6 -81.4 -81.7rsrp [dBm] -104.4 -103.8 -104.9Transmission mode 1 1 1Pathloss PL 96 96 96CQI 10 10 10Qm 2 2 2Downlink N_PRB 100 100 100I_TBS Uplink 10 10 10I_TBS Downlink 9 9 9TBS downlink=17568 15840 15840 15840

SaT5G (761413) D5.5 March 2020

Page 20 of 30

TBS uplink=8760 8760 4392 1736

MeasurementsDownlink [Mbps] 11.84 11.84 11.84Uplink [Mbps] 4.24 3.18 0.98

Theoretical maximumDownplink [Mbps] 17.568 17.568 17.568

Uplink [Mbps] 8.760 4.392 1.736(=TBS*1000)

SaT5G (761413) D5.5 March 2020

Page 21 of 30

4 Demonstration eventsThe testbed was introduced at several scientific conferences, and the industry day coordinated by theproject itself. The satellite access network portion of the testbed that was developed first was testedduring the early demonstrations, which demonstrated the direct user access through satellite links. Latertestbed demonstration included both parts. These demonstrations are introduced in the followingsections.

4.1 MWC2019The demonstration in MWC2019 was a video presentation shown in the 5GPP booth among videosfrom other projects. The demonstration included the satellite access part shown in Figure 9 as areminder. The modifications needed for the uplink random access process were explained andconnectivity was used to point that modifications allowed successful connection over satellite delays.

Figure 9. MWC demonstration setup.

4.2 EuCNC 2019

At the EuCNC in June 2019, UOULU demonstrated the backhaul and direct access connectivity overthe satellite link illustrated in Figure 10 . The demonstration at the EuCNC was a video demonstrationshowing the testbed architecture, accomplished targets and the results of the trials. The demonstrationshowcased the modified random access process for the satellite RAN as in MWC19 and that themodified satellite access can be used as a backhaul for a terrestrial system that was 5GTN in UOULU.

SaT5G (761413) D5.5 March 2020

Page 22 of 30

Figure 10: EuCNC 2019 demonstration architecture.

4.3 Industry DayAt the Industry Day in Surrey on 27 November 2019, the EuCNC19 demo was repeated with a fewmodifications. Firstly, it was a live demo since the satellite access network equipment was present atthe site. Secondly, 5GIC at UoS was used as a terrestrial system for which the satellite access provideda backhaul as illustrated in Figure 11.

Figure 11: UOULU industry day setup.

SaT5G (761413) D5.5 March 2020

Page 23 of 30

5 Discussion of trial results

The UOULU testbed analysed the satellite connectivity in the direct access and backhaul use cases.The testbed allowed researching on how the satellite link would compare to the terrestrial connection if5G NR were applied over it. The UOULU tests clearly show that a longer propagation delay for uplinkand downlink does not result in a significant degradation to the downlink and uplink data speeds overthe satellite links for the UE connectivity. Compared to the terrestrial setup connectivity, we find that themajor drawback of longer delay is associated with the retransmission of the physical layer's erroneousdata. Various defences were proposed and analysed using literature and models to counter thedeterioration of HARQ.

The measurement studies continue to show that it is possible to achieve spectral efficiency which rivalsthe efficiency achieved over satellite connection, by making slight changes in the scheduling processto delegate resources in both the uplink and downlink for satellite connection. The eNB MAC scheduleris responsible for assigning downlink and uplink services as well as advising the UE. Using a hybridscheduling algorithm capable of identifying satellite or terrestrial links could more effectively distributeavailable resources and provide better user experience.

Measurement tests with higher order modulations over highly lossy channels show that higher ordermodulation and/or low coding rates could achieve higher spectral efficiency compared to higher MCSfor a highly loss channel rather than using higher order modulation and high coding rates. The SNRmust be high at higher MCS to ensure stable interconnectivity and communication. Based on the CQIreadings, the MAC scheduler determines the MCS which is regularly calculated and recorded. Thisscheduling algorithm has been highly optimized for terrestrial connections but in order to achieve higherefficiency the scheduler needs to be reconsidered and re-adjusted for the satellite link.

The UOULU tests also indicate that the UE communication setup over the satellite link is longer for thesatellite link. This is due to the increase in timer limits designed between UE and eNB for thetransmission of request responses. Note that most of the regular calibrated timers already have theupper limit that is adequate to account for the very high delay in propagation (> 250 ms) experiencedby very high altitude geostationary (GEO) satellites.

SaT5G (761413) D5.5 March 2020

Page 24 of 30

6 Conclusions and recommendationsThe UOULU testbed studied the MAC layer of the NR protocol stack and identified the modificationswhich need to be made before 5G NR can be used over the satellite links. The MAC layer modificationssuggested are for overcoming the problems introduced by the large propagation delay of the satellitelinks. Results from the demonstrator show that these modifications can be easily applied to the existingprotocol stack defined in 3GPP. The modifications demonstrated by the UOULU testbed will allow theNR connectivity over the satellite links without altering the performance of NR over the terrestrial link.What this means is that it is possible to have hybrid connectivity for NR over the satellite and terrestriallink without disrupting any performance metric of NR over the terrestrial link.

The UOULU testbed focused on the MAC layer of the NR stack and all the claims and recommendationsare made just based on the trials conducted for the MAC layer modifications. On the other hand, WP4.4details the work which needs to be done with respect to the entire protocol stack and suggestmodifications in other layers of the NR stack as well. These need to be studied farther and developedon more test platforms to have a better understanding, and to push both satellite and terrestrial networkoperators towards developing an integrated satellite terrestrial network.

For the backhaul use case, satellites offer a very promising role in extending the services of 5G toremote and underserved places as well, since they can complement existing communicationsinfrastructure by providing capacity in crowded areas. Also, the backhaul use case offers more flexibilityand less problems compared to the direct access use case. Therefore, an integration scenario withsatellites as relay nodes for backhaul of the NR offers a convenient approach towards creating a hybridextended communication network.

SaT5G (761413) D5.5 March 2020

Page 25 of 30

7 TNO testbedWith a move to triple-play provision of services to end-users, most content is provided to end-users byexisting HTTP web server infrastructure, which is also used for delivery of other WWW content. Thishas simplified service provisiion to devices such as TV set-top boxes, computers, smartphones, and soon. MPEG-DASH or commonly called just DASH is a standardized protocol that is used for high qualitystreaming of media content over the Internet delivered from conventional HTTP web servers. It usesTCP as the transport protocol. However, MPEG-DASH suffers from performance problems whenmultiple clients are streaming on shared network links, as they are not aware of the status of the sharedlinks. DASH Assisting Network Elements (DANEs) can be used to optimize bottlenecks in network linksand improve DASH streaming performance. DANE is aware of DASH traffic on the network link, andsplits available network resources between DASH players and other traffic, thereby improvingconditions for streaming content. Local storing of popular content in MEC nodes is a way to decreaseload on the network and backhaul links. Selection of content is based on criteria specified by the contentprovider, such as popularity or expected demand.

7.1 DASH and DANEDynamic Adaptive Streaming over HTTP (DASH) is a technology for delivering video content over theInternet. With DASH, a video file is encoded in multiple bitrates and resolutions, and then split intosegments, where a typical segment size is between one and ten seconds. The DASH segments,together with a Media Presentation Description (MDP) which describes the available videorepresentations and the location of the segments, is distributed using HTTP servers, potentially in aContent Delivery Network (CDN).

Because DASH is transferred via TCP, which expects acknowledgement (ACKs) of received packets.When the network introduces larger latency, as it is case with satellite networks, DASH will wait longerfor ACK of received packets, and then draw the conclusion that the link capacity is smaller. And in thecase of DASH which has multiple available versions of the same content in multiple resolutions andbitrates, it will then send to end-user content in lower bitrate and lower resolution.

It is possible to enhance the delivery of DASH by using Server and network assisted DASH (SAND).SAND introduces the concept of DASH Aware Network Elements (DANEs) and elements that haveawareness of DASH-formatted objects (for example, MPDs and DASH segments). DANE is intendedto prioritize, parse, or even modify such objects. SAND-enabled DASH clients exchange messages withDANEs to enhance the reception and delivery of DASH content. DANEs that are in the content deliverypath and have the ability to pre-fetch content are known as caching DANEs.

Section 4.1 of deliverable D4.6 presented the workings of SAND (Server And Network enabled DASH),and uses the following messages to identify state of link

· QoSInformation – This message allows a DANE to inform DASH clients about the availableQoS information (for example, the guaranteed and maximum bitrate between the DANE andthe DASH client). DASH clients can take this information into account when requestingsegments.

· Throughput – This messages allows a DASH client to have knowledge about throughputcharacteristics and guarantees on the delivery path from DANE to DASH client.

· AnticipatedRequests – This message allows a DASH client to announce to a DANE whichsegments it is interested in (that is, which segment the DASH client is likely to request soon).

· AcceptedAlternatives – This message allows a DASH client to inform a caching DANE whenthey request a DASH segment that het are willing to accept other (alternative) segments.

· ResourceStatus – This message allows a caching DANE to inform a DASH client aboutsegment availability and caching status of the segments.

· DeliveredAlternative – This message allows a DANE to inform a DASH client that is deliversan alternative segment rather than the requested segment. This message is a response to theAcceptedAlternatives message from the DASH client.

· MaxRTT – This message allows DASH clients describe the maximum time of the request, fromwhen the request was issued until the request needs to be completely available at the DASHclient.

SaT5G (761413) D5.5 March 2020

Page 26 of 30

A caching DANE can be highly effective when deployed at the edge of a network. Multi-access EdgeComputing (MEC) offers content providers this service, by providing computing resources at the edgeof the network. The MEC environment potentially offers low-latency and high bandwidth network accessbetween the DASH clients and caching DANEs.

TNO demonstrated a caching DANE which is deployed at the edge of a network which has a multilinkconnection to the 5G core network illustrated in Figure 12.

Figure 12: DANE in a multilink scenario.

7.2 Traffic splitting mechanismThe DANE splits traffic between the different network links on the basis of segment requests. Thismeans that a full segment is transported using one network link, but multiple segments may berequested in parallel. To use multiple network links, the DANE may pre-fetch anticipated segmentsusing a second network link, which happens in parallel while delivering the requested segments. Anexample of splitting traffic based on segment requests and anticipated segments is given in Figure 13

Figure 13: Pre-fetching anticipated segments.

With pre-fetching in the DANE, it is likely that a DASH client requests a segment that has already beenpre-fetched (that is, a cached segment). In this case, the DANE can directly serve the cached segmentto the DASH client. The DANE may further continue pre-fetching segments based on the information(i.e., the anticipated requests) in the request.

7.3 DANE architectureFrom an architectural perspective, the DANE consists of two modules: (1) a module for communicatingwith the DASH client and determining which segments (anticipated and alternative segments) shouldbe pre-fetched for this client, and (2) a module for selecting one, or more, network links and do theactual pre-fetching.

SaT5G (761413) D5.5 March 2020

Page 27 of 30

Figure 14: DANE architecture.

7.4 TNO demo architectureThe TNO demonstrator presents local access using an established satellite and terrestrialbackhaul links with User Plane Function (UPF) located at a MEC node for content delivery.The UPF co-located with the MEC node is used to handle request for the local content withthe ability to optimally select between satellite or terrestrial links depending on (their) availablecapacity, network policy, link performance, and the type of end-user profile (how much ofconnectivity is provided via which link).

Increased delays introduced by satellite links result in lowering of resolution (adaptation) forHTTP based streaming. To improve the quality of streaming content, latency needs to bedecreased. The MEC runs a special cache that supports the SAND (Server and NetworkAssisted DASH) protocol defined in ISO/IEC 23009-5.

The MEC node is located next to eNB, and is connected to core network using establishedsatellite and terrestrial backhaul links. User Plane Function (UPF) is located at a MEC nodeand it is used to handle requests for the local content on one hand, and on the other hand toset up connections via core network to content server, and in that process to optimally selectbetween satellite or terrestrial links depending on available capacity, network policy, linkperformance, and the type of end-user profile.

The MEC DANE will prefetch DASH segments over the satellite link and cache them in theMEC. Pre-fetching DASH segments to cache on MEC node, and later downloading them fromthe DANE’s cache removes the high latency, which results in an increase in video quality (thatis, bitrate) and reduces the chances of a video freeze. A combination of SAND and MEC toexploit multiple pre-fetching paths can help provide the guaranteed and high quality servicesenvisioned by 5G.

SaT5G (761413) D5.5 March 2020

Page 28 of 30

Figure 15: TNO demonstrator setup.

The main building blocks of the TNO demonstrator are:· Open5GCore (by Fraunhofer FOKUS)– 5G core network compatible with 3GPP

release 15· OpenSAND – is a GEO satellite emulator which is open source, and which was

developed in scope of one of EU FP projects (www.opensand.org)· 4G base station – is a software implementation of eNB developed by

OpenAirInterface· UE – end-user terminal, which is also a software implementation by OpenAirInterface· MEC node

Whole demonstrator setup is shown in Figure 16. It is a physical implementation of thearchitecture shown in Figure 15.It is based on 4 Intel NUCs, each with an Intel i7 processor, 32GB of RAM, and 64 GB SSD.Devices are connected via a gigabit switch.The 4G base station and UE (User Equipment) are connected via SDR (Software DefinedRadio) boards, which are connected via cables instead of antennas. This was done in orderto use the same frequencies as network operators would use, and to avoid actual transmissionof radio signals, and their impact on commercial networks.

UE

DASHclient

MEC

Proxy Mediaorigin

Internet

SaT5G (761413) D5.5 March 2020

Page 29 of 30

Figure 16: TNO demonstrator setup implementation

7.5 Demonstrations and resultsThe demonstrator was presented at EuCNC 2019 in Valencia, followed by a demo during TNO’s5Gsatcom seminar, and finally at the SaT5G Industry Day at the University of Surrey.

While in principle showing the same point (added value of caching in the edge, through additions ofUPF and DANE clients on MEC node), this demo had ‘under the bonnet’ improvements.

Initially, our focus was on implementing demo and showing difference in quality of streamed video –with and without use of DANE client. For initial demo at EuCNC, the demo software was not optimized,as that was not our goal, but showing added value of placing DANE in MEC, and that collocating it withUPF can add benefits to satellite providing streaming content, in case of tight integration of 5G andsatellites.

Other two occasions – at the 5Gsatcom seminar and University of Surrey Industry Day, were the samedemo, where main changes in software were in optimization of code for the DANE client.

SaT5G (761413) D5.5 March 2020

Page 30 of 30

8 References

[1] 5GTN, “5G test network,” [Online]. Available: https://5gtn.fi/.

[2] Sat5G, “D4.4. Harmonisation of satcom with 5G control and user plane.,” Sat5G, 2019.

[3] 3. TS36.331, “Technical specification TS36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification,” 3GPP, 2017.

[4] Sat5G, “Project Sat5G,” [Online]. Available: https://www.sat5g-project.eu/.

[5] H2020, “Sat5G "Satellite and terrestrial network for 5G",” [Online]. Available: https://www.sat5g-project.eu/.

[6] Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description andsegment formats, ISO/IEC 23009-1:2014, Information technology.

[7] Dynamic adaptive streaming over HTTP (DASH) - Part 5: Server and network assisted DASH(SAND), ISO/IEC 23009-5:2017.