medieval d3.1 v1.1 - european commission :...

MEDIEVAL INFSO-ICT-258053

MEDIEVAL Deliverable D3.1

Concepts for Wireless Access in Relation to Cross-Layer Optimisation

Editor: Michelle WETTERWALD, EURECOM

Deliverable nature: Public

Due date: June 30 , 2011

Delivery date: June 30 , 2011; updated October 17, 2011

Version: 1.1

Total number of pages: 117

Reviewed by: Elena DEMARIA (TIS), Rui COSTA (ALBLF)

Keywords: MEDIEVAL, wireless access, WLAN, LTE-A, L2.5 abstraction

Abstract

This deliverable describes the concepts defined in the WP3 Work package for the integration of the wireless access in the MEDIEVAL cross layer architecture. Its objective is to present, for each of the considered wireless technology, the mechanisms which will improve the efficient transport of the video flow and show how these mechanisms interact with the upper layers, using a L2.5 abstraction concept based on and extending the IEEE 802.21 Media Independent Handover standard.

MEDIEVAL D3.1 Concepts for Wireless Access in Relation to Cross-Layer Optimisation

of (117) © MEDIEVAL 2011

List of authors

Company Author

EURECOM Michelle Wetterwald

IT Aveiro Daniel Corujo

CFR Davide Chiarotto, Marco Mezzavilla

UC3M Antonio de la Oliva, Lucas Eznarriaga

PTIN Nuno Carapeto



History

Modified by Date Version Comments

EURECOM 30/06/2011 V1.0 Deliverable Release

EURECOM 17/10/2011 V1.1 Updated with Appendix II, as requested during the annual audit



Table of Contents

History ............................................................................................................................................................... 3 Table of Contents .............................................................................................................................................. 4 List of Figures.................................................................................................................................................... 7 List of Tables ..................................................................................................................................................... 8 Abbreviations ...................................................................................................................................................10 Executive Summary ..........................................................................................................................................13 1 Introduction ...............................................................................................................................................14 2 Key Contributions .....................................................................................................................................15 3 Reference technologies and challenges .....................................................................................................17

3.1 IEEE 802.21 .......................................................................................................................................17 3.2 WLAN and 802.11aa .........................................................................................................................19

3.2.1 Stream Classification Service .....................................................................................................20 3.2.2 Interworking with IEEE 802.1 Audio Video Bridging Task Group ...........................................20 3.2.3 Groupcast with Retries (GCR) Service .......................................................................................21

3.3 Jumbo Frames ....................................................................................................................................22 3.4 LTE-Advanced ...................................................................................................................................22 3.5 eMBMS ..............................................................................................................................................25

4 Design of the Wireless Access ..................................................................................................................27 4.1 Global overview .................................................................................................................................27 4.2 L2.5 Abstraction (L25) ......................................................................................................................28

4.2.1 ODTONE 802.21 implementation ..............................................................................................29 4.2.2 Abstraction QoS Mapper (AQM) ...............................................................................................29

4.3 Contention-based wireless access (WLAN) .......................................................................................30 4.3.1 802.11aa and Dynamic configuration (WMDC) ........................................................................30 4.3.2 WLAN Monitoring Module (WLANMM) .................................................................................31 4.3.3 Jumbo frames mechanisms (JMB) ..............................................................................................31

4.4 Coordination-based Wireless Access (LTE-A) ..................................................................................32 4.4.1 Video frames selection and interface configuration (VFSIC) ....................................................32 4.4.2 Cognitive exploitation of cooperative technologies (CECT) ......................................................32 4.4.3 Measurements and Medium Access Strategies (MMAS) ...........................................................33 4.4.4 Jumbo frames mechanisms (JMB) ..............................................................................................33 4.4.5 E-MBMS Support (EMBMS) .....................................................................................................34 4.4.6 PDCP-level Relay (L2PRLY) .....................................................................................................34

4.5 Study of parameters available in the technologies and their abstraction ...........................................35 4.5.1 QoS parameters ...........................................................................................................................35 4.5.2 Measurements .............................................................................................................................37

4.6 Proposed extensions to IEEE 802.21 .................................................................................................39 4.6.1 Global Overview .........................................................................................................................39 4.6.2 New Information Elements for the MIIS ....................................................................................39 4.6.3 Link_Action ................................................................................................................................40 4.6.4 Extensions to reporting IEEE 802.21 primitives ........................................................................43

4.7 Physical placement of the functional entities .....................................................................................44 5 Interactions and interfaces with upper layer components .........................................................................47

5.1 Usage scenarios ..................................................................................................................................47 5.2 Cross-layer Optimization flows .........................................................................................................47

5.2.1 Flow Session Setup .....................................................................................................................48 5.2.2 Wireless Access dynamic reporting ............................................................................................49 5.2.3 Interface Handover .....................................................................................................................51 5.2.4 Flow Handover ...........................................................................................................................53 5.2.5 Configuration of the packet marking handling ...........................................................................53 5.2.6 Jumbo frames activation/ deactivation .......................................................................................54 5.2.7 LTE-A Medium Access algorithm optimization ........................................................................58

5.3 Interfaces with the upper layer Components ......................................................................................59 5.3.1 L25_TransportOptimization_If ...................................................................................................59



5.3.2 L25_MobilityManagement_If ....................................................................................................59 5.3.3 MIHF_MIHUSERX_If ...............................................................................................................59 5.3.4 L25_Network_If .........................................................................................................................59

5.4 Interfaces between the L2.5 Abstraction and the Media-specific modules ........................................59 5.4.2 L25_WMDC_If ..........................................................................................................................60 5.4.3 L25_WLANMM_If ....................................................................................................................60 5.4.4 L25_VFSIG_If ............................................................................................................................60 5.4.5 L25_MMAS_If ...........................................................................................................................61

5.5 Interfaces inside the Contention-based Wireless Access ...................................................................61 5.5.1 WLANMM_WMDC_If ..............................................................................................................61

5.5.1.1 WLANMM_WMDC_Set_Threshold ..................................................................................61 5.5.1.2 WLANMM_WMDC_Get_Parameters ................................................................................63 5.5.1.3 WLANMM_WMDC_Parameters_Report ...........................................................................64

5.5.2 JMB_WMDC_If (Conceptual Interface) ....................................................................................65 5.5.2.1 JMB_WMDC_Jumbo_Feasibility_Report ..........................................................................65 5.5.2.2 JMB_WMDC_Jumbo_Action .............................................................................................66

5.5.3 JMB_WLANMM_If (Conceptual Interface) ..............................................................................67 5.5.3.1 JMB_WLANMM_Set_Threshold .......................................................................................67 5.5.3.2 JMB_WLANMM_Get_Parameters .....................................................................................69 5.5.3.3 JMB_WLANMM_Parameters_Report ................................................................................70

5.6 Interfaces inside the Coordination-based Wireless Access ................................................................71 5.6.1 CECT_VFSIC_If ........................................................................................................................71

5.6.1.1 CECT_VFSIC_Set_Threshold ............................................................................................71 5.6.1.2 CECT_VFSIC_Parameters_Report .....................................................................................72

5.6.2 CECT_MMAS_If .......................................................................................................................73 5.6.2.1 CECT_MMAS_Set_Threshold_ PHYmeasurement ...........................................................73 5.6.2.2 CECT_MMAS_Set_Threshold_AllocationMAP ................................................................74 5.6.2.3 CECT_MMAS_PHYMeasurement_Report ........................................................................76 5.6.2.4 CECT_MMAS_AllocationMAP_Report ............................................................................76

5.6.3 MMAS_VFSIC_If ......................................................................................................................77 5.6.3.1 MMAS_VFSIC_Set_Threshold ..........................................................................................77 5.6.3.2 MMAS_VFSIC_Parameters_Report ...................................................................................78

5.6.4 JMB_VFSIC_If (Conceptual Interface) ......................................................................................79 5.6.4.1 JMB_VFSIC_Jumbo_Feasibility_Report ............................................................................79 5.6.4.2 JMB_VFSIC_Jumbo_Action ..............................................................................................80

5.6.5 JMB_MMAS_If (Conceptual Interface) .....................................................................................81 5.6.5.1 JMB_MMAS_Set_Threshold ..............................................................................................81 5.6.5.2 JMB_MMAS_Get_Parameters ............................................................................................83 5.6.5.3 JMB_MMAS_Parameters_Report.......................................................................................84

5.6.6 EMBMS_VFSIC_If ....................................................................................................................85 5.6.6.1 EMBMS_VFSIC_SessionStart ............................................................................................85 5.6.6.2 EMBMS_VFSIC_SessionStop ............................................................................................86

5.6.7 L2PRLY_VFSIC_If ....................................................................................................................87 6 Summary and Conclusion .........................................................................................................................88 Acknowledgements and Disclaimer .................................................................................................................89 References ........................................................................................................................................................90 Appendix I Contributions to the IEEE 802.21 standard .............................................................................93

I.1 Comment to LB4a (MIH_Radio_Get_Capabilities) ..........................................................................93 I.2 Comment to LB4a (Radio_Get_Capabilities) ....................................................................................99 I.3 Comment to LB4a (Clean Up) .........................................................................................................101 I.4 Comment to LB4a (Radio_Get_Parameters) ...................................................................................103 I.5 Comment to LB4a (Radio_Set_Parameters) ....................................................................................105 I.6 Suggested Remedy (Network Types) ..............................................................................................107

Appendix II Relevant paper contributions .................................................................................................111 II.1 Wireless access mechanisms and architecture definition in the MEDIEVAL project .....................111 II.2 Wireless access architectures for video applications: the approach proposed in the MEDIEVAL project; ........................................................................................................................................................111



II.3 Video-Enhancing Functional Architecture for the MEDIEVAL Project .........................................112 II.4 Key Function Interfacing for the MEDIEVAL Project Video-Enhancing Architecture ..................112 II.5 IEEE 802.21: Media independence beyond handover .....................................................................112 II.6 Media-Independent Multicast Signalling for Enhanced Video Performance in the MEDIEVAL Project .........................................................................................................................................................113 II.7 Context Transport Based on 802.21 .................................................................................................113 II.8 A Control Theoretic Scheme for Efficient Video Transmission over IEEE 802.11e EDCA WLANs 114 II.9 Sensor Context Information for Energy- Efficient Optimization of Wireless Procedures ...............114 II.10 A Framework for Flexible Sensor Information Dissemination ....................................................115 II.11 Impact of opportunistic routing in the MEDIEVAL project ........................................................116 II.12 Cooperation via Spectrum Leasing ..............................................................................................116



List of Figures

Figure 1: IEEE 802.21 Communication Model ................................................................................................17 Figure 2: IEEE 802.21 Media Independence Example ....................................................................................18 Figure 3: Alternate EDCA Mechanism ............................................................................................................20 Figure 4 : Example of the IEEE 802.11aa GCR mechanisms ..........................................................................21 Figure 5: E-UTRAN Architecture ....................................................................................................................23 Figure 6: Carrier Aggregation in LTE-A ..........................................................................................................24 Figure 7: LTE-A Frame Structure ....................................................................................................................24 Figure 8:3GPP Reference Architecture for eMBMS (without UTRAN) .........................................................25 Figure 9 : Global view of the Wireless Access sub-system ..............................................................................27 Figure 10 : Modules in the L2.5 Abstraction Component ................................................................................29 Figure 11 : Modules in the WLAN Component ...............................................................................................30 Figure 12 : Modules in the LTE-A Component ...............................................................................................32 Figure 13 : Physical placement of the Wireless Access Components ..............................................................45 Figure 14 : Flow Session setup .........................................................................................................................48 Figure 15 : Setup of the LTE access network ...................................................................................................49 Figure 16 : Trigger based asynchronous reporting ...........................................................................................50 Figure 17 : Direct polling report .......................................................................................................................51 Figure 18 : Interface Handover (1/3) ................................................................................................................51 Figure 19 : Interface Handover (2/3) ................................................................................................................52 Figure 20 : Interface Handover (3/3) ................................................................................................................53 Figure 21 : Configuration of the processing of packets based on marking ......................................................54 Figure 22 : Jumbo frames activation/ deactivation ...........................................................................................55 Figure 23 : Conceptual Jumbo frames enhanced handover ..............................................................................57 Figure 24 : LTE-A Medium Access algorithm optimization ............................................................................58



List of Tables

Table 1: QoS parameter mapping for IEEE 802.11 from IEEE 802.21 ...........................................................36 Table 2: QoS parameter mapping for 3GPP LTE-A ........................................................................................36 Table 3: Commonalities between WLAN and LTE-A .....................................................................................38 Table 4: QoS and multimedia extensions for IEEE 802.11 and LTE-A ...........................................................38 Table 5: Link_Action.request parameter list ....................................................................................................40 Table 6: LINK_ACTION modifications to table F.4 from IEEE 802.21 .........................................................41 Table 7: LINK_AC_TYPE additions to table F.4 from IEEE 802.21 ..............................................................41 Table 8: LINK_AC_PARAM additions to table F.4 from IEEE 802.21 ..........................................................41 Table 9: FLOW_ATTRIBUTE and RESOURCE_DESC additions to table F.4 from IEEE 802.21 ...............41 Table 10: New data types additions to table F.4 from IEEE 802.21 ................................................................42 Table 11: LINK_PARAM_802_11 modifications to table F.4 from IEEE 802.21 ..........................................44 Table 12: LINK_PARAM_LTE extension to table F.4 from IEEE 802.21 .....................................................44 Table 13: WLANMM_WMDC_Set_Threshold.request parameter list ...........................................................62 Table 14: WLANMM_WMDC_Set_Threshold.confirm parameter list ..........................................................63 Table 15: WLANMM_WMDC_Get_Parameters.request parameter list .........................................................63 Table 16: WLANMM_WMDC_Get_Parameters.confirm parameter list ........................................................64 Table 17: WLANMM_WMDC_Parameters_Report.indication parameter list ................................................65 Table 18: JMB_WMDC_Jumbo_Feasibility_Report.indication parameter list ...............................................65 Table 19: JMB_WMDC_Jumbo_Action.request parameter list ......................................................................66 Table 20: JMB_WMDC_Jumbo_Action.confirm parameter list .....................................................................67 Table 21: JMB_WLANMM_Set_Threshold.request parameter list ................................................................68 Table 22: JMB_WLANMM_Set_Threshold.confirm parameter list ...............................................................69 Table 23: JMB_WLANMM_Get_Parameters.request parameter list ..............................................................69 Table 24: JMB_WLANMM_Get_Parameters.confirm parameter list .............................................................70 Table 25: JMB_WLANMM_Parameters_Report.indication parameter list .....................................................71 Table 26: CECT_VFSIC_Set_Threshold.request parameter list ......................................................................71 Table 27: CECT_VFSIC_Set_Threshold.confirm parameter list .....................................................................72 Table 28: CECT_VFSIC_Parameters_Report.indication parameter list ..........................................................73 Table 29: CECT_MMAS_Set_Threshold_PHYmeasurement.request parameter list ......................................73 Table 30: CECT_MMAS_Set_Threshold_PHYmeasurement.confirm parameter list .....................................74 Table 31: CECT_MMAS_Set_Threshold_AllocationMAP.request parameter list .........................................75 Table 32: CECT_MMAS_Set_Threshold_AllocationMAP.confirm parameter list ........................................75 Table 33: CECT_MMAS_PHYMeasurement_Report.indication parameter list .............................................76 Table 34: CECT_MMAS_AllocationMAP_Report.indication parameter list .................................................77 Table 35: MMAS_VFSIC_Set_Threshold.request parameter list ....................................................................77 Table 36: MMAS_VFSIC_Set_Threshold.confirm parameter list ...................................................................78 Table 37: MMAS_VFSIC_Parameters_Report.indication parameter list ........................................................79 Table 38: JMB_VFSIC_Jumbo_Feasibility_Report.indication parameter list .................................................80 Table 39: JMB_VFSIC_Jumbo_Action.request parameter list ........................................................................80 Table 40: JMB_VFSIC_Jumbo_Action.confirm parameter list .......................................................................81 Table 41: JMB_MMAS_Set_Threshold.request parameter list .......................................................................82 Table 42: JMB_MMAS_Set_Threshold.confirm parameter list ......................................................................83 Table 43: JMB_MMAS_Get_Parameters.request parameter list .....................................................................83 Table 44: JMB_MMAS_Get_Parameters.confirm parameter list ....................................................................84 Table 45: JMB_MMAS_Parameters_Report.indication parameter list ............................................................85 Table 46: EMBMS_VFSIC_SessionStart.request parameter list .....................................................................85 Table 47: EMBMS_VFSIC_SessionStart.confirm parameter list ....................................................................86 Table 48: EMBMS_VFSIC_SessionStop.request parameter list .....................................................................86 Table 49: EMBMS_VFSIC_SessionStop.confirm parameter list ....................................................................87 Table 50: MIH_Capability_Discover.request parameter list ............................................................................94 Table 51: MIH_Capability_Discover.indication parameter list .......................................................................96 Table 52: MIH_Capability_Discover.response parameter list .........................................................................97 Table 53: MIH_Capability_Discover.confirm parameter list ...........................................................................98



Table 54: MIH_Capability_Discover request message ....................................................................................99 Table 55: MIH_Capability_Discover response message ..................................................................................99 Table 56: Link_Capability_Discover.confirm parameter list .........................................................................101 Table 57: LINK_ACTION_LIST parameter ..................................................................................................101 Table 58: LINK_PARAM_GEN parameter ...................................................................................................105 Table 59: LINK_ACTION parameter ............................................................................................................106 Table 60: LINK_AC_PARAM parameter ......................................................................................................106 Table 61: LINK_AC_TYPE parameter ..........................................................................................................106 Table 62: LINK_CONFIGURE parameter .....................................................................................................106 Table 63: Modification of Table F.14 from IEEE 802.21 ..............................................................................109 Table 64: Modification of Table F.15 from IEEE 802.21 ..............................................................................110



Abbreviations

3GPP Third Generation Partnership Project

AC Access Category

AIFS Arbitration Interframe Space

AQM Abstraction QoS Mapper Function

AP Access Point

ARP Allocation and Retention Priority

BLER Block Error Rate

BM-SC Broadcast/Multicast Service Centre

CECT Cognitive Exploitation of Cooperative Technologies Module

CM Connection Manager

CN Core Network

CoS Class of Service

CQI Channel Quality Indicator

CW Contention Window

DE Drop Eligibility

DL Downlink

DMS Directed Multicast Service

EDCA Enhanced Distributed Channel Access

eMBMS evolved MBMS

EPC Evolved Packet Core

EPS Evolved Packet System

E-UTRAN Evolved Universal Terrestrial Radio Access Network

FM Flow Manager

GBR: Guaranteed Bit Rate

GCR Groupcast with Retries

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

GTP-U GPRS Tunnelling Protocol - User

HARQ Hybrid Automatic Repeat request

IEEE Institute of Electrical and Electronics Engineers

ISI Integrated Services Internet

JMB Jumbo Frames Mechanisms module

L2PRLY PDCP-level Relay module

LTE Long Term Evolution

LTE-A LTE Advanced

MAC Medium Access Control

MAR Mobility Access Router



MBMS Multicast/Broadcast Multimedia Service

MBMS-GW MBMS Gateway

MBSFN Multicast Broadcast Single Frequency Network

MEDIEVAL MultimEDia transport for mobIlE Video AppLications

MICS Media Independent Command Service

MIES Media Independent Event Service

MIIS Media Independent Information Service

MIH Media Independent Handover

MIHF Media Independent Handover Function

MMAS Measurements and Medium Access Strategies module

MME Mobility Management Entity

MMS Multimedia Messaging Service

MSC Message Sequence Chart

MSGCF MAC State Generic Convergence Function

MT Mobile Terminal

MTU Maximum Transmission Unit

NAS Non-Access Stratum

OFDMA Orthogonal Frequency-Division Multiple Access

PDCP Packet Data Convergence Protocol

PDN-GW Public Data Network Gateway

PDP Packet Data Protocol

PHY Physical Layer

PoA Point of Attachment

PoS Point of Service

PSS Packet-switched Streaming Service

p-t-m point-to-multipoint

p-t-p point-to-point

PUCCH Physical Uplink Control Channel

QCI Quality of Service (QoS) Class Identifier

QoE Quality of Experience

QoS Quality of Service

RAN Radio Access Network

RB Resource Block

RF Radio Frequency

RLC Radio Link Control

RNC Radio Network Controller

RRC Radio Resource Control

SAP Service Access Point

SCS Stream Classification Service



SDO Standards Development Organization

S-GW Serving Gateway

SINR Signal to Interference plus Noise Ratio

SSM Source Specific Multicast

SVC Scalable Video Coding

ToS Type of Service

TS Traffic Stream

UE User Equipment

UL Uplink

UMTS Universal Mobile Telecommunications System

VFSIC Video Frames Selection and Interface Configuration module

WLAN Wireless Local Area Network

WLANMM WLAN Monitoring Module

WMDC 802.11aa and Dynamic Configuration module



Executive Summary

This deliverable defines and describes the video optimized Wireless Access mechanisms developed within the MEDIEVAL project. It supplements the general description given in deliverable D1.1 with detailed description of the wireless access architecture, technologies, the new functionality included and the internal interfaces between the different modules.

The deliverable begins with a brief explanation of the main technologies considered for the MEDIEVAL wireless access and the challenges faced for efficient video delivery. The deliverable focuses on the specific technologies with a central implication on the work performed. In this way, the main specifications involved on this deliverable are the 802.21 and 802.11aa from the IEEE SDO, and the LTE-A and MBMS technologies from the 3GPP SDO. A new approach to increase the available bandwidth of the wireless networks, the use of Jumbo frames, is also described in order to understand the challenges involved in its application.

The deliverable continues by presenting the architecture and main modules of its design. This part is devoted to the overall description of each module and its functionalities, indicating the relationships between the different modules.

One of the key contributions and also one of the main challenges of this work, is the definition of a set of abstract media independent interfaces that allows higher layers (such as Transport Optimization or Mobility) to control the behaviour of lower layers in an uniform way. Through the development of this interface the MEDIEVAL architecture benefits from an integrated end-to-end cross-layer information flow, enabling cross-layer optimizations such as the end-to-end processing of packet marking. In order to design this interface it has been required to analyse the different parameters available on each technology and the commonalities between them. The result of this study is also part of this deliverable.

As explained above, the key concept of the Wireless Access work is the definition of media independent interface. As such, the work on this deliverable builds on top of the IEEE 802.21 standard, which defines media independent services for handover. We aim at extending these services, broadening their scope. One example of these possible extensions is the different modifications to already existing primitives (IEEE 802.21 primitives) to allow the cross-layer interactions specified in MEDIEVAL. All these modifications have been designed standard compliant, and can be found in the respective sections of the deliverable. In addition, these primitives are, together with the standard .21 primitives, used within the MEDIEVAL architecture to interact with the Wireless Access modules, more specifically with the Layer 2.5 Abstraction module. To provide the reader with a complete view of these interactions in the real world, the deliverable also includes a section mapping the different modules of the Wireless Access to the physical components of the network.

Finally, the deliverable describes the most relevant operations, such as session setup, configuration of the packet marking, handover, LTE Medium Access optimization or Jumbo activation in the form of Message Sequence Charts. In this way, the reader is able to get a detailed knowledge on the primitives and mechanisms involved in each action. To improve this knowledge, the deliverable also includes a detailed specification of the internal interfaces between each module, with a detailed enumeration of the parameters and their data types.



1 Introduction

This deliverable aims to present the Wireless Access subsystem in relation to the cross-layer design of the MEDIEVAL project. Wireless access plays a vital role in the realization of the MEDIEVAL enhancements and optimizations to better support video transport. By exploiting the specific features of different underlying wireless technologies, the architecture is able to execute the necessary link-layer mechanisms that support or enable transport optimization and mobility procedures decided by the network and assisted by the mobile terminal. MEDIEVAL employs design and mechanism evolution over two kinds of wireless accesses: contention-based and coordination-based wireless accesses. For the first case, MEDIEVAL considers the IEEE 802.11, enhancing existing procedures with new mechanisms that provide performance increases and optimizations towards multimedia streaming over WLAN, as is the case of IEEE 802.11aa “Robust streaming of Audio Video Transport Streams” and stream classification. For the coordination-based wireless access, MEDIEVAL considers the enhancement of LTE-A mechanisms which exploit flow interaction and framing as methods for increasing multimedia performance over cellular networks.

Beyond the specific mechanisms provided by each specific technology, the wireless access architecture will also exploit the deployment of generic behaviour able to work in both kinds of accesses, albeit with small differences. In this aspect, MEDIEVAL will provide enhanced multicast support for wireless optimization, by employing groupcast handling at the WLAN access and E-MBMS at the LTE-A access. Also, the conception of using larger frame sizes (e.g., Jumbo frames) able to take advantage of today’s and tomorrow’s data rate increases is being analysed for each specific access.

Accessing the different mechanisms made available by both technologies (as well as their shared mechanisms such as Jumbo frames or packet marking) requires the availability of a common interface provided to the different cross-layer entities existing in the MEDIEVAL overall architecture. As such, this interface must provide technology-agnostic means to access said behaviour in order to facilitate the deployment and operability of heterogeneous scenarios. To provide this functionality, the wireless access architecture encompasses a L2.5 Abstraction layer which, in one hand, provides technology-agnostic access and control to link-layer information (e.g., link events and parameter values) towards high-level entities (e.g., decision modules residing both at the network and mobile terminal) and, in the other hand, enables the remote exchange of such information and control primitives between different physical entities. This L2.5 Abstraction layer is built from the existing base services and mechanisms provided by the IEEE 802.21 Media Independent Handover services. However, it will be extended to encompass the necessary elements for its introduction into the MEDIEVAL overall architecture, and the support of video-specific enhancements. It will play an important role in the integral MEDIEVAL design, since it provides the common language used by the majority of MEDIEVAL’s components belonging to the different work packages to communicate with one another.

The structure of the deliverable is organized as follows. Section 2 shortly summarizes the key contributions in terms of novelties and basic architectural choices. Section 3 takes a brief look at the reference technologies and challenges, highlighting the base components which provide the core desired functionality within the MEDIEVAL project. Section 4 elaborates on the design of the wireless access, providing details for the composition of the L2.5 Abstraction cross-layer, the components featured by the contention-based and coordination-based wireless access technologies, as well as the study and abstraction of QoS parameters available at both kinds of wireless access technologies.

The deliverable further evolves into section 5, by providing a detailed specification of the interfaces involved. Section 5.1 highlights usage scenarios, whereas section 5.2 provides cross-layer optimization flows. Sections 5.3 to 5.7 provide the specifications of the interfaces with upper layer components, inside the L2.5 Abstraction, between the L2.5 Abstraction and media-specific components, inside the contention-based and coordination-based wireless accesses, respectively. Lastly, the deliverable concludes and summarizes in section 6.

The architecture described in this deliverable will be subject to future changes, based on feedback and experience gained in the upcoming months with the effective implementation. A final, revised version of the Wireless Access sub-system architecture will be described in Deliverable D3.3.



2 Key Contributions

The list below represents the contributions offered by the MEDIEVAL project related to the work regarding the wireless access. Most of the work has been focused on understanding the additional functionalities of each wireless technology in the overall MEDIEVAL architecture. Then, on the analysis of how the different multicast technologies should be used in order to improve the QoE experienced by the users in current architectures. Finally, on studying how the two defined technologies and the multicast support fit on the framework provided by the L2.5 abstraction layer.

The key contributions of the Wireless Access subsystem detailed in this deliverable are summarized as follows:

Design of an architecture for the access network of MEDIEVAL. The architecture encompasses different modules and interfaces. The modules are divided in abstract and technology specific modules, while the interfaces focus on video mobility and transport optimization control.

The abstraction layer, known as Layer 2.5 Abstraction in this deliverable, is designed based on the Media Independent Handover Function defined in the IEEE 802.21 standard [41]. The main paradigm behind this framework is the use of the media independence concept to reduce the complexity of higher layer algorithms and management operations.

The abstract modules are integrated into the Layer 2.5 abstraction, and are defined as control modules implementing certain algorithms which serve as intelligent controllers, hence providing the unicast/multicast, prioritization and QoS configuration to the lower layers.

The technology specific modules are in charge of processing the abstract commands provided by the Layer 2.5 modules and taking specific actions. Although the actions that can be taken vary between the two technologies (LTE and WLAN), in MEDIEVAL a set of common optimization techniques is defined for both technologies. The use of packet prioritization, drop eligibility, QoS support and the use of technology-specific multicast is chosen as mechanisms to optimize the video traffic at the access network.

The interfaces with higher layers (Mobility Management and Transport Optimization) also benefit from standardized interfaces. Specifically, the interface with the Mobility subsystem which reuses a significant part of the MIH_NET_SAP of IEEE 802.21. The interface with the Transport Optimization subsystem allows communications between the access network and the core network, providing a mechanism to propagate information end to end, e.g. packet marking labels. This enables cross layer interactions involving all the implicated entities, from the source through the network and to the Mobile Node.

The designed architecture has been published at [1].

During the work reported in this deliverable, there have been important advances in the understanding of each technology involved. Regarding the L2.5, we have been analysing which parameters are worth to be reported to higher layers and how this reporting can be done (see Section 4.5). Regarding WLAN, we have been focused on the analysis of the best multicast mechanism to use depending on the number of stations and the QoS required by each one. The expected output of this work is to be able to provide a dynamic algorithm that can select the most appropriate mechanisms based on measurements of the network. Regarding LTE, the efforts have been focused on understanding the implications of the use of MBMS coupled with the mobility mechanisms of MEDIEVAL and the use of advanced relaying mechanisms. Moreover, a novel medium access strategy will be applied, taking into account the characteristics of video flows and interacting with L2.5 abstraction, to design access techniques, which are aware of the video content delivery in a network-wide perspective. In particular, allocation strategies are planned to be provided, which exploit the cross-layer techniques to allocate as many users as the LTE-A wireless channel can admit, trying not to affect the perceived QoE by the end users. This is accomplished also by the definition of a utility function which enables a better optimization of the medium access algorithm.

Finally it is worth to mention that as a direct result of the project and the discussions held within we have contributed to IEEE 802.21b. Specifically within the project we held several discussions which



allow us to modify a previous proposal already accepted into the draft standard, providing a better method (more elegant and simple) of configuring and reporting the configuration of a certain interface. These contributions can be found in Appendix I or in references [35] to [40].



3 Reference technologies and challenges

In this section is given an overview of the reference technologies that have been selected to contribute to the wireless access architecture. For each technology, the review describes its interesting features and the challenges faced when transporting video applications flows.

3.1 IEEE 802.21

The IEEE 802.21 [2] [4] [5] (or Media Independent Handover, MIH) technology is an enabler for the optimization of handovers between heterogeneous IEEE 802 systems as well as between 802 and cellular systems. The goal is to provide the means to facilitate and improve the intelligence behind handover procedures, allowing vendors and operators to develop their own strategy and handover policies. For this purpose, the IEEE 802.21 aims at optimizing the handover procedure between heterogeneous networks by adding a technology independent function (Media Independent Handover Function, MIHF) which improves the communication between different entities, either locally (mobile node) or remotely (network functions). Sharing information allows handover algorithms to guarantee seamlessness while moving across different points of attachment in the network and the use of common commands greatly simplifies the design of the algorithms.

3GPP/3GPP2

Interface802 Interface

MIH Users

Mobile Node

802 Interface

MIH Users

MIH Function

802 Network

MIH Users

MIH Function

3GPP/3GPP2 Network and Core

Networks

MIH_NET_SAPL3 Transport Interface

MIH_NET_SAPL2 Transport Interface

MIH_SAP

MIH_LINK_SAP

MIH_SAP MIH_SAP

MIH_LINK_SAP

MIES MICS MIIS

MIH Function

Figure 1: IEEE 802.21 Communication Model

Figure 1 depicts the 802.21 reference model with functional entities and associated interfaces, where the MIH technology is implemented in the mobile nodes and network side components, both being MIH-enabled. MIH defines three main mobility services:

The Media Independent Event Service (MIES) provides event classification, event filtering and event reporting, corresponding to dynamic changes in link characteristics, link status and link quality.

The Media Independent Command Service (MICS) enables MIH clients to manage and control the link behaviour related to handovers and mobility. It also provides the means to mandate actions to lower layers, in a local or in a remote protocol stack.

The Media Independent Information Service (MIIS) provides details on the characteristics and services provided by the serving and surrounding networks. The information enables effective system access and effective handover decisions.



The information exchange occurs between lower layers and higher layers, taking always the MIH Function as reference. Furthermore, information can be shared locally, within the same protocol stack, or remotely, between different network entities.

The IEEE 802.21 architecture is defined considering the Mobile Node as central point. Two definitions that are being used commonly through this document are the concepts of Point of Attachment (PoA) and Point of Service (PoS). In the following the definition of these two concepts is introduced:

Point of Attachment (PoA) is the network side endpoint of a layer 2 link that includes a mobile node as the other endpoint.

Point of Service (PoS): Network-side MIHF instance that exchanges MIH messages with an MN-based MIHF.

Figure 1 also presents the three more important Service Access Points (SAP) specified in IEEE 802.21:

MIH_SAP: Media independent interface of MIHF with the higher layers or MIH users.

MIH_LINK_SAP: Abstract media dependent interface of MIHF with the lower layers (the different technologies).

MIH_NET_SAP: Abstract media dependent interface of MIHF providing transport services over L2 and L3 over the data plane. This SAP supports the exchange of MIH information and messages with a remote MIHF or a Media Independent Information server.

The most important concept in IEEE 802.21, the Media Independence, is achieved by permitting the MIH_Users to work on a mix of underlying technologies in a media independent way. These media independent mechanisms are enabled by the MIH_SAP, which provides a set of abstract primitives and concepts. Under this paradigm, the MIHF works as a translator which is able to convert the different abstract primitives into technology specific primitives, providing a mapping between the MIH_SAP and the MIH_LINK_SAP, which takes the form of technology dependent primitives.

ManagementEntity

Service Specific Convergence Sublayer

MAC Common Part Sublayer

PHY

CS_SAP

MAC_SAP

PHY_SAP

M_S

AP

C_

SA

P LLC

MAC

PLCP and PMD

LSAP

MAC_SAP

PHY_SAP

MSGCF_SAP

LLC

LLC

MLME_PLME_SAP LLC

MSGCF_SME_SAP

MLME_SAP

PLME_SAP

MAC State Generic Convergence Function

MIH UserMIH_Link_Actions(MIHF_ID, [(Link_802.16, Link_Power_Up),

(Link_802.11, Link_Power_Up)])

MSGCF-ESS-Link-Command.request(NonAPSTAMacAddress, ESSIdentifier, POWER_UP)

MIHF

Security Sublayer

M-SSM-REQ( Operation_Type: Action, Action_Type: Power On)

IEEE 802.16 IEEE 802.11

Figure 2: IEEE 802.21 Media Independence Example

In order to clarify this concept, Figure 2 presents an example of the mapping between the MIH SAP and MIH_LINK_SAP for two different technologies, IEEE 802.11 and IEEE 802.16. The figure shows how a media independent primitive (MIH_Link_Actions) can be used to power up two interfaces of different technologies. The MIH_User issues the MIH_Link_Actions primitive containing a Link_Power_Up command to the two interfaces of the terminal. The MIHF translates this command to a technology specific primitive for each interface. In the case of IEEE 802.11, the command is translated to a primitive of the



MSGCF SAP (MAC State Generic Convergence Function SAP) as defined in IEEE 802.11u [6]. In the case of IEEE 802.16, the command is translated to a primitive of the M SAP (Management SAP) as specified in IEEE 802.16g [7].

The MEDIEVAL project takes on the challenge of exploiting and extending the operability of the IEEE 802.21 standard to consider new underlying mechanisms for the optimization of video traffic in novel operator-supported scenarios. On one hand, it will leverage on the media independent mechanisms for conveying link capabilities and operation procedures towards high-level decision entities and, on the other, enhance those existing procedures with video-aware parameters and operations. In this way, access link and mobility decision entities and procedures have their operations facilitated though the usage of cross-layer media independent mechanisms, but are also aware to take into consideration the requirements and impact that video services can have in network operations. Another challenge is to consider LTE as one of the underlying technology, adapting the media independent operations to the new set of procedures and functionalities defined by the 3GPP.

3.2 WLAN and 802.11aa

The IEEE 802.11 standard for Wireless LAN (WLAN) [8] has become one of the most common technologies to provide broadband connectivity to the Internet. The widespread deployment of high-rate access points (APs), with modulation schemas reaching up to 54 Mbps as defined by the amendments 802.11a [9] and 802.11g [10], are enabling the introduction of applications with relatively large bandwidth demands, like e.g., YouTube, Skype videoconferencing or VideoLAN video-streaming.

The original 802.11 standard was poorly suited for the efficient support of multimedia flows, and in particular video streams, because of several reasons:

i) first, the originally supported physical transmission rates (1 and 2 Mbps) imposed a severe bottleneck on the maximum achievable rate, regardless of the efficiency of the MAC protocol;

ii) second, only “best-effort” service was supported, thus preventing any sort of traffic differentiation that could improve the performance of multimedia applications, which as compared to data can relax their reliability requirements below 100 % to improve performance;

iii) third, multicast transmissions were very inefficient and unreliable (as widely reported in various works, see e.g. [11]), which eventually prevented its use on WLANs, as there is no proper support for video streaming to various receivers.

The subsequent amendments to the 802.11 standard have lessened the first two limitations. Indeed, as already mentioned, the introduction of PHY-amendments have boosted the maximum achievable rates, starting with the 802.11b [12] that increased the maximum rate up to 11 Mbps, continuing with the 802.11a and 802.11g amendments that reach up to 54 Mbps, and finally with the 802.11n [13] which specifies modulation rates up to 108 Mbps. On the other hand, the 802.11e amendment [14] has introduced traffic differentiation via the setting of the contention parameters, thus enabling both the ability to prioritize one type of traffic over other type [15] and a more efficient operation of WLANs by proper tuning of the MAC parameters [16]. The remaining challenge, therefore, is to efficiently support multicast over 802.11 WLANs.

The IEEE 802.11aa Task Group is addressing this last limitation, with the definition of the mechanisms to support “Robust streaming of Audio Video Transport Streams”. Its focus is therefore to extend the base 802.11 standard with those mechanisms that improve performance of multimedia streaming over WLAN. The new mechanisms target at significantly improving both the effectiveness and efficiency of multicast, allowing for a fine- grained control of the type of service provided to video traffic.

The upcoming IEEE 802.11aa amendment is being designed to specifically address the challenge of multimedia transmission, implementing a set of new functionalities over the base specification. In this section, we describe the main extensions to the IEEE 802.11 standard as defined in the 802.11aa Draft 3.01 [17]. The objective of these extensions is to efficiently improve the reliability of audio and video streaming, while maintaining and even improving the service as perceived by the other streams. The amendment also specifies related functionality (e.g., OBSS management) but we only consider the case of a single WLAN. Following this, we consider the following new mechanisms:

Stream Classification Service (SCS) over the EDCA mechanism.



Interworking with IEEE 802.1AVB.

Group-cast with Retries (GCR) service.

In the following we present each of these new functionalities.

3.2.1 Stream Classification Service

This service builds over the EDCA access mechanism which, based on different access categories (ACs), supports traffic differentiation by means of priorities between queues and heterogeneous configuration of the contention parameters (namely AIF S, CW and T XOP ). The SCS, along with the Intra-Access Category (AC) Traffic Stream (TS) prioritization, enables classification based on layer 2 and/or layer 3 signalling, increases the granularity of the service differentiation already provided by the EDCA mechanism.

PktPkt Pkt

Pkt

Pkt

Pkt Pkt

Pkt

Pkt

AAC_VO AC_VO AAC_VI AC_VI AC_BE AC_BK

Mapping to Access Category

VO VI BE BK

Data Packet, Traffic Class

Transmit queue for Access Category

EDCA functions

Introduced in IEEE 802.11aa

Figure 3: Alternate EDCA Mechanism

More specifically, as illustrated in Figure 3, this service introduces two additional queues within the existing EDCA access categories: one additional queue for audio and another one for video, in order to support prioritization within the video flows. Furthermore, in addition to this intra AC prioritization, packets are tagged with their drop eligibility (DE), which defines a different maximum number of (short and long) retries.

With this availability of additional access categories and the drop eligibility bit, graceful degradation of video quality is supported in case of bandwidth shortage.

3.2.2 Interworking with IEEE 802.1 Audio Video Bridging Task Group

The IEEE is actively trying to enforce the use of IEEE 802.1Qat [18], and specifically the Stream Reservation Protocol (SRP) defined on it, to enable the end-to-end reservation of resources across IEEE 802 networks. Multimedia traffic is the clear example of traffic that may take benefit of the end-to-end resource reservation and as such it is envisioned that it supports and integrates the SRP. It is important to note that the Stream Reservation Protocol is a Higher Layer Protocol. As such, the IEEE 802.11 system of a non-AP station is not able to interpret the SRP messages and its integration consists in the station sending the requests to the AP. In order to support end-to-end reservations on the wireless link, the AP has collocated a higher layer entity called Designated MSRP Node (DMN) that is in charge of processing the signalling required by SRP and invoke the required 802.11 reservation primitives.



3.2.3 Groupcast with Retries (GCR) Service

Some of the problems regarding the use of multicast in IEEE 802.11 technologies are i) the lack of reliability of the service, since multicast frames are not acknowledged, and ii) the requirement that the multicast frames are sent at a rate belonging to the Basic Rate Set. In order to overcome these limitations, the IEEE 802.11aa draft standard [17] proposes several new mechanisms that can be applied to frames addressed to a group of stations. In addition to the No-Ack/No-Reply multicast mechanism (see Figure 4, part a) defined in the base specification, the IEEE 802.11aa extends the groupcast frame handling by introducing 3 new mechanisms: GCR Unsolicited Retry, Direct Multicast Service (DMS) and GCR Block Ack. Figure 4 shows a comparison of the timings for video frame transmission for the different multicast mechanisms, and provides a rough idea of the overhead introduced by each of them.

Busy medium

DIFS

Video frame1

DIFS

Video frame2

DIFS

Video frame3No-Ack/No-Retry

Busy medium

DIFS

Video frame1

DIFS

Video frame1

DIFS

Video frame1

GCR Unsolicited

Retries

DIFS

Video frame4

DIFS

Video frame2

Busy medium

DIFS

Video frame1

SIFS

DMS

ACK

DIFS

Video frame1

SIFS

ACK

DIFS

Video frame2

SIFS

ACK

GCR group member 1 is addressed GCR group member 2 is addressed GCR group member 1 is addressed

1st UR is transmitted 2nd UR is transmitted

Busy medium

DIFS

Video frame1

SIFS

GCR BlockAck

SIFS DIFS

Video frame2 Video frame3

SIFS

BlockAckRequest

SIFS

BlockAck

BlockAckRequest

SIFS

BlockAck

SIFS

GCR group member 1

GCR group member 2

a)

b)

c)

d)

Backoff

Figure 4 : Example of the IEEE 802.11aa GCR mechanisms

A description of those mechanisms follows:

GCR Unsolicited Retry: this delivery method retransmits a group addressed frame one or more times (up to a certain lifetime limit) to increase the probability of correct reception at the STAs (see Figure 4, part b). The retransmission of these frames is implementation dependent. This mechanism provides moderate reliability but high scalability.

Direct Multicast Service (DMS): this mechanism allows the conversion multicast-to-unicast (see Figure 4, part c), transmitting group addressed frames individually to each of the associated STAs that has a DMS agreement for this group address. The individually addressed frames will be retransmitted until an ACK is received or the retransmission count limit is exceeded in which case the frame is discarded. This mechanism provides high reliability but has low scalability as the throughput decreases for an increasing number of group members. Although this mechanism was introduced in IEEE 802.11v [19], this specification extends the DMS mechanism to deal with groupcast addressed frames.

GCR Block Ack: this delivery method extends the Block Ack mechanism defined in IEEE 802.11 to group addressed frames. In the previous mechanism, the sender transmitted a burst of data frames and explicitly requested an ACK to the receiving station (see Figure 4, part d). In the case of 802.11aa, the AP, after transmitting no more than GCR buffer size frames to the GCR group address, sends a BlockAckRequest frame to one of the STAs that have a GCR Block Ack agreement for this group address. After receiving the BlockAck from the previous STA, the AP may send another BlockAckRequest to another STA of the group address, and this process may be repeated multiple times.

Although the draft standard proposes all of these retransmission mechanisms it does not include any algorithm or performance study that can be used to understand what is the best mechanism to use depending



on the situation. In MEDIEVAL we aim at understanding the trade-offs of each of the mechanisms proposed, being able to develop a weighted procedure that selects the most appropriate mechanism to use based on different characteristics of the traffic and the current situation of the network.

3.3 Jumbo Frames

Jumbo frames, or jumbograms, or just plainly jumbo, are packets with a size larger than 1500 bytes, where 1500 bytes is the normal Ethernet size being used since its creation (around the 80’s). The major benefit of using a larger frame size is that, when compared with a lower frame size, the same amount of information can be sent in fewer packets (i.e., less fragmentation occurs). Each frame, both when sending or receiving, requires CPU processing and has header overhead associated. Thus, fewer frames will require less CPU processing and generate less overhead. Using an MTU size of 1500 can be considered as legacy from 100Mbit Ethernet. With today’s Gigabit Ethernet and Fast Optical links, having a higher MTU can benefit not only the above mentioned points, but also presents itself as a controllable parameter, unlike RTT and packet loss. Jumbo allows the usage of frames up to 64KB for IPv4 (due to the 16-bit Total Length IPv4 header field which defines the entire datagram size) and 4GB for IPv6 (via a Jumbo Payload Option header) [20] establishes a relationship between the maximum TCP throughput and the Maximum Segment Size (MSS), which is composed by the MTU (Maximum Transmission Unit) decoupled of the TCP/IP headers. It states that this relationship occurs in a direct proportion, meaning that, in theory, it is possible to double TCP throughput by doubling the packet size. However, it also acknowledges that Packet Loss will also increase with the MSS size, but it occurs at a sub-linear rate, since MSS size still dominates throughput.

With packet loss presenting itself as a hurdle for the usage of Jumbo frames, the deployment of such solutions has steered away from wireless technologies, even though it is used in wired technologies such as Optical Networks or Storage Area Networks. In fact, wireless technologies have been continuously evolving in terms of bandwidth performance, but are still hindered by complex challenges which require mechanisms to deal with packet loss and contention that still consider the normal MTU size.

The wireless medium provides very stringent conditions for increased throughput mechanisms. On one hand, the medium is shared which means that multiple access techniques are employed. These multiple access techniques are typically implemented considering the balance between performance and robustness, and thus higher MTU size frames are not the subject of thorough studies. It is commonly accepted that configuring multiple access mechanisms to encompass larger MTU frames, would create a negative impact in terms of timers, access to the medium, packet re-sending and fairness. Issues such as jumbo cost of RTS/CTS need to be evaluated. On the other hand, losing a packet with 1500 bytes is less damaging than losing a packet with 9000 bytes. This affects particularly real-time video applications, where several frames can be lost. As such, MEDIEVAL will consider packet loss solutions towards the usage of jumbo frames in wireless environment such as Partial Packet Recovery [21] and Rate Adaptation [22].

In this setting, the MEDIEVAL project will address the feasibility of having jumbo frames in wireless environments, aided by novel mechanisms that improve performance against packet loss, while maintaining wireless medium fairness. The aim is to provide greater throughput for video traffic, while enabling its usage as a support mechanism in mobility and other traffic optimization procedures.

3.4 LTE-Advanced

The Third Generation Partnership Project (3GPP) [23] Evolved Packet System (EPS) represents the evolution of today’s deployed 3G networks, including the Evolved UMTS Terrestrial Radio Access Networks (E-UTRAN), also referred to as Long Term Evolution (LTE), and a new core network based on the Internet Protocol (IP): the Evolved Packet Core (EPC). LTE Advanced is the further advancement of E-UTRAN, and represents an emerging and promising solution for providing broadband ubiquitous wireless access thanks to its radio capabilities and enhanced communication protocol techniques. For a graphical representation of the system architecture, refer to Figure 5.



Figure 5: E-UTRAN Architecture

Besides improvements in the EPC, LTE and LTE-A have introduced important enhancements to streamline the control of the radio interface, compared with UMTS. The new system takes into account the new flat IP-based network architecture and the aggregation of the former Radio Network Controller (RNC) and NodeB nodes into a single new node, the eNodeB. From a radio control point of view, the Radio Resource Control (RRC) procedures have been simplified, with part of the protocol overhead being off-loaded to simpler procedures in the Medium Access Control (MAC) and Physical Layer (PHY) protocols. In the new protocol, only two RRC states are considered (Idle and Connected) and most of the interface measurements are self-contained in the lower layers. The Non-Access Stratum (NAS) layer has received the same simplification with a revised protocol operating between the Mobility Management Entity (MME) and the Mobile Terminal (MT) to operate the air interface with simpler procedures for attachment, mobility management or session management. Among other features, the LTE-A has also introduced some new types of nodes serving as relays. Relays can be divided into several types, according to the technology considered. They can operate at layer 1 where they only repeat the received Radio Frequency (RF) signal. Such technology is already in operation because it is very cheap and relatively simple. However, it introduces an important problem of interference between the RF signals received and transmitted at the relay. Layer 2 relays introduce additionally demodulation, decoding, encoding and modulation, thus eliminating the noise problem. Layer 3 relays perform the entire protocol stack processing, including PDCP (Packet Data Convergence Protocol, see Figure 5), thus benefiting from all the error correction mechanisms of the link layers. The drawback of this solution is that it introduces an additional delay in the transfer of user data. Since the start of the MEDIEVAL studies, layer-3 relays using architecture similar to what had been planned in the project have been introduced in the LTE-A roadmap [24]. However, the standardisation is still under progress at stage 3 level, which means that the detailed operation specifications are still under definition. In addition, considering video transmissions, the impact of the delay introduced on video streams by the relaying architecture has to be assessed.

Orthogonal Frequency-Division Multiple Access (OFDMA), that represents the radio access technology under consideration in LTE, tackles the frequency selective nature of the wireless channel, that limits the performance of high-speed communication system (Integrated Services Internet ,ISI), by converting the frequency selective channel into many parallel flat fading channels; then, the LTE downlink combines OFDM with channel coding and Hybrid Automatic Repeat reQuest (HARQ) to overcome the deep fading which may be encountered on the individual sub-channels [25].

The key features of such technology consists of support for reliable, high rate, high capacity and low latency data transfer (suitable for a wide range of services), seamless and lossless mobility (packet forwarding), improved coverage and cell-edge throughput, carrier and spectrum aggregation for wider transmission bandwidths to up to 100 MHz (see Figure 6), and enhanced support for multicast procedures (eMBMS), as will be discussed in the next subsection.



Figure 6: Carrier Aggregation in LTE-A

In Figure 7 is depicted the structure of LTE-A frame in order to introduce the resource allocation capabilities that will be illustrated in the following text. As mentioned above, the multi-user diversity is exploited thanks to the frequency vs. time grid that is resulting from the usage of OFDMA radio access.

Figure 7: LTE-A Frame Structure

The increasing attention of users respect to powerful portable devices (e.g., smart phones, tablets) triggers mobile operators to support video traffic delivery in their next generation mobile networks with a very good quality and in efficient way. In the literature, several works focus on optimization techniques to improve multimedia transmission over wireless channel. OFDMA broadband access technology, that characterizes the next generation networks, offers a vast range of solutions that can be adopted to increase the overall performance of the system. Fast algorithms for resource allocation, focusing on the asymptotic analysis of the user utility as a function of average rate, are presented in [26], while an efficient downlink scheduler for multiclass traffic in LTE, dealing with different Quality of Service (QoS) requirements, is designed in [27]. In [28], an extended QoS-aware OFDMA scheduling algorithm has been proposed for real time video delivery over LTE cellular networks, in which system throughput, application QoS, and scheduling fairness have been jointly considered to perform radio resource allocation for multiple users. Typically, mobile operators follow a conservative approach to schedule the available resource at the base station for the downlink traffic, especially for video traffic. In particular, the number of users that the base station is able to serve depends on the QoE perceived at the terminal guaranteed to each user. For example, this approach is adopted in a recent work [29], where the authors proposed a resource allocation technique for video streaming application in downlink LTE systems by using the packet delay, the signal to noise ratio and the buffer information to determine the amount of radio resources for video delivery to be assigned to users. However, the transmission scheme in LTE-A can be further developed by considering the aforementioned OFDMA structure adopted in the PHY layer and, in particular, the principle of channel transmission sharing, in which the time-frequency resource is dynamically shared between users. Therefore, multiple users can be served simultaneously by allocating multiple sub-channels, which results in having two degrees of freedom when exploiting the diversity offered by this system.



3.5 eMBMS

The MBMS (Multicast/Broadcast Multimedia Service) is an enhancement of the UMTS system which provides a point-to-multipoint capability for Broadcast and Multicast Services, allowing resources to be shared in the network [30]. It supports two modes of operation: the Broadcast mode and the Multicast mode. The objective of the MBMS is to provide a point-to-multipoint (p-t-m) service where data are transmitted from a single source entity to multiple recipients at once. However, in some cases, e.g., when only few users join a multicast session, the MBMS services can be transported using point-to-point (p-t-p) services.

The MBMS is divided into User services which involve the interactions between the Core Network and the user of the mobile terminal and Bearer services which define the interactions between the Radio Access Network (RAN) and the mobile terminal or User Equipment (UE). User services such as the MMS (Multimedia Messaging Service) or the PSS (Packet-switched Streaming Service) are built on top of the Bearer Services. The Bearer Services take care of the operation of the p-t-m radio link between the RAN and the UE, and support the capability to deliver IP multicast datagrams to multiple receivers, thus minimizing the core network and wireless resource usage, with a main focus on the radio interface efficiency. Using MBMS, multicast packets can be forwarded from one source to many receivers without overloading the network and consuming the scarce radio resources.

Figure 8:3GPP Reference Architecture for eMBMS (without UTRAN)

The eMBMS (evolved MBMS) (Figure 8) is the adaptation of the MBMS to the EPS architecture and the LTE access. In this picture, the red line represents the control path, while the data path is shown with a blue line. Due to the huge effort needed for standardizing the LTE, the eMBMS was delayed and introduced only in the second release level of 3GPP for LTE, but with major restrictions [31], such as the support of broadcast mode only (multicast mode remains available only with the GPRS, General Packet Radio Service), the use of a single cell only or of semi-static MBSFN (Multicast Broadcast Single Frequency Network) areas, where all the cells are tightly synchronized to improve the quality of reception of the UE. This strongly impacts the dynamicity of the mobility procedures and of the whole system in general.

The eMBMS involves the following entities: the UE which handles the activation/deactivation of the bearer services, the E-UTRAN which provides the Access Network and is responsible for the efficient delivery of the data to the designed service area, then the MME (Mobility Management Entity) which provides the MBMS control plane functions. The MBMS-GW (MBMS Gateway) is at the edge between the Core Network and the BM-SC (Broadcast/Multicast Service Centre). The eMBMS introduces the usage of IP multicast in the data plane between the MBMS-GW and the eNodeBs for both multi-cell and single cell transmissions. The MBMS multicast distribution tree in the backbone network starts at the MBMS-GW, which is the entity in charge of allocating the IP multicast address to be used by the downstream nodes [32]. In the GPRS model that is used for the early MBMS multicast supporting function, the GGSN (Gateway GPRS Support Node), which plays a role equivalent to the MBMS-GW in the new EPS model, is also able to receive MBMS specific IP multicast traffic and route this data to the proper IP multicast distribution address. The Source Specific Multicast (SSM) service model is used by nodes and routers as specified in RFC 4607 [33] and RFC 4604 [34]. The MBMS GW may be standalone or co-located with other network elements



such as the BM-SC or a combined S-GW (Serving Gateway) /PDN GW (Public Data Network Gateway). In summary, the Access Network stops at the M1 and M3 reference points, the Core Network is operated between the M1/M3 and the SGmb and SGi-mb reference points (see Figure 8), having the MBMS-GW at the edge while the IP network is beyond (including the BM-SC). The BM-SC is responsible for MBMS User Service provisioning and delivery. It may serve as an entry point for content provider MBMS transmissions, used to authorise and initiate MBMS Bearer Services within the Mobile Network. It is responsible to schedule and deliver MBMS transmissions.

Due to technical and business issues, the eMBMS functionality has been strongly restricted in the recent releases of the standards. The broadcast mode is provided by tightly synchronised cells organized in semi-static MBSFN areas, very similar to TV broadcast networks. User mobility is ensured by the synchronization of the cells, with potential data loss accepted and limited by the internal operation of the user services and applications. Multicast mode is not supported in the new architecture, which prevents benefiting in a dynamic way from the p-t-m bearer services when a reduced, but yet large enough, group starts receiving simultaneously the same session.



4 Design of the Wireless Access

4.1 Global overview

The objective of the Wireless Access subsystem is to design novel mechanisms in the wireless technologies that optimize the video delivery in the last hop. Its main focus is on contention based wireless accesses (e.g., WLAN or IEEE 802.11) and coordination based wireless accesses (e.g., LTE-Advanced from 3GPP), completed by the definition of an abstract interface hiding the technology specifics to the higher layers when executing cross-layer optimizations. As a consequence, the Wireless Access is split into three main functional blocks (see Figure 9):

the Layer 2.5 abstraction component provides the generic interfaces between video specifics (i.e., transport, services and mobility) and wireless accesses,

the WLAN component has technology-specific functions addressing all mechanisms related to the contention-based wireless accesses,

the LTE-Advanced component, on the contrary, contains the optimization features for coordination-based wireless accesses.

Figure 9 : Global view of the Wireless Access sub-system

On top of the technology-specific entities, the project considers the L2.5 abstraction component which provides to the upper layers the information and configuration mechanisms related to the video characteristics that are available in the wireless technologies, in an abstract way. The translation from generic video parameters into video specific extensions is accomplished by the underlying heterogeneous technologies. The abstract interface is designed as an extension of the standard IEEE 802.21 Media Independent Handover Services (MIH) and improves it taking into account the characteristics of video flows. In the MEDIEVAL architecture, it interacts with both the Video Mobility and the Transport Optimization subsystems, to enable cross-layer optimization.

For each technology, cross-layer optimizations are introduced to enhance the efficiency of the video flows delivery over the air interface, expressed as a set of common abstract functions:

• Provision of a cross-layer solution that, by avoiding deep packet inspection, is able to perform rate adaptation based on the channel conditions. This is achieved by performing a selection of the received video



frames based on the marking previously introduced in the IP packets. This operation is accomplished before video frames are actually managed by the L2 protocols, according to the receiver capabilities, in the Video Frame selection function.

• Provision of an enhanced medium access strategies, in particular allocation strategies for LTE Advanced, and MAC functionality able to dynamically auto-configure its behaviour based on load conditions for WLAN, which will take into account the characteristics of the video flows. This functionality is provided by the cooperation of the Abstraction QoS Mapper located at the L2.5 abstraction and the Dynamic Configuration function located at each specific technology. The Abstraction QoS Mapper works by defining a utility function for each user which permits to allocate resources in an optimal manner, providing then the optimal set of parameters to the Configuration Function at each technology.

• Provision of enhanced multicast mechanisms. In the case of WLAN, this is performed by analyzing the different groupcast mechanisms defined in IEEE 802.11aa and providing rules in order to choose the most suitable one depending on the load and network state. In the case of LTE-A, specific enhancements to improve the efficiency of eMBMS bearer service are considered, exploiting the cross-layer optimization defined in the project.

• Analysis of the suitability of Jumbo frames as a mechanism for delivering high bandwidth video to the end users. The introduction of jumbo frames mechanisms in the system is considered to increase the video performance, due to its capability to handle very large frames with MTU sizes greater than 1500 bytes.

Although the major part of the optimization envisioned can be expressed as abstract optimization that will span more than just one technology, the project also focuses on technology specific optimization such as the introduction of relaying functions at PDCP level in the LTE-A access. This functionality permits to extend the network coverage while still benefiting from the transmission quality and error recovery present in the link layer protocols.

Finally, a Monitoring function is present for each of the technologies. This function is responsible to dynamically retrieve the information related to the access network availability and quality and provide it to the upper layers through the abstract interface. Moreover, it senses its environment searching for new candidate networks and analyzes their capacity, user registration level, bandwidth usage and remaining resources.

4.2 L2.5 Abstraction (L25)

The L2.5 Abstraction component provides the media independent interfacing between high-level and link-layer components. The first ones are able to execute their functionality in a technology independent way, by mapping their requests into generic 802.21 commands and events, instead of using technology-specific interfacing. The L2.5 Abstraction is then able to receive these messages and forward them to the necessary technology. This enables the modules responsible for managing the link layers, to receive commands (and generate events) using the common format of the IEEE 802.21 standard. Also, the L2.5 Abstraction is able to provide this behaviour in a remote way, by enabling commands and events to be sent towards entities elsewhere in the network, using the MIH Protocol between two different L2.5 Abstraction components. In this way, this component acts as a mediator, enabling MIH-Users and link-layer management modules to interact directly, despite being in two different physical entities.

In MEDIEVAL, the L2.5 Abstraction is realized in two different entities: the ODTONE implementation and the Abstraction QoS Mapper. The first one implements the standard IEEE 802.21 MIHF services and mechanisms, while the second adds novel behaviour to the same components and services to better support new MEDIEVAL specific procedures. Both modules are detailed in the next sections.



Figure 10 : Modules in the L2.5 Abstraction Component

4.2.1 ODTONE 802.21 implementation

The standard MIHF will use an already available implementation of IEEE 802.21, ODTONE, which stands for Open Dot Twenty ONE, and is an open-source operating system independent implementation of the IEEE 802.21 framework. This implementation is written in C++ using Boost libraries, allowing the support of several mechanisms such as portable datatypes, networking and low-level I/O in different platforms (i.e., Microsoft Windows, Linux and Android).

ODTONE implements the standardized Media Independent Handover services, composing the Media Independent Event Service, the Media Independent Command Service and the Media Independent Information Service, which are managed in the Media Independent Handover Function. ODTONE is able to work both in a local or remote way, through the usage of the MIH Protocol, which is able to be carried over UDP or TCP.

The unique design of the ODTONE implementation allows for easy coupling of MIH mechanisms to both link layers and MIH-Users in existing nodes. Concretely, acknowledging that current network interfacing cards do not yet integrate 802.21 in their drivers, implementations require tightly coupled solutions to interface with the link layers, that limit those implementations’ scope and flexibility. ODTONE counters this through an ingenious design where the MIH_SAP and MIH_LINK_SAPs, instead of being software API’s, are in fact internal sockets which are able to understand the MIH Protocol. In this way, the MIH Protocol is re-used internally, between the MIHF, link layers and MIH-Users.

To support this design, ODTONE provides a MIH Protocol library which can be included in any MIH-User code, or link layer management code. In this way, existing link layer software or driver mechanisms implemented by the different partners need only to include the MIH Protocol library, besides adding MIH processing behaviour. Similarly, high level entities just require the inclusion of the same library and the ability to process the received messages. Both MIH-Users and link layer modules require the means to send and receive messages through sockets towards the MIHF.

The ODTONE implementation is available at http://hng.av.it.pt/projects/odtone and provides simple event and command examples for WLAN link layer modules (currently, samples for Microsoft Windows and Linux exist) as well as a testing MIH-User.

ODTONE also provides an implementation of the Information Elements Basic Schema in binary and RDF, which can be used for creating MIIS Servers.

4.2.2 Abstraction QoS Mapper (AQM)

The objective of this module is to provide a comprehensive mechanism for the higher layers (Mobility Management and Transport Optimization) to be able to map their requirements in terms of QoS or even QoE to a set of abstract parameters that the lower layers can understand. In this way, the higher layers will provide to this module, through the Abstract Interface, the flow requirements in terms of QoS, Multicast and drop



eligibility. This module based on that information maps the flow requirements to a certain traffic class or L2 parameters that will be translated to the appropriate module at L2 so the specific technology is configured accordingly. For example, consider a SVC video flow consisting of two layers. Packets belonging to each layer will be marked at source and this marking will be propagated through the network. The Abstraction QoS Mapper module, upon reception of the information regarding the marking, configures the access network (802.11aa and Dynamic Configuration module for WLAN and Video Frame selection and Interface configuration for LTE) in such a way that each layer receives a differentiated service. This service may be a different drop eligibility or even a different QoS class treatment.

In order to do so, and to simplify as much as possible the implementation of this module, the interface with lower layers is bidirectional, enabling the direct gathering of information about the configuration of the link layers. In this way, this module can be implemented with the minimum amount of states.

4.3 Contention-based wireless access (WLAN)

Figure 11 : Modules in the WLAN Component

4.3.1 802.11aa and Dynamic configuration (WMDC)

The functionality of this module is threefold. In first place it is the module in charge of configuring the actual L2 parameters on the WLAN physical interface. In second place, it is the module in charge of reading the marking of each packet and queue it on the appropriate queue and apply the selected groupcast mechanism. Finally it is also in charge of keeping track of the actual configuration of the interface and propagating this information to the higher layers by using the abstract interface.

Regarding the different attributes of each flow, the WMDC module receives commands from the AQM. The AQM performs the mapping between the actual marking carried on the packet and the type of service provided by the wireless technology. In this way, the AQM provides to the WMDC the list of attributes per flow, namely the QoS class of the flow, the drop eligibility and if multicast should be used. Based on this information, the WMDC computes and applies the best L2 unicast and multicast configuration.

For unicast traffic based on the different intra-Access Classification (ACs), the different congestion window of the stations and the average bitrate required by each station, the WMDC is able to compute the optimal configuration for each station that provides the best QoS to each flow.

For multicast traffic, based on the configuration of each station for unicast and multicast traffic, the number of stations and the characteristics of the flow, the WMDC implements an algorithm that dynamically adapts the groupcast mechanism used. In this way, the AP can switch dynamically between the GCR-DMS, GCR-Unsolicited-Retry or GCR-Block-Ack delivery modes, taking into account that only one delivery mode may be active at any given time for each GCR group address.

In order to process the packets, the WMDC uses several classifier functions. In first place, the packet is queued based on the QoS label included in the Flow ID/TOS field on the IP header. For audio and video packets (AC_VI and AC_VO), a secondary selection is performed based on the drop eligibility mark, hence



packets are queued in the AC_VI/AC_VO queue if the packet is not eligible for dropping. Otherwise, the packets are queued on the alternate AC queues (AAC_VI, AAC_VO, see section 3.2.1). Finally based on the flow id provided by higher layers (Five tuple) and the multicast characteristics of the flow, a different groupcast mechanism is selected.

4.3.2 WLAN Monitoring Module (WLANMM)

Operators who have the ability to switch the session of a user among access technologies (vertical handover), can better manage the network resources and better meet the requirements of the users (i.e., personal broadcast/multicast services). For instance, as soon as the quality level of a video is no longer guaranteed in the LTE network, the flow can be off-loaded to the WLAN hotspot exploiting the standard IEEE 802.21 deployed and extended in the MEDIEVAL architecture. Therefore, the new WLAN connection permits to exploit a better channel capacity, lower network congestion and a decreased latency.

The objective of this module is to provide dynamic information related to WLAN network availability and quality to the Layer 2.5 Abstraction (L25). Specifically, this module provides dynamic information as the number and type of registered users, the system capacity, the number of active users, etc. To make available this information, this module senses the environment to look for WLAN networks that can be used by the LTE mobile user, as long as the link quality is sufficient to deliver the video flow.

4.3.3 Jumbo frames mechanisms (JMB)

The Jumbo Frame feasibility for WLAN aims to provide mechanisms that will take advantage of frames with MTU sizes greater than 1500 bytes. Due to the complexity of the wireless medium and the current state of the art in terms of wireless devices, this study aims to provide theoretical or simulation results. Also, the designed mechanisms will consider the high degree of flexibility provided in the MEDIEVAL architecture, and therefore will aim to have a negligible impact in the current or upcoming architectural developments.

Concretely, the deployment of jumbo frames will have to consider not only the last hop towards mobile users (which is wireless), but also to consider the full path from mobile users to the content provider. This means that different media will be crossed at different points of the network, which need to be aware of jumbo frames. Also, the mobility of users can seriously impact and alter conditions experimented by the mobile terminals, and thus measures are needed. Also, considering the number of users associated to the same Access Point, the usage of greater MTU sizes can cause fairness issues in multi-user environments. As such, the development of new resource allocation through, for example, channel hoping, is required. Otherwise, jumbo ability can be emulated at higher layers of the protocol stack, impacting only queues at the lower layers.

For evaluation on this matter, the usage of jumbo frames is being addressed in the wireless environment, so this means the last hop, between MN and PoA. In order to simplify things, evaluation will contemplate the PoA acting as a PoS, in order not to mix wireless jumbo frames, with wired jumbo frames. As such, at a first stage, this module represents driver modifications at the MN and Access Point, and it will take advantage of optimal wireless link conditions with which to adapt jumbo-related parameters to enable this feature.



4.4 Coordination-based Wireless Access (LTE-A)

Figure 12 : Modules in the LTE-A Component

4.4.1 Video frames selection and interface configuration (VFSIC)

The Video frames selection and interface configuration (VFSIC) combines two functional sub-entities. The first one operates a selection or prioritization of the video frame and is responsible of selecting and potentially dropping part of the traffic in the case when the wireless access is congested. The second one handles the configuration of the interfaces and flows when it receives commands through the abstract interface, translating them into the procedures available according to the LTE protocols.

The User Equipment capabilities information, announced at network attachment, is exploited to improve the bandwidth occupation of the video signal flowing in the last wireless hop of the network. Based on the information received through the abstract interface, the control plane instructs the user plane entities to select and transmit towards the air interface only those video frames which are adapted to the receiving device capabilities and the load on the wireless link. This operation is accomplished in the eNodeB, after the packets have been decapsulated from the GTP-U tunnel if it exists and before it is encapsulated in the PDCP protocol. This capabilities information is provided by the User Equipment when it attaches the network and is stored in the UE context. It is provided to the upper layers through the abstract interface for further exploitation. In the eNodeB, if necessary, it can be combined with the packet marking of the video signal, based on the svc layers and on the priorities set in the Transport Optimization sub-system, to reduce the flow to the quality level corresponding to the equipment. Each video packet is marked by the application or service layer in the IP header. This information is provided to the transmitting entities, which then prioritize or even drop the video packets, thus reducing the bandwidth occupation in the downstream nodes, and especially in the last wireless hop. In the case of a unicast session, this filtering is performed in the eNodeB at the entry of the cellular network. In the case of an eMBMS multicast session, this information is correlated with the knowledge of the users who joined a specific service in each cell (MBMS UE Context), and the filter is applied accordingly.

The interface and flows configuration function handles the dynamic configuration of the LTE protocols based on the information received from the upper layers through the abstract interface Command Service. These commands can address the interface itself (power up, power down) or the configuration of the data radio bearers (Link activate resources, link deactivate resources) corresponding to the video flows. The power up/ power down commands trigger the various procedures for the network attachment or detachment of the mobile node and establishment of a default radio bearer. The resources related commands trigger procedures for the setup/ release of a PDP context and a data radio bearer allocated to the flow, as explained in the description of the Flow Manager in deliverable D4.1 [42]. In all cases, the corresponding NAS or RRC procedures are triggered in the LTE-A network interface.

4.4.2 Cognitive exploitation of cooperative technologies (CECT)

The presence of Cognitive Exploitation of Cooperative Technologies (CECT) module is triggered by the need of providing a medium access strategy that is able to exploit both the capabilities of each user



connection and the potential of the MEDIEVAL system architecture, by taking into account the characteristics of video flows and identifying techniques to interact with upper layers. This is accomplished in this module by designing a novel medium access strategy which exploits the diversity provided by the channel transmission sharing (time-frequency resource is dynamically shared between users) at the scheduler, located in the base station, to maximize the number of users that can be served within the cell. This results in drawing a mixed scheduling policy region where the mobile operator can tune its own operating point, in order to flexibly allocate resources to a high number of end users, while guaranteeing a target video quality. In particular, the allocation strategy proposed exploits the presence of the Measurements and Medium Access Strategies (MMAS) and cross-layer optimization (via VFSIC/L2.5 Abstraction) to allocate as many users as the LTE-A wireless channel can admit, keeping steady the perceived quality of users. For example, gather channel measurements performed in MMAS is crucial to optimally allocate the available resources (e.g., knowing the load of the cell at network level or the quality of the links perceived by the mobile terminal improves the decision-making algorithms in the upper layers entities).

The first step of this algorithm is to take into account a utility function for each active user, which depicts the quality perceived by each user. In the classical medium access approaches, the resource allocator finds the maximum number of users that are allowed to access the wireless channel by fixing a target rate, TH, which gives a certain quality perceived by users. Following this scheme, users with poor channel conditions need a bigger amount of resources with respect to users with a good channel conditions. Unlike the previous approach, we define a new medium access strategy with two thresholds. We set a first threshold TH1 (lower than the aforementioned TH) on the video quality that is granted to all users. However, the resources allocated are reduced with respect to the first case because of the lower value of TH1. The remaining part of the available resources is allocated based on TH2 (greater than TH, thus greater than TH1 too), only for users with the better channel conditions. Thus, we are able to increase the number of users served (keeping as much steady as possible the perceived quality of the video), exploiting the diversity of the wireless channel. Therefore, the output of this procedure is an allocation map that permits to order all users following the requirements imposed by the quality of the link and the higher layers.

4.4.3 Measurements and Medium Access Strategies (MMAS)

As already mentioned above, the link quality information between users and eNodeB is at the basis of a medium access strategy. Therefore, the first function of this module is to gather all the LTE-A wireless channel measurements that will be used in Cognitive Exploitation of Cooperative Technologies (CECT). In addition, this module receives from Video frames selection and interface configuration (VFSIC) other measurements coming from LTE layer 2 that need to be reported to the Media Specific Service Access Point (SAP) via Media Independent Event Services (MIES). This choice permits to have only one interface that reports events for vertical handover decisions. Besides these measurements that come from VFSIC, the Measurements and Medium Access Strategies (MMAS) module is in charge of reporting other measurements that need to be reported to the Media Specific SAP via MIES, in order to offer to the upper layers the required information. Moreover, MMAS receives the allocation map from CECT and performs the medium access strategy that permits to optimally allocate users into the available resources.

4.4.4 Jumbo frames mechanisms (JMB)

Jumbo frames in LTE-A share the same issues presented in section 2.3.3 for the WLAN case. However, when considering specific fairness solutions, cellular access offers other methods which consider the use of different codes per user, thus avoiding wireless medium hogging by jumbo-enabled devices. Nevertheless, the aim of the jumbo frame deployment in MEDIEVAL is to provide a flexible solution able to be used by both WLAN and LTE-A access networks. Thus, the possibility of deploying jumbo frames as an emulated concept by other layers in the network protocol stack is also an option. In terms of evaluation, wireless utilization of jumbo frames between the MN and the base-station will be considered, with the content source being part of the PoA infrastructure, or at least be as close to it as possible. The studies evolved around the feasibility of Jumbo in LTE-A environments will also address specific link characteristics of this wireless technology, for the deployment of Jumbo behaviour.



4.4.5 E-MBMS Support (EMBMS)

In LTE-Advanced, multicast mainly means to support and extend the evolved Multimedia Broadcast and multicast Services (eMBMS) Bearer service specified in the LTE standards. The eMBMS support module provides several levels of QoS for the Multicast Traffic Channel (MTCH), in order to improve its efficiency for the transfer of the video frames. Multicast data are transported in an unacknowledged mode radio bearer, as usually defined for streaming flows in the 3GPP QoS (Quality of Service) architecture.

Whenever possible, the opportunity of transferring the flow in a multicast bearer (eMBMS) is exploited, with such improvement as the optimization of the MBMS Session Start procedure thanks to a cross layer interaction with the Mobility and Video Services components. This is essential to some of the user services providing video delivery identified in the project, while improving their overall management. The “MBMS Session Start” procedure is optimized to convey the maximum amount of information at once and reduce the number of steps needed for its completion. In particular, some cross-layer parameters exchange are introduced, with the Mobility entities in the case of handover, and with the video application and service entities in case of session initial establishment, to flatten the procedure. With this mechanism, the mobility is made more dynamic by introducing some bearer service preparation earlier in the procedure. The MBMS session parameters can be received while the first UE is preparing for the handover and before the actual handover execution time. In the case when the handover implies a change of reception parameters for the UE, these are provided to the UE directly, before the handover, bypassing the time to receive and decode the MCCH (MBMS point-to-multipoint Control Channel).

Another important feature is the counting of listening mobiles in each cell by the eNodeB. This information is interesting to report the usage of the multicast session and possibly move the flow back to a point-to-point bearer if only one user in the cell is listening. To avoid disturbing other types of traffic (e.g., voice) that could take place simultaneously, a coordinated control of unicast and multicast communications in a cell providing the eMBMS service is established. Supporting multicast and video traffic in eMBMS influences also the way the data traffic is handled in the LTE-A interfaces. They must be able to forward the IP multicast packets towards the air interface from the eNodeB in the multicast bearers and enable the reception of the packets in the mobile.

The configuration of the radio access also takes into account the specific spectrum usage and the resource allocation. Multicast flows require bandwidth reservation based on the dedicated eMBMS Bearer parameters received from upper layers and the worst CQI (Channel Quality Indicator) of multicast clients measured in the lower layers. This results in a bad spectrum usage because users with a robust link underutilize the bandwidth resources. The proposed solution combines H.264/SVC (Scalable Video Coding) together with cross-layer optimization to dynamically tune the QoE for each user according to the channel feedback.

4.4.6 PDCP-level Relay (L2PRLY)

In the standard version of LTE, all the IP packets flowing in the network are exchanged between the UE and the PDN-GW (or MBMS-GW in case of multicast) through the eNodeB and the SGW. A first level of relay at Physical Layer level, aiming to extend the network coverage beyond the Node-B has been introduced in the standards. However, such a solution propagates the inter-cell interference present in the RF signal and introduces an additional interference from to backbone signal on the relayed signal. In order to get rid of that problem, we introduce another relaying scheme. This scheme extends the network beyond the Node-B, but forwarding the packets at PDCP level, in order to benefit from the transmission quality and error recovery introduced by the MAC, RLC and PDCP layers. A similar solution has recently been introduced in the latest version of the LTE-A (release 10 of 3GPP at stage 2 level) and is still under detailed definition (release 11 of 3GPP at stage 3 level). This type of relay impacts mainly the PHY layer configuration and the radio control procedures.

In the L2PRLY function, a radio configuration similar to 3GPP is adopted. The eNodeB and relay PHY signals are supposed to be differentiated either by operating on a different frequency or by time-division multiplexing. This module thus focuses mostly on the problems related to the Radio Control procedures, e.g. radio attachment of the LTE relay to the LTE eNodeB (called "donor eNb" in the 3GPP), attachment of a mobile node to the cellular system through the LTE relay, session setup and tear down, detachment of the mobile node or LTE relay from the network. As a first step, it is expected that the LTE relay serves as an extension of the network to increase its capacity and thus is not moving.



This scheme can be reused and extended to a completely different objective in the case of multicast in conjunction with the Personal Broadcast Service. When the source UE and the receivers are located in the same cell (or in cells belonging to the same area), the route optimization, when available, can make the IP packets be transferred directly from the source bearer to the destination point-to-multipoint bearer, without going up to the MBMS-GW.

4.5 Study of parameters available in the technologies and their abstraction

4.5.1 QoS parameters

The QoS abstract parameters provided by the L2.5 interface are defined in the IEEE 802.21 standard as generic link QoS parameters. In MEDIEVAL, different traffic classes are supported, therefore, per Class of Service (CoS) accuracy parameters need to be maintained in order to monitor how individual traffic classes are faring. The generic per CoS link QoS parameters defined in IEEE 802.21 are:

a) Link Throughput: Number of bits successfully received divided by the time it took to transmit them over the medium.

b) Link Packet Error Rate: Ratio between the number of frames received in error and the total number of frames transmitted in a population of interest.

c) Supported Classes of Service: represents the maximum number of differentiable classes of service supported by the link.

d) Class of Service Parameters List: For each of the supported classes of service the following parameters are defined:

1) Class Minimum Packet Transfer Delay: Minimum delay over a class population of interest.

2) Class Average Packet Transfer Delay: Mean of the delay over a class population of interest.

3) Class Maximum Packet Transfer Delay: Maximum delay over a class population of interest.

4) Class Packet Delay Jitter: Standard deviation of the delay over a class population of interest.

5) Class Packet Loss Rate: Ratio between the number of frames that are transmitted but not received and the total number of frames transmitted over a class population of interest.

The IEEE 802.21 standard also provides a mapping between previously described generic QoS parameters and those used by different technologies. Following tables provide the mapping with IEEE 802.11 and 3GPP LTE-A, respectively.

IEEE 802.21 link QoS parameters

Related IEEE 802.11 parameters

IEEE 802.11 IE Name

Note

Throughput Not currently supported. Measurement is defined as the total number of octets transmitted / Measurement duration

Packet error rate TransmittedFragmentCount MulticastTransmittedFrameCount FailedCount ReceivedFragmentCount (See NOTE) MulticastReceivedFrameCount FCSErrorCount (See NOTE) TransmittedFrameCount RetryCount MultipleRetryCount FrameDuplicateCount RTSSuccessCount RTSFailureCount



ACKFailureCount Supported number of CoS

4 for IEEE 802.11e, 8 for HCCA, 1 for non-IEEE 802.11e systems

CoS minimum packet transfer delay

Transmit Delay Histogram (See NOTE)

Transmit Stream/ Category Measurement Report

Trigger (Option) (only to specific STA)

CoS average packet transfer delay

Average Transmit Delay Transmit Stream/ Category Measurement Report


CoS maximum packet transfer delay

Transmit Delay Histogram (See NOTE)



CoS packet delay jitter

Transmit Delay Histogram Average Transmit Delay (See NOTE)



CoS packet loss rate QoSTransmittedFragmentCount (See NOTE) QoSFailedCount QoSRetryCount QoSMultipleRetryCount QoSFrameDuplicateCount QoSRTSSuccessCount QoSRTSFailureCount QoSACKFailureCount (See NOTE) QoSReceivedFragmentCount QoSTransmittedFrameCount QoSDiscardedFrameCount QoSMPDUsReceivedCount QoSRetriesReceivedCount

STA Statistics Report

Transmitted MSDU Count (See NOTE) MSDU Discarded Count (See NOTE) MSDU Failed Count MSDU Multiple Retry Count QoS CF-polls Lost Count



NOTE —This parameter is most likely to be used to directly derive IEEE 802.21 LinkQoSParameters Table 1: QoS parameter mapping for IEEE 802.11 from IEEE 802.21

IEEE 802.21 link QoS parameters

Related 3GPP LTE-A parameters

Throughput Scheduled IP Throughput Packet error rate Packet Discard Rate Supported number of CoS Quality of Class Indicator (QCI) + RLC parameters CoS minimum packet transfer delay

Minimum Packet Delay per QCI

CoS average packet transfer delay

Average Packet Delay per QCI

CoS maximum packet transfer delay

Maximum Packet Delay per QCI

CoS packet delay jitter Delay Jitter CoS packet loss rate Packet Loss Rate on the User Equipment air interface (Uu)

Table 2: QoS parameter mapping for 3GPP LTE-A



4.5.2 Measurements

The monitoring capabilities provided by the L2.5 abstraction use extensively the reporting mechanisms provided by the IEEE 802.21 standard. Basically, this standard allows the MIH user to gather information about the lower layers through two mechanisms:

Direct query (through the MIHF) regarding any of the parameters available for measurement. This method uses the command MIH_Link_Get_Parameters from the MIH_SAP and the command Link_Get_Parameters from the LINK_SAP.

Periodic or upon threshold crossing event notification, reporting the value of a certain parameter. In this case, a registered MIH user is able to set up thresholds and timers for selected link measurements. Each time any of the monitored metrics crosses a certain threshold or a timer expires, the MIHF will receive an event from lower layers, which will be forwarded to the appropriate MIH user. This method uses the command from the MIH_SAP MIH_Link_Configure_Thresholds to set the appropriate threshold levels, and the event MIH_Link_Parameters_Report to send the event to the target MIH user. From the LINK_SAP, this method uses the Link_Configure_Thresholds command to configure the thresholds in the actual network card, while it uses the Link_Parameters_Report event to notify the MIHF of a threshold crossing.

The actual message sequence chart of the configuration and reporting of both mechanisms can be found in section 5.2.2.

Once the different mechanisms used by IEEE 802.21 (and hence MEDIEVAL) are understood, it is worth to notice that not all the information of the network adapter is available through both mechanisms. IEEE 802.21 defines two types of reporting variables. The first one corresponds to measurements taken in the network card. The second one corresponds to information regarding the configuration of the interface, such as its mode of operation (Normal, Power Saving or Down) or Channel ID. The former information can be accessed using both mechanisms but the second information can only be accessed through the direct polling.

Regarding the different information that can be gathered from the network interfaces, the measurements can be divided in generic parameters (common to all technologies), technology specific and QoS related. The QoS related parameters have been described in detail in section 4.5.1. It is also worth to notice that IEEE 802.21 has not defined any metric that can be directly measured for UMTS and LTE. This is due to the fact that LTE being defined by the 3GPP, direct access to any of the metrics available at this kind of interfaces has been out of the scope of the IEEE specifications. However, in MEDIEVAL, we introduce a set of metrics derived from the 3GPP specifications to enable the cross layer optimization.

The generic parameters available to any technology that can be reported using IEEE 802.21 mechanisms are the following:

Data Rate

Signal Strength

Signal over interference plus noise ratio

Throughput (the number of bits successfully received divided by the time it took to transmit them over the medium).

Packet Error Rate (representing the ratio between the number of frames received in error and the total number of frames transmitted in a link population of interest).

The knowledge gained from the above parameters can be improved by asking for the technology specific measurements. In the case of WLAN, the parameters available to report are the following:

RSSI of the beacon channel, as defined in IEEE Std 802.11-2007. (This is applicable only for an MN.)

No QoS resource available. This applicable when the traffic stream to be transmitted is on an access category configured for mandatory admission control and the request for bandwidth was denied by the available APs in the access network



Multicast packet loss rate.

Commonalities and abstract parameters between WLAN and LTE-A technologies

In the following, WLAN technology parameters are compared with the ones available in LTE-A, in order to get the commonalities used to define the abstract parameters.

IEEE 802.11 measurements 3GPP LTE-A measurements

SSID Service Set Identifier Cell Id eNodeB Cell Identifier

Rates List of supported rates MCS Modulation and Coding Scheme

Channel Channel number RB Resource Block

SNR Signal to Noise Ratio SNR Signal to Noise Ratio

FER Frame Error Rate BLER Block Error Rate (Transport Block)

BER Bit Error Rate BER Bit Error Rate

Tx_power Transmit Power (dBm) Tx_power Transmit Power (dBm)

Tx_frames Number of transmitted frames

Tx_RBs Number of transmitted packets on the RBs

Rx_frames Number of received frames

Rx_RBs Number of received packets on the RBs

Table 3: Commonalities between WLAN and LTE-A

IEEE 802.11e/aa MAC parameters 3GPP LTE-A parameters

AC Queue Access Category queue: AC_BK, AC_BE,

AC_VI, AAC_VI, AC_VO, AAC_VO

EPS Bearer ARP, QCI

QoS parameters – MAC Queue

CWimin Minimum contention

window per ACi X /

CWimax Maximum contention

window per ACi X /

AIFSi Arbitration Interframe Space per ACi

X /

TXOP_limiti Transmission Opportunity limit per ACi

X /

Table 4: QoS and multimedia extensions for IEEE 802.11 and LTE-A

From the above information, it is clear that the amount of information available for reporting in the current IEEE 802.21 is quite reduced and not enough for the purposes of MEDIEVAL. Although we consider the standard as a base line, we aim at extending the parameters available for reporting. This extension to IEEE 802.21 is explained in more detail in section 4.6.



4.6 Proposed extensions to IEEE 802.21

4.6.1 Global Overview

IEEE 802.21 provides a set of services that aim to optimize handovers in heterogeneous environments, as described in section 3.1.

MEDIEVAL aims to, not only use these existing services, but also complement and extend them with video awareness.

Video-Events from MIH-Users

These are part of the MIH-Users event service. Whenever it is detected that the Video Services stream quality reaches previously provided thresholds these will be sent to MIH-Users thus triggering appropriated adaptations and optimizations.

Video-related Information Elements

The video related Information Elements allow the query of specific static parameters related with video services between MIH elements,

Multicast transport of MIH signalling

The Multicast transport of MIH signalling allows the delivery of MIH signalling simultaneously to different MIH elements in different locations. This makes use of Multicast delivery services and allows a faster and more efficient delivery of MIH signalling messages.

In order to accommodate the new functionalities described above, some of the 802.21 primitives need to be extended as described below.

4.6.2 New Information Elements for the MIIS

The MEDIEVAL project will consider the introduction of new Information Elements enhancing the standard MIIS with more information able to support the new MEDIEVAL mechanisms. The new introduced Information Elements are categorized in the following manner:

Jumboframes Mechanisms

The MIIS will be able to provide indication of Jumboframe support from the different PoAs. This will consist of a new Information Element, of a Boolean datatype, and a second Information Element highlighting specific jumbo-related parameters such as MTU. This set of parameters is, however, yet to be defined.

Multicast Capabilities

The support of Multicast mechanisms such as MBMS can be used (both by mobile terminals or network decision entities) as a choice parameter regarding handover candidates. As such, the MIIS will be enhanced with a new Information Element indicating if PoAs support multicast mechanisms or not.

PDCP Relay Capabilities

Relaying capabilities provide extended behaviour to cellular networks which can originate specific handover candidacy opportunities. As such, a new Information Element will be created to identify networks which support this mechanism.

QoS Capabilities

IEEE 802.21 supports a simple QoS parameter list with which mobility decision entities can better select handover candidates. MEDIEVAL will enhance this list with new parameters that enable video-related scenarios while enabling optimum handover execution. However, this list of parameters is still under definition.

New Wireless Interfaces Support

Considering the increasing heterogeneity of networks in future deployments of wireless accesses, MEDIEVAL considers the definition of more wireless network types than the ones defined in the standard, considering future developments of existing technologies and even other kinds of accesses. As such,



MEDIEVAL enhances the network type and subtypes definitions of Information Elements from the 802.21 standard, allowing the future definition of more network types. These changes have been proposed as modifications to the 802.21b standard. Details on these specific changes can be viewed in detail in Appendix I, where enhancements to already-existing Information Elements with the respective new network type possibilities are exemplified.

4.6.3 Link_Action

This section details the changes to the Link_Action.request primitive in order to accommodate the operation of the Media Specific components optimizations. It is shown in a format similar to what would be required to a contribution to the standards.

1.1 Link_Action.request

1.1.1 Function

This primitive is used by the MIHF to request an action on a link-layer connection to enable optimal handling of link-layer resources for the purpose of handovers.

The link-layer connection can be ordered (e.g., to shut down) to remain active, to perform a scan, or to come up active and remain in stand-by mode. The command execution delay time can also be specified for cases where the link-layer technology under consideration supports the action.

Through the MEDIEVAL extensions, this command enables in addition the operation of the cross-layer interactions for configuration of the packet mark processing and the configuration of the video flows on the Link access.

1.1.2 Semantics of service primitive

Link_Action.request ( LinkAction, ExecutionDelay, PoALinkAddress )

Parameters:

Name Data type Description

LinkAction LINK_ACTION Specifies the action to perform.

ExecutionDelay UNSIGNED_INT(2) Time (in ms) to elapse before the action needs to be taken. A value of 0 indicates that the action is taken immediately. Time elapsed is calculated from the instance the request arrives until the time when the execution of the action is carried out.

PoALinkAddress LINK_ADDR (Optional) The PoA link address to forward data to. This parameter is used when DATA_FWD_REQ action is requested.

Table 5: Link_Action.request parameter list

In order to use the MEDIEVAL extensions, the following modifications to the standard are required:

Change the LINK_ACTION (table F.4 on IEEE 802.21) data type to include LINK_AC_PARAM which can contain possible parameters:



LINK_ACTION SEQUENCE(LINK_AC_TYPE, LINK_AC_ATTR, LINK_AC_PARAM )

Link action

Table 6: LINK_ACTION modifications to table F.4 from IEEE 802.21

Add new LINK_AC_TYPES: FLOW_ATTR, LINK_ACTIVATE_RESOURCES, LINK_DEACTIVATE_RESOURCES (table F.4 on IEEE 802.21)

LINK_AC_TYPE UNSIGNED_INT(1) An action for a link. The meaning of each link action is defined in Table F.5. 0: NONE 1: LINK_DISCONNECT 2: LINK_LOW_POWER 3: LINK_POWER_DOWN 4: LINK_POWER_UP 5: FLOW_ATTR 6: LINK_ACTIVATE_RESOURCES 7: LINK_DEACTIVATE_RESOURCES 8–255: (Reserved)

Table 7: LINK_AC_TYPE additions to table F.4 from IEEE 802.21

Add the definition of the newly created LINK_AC_PARAM data type to table F.4:

LINK_AC_PARAM CHOICE(NULL, FLOW_ATTRIBUTE, RESOURCE_DESC).

The choice of FLOW_ATTRIBUTE is used when the FLOW_ATTR action is selected in order to provide the mark and multicast configuration to be set up for the flow. The choice of RESOURCE_DESC is used when LINK_ACTIVATE_RESOURCES or LINK_DEACTIVATE_RESOURCES actions are used.

Table 8: LINK_AC_PARAM additions to table F.4 from IEEE 802.21

Define the FLOW_ATTRIBUTE and RESOURCE_DESC data type (table F.4):

FLOW_ATTRIBUTE SEQUENCE( FLOW_ID, CHOICE (NULL, MULTICAST_ENABLE), CHOICE (NULL, SEQUENCE(MARK,QOS)) CHOICE (NULL, SEQUENCE(MARK,DROP_ELIGIBILITY)) )

The choice of FLOW_ATTRIBUTE is used when the FLOW_ATTR action is selected in order to provide the mark and multicast configuration to be set up for the flow.

RESOURCE_DESC SEQUENCE( LINK_ID, FLOW_ID, CHOICE(NULL, LINK_DATA_RATE), CHOICE(NULL, QOS), CHOICE(NULL, JUMBO_ENABLE) CHOICE(NULL, MULTICAST_ENABLE) )

The choice of RESOURCE_DESC is used when the LINK_ACTIVATE_RESOURCES or DEACTIVATE action is selected in order to identify and configure the flow subject to action

Table 9: FLOW_ATTRIBUTE and RESOURCE_DESC additions to table F.4 from IEEE 802.21



Define each of the new data types to be included (table F.4):

PORT OCTET(2) 2 octets defining the port used by the transport protocol

IP_TUPLE SEQUENCE(IP_ADDR, PORT) Tuple consisting on an IP address and the port

PROTO ENUMERATED The transport protocol used: 0: TCP 1: UDP

FLOW_ID SEQUENCE(IP_TUPLE, IP_TUPLE, PROTO) Five tuple, consisting on the source and destination address and ports plus the transport protocol used.

MARK CHOICE(BITMAP(6), BITMAP(20))

6 Bits (IPv4) or 20 Bits (IPv6) mask to be applied to the DSCP or Flow Label field of IPv4/v6 header

QOS CHOICE( SEQUENCE( MAX_DELAY, BITRATE, JITTER, PKT_LOSS), COS )

The choice of delay and bitrate corresponds to a new flow being signalled through the MIH_SAP, the COS parameter is used after being processed by the WP3 AQM.

MAX_DELAY UNSIGNED_INT(2) Maximum delay supported by the flow in ms

BITRATE UNSIGNED_INT(4) A type to represent the maximum data rate in kb/s. Valid Range: 0 –– 232––1

JITTER UNSIGNED_INT(2) A type to represent the packet transfer delay jitter in ms

PKT_LOSS_RATE UNSIGNED_INT(2) A type to represent the packet loss rate. The loss rate is equal to the integer part of the result of multiplying --100 times the log10 of the ratio between the number of packets lost and the total number of packets transmitted.

COS UNSIGNED_INT(2) COS Class to be used for queuing. To be filled for LTE and WLAN

DROP_ELIGIBILITY BOOLEAN 0 means the frames are not eligible to discarding. 1 means frames are eligible for discarding.

MULTICAST_ENABLE BOOLEAN Identifies if a flow is multicast. 0: is not multicast 1: is multicast

JUMBO_ENABLE BOOLEAN Identifies if JUMBO must be activated 0: Deactivate Jumbo 1: Activate Jumbo

Table 10: New data types additions to table F.4 from IEEE 802.21



1.1.3 When generated

The MIHF generates this primitive upon request from the MIH user to perform an action on a pre-defined link-layer connection.

1.1.4 Effect on receipt

Upon receipt of this primitive, the link-layer technology supporting the current link-layer connections performs the action specified by the Link Action parameter in accordance with the procedures specified by the relevant standards organization and at the time specified by the Execution Delay parameter.

4.6.4 Extensions to reporting IEEE 802.21 primitives

The IEEE 802.21 uses several primitives for reporting and monitoring as explained in section 4.5.2. In order to provide the MEDIEVAL extra functionality, it is required to extent some data types with new elements. All these extensions do not require any modification to the primitives used for monitoring (Link_Get_Parameters, Link_Parameters_Report and Link_Configure_Threshold) since the modification only apply to the derived data types for the specific technologies parameters, e.g. LINK_PARAM_802_11 that is used in LINK_PARAM_TYPE.

In MEDIEVAL, we consider two main technologies, IEEE 802.11 and LTE, so the data types corresponding to these technologies together with the QoS generic data type, are the only ones to be used in the MEDIEVAL project. In the following are presented the modifications that would be required to these data types in table F.4 of the standard. The LINK_PARAM_802_11 is enriched with a new set of parameters (parameters 3 to 7). A new data type LINK_PARAM_LTE is introduced to contain the LTE parameters to be reported.

LINK_PARAM_802_11 UNSIGNED_INT(1) A type to represent a link parameter for IEEE 802.11 0: RSSI of the beacon channel, as defined in IEEE Std 802.11-2007. (This is applicable only for an MN.) 1: No QoS resource available. The corresponding LINK_PARAM_VAL is BOOLEAN set to TRUE when no QoS resources available. (This applicable when the traffic stream to be transmitted is on an access category configured for mandatory admission control and the request for bandwidth was denied by the available APs in the access network). 2: Multicast packet loss rate. 3: System Load. Percentage of usage load present at the system. 4:Number registered users. 5:Number active users. 6:Congestion window of users. Ordered list of the CW used by the clients, ordered according to highest value of MAC address. 7:Transmission rate of users. Ordered list of the transmission rate used by the clients, ordered



according to highest value of MAC address. 8-255: (Reserved)

Table 11: LINK_PARAM_802_11 modifications to table F.4 from IEEE 802.21

LINK_PARAM_LTE UNSIGNED_INT(1) A type to represent a link parameter for 3GPP LTE 0: UE Reference Signal Received Power (RSRP) 1: UE Reference Signal Received Quality (RSRQ) 2: Link Quality (CQI) 3: Available bandwidth / Resource usage 4: Packet delay on the radio link 5: Packet Loss rate on the radio link 6 : L2 buffer/queues status 7 : Mobile Node capabilities 8: eMBMS capability 9: Jumbo feasibility 10: Jumbo setup status 11: number of active eMBMS receivers per flow 12-255: (Reserved)

Table 12: LINK_PARAM_LTE extension to table F.4 from IEEE 802.21

4.7 Physical placement of the functional entities

Figure 13 depicts the Wireless Access subsystem functional entities arrangement in the Physical Nodes, which is restricted to the Radio Access Network (RAN). In particular, the figure shows the Mobile Terminal (MT), the Point of Attachment (PoAs) and the Point of Services (PoSs).



Figure 13 : Physical placement of the Wireless Access Components

Inside the MT node, the upper layers are represented by the Application Layer and the Connection Manager. A first component of the Wireless Access subsystem is represented by the L2.5 Abstraction that is located between higher layers and wireless accesses (WLAN and LTE). This component permits to communicate with the rest of the network (i.e., LTE and WLAN PoAs and PoSs). Wireless accesses include WLAN and LTE. The WLAN part contains the following modules:

WLAN monitoring module;

Jumbo frames mechanisms module.

The LTE part has the following modules:

Measurements and Medium Access Strategies;

Video frames selection and interface configuration;

Jumbo frames mechanisms.

The PoAs are represented in Figure 13 by two main components: WLAN Access Point (AP) and LTE eNodeB (with LTE Relay). WLAN AP communicates through L2.5 Abstraction, in line with the philosophy of MEDIEVAL. The information exchanged is mapped into suitable information for lower layers by a Wireless Access function named Abstraction QoS Mapper. The lower layer is composed by the following Wireless Access modules

802.11aa and Dynamic configuration;

WLAN monitoring module;




As for WLAN AP, the LTE eNodeB communicates via L2.5 Abstraction/802.21 and the information exchanged is translated by the Abstraction QoS Mapper for the lower layer, which is composed by the following Wireless Access modules blocks:

Measurements and Medium Access Strategies;

Video frames selection and interface configuration;

E-MBMS Support;

Cognitive exploitation of cooperative technologies;


Finally, the LTE relay contains the PDCP-level Relay and communicates with the rest of the network via the L2.5 Abstraction/802.21.

Point of Services (PoSs) are composed of MIIS server and Mobility Access Router (MAR). The MAR contains L2.5 Abstraction to communicate with the MT and PoAs (WLAN AP and LTE eNodeB). The interaction between the Wireless Access and the Core Network (CN) is represented by the Flow Manager module (Mobility subsystem) and the X-Layer Optimization (Transport Optimization subsystem), which represent the MIH User for the L2.5 Abstraction. Finally, the Decision Module is depicted in Figure 13 inside the MAR for completeness.

The MIIS server contains the 802.21 PoS Information Server, which communicates with the MAR, the MT and the PoAs.



5 Interactions and interfaces with upper layer components

5.1 Usage scenarios

Some usage scenarios have been defined in D1.1 [41] which show the user view of the MEDIEVAL architecture. Obviously, the Wireless Access sub system is involved in each and every step of these scenarios. In order to demonstrate the main cross layer optimization operations involving the Wireless Access, some steps of these use cases are recalled here with the Wireless Access point of view. Most of these operations are contained in use case 1 (UC1: David’s holiday afternoon at the city centre) with a few additional points in use case 2 (UC2: Arriving at the city).

Watching a video on a mobile implies starting a session which provides a good QoE to the user. This is the case for example in UC1, step 2 "he loves its big screen and the quality in which the videos are transmitted". The flow in section 5.2.1 pictures the interactions required on the Wireless Access to setup a new session and allocate the necessary resources with the right parameters.

While the user is watching his program, the device and the network keep monitoring the quality of the transmission. This is also illustrated in UC1. Step 3 implies network monitoring: "At the peak hours he would spend more time watching the loading bar and waiting for the video to get cached than actually watching it. But, that doesn’t happen anymore with his MEDIEVAL video store, so he sits back comfortable and watches his movie. ". Here the MEDIEVAL components monitor the status of the link serving Jean's mobile and are able to apply some transport optimization techniques based on the reporting from the access network. In step 5: "Meanwhile the PDA reports the presence of a faster Internet connection which is supported by the MEDIEVAL technology. Marie decides to switch to this one and starts viewing the next lecture with a greater satisfaction", it is the device which monitors the quality of the wireless link and is able to trigger the switching to another technology. The operation of the Wireless Access covering both cases of dynamic reporting is illustrated is section 5.2.2. The interactions with the upper layers in order to switch from one technology to the other one are presented in section 5.2.3.

Sometimes, it is not necessary to switch the whole interface, but rather to distribute them on the available technologies, as shown in UC2, step 4: "The video flow is moved to WLAN (WLAN offload). E-mail remains on LTE." Section 5.2.4 explains how this impacts the Wireless Access, including the allocation of new resources to the moved flow.

In UC1 step 2, Jean experiences a MEDIEVAL-specific transport optimization, based on dynamic reporting and resource allocation strategies, which improves his quality of experience by optimizing the LTE Medium Access scheduling according to the characteristics of the video flow: "Furthermore, the video stream feels like it was made right for his mobile resolution and he doesn’t get breaks in the stream or annoying caching times." The interactions between the various components of the LTE wireless access and the upper layers to perform this optimization are presented in section 5.2.7.

In UC1, step 4, Lou experiences some network overload, which is immediately recovered by the network: "He is connected to the café WLAN hotspot at this time, the Internet service is a bit slow: he barely could download some emails with attachments a minute ago. However, the TV & Video service is supported by MEDIEVAL, so he can watch the news quite well". The Wireless Access additionally offers some techniques which cooperate with the Transport Optimization to correct the problem transparently to the user. The video packets are selected and prioritized, based on packet marking, which requires some cooperation between the access and upper layers and the signalling of how the packet are marked for further processing. This signalling is illustrated in the flow described in section 5.2.5.

This section has quoted some extracts of the MEDIEVAL use cases demonstrating the operation of the Wireless Access. As stated before, next section will illustrate the interactions required between the various components to perform these cross-layer interactions. It is followed by an initial description of the interfaces involved in these interactions.

5.2 Cross-layer Optimization flows

This section presents the generic Message Sequence Charts (MSC) related to the operation of the Wireless Access.



5.2.1 Flow Session Setup

This flow shows the interactions between the Wireless Access subsystem and the upper layers when a new session is established. The reader is referred to D1.1 [41] for a complete view of the session setup across the whole architecture. In this signalling sequence, the Link Layer could be either the WLAN component or the LTE component. It is supposed that the network interface is already up and running at the time the MSC starts, in particular, the link capability discovery and reporting threshold configuration has been executed as described in section 5.2.2.

Figure 14 : Flow Session setup

In the previous flow, the 802.21 extensions introduced in the MIH_LINK SAP have been marked with **

The Wireless Access is then involved as described below during the overall session setup procedure:

It provides the quality of the various links to the Connection Manager, helping it choose the best technology; this is achieved using Link_Get_Parameters primitives.

It provides the status of the PoA to the Flow Manager, helping the network entities select the best suited access in terms of available resources; this is achieved using again the Link_Get_Parameters primitives.

When the technology is selected, the corresponding resources are allocated and the necessary parameters such as QoS are passed to the PoA to enable an efficient transport of the flow; this is achieved using Link_Action primitives, using a new Action Type LINK_ACTIVATE_RESOURCES. The same primitive can be used in LTE, whether the resource to activate is a unicast p-t-p nearer or an MBMS p-t-m- bearer to set up. In the later case, the MULTICAST_ENABLE parameter is set to TRUE.



The following MSC shows a more detailed view of the setup of the access network in the case where the LTE technology is used:

Figure 15 : Setup of the LTE access network

This figure has shown how the MIH_Link_Actions.request carrying a LINK_ACTIVATE_RESOURCES triggers the related LTE procedures. This primitive carries parameters that describe the flow, as listed in the detailed primitive description in section 4.6.3. These L3 parameters are mapped to L2 parameters in the Abstraction QoS Mapper function of the L2.5 Abstraction; they are then transferred to the LTE VFSIC module located in the eNodeB using a Link_Action.request primitive. The VFSIC then triggers the Context Setup procedure to establish a new PDP context and the corresponding radio bearers between the eNodeB and the UE. In case of LTE, the MBMS session start procedure is triggered, but only if the session was not yet received in the cell covered by the eNodeB. The same restriction applies during the MBMS session stop.

5.2.2 Wireless Access dynamic reporting

This section presents the message sequence charts for the functionality already explained in section 4.5.2. In the following the two mechanisms used in MEDIEVAL for reporting are shown. Figure 16 describes the required messages to register, set up and receive trigger-based notifications. The MSC is divided in two main sections, being the first one devoted to local reporting while the second one considers remote reporting. Both cases require, as first step, the MIH-Users (Connection Manager for local reporting and Flow Manager in the case of remote reporting) to discover the capabilities of the Layer 2.5 abstraction, i.e. if the specific Layer 2.5 Abstraction supports remote events or commands etc. Once the specific capabilities of the Layer 2.5 Abstraction are known, in the case of remote events, the remote Layer 2.5 Abstraction needs to register with the local one. In this way, the communication between both nodes can be authenticated and the local L2.5 Abstraction is able to gather the information required to send the reports to the remote L2.5 Abstraction. In the local case, the registration is not required.

The next step requires the MIH-Users to subscribe to the different events that they want to receive, and to configure the thresholds for the parameters being monitored. This is required, since the L2.5 Abstraction only delivers the events to the MIH-Users (local or remote) that have asked for them via a subscription mechanism.

The configuration stage finishes with the previous messages, after configuring the thresholds, the Layer 2.5 Abstraction has finished setting up the entire required configuration in the link layers and the MIH-Users are waiting for the reception of some event.

Events can be generated by the lower layers through several mechanisms, namely via threshold crossing or timer expiration. Once these two situations occur, the event is generated by the lower layers and the L2.5 Abstraction forwards it to the appropriate MIH-User.



Figure 16 : Trigger based asynchronous reporting

Figure 17 presents the second choice of monitoring tools used in MEDIEVAL, the direct polling. In addition to the trigger-based reporting explained above, MEDIEVAL also provides mechanisms for the MIH-Users to directly ask the L2.5 Abstraction and the lower layers for some of their parameters and other information. Figure 17 is divided in local and remote interactions. The remote interaction requires a previous step of registration and capabilities discovery that is not shown in the figure. Basically, both local and remote interactions are similar. An MIH-User asks for some parameter and the request is propagated to the local/remote L2.5 Abstraction. This module then asks the lower layers for the specific information, returning the response with the information.



Figure 17 : Direct polling report

5.2.3 Interface Handover

Figure 18 shows the actions triggered in the wireless access and L2.5 abstraction during a mobility operation from WLAN to LTE, in the example case when the signal is decreasing in the WLAN access.

Figure 18 : Interface Handover (1/3)

This handover involves the Wireless Access during the following interactions:



During the HO preparation phase, the L2.5 abstraction relays the MIH_Get_information primitives between the CM in the Mobile Node and the MIIS Server.

When the quality of the link decreases below a certain level in the WLAN access, an event is triggered towards the CM, being transported in Link_Going_Down primitives.

During the resource availability check, the network, or more precisely the FM located in the target MAR queries the status of resources of the candidate PoA using MIH_Link_Get_Parameters primitives.

Figure 19 shows the execution of the handover.


First, the resources are allocated in the network using Link_Action primitives, with a new type of Action: LINK_ACTIVATE_RESOURCES, as was described in section 5.2.1. In the case when the HO



applies to an interface that was receiving a flow enabled to multicast and MBMS is available on the link, the session start procedure is triggered. The early reception of the allocation request in the LTE eNodeB, while the mobile is still preparing for its handover, will allow optimizing the handling of this procedure. The handover is then committed by upper layers.

The execution of the handover itself is executed by the CM which sends a MIH_Link_Actions primitive, with the action type as LINK_POWER_UP, to trigger the attachment of the interface to the selected PoA. The signalling flow in Figure 19 shows the case of an LTE interface and a MIHO, but it would be identical in case of a WLAN interface or a NIHO.

When the interface is up, a Link_Up.indication report is generated by the LTE component which is forwarded to the CM and FM components according to their subscriptions.

Figure 20 shows the completion of the handover and the release of the former used resources in the wireless access network, since they are not used anymore.


In the previous MSCs, the 802.21 extensions introduced in the MIH_LINK_SAP have been marked with **.

5.2.4 Flow Handover

The wireless access supports the flow handover as described in D4.1. In this case, the MN is supposed to have both technologies active. There is thus no necessity of activating the interface from the Connection Manager in the MN as shown in Figure 19. On the other hand, the signalling related to the activation of resources between the Flow Manager and the L2.5 Abstraction remains identical to the one shown in Figure 19.

5.2.5 Configuration of the packet marking handling

The Wireless Access defined in MEDIEVAL includes the capability of acting upon a certain mark in the packets. It is important to understand that the Wireless Access does not add or modify the marks in the



packets. These marks and the behaviour expected while processing them are inputs expected to be propagated from the higher layers (Transport Optimization subsystem interface defined in D1.1 [41]). Figure 21 presents the MSC for the configuration of the Wireless Access to perform certain actions based on the packet mark.

Figure 21 : Configuration of the processing of packets based on marking

The first step in the MSC is the Abstract QoS Mapper to detect and get information regarding the different Classes of Service (CoS) supported by the link layers, including the delay and throughput characteristics between other parameters. Once this information is obtained, the Abstract QoS Mapper is able to map any flow request into the appropriate link layer specific CoS.

Once a new flow that requires a specific action is installed, based on its mark, the Transport Optimization subsystem uses the MIH_Link_Action primitive with the Action Type set to FLOW_ATTR to provide the information regarding the mark and the behaviour expected from the lower layers.

5.2.6 Jumbo frames activation/ deactivation

This flow depicted in Figure 22 describes the generic conceptual approach towards the activation of jumboframes in a wireless link. The process first starts by having a Network Decision Entity gaining awareness of which entities in its management domain (both network and mobile terminal entities) support jumbo frames. This is a dynamic procedure achieved by broadcasting a MIH_Capability_Discover.request message and collecting the responses. In case responding network entities are unable to reply to network-side broadcast messages, the Network Decision Entity is able to query a Media Independent Information Server to identify PoAs which support jumboframes.

These PoAs, through monitoring modules, are able to evaluate a set of link layer conditions and generate a 802.21 Event indicating that conditions enabling the usage of Jumboframes are met. This set of conditions is under development, but the 802.21 infrastructure allows the definition of thresholds for different link-layer parameters that identify the specific values at which the 802.21 Event is generated. When this occurs, this event is sent towards the Network Decision entity which is then able to issue a MIH_Link_Action.request command towards the involved PoA and MT, in order to activate their jumboframes abilities, and take advantage of a performance increase. Although not directly depicted here, whenever such conditions have changed and are deemed no longer feasible for jumboframes, the Network Decision Entity is able to send 802.21 command messages towards the PoA and the MT to deactivate jumboframes in their link-layers, reverting to the default settings.



Figure 22 : Jumbo frames activation/ deactivation



The next procedure (Figure 23) highlights on-going efforts to design a jumboframe-enabled handover mechanism. It is currently under conception and its feasibility is still being evaluated. As such, although it follows the mobility procedures being discussed within WP4, it does not yet reach a mature state in which inter WP interfaces have been defined. The objective is to evolve the design of this procedure and evaluate its feasibility, while maintaining a close coupling with the signalling and interfaces defined for WP4 and WP3 interaction.

The aim of this procedure is to enhance the Network Decision Entity with knowledge of the mobile terminal’s and surrounding PoAs support of jumboframes. With this, Jumboframe Support becomes a handover preference for entities that support it. As such, scenarios can be conceived where a PoA is preferable to another, because it (and the Mobile Terminal) support jumboframes.

When the Mobile Terminal is connected to a PoA (both support jumboframes) and a handover to another PoA has been decided, the MDE can trigger the Content Source (e.g., a video server) to generate a jumboframe-size of video burst towards the mobile terminal, using a MIH_Link_Action.request. The objective is to have the video application (or link layer in the Content Source) to take advantage of the jumboframe capabilities of the link between the MT and the PoA, to fill out the MT’s buffers in advance of the handover. As such, the MT is able to sustain lengthier handovers (e.g., due to signalling delay, or heavy network delay). When the handover is finished, the Mobile Terminal is able to send a Link_Up.indication event, triggering the Content Source to resume normal the normal video feed.



Figure 23 : Conceptual Jumbo frames enhanced handover



5.2.7 LTE-A Medium Access algorithm optimization

This flow, depicted in Figure 24, describes the procedure through which the LTE-A resource allocator has been optimized. The first step, as described in Flow Session Setup (section 5.2.1), is represented by the communication of upper layers parameters containing flows information such as the QoS Class Identifier (QCI) and the Allocation and Retention Priority (ARP). This procedure, as detailed above, required the introduction of a new Link_Action, LINK_ACTIVATE_RESOURCE. Therefore, the first input has been provided to the Cognitive exploitation of cooperative technologies (CECT) module. Now, a set of channel information is needed in order to execute the proposed resource allocation approach. In fact, as described in previous sections, channel parameters together with flows related information are needed to perform the allocation via cross layer techniques. In LTE-A, periodic L1 measurements are executed, and channel quality indicator (CQI) associated to each system Resource Block (RB) is provided to the eNodeB (PoA) in the Physical Uplink Control Channel (PUCCH). As shown in the flow, these measurements are executed in the Measurements and Medium Access Strategies (MMAS) module that is also in charge of communicating such parameters to the CECT entity (input 2). Once this module has received the two inputs, it generates the Utility Function, described in Section 4.4.2. Then, the CECT module delivers the output of this function to the MMAS entity in order to trigger the optimized resource allocation. Once the allocation map has been generated, i.e., some radio bearer packets have been removed from the MAC queues, the MMAS module inform the VFSIC about the LTE MAC queues status. Finally, all the channel measurements previously executed are transmitted to the upper layers via the L2.5 Abstraction layer, as shown in the last part of the flow.

Figure 24 : LTE-A Medium Access algorithm optimization



5.3 Interfaces with the upper layer Components

The Wireless Access interacts mainly with the Transport Optimization and the Mobility subsystems, through the L2.5 Abstract interface based on the MIH standard. These interfaces are summarized in this section and described with more details in deliverable D1.1 [41].

5.3.1 L25_TransportOptimization_If

The objective of this cross-layer interaction is to enable an efficient and optimized video transport by exchanging information through the abstract interface. To the Transport Optimization subsystem (Core Network Monitoring), it provides information about the reliability and quality of the link of the wireless accesses and the dynamic variations of the wireless access link parameters including the link capacity. From the Transport Optimization subsystem (X-layer optimization), it receives information to enhance the configuration of the wireless access: flow requirements (for QoS and multicast mechanism), flow identification, marking criteria.

5.3.2 L25_MobilityManagement_If

The objective of this cross-layer interface is to extend the media-independent signalling functionalities provided by IEEE 802.21 to support extra mobility functionalities and video aware services. All these extensions can be applied to the three services of IEEE 802.21, namely the Media Independent Events/Commands/Information Services. The MIH primitives are exchanged with the Flow Manager in the MAR and the Connection Manager in the Mobile Node. To the Mobility subsystem, this interaction provides information about the link status and the resource availability. From the Mobility subsystem, it receives configuration commands and parameters.

5.3.3 MIHF_MIHUSERX_If

This interface represents the generic interface between the MIHF function of the L2.5 Abstraction component and upper layer components (also dubbed MIH-Users). The MIHF will belong to the ODTONE implementation which provides facilitated mechanisms for interfacing with both link layers and MIH-Users. ODTONE provides an internal implementation of the MIH Protocol which requires MIH-Users to provide a socket for receiving and sending messages, and include the MIH Protocol library provided by ODTONE. MIH-Users will need to serialize and de-serialize the received 802.21 messages in order to extract the parameters therein, with which they can optimize their underlying procedures.

The primitives and parameters provided by this interface are defined in the IEEE 802.21 which should be consulted for further details. The MIHF will however provide support for new 802.21 primitives and/or parameters indicated in other sections of this deliverable.

5.3.4 L25_Network_If

This interface represents the interactions between the MIHF function of the L2.5 Abstraction component and networking mechanisms. The objective is to allow remote 802.21 signalling exchange between two MIHF entities belonging to different nodes. This function will be provided by the ODTONE implementation of 802.21, supporting both UDP and TCP transport solutions with and without acknowledgement service.

This interface implements the primitives and parameters defined in the IEEE 802.21 protocol, which should be consulted for further detail.

5.4 Interfaces between the L2.5 Abstraction and the Media-specific modules

5.4.1 L25_LinkX_If

This interface represents the generic interface between the L2.5 Abstraction and Link Layers. In the case of MEDIEVAL, this interface will exist between the MIHF function of the L2.5 Abstraction and the Media-specific components for WLAN and LTE (here LinkX is just a reference for the different technologies). Both



in the MIHF component and each media-specific component, the interface will require a socket and inclusion of the MIH Protocol library from ODTONE. As such, the Media-specific components will need to apply serialization and de-serialization of MIH messages into their modules behaviour.

The interface will reuse the existing primitives and parameters from the MIH Protocol defined in the IEEE 802.21 standard, which should be consulted for more details. The MIHF will also provide support for the inclusion of new primitives and/or parameters defined in other sections of this deliverable, when required.

5.4.2 L25_WMDC_If

This interface corresponds to the communication between the Layer 2.5 Abstraction (L25) and the 802.11aa and Dynamic Configuration Module (WMDC). This interface is based on the MIH_LINK_SAP defined in IEEE 802.21 and as such is a media dependant abstract interface. The information exchanged in this interface encompass i) the information regarding the flow attributes (CoS class, drop eligibility, mark used and multicast/Jumbo requirements), ii) link actions requested by higher layers and iii) parameter reporting.

This interface implements the complete IEEE 802.21 MIH_LINK_SAP plus several modifications which are explained in Section 4.6.

The MEDIEVAL specific primitives (modifications to IEEE 802.21 standard primitives) used in this interfaces are the following:

Link_Action o Action Type: FLOW_ATTR o Action Type: LINK_ACTIVATE_RESOURCES o Action Type: LINK_DEACTIVATE_RESOURCES

Regarding the reporting of information, this interface includes the reporting of the QoS parameters and CoS classes, although the main reporting of parameters is performed through the interface L25_WLANMM_ If.

5.4.3 L25_WLANMM_If

This interface exploits the definition of the MIH-LINK SAP interface described in IEEE 802.21 standard. Specifically, it defines the interaction between the WLAN Monitoring Module (WLANMM) and the Layer 2.5 Abstraction (L25), focusing on the reporting of dynamic information related to WLAN technology.

The following primitives are used according to the standard:

Link_Configure_Thresholds.request

Link_Configure_Thresholds.confirm

Link_Get_Parameters.request

Link_Get_Parameters.confirm

Link_Parameters_Report.indication

All the exchanged parameters in this interface are listed in Section 4.6.4, where the data type LINK_PARAM_LTE has been created for MEDIEVAL purposes.

5.4.4 L25_VFSIG_If

This interface is based on the MIH-LINK SAP as described in [2]. In this interface, the following primitives are used according to the standard:





Link_Action.request

Link_Action.confirm

The Link_Action group of primitives has been modified to fulfil the MEDIEVAL Requirements. The Link_Action.request primitive is used by the L25 to request an action on the LTE interface to enable optimal handling of link-layer resources. The LTE link-layer interface can be ordered to attach to the network (Action = LINK_POWER_UP) or detach from the network (Action = LINK_POWER_DOWN). In addition to the standard, three new actions types have been introduced in MEDIEVAL for this interface: FLOW_ATTR, LINK_ACTIVATE_RESOURCES and LINK_DEACTIVATE_RESOURCES, as described in section 4.6.3. The other parameters are handled according to the IEEE 802.21 standard.

5.4.5 L25_MMAS_If

This interface defines the interaction between the Measurements and Medium Access Strategy (MMAS) and the Layer 2.5 Abstraction (L25). The objective of this interface is to report dynamic information related to LTE-A technology to L25, exploiting the definition of the MIH-LINK SAP interface done in the IEEE 802.21 standard. The following primitives are used according to the standard:

Link_Configure_Thresholds.request

Link_Configure_Thresholds.confirm



Link_ Parameters_Report.indication

All the exchanged parameters in this interface are listed in Section 4.6.4, where the data type LINK_PARAM_LTE has been created for MEDIEVAL purposes.

5.5 Interfaces inside the Contention-based Wireless Access

5.5.1 WLANMM_WMDC_If

This interface enables the communication between the WLAN Monitoring Module (WLANMM) and the 802.11aa and Dynamic configuration module (WMDC). Basically this interface provides reporting mechanism such as the ones explained in section 4.5.2. This interface corresponds to internal communication mechanisms within the WLAN technology, and as such, the primitives herein presented do not belong to the MIH_LINK_SAP of IEEE 802.21. Nevertheless we reuse as much as possible this interface and the primitives designed for this interface are very similar to some of the IEEE 802.21 MIH_LINK_SAP primitives.

5.5.1.1 WLANMM_WMDC_Set_Threshold

5.5.1.1.1 WLANMM_WMDC_Set_Threshold.request

Function

This primitive is used by the WMDC to configure the set of thresholds upon which the WLANMM issues an event.



Semantics of the service primitive

WLANMM_WMDC_Set_Threshold.request( ParameterThresholds ) Parameters:

Name Data Type Description

ParameterThresholds SEQUENCE(

LINK_PARAM_802_11,

CHOICE(NULL, TIMER_INTERVAL),

TH_ACTION,

LIST(THRESHOLD)

)

This compound data type carries all information required to set up thresholds for the parameters indicated in the LINK_PARAM_802_11 field. The LINK_PARAM_802_11 field has been modified by MEDIEVAL and its extensions are presented in section 4.6.4. The rest of parameters are used as specified in IEEE 802.21

Table 13: WLANMM_WMDC_Set_Threshold.request parameter list

When generated

This message is generated at the WMDC when it requires to be notified about a parameter crossing a specific threshold.

Effect on receipt

The WLANMM configures itself to notify the WMDC upon threshold crossing or timer expiration for the specified parameters.

5.5.1.1.2 WLANMM_WMDC_Set_Threshold.confirm

Function

This primitive is used by the WLANMM to indicate the result of the threshold configuration request done by the WMDC.


WLANMM_WMDC_Set_Threshold.confirm( Status, ThresholdSetupResult )

Parameters:


Status STATUS Status of operation.

The status of a primitive execution. 0: Success 1: Unspecified Failure 2: Rejected 3: Authorization Failure 4: Network Error

ThresholdSetupResult

SEQUENCE(

LINK_PARAM_802_11,

THRESHOLD,

This sequence carries the information regarding each parameter, the threshold associated to it and the result of



CONFIG_STATUS

)

the configuration. CONFIG_STATUS can be True or False (IEEE 802.21).

Table 14: WLANMM_WMDC_Set_Threshold.confirm parameter list

When generated

This message is generated at the WLANMM after setting up the different thresholds on the link layers. It includes explicit confirmation of the correct set up for each parameter.

Effect on receipt

The WMDC is able to start relying on event notifications from the WLANMM.

5.5.1.2 WLANMM_WMDC_Get_Parameters

5.5.1.2.1 WLANMM_WMDC_GET_Parameters.request

Function

This primitive is used by the WMDC to poll the WLANMM for the value of some parameters.


WLANMM_WMDC_Get_Parameters.request( LinkParameters )

Parameters:


LinkParameters LIST(LINK_PARAM_802_11) This data type corresponds to a list of the parameters available for WLAN. Note that the LINK_PARAM_802_11 data type has been extended in MEDIEVAL (see section 4.6.4)

Table 15: WLANMM_WMDC_Get_Parameters.request parameter list

When generated

This message is generated at the WMDC when it requires knowing the value of some WLAN specific parameter.

Effect on receipt

The WLANMM retrieves the values of the parameters and sends this information to the WMDC via a WLANMM_WMDC_Get_Parameters.confirm

5.5.1.2.2 WLANMM_WMDC_Get_Parameters.confirm

Function

This primitive is used by the WLANMM to return the values of the queried parameters to the WMDC.




WLANMM_WMDC_Get_Parameters.confirm( Status, LinkParametersResult )

Parameters:




LinkParametersResult

LIST(

SEQUENCE(

LINK_PARAM_802_11,

LINK_PARAM_VAL)

)

This sequence carries the information regarding each parameter; it is a list of sequences of parameters and their values.

Table 16: WLANMM_WMDC_Get_Parameters.confirm parameter list

When generated

This message is generated at the WLANMM after retrieving the value of the requested parameters.

Effect on receipt

WMDC receives the requested parameters.

5.5.1.3 WLANMM_WMDC_Parameters_Report

5.5.1.3.1 WLANMM_WMDC_Parameters_Report.indication

Function

This event is generated by the WLANMM upon a threshold crossing or timer expiration, in order to inform the WMDC of this event.


WLANMM_WMDC_Parameters_Report.indication( LinkParametersReport )

Parameters:


LinkParametersReport

LIST(

SEQUENCE(

LINK_PARAM_802_11,




LINK_PARAM_VAL)

)

Table 17: WLANMM_WMDC_Parameters_Report.indication parameter list

When generated

This message is generated at the WLANMM upon threshold crossing or timer expiration.

Effect on receipt

WMDC receives information on WLAN parameters.

5.5.2 JMB_WMDC_If (Conceptual Interface)

This interface allows the configuration and activation of Jumbo mechanisms within the WLAN interface.

The interface has two main functions, first to report the feasibility of the Jumbo utilization in the current network situation, and second, it allows the enabling of the Jumbo functionality.

5.5.2.1 JMB_WMDC_Jumbo_Feasibility_Report

5.5.2.1.1 JMB_WMDC_Jumbo_Feasibility_Report.indication

Function

This event is generated by the JMB module each time the Jumbo functionality is feasible and can be applied. It also informs of the case when it becomes unfeasible.


JMB_WMDC_Jumbo_Feasibility_Report.indication( JumboFeasibility JumboMTU, JumboLayer )

Parameters:


JumboFeasibility

BOOLEAN This parameter indicates the feasibility of the Jumbo mechanism.

True: indicates that the use of Jumbo is feasible

False: indicates that the use of Jumbo is unfeasible.

JumboMTU UNSIGNED_INT(4) Indicates the value of the Maximum Transfer Unit that the Jumbo frame can use.

JumboLayer BITMAP(2) The layer at which the Jumbo frame is applied.

Bit 0: L2

Bit 1: L3

Table 18: JMB_WMDC_Jumbo_Feasibility_Report.indication parameter list



When generated

This message is generated at the JMB module each time the Jumbo functionality becomes feasible or unfeasible.

Effect on receipt

If the Jumbo mechanism becomes feasible, the WMDC may use it. If it becomes unfeasible, then all configurations using Jumbo must be deactivated.

5.5.2.2 JMB_WMDC_Jumbo_Action

5.5.2.2.1 JMB_WMDC_Jumbo_Action.request

Function

This command is generated by the WMDC in order to activate or deactivate the Jumbo mechanism.


JMB_WMDC_Jumbo_Action.request( JumboActivate JumboMTU, JumboLayer )

Parameters:


JumboActivate

BOOLEAN This parameter indicates to the JMB if it must activate the Jumbo mechanism.

True: Activate Jumbo Mechanism

False: Deactivate Jumbo Mechanism

JumboMTU UNSIGNED_INT(4) Indicates the value of the Maximum Transfer Unit that the Jumbo frame must use.

JumboLayer BITMAP(2) The layer at which the Jumbo frame must be applied.

Bit 0: L2

Bit 1: L3

Table 19: JMB_WMDC_Jumbo_Action.request parameter list

When generated

This message is generated at the WMDC in order to activate the Jumbo mechanisms.

Effect on receipt

The JMB must activate or deactivate the Jumbo mechanism and configure the appropriate MTU and layer to be used.



5.5.2.2.2 JMB_WMDC_Jumbo_Action.confirm

Function

This command provides feedback to the WDMC regarding the activation of the Jumbo mechanisms.


JMB_WMDC_Jumbo_Action.confirm( JumboActivate JumboMTU, JumboLayer )

Parameters:


JumboActivate




Table 20: JMB_WMDC_Jumbo_Action.confirm parameter list

When generated

This message is generated at the JMB in order to provide feedback to the WMDC about the Jumbo configuration.

Effect on receipt

Received information about the Jumbo activation procedure.

5.5.3 JMB_WLANMM_If (Conceptual Interface)

This interface allows collection of WLAN related metrics for the evaluation of Jumbo-suitable radio condition.

The interfaces regarding the jumboframes behaviour are dependant of the final established behaviour for jumbo frames within the project. Depending on its deployment on the actual Layer 2 or instead, higher layer emulation mechanisms, the interfaces will provide the ability to activate, configure and deactivate jumbo frames behaviour, but will be conceptual in nature, since the results are foreseen to be obtainable in theoretical or simulation form.

5.5.3.1 JMB_WLANMM_Set_Threshold

5.5.3.1.1 JMB_WLANMM_Set_Threshold.request

Function

This primitive is used by the Jumbo module to configure the set of thresholds upon which the WLANMM issues an event. The aim is to allow the Jumbo module to define link parameters with which to determine if the wireless link conditions are able to provide jumbo feasibility or not.




JMB_WLANMM_Set_Threshold.request( ParameterThresholds )

Parameters:



LINK_PARAM_802_11,


TH_ACTION,

LIST(THRESHOLD)

)

This compound data type carries all information required to set up thresholds for the parameters indicated in the LINK_PARAM_802_11 field. The LINK_PARAM_802_11 field has been modified by MEDIEVAL and its extensions are presented in section 4.6. The rest of parameters are used as specified in IEEE 802.21

Table 21: JMB_WLANMM_Set_Threshold.request parameter list

When generated

This message is generated at the Jumbo module when it requires to be notified about a parameter crossing a specific threshold.

Effect on receipt

The WLANMM configures itself to notify the Jumbo module upon threshold crossing or timer expiration for the specified parameters.

5.5.3.1.2 JMB_WLANMM_Set_Threshold.confirm

Function

This primitive is used by the WLANMM to indicate the result of the threshold configuration request done by the Jumbo module.


JMB_WLANMM_Set_Threshold.confirm( Status, ThresholdSetupResult )

Parameters:



The status of a primitive execution.

0: Success 1: Unspecified Failure 2: Rejected 3: Authorization Failure 4: Network Error




SEQUENCE(

LINK_PARAM_802_11,

THRESHOLD,

CONFIG_STATUS

)

This sequence carries the information regarding each parameter, the threshold associated to it and the result of the configuration. CONFIG_STATUS can be True or False (IEEE 802.21).

Table 22: JMB_WLANMM_Set_Threshold.confirm parameter list

When generated

This message is generated at the WLANMM after setting up the different thresholds on the link layers. It includes explicit confirmation of the correct set up for each parameter.

Effect on receipt

The Jumbo module is able to start relying on event notifications from the WLANMM.

5.5.3.2 JMB_WLANMM_Get_Parameters

5.5.3.2.1 JMB_WLANMM_Get_Parameters.request

Function

This primitive is used by the Jumbo module to poll the WLANMM for the value of parameters related with link conditions for the evaluation of jumbo feasible conditions.


JMB_WLANMM_Get_Parameters.request( LinkParameters )

Parameters:


LinkParameters LIST(LINK_PARAM_802_11) This data type corresponds to a list of the parameters available for WLAN. Note that the LINK_PARAM_802_11 data type has been extended in MEDIEVAL (see section 4.6)

Table 23: JMB_WLANMM_Get_Parameters.request parameter list

When generated

This message is generated at the Jumbo module when it requires knowledge of some WLAN specific parameter value.

Effect on receipt

The WLANMM retrieves the values of the parameters and sends this information to the Jumbo module via a JMB_WLANMM_Get_Parameters.confirm



5.5.3.2.2 JMB_WLANMM_Get_Parameters.confirm

Function

This primitive is used by the WLANMM to return the values of the queried parameters to the Jumbo module.


JMB_WLANMM_Get_Parameters.confirm( Status, LinkParametersResult )

Parameters:


Status STATUS The status of the primitive execution.



LIST(

SEQUENCE(

LINK_PARAM_802_11,

LINK_PARAM_VAL)

)

This sequence carries the information regarding each parameter, it is a list of sequences of parameters and their values.

Table 24: JMB_WLANMM_Get_Parameters.confirm parameter list

When generated

This message is generated at the WLANMM after retrieving the value of the requested parameters.

Effect on receipt

The WLANMM receives the parameters about Jumbo configuration.

5.5.3.3 JMB_WLANMM_Parameters_Report

5.5.3.3.1 JMB_WLANMM_Parameters_Report.indication

Function

This event is generated by the WLANMM upon threshold crossing or timer expiration, in order to inform the Jumbo module of a wireless link event.


JMB_WLANMM_Parameters_Report.indication( LinkParametersReport )

Parameters:


LinkParametersReport LIST( This sequence carries the information regarding each



SEQUENCE(

LINK_PARAM_802_11,

LINK_PARAM_VAL)

)

parameter; it is a list of sequences of parameters and their values.

Table 25: JMB_WLANMM_Parameters_Report.indication parameter list

When generated

This message is generated at the WLANMM upon threshold crossing or timer expiration.

Effect on receipt

The WLANMM is alerted with information regarding Jumbo parameters.

5.6 Interfaces inside the Coordination-based Wireless Access

5.6.1 CECT_VFSIC_If

This interface enables the communication between the Video Frame Selection and Interface Configuration (VFSIC) and the Cognitive Exploitation of Cooperative Technologies module (CECT). Basically this interface provides flows reporting mechanism such as the ones explained in sections 4.4.1 and 4.4.2.

5.6.1.1 CECT_VFSIC_Set_Threshold

5.6.1.1.1 CECT_VFSIC_Set_Threshold.request

Function

This primitive is used to configure the set of thresholds upon which VFSIC issues an event (flows related information report), that is, in our case, 1 millisecond.


CECT_VFSIC_Set_Threshold.request( ParameterThresholds )

Parameters:



LTE_FLOW_INFO,

TIMER_INTERVAL,

)

Configuration of the time threshold that defines the reporting parameters period (1 ms).

Table 26: CECT_VFSIC_Set_Threshold.request parameter list

When generated

This message is generated when CECT requires to be notified about the flows information to be scheduled in the transmission, after crossing a specific time threshold.

Effect on receipt

The VFSIC configures itself to notify the CECT upon timer expiration for the specified parameters.



5.6.1.1.2 CECT_VFSIC_Set_Threshold.confirm

Function

This primitive is used by the VFSIC to return the values of the queried parameters to the CECT.


CECT_VFSIC_Set_Threshold.confirm( Status, ThresholdSetupResult )

Parameters:


Status STATUS The status of the primitive execution. 0: Success 1: Unspecified Failure 2: Rejected 3: Authorization Failure 4: Network Error


SEQUENCE(

LTE_FLOW_INFO,

TIMER_INTERVAL,

CONFIG_STATUS

)


Table 27: CECT_VFSIC_Set_Threshold.confirm parameter list

When generated

This primitive is used by the VFSIC to indicate the result of the threshold configuration request done by the CECT.

Effect on receipt

The CECT is able to start relying on event notifications from the VFSIC.

5.6.1.2 CECT_VFSIC_Parameters_Report

5.6.1.2.1 CECT_VFSIC_Parameters_Report.indication

Function

This event is generated by the VFSIC upon timer expiration, in order to inform the CECT module of incoming flow parameters.


CECT_VFSIC_Parameters_Report.indication( LinkParametersReport )

Parameters:



LIST(SEQUENCE(FLOW_ID, UNSIGNED_INT(1),

This sequence carries the incoming flows information, previously referred to as



UNSIGNED_INT(1))) LTE_FLOW_INFO that are related to each EPS bearer: FLOW_ID, QCI, and ARP.

Table 28: CECT_VFSIC_Parameters_Report.indication parameter list

When generated

This message is generated at the VFSIC upon timer expiration.

Effect on receipt

CECT receives information regarding incoming flow to enable it algorithm.

5.6.2 CECT_MMAS_If

This interface links the Cognitive Exploitation of Cooperative Technologies (CECT) and the Measurements and Medium Access Strategy (MMAS) by providing the information described is sections 4.4.2 and 4.4.3. In particular, the MMAS sends to the CECT module information regarding the channel status perceived by each user (e.g., CQI). On the other hand, CECT sends to MMAS the generated allocation map, which will be used by MMAS to perform the resource allocation. Both set of parameters are periodically communicated to the respective blocks; the time period corresponds to the allocation slot time, i.e., 2 slots (1 ms).

5.6.2.1 CECT_MMAS_Set_Threshold_ PHYmeasurement

5.6.2.1.1 CECT_MMAS_Set_Threshold_ PHYmeasurement.request

Function

This primitive is used to configure the set of thresholds upon which MMAS issue an event (physical measurements report), that is, in our case, 1 millisecond.


CECT_MMAS Set_Threshold_PHYmeasurement.request( ParameterThresholds )

Parameters:



LTE_CHANNEL_MEASUREMENT,

TIMER_INTERVAL,

)


Table 29: CECT_MMAS_Set_Threshold_PHYmeasurement.request parameter list

When generated

This message is generated when CECT requires to be notified about the channel measurements perceived by each user crossing a specific time threshold.

Effect on receipt

The MMAS configures itself to notify the CECT upon timer expiration for the specified parameters (PHY measurements).



5.6.2.1.2 CECT_MMAS_Set_Threshold_PHYmeasurement.confirm

Function

This primitive is used by the MMAS to return the values of the queried parameters to the CECT.


CECT_MMAS_Set_Threshold_PHYmeasurement.confirm( Status, ThresholdSetupResult )

Parameters:


Status STATUS The status of the primitive execution. 0: Success 1: Unspecified Failure 2: Rejected 3: Authorization Failure 4: Network Error


SEQUENCE(

LTE_CHANNEL_MEASUREMENT,

TIMER_INTERVAL,

CONFIG_STATUS

)


Table 30: CECT_MMAS_Set_Threshold_PHYmeasurement.confirm parameter list

When generated

This primitive is used by the MMAS to indicate the result of the threshold configuration request done by the CECT.

Effect on receipt

The CECT is able to start relying on event notifications from the MMAS.

5.6.2.2 CECT_MMAS_Set_Threshold_AllocationMAP

5.6.2.2.1 CECT_MMAS_Set_Threshold_AllocationMAP.request

Function

This primitive is used to configure the set of thresholds upon which CECT issue an event (allocation map report), that is, in our case, 1 millisecond.


CECT_MMAS_Set_Threshold_AllocationMAP.request( ParameterThresholds )



Parameters:



ALLOCATION_MAP,

TIMER_INTERVAL,

)


Table 31: CECT_MMAS_Set_Threshold_AllocationMAP.request parameter list

When generated

This message is generated when MMAS requires to be notified about the allocation map generated by the CECT entity after crossing a specific time threshold.

Effect on receipt

The CECT configures itself to notify the MMAS upon timer expiration for the specified parameters (allocation map report).

5.6.2.2.2 CECT_MMAS_Set_Threshold_AllocationMAP.confirm

Function

This primitive is used by the CECT to return the values of the queried parameters to the MMAS.


CECT_MMAS_Set_Threshold_AllocationMAP.confirm( Status, ThresholdSetupResult )

Parameters:





SEQUENCE(

ALLOCATION_MAP,

TIMER_INTERVAL,

CONFIG_STATUS

)


Table 32: CECT_MMAS_Set_Threshold_AllocationMAP.confirm parameter list

When generated

This primitive is used by the CECT to indicate the result of the threshold configuration request done by the MMAS.



Effect on receipt

The MMAS is able to start relying on event notifications from the CECT.

5.6.2.3 CECT_MMAS_PHYMeasurement_Report

5.6.2.3.1 CECT_MMAS_PHYMeasurement_Report.indication

Function

This event is generated by the MMAS upon timer expiration, in order to inform the CECT module of channel measurements event.


CECT_MMAS_PHYMeasurement_Report.indication( LinkParametersReport ) Parameters:



LIST(SEQUENCE(UNSIGNED_INT(1), IP_ADDR, LINK_PARAM_LTE))

This sequence carries the channel information perceived by each user, previously referred to as LTE_CHANNEL_MEASUREMENT. The sequence represents, respectively, the RB, the IP_ADDR, and the CQI value.

Table 33: CECT_MMAS_PHYMeasurement_Report.indication parameter list

When generated

This message is generated at the MMAS upon timer expiration.

Effect on receipt

CECT receives information regarding channel measurements.

5.6.2.4 CECT_MMAS_AllocationMAP_Report

5.6.2.4.1 CECT_MMAS_AllocationMAP_Report.indication

Function

This event is generated by the CECT upon timer expiration, in order to inform the MMAS module of the allocation map.


CECT_MMAS_AllocationMAP_Report.indication( LinkParametersReport )

Parameters:


LinkParametersResult LIST(SEQUENCE(UNSIGNED_INT(1), IP_ADDR))

This sequence carries the allocation map realization, previously referred



to as ALLOCATION_MAP that represent the mapping between each RB and the respective allocated UE.

Table 34: CECT_MMAS_AllocationMAP_Report.indication parameter list

When generated

This message is generated at the CECT upon timer expiration.

Effect on receipt

MMAS receives the allocation map and performs the allocation.

5.6.3 MMAS_VFSIC_If

This interface provides information about the actual resource usage of the system, needed by VFSIC to know whether EPS bearers may be established. Therefore, as described in previous sections, this information is provided every allocation time slot (1 ms) because the queues will be accordingly updated.

5.6.3.1 MMAS_VFSIC_Set_Threshold

5.6.3.1.1 MMAS_VFSIC_Set_Threshold.request

Function

This primitive is used by the VFSIC to configure the set of thresholds upon which the MMAS issues an event.


MMAS_VFSIC_Set_Threshold.request( ParameterThresholds )

Parameters:



RESOURCE_USAGE,

TIMER_INTERVAL,

)


Table 35: MMAS_VFSIC_Set_Threshold.request parameter list

When generated

This message is generated at the VFSIC when it requires to be notified about a parameter crossing a specific threshold.

Effect on receipt

The MMAS configures itself to notify the VFSIC upon threshold crossing or timer expiration for the specified parameters.



5.6.3.1.2 MMAS_VFSIC_Set_Threshold.confirm

Function

This primitive is used by the MMAS to indicate the result of the threshold configuration request done by the VFSIC.


MMAS_VFSIC_Set_Threshold.confirm( Status, ThresholdSetupResult )

Parameters:






SEQUENCE(

RESOURCE_USAGE,

TIMER_INTERVAL,

CONFIG_STATUS

)


Table 36: MMAS_VFSIC_Set_Threshold.confirm parameter list

When generated

This message is generated at the MMAS after setting up the different thresholds on the link layers. It includes explicit confirmation of the correct set up for each parameter.

Effect on receipt

The VFSIC is able to start relying on event notifications from the MMAS.

5.6.3.2 MMAS_VFSIC_Parameters_Report

5.6.3.2.1 MMAS_VFSIC_Parameters_Report.indication

Function

This event is generated by the MMAS upon threshold crossing or timer expiration, in order to provide system resource information to the VFSIC.


MMAS_VFSIC_Parameters_Report.indication( LinkParametersResult )



Parameters:



LINK_PARAM_LTE This parameter provides the VFSIC with system resource information, previously referred to as RESOURCE_USAGE

Table 37: MMAS_VFSIC_Parameters_Report.indication parameter list

When generated

This message is generated at the MMAS upon threshold crossing or timer expiration.

Effect on receipt

VFSIC receives system resource information.

5.6.4 JMB_VFSIC_If (Conceptual Interface)

This interface allows the configuration and activation of Jumbo mechanisms within the LTE interface, depending on the possibility of the technology allowing that action, by an external entity by using an 802.21 command.

5.6.4.1 JMB_VFSIC_Jumbo_Feasibility_Report

5.6.4.1.1 JMB_VFSIC_Jumbo_Feasibility_Report.indication

Function

This event is generated by the JMB module each time the Jumbo functionality is feasible and can be applied. It also informs of the case when it becomes unfeasible.


JMB_VFSIC_Jumbo_Feasibility_Report.indication( JumboFeasibility JumboMTU, JumboLayer )

Parameters:


JumboFeasibility

BOOLEAN This parameter indicates the feasibility of the Jumbo mechanism.

True: indicates that the use of Jumbo is feasible

False: indicates that the use of Jumbo is unfeasible.

JumboMTU UNSIGNED_INT(4) Indicates the value of the Maximum Transfer Unit that the Jumbo frame can use.

JumboLayer BITMAP(2) The layer at which the Jumbo frame is applied.



Bit 0: L2

Bit 1: L3

Table 38: JMB_VFSIC_Jumbo_Feasibility_Report.indication parameter list

When generated

This message is generated at the JMB module each time the Jumbo functionality becomes feasible or unfeasible.

Effect on receipt

If the Jumbo mechanism becomes feasible, the VFSIC may use it. If it becomes unfeasible, then all configurations using Jumbo must be deactivated.

5.6.4.2 JMB_VFSIC_Jumbo_Action

5.6.4.2.1 JMB_VFSIC_Jumbo_Action.request

Function

This command is generated by the VFSIC in order to activate or deactivate the Jumbo mechanism.


VFSIC_JMB_Jumbo_Action.request( JumboActivate JumboMTU, JumboLayer )

Parameters:


JumboActivate




JumboMTU UNSIGNED_INT(4) Indicates the value of the Maximum Transfer Unit that the Jumbo frame must use.

JumboLayer BITMAP(2) The layer at which the Jumbo frame must be applied.

Bit 0: L2

Bit 1: L3

Table 39: JMB_VFSIC_Jumbo_Action.request parameter list

When generated

This message is generated at the VFSIC in order to activate the Jumbo mechanisms.



Effect on receipt

The JMB must activate or deactivate the Jumbo mechanism and configure the appropriate MTU and layer to be used.

5.6.4.2.2 JMB_VFSIC_Jumbo_Action.confirm

Function

This command provides feedback to the VFSIC regarding the activation of the Jumbo mechanisms.


JMB_VFSIC_Jumbo_Action.confirm( JumboActivate JumboMTU, JumboLayer )

Parameters:


JumboActivate




Table 40: JMB_VFSIC_Jumbo_Action.confirm parameter list

When generated

This message is generated at the JMB in order to provide feedback to the VFSIC about the Jumbo configuration.

Effect on receipt

The VFSIC receives the requested Jumbo configuration information.

5.6.5 JMB_MMAS_If (Conceptual Interface)

This interface allows collection of LTE related metrics for the evaluation of Jumbo-suitable radio condition, as well as indicating (on behalf of the Jumbo module) if the activation/deactivation of Jumbo procedures has occurred successfully or not.

The jumbo frames mechanisms for LTE-A will be developed after the WLAN feature is completed, aiming to maintain a generic approach. As such, the interface so far shares the same behaviour defined in the WLAN counterpart, and will also be developed under a theoretical or simulation approach.

5.6.5.1 JMB_MMAS_Set_Threshold

5.6.5.1.1 JMB_MMAS_Set_Threshold.request

Function

This primitive is used by the Jumbo module to configure the set of thresholds upon which the MMAS issues an event. The aim is to allow the Jumbo module to define link parameters with which to determine if the cellular link conditions are able to provide jumbo feasibility or not.




JMB_MMAS_Set_Threshold.request( ParameterThresholds )

Parameters:



LINK_PARAM_LTE-A,


TH_ACTION,

LIST(THRESHOLD)

)

This compound data type carries all information required to set up thresholds for the parameters indicated in the LINK_PARAM_LTE-A is a new parameter added by MEDIEVAL to the 802.21 standard regarding LTE-A, which is still under definition

Table 41: JMB_MMAS_Set_Threshold.request parameter list

When generated

This message is generated at the Jumbo module when it requires to be notified about a parameter crossing a specific threshold.

Effect on receipt

The MMAS configures itself to notify the Jumbo module upon threshold crossing or timer expiration for the specified parameters.

5.6.5.1.2 JMB_MMAS_Set_Threshold.confirm

Function

This primitive is used by the MMAS to indicate the result of the threshold configuration request done by the Jumbo module.


JMB_MMAS_Set_Threshold.confirm( Status, ThresholdSetupResult )

Parameters:






SEQUENCE(

LINK_PARAM_LTE-A,

This sequence carries the information regarding each parameter, the threshold associated to it and the result of the configuration.



THRESHOLD,

CONFIG_STATUS

)

CONFIG_STATUS can be True or False (LTE-A).

Table 42: JMB_MMAS_Set_Threshold.confirm parameter list

When generated

This message is generated at the MMAS after setting up the different thresholds on the link layers. It includes explicit confirmation of the correct set up for each parameter.

Effect on receipt

The Jumbo module is able to start relying on event notifications from the MMAS.

5.6.5.2 JMB_MMAS_Get_Parameters

5.6.5.2.1 JMB_MMAS_Get_Parameters.request

Function

This primitive is used by the Jumbo module to poll the MMAS for the value of parameters related with link conditions for the evaluation of jumbo feasible conditions.


JMB_MMAS_Get_Parameters.request( LinkParameters )

Parameters:


LinkParameters LIST(LINK_PARAM_LTE-A) This data type corresponds to a list of the parameters available for WLAN. Note that the LINK_PARAM_LTE-A is a new parameter added by MEDIEVAL to the 802.21 standard regarding LTE-A, which is still under definition

Table 43: JMB_MMAS_Get_Parameters.request parameter list

When generated

This message is generated at the Jumbo module when it requires knowledge of some LTE-A specific parameter value.

Effect on receipt

The MMAS retrieves the values of the parameters and sends this information to the Jumbo module via a JMB_MMAS_Get_Parameters.confirm

5.6.5.2.2 JMB_MMAS_Get_Parameters.confirm

Function

This primitive is used by the MMAS to return the values of the queried parameters to the Jumbo module.




JMB_MMAS_Get_Parameters.confirm( Status, LinkParametersResult )

Parameters:






LIST(

SEQUENCE(

LINK_PARAM_LTE-A,

LINK_PARAM_VAL)

)


Table 44: JMB_MMAS_Get_Parameters.confirm parameter list

When generated

This message is generated at the MMAS after retrieving the value of the requested parameters.

Effect on receipt

The MMAS receives the information on Jumbo parameter configuration.

5.6.5.3 JMB_MMAS_Parameters_Report

5.6.5.3.1 JMB_MMAS_Parameters_Report.indication

Function

This event is generated by the MMAS upon threshold crossing or timer expiration, in order to inform the Jumbo module of a wireless link event.


JMB_MMAS_Parameters_Report.indication( LinkParametersReport )

Parameters:



LIST(

SEQUENCE(

LINK_PARAM_LTE-A,




LINK_PARAM_VAL)

)

Table 45: JMB_MMAS_Parameters_Report.indication parameter list

When generated

This message is generated at the MMAS upon threshold crossing or timer expiration.

Effect on receipt

The MMAS is notified about the Jumbo related information that crossed the predefined threshold.

5.6.6 EMBMS_VFSIC_If

The objective of this interface is to trigger the MBMS Session Start procedure in the LTE eNodeB.

5.6.6.1 EMBMS_VFSIC_SessionStart

5.6.6.1.1 EMBMS_VFSIC_SessionStart.request

Function

Used to indicate to the MBMS function that a new session should be started


EMBMS_VFSIC_SessionStart.request ( SessionID, RequestedQOS, RequestedRate )

Parameter Type Description

SessionID FLOW_ID Identifier (5-tuple) for the new flow. This parameter has been described in section 4.6.3

RequestedQoS COS This parameter specifies the required traffic class

RequestedRate LINK_DATA_RATE This parameter specifies the required data rate on the link for the MBMS session.

Table 46: EMBMS_VFSIC_SessionStart.request parameter list

When generated

This message is received from the VFSIC to request the EMBMS sub-system to start a new session

Effect on receipt

The EMBMS propagates the session request to the LTE eNodeB to allocate the necessary resources and start broadcasting the information on the MCCH channel if not already available, allowing the users to join it.

5.6.6.1.2 EMBMS_VFSIC_SessionStart.confirm

Function

Used to indicate that the request to start a new session has been processed.




EMBMS_VFSIC_SessionStart.confirm ( SessionID, ReturnCode )


SessionID FLOW_ID Identifier (5-tuple) for the new flow. This parameter has been described in section 4.6.3

ReturnCode UNSIGNED_INT Status code indicating whether the request could be satisfied (0), or was rejected due to lack of resources (1), or due to failed procedure (2)

Table 47: EMBMS_VFSIC_SessionStart.confirm parameter list

When generated

Generated by the EMBMS once the LTE eNodeB has committed the necessary resources for accommodating the new flow.

Effect on receipt

The data belonging to this MBMS session can be forwarded to the eNodeB.

5.6.6.2 EMBMS_VFSIC_SessionStop

5.6.6.2.1 EMBMS_VFSIC_SessionStop.request

Function

Used to indicate to the EMBMS function that an existing session should be stopped.


EMBMS_VFSIC_SessionStop.request ( SessionID, )


SessionID FLOW_ID Identifier (5-tuple) for the flow to be stopped. This parameter has been described in section 4.6.3

Table 48: EMBMS_VFSIC_SessionStop.request parameter list

When generated

This message is received from the VFSIC to request the EMBMS sub-system to deactivate the resources related to an existing session.

Effect on receipt

The EMBMS propagates the request to the LTE eNodeB to stop broadcasting the information on the MCCH channel and de-allocate the used resources



5.6.6.2.2 EMBMS_VFSIC_SessionStop.confirm

Function

Used to indicate that the request to stop a session has been processed.


EMBMS_VFSIC_SessionStop.confirm ( SessionId, ReturnCode )


SessionId FLOW_ID Identifier for the stopped flow

ReturnCode UNSIGNED_INT Status code indicating whether the request could be satisfied (0), or was rejected due to lack of resources (1), or due to failed procedure (2)

Table 49: EMBMS_VFSIC_SessionStop.confirm parameter list

When generated

Generated by the EMBMS once the LTE eNodeB has released the resources that were used by the stopping flow.

Effect on receipt

No more data belonging to this MBMS session can be forwarded to the eNodeB.

5.6.7 L2PRLY_VFSIC_If

Function

This interface covers the following procedures introduced with the LTE 2P Relay:

radio attachment of the LTE relay to the LTE eNodeB

attachment of a mobile node to the cellular system through the LTE relay,

session setup

session tear down,

detachment of the mobile node,

detachment of the LTE relay from the network.

It uses the primitives similar to those introduced in section 5.4.4 (L25_VFSIG_If), but triggers specific procedures.



6 Summary and Conclusion This deliverable presented the concepts defined in the Wireless Access subsystem in order to take part in the MEDIEVAL cross-layer optimization framework.

A first step consisted in the review of technologies currently available for the wireless access. Some of them can easily be foreseen, such as WLAN which represents the contention-based wireless accesses or the LTE-A which represents the coordination-based wireless accesses. Others are less usual, e.g. the usage of IEEE 802.21 Media Independent Services as a Layer 2.5 abstraction or the MBMS which provides point-to-multipoint capability to the cellular medium. The usage of Jumbo frames, which is usually considered for wired medium such as the Ethernet, is also analyzed.

In a second step is described how these technologies are used and optimized for the transport of mobile video applications. Several techniques which are specific to a certain technology or more generic are explained. The upcoming 802.11aa amendment will enhance the WLAN standard for addressing more specifically the video flows. Multicast with eMBMS in LTE-A enlarges the scope of this technology for more efficient multicast transmissions. Packet marking enables the selection or prioritization of the flows. The introduction of jumbo frames in the wireless access operation increases the efficiency in some specific cases. The LTE Medium Access scheduling can be enhanced to improve the support of video packets. Finally, the introduction of L3 LTE relays extends the network coverage and its bandwidth capability. All these techniques interact with a L2.5 abstraction which reuses and extends the media independence concept of the 802.21 framework to streamline the cross-layer cooperation with the upper layer components. Moreover, the distribution of the above mentioned functionalities across the various nodes of the wireless access network has been described.

The third step shows the interaction with upper layers, starting from the scenarios that were defined in the D1.1 deliverable and introducing the main cross layer optimization flows. This part is completed by an initial specification of the Wireless Access internal interfaces, the external interfaces being part of the global architecture in D1.1.

The upcoming implementation work will enable a revision and the preliminary testing of this architecture and these functionalities. It is expected that the techniques and interfaces proposed in this document will be validated while amended to improve their efficiency, in order to derive final specifications which will be part of the D3.2 deliverable.



Acknowledgements and Disclaimer

This work was partially funded by the European Commission within the 7th Framework Program in the context of the ICT project MEDIEVAL (Grant Agreement No. 258053). The views and conclusions contained here are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the MEDIEVAL project or the European Commission.



References

[1] Marco Mezzavilla, Michelle Wetterwald, Leonardo Badia, Daniel Corujo, Antonio de la Oliva Wireless Access Mechanisms and Architecture Definition in the MEDIEVAL Project; 2011 IEEE Workshop on multiMedia Applications over Wireless Networks (MediaWin2011), Corfu, Greece, June 2011

[2] IEEE Standard for Local and metropolitan area networks- Part 21: Media Independent Handover Services, IEEE Std. 802.21, 2008.

[3] C. J. Bernardos, A. de la Oliva, J. C. Zuniga, and T. Melia. Applicability Statement on Link Layer implementation/Logical Interface over Multiple Physical Interfaces. Internet Engineering Task Force, draft-bernardos-netext-ll-statement-01.txt (work-in-progress), March 2010.

[4] A. De La Oliva, A. Banchs, I. Soto, T. Melia, A. Vidal, An overview of IEEE 802.21: media-independent handover services, IEEE Wireless Communications 15 (4) (2008) 96–103.

[5] S. Das, M. Tauil, Y. Cheng, A. Dutta, D. Baker, M. Yajnik, D. Famolari, et al., IEEE 802.21: Media independent handover: Features, applicability, and realization, IEEE Communications Magazine (2009) 113.

[6] LAN/MAN Committee of the IEEE Computer Society, IEEE Std 802.11u-2009, Standards for Local and Metropolitan Area Networks - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications - Amendment 7: Interworking with External Networks.

[7] LAN/MAN Committee of the IEEE Computer Society, IEEE 802.16g- 2007 Standards for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems - Amendment 3: Management PLANe Procedure and Services.

[8] IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, IEEE Std. 802.11, 2007.

[9] IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 1: High-speed Physical Layer in the 5 GHZ Band, IEEE Amendment 802.11a, 1999.

[10] IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 4: Further Higher Data Rate Extension in the 2.4 GHz Band, IEEE Amendment 802.11g, 2003.

[11] S.Kasera,G.Hjalmtusson,D.Towsley,andJ.Kurose,“Scalablereliable multicast using multiple multicast channels,” Networking, IEEE/ACM Transactions on, vol. 8, no. 3, pp. 294 –310, Jun. 2000.

[12] IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 2: Higher-speed Physical Layer (PHY) extension in the 2.4 GHz band, IEEE Amendment 802.11b, 2001

[13] IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications - Amendment 5: Enhancements for Higher Throughput, IEEE Std. 802.11n, 2009.

[14] IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements, IEEE Amendment 802.11e, 2005.

[15] A. Banchs, P. Serrano, and L. Vollero, “Providing service guarantees in 802.11e edca wlans with legacy stations,” Mobile Computing, IEEE Transactions on, vol. 9, no. 8, pp. 1057 –1071, 2010.



[16] P.Serrano, A.Banchs, P.Patras and A.Azcorra,“Optimal configuration of 802.11e EDCA for real-time and data traffic,” Vehicular Technology, IEEE Transactions on, vol. 59, no. 5, pp. 2511 –2528, Jun. 2010.

[17] IEEE P802.11aa/D3.01 Draft Standard for Information Technology- Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wire- less LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 3: MAC Enhancements for Robust Audio Video Streaming, IEEE Amendment 802.11aa, 2011.

[18] IEEE 802.1Qat/D6.1 Draft Standard for Information Technology- Telecommunications and information exchange between systems-Local and metropolitan area networks: Virtual Bridged Local Area Networks - Amendment 9: Stream Reservation Protocol (SRP), IEEE Std. 802.1Qat, 2010.

[19] IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications - Amendment 8: IEEE 802.11 Wireless Network Management, IEEE Std. 802.11v, 2011.

[20] Mathis, M., Semke, J., Mahdavi, J. and Ott, T., “The macroscopic behavior of the TCP congestion avoidance algorithm”, ACM SIGCOMM Computer Communication Review, Vol. 27, Issue 3, July 1997

[21] Iyer, A.P.; Deshpande, G.; Rozner, E.; Bhartia, A.; Lili Qiu; , "Fast Resilient Jumbo frames in wireless LANs," Quality of Service, 2009. IWQoS. 17th International Workshop on , vol., no., pp.1-9, 13-15 July 2009

[22] Ming Li, Devesh Agrawal, Deepak Ganesan, and Arun Venkataramani. 2009. Block-switched networks: a new paradigm for wireless transport. In Proceedings of the 6th USENIX symposium on Networked systems design and implementation (NSDI'09)

[23] 3GPP, http://www.3gpp.org

[24] 3GPP TS 36.300 ; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 10)

[25] S. Sesia, M. P. J. Baker, I. Toufik, LTE, the UMTS long term evolution: from theory to practice.

[26] R. Madan, S. P. Boyd, and S. Lall, “Fast algorithms for resource allocation in cellular networks,” IEEE/ACM Trans- actions on Networking, vol.18, no.3, June 2010.

[27] B. Sadiq, R. Madan, and A. Sampath, “Downlink Scheduling for Multiclass Traffic in LTE, ” EURASIP Journal on Wire- less Communications and Networking, vol. 2009, Article ID 510617, 18 pages, 2009.

[28] H. Luo, S. Ci, D. Wu, J. Wu, H. Tang, “Quality-Driven Cross-Layer Optimized Video Delivery over LTE,” IEEE Communications Magazine, vol.48, February 2010

[29] H. A. M. Ramli, K. Sandrasegaran, R. Basukula, R. Patachaianand, M. Xue, and C.-C. Lin, Resource Allocation Technique for Video Streaming Applications in the LTE System, in Wireless and Optical Communications Conference, Shanghai, China, May 2010.

[30] 3GPP TS 23.246, MBMS; Architecture and functional description, Release 6

[31] 3GPP TR R3.018 "Evolved UTRA and UTRAN Radio Access Architecture and Interfaces", Release 7, 2007.

[32] 3GPP TS 23.246, MBMS; Architecture and functional description, Release 9.

[33] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[34] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.

[35] Antonio de la Oliva, Yoshihiro Ohba, Christian Niephaus and Johannes Lessmann, “Comment to LB4a (MIH_Radio_Get_Capabilities)”, Presented in the 43th IEEE 802.21 meeting, March 2011.



Available: https://mentor.ieee.org/802.21/dcn/11/21-11-0031-02-bcst-comment-to-lb4a-mih-radio-get-capabilities.docx

[36] Antonio de la Oliva, Yoshihiro Ohba, Christian Niephaus and Johannes Lessmann, “Comment to LB4a (Radio_Get_Capabilities)”, Presented in the 43th IEEE 802.21 meeting, March 2011. Available: https://mentor.ieee.org/802.21/dcn/11/21-11-0030-02-0000-comment-to-lb4a-radio-get-capabilities.docx

[37] Antonio de la Oliva, Yoshihiro Ohba, Christian Niephaus and Johannes Lessmann, “Comment to LB4a (Clean Up)”, Presented in the 43th IEEE 802.21 meeting, March 2011. Available: https://mentor.ieee.org/802.21/dcn/11/21-11-0028-01-bcst-comment-to-lb4a-radio-get-parameters.docx

[38] Antonio de la Oliva, Yoshihiro Ohba, Christian Niephaus and Johannes Lessmann, “Comment to LB4a (Radio_Get_Parameters)”, Presented in the 43th IEEE 802.21 meeting, March 2011. Available: https://mentor.ieee.org/802.21/dcn/11/21-11-0028-01-bcst-comment-to-lb4a-radio-get-parameters.docx

[39] Antonio de la Oliva, Yoshihiro Ohba, Christian Niephaus and Johannes Lessmann, Comment to LB4a (Radio_Set_Parameters)”, Presented in the 43th IEEE 802.21 meeting, March 2011. Available: https://mentor.ieee.org/802.21/dcn/11/21-11-0029-01-bcst-comment-to-lb4a-radio-set-parameters.docx

[40] Antonio de la Oliva, Daniel Corujo, “Suggested Remedy (Network Types)”, Presented in the 44th IEEE 802.21 meeting, May 2011. Available: https://mentor.ieee.org/802.21/dcn/11/21-11-0080-00-bcst-suggested-remedy-network-types.docx

[41] MEDIEVAL, Deliverable D1.1, Preliminary architecture design

[42] MEDIEVAL, Deliverable D4.1, "Light IP Mobility architecture for Video Services: initial architecture"



Appendix I Contributions to the IEEE 802.21 standard

This appendix provides a copy of the different contributions submitted to the IEEE 802.21b.

I.1 Comment to LB4a (MIH_Radio_Get_Capabilities)

Presented in the 43th IEEE 802.21 meeting, March 2011.

Link: https://mentor.ieee.org/802.21/dcn/11/21-11-0031-02-bcst-comment-to-lb4a-mih-radio-get-capabilities.docx

Project IEEE 802.21b

<https://mentor.ieee.org/802.21>

Title Suggested Remedies for 802.21b: MIH_Radio_Get_Capabilities

DCN 21-11-0031-02-bcst

Date Submitted

Source(s) Antonio de la Oliva, Yoshihiro Ohba, Christian Niephaus, Johannes Lessmann

Re:

Abstract The functionality provided by MIH_Radio_Get_Capabilities can be included in MIH_Capabilities_Discover primitive.The changes proposed here are mean to replace current MIH_Radio_Get_Capabilities primitive from .21b draft v2.

Purpose Proposes changes in the current draft

Notice This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that IEEE 802.21 may make this contribution public.

Patent Policy

The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf

Changes Required 7.4.1 MIH_Capability_Discover 7.4.1.1 MIH_Capability_Discover.request 7.4.1.1.1 Function



This primitive is used by an MIH user to discover the capabilities of the local MIHF or a remote MIHF. When invoking this primitive to discover the capabilities of a remote MIHF, the MIH user can optionally piggyback the capability information of its local MIHF so that the two MIHFs can mutually discover each otherí’s capabilities with a single invocation of this primitive. 7.4.1.1.2 Semantics of service primitive MIH_Capability_Discover.request (

DestinationIdentifier, LinkAddressList, SupportedMihEventList, SupportedMihCommandList, SupportedIsQueryTypeList, SupportedTransportList, MBBHandoverSupport, SupportedLinkActionsList )

Parameters: Name Data type Description DestinationIdentifier MIHF_ID This identifies the local MIHF or

a remote MIHF that will be the destination of this request.

LinkAddressList LIST(NET_TYPE_ADDR)

(Optional) A list of network type and link address pair on the local MIHF.

SupportedMIHEventList MIH_EVT_LIST (Optional) List of supported events on the local MIHF.

SupportedMIHCommandList MIH_CMD_LIST (Optional) List of supported commands on the local MIHF.

SupportedISQueryTypeList MIH_IQ_TYPE_LST (Optional) List of supported MIIS query types on the local MIHF.

SupportedTransportList MIH_TRANS_LST (Optional) List of supported transport types on the local MIHF.

MBBHandoverSupport LIST(MBB_HO_SUPP)

(Optional) This is used to indicate if a make before break handover is supported on the local MIHF. Break before make handover is always supported.

SupportedLinkActionsList LINK_ACTION_LIST (Optional) In case bit 2 of SupportedMIHCommandList parameter is set, SupportedLinkActionsList indicates the list of supported link actions on the local MIHF.

Table 50: MIH_Capability_Discover.request parameter list

7.4.1.1.3 When generated This primitive is generated by an MIH user to discover the capabilities of the local MIHF or a remote MIHF. In the case of remote discovery, this primitive contains the SupportedMihEventList, SupportedMihCommandList, SupportedIsQueryTypeList, SupportedTransportList, and MBBHandoverSupport parameters of the local MIHF to enable mutual discovery of each otherí’s capabilities.



7.4.1.1.4 Effect on receipt If the destination of the request is the local MIHF itself, the local MIHF responds with MIH_Capability_Discover.confirm. If the destination of the request is a remote MIHF, the local MIHF shall generate a corresponding MIH_Capability_Discover request message to the remote MIHF if it does not have the capability information of the remote MIHF. 7.4.1.2 MIH_Capability_Discover.indication 7.4.1.2.1 Function This primitive is used by an MIHF to notify an MIH user on the receipt of an MIH_Capability_Discover request message from a peer MIHF. 7.4.1.2.2 Semantics of service primitive MIH_Capability_Discover.indication ( SourceIdentifier,

LinkAddressList, SupportedMihEventList, SupportedMihCommandList, SupportedIsQueryTypeList, SupportedTransportList, MBBHandoverSupport, SupportedLinkActionsList )

Parameters: Name Data type Description SourceIdentifier MIHF_ID This identifies the invoker of

this primitive, which is a remote MIHF.

LinkAddressList LIST(NET_TYPE_ADDR) (Optional) A list of network type and link address pair on the remote MIHF.

SupportedMIHEventList MIH_EVT_LIST (Optional) List of supported events on the remote MIHF.

SupportedMIHCommandList MIH_CMD_LIST (Optional) List of supported commands on the remote MIHF.

SupportedISQueryTypeList MIH_IQ_TYPE_LST (Optional) List of supported MIIS query types on the remote MIHF.

SupportedTransportList MIH_TRANS_LST (Optional) List of supported transport types on the remote MIHF.

MBBHandoverSupport LIST(MBB_HO_SUPP) (Optional) This is used to indicate if a make before break handover is supported on the remote MIHF. Break before make handover is always supported.

SupportedLinkActionsList LINK_ACTION_LIST (Optional) In case bit 2 of SupportedMIHCommandList parameter is set, SupportedLinkActionsList indicates the list of supported link actions on the remote MIHF.



Table 51: MIH_Capability_Discover.indication parameter list

7.4.1.2.3 When generated This primitive is used by an MIHF to notify an MIH user when an MIH_Capability_Discover request message is received. This primitive is optional since the MIHF can immediately return an MIH_Capability_Discover response message without generating this primitive to the MIH user. 7.4.1.2.4 Effect on receipt The MIH user responds with an MIH_Capability_Discover.response primitive when an indication is received. 7.4.1.3 MIH_Capability_Discover.response 7.4.1.3.1 Function This primitive is used by an MIH user to convey the locally supported MIH capabilities to the MIH user that invoked the MIH_Capability_Discover request. 7.4.1.3.2 Semantics of Service primitive MIH_Capability_Discover.response(

DestinationIdentifier, Status,

LinkAddressList, SupportedMihEventList, SupportedMihCommandList, SupportedIsQueryTypeList, SupportedTransportList, MBBHandoverSupport, SupportedLinkActionsList )

Parameters: Name Data type Description DestinationIdentifier MIHF_ID This identifies the remote

MIHF that will be the destination of this response.

Status STATUS Status of operation. LinkAddressList LIST(NET_TYPE_ADDR) (Optional) A list of network

type and link address pair on local MIHF

SupportedMIHEventList MIH_EVT_LIST (Optional) List of supported events on local MIHF.

SupportedMIHCommandList MIH_CMD_LIST (Optional) List of supported commands on local MIHF.

SupportedISQueryTypeList MIH_IQ_TYPE_LST (Optional) List of supported MIIS query types on local MIHF.

SupportedTransportList MIH_TRANS_LST (Optional) List of supported transport types on local MIHF.

MBBHandoverSupport LIST(MBB_HO_SUPP) (Optional) This is used to indicate if a make before break handover is supported on local MIHF. Break before



make handover is always supported.

SupportedLinkActionsList LINK_ACTION_LIST (Optional) In case bit 2 of SupportedMIHCommandList parameter is set, SupportedLinkActionsList indicates the list of supported link actions on the local MIHF.

Table 52: MIH_Capability_Discover.response parameter list

7.4.1.3.3 When generated This primitive is generated by an MIH user as a response to a received MIH_Capability_Discover.indication primitive. 7.4.1.3.4 Effect on receipt Upon receiving this primitive, the MIHF shall generate and send the corresponding MIH_Capability_Discover response message to the destination MIHF. 7.4.1.4 MIH_Capability_Discover.confirm 7.4.1.4.1 Function This primitive is used by the MIHF to convey the supported MIH capabilities about Event Service, Command Service, and Information Service to the MIH user that invoked the MIH_Capability_Discover.request. 7.4.1.4.2 Semantics of service primitive MIH_Capability_Discover.confirm (

SourceIdentifier, Status, LinkAddressList,

SupportedMihEventList, SupportedMihCommandList, SupportedIsQueryTypeList, SupportedTransportList, MBBHandoverSupport, SupportedLinkActionsList )

Parameters: Name Data type Description SourceIdentifier MIHF_ID This identifies the invoker of

this primitive, which can be either the local MIHF or a remote MIHF.

Status STATUS Status of operation. LinkAddressList LIST(NET_TYPE_ADDR) (Optional) A list of network

type and link address pair on the MIHF identified by Source Identifier.

SupportedMIHEventList MIH_EVT_LIST (Optional) List of supported events on the MIHF identified by Source Identifier.

SupportedMIHCommandList MIH_CMD_LIST (Optional) List of supported



commands on the MIHF identified by Source Identifier.

SupportedISQueryTypeList MIH_IQ_TYPE_LST (Optional) List of supported MIIS query types on the MIHF identified by Source Identifier.

SupportedTransportList MIH_TRANS_LST (Optional) List of supported transport types on the MIHF identified by Source Identifier.

MBBHandoverSupport LIST(MBB_HO_SUPP) (Optional) This is used to indicate if a make before break handover is supported on the MIHF identified by Source Identifier. Break before make handover is always supported.

SupportedLinkActionsList LINK_ACTION_LIST (Optional) In case bit 2 of SupportedMIHCommandList parameter is set, SupportedLinkActionsList indicates the list of supported on the MIHF identified by the SourceIdentifier.

Table 53: MIH_Capability_Discover.confirm parameter list

7.4.1.4.3 When generated This primitive is invoked by a local MIHF to convey the results of a previous MIH_Capability_Discover.request primitive from an MIH user. 7.4.1.4.4 Effect on receipt Upon reception of this primitive the receiving entity becomes aware of the supported MIH capabilities. However, if Status does not indicate ì“Success,î” the recipient ignores any other returned values and, instead, performs appropriate error handling. 8.6.1 MIH messages for service management 8.6.1.1 MIH_Capability_Discover request The corresponding MIH primitive of this message is defined in 7.4.1.1. If a requesting MIHF entity knows the destination MIHF entityí’s MIHF ID, the requesting MIHF entity fills its destination MIHF ID and sends this message to the peer MIHF over the data plane, either L2 or L3. If a requesting MIHF entity does not know the destination MIHF entityí’s MIHF ID, the requesting MIHF entity may fill its destination MIHF ID with a multicast MIHF ID to send this capability discover message.

MIH Header Fields (SID=1, Opcode=1, AID=1) Source Identifier = sending MIHF ID

(Source MIHF ID TLV) Destination Identifier = receiving MIHF ID

(Destination MIHF ID TLV) LinkAddressList (optional)

(Link address list TLV) SupportedMihEventList (optional)

(MIH event list TLV)



SupportedMihCommandList (optional) (MIH command list TLV)

SupportedISQueryTypeList (optional) (MIIS query type list TLV)

SupportedTransportList (optional) (Transport option list TLV)

MBBHandoverSupport (optional) (MBB handover support TLV)

SupportedLinkActionsList (optional) (Link Actions list TLV)

Table 54: MIH_Capability_Discover request message

8.6.1.2 MIH_Capability_Discover response The corresponding MIH primitive of this message is defined in 7.4.1.3. This message is sent in response to an MIH_Capability_Discover request message that was destined to a single or multicast MIHF ID.

MIH Header Fields (SID=1, Opcode=2, AID=1)Source Identifier = sending MIHF ID

(Source MIHF ID TLV) Destination Identifier = receiving MIHF ID

(Destination MIHF ID TLV) Status

(Status TLV) LinkAddressList (optional)

(Link address list TLV) SupportedMihEventList (optional)

(MIH event list TLV) SupportedMihCommandList (optional)

(MIH command list TLV) SupportedISQueryTypeList (optional)

(MIIS query type list TLV) SupportedTransportList (optional)

(Transport option list TLV) MBBHandoverSupport (optional)

(MBB handover support TLV) SupportedLinkActionsList (optional)

(Link Actions list TLV)

Table 55: MIH_Capability_Discover response message

ADD TO TABLE L.2 Link Actions list TBD by editor LINK_ACTION_LIST

I.2 Comment to LB4a (Radio_Get_Capabilities)


Link: https://mentor.ieee.org/802.21/dcn/11/21-11-0030-02-0000-comment-to-lb4a-radio-get-capabilities.docx





Title Suggested Remedies for 802.21b: Radio_Get_Parameters

DCN 21-11-0030-01-bcst

Date Submitted


Re:

Abstract The functionality provided by Radio_Get_Capabilities can be included in Link_Capability_Discover primitive. The proposed change aims at replacing current Radio_Get_Capabilities primitive from .21b draft v2.




Patent Policy


Changes Required 7.3.9 Link_Capability_Discover 7.3.9.1 Link_Capability_Discover.request 7.3.9.1.1 Function This primitive is used by the MIHF to query and discover the list of supported link-layer events and linklayer commands. 7.3.9.1.2 Semantics of service primitive No primitive parameters exist for this primitive. Link_Capability_Discover.request () 7.3.9.1.3 When generated This primitive is generated by the MIHF when it needs to receive link-layer event notifications and learn about which link-layer commands the lower layer can support. 7.3.9.1.4 Effect on receipt The recipient responds immediately with Link_Capability_Discover.confirm primitive. 7.3.9.2 Link_Capability_Discover.confirm 7.3.9.2.1 Function This primitive returns the result of the query to discover link-layer capability. 7.3.9.2.2 Semantics of service primitive



Link_Capability_Discover.confirm( Status,

SupportedLinkEventList, SupportedLinkCommandList, SupportedLinkActionsList )

Parameters:

Name Data type Description Status STATUS Status of operation. Code 3

(Authorization Failure) is not applicable.

SupportedLinkEventLista LINK_EVENT_LIST List of link-layer events supported by the link layer.

SupportedLinkCommandList LINK_CMD_LIST List of link-layer commands supported by the link layer.

SupportedLinkActionsList LINK_ACTION_LIST In case bit 5 of SupportedLinkCommandList parameter is set, SupportedLinkActionsList indicates which link actions are supported by the link.

Table 56: Link_Capability_Discover.confirm parameter list

7.3.9.2.3 When generated This primitive is generated in response to a Link_Capability_Discover.request primitive. 7.3.9.2.4 Effect on receipt The recipient examines the returned event and command list and learns about link-layer capability. However, if Status does not indicate “Success” the recipient performs appropriate error handling. MODIFY TABLE F.4 ADDING THE FOLLOWING DATA TYPE LINK_ACTION_LIST BITMAP(32) A list of link actions.

Bitmap Values: Bit 0: Reserved Bit 1: LINK_DISCONNECT Bit 2: LINK_LOW_POWER Bit 3: LINK_POWER_DOWN Bit 4: LINK_POWER_UP Bit 5: LINK_CONFIGURE Bit 6-31: (Reserved)

Table 57: LINK_ACTION_LIST parameter

I.3 Comment to LB4a (Clean Up)


Link: https://mentor.ieee.org/802.21/dcn/11/21-11-0032-02-bcst-comment-to-lb4a-clean-up.docx





Title Suggested Remedies for 802.21b: Clean_Up

DCN 21-11-0032-02-bcst

Date Submitted


Re:

Abstract The purpose of this contribution is to highlight the data types and primitives that should be removed from the standard since they are not use anymore.




Patent Policy


Changes Required REMOVE FROM TABLE F.4 (UNUSED DATA TYPES ONLY USED BY MY PREVIOUS PROPOSAL) RADIO_CONFIG_PARAMETERS RADIO_CAPABILITY_REQ RADIO_CAPABILITY_TYPE RADIO_CAPABILITY_RSP RADIO_CAPAB_VAL REMOVE FROM TABLE L.2 THE OLD PRIMITIVES Radio_Configuration_Parameters Radio_Capabilities_Request Radio_Capabilities_Response Current_Interface_Configuration REMOVE CLAUSES -7.3.15 -7.3.16 -7.3.17 -7.4.28 -7.4.29 -7.4.30



-8.6.3.24 -8.6.3.25 -8.6.3.26 -8.6.3.27 -8.6.3.28 -8.6.3.29 -8.6.3.30

I.4 Comment to LB4a (Radio_Get_Parameters)


Link: https://mentor.ieee.org/802.21/dcn/11/21-11-0028-01-bcst-comment-to-lb4a-radio-get-parameters.docx



Title Suggested Remedies for 802.21b: Radio_Get_Parameters

DCN 21-11-0028-01-bcst

Date Submitted


Re:

Abstract The functionality provided by Radio_Get_Parameters can be included in Link_Get_Parameters primitive. The change proposed aims at replacing current Radio_Get_Parameter and MIH_Radio_Get_Parameters primitives present at .21b draft v2.




Patent Policy


Changes Required No change is required in clause 7.3.12 (Link_Get_Parameters primitive).



Need to modify the following data types: MODIFY TABLE F.4 ACCORDING TO: LINK_PARAM_GEN UNSIGNED_INT(1) A type to represent a generic link

parameter that is applicable to any link type. 0: Data Rate—the parameter value is represented as a DATA_RATE. 1: Signal Strength—the parameter value is represented as a SIG_STRENGTH. 2: Signal over interference plus noise ratio (SINR)—the parameter value is represented as an UNSIGNED_INT(2). 3:Throughput (the number of bits successfully received divided by the time it took to transmit them over the medium) —the parameter value is represented as an UNSIGNED_INT(2). 4: Packet Error Rate (representing the ratio between the number of frames received in error and the total number of frames transmitted in a link population of interest)—the parameter value is represented as a PERCENTAGE. 5: Channel Central frequency—the parameter value is represented as a FREQUENCY. 6: Channel Central bandwidth—the parameter value is represented as BANDWIDTH. 7: Channel Central power—the parameter value is represented as TX_POWER. 8: Higher adjacent channel frequency—the parameter value is represented as a FREQUENCY. 9: Higher adjacent channel bandwidth—the parameter value is represented as BANDWIDTH. 10: Higher adjacent channel power—the parameter value is represented as TX_POWER. 11: Lower adjacent channel frequency—the parameter value is represented as a FREQUENCY. 12: Lower adjacent channel bandwidth—the parameter value is represented as BANDWIDTH. 13: Lower adjacent channel power—the parameter value is represented as TX_POWER. 14--255: (Reserved)



Table 58: LINK_PARAM_GEN parameter

Corresponding MIH SAP primitive MIH_Link_Get_Parameters does not require any change

I.5 Comment to LB4a (Radio_Set_Parameters)


Link: https://mentor.ieee.org/802.21/dcn/11/21-11-0029-01-bcst-comment-to-lb4a-radio-set-parameters.docx



Title Suggested Remedies for 802.21b: Radio_Set_Parameters

DCN 21-11-0029-01-bcst

Date Submitted


Re:

Abstract The functionality provided by Radio_Set_Parameters can be included in Link_Action primitive. The proposed change aims at replacing the Radio_Set_Parameters and MIH_Radio_Set_Parameters primitives of current .21b draft v2.




Patent Policy




Changes Required No change is required in clause 7.3.14 (Link_Action primitive). Need to modify the following data types: CHANGE THE LINK_ACTION DATA TYPE IN TABLE F.4 LINK_ACTION SEQUENCE(

LINK_AC_TYPE, LINK_AC_ATTR, LINK_AC_PARAM )

Link action

Table 59: LINK_ACTION parameter

ADD LINK_AC_PARAM TO F.4 LINK_AC_PARAM CHOICE(NULL,

CHANNEL_CONFIG_SET). The choice of CHANNEL_CONFIG_SET is used when the LINK_CONFIGURE action is selected in order to provide the configuration to be set up in the interface

Table 60: LINK_AC_PARAM parameter

CHANNEL_CONFIG_SET is already defined in current .21b draft v2. CHANGE IN TABLE F.4 THE DEFINITION OF LINK_AC_TYPE AS: LINK_AC_TYPE UNSIGNED_INT(1) An action for a link. The

meaning of each link action is defined in Table F.5. 0: NONE 1: LINK_DISCONNECT 2: LINK_LOW_POWER 3: LINK_POWER_DOWN 4: LINK_POWER_UP 5: LINK_CONFIGURE 6–255: (Reserved)

Table 61: LINK_AC_TYPE parameter

ADD TO TABLE F.5 THE FOLLOWING: LINK_CONFIGURE Apply the requested channel configuration to the interface.

Table 62: LINK_CONFIGURE parameter

Corresponding MIH SAP primitive MIH_Link_Actions does not require any change



I.6 Suggested Remedy (Network Types)

Presented in the 44th IEEE 802.21 meeting, May 2011

Link: https://mentor.ieee.org/802.21/dcn/11/21-11-0080-00-bcst-suggested-remedy-network-types.docx



Title Suggested Remedies for 802.21b: New Network Types need to be defined

DCN 21-11-0080-00-bcst

Date Submitted

16/05/2011

Source(s) Antonio de la Oliva (UC3M), Daniel Corujo (ITAv)

Re:

Abstract IEEE 802.21b extends IEEE 802.21 to handle DO technologies such as DVB, T-DMB and ATSC-M/H. This technologies are not defined as Network Types




Patent Policy


Suggested Changes:



This contribution also updates table F.14 and tables derived from it with the latest version of the RADIUS NAS-Port Type mapping. Change Table F.14 in the following way: Network Link type Network subtype (Reserved) 0 N/A Wireless - GSM 1 N/A Wireless - GPRS 2 N/A Wireless - EDGE 3 N/A (Reserved) 4-14 N/A Ethernet - IEEE 802.3 15 Bit 0: 10 Mb

Bit 1: 100 Mb Bit 2: 1000 Mb Bit 3ñ–63: (Reserved) The above bits represent the link speeds that Ethernet supports. The capability information of twisted pair Ethernet link can be obtained via auto-negotiation as defined in Clause 28 of IEEE Std 802.3.

(Reserved) 16-17 N/A Wireless - Other 18 Bit 0: DVB

Bit 1: T-DMB Bit 2: ATSC-M/H

Wireless - IEEE 802.11 19 Bit 0: 2.4 GHz Bit 1: 5 GHz Bit 2: 4.9 GHz Bit 3: 3.65 GHz Bit 4: 316 THz Bit 5-63 (Reserved) The above bits represent the frequency band that IEEE 802.11 link supports. The capability information and extended capabilities information of IEEE 802.11 link can further be represented as defined in 7.3.1.4 and 7.3.2.27, respectively, of IEEE Std 802.11-2007.

(Reserved) 20-21 N/A Wireless - CDMA2000 22 N/A Wireless - UMTS 23 Bit 0: Rel-99

Bit 1: Rel-4 Bit 2: Rel-5 (w/ HSDPA) Bit 3: Rel-6 (w/ HSUPA) Bit 4: Rel-7 (MIMO/OFDM)



Bit 5: Rel-8 Bit 6ñ–63: (Reserved)

Wireless - cdma2000-HRPD 24 Bit 0: Rev-0 Bit 1: Rev-A Bit 2: Rev-B Bit 3: Rev-C Bit 4ñ–63: (Reserved)

(Reserved) 25-26 N/A Wireless - IEEE 802.16 27 Bit 0: 2.5 GHz

Bit 1: 3.5 GHz Bit 2-63: (Reserved) The above bits represent the frequency band that IEEE 802.16 link supports. The system profiles of IEEE 802.16 link can further be represented as defined in clause 12 (12.3 and 12.4) of IEEE Std 802.16e-2005.

Wireless - IEEE 802.20 28 N/A Wireless - IEEE 802.22 29 N/A (Reserved) 30-35 N/A Wireless-XGP 36 N/A (Reserved) 37-255 N/A

Table 63: Modification of Table F.14 from IEEE 802.21

NOTE- The Link type values in Table F.14 are deliberately made consistent with RADIUS network access server (NAS)-Port-Type definitions as specified by Internet Assigned Numbers Authority (IANA). NOTE: The DO technologies which do not have associated any RADIUS NAS-Port-Type are indicated through a subtype of Wireless-Other. Change table F.15 as: Network Link type Network subtype NET_TYPE_INC BITMAP(32) A type to represent a set of

link types. The value is a four octet bitmap: Bit 0: Wireless - GSM Bit 1: Wireless - GPRS Bit 2: Wireless - EDGE Bit 3: IEEE 802.3 (Ethernet) Bit 4: Wireless - Other Bit 5: Wireless - IEEE 802.11 Bit 6: Wireless - CDMA2000 Bit 7: Wireless - UMTS Bit 8: Wireless - cdma2000-HRPD Bit 9: Wireless - IEEE 802.16 Bit 10: Wireless - IEEE 802.20 Bit 11: Wireless - IEEE 802.22 Bit 12: Wireless-DVB



Bit 13: Wireless-DMB Bit 14: Wireless-ATSC-M/H Bit 15–31: (Reserved AND shall be always set to 0)

Table 64: Modification of Table F.15 from IEEE 802.21



Appendix II Relevant paper contributions

II.1 Wireless access mechanisms and architecture definition in the MEDIEVAL project

Marco Mezzavilla, Michelle Wetterwald, Leonardo Badia, Daniel Corujo, Antonio De La Oliva, "Wireless access mechanisms and architecture definition in the MEDIEVAL project", MediaWin 2011, 6th IEEE Workshop on multiMedia Applications over Wireless Networks, June 28th, 2011, Kerkyra (Corfu), Greece

This paper presents the WP3 wireless access architecture, including the cross-layer design. It describes the main mechanisms that are considered for the enhanced contention-based and coordination-based wireless accesses, together with the abstraction layer and the usage of IEEE 802.21 framework as a basis for this work.

Abstract

Wireless network access and the exchange of multimedia flows over the Internet are becoming more and more pervasive in the everyday life. However, simple technological advances in terms of improved network capacity cannot satisfy the increasing demand of such services, since a paradigm shift from the current Internet architecture is required. The EU FP7 MEDIEVAL project tackles this issue by addressing novel architectural frameworks and viable strategies to efficiently deliver video services in a wireless Internet context. This paper reviews the currently ongoing activities of the project for what concerns wireless access, in particular the identification of useful techniques for the considered access technologies (WLAN and LTE-A) and the general definition of architectural schemes to efficiently support video flows.

II.2 Wireless access architectures for video applications: the approach proposed in the MEDIEVAL project;

Leonardo Badia, Rui L Aguiar, Albert Banchs, Telemaco Melia, Michelle Wetterwald, Michele Zorzi; "Wireless access architectures for video applications: the approach proposed in the MEDIEVAL project"; in proceedings MediaWiN 2010, IEEE Workshop on multiMedia Applications over Wireless Networks, 22 June 2010, Riccione, Italy; and in Proc. IEEE ISCC, Jun. 2010

This paper, written at the very beginning of the project, gives an overview of the challenges and the key points that the MEDIEVAL project plans to tackle in order to deliver video services over wireless access. It introduces a cross-layer network architecture to improve the users' quality of experience within the cellular networks of future deployment and presents the sub-systems envisioned to solve this problem. The Layer 2.5 Abstraction communicates with Contention-Based Wireless Accesses and Coordination-Based Wireless Accesses and hides their specificities to higher layers, while some enhancements are planned for each of these technologies.

Abstract

Video transmission is expected to be the next big thing in personal communication systems. While text messaging applications have already experienced an explosive growth, the exchange of multimedia content is still lacking architectural solutions which enable it to become the next killer application. The EU project MEDIEVAL (MultimEDia transport for mobIlE Video AppLications) [1] aims at filling this gap. In this paper we describe the approaches envisioned by the project for what concerns the data link layer, with special emphasis on wireless access and its related cross-layer issues. After presenting some general project aspects, we will review the state of the art and enumerate several open issues, concerning the identification of the most suitable radio technologies for video support, as well as their integration and required enhancements to enable efficient video transport.



II.3 Video-Enhancing Functional Architecture for the MEDIEVAL Project

Daniel Corujo, Albert Banchs, Telemaco Melia, Michelle Wetterwald, Leonardo Badia, Rui L Aguiar; "Video-Enhancing Functional Architecture for the MEDIEVAL Project", in proceedings MONAMI 2010, International ICST Conference on Mobile Networks and Management, September 2010, Santander, Spain.

This paper, also written at the very beginning of the project, presents the key points and challenges that the MEDIEVAL project will address aiming to deliver video services in an optimized way over wireless mobile access. The major architectural areas highlighted here are wireless access technologies, mobility, transport optimization and video services, which reflect the general work items of the project. Concerning the WP3 topics, it details in addition the planned key innovation points and research objectives for the areas of jumbo frames, MIH signalling extension and multicast support, which are important tools and mechanisms in the overall MEDIEVAL design.

Abstract

The MEDIEVAL project aims to leverage today’s Internet with the necessary fabric to provide optimized video services in a mobile wireless world. It is expected that video traffic will surpass Peer-to-Peer (P2P) in volume in the coming years, and thus novel mechanisms and techniques need to be provided to better suit its unique requirements. This article describes the key functional elements of the MEDIEVAL architecture, which provides a video-aware networking core coupled with abstracting interfaces which cater to service and access technology specific requirements, aiming to enable efficient video transport and novel video service development.

II.4 Key Function Interfacing for the MEDIEVAL Project Video-Enhancing Architecture

Daniel Corujo, Carlos J. Bernardos, Telemaco Melia, Michelle Wetterwald, Leonardo Badia, Rui L. Aguiar, "Key Function Interfacing for the MEDIEVAL Project Video-Enhancing Architecture", Proc. 3rd International ICST Conference on Mobile Networks and Management, Special Session on Future Research Directions, Aveiro, Portugal, Sep 2011

This paper addresses the overall architecture of the MEDIEVAL project, highlighting services, interfaces and use cases as well. In respect to WP3, it identifies interfaces involving the L2.5 abstraction layer, the WLAN and LTE link interfaces, enabling their access by the Mobility, Video Services and Transport Optimization functional counterparts.

Abstract

The FP7 M EDIEVAL project, which started in 2010, has been defining the necessary evolutions over today’s mobile Internet architecture, in order to more efficiently support the upcoming growth of video services, in mobile wireless environments. This paper evolves from these initial definitions, by taking into consideration the requirements placed by a core set of next generation video services and defining a global architecture. We describe its main functionalities and subsystems as well as the necessary interfaces, towards the operation of these services in different use cases.

II.5 IEEE 802.21: Media independence beyond handover

Antonio de la Oliva, Ignacio Soto, Albert Banchs, Johannes Lessmann, Christian Niepahus and Telemaco Melia, “IEEE 802.21: Media Independence beyond handover”, Elsevier Computer Standards and Interfaces, Volume 33, Issue 6, November 2011, pages 556-564.



This paper presents the key ideas on the architecture of WP3 applied to a generalized model for a Media Independent Service Layer, built on top of the Media Independent Handover Function defined in IEEE 802.21. The concepts extending this L2.5 including new primitives in order to tackle a set of novel scenarios through a media independent paradigm are covered in this publication, including also an analysis of the requirements that the new Media Independent Service Layer should met.

Abstract

The IEEE 802.21 standard facilitates media independent handovers by providing higher layer mobility management functions with common service primitives for all technologies. Right after the base specification was published, several voices rose up in the working group advocating to broaden the scope of IEEE 802.21 beyond handovers. This paper aims at updating the reader with the main challenges and functionalities required to create a Media Independence Service Layer, through the analysis of scenarios which are being discussed within the working group: 1) Wireless Coexistence, and 2) Heterogeneous Wireless Multihop Backhaul Networks.

II.6 Media-Independent Multicast Signalling for Enhanced Video Performance in the MEDIEVAL Project

Daniel Corujo, Sergio Figueiredo, Rui L. Aguiar, "Media-Independent Multicast Signalling for Enhanced Video Performance in the MEDIEVAL Project", Proc. 2011 Future Network & Mobile Summit, Warsaw, Poland, Jun 2011

This paper presents some considerations regarding necessary extensions to the IEEE802.21 signalling, in order to support multicast. The MIH Protocol signalling defined by the IEEE802.21 standard occurs in a point-to-point mode. Considering the broadcast and multicast nature of the video services and mobility procedures being tackled in the MEDIEVAL project, this paper provides a first step in the definition of point-to-multipoint MIH Protocol signalling, allowing the network to provide adaptations and optimizations to several mobile terminals at the same time.

Abstract

With the foreseen major increase in video traffic over the coming years, the current Internet’s design is being perceived as inefficient for handling the demanding flow of video over wireless access networks, populated by an ever increasing number of mobile terminals. The MEDIEVAL project aims to evolve the current Internet architecture to provide an optimized video support in all layers of the protocol stack. With its cross-layer approach, abstraction mechanisms such as IEEE802.21 will work as enablers between the different architecture modules. With the widespread diffusion of video being realized over multicast and broadcast channels for resource optimization, using 802.21 signalling to optimize handovers affecting groups of users will generate multiple messages to each individual terminal. In this article, we extend 802.21 to support multicast transport of its signalling, enabling more efficient group handover scenarios.

II.7 Context Transport Based on 802.21

Marcelo Silva Lebre, Daniel Corujo, Diogo Gomes, Rui L. Aguiar, "Context Transport Based on 802.21", Proc. 1 CNRS 2011 - Conference on Wireless Sensor Networks, Coimbra, Portugal, Mar 2011

This article considers the dissemination of media independent sensor information towards context servers. These servers, using higher layer transport protocols, can provide this sensor information to other entities on the network, allowing for different application scenarios. Also, the sensorial information can be processed in such a way that it can be used to optimize network management, which is of vital importance to the deployment of video services provision in environments featuring increasing numbers of mobile users.



Abstract

Sensor networks, along with the sensorial output from their nodes, provide an information source to enhance and enrich upper layers mechanisms. The 802.21 MIH protocol provides a cross layer framework that can be extended for sensor information transport. At the same time, it creates an abstraction layer that removes hardware and software specificity from sensor nodes. On a higher level of the network stack, the XMPP protocol also provides an upper layer solution for content syndication on a platform with global access availability. We present a framework which integrates a cross-layer abstraction approach towards sensor devices of different families, while enabling the integration of media-independent sensor information into context consumers with the aim of optimizing network management, as well as application operation and usability. The work presented was also part of the first author’s MsC dissertation.

II.8 A Control Theoretic Scheme for Efficient Video Transmission over IEEE 802.11e EDCA WLANs

P. Patras, A. Banchs, and P. Serrano, “A Control Theoretic Scheme for Efficient Video Transmission over IEEE 802.11e EDCA WLANs” ACM Transactions on Multimedia Computing, Communications and Applications, Jul. 2011.

This paper presents the fundamental analysis required to understand the optimal point of operation for the IEEE 802.11 technology when video traffic is used. In contrast with future work we are working on, this paper addresses the use of the EDCA mechanism, without introducing the upcoming extensions to support reliable multicast being standardized in IEEE 802.11aa. This work forms the basis of our future work and also serves as the mechanism of choice for configuring the legacy IEEE 802.11 technologies in the MEDIEVAL scenarios.

Abstract

The EDCA mechanism of the IEEE 802.11 standard has been designed to support, among others, video traffic. This mechanism relies on a number of parameters whose configuration is left open by the standard. Although there are some recommended values for these parameters, they are fixed independent of the WLAN conditions, which results in suboptimal performance. Following this observation, a number of approaches in the literature have been devised to set the EDCA parameters based on an estimation of the WLAN conditions. However, these previous approaches are based on heuristics and hence do not guarantee optimized performance. In this paper we propose a novel algorithm to adjust the EDCA parameters to carry video traffic which, in contrast to previous approaches, is sustained on mathematical foundations that guarantee optimal performance. In particular, our approach builds upon i) an analytical model of the WLAN performance under video traffic, used to derive the optimal point of operation of EDCA, and ii) a control theoretic designed mechanism which drives the WLAN to this point of operation. Via extensive simulations, we show that the proposed approach performs optimally and substantially outperforms the standard recommended configuration as well as previous adaptive proposals.

II.9 Sensor Context Information for Energy- Efficient Optimization of Wireless Procedures

Daniel Corujo, Marcelo Silva Lebre, Diogo Gomes, Rui L. Aguiar, "Sensor Context Information for Energy-Efficient Optimization of Wireless Procedures", Proc. 22nd IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Toronto, Canada, Sep 2011

Considering the different wireless access technologies available to mobile terminals today (as is the case in the MEDIEVAL project), novel mechanisms to help save battery are required. In this paper, we argue that, typically, when a mobile terminal is not moving, the list of available (and within range) points of attachment will not change. As such, continuous scanning will always provide the same result and, as a consequence, battery will be wasted unnecessary. In the article we explore the use of context information provided by



sensors available in today’s mobile terminals (e.g., accelerometer) to detect movement of the user. By integrating that sensor information with the 802.21 MIH protocol being used in the MEDIEVAL project, we are able to execute wireless interface commands to shutdown the wireless scanning process (or the wireless card completely). This work covers not only local sensor signalling, but also the convey of sensor information to a context server in the network, to use that information for optimizing network-controlled processes, such as mobility.

Abstract

The wide deployment of Wireless Local Area Networks (WLAN) we are witnessing today increases connectivity opportunities for mobile terminal devices, such as smartphones. However, continuous scanning for WLAN points of attachment can be a power exhausting mechanism for such battery-powered devices. These mobile devices, besides being equipped with different wireless access interfaces, are also coupled with sensors such as accelerometer, GPS , luminance and magnetic compass. In fact, sensors are increasingly being coupled into different devices and environments and are able to convey sensing information through networks into decision entities able to optimize different processes. In this paper we propose a framework where media independent sensing information is used to enhance wireless link management towards energy-efficiency. This framework enables the dissemination of sensing information towards local and remote decision entities, enhancing other processes (e.g. mobility) with sensing information in order to provide true Ambient Intelligence scenarios. We introduce this framework into a wireless management scenario able to provide energy-efficient optimal network connectivity.

II.10 A Framework for Flexible Sensor Information Dissemination

Daniel Corujo, Marcelo Silva Lebre, Diogo Gomes, Rui L. Aguiar, "A Framework for Flexible Sensor Information Dissemination", Proc. 2nd International Workshop on Interconnections of Wireless Sensor Networks, Barcelona, Spain, Jun 2011

This article is a compendium of the previous one, where the extensions done over the 802.21 MIH protocol for supporting sensors are defined. We argue that the different mobile user terminals can come coupled with different kinds of sensors, which have to be interfaced with different APIs. As such, re re-expand the abstraction concepts of the IEEE 802.21 standard being used in MEDIEVAL, to also enable an abstract access to sensors, independently of the manufacturer, type and characteristics of the sensor. Concretely, here we define a Service Access Point able to abstractly interface with the sensors (like the normal link service access points in IEEE 802.21), as well as a new set of messages enabling the access of information and control of the sensors. This paper highlights the flexibility and extension possibilities of the IEEE 802.21 standard, which not only confirms that its adoption by the MEDIEVAL project was justified, but also provides the considerations and possibilities of different areas addressed in Future Internet architectures.

Abstract

The integration of the digital world into every aspect of our lives is becoming more and more preeminent. Nowadays, not only humans but also devices and the environments where we dwell are also able to provide their own information, through the usage of sensors. Through their interconnection over communication networks, sensors enable Ambient Intelligent scenarios achieving a true Internet of Things, and crossing the gap between computer systems and the real world. However, the different sensing devices and information generated by them, are of such disparate nature that it becomes increasingly difficult to access and make use of such heterogeneous data. In this paper, we propose a framework which not only considers a media independent information access to sensors and their supplied data, but is also flexible enough to configure and provide different means to best transport collected sensor information via wireless gateways, facilitating its deployment in different scenarios. We demonstrate its usefulness by providing a throughput efficient approach towards the collection and dissemination of sensing data, through sensing information compression and aggregation of multiple sources.



II.11 Impact of opportunistic routing in the MEDIEVAL project

Davide Chiarotto, Osvaldo Simeone, and Michele Zorzi, "Throughput and Energy Efficiency of Opportunistic Routing with type-I HARQ in Linear Multihop Networks", in Proc. IEEE GLOBECOM, Dec. 2010, Miami, FL

In this paper a technique to optimize the wireless access strategy is analyzed. This work can be considered as a preliminary work in the MEDIEVAL project, in a tentative of studying innovative packet forwarding techniques in complex scenarios.

Abstract

Opportunistic routing is a well-known technique that exploits the broadcast nature of wireless transmissions and path diversity to form the route in an adaptive manner based on current channel conditions. This paper studies the throughput advantages of opportunistic routing over conventional multihop routing for linear multihop wireless networks with type-I Hybrid Automatic Repeat reQuest (HARQ) and quasi-static Rayleigh fading channels. The end-to-end throughput of opportunistic routing is derived using Markov chain tools and accounting for fading statistics. Both fixed-rate and optimal-rate transmissions are considered. Moreover, an investigation of the throughput using standard information-theoretic performance metrics for asymptotic signal-to-noise ratio regimes is provided. Specifically, the multiplexing gain and energy efficiency (i.e., minimum energy per bit) of both opportunistic and multihop routing are analyzed. Numerical results are given to corroborate the analysis.

II.12 Cooperation via Spectrum Leasing

In the following two papers a new framework for cooperation between users with different priorities is proposed. In a preliminary study of feasibility for the Medieval project, these papers present both analytical and simulative analysis, which permit to assess the performance that can be reached in a scenario where users, with different transmitting policies, cooperate to each other in order to increase network performance, such as network throughput and delay.

1) Davide Chiarotto, Osvaldo Simeone, and Michele Zorzi, "Spectrum Leasing via Cooperative Opportunistic Routing", in Proc. Asilomar Conf, Nov. 2010, Pacific Grove, CA

Abstract

A spectrum leasing mechanism is proposed for the coexistence between a primary and a secondary network that is based on cooperation and opportunistic routing. The primary network consists of a source and a destination communicating via a number of primary relay nodes. In each transmission slot, the next hop is selected in an on-line fashion based on the decoding outcomes in the previous transmissions according to the idea of opportunistic routing. The secondary nodes may serve as potential next hops for the primary network, but only in exchange for leasing of spectral resources so as to satisfy secondary quality-of-service constraints. Four policies based on spectrum leasing via opportunistic routing are proposed that provide different tradeoffs between gains in throughput and overall energy expenditure for the primary network. Analysis is carried out for networks with a linear geometry and quasi-static Rayleigh fading statistics by using Markov chain tools.

2) Davide Chiarotto, Osvaldo Simeone, and Michele Zorzi, "Spectrum Leasing via Cooperative Opportunistic Routing Techniques", IEEE Trans. on Wireless Commun., Jun. 2011



Abstract

A licensed multihop network that coexists with a set of unlicensed nodes is considered. Coexistence is regulated via a spectrum leasing mechanism that is based on cooperation and opportunistic routing. Specifically, the primary network consists of a source and a destination communicating via a number of primary relay nodes. In each transmission block, the next hop is selected in an on-line fashion based on the channel conditions (and thus the decoding outcome) in the previous transmissions, according to the idea of opportunistic routing. The secondary nodes may serve as extra relays, and hence potential next hops, for the primary network, but only in exchange for spectrum leasing. Namely, in return for their forwarding of primary packets, secondary nodes are awarded spectral resources for transmission of their own traffic. Secondary nodes enforce Quality-of-Service requirements in terms of rate and reliability when deciding whether or not to cooperate. Four policies that exploit spectrum leasing via opportunistic routing in different ways are proposed. These policies are designed to span different operating points in the trade-off between gains in throughput and overall energy expenditure for the primary network. Analysis is carried out for networks with a linear geometry and quasi static Rayleigh fading statistics by using Markov chain tools. Different multiplexing techniques are considered for multiplexing of the primary and secondary traffic at the secondary nodes, namely orthogonal multiplexing (such as time, frequency or orthogonal code division multiplexing) and superposition coding. The optimality in terms of both throughput and primary energy consumption of superposition coding over all possible multiplexing strategies, for the given routing techniques, is proved. Finally, numerical results demonstrate the advantages of the proposed spectrum leasing solution based on opportunistic routing and illustrate the trade-offs between primary throughput and energy consumption.

medieval d3.1 v1.1 - european commission :...

Documents