Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment

PROJECT FINAL REVIEW SELF-ASSESSMENT

Acronym: MARCH

Project title: Multilink architecture for multiplay services

Contributor: Terje Tjelta

Planned start date: 1 April 2008 Real start date: 1 June 2008

Planned finish date: 31 March 2011 Expected finish date: 30 September 2011 Involved partners  Telenor ASA [Telenor], Norway  Budapest University of Technology and Economics [BME], Hungary  Bitnet CCSS [Bitnet], Romania  Telvent [Telvent], Spain  Telecom Castilla - La Mancha S.A. [TCLM], Spain  Technical University of Cluj - Napoca [TUCN], Romania  Gravity R&D Kft. [Gravity], Hungary  Simula Innovation [Simula], Norway  Lividi [Lividi], Norway  WiNetworks Ltd [WiNetworks], Israel (Note RuggedCom acquired WiNetworks)  LiveU [LiveU], Israel  Indra Sistemas S.A [INDRA], Spain Executive assessment of project achievements MARCH was an explorative project that worked along two main axes, a market and business understanding of broadband access and content delivery over the Internet, and multilink techniques and architectures for broadband over heterogeneous networks. The link between the axes was through scenarios, market and business case evaluations, where technologies for scenarios were developed and demonstrated. A separate activity on requirements was done during the first year that outlined some of the basic constraints. There are many good results from the business aspect area (WP2 and WP3) covering market development, content delivery, consumer spending, forecasts and detailed scenarios evaluation with qualitative and quantitative technical economical calculations. The scenario calculations got inputs from the other work packages and delivered, as well, motivation to complete the multilink technology, architecture and demonstrations. The achievements on requirements were useful, but as the project evolved the actual technical settings had to be revisited. So were the scenarios as well, where a more focused line was followed for the multilink techniques and architecture work (in WP4 and WP5). To what degree the scenarios studied are realistic and of interest for future business is complicated to predict. For some it is already business, e.g., with proprietary terminals. Other will require new software, both in standard existing terminals and in the network. MARCH technology will still need time before it is included in standards, such as new 3GPP releases for broadband mobile communication. MARCH approached multilink technology and architecture on a fairly wide front early in the project, and hence issued more of a framework, although with many detailed elements identified and described. It was necessary to narrow the scope in the second part of the project after the mid term review. Also changes at the partnership left less resources for scopes such as combination of broadcast and mobile, i.e., and interactive broadcast multilink solution. The

1 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment research was limited to mobile plus fixed hot spots, primarily the wide-spread Wi-Fi networks. There are good quality technical results achieved from the work in WP4 and WP5, in particular for combination in multilink of a cellular network with a fixed hot-spot network. Additionally, also other elements analysed provide very interesting results. On the critical side it seems that MARCH should have focussed even more in this direction earlier. The demonstrations and trials really show that the partners have achieved both workable solutions and results that may help for future business. The focus has been more on making products than writing papers, at least as long as industry partners goes. Partners of MARCH already make business from multilink technology, and there is reason to believe that the business will grow and even new companies may emerge. Note that one company actually started at the same time as MARCH, significantly motivated by the new project starting. Demonstration activities have been focused on scenarios combining various terrestrial networks, and on the TV reporter service deploying several access networks. MARCH also worked out other interesting business scenarios such as for an emergency fleet, but did not manage to demonstrate it. MARCH established early a user friendly and informative website that has been maintained since. It has provided the results as they have appeared including other publications and presentations. The management of MARCH under the Celtic project regime allowed establishing a competent international team for tasks that really required cross-national collaboration, and yet obtain national funding for own organisations. At national level this created for MARCH partners an opportunity to work on fields of interest for both research and business, and at the same time collaborate European wide to even achieve more comprehensive results. The downside is that each national team formed a sub-project that, to some degree, also appears stand-alone. They were also evaluated this way – nation by nation, every year. MARH management dealt with the tasks, with the right web tools and agreements in place from the start. A lot of good collaboration took place over the phones, emails, net-meetings, and some face-to-face meetings. The project used extensively the web-based archive for up-to-date documents showing the progress for each deliverable and milestone document through an automatic document version number system. MARCH managed however, not to share the workload well enough on work package and task levels, such as work package leader responsibilities. The work was therefore towards the end of the project, organised around deliverable editors, which under these circumstances worked out satisfactory. Conformity of work compared to plans MARCH followed the PD along the main topics, and kept the main objectives. However, as reflected in the various PDs, in total seven versions, from the first version there are some shifts of emphasis for some areas, such as:  Increased work on market and economics.  Decreased work on modular aspects for multilink network architectures. Some deliverables were merged into one in the second half of the project, i.e., D4.2 (general multilink techniques) and D5.1 (multilink preliminary architecture), and D7.6 included planned information for D7.4 (standardisation activities) and D7.7 (published papers). Deliverable D1.2 on IPR-issues was dropped, i.e., no issues to report. Perceived quality of produced results The project results have been well received by colleagues from Telco and research community. People outside the project have attended public workshop and particular interest has been shown towards multilink technology and demonstrations. Also, scientific articles have been published in peer reviewed journals and at conferences. AS an example, one of the MARCH demonstrations showing live excavation of Jurassic marine reptiles at Svalbard received a lot of attention. Under this event, MARCH demonstrated robust multilink networking for a remote area with challenging conditions for continues streaming of high quality live video over a period of more than 2 weeks. Perceived quality and efficiency of current consortium The consortium consisted of telecom operators, network equipment vendors, academia and consultancy or small enterprises: the partners had complementary skills. The expertise included

2 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment telecommunication and broadcasting networks, information technology, network hardware and software, service delivery, and business modelling. MARCH has kept its main goals, but adjusted delivery time for some of the results. The late start for some partners delayed discussions on scenarios and business modelling, and continued late national decision on funding delayed important inputs for other project areas. The budget of MARCH is significant for a European collaborative research project. The approach has been fairly wide, i.e., research on broadband Internet business and market development combined with technical, analytical, and practical technology development with demonstrations of new product and features. Judged by the estimated return of investments, the partners conclude that the project results are worth the investments. The results on better understanding of the new business challenges and the potential new technology and architecture of multilink technology addressed, makes the investment defendable. Mid Term Review Below, each MTR corrective action is shown in italics followed by MARCH’s detailed response which was followed as much as possible. It is also indicated at the time for Final Review, text preceded by FR, to what extent or in which deliverable MARCH met the corrective actions. Corrective actions It seems that there is a lack of coordination among the work packages. Even at the slideshow level, it seems that no end-to-end integration and shaping were done. The reports should better explain what the tangible contributions of each partner are, how the partners collaborated and what the impact of this collaboration was. MARCH Response We partially agree to this general comments, we can understand that at the level of the slideshow at the MTR a better work could have been done, and that presentations where done without end- to-end shaping. However, we believe that the way the project is currently constructed supports project goals, and that coordination within and between WPs and partners is done in a reasonable manner. We have regular conference calls and meetings, we always save time for cross WPs discussions in face to face meetings. Here is a brief description of how the project perceives our cross-WP collaboration:  WP1 is responsible for management aspects, PCC issues, meeting arrangements, tracking progress and handling required modifications to solve problems when occurring. This WP has interfaces with all other WPs.  WP2 is responsible in providing multilink requirements based on identified business scenarios. Some scenarios reflecting real current business opportunities while other are more futuristic. WP2 provides inputs to all WPs, in particular to WP3, WP4, and WP5.  WP3 analyses and refine the identified scenarios from a business model point of view. It receives inputs from WP2 for their requirements and from WP4 for their possible cost and gain implications.  WP4 is responsible for developments of techniques for multilink. Developed techniques are in some cases strictly related to scenario and sometime common to several scenarios. WP4 receives inputs from WP2 and provide inputs to WP3, WP5, WP6, and WP7. A reference architectural framework for multilink techniques has been developed by WP4.  WP5 is responsible in providing a comprehensive architecture, based on the WP4 reference architectural framework to cover main and selected scenarios and cases. It receives inputs from WP4, and WP3 and provides its output to WP7 and WP6.  WP6 is responsible in demonstrating selected developed techniques; it receives its main inputs from WP4 and WP3, while also respecting multilink architecture work as proposed by WP5.  WP7 is responsible for dissemination and exploitation of project results based on work conducted in the other WPs.

Corrective actions High level application scenarios should be proposed. An architecture supporting the requirement of these scenarios should be described. The mapping (functional and physical) of the proposed mechanisms over the general architecture should be proposed and optimized and related technical challenges identified. The work plan for the second phase should explain how these challenges will be tackled.

3 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment

MARCH response Work done within the project up to this stage (aligned with existing approved PD) follows approved deliverables and milestones time lines which implies that scenarios and requirements would be identified as part of WP2 activities as was done and presented. These scenarios were also discussed during the MTR and we considered them as “proposed”. The recommended architecture to cover suggested scenarios was considered part of WP5 activities and the approved time for this deliverable is suggested at the end of the MARCH project rather than at the middle. WP4 analysed technically all the scenarios and suggested an architectural framework to study multilink techniques in the context of this architecture. Deliverable D4.1 describes initial architecture entities, interfaces, and functional decomposition that covers all the proposed scenarios and serves as input in WP5 work. In the second part of the project, we will complete techniques study; these techniques are already identified and described in Milestone M4.2. In parallel while accepting reviewers’ suggestion, WP5 will provide a recommendation for architecture at an earlier stage of the project which will map the functional and physical recommendation of the project and will leave more time for implementation and demonstration at WP6. These changes will be reflected in a new version of the PD (Version 6). FR: MARCH followed the revised plans and made an attempt to show how scenarios, multilink techniques, multilink architectures, and demonstrations are connected.

Corrective action There is a need to better understand possible business models among the various actors and market constraint that may delay or even impede the deployment of the proposed solutions. The business models for the proposed services and network brokers should be analyzed. Those brokers will compete with existing network and service providers, how the neutrality issue will be tackled? How the issue of dynamic price changes will be taken into account? What can be done to ensure that this issue won't limit the usage of the proposed service models? Concepts like auction based and congestion based pricing never took-off in particular because of the difficulties for a customer to deal with "dynamic pricing" and the related difficulties to forecast the communication budget. MARCH response We agree that a better understanding of possible business models and the various actors is essential for accepting parts of project results in the industry. That is in line with current work plan and defined deliverables and milestones. In Deliverable D3.1 which was not released prior to the MTR, we analyse the business models and will perform detailed economical estimates of identified scenarios in Deliverable D3.3. The project will not be in a position to in depth deal with neutrality and regulatory issues as this question is very big and requires much more resources that available for MARCH and to some degree different type of partners. MARCH is not considering dynamic pricing, but longer term averages. For cases where multilink cross-provider and end-to-end service quality and assurance are critical we will consider collaboration with the EU FP7 ETICS project (Economics and Technologies for Inter-Carrier Services). FR: Deliverable D3.3 has quantitative estimations, although uncertain, of realistic business opportunities.

Corrective action Application transparency (not having to modify terminals or applications) is an important factor of success. How this can be achieved and what are the project recommendations? How intelligence distribution among terminals, networks and service platforms will be distributed? A better analysis/optimization of which components participate in taking the link selection, link aggregation or load balance decisions is required. MARCH response We agree the reviewers’ view, in Deliverable D4.1 we are suggesting several options for multilink gateway (MLG) and its positioning at various layers and network entities (new and existing). When MLG resides within the network or within lower layers below the application layers at both

4 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment user equipment and content server the development of application is transparent. Moreover, when MLG is located over the networking layers it may be supported via software upgrade. However, we don’t limit our contributions to cases where hardware may need to be replaced for supporting either proprietary or longer term developments. In WP5 we shall take reviewers inputs and shape the recommended architecture in a way that allows transparency. We also identified in D4.1 cases where the network selects the proper access points to be used transparent to the user equipment modifications. These cases are for further study under second (final) deliverable and where both centralised and distribution RRM algorithms/link selection algorithms are identified. In Milestone M4.2 there is a list of algorithms and techniques that are being under study and results shall be available when next stage of the project is completed. FR: Deliverable D5.2 on multilink architecture has addressed these issues.

Corrective action Some of the proposed mechanisms are being standardized natively by the 3GPP. The project should position itself clearly with respect to these evolutions. MARCH response In Deliverable D4.1 relevant international standards regarding multilink (3GPP 23.861, IEEE 1900.4, and IEEE 802.21) were identified, as a first step towards MARCH contributions enhancing them. The ambition is to provide information to these standards bodies as well as TM Forum IPsphere. MARCH has already identified what the 3GPP is not dealing with, i.e., split and merge of IP streams for the same service, and will look for opportunities to contribute this and similar information to the relevant internationals standards bodies. One step is to produce a document identifying the contributions a part of the dissemination activity (WP7), another likely possibility is at 3GPP meetings to provide an information document. FR: MARCH focused most on what would be possible following the 3GPP initiatives. This will also be of interest for other standardisation organisations, as indicated in the response, but MARCH has not been able to follow this in such level of details as initially indicated.

Corrective action The concepts presented in WP5 slides are generic and apply to any context. The project should propose a detailed architecture with the corresponding functional groups, interfaces, protocols and information models as well as recommended physical architectures. The way to map the various proposed mechanisms over this architecture should be explained. MARCH response The goal of WP5 is similar in concept to suggested corrective actions. Therefore we intend to describe architecture in details following two steps: an early preliminary architecture after summer 2010 and a final refined architecture at the end of the project. The architectures will be done for selected application scenarios using the results on multilink techniques derived in WP4, also taking into account identified requirements and capabilities addressed by WP2 and WP3. The detailed architecture will form a basis for demonstration activities in WP6. In the project plan until now it was not planned to demonstrate the full outcome architecture from WP5, or expressed differently, the final output architecture of WP5 should not be limited by what was possible to demonstrate in WP6. FR: Deliverables D4.2/D5.1 and D5.2 are less generic and more focussed. Particularly, D5.2 focussed on a narrower scope. However, components and interfaces have not been specified in same detail as in 3GPP.

Corrective action The feasibility of deploying the proposed mechanisms should be analyzed. For example, what are the requirements to deploy the proposed CRRM? How the proposed mechanisms will interact with existing deployed networks to acquire the required information for decision making? Are hierarchical architectures considered? MARCH response Developed techniques in the project may be used in real networks, however for mass scale

5 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment deployment we believe that standard activities of the future will benefit from the research work and developed techniques. In the time being for the short term we intend to benefit from developed techniques in industrial partners solutions which are mostly proprietary. The insight of the architecture framework and further detailed architecture in WP5 do consider hierarchical structure where data and management has the architecture of a tree, in that case where two elements from different networks want to share information they go through a parent proxy, this will also ease existing networks and protocols between different vendors to collaborate. We used the term proxy approach for that in Milestone M4.1, and in Deliverable D4.1 we used the term MLG as the parent entity which handles management, control and data planes. However the study of certain techniques may go beyond that hierarchical approach, to support longer term contributions. FR: Deliverable D4.2/D5.1 present the results achieved.

Corrective action In the described scenarios there is a unique source for each flow. How the mechanisms will work in a more distributed environment like P2P TV distribution?

MARCH response The choice for Deliverable D4.1 (as expressed in the deliverable) was to focus on cases involving splitting/merging of a single user data flow into sub-flows in order to exploit multiple links. However, the proposed architectural framework is not limited to such cases, and WP5 will address in more detail cases (some of which where discussed in D4.1) where the multilink user equipment or terminal handles several concurrent separate service data flows, also considering required management and control in more detail. None of the industrial partners are dealing with P2P TV distributions, therefore P2P TV distribution was not foreseen dealt with in MARCH. However we do intend to look into this technology in high level investigations as background or side developments that we should recognise. FR: Deliverables D4.2/D5.1 and D5.2 present how flows are dealt with.

Corrective action In WP6 it is not clear which of the mechanisms studied in the other WPs are demonstrated. The project should ensure that at least some of the proposed mechanisms are demonstrated. MARCH response With accordance to approved PD and work plan, WP6 deliverables and milestones addressing demonstrations aspects are scheduled after the MTR, but more precise statements in the updated PD (Version 6) makes it clear that MARCH from the start planned to demonstrate specific mechanism in test scenarios. FR: Deliverable D6.1 presents the details of every demonstration held.

Produced deliverables and other project results Deliverables with last version date indicated D1.1 Project presentation. 12 June 2008 D1.3 Final report. V1.0, 7 September 2011 D2.1 Scenarios enabled by multilink systems - Preliminary version. V1.1, 8 December 2008 D2.2 Scenarios enabled by multilink systems (final version). V1.0, 27 May 2009 D2.2 Scenarios enabled by multilink systems (version 2). V2.1, 16 December 2009 D2.3 Requirements from operators and users of multilink networks. V1.1, 8 December 2009 D3.1 N-Play business models. V1.0, 8 May 2010 D3.2 Substitution and complementarities in the content and media services. V1.0, 10 February

6 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment

2010 D3.3 Economic scenarios analyses. V1.0, 15 February 2010 D3.4 Market development up to 2015. V1.0, 2 December 2010 D3.5 Consumer spending and forecast for content and communication services. V1.0, 30 May 2011 D4.1 Architectural framework for multilink techniques. V1.1, 26 November 2009 D4.2/D5.1 General techniques and preliminary multilink end to end technical architecture. V1.0, 30 December 2010 D5.2 Multilink network architecture. V1.0, 7 September 2011 D6.1 Demonstration of multilink features. V1.9, 7 September 2011 D7.1 Dissemination and exploitation plan, V1.1, 25 August 2009 D7.2 Project web site. January 2009 D7.3 First international workshop. March 2010 D7.5 Second international workshop. 21 September 2011 D7.6 MARCH Exploitation, dissemination and standardisation activities. V1.0, 23 June 2011. (Project internal) Demonstrations Software, products Workshops Missed milestones The project description (PD) has been updated to reflect the current situation. However, compared with expectations given in the full project proposal, results on user and network operator requirements, business models, and multilink network architecture were delayed. Also a second version of multilink network scenarios has been issued to include late-comer inputs. Standardisation and dissemination activities Input to standardisation (3GPP, IETF) Contributions to peer reviewed international and national journals and conferences A number of demonstrations/trials. Three of these demonstrated various multilink solutions at public workshops. Involvement of higher education (PhD, MSc, BSc) Encountered problems in the project The long start-up time for MARCH was a negative experience. Various partners from different countries all with their own funding schemes and timetables created difficulties. In the full project proposal, MARCH started with some partner from France and Austria that eventually could not join due to lack of funding; as a replacement other partners were approached and joined later. Partners from Israel joined after the project start, but aligned quickly and smoothly. The partners from Spain needed more than a year to receive satisfactory funding, and the Spanish part of the consortium was also modified in this process. As a consequence, little input was provided from Spain the first year. In fact, this situation continued throughout the whole project with late decisions and apparently also small amount of funding, with resulting delays of deliverables depending on Spanish inputs. The partners from Romania received positive signals about funding, but could not get satisfactory contract conditions. This made it more difficult for them to participate. However, Romanian delivered very well at own cost throughout the whole project. Funding is an issue between the partner of one country and their national funding source. From the management point of view this makes it almost impossible to have a good view of real resources used. It is also a complicating factor that the funding for some partner is, upon certain conditions, for the full project period, while for other partners is from year to year. All have their

7 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment own timetables. Telenor, the project coordinator, reorganised the research and innovation department in February 2010. It had a significant impact on MARCH with resulting reduced research resources. However, at later the same year collaboration with Sintef started, enabling Telenor to largely deliver what was intended, in fact, more on multilink resource management and throughput calculations, but less on modular aspect of network architectures. The MARCH consortium consisted already from start of many small and medium sized enterprises (SMEs). Some of these were later acquired by other companies (Israel and Hungry), and some replaced by new partners (Spain). MARCH lost a large company at the start (France). The impact on the project work were both positive and negative, where the problematic part affected field of expertise and management workload sharing such as being work package leader jobs.

Expected impact of the results See list below:

Type of impact Number Remark Number of new products that have been 4 developed based on the project results Number of products that have been 7 improved using the results of the project It is difficult to give good estimates, however, MARCH partners have made an attempt. Averaged number over all partners weighted by their respective Expected return of investment (RoI) budget. Industry partners either 10 or 1, within the next 3 years (related to the depending on focus of current and expected 5,6 cost of the project: 0, 1x, 10x, 100x, future business. Academia has indicated 0. 1000x etc.) The return comes from better understanding of the broadband market, increased network utilisation with multilink networks, new products for multilink and also radio resource management. Number of new companies that were 1 Lividi started at the beginning of MARCH. created commercialising project results Number of new permanent employees hired by the partner organisations or 14 spin-off companies due to activities generated by the project results Cross domain cooperation (e.g., telecom-power, telecom – civil 5 engineering) Patents 0 Prototypes/field trials 50 LiveU has had 40 field trials. Number of contributions to standards 4 based on results of the project Standard implementations/Workability 0 trials of new standards Number of journal publications 8 Number of conference papers 18 Number of PhD thesis contributing to 8 and using project results

8 Celtic project CP5-013 MARCH - Multilink architecture for multiplay services Final review: Self-assessment

Number of Master thesis contributing to 14 and using project results Opens source software users Software 0 developed in the project Future prove networks 4 Techno-economics 2 Home network/gateway concepts 2 Web-telecom convergence 1 BME: 8 contributions for Student Conference of the Hungarian Scientific Association for Infocommunications Other 29 BME: 15 Bachelor theses contributing to and using project results BME: 5 developed software technologies/software simulators

9