Federico Corò

Roberto Verdecchia

Emilio Cruciani

Breno Miranda

Antonia Bertolino

JTeC: A Large Collection of Java Test Classes for Test Code Analysis and Processing

The recent push towards test automation and test-driven development continues to scale up the dimensions of test code that needs to be maintained, analysed, and processed side-by-side with production code. As a consequence, on the one side regression testing techniques, e.g., for test suite prioritization or test case selection, capable to handle such large-scale test suites become indispensable; on the other side, as test code exposes own characteristics, specific techniques for its analysis and refactoring are actively sought. We present JTeC, a large-scale dataset of test cases that researchers can use for benchmarking the above techniques or any other type of tool expressly targeting test code. JTeC collects more than 2.5M test classes belonging to 31K+ GitHub projects and summing up to more than 430 Million SLOCs of ready-to-use real-world test code.

Introduction

Test automation has been actively pursued since the 90's [START_REF] Pettichord | Success with test automation[END_REF] as a solution to reduce the high costs of software testing and improve product quality [START_REF] Kasurinen | Software test automation in practice: empirical observations[END_REF]. In more recent years, the advent of test driven development [START_REF] Janzen | Test-driven development concepts, taxonomy, and future direction[END_REF], and the following broad industrial take-up of continuous integration [START_REF] Fowler | Continuous integration[END_REF] and DevOps [START_REF] Zhu | Devops and its practices[END_REF] practices, with their promise of faster time to market and improved maintainability, are further pushing companies into test automation. A recent study by Zion Market Research [START_REF]Test automation market by test type: Global industry perspective, comprehensive analysis, and forecast[END_REF] estimates that the software test automation market will grow from the 16 Billion Dollars of 2016 up to 55 Billion Dollars by end of 2022.

However, this insurgence of test automation also comes with challenges and risks, which several researchers have been prompt to identify and face. One of the most evident issues is related to the growing scale of the test code that needs to be maintained, analysed, and processed side-by-side with production code. Indeed, as a result of promoting the practice of testing often and continuously, the sizes of test suites that have to be managed grow to limits that make traditional testing methods and tools not applicable anymore [START_REF] Memon | Taming google-scale continuous testing[END_REF]. Therefore, a thread of software testing research is addressing expressly the challenge of finding more efficient and scalable approaches [START_REF] Miranda | FAST approaches to scalable similarity-based test case prioritization[END_REF][START_REF] Elbaum | Techniques for improving regression testing in continuous integration development environments[END_REF][START_REF] Memon | Taming google-scale continuous testing[END_REF]. In [START_REF] Miranda | FAST approaches to scalable similarity-based test case prioritization[END_REF] we coined the term big testsets to denote test suites whose dimensions go beyond the capacity of existing testing tools.

On the other hand, many of the problems that Software Engineering research has been facing for decades in handling large scale software applications re-propose themselves for tackling such big testsets. However, studies have shown that test code exposes different characteristics than production code [START_REF] Van Deursen | Refactoring test code[END_REF][START_REF] Garousi | Developing, verifying, and maintaining high-quality automated test scripts[END_REF] and hence needs ad hoc methods. As a consequence several researchers analyse the quality of test code, propose metrics to assess test code quality, and try to identify useful patterns for good test code.

Repositories and associated languages

Step 2

Java repository identification

Java repositories URLs

Step 1

GitHub repository filtering

Step 3

Test classes identification

Repositories with count of test classes

Step 4

Repository selection

Step 5

Local storage

Final Java Repositories Raw dataset

Step 6

Preliminary quality filtering

JTeC

Figure 1: Overview of the JTeC composition steps and intermediate outputs

All the above research efforts demand availability of a large dataset of test code, to which the proposed methods and tools can be applied. However there does not yet exist such a collection for ready usage by the community. Therefore, most studies search in databases of Open Source projects, for example from GitHub, to collect a proper amount of test code: we did this recently in [START_REF] Cruciani | Scalable approaches for test suite reduction[END_REF] for challenging the efficiency of a scalable test reduction approach, while Gonzales and coauthors [START_REF] Gonzalez | A largescale study on the usage of testing patterns that address maintainability attributes: patterns for ease of modification, diagnoses, and comprehension[END_REF] made the same for studying testing patterns that can affect maintainability. In the above and many similar studies a consistent amount of effort has to be spent by the authors for setting up the experimental subjects. Moreover, as each team makes its own selection, it is difficult to make a comparison across similar studies.

As we ourselves are going to need such a dataset for validating our scalable approach to test prioritization [START_REF] Miranda | FAST approaches to scalable similarity-based test case prioritization[END_REF], we would like to make available for the usage of the community the test classes dataset that we collected. At the time of submission, the dataset, called JTeC (Java Test Classes), provides 2.5M+ test classes collected from a set of 31K+ projects in Github, which from now on the community working on test code analysis and processing can reuse without spending further effort. The JTeC dataset, and the quality filtering script which is provided as complement to the dataset, are available online in the JTeC bundle. 1In the remainder we describe the methodology followed to collect the dataset (Section 2), its structure (Section 3), and how it can be used for research (Section 4). We conclude the paper hinting at envisaged future JTeC developments.

Methodology

In this section we report the methodology we use to gather the data of our dataset. The process, illustrated in Figure 1, consists of six main steps: (i) GitHub repository filtering, (ii) Java repository identification, (iii) test classes identification, (iv) repository selection, (v) local storage of test classes, and (vi) preliminary quality filtering. In the reminder of this section we document the specifics of each step. For lower-level implementation details, we refer the reader to our replication package, containing the entirety of the scripts utilized to generate the dataset2 for the sake of the verification of the dataset, its replication and extension.

Step 1: GitHub repository filtering. The first step of our process consists of indexing the public GitHub repositories, and is carried out in order to execute efficiently the subsequent phases of our process. In this step we first retrieve the name of the public repositories and the username of their creators. This is achieved via a query to the GitHub API3 specifying the unique identifiers (ID) of the repositories in an incremental fashion (starting from the repository with ID=1). As stopping criterion for the repository indexing process we adopt the number of repositories required to collect 2.5M test classes. This number is approximated via a preliminary exploratory analysis, and amounts to approximately 31K repositories. We chose to target 2.5M test classes as we deem such number adequate in order to carry out studies requiring as input a large scale amount of heterogeneous test source code.

Subsequently, once we obtain the list of repository names mapped to the usernames of their creators, we can launch a second query to the GitHub API in order to retrieve the programming languages associated with each repository. The final output of this step consists of a local .csv file containing for each public repository indexed the following fields: repository ID, username of repository creator, name of the repository, and programming languages associated to the repository.

Step 2: Java repository identification. Once obtained a local copy of the indexed repositories mapped to their programming languages, we can effortlessly retrieve the URLs of the repositories developed in a specific language. In our case, we parse the .csv file created in the previous step to isolate the repositories developed exclusively in Java by inspecting the language tag of the indexed repositories, and subsequently combine their name with the username of their creators in order to identify the unique URL of the repositories. By parameterizing in our approach the programming language to be considered, we make the process effortlessly modifiable and extensible to take into account other languages, which are not utilized for the creation of the current version of the dataset. The final output of this step is the list of URLs corresponding to all Java repositories out of the ones indexed in Step 1.

Step 3: Test classes identification. Once we isolated the repositories developed in Java, we can identify the test classes of the repositories to store them locally. This is achieved by leveraging the standard naming conventions for Java test classes in Junit, the most popular Java unit testing framework [START_REF] Linares-Vásquez | How do developers test android applications?[END_REF]. Specifically, we do this by selecting the source code files of the selected repositories whose name ends with "Test.java" and "Tests.java".

More accurate methods could be used to select test cases, e.g., via static source code analysis [START_REF] Gonzalez | A largescale study on the usage of testing patterns that address maintainability attributes: patterns for ease of modification, diagnoses, and comprehension[END_REF]. Nevertheless, we opt for this solution as, given the large scale nature of our dataset, more complex solutions would potentially entail slower running times, hindering our ability to build the dataset in a reasonable amount of time. Moreover, by adopting a standard naming convention to select test classes, we aim not to introduce any significant bias.

More in detail, this third step entails the recursive retrieval of the file listing of the repositories4 by executing a query via the GitHub API. Subsequently, the list of files per repository is parsed in order to identify the files matching our specified naming convention. The naming convention adopted is designed as a parameter in our process, and can hence be adapted in order to consider a different naming convention w.r.t. the one adopted to create the current version of the dataset. The final output of this step consists of a list of Java repositories mapped to the number of test cases they contain, and commit hash considered (for replication purposes).

Step 4: Repository selection. Once we gather the list of Java repositories, we select all the original repositories present in the list for their subsequent inclusion in the dataset. In order to enhance the dataset and enable a wider range of potential research studies, we select among the forks of each original repository the one which contains the highest number of test cases. We opt to include exclusively the fork containing the highest number of test cases as this option maximizes the efficiency and effectiveness of the crawling process. Additionally, such a heuristic provides us a fitting criterion to pick, among various forks of a repository, the one which is best fitted to be included in our large scale collection of testing artifacts. As further documented in Section 3, forked repositories can effortlessly be trimmed out the JTeC dataset through a post-hoc filtering process (see Step 6).

Step 5: Local storage of test classes. Once we identify the Java repositories to be included in the dataset, we proceed to store locally the source code of the identified test classes. This is achieved by taking advantage of the file listing of the repositories retrieved in Step 3 to identify the test classes. For traceability purposes, the filesystem hierarchy of the repositories is preserved while storing locally the test source code. The output of this process is the entirety of the source code of the identified Java test classes and a .csv file specifying the repositories included, their considered commit hash, and their number of test cases.

Step 6: Preliminary quality filtering. To ensure the quality of the data contained in JTeC, we carry out a preliminary quality filtering process on the collected raw dataset. This process is carried out by excluding potential "toy" test suites, and entails identifying test suites comprising less than 5 test cases, and subsequently removing such instances from the dataset. The final output of this step is the final JTeC dataset, which is available online as part of the JTeC bundle [START_REF] Corò | JTeC: A Large Collection of Java Test Classes forTest Code Analysis and Processing[END_REF]. In order to make the dataset further tunable according to specific quality requirements which JTeC users may have, we provide the quality filtering script as complement of the JTeC dataset. Such script, taking as input several variables according to the dataset schema, enables the effortless execution of ad-hoc trimming operations on JTeC, as further documented in Section 3.1.

Description

The dataset is provided in compressed format and contains the entirety of the collected test source code (JTeC-Bundle.tar.gz). The total data storage space of the dataset amounts to 15 GB, and comprises 2.5M+ Java test classes distributed over 31K repositories, summing up to 431M source lines of code (SLOC). As the hierarchical tree structure of the GitHub repositories is preserved, the first two folder levels of JTeC consist of the repository creator username followed by the repository name. Further nested into the filesystem tree reside the test classes collected, according to the original ordering of the test files as reported in the GitHub repositories.

In addition to the complete collection of gathered source code, we provide an overview of the JTeC metadata in the file JTeC.csv. Such a file contains the most relevant information for each of the included repositories, in order to provide an eagle-eye overview of the data constituting the JTeC dataset. Specifically, each row of JTeC.csv corresponds to one of the repositories contained in JTeC, while the columns represent the following attributes:

• user: repository owner,

• repository: repository name,

• id: repository unique incremental identifier provided by GitHub API,

• fork id: unique incremental identifier of the original repository provided by GitHub API (value not empty only for repository forks),

• hash: repository commit hash of the version in JTeC,

• date: date of the commit considered in JTeC,

• n tests: number of identified test classes,

• SLOC: total SLOC of the test classes,

• size: total data storage space (Bytes) of the test classes.

An overview of the distribution of the date attribute of the repositories stored in JTeC is depicted in Figure 2. From the distribution we can observe that the median commit is dated to late-2012. This trend has to be attributed to the adoption of the repository ID in Step 1 to index repositories. We expect the distribution to be more skewed towards more recent dates if the dataset is expanded in the future, as more recent and active repositories would potentially be included. By inspecting more in depth the data, we can conclude that most of the outliers on the left hand side of the diagram correspond to commit dates modified manually a posteriori by the authors, as they are prior to both the creation git and GitHub. We opted not to remove such occurrences, as such process falls outside the scope of our dataset.

The distribution of the n test attribute of the repositories stored in JTeC is depicted in Figure 3. From the figure we can observe that the number of test classes varies highly across repositories, ranging from 5 test cases to more than 12 thousands, with a median of 14 test classes per repository and a mean of 85. Given the heterogeneous nature of this attribute, JTeC constitutes an encompassing dataset of testing artifacts, which enables via the filtering script to effortlessly retrieve source code according to specific ranges of test suite sizes, from small suites to big ones containing thousands of test classes.

In Figure 4, the distribution of SLOC per test suite is reported. As we can observe, the SLOC vary from a few lines per test suite to test suites containing more than 2M test SLOC (including test suites belonging to some projects of popular open source foundations, e.g. Apache and Eclipse). As for the number of test classes collected in JTeC, the variability of the SLOC attribute points to the heterogeneity of the source code collected, which encompasses small test suites as well as the ones of prominent open source projects.

Quality filter

As integrating part of the JTeC dataset, we make available in the JTeC bundle [START_REF] Corò | JTeC: A Large Collection of Java Test Classes forTest Code Analysis and Processing[END_REF] the filtering script adopted to carry out the preliminary quality filtering (see Section 2 -Step 6). Through such script we provide JTeC users with the capability to effortlessly explore the dataset and trim it according to their needs by applying further quality filters. The quality filter script, in fact, allows the user to generate a refined version of the dataset that only contains projects and test classes that adhere to user-defined constraints. The user, through a configuration file (config.json) provided in the JTeC bundle, can define a range of values for the following criteria (prefix MIN /MAX ):

• TS Size: test suite size (measured as number of test classes),

• TS Bytes: total number of Bytes of test suite,

• TS SLOCs: total number of SLOCs of test suite,

• TS Year: test suite year (based on the last commit date).

Additionally, the user has the ability to (prefix BOOL ):

• TS Clone: generate a cleaned copy of the dataset in folder JTeC-Clean/, with the same structure as that of JTeC/,

• TS Index: create JTeC-Clean.csv, an index of the cleaned dataset (in the same fashion of JTeC.csv),

• TS Original: include original projects in the cleaned dataset,

• TS Fork: include forks with the highest number of test classes (at the moment of download) in the cleaned dataset.

4 Purpose and applications

Our motivation

In our previous work we have been investigating scalable approaches for test case prioritization [START_REF] Miranda | FAST approaches to scalable similarity-based test case prioritization[END_REF] and test suite reduction [START_REF] Cruciani | Scalable approaches for test suite reduction[END_REF]. In [START_REF] Miranda | FAST approaches to scalable similarity-based test case prioritization[END_REF], for answering our research question related to scalability, we looked for datasets of big test suites (our aim was to have at least one million test cases) but because such a dataset was not available, we had to rely on the generation of synthetic test cases for carrying out our studies. Similarly, we also evaluated the scalability of the approach proposed in [START_REF] Cruciani | Scalable approaches for test suite reduction[END_REF]. This time, however, for minimizing possible threats to the validity associated with the use of synthetic tests, we downloaded 500K real test cases from multiple GitHub projects (without following any systematic approach, though). These experiences led us to realize it was time for us to create a curated dataset of test cases that could be used in our own research and shared with the community.

Potential applications

Beyond our own motivation, we consider JTeC could be used to the benefits of researchers in several areas, including:

• Static analysis: static analysis of test code has been applied for many purposes, including, for example, the identification of test smells [START_REF] Palomba | Automatic test smell detection using information retrieval techniques[END_REF], the study of test patterns [START_REF] Gonzalez | A largescale study on the usage of testing patterns that address maintainability attributes: patterns for ease of modification, diagnoses, and comprehension[END_REF], and recommendations for test code refactoring [START_REF] Van Deursen | Refactoring test code[END_REF][START_REF] Greiler | Automated detection of test fixture strategies and smells[END_REF]. JTeC can support such analyses by providing a ready-for-use large dataset of test classes.

• Regression testing: JTeC can be used as a benchmark to assess efficiency and scalability of regression techniques that use only test code as input, e.g., black-box similarity based techniques of our own recent work [START_REF] Miranda | FAST approaches to scalable similarity-based test case prioritization[END_REF][START_REF] Cruciani | Scalable approaches for test suite reduction[END_REF].

• Test case generation: within the ElasTest project [1], a recommender engine developed by the IBM partner uses machine learning techniques to generate new test cases based on the knowledge acquired by analyzing the existing ones [START_REF] Kacmajor | Say it in plain english[END_REF]. Supported by JTeC, similar studies can be applied from a perproject perspective, where the idea is to analyze the existing test cases to generate new ones for the same project, as well as for inter-project learning, where the idea would be to learn from multiple sources to generate new test cases to a target project.

Conclusions and future work

We have presented the JTeC dataset that makes ready available to the community of software testing researchers a large collection of Java test classes useful for several potential purposes related to test code analysis and processing. Our aim goes beyond the current version of the dataset: we strive towards the establishment of a continuously updated dataset, collecting together in a single source the test code belonging to the vast majority of test cases publicly available.

In the future the dataset can be expanded in several directions: as a first step, we intend to augment the test collection by including test code written in other programming languages. Such variation, which is relatively easy to implement (for example by using GHTorrent [START_REF] Gousios | The GHTorent dataset and tool suite[END_REF]) will allow the community to answer interesting research questions not applicable to a purely Java repository. For example, what are the characteristics of test cases written for projects with different size, complexity, development history, programming languages, etc? What are the common practices of developers/testers when writing test cases in a particular programming language?

Another important improvement we envisage is to compute and provide test related measurements with the test classes, for example code coverage information. Given the large scale, obtaining such information is clearly highly effort-intensive, and we consider that coarse criteria such as function coverage would be enough. Having this type of information could support benchmarking other regression testing techniques beyond black-box similarity-based ones.

Additionally, to broaden the capabilities of JTeC, we envision to include in future versions also fault information of the identified test classes. Providing this latter type of information, would enable researchers to have at disposal a large-scale real-world dataset containing the most important information related to test suites, enabling them to conduct a vast range of studies related to the research field of software testing.

As a final word, we of course welcome the maintenance support and more ideas for improvement coming from the community over which JTeC is now handed.

Figure 2 :Figure 3 :Figure 4 :

 234 Figure 2: Distribution of dates of considered commits

https://doi.org/10.5281/zenodo.3711509

https://github.com/JTeCDataset/JTeC

https://developer.github.com/v3

We purposely design this step to consider the default branch and the most recent commit of the repositories, as this will potentially lead to the identification of a higher number of test cases.


Mathieu Cunche

Valentin Savin

Vincent Roca

Ghassan Kraidy

Alexandre Soro

Jérôme Lacan

Low-rate coding using incremental redundancy for GLDPC codes

In this paper we propose a low-rate coding method, suited for application-layer forward error correction. Depending on channel conditions, the coding scheme we propose can switch from a fixed-rate LDPC code to various low-rate GLDPC codes. The source symbols are first encoded by using a staircase or triangular LDPC code. If additional symbols are needed, the encoder is then switched to the GLDPC mode and extra-repair symbols are produced, on demand. In order to ensure small overheads, we consider irregular distributions of extra-repair symbols optimized by density evolution techniques. We also show that increasing the number of extra-repair symbols improves the successful decoding probability, which becomes very close to 1 for sufficiently many extra-repair symbols.

I. INTRODUCTION

Forward Error Correction (FEC) codes are a key building block for many content distribution applications. FEC codes can operate at the physical layer (e.g. the LDPC codes of DVB-S2), just below IP (e.g. the MPE-FEC scheme of DVB-H), or within the transport or the application layers (e.g. within the IP-Datacasting service of DVB-H). In this paper we will focus on application-layer FEC codes, referred as AL-FEC. AL-FEC codes are complementary and not opposed to physical layer codes. There are two major differences between these two classes. A first difference is the block of data upon which FEC encoding is performed. With physical layer (respectively sub-IP) FEC codes, FEC encoding is performed on a sequence of bits (respectively IP datagrams). With AL-FEC codes, encoding is performed over the whole object (ideally by using a single block with the so-called "large block codes"). A second difference is the type of errors these codes will correct, or equivalently the channel type. With physical layer FEC codes, we are dealing with a channel that can alter the received content. With sub-IP and AL-FEC codes, we are dealing with erasure channels, i.e. a channel in which each data unit is either transmitted without error or entirely erased. Indeed, the potential physical layer CRC, or physical layer FEC codes, or even transport level UDP checksums, lead a receiver to discard erroneous data units.

For small to medium codeword lengths, Maximum-Distance Separable (MDS) codes are known to achieve the channel capacity. However, for large block lengths, their decoding becomes intractable and thus, iteratively decoded graph-based codes constitute the main alternative. Low-density paritycheck (LDPC) codes [START_REF] Gallager | Low Density Parity Check Codes[END_REF] [START_REF] Gallager | Low Density Parity Check Codes[END_REF] with iterative decoding [START_REF] Zyablov | Decoding complexity of low-density codes for transmission in a channel with erasures[END_REF] proved to perform very close to the channel capacity with reasonable decoding complexity [START_REF] Richardson | Design of capacity-approaching irregular low-density parity-check codes[END_REF] [START_REF] Luby | Efficient erasure correcting codes[END_REF]. LDPC codes were generalized by Tanner [START_REF] Tanner | A recursive approach to low complexity codes[END_REF] by introducing the sparse graph representation and replacing the Single Parity Check (SPC) constraint nodes with error correcting block codes. Nowadays, these codes are known as GLDPC codes and were recently investigated for different channels in [START_REF] Lentmaier | On generalized low-density paritycheck codes based on Hammingcomponent codes[END_REF][8] [START_REF] Hirst | Application of efficient Chase algorithm in decoding of generalized low-density parity-check codes[END_REF][10] [START_REF] Miladinovic | Generalized LDPC codes and generalized stopping sets[END_REF]. Moreover, "rateless" codes that are capable of generating an infinite sequence of repair symbols were proposed in [START_REF] Luby | LT codes[END_REF] [START_REF] Shokrollahi | Raptor codes[END_REF]. Patent-free LDPCstaircase and LDPC-triangle codes were proposed in [START_REF] Roca | Design, Evaluation and Comparison of Four Large Block FEC Codecs, LDPC, LDGM, LDGM Staircase and LDGM Triangle, plus a Reed-Solomon Small Block FEC Codec[END_REF] [START_REF] Roca | Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC)[END_REF]. In [START_REF] Cunche | Improving the Decoding of LDPC Codes for the Packet Erasure Channel with a Hybrid Zyablov Iterative Decoding/Gaussian Elimination Scheme[END_REF] it was shown that, decoded by a hybrid iterative-Gaussian elimination algorithm, these codes tightly approach the performance of an ideal MDS code on the binary erasure channel.

In this paper, we propose a coding scheme that can produce on-demand, extra-repair symbols, either to cope with bad channel conditions, or to be used with fountain-like content distribution applications, e.g. FLUTE/ALC. The coding scheme is based on a LDPC code, which can be extended to various low-rate GLDPC codes. The extra-repair symbols are produced in an incremental way by the GLDPC codes. We show that code optimization is possible, by varying the number of extra-repair symbols from one constraint node to another (irregular distribution).

The paper is organized as follows: in Section II we describe the coding scheme; in Section III we propose a code design exploiting the LDPC-staircase codes. We analyze the asymptotic behavior of the proposed coding scheme in Section IV. Then we provide a performance evaluation of these codes in Section V. Finally we conclude.

II. PROPOSED CODING SCHEME

Let H be a sparse binary matrix with M rows and N = K + M columns. We write

H = (H 1 | H 2 )
, where H 1 is the M × K left side of H, and H 2 is the M × M right side of H, and we further assume that H 2 is a staircase (double diagonal) or a lower-triangular matrix. The bipartite (Tanner) graph associated to H consists of M constraint nodes and N symbol nodes corresponding respectively to the rows and the columns of H. A symbol node n is connected to a constraint node m iff the corresponding element of H is equal to 1. In this case, we also say that symbol node n is participating in the constraint node m. The bitwise XOR sum of all the symbol nodes of a constraint node by definition is equal to zero. Note that symbols often represent packets (several byte long) rather than individual bits with AL-FEC codes.

We further consider a systematic Reed-Solomon (RS) or any MDS code over a finite field GF(2 p ). Each symbol of the finite field corresponds to a group of p bits, and the sum of two GFsymbols corresponds to the bitwise XOR. Let the parameters of the RS code be (k + 1 + E, k). Thus, k is the number of information symbols (the code dimension), k + 1 + E is the number of coded symbols (the code length), and the number of repair symbols that can be generated by the code is equal to 1 + E. Without losing generality, we may assume that the first repair symbol is the XOR sum of the k information symbols. Precisely, since the RS code is systematic, for any information symbols (x 1 , . . . , x k ), the repair symbols are computed as:

(y 1 , y 1,1 , . . . , y 1,E ) = (x 1 , . . . , x k )G ( 1
)
where G is a k × (1 + E) matrix with coefficients in GF(2 p ).

The first repair symbol y 1 is the XOR sum of the source symbols x 1 , . . . , x k iff all the coefficients on the first column of G are equal to 1. This can be obtained by multiplying G at the left by an appropriate invertible matrix, which will change the way the encoding is done but not the MDS property of the code.

For the clarity of the presentation, let us assume for the moment that each row of the matrix H has k + 1 coefficients equal to 1 (i.e. each constraint node is of degree k + 1). For a given sequence of source symbols s 1 , s 2 , . . . , s K , we can compute a sequence of repair symbols by "walking down the stairs", as follows:

• Consider the k + 1 symbol nodes participating in the constraint node corresponding to the first row of H. The first k symbol nodes represent information symbols. The (k + 1) th symbol (i.e., the coefficient 1 on the diagonal of H 2 ) is the XOR sum of the first k symbols. Then encode the sequence of the first k symbols using the systematic RS code, and let p 1 , p 1,1 , . . . , p 1,E be the output repair sequence. Note that p 1 is the value of the (k + 1) th symbol (they are both equal to the XOR sum of the k information symbols). Symbols p 1,1 , . . . , p 1,E are called extra-repair symbols, and they will not be used later in the encoding process.

• Consider the k + 1 symbol nodes participating in the constraint node corresponding to the second row of H. The first k symbol nodes represent either information symbols, or the above repair symbol p 1 . The (k + 1) th symbol (i.e., the coefficient 1 on the diagonal of H 2 ) is the XOR sum of the first k symbols. Then encode the sequence of the first k symbols using the systematic RS code, and let p 2 , p 2,1 , . . . , p 2,E be the output repair sequence. Note that p 2 is the value of the (k + 1) th symbol (they are both equal to the XOR sum of the k information symbols). Symbols p 2,1 , . . . , p 2,E are called extra-repair symbols, and they will not be used later in the encoding process.

• Continue the above encoding process until the last row of matrix H is reached. We note that the sequence s 1 , s 2 , . . . , s K , p 1 , . . . , p M is simply a codeword of the LDPC code with parity check matrix H.

The advantage of our approach consists in the availability of extra-repair symbols that turn this code into a small rate code. This code is therefore suitable for all the situations that benefit from low rate (or at the extreme rateless) codes, i.e. the possibility of generating infinite number of repair symbols. Moreover, the extra-repair symbols can be computed "just-intime", prior to being transmitted, rather than in advance.

It is also important to note that the assumption of constraint nodes being of constant degree k + 1 is not necessary. Indeed, in case of constraint nodes with various degrees, we can chose k such that the maximum constraint degree is equal to k + 1. Then, for a constraint node of degree k ′ + 1, with k ′ < k, we can use zero-padding in order to provide the systematic RS-encoder with a sequence of length k.

The LDPC code with parity matrix H will be called initial code, and its coding rate r = K/N will be called base coding rate. Let us assume that e(m) extra RS repair symbols are generated for the constraint node of row m, with 0 ≤ e(m) ≤ E and m = 1, . . . , M . Thus, the sequence:

s 1 , s 2 , . . . , s K , p 1 , p 1,1 , . . . , p 1,e(1) , . . . . . . , p M , p M,1 , . . . , p M,e(M) (2)
is the codeword of a GLDPC code. We call this latter the extended code. We note that the symbol nodes corresponding to extra RS repair symbols p m,i are all of degree 1 (in the bipartite graph associated with the extended code).

Let f e denote the fraction of constraint nodes with e extra RS repair symbols:

f e = card{m = 1, . . . , M | e(m) = e} M (3)
and f be the average number of extra RS repair symbols per constraint node:

f = E e=0 f e • e (4)
The coding rate r of the extended code can then be computed as:

r = K N + M f = r 1 + (1 -r) f (5)
For instance, if the initial code rate is r = 1/2 and the average number of extra RS repair symbols per constraint node is f = 6, we obtain an extended code with coding rate r = 1/8.

III. CODE DESIGN

This section focuses on the design of extended codes. The initial code are the LDPC-staircase codes described in [START_REF] Roca | Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC)[END_REF]. Thus, H = (H 1 | H 2 ), where each column of H 1 has 3 coefficients equal to 1, and H 2 is a staircase (double diagonal) matrix. We further assume that the degree of constraint nodes is constant (which is true with the coding rate considered). We consider a base coding rate r = 1/2. Thus the constraint nodes must be of degree 5 and then k = 4.

For the extended codes, we consider two kinds of extrarepair symbol distributions:

• regular (A.K.A. "skyscraper") distributions: f E = 1, and f e = 0 for e ∈ {0, 1, . . . , E -1}. Thus, each constraint node has the same number E of extra-repair symbols.

• uniform distributions: f e = 1/(E + 1), for e ∈ {0, 1, . . . , E}. The average number of extra-repair symbols is f = E/2. An irregular distribution is one for which the number of extra RS repair symbols varies from one constraint node to another. Thus, the uniform distribution is an irregular one. Obviously, additional irregular distributions can be considered, but we will show that the performance of the uniform distribution is very close to that of optimal irregular distributions. Another reason for considering these distributions is that they can be nested when E increases from 0 up to some maximum value. This allows for incremental redundancy, as explained below for the case of uniform distribution:

• Send the LDPC repair symbols. Set E = 0. Set E = E + 1. • . . . We will show in next section that the extended codes perform very close to the capacity if the number of extrarepair symbols is sufficiently large. This property ensures that by sending a sufficient number of extra-repair symbols, the erased source symbols will be successfully recovered with probability 1.

IV. DENSITY EVOLUTION

In this section we use a density evolution approach [START_REF] Storn | Differential evolution: a simple and efficient adaptive scheme for global optimization over continuous spaces[END_REF] in order to optimize the extra-symbols distribution f for a given base matrix H and target extended rate r. The iterative decoding of the extended codes is similar to the one of the base LDPC code, the only exception being that each constraint node m can recover from e(m) + 1 erased symbols. It is important to note that the extra RS repair symbols provide information to a single constraint node, the one they participate in, and they cannot relay any information during the iterative decoding itself. Moreover, once all the source symbols of a constraint node have been decoded, there is no need to decode the extrarepair symbols since they no longer have any utility.

The degree of a constraint node will always be considered with respect to the base LDPC code (i.e. we omit the extrarepair symbols). The maximum constraint node degree is denoted by d c and the maximum (base) symbol node degree by d s . As usual, we denote by λ and ρ the degree distribution polynomials of respectively symbol and constraint nodes of the base LDPC code: We also note:

• λ d is
• P ℓ , the probability of a LDPC symbol node sending an erasure at iteration ℓ • Q ℓ , the probability of a constraint node sending an erasure at iteration ℓ Thus P 0 is just the channel erasure probability, since we assume that each symbol is either received or completely erased.

Consider a constraint node m of degree k + 1, and let e(m) = e be the number of extra RS repair symbols of m. Let n, n 1 , . . . , n k , t 1 , . . . t e be the symbols participating in m, the first k + 1 of which are LDPC repair symbols (source and repair), while the last e represent extra RS repair symbols. The constraint node m can recover the value of the LDPC symbol n if and only if the number or erasures in the sequence n 1 , . . . , n k , t 1 , . . . t e is less than or equal to e. At iteration ℓ, the LDPC repair symbols are erased with probability P ℓ , while extra RS repair symbols are always erased with probability P 0 , the channel erasure probability. It follows that the probability of the constraint node m recovering the value of a LDPC symbol n at iteration ℓ + 1, denoted by Qℓ+1 (k, e), can be computed as:

Qℓ+1 (k, e) = 0≤i≤k,0≤j≤e i+j≤e k i P i ℓ (1 -P ℓ ) k-i e j P j 0 (1 -P 0 ) e-j
(6) Hence, the probability of the constraint node m sending an erasure to a LDPC symbol n at iteration ℓ+1 is (1-Qℓ+1 (k, e)), and averaging over all possible values of k and e, we get:

Q ℓ+1 = 1 - dc-1 k=0 ρ k+1 E e=0 f e Qℓ+1 (k, e) (7)
Conversely, a LDPC symbol node n of degree d, participating in constraint nodes m, m 1 , . . . , m d-1 , sends an erasure to the constraint node m iff it was erased by the channel, and it received erased messages from all constraint nodes m 1 , . . . , m d-1 . Since this happens with probability

P 0 • Q d-1
ℓ+1 , and averaging over all possible degrees d, we get:

P ℓ+1 = P 0 ds d=1 λ d Q d-1 ℓ+1 = P 0 λ(Q ℓ+1 ) (8)
Thus, we can track the erasure probability P ℓ at each iteration l ≥ 0 using equations ( 6), ( 7), [START_REF] Boutros | Generalized low density (Tanner) codes[END_REF], and the decoder can recover from a fraction of P 0 erased symbols iff lim ℓ→+∞ P l = 0.

The threshold probability P th is defined by:

P th = max{P 0 | lim ℓ→+∞ P l = 0} (9)
and the gap to capacity is:

∆ = 1 -r -P th . ( 10
)
where r is the coding rate of the extended code. The decoding inefficiency is defined as the ratio between the number of symbols needed for decoding and the number of source symbols. The threshold inefficiency may be computed by:

µ th = 1 -P th r = 1 -P th r (1 + (1 -r) f ) (11)
where r is the initial code rate. Theoretical performances of the regular and the uniform distributions are shown in terms of inefficiency threshold and gap to capacity in Fig. 1 and Fig. 2. The bottom horizontal axis shows the average number of extra RS repair symbols per row ( f ), while the top axis gives the corresponding extended code rate (r). The inefficiency of the initial code (without extrarepair symbols) is µ = 1.1023. By increasing the number of extra-repair symbols, the extended code rate decreases down to 0.059, while the inefficiency increases up to 1.1604 for regular distributions and up to 1.1205 for uniform distributions, which is only at 2% from the initial code inefficiency. It is important to note that the decoding inefficiency is biased by the coding rate. In fact, from Fig. 2, we see that the gap to capacity, i.e. distance between extended-codes and ideal codes, decreases down to 0.0071 when the average number of extra RS repair symbols becomes equal to 15. We note that it is possible to optimize the extra-repair symbol distribution f , by optimizing the function that associates to f the corresponding gap to capacity using the differential evolution algorithm [START_REF] Storn | Differential evolution: a simple and efficient adaptive scheme for global optimization over continuous spaces[END_REF]. We have performed this optimization for different average number of extra-repair symbols f . For each f , the performance of the optimized distribution was only insignificantly better than the one of the uniform distribution. For instance, for f = 3 the gap to capacity of the optimized distribution was 0.0213 (instead of 0.0219 for the uniform distribution), and for f = 10 the gap to capacity of the optimized distribution was 0.0092 (instead of 0.0099 for the uniform distribution). Thus, we think that the uniform distribution is the best choice, since it also allows for incremental redundancy as explained in Section III. The table bellow gives an example of irregular distribution, with f = 3, obtained after 100 iterations of the differential evolution algorithm.

V. SIMULATION RESULTS

We performed Monte-Carlo simulations for both the regular and uniform distributions with various K values. Performance in terms of average inefficiency is shown in Fig. 3 for the regular and in Fig. 4 for the uniform distribution. Fig. 5 shows the gap to capacity of the uniform distribution for various K values. These tests confirm the good performance of extended GLDPC codes using a uniform distribution while generating extra-repair symbols.

VI. CONCLUSIONS

In this paper we proposed a coding scheme than can produce incremental redundancy in order to cope with bad channel conditions or with fountain like content distribution applications (e.g. FLUTE/ALC). The coding scheme is based on a LDPC-Staircase code, and extra-repair symbols are produced ondemand by extending the initial code to a GLDPC code. Performances of various extra-repair symbols distributions were considered. Tests have showed that the uniform distribution performs very close to optimized distributions, while easily allowing for incremental redundancy. We also showed that, by increasing the number of extra-repair symbols, the extended codes approach the performance of ideal maximum-distanceseparable codes. Our proposal can therefore be used to build efficient small-rate, large block AL-FEC codes. Moreover, it is very likely that the gap between our extended codes and ideal codes can be tighten by using a hybrid iterative-maximum likelihood decoding.

  the fraction of edges connected to LDPC symbol nodes of degree d, and λ(X) = ds d=1 λ d X d-1 • ρ d is the fraction of edges connected to constraint nodes of degree d, and ρ(X) = dc d=1 ρ d X d-1

Fig. 1 .

 1 Fig. 1. Inefficiency threshold as a function of the average number of extrarepair symbols per row.

  0.0511 0.0047 0.2446 0.1614 0.2405 0.0595 3 0.0213

Fig. 4 .Fig. 5 .

 45 Fig. 4. Simulated average inefficiency as a function of the average number of extra-symbols per row, uniform distribution case.

  Simulated average inefficiency as a function of the average number of extra-symbols per row, regular distribution case.

								Expanded code rate
		0.500 0.333 0.250 0.200 0.167 0.143 0.125 0.111 0.100 0.091 0.083 0.077 0.071 0.067 0.063 0.059
		1.2
		1.18
	ave (average inefficiency)	1.14 1.16
	µ
		1.12
														DE threshold
														k = 1000
		1.1												K = 5000 K = 10000
														K = 50000
		0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
						f -	(average number of extra-symbols per row)
	1.12 1.14 1.16 1.18 1.2 0.500 0.333 0.250 0.200 0.167 0.143 0.125 0.111 0.100 0.091 0.083 0.077 0.071 0.067 0.063 0.059 Expanded code rate DE threshold K = 1000 K = 5000 Fig. 3. 1.1 µ ave (average inefficiency) K = 10000
														K = 50000
		0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
						f -	(average number of extra-symbols per row)


Emilio Cruciani

Hlafo Alfie Mimun

Matteo Quattropani

Sara Rizzo

Brief Announcement: Phase Transitions of the k-Majority Dynamics in a Biased Communication Model

We analyze the binary-state (either R or B) k-majority dynamics in a biased communication model where nodes have some fixed probability p, independent of the dynamics, of being seen in state B by their neighbors. In this setting we study how p, as well as the initial unbalance between the two states, impact on the speed of convergence of the process, identifying sharp phase transitions.

Introduction

Designing distributed algorithms that let the nodes of a graph reach a consensus, i.e., a configuration of states where all the nodes agree on the same state, is a fundamental problem in distributed computing and multi-agent systems. Consensus algorithms are used in protocols for other tasks, such as leader election and atomic broadcast, and in real-world applications such as clock synchronization tasks and blockchains.

Recently there has been a growing interest in the analysis of simple local dynamics as distributed algorithms for the consensus problem [START_REF] Cooper | Coalescing random walks and voting on connected graphs[END_REF][START_REF] Ghaffari | Nearly-tight analysis for 2-choice and 3-majority consensus dynamics[END_REF], inspired by simple mechanisms studied in statistical mechanics for interacting particle systems. In this scenario, nodes are anonymous (i.e., they do not have distinct IDs) and they have a state that evolves over time according to some common local interaction with their neighbors. Many dynamics have been investigated in such a setting, for example voter, where nodes copy the state of a random neighbor, and 3-majority, where nodes sample 3 neighbors with replacement and update their states to the most frequent among the samples. The time needed by such dynamics to reach a consensus is very different: for example, on the complete graph, voter needs Ω(n) rounds, while 3-majority converges in O(log n) [START_REF] Cooper | Coalescing random walks and voting on connected graphs[END_REF][START_REF] Ghaffari | Nearly-tight analysis for 2-choice and 3-majority consensus dynamics[END_REF].

Communication Model

We focus on the scenario where each of the n nodes of the underlying communication graph G has a binary state (either R or B) and the communication among the nodes proceeds in synchronous rounds. In this setting we analyze the k-majority dynamics, where nodes sample k neighbors from their neighborhood uniformly at random and with replacement, and then update their state to the majority of the sample; ties are broken uniformly at random.

Differently from most of the previous works, we consider a communication model which is biased, w.l.o.g., toward state B, i.e., whenever nodes sample a neighbor they see state B with some probability p, regardless of the state of the sampled node, and its true state with probability 1 -p. This biased communication model has been introduced in [START_REF] Cruciani | Phase transition of the 2-choices dynamics on core-periphery networks[END_REF], where it is used as a tool for the analysis of the 2-choices dynamics on core-periphery networks.

Results

Most of the previous works rely on strong topological assumptions, e.g., considering complete graphs or expanders, to prove upper bounds on the consensus time of the dynamics. We move a step forward in this direction by removing all assumptions that depend on the topology of the graph; indeed we only require the underlying communication graph to be sufficiently dense, i.e., with minimum degree ω(log n). Such a milder assumption, though, comes at the cost of a weaker notion of consensus, that we call almost-consensus. Pushing our techniques to their limit, we could prove a consensus on state B in O(log n) rounds. We would still require no topological assumptions, but just a stronger condition on the minimum degree (from ω(log n) to Ω(n)), thus dramatically restricting the class of graphs taken into account to extremely dense ones. Note that, in the biased communication model we consider, the Markov Chain that models the process has a single absorbing state where all nodes are in state B. For this reason we first consider an initial configuration where all the nodes are in state R and study the time needed by the process to reach a Balmost-consensus. Trivially, if p = 0 the process remains stuck in its initial configuration, while if p = 1 the process reaches the absorbing state in one single round. More in general, it is intuitive that the process will converge slowly to the absorbing state if p is small and quickly if p is large. With such an intuition in mind, we prove a first phase transition phenomenon. Theorem 1. Consider the k-majority dynamics in the communication model with bias p toward state B, in any graph G with minimum degree ω(log n), and where initially all nodes are in state R. For every k ≥ 3 there exists a constant p k ∈ [1 9 , 1 2 ] such that:

• Slow convergence: If p < p k , a B-almost-consensus is reached in n ω(1) rounds, a.a.s. 1 • Fast convergence: If p > p k , a B-almost-consensus is reached in O(1) rounds, a.a.s.
The proof looks at the expected evolution of the fraction of neighbors in state B of every node and then applies concentration of probability arguments, akin to what has been done in [START_REF] Cruciani | Phase transition of the 2-choices dynamics on core-periphery networks[END_REF]. However, compared to [START_REF] Cruciani | Phase transition of the 2-choices dynamics on core-periphery networks[END_REF], we have a more comprehensive scenario (k-majority for any k vs. 2-choices) with substantially more precise results.

Another important innovation with respect to [START_REF] Cruciani | Phase transition of the 2-choices dynamics on core-periphery networks[END_REF] is the presence of a second phase transition on the initial unbalance between the states. Clearly in the fast convergence regime, i.e., when p > p k , the initial configuration in which none of the nodes is in state B is the hardest one for the process to reach a Balmost-consensus. However, the scenario changes in the slow convergence regime, where a different initial configuration with some of the nodes already in state B could speed up the process. Theorem 2. Consider the k-majority dynamics in the communication model with bias p < p k toward state B, in any graph G with minimum degree ω(log n), and where initially every node is in state B with probability 1 -q, independently of the others. For every k ≥ 3 there exists a constant q p,k such that:

• Fast convergence: If q < q p,k , a B-almost-consensus is reached in O(1) rounds, a.a.s.

• Slow convergence: If q > q p,k , a B-almost-consensus is reached in n ω(1) rounds, a.a.s.

Applications

Our results show that adding a bias to k-majority affects the dynamics in a non-trivial way. In particular, the arise of a metastable phase makes the framework suitable to design distributed algorithms to recover planted partitions in networks [START_REF] Becchetti | Step-by-step community detection in volume-regular graphs[END_REF][START_REF] Cruciani | Distributed community detection via metastability of the 2-choices dynamics[END_REF][START_REF] Shimizu | Phase transitions of best-of-two and best-of-three on stochastic block models[END_REF]. Consider a graph G = ((V 1 , V 2 ), E) with two clusters and such that, for every pair of nodes in each cluster, their fraction of neighborhood toward the other cluster is equal to some constant z, as in [START_REF] Becchetti | Step-by-step community detection in volume-regular graphs[END_REF]. Let G run the k-majority and suppose that the two clusters reach a local almost-consensus on different states, say nodes in V 1 agrees on R and nodes in V 2 on B. The evolution of such a process can be described by the biased k-majority dynamics. In fact, note that the k-majority dynamics with bias p = z toward B performed by the nodes of the subgraph induced by V 1 describes the local evolution of the nodes in V 1 , when considering a worst-case scenario in which the nodes in V 2 never change color. If G is such that z = p < p k , Theorem 1 implies that V 1 remains in an almost-consensus configuration, a.a.s. Since the same reasoning can be done for V 2 , it follows that the graph would stay in a configuration that highlights its clustered structure for n ω (1) rounds, hence making k-majority a suitable dynamics for the design a distributed community detection protocol.

Definition 1 .

 1 A process reaches an B-almost-consensus whenever a fraction 1 -o(1) of the volume of the graph is in state B.

We say that an event En happens asymptotically almost surely (in short, a.a.s.) if Pr(En) = 1 -o(1).


H Yousefi-Mashouf

L Bailly

L Orgéas

N Henrich Bernardoni

S Rolland Du Roscoat

Mechanical characterization of gelatinbased hydrogels upon finite strains in tension, compression and shear

Introduction

Hydrogels are attractive biomaterials used in a wide range of biomedical applications, such as scaffolds for cell culture in tissue engineering, biomimetic models for human tissues, and carriers in drug delivery. Hydrogels consist of hydrophilic polymeric 3D networks, able to retain high tissue-like water content without dissolution. Among the biopolymers used to process hydrogels, gelatin is very common due to its cost-effectiveness, ease of manufacturing and ability to form thermo-reversible gels [1,2]. The poor mechanical performances of standard gelatin-based hydrogels (e.g. low elastic modulus, low ultimate elongation, brittle failure) are known to be tunable and enhanced with additional physical and/or chemical crosslinking in the gels [2,3].

A proper and complete characterization of the mechanical behavior of these hydrogels is critical to evaluate the relevance of their utility for biomedical applications. However, corresponding experimental studies are often limited either to one specific loading mode (mainly compression or shear) with a single quasi-static monotonic path up to failure, or to standard infinitesimal strain DMA analyses [2][3][4]. These configurations are usually far from those endured in vivo by native tissues which are subjected to numerous complex and coupled mechanical loading upon finite strains and various strain rates. In this work, we propose a procedure to characterize and to highlight the role of the finite strain mechanical loading (tensions, compressions and shear) on the mechanical behavior of gelatin-based hydrogels.

Experimental Methods

Dry porcine gelatin (gel strength ≈ 300 g Bloom, Type A, Sigma-Aldrich®) was used to produce a series of hydrogels, mixing the powder in ultrapure water (18.2 MΩ) for 30 min at 45°C. The prepared aqueous solutions were casted into a Teflon® mold at room temperature for 1 h, and kept at 3 °C for 24 h to form a rectangular gel plate (100 × 100 × 5 mm 3 ). Two parameters were varied during the processing route: (i) the gelatin concentration in the aqueous solutions, i.e., 5, 10 and 15 %w/v [1,3]; (ii) the use of a crosslinking reagent (0.5 wt% of glutaraldehyde (GA), Sigma-Aldrich®). Samples were cut from the plates at a length-to-width ratio ranging from 5:1 to 1:5, and coated with a random pattern made of small speckles. Mechanical tests were carried out using a standard uniaxial machine (Instron® 5944) equipped with a ±10 N load cell. Five loading modes were studied: simple tension, plain strain tension (pure shear), simple and plain strain compressions and simple shear [5]. Whatever the loading mode, samples were subjected to cyclic loadings with increasing strain amplitude up to the ultimate elongation. Pictures of the deformed sample in frontal and lateral views were recorded using two high-resolution CCD cameras (JAI® BM-500GE, 5 MPixels), to quantify its dimensional changes and to allow digital image correlation for the measurement of local strain field (7D software [6]). For each loading case, two parameters were varied during the protocol: (i) the strain rates, ranging from 10 -3 s -1 to 10 1 s -1

; (ii) the surrounding hygrometric conditions, regulated at ambient or saturated (RH 100%) atmosphere.

Results and Discussion

To illustrate some of our results, we have plotted in Figure 1 stress-strain curves showing the typical cyclic mechanical behavior at a cross head speed of 0.05 mm.s -1 of the processed hydrogels in simple tension and compression (here with gelatin 10% w/v, no chemical crosslinking). The figure clearly emphasizes the impact of the mechanical loading on the behavior of the hydrogels: weak hysteresis and weak residual strain in tension, these two features being pronounced in compression where, in addition, stress levels being much higher than those recorded in tension. In addition, the figure highlights the strong impact of the sample air-drying on stress-strain curves: the higher the resting time, the higher the stress levels.

Conclusion

The results of this work will help to clarify the mechanical protocols and specially the loading modes to be considered for the biomimetic design of new homogeneous materials. This knowledge is expected prior to develop any suitable fibre-reinforced biocomposites, able to mimic the histological and biomechanical features of native tissues.