Improving Bluetooth EDR Data Throughput Using FEC and Interleaving

ALICE is one of the four major LHC experiments at CERN. When the accelerator enters the Run 3 data-taking period, starting in 2021, ALICE expects almost 100 times more Pb-Pb central collisions than now, resulting in a large increase of data throughput. In order to cope with this new challenge, the collaboration had to extensively rethink the whole data processing chain, with a tighter integration between Online and Offline computing worlds. Such a system, code-named ALICE O2, is being developed in collaboration with the FAIR experiments at GSI. It is based on the ALFA framework which provides a generalized implementation of the ALICE High Level Trigger approach, designed around distributed software entities coordinating and communicating via message passing. We will highlight our efforts to integrate ALFA within the ALICE O2 environment. We analyze the challenges arising from the different running environments for production and development, and conclude on requirements for a flexible and modular software framework. In particular we will present the ALICE O2 Data Processing Layer which deals with ALICE specific requirements in terms of Data Model. The main goal is to reduce the complexity of development of algorithms and managing a distributed system, and by that leading to a significant simplification for the large majority of the ALICE users.

Download Full-text

Distributed binary geometric sensor arrays for low-data-throughput human gait biometrics

2012 IEEE 7th Sensor Array and Multichannel Signal Processing Workshop (SAM) ◽

10.1109/sam.2012.6250537 ◽

2012 ◽

Author(s):

Tianyao Yue ◽

Qi Hao ◽

David J. Brady

Keyword(s):

Sensor Arrays ◽

Human Gait ◽

Data Throughput ◽

Gait Biometrics

Download Full-text

Message exchange on base of a blockchain-based layered architecture

it - Information Technology ◽

10.1515/itit-2017-0037 ◽

2018 ◽

Vol 60 (5-6) ◽

pp. 253-261

Author(s):

Uwe Roth ◽

Theophane Ngne Djoua

Keyword(s):

Business Process ◽

Proof Of Concept ◽

Layered Architecture ◽

Knowing That ◽

Data Throughput ◽

Fast Development ◽

Message Structure ◽

Message Exchange ◽

Point To Point ◽

Main Message

Abstract In this article, we propose an architecture that allows to exchange messages or data via a blockchain solution, while keeping the business process independent from the concrete blockchain. The project is the consequence of a need to have fast development of a blockchain based proof of concept that shows the feasibility of a business process, while knowing that in a future step the underlying blockchain solution has to be replaced for reasons of licensing or maximal data throughput. This is done by providing an architecture on base of layers, similar to the OSI-model, and encapsulates the used blockchain within a wrapper layer that covers all blockchain specific properties and only provides a transparent view on the reading or writing from and to the blockchain. The higher layers re-implement point-to-point communication and introduce confidentiality by the use of encryption techniques. The architecture has been tested and proven by implementing two different blockchain solutions that are shielded by specific wrapper layer implementations. This wrapper layer is responsible for the fragmentation of the sent data and their encapsulation into the concrete blockchain solution. The reconstruction of the data takes care of the data fragments being sent potentially out of order or being incomplete. A payload layer is introduced to provide point-to-point communication and to embed the main message inside a message structure. In collaboration with underlying layer it identifies for which message one is not the addressee and allow the underling layer to stop collecting unnecessary data. A crypto-layer finally provides ways of encrypting messages for one or many recipients. Having fixed layers not only allows to replace the underlying blockchain solution but also to extend or replace the other layers in case new security features or optimized protocols need to embedded. The proposed solution does not allow to use specific features like smart contracts and only provides undeniable tamper-proofed existence of a sent message.

Download Full-text