domain: info sde

text:
Sylvain Kubler
email: sylvain.kubler@uni.lu

Jérémy Robert
email: jeremy.robert@uni.lu

Ahmed Hefnawy
email: ahmed.hefnawy@univ-lyon2.fr

Kary Främling
email: kary.framling@aalto.fi

Chantal Cherifi
email: chantal.bonnercherifi@univ-lyon2.fr

Abdelaziz Bouras
email: abdelaziz.bouras@qu.edu.qa

Open IoT Ecosystem for Sporting Event Management

Keywords: Internet of Things, Smart city, Interoperability, Ecosystem, Open innovation, API economy

By connecting devices, people, vehicles and infrastructures everywhere in a city, governments and their partners can improve community wellbeing and other economic and financial aspects (e.g., cost and energy savings). Nonetheless, smart cities are complex ecosystems that comprise many different stakeholders (network operators, managed service providers, logistic centers. . . ) who must work together to provide the best services and unlock the commercial potential of the so-called IoT. This is one of the major challenges that faces today's smart city movement, and the emerging "API economy". Indeed, while new smart connected objects hit the market every day, they mostly feed "vertical silos" (e.g., vertical apps, siloed apps. . . ) that are closed to the rest of the IoT, thus hampering developers to produce new added value across multiple platforms and/or application domains. Within this context, the contribution of this paper is twofold: (i) present the strategic vision and ambition of the EU to overcome this critical vertical silos' issue; (ii) introduce the first building blocks underlying an open IoT ecosystem developed as part of an EU (Horizon 2020) projet and a joint project initiative (IoT-EPI). The practicability of this ecosystem, along with a performance analysis, are carried out considering a proof-of-concept for enhanced sporting event management in the context of the forthcoming FIFA World Cup 2022 in Qatar.

I. INTRODUCTION

New Internet of Things (IoT) applications that leverage ubiquitous connectivity, system interoperability and analytics, are enabling Smart City initiatives all over the world [START_REF] Sun | Internet of Things and Big Data analytics for smart and connected communities[END_REF], [START_REF] Neirotti | Current trends in smart city initiatives: Some stylised facts[END_REF]. These new applications introduce tremendous new capabilities such as the ability to connect, manage, and optimize complex sets of disparate information systems, sensors, devices, people and software solutions into a "System-of-Systems" (SoS) like fashion [START_REF] Alam | C2ps: A digital twin architecture reference model for the cloud-based cyber-physical systems[END_REF], [START_REF] Naphade | Smarter cities and their innovation challenges[END_REF].

Although the smart city paradigm paves the way for societal and economic opportunities, for example to reduce costs for societies, increase the service for the citizens in a number of areas, foster a sustainable economic growth, they also pose architectural and structural issues that must be addressed for businesses to benefit [START_REF] Pahlavan | Localization challenges for the emergence of the smart world[END_REF], [START_REF] Schaffers | Smart cities as innovation ecosystems sustained by the future internet[END_REF]. One of the most critical obstacles is the vertical silos' model that shapes today's IoT, which hampers developersdue to the lack of interoperability and openness -to produce new added value across multiple platforms (data is "siloed" in a unique system, cloud, domain, and stays there) [START_REF] Zhao | An event-driven service provisioning mechanism for IoT (Internet of Things) system interaction[END_REF], [START_REF] Kubler | Digitising the Industry Internet of Things Connecting the Physical, Digital and Virtual Worlds[END_REF]. This is all the more true in a smart city environment, as it is a complex ecosystem that comprises a wide range of interacting and cooperating actors such as users, software and network providers, financial institutions, logistic centers, and so on [START_REF] Paskaleva | The smart city: A nexus for open innovation?[END_REF], [START_REF] Abu-Matar | Towards a software defined reference architecture for smart city ecosystems[END_REF], which is why cities are usually built on vertically-oriented closed systems that are difficult to interconnect.

Several organisms and standardization fora understood this critical challenge and started to build up consortia and IoT initiatives to address it. Let us cite, for example, the Web of Things initiative at W3C that aims to create open ecosystems based upon open standards, including identification, discovery and interoperation of services across platforms [START_REF] Raggett | The Web of Things: Challenges and opportunities[END_REF]; the Alliance for Internet of Things Innovation (AIOTI) launched by the EU with the aim of strengthening links and building new relationships between the different IoT players (industries, SMEs, startups) [START_REF] Aioti | Alliance for Internet of Things innovation (aioti)[END_REF]; the Open Platform 3.0 TM at The Open Group that focuses more on organization applications and practices [START_REF]the nexus of forces in action -business use-cases of open platform 3.0 TM[END_REF]; the OneM2M global standards initiative that involves eight standard bodies for Machine to Machine (M2M) communications [START_REF] Swetina | Toward a standardized common M2M service layer platform: Introduction to OneM2M[END_REF]; the IEEE Internet of Things (IoT) initiative [START_REF] Minerva | Towards a definition of the internet of things[END_REF] or still the International Technical Working Group on IoT-Enabled Smart City Framework developed at NIST [START_REF] Rhee | Catalyzing the internet of things and smart cities: Global city teams challenge[END_REF]. Although most of those initiatives promote various types of standards and specific technology enablers, they all share the same vision about relying as much as possible on open and interoperable standards to foster emergence of open ecosystems, and unlock the commercial potential of the IoT.

Within this context, the research work presented in this paper aims to present one framework that enables IoT service [START_REF]Smart farming and food safety internet of things applications -challenges for large scale implementations[END_REF] WG7 -Wearables Focus on IoT solutions that integrate key technologies (e.g. nano/organic electronics, embedded software. . . ) into intelligent systems to bring new functionalities into clothes and other body-mounted devices.

[25]

WG8 -Smart Cities Refer to IoT solutions that allow for increased multi-modal mobility, more efficient traffic management, a dynamic road infrastructure, automated road tolling, usage based insurance, and improved policy making. [START_REF]Alliance for Internet of Things Innovation[END_REF] WG9 -Smart Mobility Focus on IoT solutions that improve water management efficiency by monitoring and controlling surface water retention, flooding, and so forth.

[27]

WG10 -Smart Water Management Focus on IoT solutions that bring together information, technology and human ingenuity to achieve a rapid revolution in the development and application of manufacturing intelligence.

-WG11 -Smart Manufacturing Focus on IoT solutions that bring together information, technology and human ingenuity to achieve a rapid revolution in the development and application of manufacturing intelligence to every aspect of business.

[28]

WG12 -Smart Buildings and Architecture

Focus on IoT solutions deployed by various companies along the value chain (i.e., energy companies, supply, traders, etc.) to allow the performance optimisation of their energy asset portfolios.

-

WG13 -Smart Buildings and Architecture

Focus on IoT technologies and solutions deployed in buildings and districts of buildings to improve life of the occupant by addressing and optimising elements such as comfort, light, air quality, water, nourishment, fitness, and energy usage.

stakeholders (either service publishers or consumers) to join, contribute and benefit from an open IoT ecosystem developed in the context of an ongoing EU H2020 project named bIoTope 1 . This project contributes both to the AIOTI initiative and a joint project initiative named IoT-EPI 2 (European Initiative for IoT platform development) that aims to build a vibrant and sustainable IoT-ecosystem in Europe. Our research work is also part of the Open Platform 3.0 initiative since the messaging protocols used in bIoTope are the ones published by The Open Group, as will be discussed in this paper. Section II provides a more detailed view on such initiatives, especially with regard to EU's vision and ambition. Following this, section III provides a first overview of the building blocks underlying the bIoTope's ecosystem. Section IV develops and evaluates the practicality of these technical building blocks with regard to a sporting event management scenario defined in the framework of the forthcoming FIFA World Cup 2022; conclusion and discussion follow.

It is important to note that this article is an extension of the conference paper published in the proceedings of the 13th Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services [START_REF] Kubler | IoT-based smart parking system for sporting event management[END_REF], whose extended content includes: (i) a more in-depth presentation of the EU initiatives, along with a discussion of how the API Economy could play a key role in solving the problem of "vertical silos" in the IoT, (iii) an introduction of the IoT service marketplace designed in bIoTope, which acts as a Web of Things-like environment (including multimodal search 1 http://www.biotope-project.eu, last accessed Apr., 2017. 2 http://iot-epi.eu, last accessed Apr., 2017. and discovery IoT data/services), (iv) a presentation of how bIoTope fosters easy service composition using IoT visual programming tool.

II. EUROPEAN IOT VISION & AMBITION A. Towards open IoT ecosystems

While in the US, IoT ecosystems are created around big, multinational players such as Google, Amazon, Facebook and Applethe so-called GAFA [START_REF] Miguel | Gafanomy (google, amazon, facebook and apple): The big four and the b-ecosystem[END_REF] -the EU's strength is rather in smaller and agile companies. Several past EU initiatives gave rise to a multitude of IoT platforms in various domains [START_REF] Vermesan | Internet of Things -From Research and Innovation to Market Deployment[END_REF], let us cite the IERC cluster in which IoT-A, OpenIoT, BUTLER, etc., were developed, or still the Future Internet-PPP programme that contributed to the development of the FI-WARE cloud-based infrastructure that offers a number of general-and specific-purpose functions in multiple sectors (farming, manufacturing, mobility, pervasive game. . . ). All these projects/platforms were funded and developed in the FP7 framework (2007)(2008)(2009)(2010)(2011)(2012)(2013)(2014)(2015) that constituted the ignition phase of the IoT program approach. The second phasestarted in 2016 -aims to foster the emergence of open IoT (or business) ecosystems enabling and incentivizing communities of citizens, SMEs, and other public-private institutions, to join and contribute to the growth and sustainability of these ecosystems. To achieve this mission, the EU recently launched the AIOTI alliance with the aim of making recommendations for future collaborative work in the context of the IoT Focus Area in the H2020 EU program. TABLE I provides a short overview of the 13 Work Group (WG) composing the AIOTI alliance, their respective focus area, and recent report(s)/white paper(s) that have been published by each WG. One particularity of this cluster, compared with previous EU initiatives, is that these seven R&I projects are part of the joint IoT-EPI project initiative, aiming to maximize opportunities for platform development, interoperability and information sharing across projects and use case pilots. This initiative and underlying projects are discussed in the next section.

B. IoT-EPI: a joint project initiative to foster a vibrant and sustainable IoT-ecosystem in Europe

The seven R&I projects carried out in the ICT30 cluster aims to improve horizontal interoperability and provide viable proofs-of-concept about how existing platforms for connected smart objects can easily, safely, and reliably be integrated for a multiplicity of novel IoT applications. • Interoperable APIs: this topic refers to standardized and open APIs that must cope with the IoT peculiarities and requirements, e.g. to support efficient data publication, consumption and composition of heterogeneous information sources from across various platforms. Those APIs must provide the necessary messaging interfaces, along with generic content description models for IoT data representation. Each project will investigate, adopt (or develop) such open API solutions, although one challenging task amongst the projects will be the convergence towards the use of a common set of standards;

• Autonomous reasoning: this topic refers to context-aware and self-adaptation capabilities of the system/ecosystem [START_REF] Perera | Context aware computing for the Internet of Things: A survey[END_REF].

Two coordination support actions (CSA) are supporting the R&I projects, namely UNIFY-IoT focusing on scientific aspects, and Be-IoT focusing on long-term impact-, communityand ecosystem-building success. These two CSA projects are actually leading the IoT-EPI initiative to foster cooperation and convergence between the seven R&I projects. To better understand the ambition of IoT-EPI, Fig. 1 provides an at-aglance overview of the desired impact from the API economy perspective. As illustrated in this figure, while companies release digital products and services through proprietary APIs, new opportunities arise with the emergence of open ecosystems built upon standardized open APIs, allowing companies to reimagine their business processes and customer experience. Such types of ecosystems are intended to support joint

III. OVERVIEW OF BIOTOPE ECOSYSTEM BUILDING

BLOCKS

The following ecosystem building blocks are introduced and discussed in sections III-A to III-C, respectively dealing with: (i) the IoT service marketplace enabling the publication and discovery of IoT data and/or services in the ecosystem, (ii) O-MI providing a generic Open API for implementing RESTful IoT information systems, and (iii) O-DF providing a generic content description model for Things in the IoT.

A. IoT service marketplace

bIoTope is evolutionary insofar as it lays a solid foundation to allow existing communities of developers (businesses, system integrators, etc.) and end-users (citizens, institution and other legal entities) to join an open, easy-to-use and secure IoT ecosystem that fosters new relationships. In keeping with this visionary action, the core concepts and building blocks underlying the bIoTope ecosystem are summarized in Fig. 2 (a few real-life solution providers are referenced in an effort to ease the understanding). First, parts denoted by ➀ in Fig. 2 stress the fact that the project leverages the available platforms and cloud endpoints such as weather station solution providers (as denoted by "0"), car manufacturers, etc., using them to create smart cities, industries, and homes. The second step, denoted by ➁, emphasizes the fact that bIoTope provides the necessary tools to enable any legal entity (citizens, businesses, municipalities, etc.) to exposeusing O-MI/O-DF standards as basic interoperability layer -personal IoT data or 5 IoT services, while providing them with the possibility of (i) choosing what personal data items can be shared with peer systems/developers; (ii) deciding for which purpose personal data can be used, for how long, and at what cost; (iii) being informed whenever data is used/called, and by whom.

Although more details about O-MI and O-DF will be provided in sections III-B and III-C, it should be stressed that O-MI provides a generic Open API for implementing RESTful IoT information systems, while O-DF provides a generic content description model for Things in the IoT that can, and should be extended with more specific semantic web vocabularies. Stage denoted by ➀ in Fig. 2 illustrates this extension principle, where either/both domain-independent vocabularies (such as iot.schema.org, SSN, etc.) or/and domain-dependent vocabularies (such as DATEX II or MobiVoc for the mobility sector, HL7 for healthcare, etc.) can be used as extension of O-DF. Such vocabularies can be found through LOV-like repositories6 [START_REF] Vandenbussche | Linked Open Vocabularies (LOV): a gateway to reusable semantic vocabularies on the web[END_REF]. Overall, when used together, O-MI and O-DF provide the necessary tools for "any" IoT information systems to interoperate successfully in ad-hoc manners. Getting back to the main subject of exposing IoT data/services, bIoTope aims to develop an IoT service marketplace 7 (including search engine and smart contract capabilities) whose primary goal is to put IoT data/service publishers and potential third party • Spatial/Temporal-based search: one may want to search for services within a geographical area;

• Keyword-based search: one may want to search for services falling in a specific application area (e.g., mobility, healthcare, etc.);

• Reputation-based search: one may want to search for a service ensuring a certain level of quality, which comprises various dimensions such as (i) data quality: quality of sensor data streams, or of more advanced services (e.g., how accurate a failure prediction algorithm is), (ii) service owner reputation: third party developers being able to leave a review about whether the data stream works fine, the publisher of the accessed data stream is reactive when asking question, etc.;

• Contractual term or Technology-based search: one may want to search only for IoT data/service publishers that make them available for free or are compliant with a specific crypto currency, or data/services that are compliant with specific IPR policies (e.g., license type, etc.); Once a third party developers identify relevant IoT data or services that they would like to access to, agree on the contract terms (potentially leading to monetary transactions), the IoT service marketplace "delivers" one or more API access security tokens and/or certificates (valid for specific durations, access rights, etc.) that will enable them to access the data/service from the remote O-MI node/server, whose communications between the consumer and publisher is achieved in an ad-hoc manner (see stage ➃). At this stage, third party developers can rely on their own preferred IDE (Integrated Development Environment) for accessing, combining, and processing the accessed data streams or services, meaning that bIoTope does not impose the use of any specific IDE tool, as illustrated in Fig. 2. For example, in section IV, the IoT visual programming tool "Node-Red" (developed by IBM) is used for service composition purposes. The next section provides greater insights into O-MI and O-DF standard specifications.

B. O-MI: a generic and standardized Open API

O-MI and O-DF standards emerged out of past EU FP6 and FP7 projects (e.g., PROMISE FP6, LinkedDesign FP7. . . ), where real-life industrial applications required the collection and management of product instance-level information for many domains involving heavy and personal vehicles, household equipment, phone switches, etc. [START_REF] Främling | Universal messaging standards for the IoT from a lifecycle management perspective[END_REF], [START_REF] Främling | Sustainable PLM through intelligent products[END_REF], [START_REF] Kiritsis | Closed-loop PLM for intelligent products in the era of the Internet of Things[END_REF]. Information such as sensor readings, alarms, assembly, disassembly, shipping event, and other information related to the entire product life cycle needed to be exchanged between products and systems of different organizations. Based on the needs of those real-life applications, and as no existing standards could be identified that would fulfil those requirements without extensive modification or extensions, the partner consortia started the specification of new messaging interfaces [START_REF] Främling | Universal messaging standards for the IoT from a lifecycle management perspective[END_REF]. Those specifications have since then been further developed and published by the IoT WG of The Open Group. O-MI provides a generic Open API for any RESTful IoT information system, meaning that in the same way that HTTP can be used for transporting payloads in formats other than HTML, O-MI can be used for transporting payloads in nearly any format. In resume, O-MI and O-DF are independent entities that reside in the OSI Application layer, where O-MI is specified at the "communication" level and O-DF at the "format" level.

C. O-DF: a generic content description model for Things

O-DF is defined as a simple ontology, specified using XML Schemawhich might currently be the most common textbased payload format due to its flexibility, thus providing more opportunities for complex data structures [START_REF] Perera | Context aware computing for the Internet of Things: A survey[END_REF] -that is generic enough for representing "any" object and information that is needed for information exchange in the IoT. It is intentionally defined in a similar manner as data structures in objectoriented programming. O-DF is structured as a hierarchy with an "Objects" element as its top element (see Fig. 3), which can contain any number of "Object" sub-elements. "Object" elements can have any number of properties, referred to as InfoItems, as well as "Object" sub-elements. The resulting Object tree can contain any number of levels (cf., Fig. 3). Every Object has a compulsory sub-element called "id" that identifies the Object. The "id" should preferably be globally unique or at least unique for the specific application, domain, or network of the involved organizations. The proof-of-concept developed in Regarding O-MI, one of its defining characteristics is that nodes may act both as "servers" and as "clients", and therefore communicate with each other or with back-end servers in a peer-to-peer manner. Typical examples of exchanged data are sensor readings, lifecycle events, requests for historical data, notifications, etc. One of the fundamental properties of O-MI is that O-MI/O-DF messages are "protocol agnostic" so they can be exchanged using HTTP, SOAP, SMTP, or similar protocols. Four operations are supported, as summarized in TABLE III. Another important feature of O-MI is that messages are "selfcontained" in the sense that all the necessary information to enable the recipient to handle the message is contained in the message itself (e.g., actions to be performed, callback address, TTL. . . ). Other relevant interfaces are presented in more details in [START_REF] Främling | Universal messaging standards for the IoT from a lifecycle management perspective[END_REF], [START_REF] Kubler | A standardized approach to deal with firewall and mobility policies in the IoT[END_REF], [START_REF] Kubler | P2P data synchronization for Product Lifecycle Management[END_REF] such as the "publication and discovery" mechanisms for data, services and meta-data using the "RESTful" URL-based queries. There are several IoT messaging standards comparable with O-MI, and vice-versa (e.g., MQTT, AMQP. . . ). Nonetheless, each standard is designed to address different IoT communication requirements. In fact, there are four distinct IoT communication models according to the RFC-7452 for networking of smart objects [START_REF] Tschofenig | Architectural considerations in smart object networking[END_REF], which are all illustrated in Fig. 4 and described hereinafter:

• Device-To-Device (D2D): two or more devices directly connect and communicate between one another rather than through an intermediary application server (cf., inside silos 1, 2 and 3 in Fig. 4);

• Device-To-Gateway (D2G): the IoT device connects to a local gateway device that may either (i) be connected to a Cloud service provider (cf., inside silo 1) or (ii) store and process device-related data at the edge (cf., inside silo 2);

• Device-To-Cloud (D2C): the IoT device connects directly to an Internet Cloud provider to exchange data and services (cf., inside silo 3). Frequently, the device and Two types of subscriptions can be performed:

• subscription with callback address: the subscribed data is sent to the callback address at the requested interval. Two types of intervals can be defined: interval-based or event-based; • subscription without callback address: the data is memorized on the subscribed O-MI node as long as the subscription is valid. The memorized data can be retrieved/polled by issuing a new O-MI read request by using the subscription ID.

-Cancel

Used to cancel a subscription before it expires.

Cloud service are from the same vendor (commonly referred to as "vendor lock-in"); [START_REF] Al-Fuqaha | Internet of Things: A survey on enabling technologies, protocols and applications[END_REF], highlighting for which IoT communication model(s) they have been primarily thought and designed for. Our study reports CoAP (developed by IETF), MQTT (developed by IBM), AMQP (developed by OASIS), Data Distribution Service -DDS (developed by the Object Management Group), and XMPP (developed by Cisco). As emphasized in this table, O-MI is primarily aiming at improving horizontal interoperability across vertical silos (S2S). Although this paper is not intended to carry out a technical and thorough comparison between O-MI and the above-mentioned standards, a few striking differences and cornerstones of this standard can nonetheless be pointed out: O-MI uses text-based representations (XML, JSON. . . ) instead of binary formats and can use any of the 'Communication' and 'Transport' level standards as its underlying protocol; O-MI provides a "RESTful" URL-based query mechanism and, like DDS, is "Data-centric" meaning that middleware can understand the data (e.g., object identity, hierarchy. . . ). This table highlights that three messaging protocols have the necessary provisions for Back-End Data-Sharing communications (DDS, XMPP, O-MI), although this may be a debatable topic; this is why a more in-depth analysis between all these communication protocols should be carried out in the future.

✓ ✓ D2G model ✓ ✓ ✓ ✓ D2C model ✓ ✓ ✓ S2S model ✓ ✓ ✓

IV. PROOF-OF-CONCEPT: SMART PARKING

The Qatari government that is closely working with Qatar University, expressed an interest in exploring and developing first proofs-of-concept using the O-MI/O-DF standards [START_REF] Hefnawy | Integration of smart city and lifecycle concepts for enhanced large-scale event management[END_REF].

In this respect, two usage scenarios have been developed and tested, respectively focusing on smart parking management of (1) cars arriving at stadium and in case of incidents inside the stadium (enabling smart emergency services during sporting events), and (2) city bikes to optimize citizens' and visitors' life during sporting events. Sections IV-A and IV-B focus on scenario 1, including a performance analysis of the O-MI/O-DF standards, while scenario 2 is detailed in section IV-C with a focus on service composition built using both Node-Red and the bIoTope technical building blocks previous described.

A. Scenario 1: Smart parking management -Information publication, discovery and consumption

In our scenario, each spectator has a unique profile that holds personal information, payment tools, and booked stadium seat numbers. Parking spots are booked in-advance through an online booking system that optimizes the spot allocation (e.g., to enable a car owner to be as close as possible to his/her stadium seat). Upon parking spot allocation, users may enter their car plate number to get fast track access to the stadium, which has several outer gates (see Fig. 5). Fast track gates have sensors to read the car plate numbers and check their eligibility to get in. Another sensor located at each parking spot reads the car plate number to check whether the car is or not at the right spot. If not, a signal as a warning (e.g., light or acoustic) will be issued to notify the user about

➁

Third party developers (system integrators, device manufacturers, businesses, public/ private institution. . . ) searching for valuable IoT data/services to turn them into new and sustainable developments that fulfill untapped needs and applications.

bI oT op eww w. bi ot op epr oj ec t.e u the disturbing situation (cf., red lights in Fig. 5). In this proofof-concept, we consider a simplified parking that is composed of four parking spot areas, respectively denoted by Areas A to D in Fig. 5. Those areas are respectively composed of 3, 6, 3 and 3 parking spots denoted by P i,j where i is the area index (i ∈ {A..D}) and j the corresponding spot index (e.g., j ∈ {1..6} for i = B). Given the parking configuration, several O-MI edge nodes (see O-MI nodes 1 to 4 in Fig. 5) have been implemented. O-MI node 1 (see Fig. 5) is responsible for collecting and publishing parking-related data (e.g., onsite car plate numbers, cars parked at the right spot. . . ).

• ✇ ✇ • ✇ • • ✇ ✇ • ✇ • • ✇ ✇ • ✇ • • ✇ ✇ • ✇ • Area B ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ • ✇ • • • ✇ • • Area C ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ • ✇ ✇ • ✇ • • ✇ ✇ • ✇ • Area D ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ • ✇ ✇ • ✇ • • ✇ ✇ • ✇ • • ✇ ✇ • ✇ • Area A ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ • • • • ✇ • • ✙ ✚ • • • • ➂ ➃ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ 13-CWK-91 ✉ O-MI Write ✉ O-MI Subscription O-MI node 1
In our usage scenario, the four O-MI edge nodes' owners can take the decision to expose to the service marketplace one or more of the IoT data/service published by these edge nodes. This stage is illustrated through arrows denoted by ➀ in Fig. 5, therefore allowing third party developers to search for, access and benefit from valuable IoT data/services in the city. Such a stage is not detailed in this paper, although an example of how a third party developer can innovate on top of this service marketplace is presented in section IV-C. In this first scenario, we assume that various system integrators, namely the stadium's, city's and hospital's system integrators have developed, based on the information exposed/published by these four O-MI edge nodes, new services for smart sporting event management. Arrows denoted by ➂ to ➆ illustrate the different network communications and interactions between the different O-MI node servers and city stakeholders.

A more detailed view of these network communications between O-MI node 1 and O-MI node 2 is given in Fig. 6 (see arrows denoted by "1" and "2a"), whose associated O-MI/O-DF subscription message ("1") is given in Fig. 7. Rows 1 to 5 detail the O-MI message interface where the operation is set to "read" with an interval set to "-1" and a specific callback address (see row 4), meaningaccording to the standard specifications -that the subscribed data values must be returned in an event-based manner to the stadium office (i.e., O-MI node 2). Rows 6 to 26 detail the message payload, or to be more exact, the part of the O-DF hierarchy that is subscribed to (the summarized hierarchy view in Fig. 7 helps to better understand how this information hierarchy has been thought/designed for this specific use case). In this example, the stadium office (O-MI node 2) subscribes to Plate Number Readers information related to Area 1 (P A,1 to P A,3 , Gate1. . . ). Given the message interface setting, the stadium office receives a notification every time that an InfoItem value changes. This is illustrated in Fig. 6 through arrow denoted by "2b", where a car whose plate number is 375684 arrived in front of Gate 1; a notification is then automatically pushed to the stadium office (O-MI node 2) that decides to open (or not) the Gate. In the scenario depicted in Fig. 6, the car is authorized to get in the parking and, accordingly, an O-MI write request is sent to O-MI node 1 (see arrow denoted by "3" in Fig. 6). The information collected by the stadium office can therefore be further processed and turned into (i) new key performance indicators (KPIs) such as the number of free parking spots, car queue length in front of each gate, etc.; or still into (ii) stadium free or fee-based Apps (see arrows denoted by ➄ in Fig. 5) that could potentially inform world cup spectators about how busy a drink and food sale booth is. Fig. 5 highlights through the communication between O-MI node 3 (city) and O-MI node 2 (stadium avatar) how the city can discover, access and use the stadium KPIs for various purposes (e.g., to provide indicators on the city health, citizens' well-being, number of free parking spots and real-time traffic state in the whole city, and so on).

• • • • ✇ ✇ • ✇ • ✶ ✶ • ✇
11 ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ Gate 4 closed ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚ ❚
A cross-domain scenario considering an emergency situation in the stadium is proposed and depicted in Fig. 6, where a notification about the emergency is sent to the city hospital. The hospital system sends an emergency vehicle to the stadium site. In order to be aware of whether there are controllable entrances/gates around the area of the accident, the emergency vehicleor hospital's back-end systemcalls the service marketplace's API requesting for the set of available IoT data/services that meet this multimodal search demand (see arrow denoted by ➃). The marketplace's IoT search engine identifies four InfoItems/Gates in the service catalog, which are returned as a list to the emergency vehicle (see ➄). In view of the vehicle's location and trajectory in the city, the vehicle predicts that Gate 4 will need to be opened when reaching the stadium. To this end, the vehicle or hospital's back-end system -sends a new request to the service marketplace asking the information needed to pay for accessing and controlling Gate 4. Although this microbilling process is out-of-scope of this paper (see [START_REF] Robert | Micro-billing framework for IoT: Research & technological foundations[END_REF]), the core idea is to establish a smart contract (e.g., based on blockchain-like technologies) between the vehicle/hospital and the "owner" of Gate 4-related data/services (stadium in our scenario) and, for this to happen, the service marketplace provides the vehicle/hospital with the necessary information, while monitoring that the contract/transaction is successfully agreed/made between both parties (publisher-consumer). Once confirmed, the necessary access rights to communicate and control Gate 4 are sent to the hospital/vehicle. All this is illustrated through arrows denoted by ➅ to ➈, while the last two stages/arrows emphasize the O-MI Write request sent by the hospital/vehicle to open Gate 4. Although it is obvious that it makes little sense to charge an emergency vehicle to get in the stadium parking, this scenario was presented first and foremost to describe the automated discovery and micro-billing stages, which are needed in many other IoT applications.

B. Scenario 1: A performance analysis of O-MI/O-DF

A first version of the O-MI and O-DF reference implementation has been released 8 and used as foundation of our smart parking system's proof-of-concept. As a complement of this reference implementation, a smart parking emulator and monitoring tool has been developed for both emulating the sensor/actuator events occurring on the field (e.g., the arrival of a car at a specific parking area. . . ) andfrom the client side -for visualizing the current state of the parking. Two screenshots of the parking emulator and monitoring tool are shown in Fig. 6. From an implementation perspective, and according to the O-MI/O-DF reference implementation guidelines, it is necessary to develop a software agent that periodically pushes the emulated data to an internal database (internal to the reference implementation). This data is then published and made available (depending on the access rights) for any peer O-MI node 9 . q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p Data load (bytes) 23

R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p R e q R e p Data load (bytes) Along with this emulator/monitoring tool, we propose to study the performance of the O-MI/O-DF reference implementation in terms of 'efficiency', which refers in this study to the amount of data (called 'data load' in the following) produced by the reference implementation to access one or more InfoItems and its efficiency ratio. To this end, a network analyser (Wireshark) has been used to analyze the network traffic considering the smart parking use case, which contains 23 InfoItems in total. At a more concrete level, these 23 InfoItems are read on an incremental basis, i.e. one read request/response including 1 InfoItem (and associated Objects' tree) is performed, then one request/response including 2 InfotItems, and so on. The result of this analysis is given in Fig. 8, where data load is composed of:

• a constant part related to the sum of the Ethernet protocol (26 bytes), the IP and TCP headers (respectively 20 and 32 bytes) for each request/response and their respective acknowledgment (78 bytes in the reference implementation). The transient states of the TCP opening and closing operations have not been considered. (encapsulation being represented in white color in the histogram). If the O-MI/O-DF message payload needs to be fragmented into a set of frames (according to the Maximum Transmission Unit equals to 1500 bytes in our implementation), the sum of the encapsulation is multiplied by the number of frames so as to obtain the global data load;

• a variable part related to the type of request/response. Indeed, when using the reference implementation via a web interface (see Fig. 8(a)), the application protocol HTTP is constant (462 bytes for the request and 173 bytes for the response) and the message payload is growing depending on the O-DF information hierarchy; the higher the number of levels, the higher the size of the message as demonstrated in Fig. 8(a).

In the performance evaluation process, O-DF is considered as payload in the reference implementation. However, one may argue that the payload is only the 'useful' data for the application, which can be either the value itself or the semantic (O-DF) structure depending on whether the application needs to understand the data before using it (reason for annotating data using O-DF and other web semantic annotations). As a consequence, we decided to study these two considerations that implies using, on the one hand, the reference implementation that conveys the whole or part of the O-DF tree depending on the request (associated performance results are given in Fig. 8(a)) and, on the other hand, the REST interface whose payload consists only of the URL in the request 10 and the value in the response (associated performance results are given in Fig. 8(b)). As can be observed in both figures, using the REST interface needs to send as many frames as InfoItems when reading more than one InfoItem; this is why the data load is continuously growing in Fig. 8(b), and vice-versa, using an aggregation strategy (i.e., using the O-DF payload) results in more efficient data load than sending one frame per infoItem. Looking deeper at both histograms, this aggregation strategy is paying off when embedding more than 7-8 InfoItems in a single message (cf. Fig. 8(b)), even though this is true only for this use case since it depends on the O-DF structure and content.

The number of frames and their size can impact the reliability and performance of the application depending, among other things, on the environment in which the application is being run. If the environment is noisy with a high bit/frame error rate (e.g., wireless network or in industrial environments), then it may be more sensible to send smaller frames (i.e., to adopt the REST interface strategy) at the expense of the global data load that increases when reading more than 7-8 InfoItems in this specific case. Indeed, the higher the packet size, the higher the probability that an error occurs, which has a non negligible impact on the efficiency performance due to erroneous frames retransmission. However, the aggregated strategy (i.e., making use of O-DF) adds a generic semantic/vocabulary that is key to automate the reasoning in IoT applications, which is more than essential for enhanced interoperability in the "Back-End Data Sharing" communication model, whereas the REST interface has the advantage of minimizing the load related to the HTTP layer as evidenced when comparing the first request/response between Fig. 8(a) and 8(b). These two advantages could potentially be combined in future reference implementation versions by sending to the REST interface (via HTTP POST) an O-DF payload. Furthermore, since REST-based messages are intended to be processed by machines/devices, we could even suggest to optimize the O-DF payload by removing human-readable constraints imposed by the web-interface of the reference implementation (i.e., spaces and carriage return feeds). Such an hybrid strategy has been set up, whose performance results are given in Fig. 8(c). It can be noted that the size of the frames (and thus the number of frames) and the global data load decrease compared with the web-version (cf., Fig. 8(a)), and the efficiency ratio increases.

In summary, even if the data load generated by the initial version of the O-MI/O-DF reference implementation is non negligible, it remains acceptable for non real-time or critical time applications. Nonetheless, as explained in section III and evidenced through IoT-based smart parking use case, O-MI/O-DF standards have not been designed for such timeconstrained applications, but rather to improve interoperability across distinct systems and organizations. Regarding the final smart parking infrastructure, the Qatar government has not yet decided on the technologies to be used/deployed on site, but we believe that our findings can help to decide how to use or properly adapt the O-MI/O-DF reference implementation to the final decisions and expectations. For example, if more automated services (without human in the loop) would need to be developed, we could propose more advanced frameworks that would take full advantage of the REST interface (i.e., both HTTP GET and POST -Fig. 8(b)-8(c)), while taking into account the overall environment and selected technologies (e.g., if the network suffers from high packet loss rates, etc.). The self-adaptation capabilities of such frameworks could even take into consideration the final O-DF tree for deciding to switch, when reading a certain number of InfoItems, between the HTTP GET and POST depending on whether or not the aggregation strategy is paying off.

C. Scenario 2: Smart parking management -Service composition workflow using IoT visual programming tool

The objective of this second scenario is to show that third party developersafter having identified, paid for, and received the necessary rights to access specific IoT data/services -can use their own preferred IDE to develop innovative applications. In this scenario, we consider the open source software tool Node-Red11 , which allows developers to wire together devices, APIs, and other online services as part of the IoT. In this respect, the bIoTope consortium has developed and released a Node-Red's nodes 12 covering the O-MI and O-DF standard specifications (see bottom-left of Fig. 9).

Overall, Fig. 9 provides an overview of the different flows and nodes used to create a new cross-platform service for citizen or visitors during the FIFA World Cup 2022 event. This service is intended to enable a citizen/visitor to provide his/her home/hotel location as input parameter in order to be notified about the best bike parking spot to go and pick up a bike, taking into consideration both the weather forecast as well as the number of bikes available per spot. A screenshot of the resulting App that the municipality wants to develop is provided in Fig. 10. For such a development, the municipality's developer identifies via the data/service marketplace that (i) bike parking spot-related data can be accessed for free via the municipalities O-MI node (see Fig. 9); similarly regarding (ii) weather station-related data in the city, where some owners charge for the access; and let us assume that (iii) the App's end-user home or hotel is equipped with a smart bulb that can be controlled using O-MI, which serves in our scenario to turn the light to a specific color when the end-user is about leaving according to the current situation (e.g., turn the light to red if there are less than n bikes on all the surrounding parking spots, thus notifying end-users that they have to hurry up or potentially change their plan). Fig. 9 shows the service composition flow that the municipality's developer has developed using Node-Red, which consists of three layers:

• P2P data access: this is may be the most important layer, or at least the key message we want to convey through this paper, namely that municipality's developer only has one standard to use for both understanding and accessing IoT data or services in the city, regardless of whether the "underlying" platforms come from hundreds or thousands of vendors. In this scenario, the municipality's developer subscribe to all bike parking spot-related data streams surrounding the end-user's home/hotel (namely the num-ber of available bikes on all spots over the city) and to the weather station that is the nearest of end-user's home/hotel;

• Intelligence workflow: this layer contains the set of algorithms that compose the service workflow, fulfilling the service logic/behaviour above-described;

• Web-based App: this layer deals with the App's UI; A recent tutorial and showcase video has been edited and uploaded to Youtube 13 , showing all the elements discussed in this paper, meaning the use of (i) the bIoTope service marketplace, (ii) the O-MI and O-DF nodes in Node-Red, and (iii) the App developed based on Node-Red. Readers can potentially watch this video to obtain additional information and a better understanding of the bIoTop's vision and ambition.

V. CONCLUSION

The IoT is playing an ever-important role in this new digital landscape, offering us ways to make our world smarter and more interconnected than it has ever been before. Having said that, there are still important challenges ahead that need to be Fig. 10. Citizen App developed based on Node-Red (see Fig. 9) addressed to enable businesses to make the most of the IoT. A crucial challenge is to overcome the "vertical silos" that shape today's IoT (e.g., vendor-lock in/siloed Apps), which are closed to the rest of the IoT and hamper developers to produce new added value across multiple platforms. The EU has taken this challenge very seriously by launching several and complementary IoT Programmes. This paper offers an overview of such EU programmes initiatives. This paper further focuses on the vision, ambition and first technical building blocks developed in the bIoTope H2020 project, which makes use of recent Open API standards named Open Messaging Interface (O-MI) and Open Data Format (O-DF) to fulfill requirements for "Back-End Data-Sharing' communications (RFC7452). Further insights into these standard specifications are provided in this paper, along with a proof-of-concept developed based upon O-MI/O-DF and other ecosystem building blocks -for enhanced sporting event management in the context of the forthcoming FIFA World Cup 2022 in Qatar.

Although bIoTope like initiatives provide the necessary foundation to create technically and economically viable IoT ecosystems in Europe, there are still challenges to be solved, particularly to leverage semantic web technologies for the IoT (also called "Semantic Web of Things") to converge heterogeneous data sources in a smart ecosystem. The answers that will be given will not put into question the O-DF standard since it only provides a generic content description models for IoT data representation description, which needs to be annotated using other vocabularies (iot.schema.org, SSN, DATEX II, HL7, etc.), as can be found on Linked Open Vocabularies (LOV) like repositories that make it possible to lookup vocabularies to annotate and parse messages.

Finally, although this deliverable has not focused on security and privacy aspects, the bIoTope consortium is investigating and developing the necessary building blocks to make the ecosystem robust and resilient against cyber-attacks and/or failures (including identification and authentication, data protection and prevention against threats at both the device and system levels. The ecosystem must provide end-users (either developers who make use of the IoT service marketplace or Apps' end-users) with tools and supports to give them back control over of their personal data/services, e.g. to help them to (i) decide sharing (or stop sharing) personal data with third parties; (ii) know what personal data are exposed and its actual content (ii) audit who are accessing and processing personal data (iii) have automated vulnerability notification mechanisms to ensure that the ecosystem cannot be too much affected by harmful intent (malware, viruses, hackers), etc.

Fig. 1 .

 1 Fig. 1. Towards more open IoT ecosystems for joint service co-creation, delivery, and radical innovation practices

Fig. 2 .

 2 Fig. 2. IoT-based Smart Parking System for Sporting Event Management using O-MI & O-DF standards

Fig. 4 .

 4 Fig. 4. IoT communication models (RFC-7452)

  Service marketplace: Search, Discovery & Micro-billing capabilities . . .

4 ➀Fig. 5 .

 45 Fig. 5. IoT-based Smart Parking System for Sporting Event Management using O-MI & O-DF standards

7 O

 7 Emulator developed to generate events on the the field (i.e., the sensors' state). Here e.g. we emulate the arrival of a car at Gate A Actuator value (open or close the barrier) Sensor value (car plate number) ➀ O-MI Sub(Are a 1-relat ed InfoIte ms) See message given in Fig. -MI Resp(Su b ID=1) 2a 2b O-MI Resp(Pl ate GateA=3 75684,S ub ID=1) ➂ O-MI Write(G ate1=Op en) Performance evaluation of the O-MI/O-DF reference implementation (see section 4.B)

Fig. 6 . 1 < 5 <omi:msg> 6 <O 7 <O b j e c t> 8 <i d>StadiumParking</ i d> 9 <O b j e c t> 10 <i d>Area1</ i d> 11 <O b j e c t> 12 <i d>Plate_Number_Readers</ i d> 13 <O b j e c t> 14 <i d>Plate_Number_Readers_Parking</ i d> 15 <I 18 </ O b j e c t> 19 <O b j e c t> 20 <i d>Plate_Number_Readers_Gates</ i d> 21 <I 22 </ O b j e c t> 23 </ O b j e c t> 24 </ O b j e c t> 25 </ O b j e c t> 26 </ O b j e c t s> 27 </ omi:msg> 28 <Fig. 7 .

 615678910111213141518192021222324252627287 Fig. 6. Smart parking scenario combining a parking emulator and monitoring tool based on the O-MI/O-DF reference implementation

(

  a) Data Load (bytes) and efficiency ratio of the web interface with O-DF payload

(

  b) Data Load (bytes) and efficiency ratio of the REST interface with payload as text-plain value (HTTP GET)

Fig. 8 .

 8 Fig. 8. O-MI/O-DF reference implementation analysis with respect to the standard specifications

Fig. 9 .

 9 Fig. 9. Innovative Cross-domain & Cross-platform IoT service developed based upon the bIoTope's open IoT ecosystem developed and Node-Red's IoT visual programming tool

  TABLE II provides an overview of what are the focus of each project, namely:

	• Integration of devices: this topic refers to M2M commu-
	nications capabilities, where turn-key M2M solutions and
	components are developed and easy to be deployed. For
	example, TagItSmart will develop innovative optical tags
	(using a new QR code ink technology) and associated
	Cloud services for enhanced product tracking; INTER-IoT
	and symbIoTe aim to use a common M2M service layer
	specifications (based on the ETSI's oneM2M standard);
	AGILE proposes a gateway access point that should inte-
	grate key IoT modules such as modularity, extensibility,
	privacy and development toolkit management;

• Creation of platforms: this topic refers to the definition, specification and extension of platforms, either Cloud-based or local (or both), depending on the pilot needs and requirements. For example, TagItSmart and symbIoTe are developing Cloud-based services (TagItSmart will e.g. re-use available FIWARE components); bIoTope and VICINITY put particular emphasis on edge nodes (e.g., based on Fog computing and distributed analytics);

  In this paper, our research work focuses on the standardized open API developed and used in the bIoTope project, notably the Open Messaging Interface 3 (O-MI) and Open Data Format 4 (O-DF) standards.

		TABLE II
		H2020 PROJECTS DEVELOPED UNDER THE ICT-30 PROGRAMME (2016-2019)
	Acronym	Project Name	Integration of devices	Creation of platforms	Interoperable APIs	Autonomous reasoning	Website
	AGILE	Adoptive gateways for diverse multiple environments	✓	✗	✓	✗	www.agile-iot.eu
	BIG IoT	Bridging the Interoperability Gap of the Internet of Things	✗	✓	✓	✓	www.big-iot.eu
	bIoTope	Building an IoT oPen innovation ecosystem for connected smart objects	✗	✓	✓	✓	www.biotope-project.eu
	INTER-IoT	Interoperability of heterogenous IoT platforms	✓	✓	✓	✗	www.inter-iot-project.eu
	symbIoTe	Symbiosis of smart objects across IoT environments	✓	✓	✗	✗	www.symbIoTe-h2020.eu
	TagItSmart	Smart Tags driven service platform for enabling ecosystems of connected objects	✓	✓	✗	✗	www.tagitsmart.eu
	VICINITY	Open virtual neighbourhood network to connect intelligent buildings & smart objects	✗	✓	✓	✗	www.vicinity2020.eu
	offerings, ad-hoc collaboration, co-creation and co-invention,
	adopting exploratory approaches targeting radical innovations
	[33], [6]. As stated in the recent IBM's report, entitled "The
	Power of the API Economy" [34]:
	"The API Economy has changed how we think
	about building applications (think apps) and how
	we deploy software (think cloud). The largest im-
	pact of this change for business is speed: Business
	processes and data are no longer locked inside
	applications.The result is the death of data and
	application silos."

  TABLE IV gives insight into well known IoT messaging standards

https://www2.opengroup.org/ogsys/catalog/C14A, last accessed Apr., 2017.

https://www2.opengroup.org/ogsys/catalog/C14B, last accessed Apr., 2017.

A distinction is made between IoT data and IoT services in this document, "IoT data" referring to IoT data streams coming from sensors or other systems generating or holding data (databases, files. . . ), while an "IoT service" refers to the call of a web service that takes, as inputs, one or more parameters and imply a processing stage to return the expected result.

LOV (Linked Open Vocabularies) initiative gathers and makes visible indicators such as the interconnections between vocabularies and each vocabulary's version history, along with past and current editor (individual or organization).

[START_REF] Zhao | An event-driven service provisioning mechanism for IoT (Internet of Things) system interaction[END_REF] A first version of the IoT service marketplace has been released at the following URL: https://otaniemi3d.cs.hut.fi/IoTBnB/, last accessed Apr., 2017.

JOURNAL OF L A T E X CLASS FILES, VOL. 14, NO. 8, AUGUST 2015

Github: https://github.com/AaltoAsia/O-MI, last accessed Apr., 2017.

A web-interface is supported facilitating the use of the O-MI operations (read, write. . . ): http://biotope.sntiotlab.lu:8080/html/webclient/index.html

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2017.2692247, IEEE Access JOURNAL OF L A T E X CLASS FILES, VOL. 14, NO. 8, AUGUST 2015

Embedded in the HTTP protocol as a plain-text, which means that the size of HTTP varies according to the URL (i.e., the number of digit, e.g. in the string Objects/StadiumParking/Zone1/Gates/Gate1).

https://nodered.org, last accessed Apr., 2017.

The corresponding files (.js and .html) are available at the following GitHub repository, but not yet in the Node-RED Library: https://github.com/skubler, last accessed Apr., 2017.

https://www.youtube.com/watch?v=OueY3o-Rf 4&t=36s, last accessed Apr., 2017.

ACKNOWLEDGMENT

The research leading to this publication is supported by the EU's H2020 Programme for research, technological development and demonstration (grant 688203), as well as the National Research Fund Luxembourg (grant 9095399).


Mohamed Amine Menacer
email: mohamed-amine.menacer@loria.fr

Odile Mella
email: odile.mella@loria.fr

Dominique Fohr

Denis Jouvet

David Langlois
email: david.langlois@loria.fr

Kamel Smaïli

Kamel Smaili
email: kamel.smaili@loria.fr

An enhanced automatic speech recognition system for Arabic

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The Arabic language is the fifth most widely spoken language in the world with an estimated 295 million native speakers. It is one of the most morphologically complex languages. Due to this, developing an Automatic Speech Recognition (ASR) system for Arabic is a very challenging task.

Arabic language is characterized by the high number of dialects used in daily communications. There is a significant difference between these dialects and the Modern Standard Arabic (MSA), which is used in newspapers and formal commu-nication. In this article, we will describe our ASR system for MSA implemented using Kaldi toolkit.

Kaldi is a state of the art toolkit for speech recognition based on Weighted Finite State Transducers (WFST) [START_REF] Povey | The kaldi speech recognition toolkit[END_REF][START_REF] Mohri | Speech recognition with weighted finite-state transducers[END_REF]. It includes multiple scripts and recipes for most standard techniques. These recipes are available with many speech corpora and they are frequently updated to support the latest techniques like Deep Neural Networks (DNN).

In this work, several state of the art's modeling techniques are tested, namely the GMM-HMM models, the DNN models and various techniques like: Maximum Mutual Information (MMI) [START_REF] Bahl | Maximum mutual information estimation of hidden markov model parameters for speech recognition[END_REF], feature-space Maximum Likelihood Linear Regression (fMLLR) [START_REF] Povey | Feature and model space speaker adaptation with full covariance gaussians[END_REF] and Speaker Adaptive Training (SAT) [START_REF] Anastasakos | A compact model for speaker-adaptive training[END_REF]. The gain obtained after training each model will be reported later on.

Our ASR system is built using several hours of standard Arabic news broadcasts from corpora distributed by ELRA.

Another interesting treatment, proposed in this article, is the auto-correction of hamoza in the ASR system output in order to rectify the orthography confusion of this symbol above or below Alif. The approach used is inspired from various techniques proposed in the literature for detection and correction of spelling errors. The particularity of our approach is the use of the vector representation of words to retrieve the context and to correct misspelled words.

In the next section, an overview about Arabic language issues and some works proposed in the literature to deal with those problems is presented. Section 3 describes the different corpus used to train the acoustic and language models, as well as the data normalization process. Section 4 details the acoustic and language models. Finally, the ex-perimental results are discussed in Section 5.

Related works

Even though classic techniques for ASR systems can be efficiently applied to Arabic speech recognition, it is necessary to take into account language specificities to improve the system performance. Arabic is a morphologically rich language. By concatenating prefixes and suffixes to stems, other words are obtained. The stem can be also decomposed into a root (generally a sequence of three consonants) and a pattern of vowels and, possibly, additional consonants. For example: the word wabikutubihim "and with their books" is composed of the two prefixes w "and" and b "with", the stem kutub "books", which is derived from the root ktb "to write" and the suffixe hum "their". This explains the high out-of-vocabulary (OOV) rate compared with English language which consequently leads to the increase of the Word Error Rate (WER). To deal with this issue, [START_REF] Afify | On the use of morphological analysis for dialectal arabic speech recognition[END_REF][START_REF] Xiang | Morphological decomposition for arabic broadcast news transcription[END_REF][START_REF] Diehl | Morphological analysis and decomposition for arabic speech-to-text systems[END_REF][START_REF] Ng | Improved morphological decomposition for arabic broadcast news transcription[END_REF] propose to use morphological segmentation. They shown that the results obtained with a large lexicon could be achieved with a reduced one if morphological decomposition is applied.

Another interesting approach investigates language models based on morphological analysis. [START_REF] Choueiter | Morpheme-based language modeling for arabic lvcsr[END_REF] used a morpheme-based language modeling by exploiting a statistical segmentation algorithm [START_REF] Lee | Language model based arabic word segmentation[END_REF] to decompose data. An automaton of type finite state acceptor was used to allow legal sequences of morphemes. With this approach, a 2.4% absolute WER improvement was achieved by using a medium vocabulary (less than 64k words) and a morpheme n-gram model compared to a conventional word-based model. However, by using a large vocabulary (800k words), an absolute improvement of only 0.2% was achieved.

Likewise, the Factored Language Models (FLMs) [START_REF] Bilmes | Factored language models and generalized parallel backoff[END_REF] was used to improve the WER. In [START_REF] El-Desoky | A hybrid morphologically decomposed factored language models for arabic lvcsr[END_REF], the morphological decomposition was combined with FLM to iron out the Arabic complex morphology. A good improvement was shown by rescoring the n-best list with a FLM based on partially decomposed words.

One more idiosyncrasy of the Arabic language is that it is a consonantal language. It just has three vowels, each of which has a long and short form. Formal texts are generally written without short vowels, consequently a single grapheme word could have several possible pronunciations. For example, the word ktb could be pronounced like: kataba "write", kutubN "books" or Kutiba "written by" and it also has other potential diacritizations. This ambiguity is solved by using the contextual information of words. Even though the short vowels make easy the pronunciation modeling, their use increases the number of the entries in the vocabulary and consequently the size of the language model. In fact, [START_REF] El-Desoky | Investigating the use of morphological decomposition and diacritization for improving arabic lvcsr[END_REF] showed that the best WER value is achieved by applying a morphological decomposition on a non-diacritized vocabulary. However, a nice improvement was shown in (Kirchhoff and others, 2002) by using short vowels in data training transcripts.

Besides short vowels, another problem to be taken into account in pronunciation modeling is the geminated consonants. In fact, there are cases where the consonant pronunciation should be stressed, and this can frequently happen with the prefix Al "the". The solar consonants after this prefix should be doubled (the solar consonants are: t, v, d, g, r, z, s, $, S, D, T, Z, l, n). The matter of geminated consonants was investigated in some studies. In [START_REF] Lamel | Automatic speech-to-text transcription in arabic[END_REF], it has been shown that modeling explicitly geminates improved a little bit the system performance.

Another issue in Arabic concerns the omission of the symbol hamoza which is pronounced but often not written. This leads to a pronunciation ambiguity. For example: the word AlEb could be pronounced >aloEab "I play" if the hamoza is above Alif or <ilEab "play" if it is below Alif .

Data resources

The data presented in this section are utilized to train acoustic and language models, to estimate the different parameters and to test the performance of the system.

Acoustic data

To train the acoustic model, a collection of spoken transcribed data-set is required. In our case, we used two corpora: Nemlar 1 and NetDC 2 distributed by ELRA. They consist of several hours of Standard Arabic news broadcasts recorded in linear PCM format, 16 kHz and 16 bits.

The data was splitted into three parts: one part for training (Train), the second for tuning (Dev) and the last one for evaluating the performance of our system (Test). Table 1 illustrates some statistics about the acoustic data.

Corpus

Train Dev Test Total Nemlar 33(83%) 3(08%) 3(9%) 40 NetDC 19(82%) 3(10%) 2(8%) 23 Total 52(83%) 6(09%) 5(8%) 63

Table 1: The acoustic data (hours).

The data splitting is done randomly by keeping 52 hours for the Train, which is equivalent to 83% of data. 6 hours (9% of data) are used in the Dev set and the rest (5 hours) is used in the Test set. In order to balance the data selection between the two corpora, two-thirds of the data is selected from Nemlar corpus.

Textual data

The language model is trained by using two corpora: GigaWord 3 Arabic corpus and the acoustic training data transcription.

GigaWord corpus was collected from nine sources of information with a total of 1,000 million word occurrences. The transcription of the acoustic training data contains about 315k words.

As regards the lexicons, the Nemlar and NetDC corpora are provided with phonetic lexicons in Arabic SAMPA format. We used them in the training task in order to specify the pronunciation of each word in the transcription of acoustic training data. The two lexicons have 79k pronunciation variants and 77k unique vowelized words, which is equivalent to an average of 1.02 pronunciation variants per word. The number of pronunciation variants per word is weak because all data transcripts and lexicons are written with short vowels 1 http://catalog.elra.info/product_ info.php?products_id=874

2 http://catalog.elra.info/product_ info.php?products_id=13&language=fr

3 https://catalog.ldc.upenn.edu/ LDC2011T11

and thus each word will not have various pronunciation.

In the recognition task, we used non-diacritized data for training language model, therefore another lexicon without short vowels is used. This lexicon will be described in Section 4.2.

Data normalization

Several issues were encountered while processing the textual corpora due to the Arabic spelling, which is often ambiguous. Therefore, a normalization step is necessary when processing the Arabic text.

Most of the orthographical errors were treated by using regular expression rules. In following, some processing necessary for reducing the ambiguity of spelling and pronunciation are presented:

• All email addresses, url paths, special characters (<, $amp; ...), punctuations and non-Arabic texts are removed.

• All diacritics representing short vowels or consonant stressing are striped.

• All numbers are normalized and they are converted into literal words.

• The prefix wa "and" is separated from words by using Farasa toolkit [START_REF] Abdelali | Farasa: A fast and furious segmenter for arabic[END_REF] and all other prefixes: b, f, Al, k, l and s are concatenated to words.

• The stretched words are reduced to their original form. For example: is replaced by "men".

• A space is inserted after all words end by a ta marobuTa if it is attached to the next word. For example: replace by nihAyat Aloqaron "century end".

• The time is literally written such as in the following example: replace 15:30 by Alv∼livap wa valAvwn daqyqap.

• Some abbreviations are replaced by their corresponding meaning (see

Modelization

In this section, the different steps involved in the development of the DNN acoustic model is presented. Afterwards, the language modeling aspects and the various models developed are detailed.

Acoustic model

The development of the acoustic model is based on the Kaldi recipe. Our purpose here is to train a DNN model, which perform well with respect to the WER. For this, six different acoustic modeling systems are developed. For three of them, the emission probability of the HMM states is modeled by Gaussian Mixture Models (GMM) and for the others it is modeled by DNN models.

The acoustic features used are the Mel-Frequency Cesptral Coefficients (MFCC) with first and second order temporal derivatives. Therefore, the feature dimension is 39.

Three GMM-HMM models are successively trained. The first acoustic model (triphone1) is trained using directly the MFCC features. A Linear Discriminative Analysis (LDA) followed by a Maximum Likelihood Linear Transform (MLLT) are applied to train the second acoustic model (tri-phone2). For the third model (triphone3), the Speaker Adaptive Training (SAT) transformation with feature-space Maximum Likelihood Linear Regression (fMLLR) are used to make the system independent of speakers.

In order to take into account the influence of the context on the acoustic realization of the phones, all these models are triphone based models. The last model (triphone3) has 100k Gaussians for 4,264 states.

The DNN-HMM systems are trained using the frame-level cross entropy, sMBR criterion, the senone generated from the last GMM-HMM model (triphone3) and corresponding fMLLR transforms. In total, three DNN models are trained.

• DNN1 classifies frames into triphone-states, i.e it estimates Probability Density Functions (PDFs). DNN1 training is based on the crossentropy criterion.

• DNN2 and DNN3 are based on sMBR sequence-discriminative training. The difference between the two models is the number of iterations used to train the model. The sMBR sequence-discriminative training is used to train the neural network to jointly optimize for whole sentences instead of a frame-based criterion.

The DNN models have 6 hidden layers and 2048 nodes per layer. The input layer has 440 nodes (40-dimensional fMLLR features spliced across 5 frames on each side of the central frame) and the output has 4,264 nodes. The number of parameters to estimate is about 30.6 millions.

Figure 1 summarizes all the acoustic models of our ASR system.

Language modeling

A 2-gram Language Model (LM) is used to generate the lattice and a 4-grams LM is used to rescore this lattice. As the two text corpora available (Gi-gaWord and transcripts of Train corpus) are unbalanced, a conventional training process is used. A LM is first trained on each data set (one on Gi-gaWord and one on transcripts). They are then merged through a linear interpolation, where the optimal weights are determined in order to maximize the likelihood of the transcripts the Dev set, which has a size of about 31k words.

For the 4-gram LM, which is used to rescore the lattice, 10 LMs are interpolated. Nine of them are trained on the different sources of GigaWord corpus and the last one is trained on the transcripts of the Train data. The interpolation coefficients are again estimated on the transcripts of the Dev data set.

The recognition vocabulary (lexicon) is generated by first keeping the 109k most frequent words from GigaWord corpus and the words that appear more than 3 times in the transcripts of the Train corpus. Afterwards, only the words for which pronunciation variants are in the Nemlar, NetDC lexicons and the lexicon used in [START_REF] Ali | A complete kaldi recipe for building arabic speech recognition systems[END_REF] were kept. This process has generated a lexicon having 95k unique grapheme words and 485k pronunciation variants, that is an average of 5.07 pronunciation variants per word. The high number of pronunciation variants per word is due to the fact that the lexicon entries do not contain the indication of the short vowels. Hence several pronunciation variants are possible for each word. This lexicon is used as the vocabulary to train the language models.

The SRILM toolkit [START_REF] Stolcke | SRILM-an extensible language modeling toolkit[END_REF] has been used to train the different LMs and all of them use Good-Turing (Katz) [START_REF] Katz | Estimation of probabilities from sparse data for the language model component of a speech recognizer[END_REF] smoothing technique. It is known that the Kneser-Kney smoothing (Chen and Goodman, 1996) performs better than the Katz technique. However, in [START_REF] Chelba | Study on interaction between entropy pruning and kneser-ney smoothing[END_REF], the authors showed through different experimental setup that the Katz smoothing performs much better than the Kneser-Kney smoothing for aggressive pruning regimes, which is the case in our system. In fact, due to memory constraints while compiling the automaton used by Kaldi for speech decoding, we used 2-grams pruned language models to generate the lattice. The pruning is done by keeping the n-grams with probability greater than 10 -9 . The 4-grams language model has also been pruned according two approaches. The first approach is the same as the one used to prune the 2-grams LM and the second is based on stolcke pruning technique [START_REF] Stolcke | Entropy-based pruning of backoff language models[END_REF]. This second pruned 4-grams LM is presented in Section 5.2.

The n-gram number and the perplexity calculated on the transcripts of the Dev data for various models before and after pruning are presented in Table 3.

n-gram unpruned pruned

Evaluations

This section presents the speech recognition results obtained with a 95k word lexicon for the baseline system, and after rescoring lattices. We also proposed an approach to auto-correct the hamoza above or below Alif to improve the performance.

Baseline system

Speech recognition engines determine the word sequence W which maximises the combination of two scores: the acoustic score P (O|W ) and the linguistic one P (W ). However, these two scores are calculated on different data which leads to a different scale of probabilities. In fact, the language model score is greater than the one provided by the acoustic model. The probabilities are adjusted as follows:

Ŵ = arg max W P (O|W )P (W ) LM (1)
where LM is a fudge factor. In order to estimate the best value of LM , we used the transcripts of the Dev corpus. Figure 2 presents the evolution of the WER with respect to the language model weight LM for each acoustic model. In table 4, the best values of LM for each acoustic model are presented, as well as the WER calculated on the Dev (31,314 running word) and the Test (31,726 running word) sets. Note that the lattice, in this baseline system, is generated by using the pruned 2-grams language model. As expected, DNN models perform better than the GMM-HMM models. The best WER value is 14.42 obtained by using the DNN3 model, which is based on four iterations of sMBR sequencediscriminative training. It should be noted that another GMM-HMM model is trained by applying the Maximum Mutual Information (MMI) criterion. By this, the WER decreased from 17.65 to 16.86 (a relative improvement of 4%). By using the DNN model, a relative reduction in WER of 14.47 has been achieved with respect to GMM-HMM model.

Model

It should be also noted that OOV rate is about 2.35% for the Dev part and 2.54% for the Test.

Rescoring

Let's recall that Kaldi is based on Weighted Finite State Transducers (WFST) for decoding. Because of this constraint, the decoding is done with a 2grams LM. One can expect that a rescoring using a more detailed LM (e.g., 4-grams) would improve performance. Thus, we applied a 4-grams rescoring, but only on the DNN3 hypotheses.

WFST is an automaton, which has a set of states and a unique start state. These states are interconnected by arcs, where each arc has an input label, an output label and a weight. To accomplish the language model rescoring, Kaldi generally first subtract the old language model cost from the global score and then add in the new language model cost to avoid modifying the other parts of the global score.

When using this approach, it is more accurate to replace a 4-grams model by another 4-grams LM. For this, we pruned the full 4-grams LM by using stolcke pruning technique [START_REF] Stolcke | Entropy-based pruning of backoff language models[END_REF]. This technique is based on minimizing the relative entropy between the full and the pruned model. We get a model which represents only 30% of the original model and consisting of 4 × 10 6 n-grams. It should be noted that the pruning is done by using the pocolm toolkit4 . We used this new model to produce the lattice. Afterward, this lattice is rescored by using a full 4-grams LM.

As in the baseline system, we estimate the impact of the LM weight on the Dev data. The variation of the LM weight is illustrated in Figure 3. We can remark that the smallest value of WER is obtained for LM = 14. The evolution of the WER with or without rescoring is given in Table 5. Rescoring the whole lattice with the 4-gram LM leads to an absolute improvement of 1.58% on the Dev set and 1.3% on Test corpus in comparison to the system, where the lattice is produced using the pruned 4-grams language model (the LM with 4 × 10 6 n-grams).

Model

We can also remark that producing the lattice by using a 2-grams pruned LM gives better results than using a 4-grams LM pruned with an aggressive pruning regimes. This is justified by the number of n-grams in each model (the number of n-grams in 2-grams LM is 5 times greater than the number of n-grams in the 4-grams pruned LM).

Auto-correction of hamoza

The hamoza symbol is widely used in Arabic; by analyzing the ASR system output, we noticed that there are cases where the symbol hamoza above or below Alif is omitted. Therefore, it seems interesting to auto-correct the hamoza spelling.

Our approach is inspired from techniques proposed in the literature to detect and auto-correct the spelling errors. This issue is a common problem to all languages. In Arabic, the most frequently occurring errors are editing errors and semantic spelling errors. The first error type occurs when a correctly spelled word is replaced by a non-word, while in the semantic spelling errors, the word is replaced by another correctly spelled word [START_REF] Mohamed I Alkanhal | Automatic stochastic arabic spelling correction with emphasis on space insertions and deletions[END_REF].

Several works have been proposed for spelling auto-correction in Arabic. Most of these works are based on the three steps described below.

Error detection: Techniques used in the literature for detecting Arabic spelling errors are essentially based on two approaches: the language rules [START_REF] Alshenaifi | Arib@ qalb-2015 shared task: A hybrid cascade model for arabic spelling error detection and correction[END_REF][START_REF] Shaalan | An approach for analyzing and correcting spelling errors for non-native arabic learners[END_REF][START_REF] Hassan | Arabic spelling correction using supervised learning[END_REF] or a dictionary [START_REF] Attia | Gwu-hasp: Hybrid arabic spelling and punctuation corrector[END_REF][START_REF] Zerrouki | Autocorrection of arabic common errors for large text corpus[END_REF][START_REF] Mohamed I Alkanhal | Automatic stochastic arabic spelling correction with emphasis on space insertions and deletions[END_REF]. For the first technique, detecting whether a word is misspelled or not depends on morphological analyzers. While the dictionary based technique de-pends on a large word list that covers the most frequently used words in the language.

The technique which we used to detect hamoza error is the dictionary lookup, where the input word is considered such as a non-word if it is not found in the dictionary. The word list size used in our case is 9.2M words. It is developed by [START_REF] Attia | Improved spelling error detection and correction for arabic[END_REF] by amalgamating various Arabic resources.

Production of hypotheses: The most common used technique to produce candidates is based on an edition distance, which measures the difference between two sequences by calculating the number of required edits to transform a word into another. We used a modified version of Damerau-Levenshtein distance proposed in [START_REF] Mohamed I Alkanhal | Automatic stochastic arabic spelling correction with emphasis on space insertions and deletions[END_REF]. The idea behind this distance is to assign a low distance cost for the letters that have shape or pronunciation similarity, or keyboard proximity. As we just want to correct hamoza error, we considered the similarity between the letters , , and . For example: consider the misspelled word Aamara "to order", if we calculate the similarity between the misspelled word and the two correct words tamor "date" and >amara "to order" using the normal Damerau-Levenshtein distance, we will obtain the same cost=1. While the modified distance will assign a lower cost for the word >amara "to order" than tamor "date" because of the similarity between the two letters and . At the end, to produce correction hypotheses, we just considered words in the Arabic word list, which have the same spelling as the wrong word except for the hamoza above or below Alif ( and . In the case where any candidature is not found, the word will not be corrected.

Error correction: for error correction i.e. selecting the best solution among the list of candidates, we tried to retrieve the words context by using word2vec [START_REF] Mikolov | Distributed representations of words and phrases and their compositionality[END_REF]. In fact, we used the GigaWord corpus to train a cbow model and to obtain word vectors, which are positioned in a 200-dimensional space such that words that share common contexts in the corpus are located in close proximity to one another in the space. Afterwards, we used the cosine similarity to retrieve the most similar word among the candidates.

Table 6 shows the results before and after cor-recting the hamoza in the ASR system output. Table 6: WERs before and after correcting the hamoza.

Model

From Table 6, note that the WER for the baseline system is 14.42. It should be noted that the lattice in this system is generated by using the 2grams LM. By correcting the hamoza in the ASR system output, we improved our ASR baseline system by 2%. The WER after rescoring the lattice generated by using the pruned 4-grams LM is 14.02. This represents 3% relative reduction in WER comparing to the baseline system. The best WER is 13.45 obtained by correcting the system output after rescoring. This leads to 7% relative improvement.

Conclusion

In this article, we described an ASR system for MSA developed by using Kaldi toolkit. We presented the different acoustic models trained and the text pre-processing done before training the LMs. The best results are achieved by rescoring the lattice, which is generated by using the DNN model, a 4-grams pruned LM and a lexicon of 95k words. This way we have obtained 3% relative improvement. In order to improve the system output, we proposed an approach based on the edit distance to auto-correct the hamoza spelling above or below Alif. Applying this approach, we achieved an improvement of 12% relative in comparison to the baseline model.

Figure 1 :

 1 Figure 1: Acoustic model flow diagram.

Figure 2 :

 2 Figure 2: WER evolution with respect to the language model weight.

Figure 3 :

 3 Figure 3: WER with respect to the language model weight after rescoring the lattice.

Table 3 :

 3 Statistics about LMs used to generate and to rescore the lattice.

Table 4 :

 4 WERs for baseline systems (without rescoring and by using the 2-grams LM).

		LM w Dev WER Test WER
	tri3	17	16.69	17.65
	DNN1	14	14.18	15.23
	DNN2	14	13.76	14.61
	DNN3	13	13.54	14.42

Table 5 :

 5 WERs before and after rescoring the whole lattice produced by using the 4-grams pruned LM.

		Dev WER Test WER
	DNN3	14.65	15.32
	DNN3+rescoring	13.07	14.02

https://github.com/danpovey/pocolm