Head office: 39 rue Paul Claudel, 91000 EVRY, France - www.amarisoft.com
S howroom: 105 rue Anatole France, 92300 LEVALLOIS PERRET, France

SAS with a capital of 300,000 Euros - VAT FR 21 753 998 269 - SIRET 753 998 269 00025 R.C.S EVRY - NAF 6201Z DUNS 264482426



Rapport d’avancement

Période technique n°1
décembre 2017


_____________


Projet OSTV

Appel à projets grands défis du numérique

n° P143528-3924174/DOS0045152/00-DOS0045153/00




Tableaux de synthèse 5

Jalons décisionnels 5

Planning prévisionnel général initial 7

Répartition prévisionnelle initiale des efforts et du budget 8

Par partenaire 8

Par tâche/jalon 8

Echéancier administratif global du projet 9

Présentation détaillée de l’ensemble des livrables associés aux travaux prévus dans l’Annexe technique 13

WP0 - Gestion de projet 13

WP1 - Pilote Mayotte centralise 13

Déploiement eNodeB en France 14

Déploiement eNodeB Mayotte 15

Déploiement 7 eNodeB Mayotte 15

Extensions fonctionnelles du réseau 17

Développement extensions eNodeB 18

Tour de télécommunication 18

RuggedPOD Outdoor 19

Open Telecom Tower POC 21

Open Telecom Power Solar 22

Open Telecom Power Wind 22

Open Telecom Power Wind (maintenance) 23

WP2 - Prototype décentralisé 23

4G/5G Mesh 24

4G/5G Mesh POC 24

4G/5G Mesh Peer 25

4G/5G Mesh Standardization 26

Core Network décentralisé 26

Profil SlapOS 2G 26

Accès internet réparti 27

Portail inscription et facturation 29

Profil SlapOS LTE 29

Optimisation des routes pour la voix 30

Mise aux enchères et refacturation 30

Intégration mesh 4G/5G 30

Redirection de session voix 31

Facturation répartie temps réel 31

RRH Ethernet 32

Prototype RRH Ethernet 32

Batch de test 35

Normalisation RRH Ethernet 35

WP3 - Pilote Mayotte décentralisé 36

Accès LTE individuel 36

Test et intégration système 36

Test et intégration core network 37

Adaptations eNodeB 38

Accès LTE individuels multiples 38

Test et intégration système 38

Test et intégration core network 39

Adaptations eNodeB 40

Jalons 40

1. Pilote France 1 antenne 40

2. Pilote Mayotte 1 antenne 40

3. Pilote Mayotte 7 antennes 40

4. Liaison data mesh entre 2 eNodeB 41

5. OSTV Cloud v1 41

6. OSTV Node v1 41

7. Interface mesh layer 2 41

8. OSTV Cloud v2 41

9. OSTV Node v2 42

10. RRH Ethernet 42

11. Norme mesh 5G 42

12. Norme service based routing babel 42

13. Norme RRH Ethernet 43

14. POC Tour Télécom 43

15. Tour Télécom auto-alimentée 43

Etat des dépenses 44





Tableaux de synthèse


Jalons décisionnels

Jalon

Responsable

Date de réalisation indiquée dans l’Annexe technique

Commentaires et date de réalisation

1

Pilote France 1 antenne

BJT

2017-01-01

Le site St Pierre et Miquelon permet de valider ce jalon.

2

Pilote Mayotte 1 antenne

BJT

2017-04-01

Fait depuis le 1er novembre 2017

3

Pilote Mayotte 7 antennes

BJT

2017-10-01

Ce déploiement a pris du retard du fait du décalage du versement de la BPI, des fréquences radioélectriques allouées qui nécessitent un travail d'adaptation pour AW2S et de la volonté d'améliorer le POD afin de l'adapter aux contraintes du terrain.

Parallèlement, l’entrée dans la saison des pluies (décembre à mars/avril) à Mayotte rend les points hauts inaccessibles aux engins nécessaires à l’aménagement des sites. Il nous faudra donc attendre que les chemins d’accès aux sites sèchent afin de reprendre les travaux.

Ainsi, compte tenu des contraintes terrain et matériel, ce jalon pourra être réalisé fin juillet 2018.

4

Liaison data mesh entre 2 eNodeB

Amarisoft

2017-10-01

Réalisation d’un PoC en cours

5

OSTV Cloud v1

Nexedi

2017-10-01

Réalisation en cours, première présentation réalisée fin décembre 2017.

6

OSTV Node v1

Nexedi

2017-10-01

Fait

7

Interface mesh layer 2

Amarisoft

2018-10-01


8

OSTV Cloud v2

Nexedi

2018-10-01


9

OSTV Node v2

Nexedi

2018-10-01


10

RRH Ethernet

AW2S

2018-10-01


11

Norme mesh 5G

Amarisoft

2019-10-01


12

Norme service based routing babel

Paris 7

2019-10-01


13

Norme RRH Ethernet

AW2S

2019-10-01



Planning prévisionnel général initial



Répartition prévisionnelle initiale des efforts et du budget

Par partenaire



Par tâche/jalon

Référence

Titre

Date d'expédition

Date de livraison

Total Service

SO-OSTV

Unité

10/2016

10/2016

Day

SO-OSTV

Quantité totale

10/2016

10/2016

9450

SO-OSTV-10

WP0 - Gestion de projet

10/2016

09/2019

150

SO-OSTV-20

WP1 - Pilote Mayotte centralisé

10/2016

09/2019

2300

SO-OSTV-20-10

Déploiement eNodeB en France

10/2016

12/2016

100

SO-OSTV-20-20

Déploiement eNodeB Mayotte

01/2017

03/2017

150

SO-OSTV-20-30

Déploiement 7 eNodeB Mayotte

04/2017

09/2017

400

SO-OSTV-20-40

Extensions fonctionnelles du réseau

10/2017

09/2018

400

SO-OSTV-20-100

Développement extensions eNodeB

10/2016

09/2018

50

SO-OSTV-20-200

Tour de télécommunication

10/2016

09/2019

1200

SO-OSTV-20-200-10

RuggedPOD Outdoor

10/2016

09/2017

200

SO-OSTV-20-200-20

Open Telecom Tower POC

10/2016

09/2017

200

SO-OSTV-20-200-30

Open Telecom Power Solar

10/2017

09/2018

200

SO-OSTV-20-200-40

Open Telecom Power Wind

10/2017

09/2018

200

SO-OSTV-20-200-50

Open Telecom Power Wind (maintenance)

10/2018

09/2019

400

SO-OSTV-30

WP2 - Prototype décentralisé

10/2016

09/2019

6100

SO-OSTV-30-10

4G/5G Mesh

10/2016

09/2019

1800

SO-OSTV-30-10-10

4G/5G Mesh POC

10/2016

09/2017

600

SO-OSTV-30-10-20

4G/5G Mesh Peer

10/2017

09/2018

600

SO-OSTV-30-10-30

4G/5G Mesh Standardization

10/2018

09/2019

600

SO-OSTV-30-20

Core Network décentralisé

10/2016

09/2019

2800

SO-OSTV-30-20-10

Profil SlapOS 2G

10/2016

09/2019

400

SO-OSTV-30-20-20

Accès internet réparti

10/2016

09/2019

400

SO-OSTV-30-20-30

Portail inscription et facturation

10/2016

09/2019

200

SO-OSTV-30-20-110

Profil SlapOS LTE

10/2017

09/2018

200

SO-OSTV-30-20-120

Optimisation des routes pour la voix

10/2017

09/2018

400

SO-OSTV-30-20-130

Mise aux enchères et refacturation

10/2017

09/2018

200

SO-OSTV-30-20-210

Intégration mesh 4G/5G

10/2018

09/2019

400

SO-OSTV-30-20-220

Redirection de session voix

10/2018

09/2019

400

SO-OSTV-30-20-230

Facturation répartie temps réel

10/2018

09/2019

200

SO-OSTV-30-30

RRH Ethernet

10/2016

09/2019

1500

SO-OSTV-30-30-10

Prototype RRH Ethernet

10/2016

09/2017

500

SO-OSTV-30-30-20

Batch de test

10/2017

09/2018

600

SO-OSTV-30-30-30

Normalisation RRH Ethernet

10/2018

09/2019

400

SO-OSTV-40

WP3 - Pilote Mayotte décentralisé

10/2017

09/2019

900

SO-OSTV-40-10

Accès LTE individuel

10/2017

09/2019

500

SO-OSTV-40-10-10

Test et intégration système

10/2017

09/2018

100

SO-OSTV-40-10-20

Test et intégration core network

10/2017

09/2018

300

SO-OSTV-40-10-30

Adaptations eNodeB

10/2017

09/2018

100

SO-OSTV-40-20

Accès LTE individuels multiples

10/2018

09/2019

400

SO-OSTV-40-20-10

Test et intégration système

10/2018

09/2019

100

SO-OSTV-40-20-20

Test et intégration core network

10/2018

09/2019

200

SO-OSTV-40-20-30

Adaptations eNodeB

10/2018

09/2019

100


Echéancier administratif global du projet

Échéance

Intitulé

Réf.

Description / TO DO

01/10/2016

Date de commencement du projet OSTV

art 6 CP*

Début des travaux

17/02/2017

Retour de la convention Amarisoft-BPI signée

30/03/2017

Indicateur spécifique

art 13 CP

- Liste actualisée des opérations de fusion ou acquisition réalisées
- Chiffre d'affaires global au cours de l'exercice précédent et celui lié au projet OSTV

14/04/2017

Avance à notification

art 7.2a CG*
art 10.1 CP

Versement automatique de l'avance à notification (352 288 €)

30/09/2017

Période technique n°1

art 8.2 CP

Fin de la période technique n°1

19/10/2017

Réunion d'avancement


Réunion intermédiaire des partenaires ; point sur la période technique n°1

20/11/2017

Réunion d'avancement


Réunion intermédiaire des partenaires ; point sur la période technique n°1 et préparation de la réunion d'avancement

15/12/2017

Réunion d'avancement

art 6.5 CG

Documents à transmettre 15 jours avant la réunion :
- Rapport d'avancement
- Rapport écrit listant l'ensemble des livrables associés aux travaux prévus dans l'annexe technique
- Présentation synthétique de l'ensemble des livrables (démonstrateurs et logiciels)
- Accord de partenariat signé
- Etat de réalisation des Objectifs Techniques Principaux (OTP)

30/12/2017

Jalon décisionnel

art 8.3 CP

Pilote comportant 7 antennes à Mayotte

30/12/2017

Réunion d'avancement

art 6.3 CG

- Point sur les travaux réalisés en cours de période
- Organisée par Amarisoft en accord avec le MEIN/DGE/SEN/Bureau du logiciel qui la préside

30/03/2018

Demande de versement intermédiaire

art 7.2b CG

Adresser demande avec les documents suivants :
- Etat des dépenses portant sur la période de suivi technique 2017 établi selon le modèle

30/03/2018

Indicateur spécifique

art 13 CP

- Liste actualisée des opérations de fusion ou acquisition réalisées
- Chiffre d'affaires global au cours de l'exercice précédent et celui lié au projet OSTV

30/09/2018

Période technique n°2

art 8.2 CP

Fin de la période technique n°2

15/12/2018

Réunion d'avancement

art 6.5 CG

Documents à transmettre 15 jours avant la réunion :
- Rapport d'avancement
- Rapport écrit listant l'ensemble des livrables associés aux travaux prévus dans l'annexe technique
- Présentation synthétique de l'ensemble des livrables (démonstrateurs et logiciels)
- Etat de réalisation des Objectifs Techniques Principaux (OTP)

30/12/2018

Réunion d'avancement

art 6.3 CG

- Point sur les travaux réalisés en cours de période
- Organisée par Amarisoft en accord avec le MEIN/DGE/SEN/Bureau du logiciel qui la préside

30/03/2019

Demande de versement intermédiaire

art 7.2b CG

Adresser demande avec les documents suivants :
- Etat des dépenses portant sur la période de suivi technique 2018 établi selon le modèle

30/03/2019

Indicateur spécifique

art 13 CP

- Liste actualisée des opérations de fusion ou acquisition réalisées
- Chiffre d'affaires global au cours de l'exercice précédent et celui lié au projet OSTV

30/09/2019

Date d'achèvement du projet OSTV

art 6 CP

- Fin des travaux

30/09/2019

Période technique n°3

art 8.2 CP

Fin de la période technique n°3

15/12/2019

Réunion d'avancement

art 6.5 CG

Documents à transmettre 15 jours avant la réunion :
- Rapport final
- Rapport écrit listant l'ensemble des livrables associés aux travaux prévus dans l'annexe technique
- Etat de réalisation des Objectifs Techniques Principaux (OTP)
- Présentation synthétique de l'ensemble des livrables (démonstrateurs et logiciels)

30/12/2019

Réunion d'avancement

art 6.3 CG

- Point sur les travaux réalisés en cours de période
- Organisée par Amarisoft en accord avec le MEIN/DGE/SEN/Bureau du logiciel qui la préside

30/03/2020

Demande de versement intermédiaire

art 7.2b CG

Adresser demande avec les documents suivants :
- Etat des dépenses portant sur la période de suivi technique 2019 établie selon le modèle

30/03/2020

Indicateur spécifique

art 13 CP
art 11.2 CP

- Liste actualisée des opérations de fusion ou acquisition réalisées
- Chiffre d'affaires global au cours de l'exercice précédent et celui lié au projet OSTV
- Relevé d'exploitation commerciale selon le modèle établi
- Attestation par un auditeur

30/09/2020

Demande de versement du solde

art 7.2c CG

Adresser demande avec les documents suivants :
- Etat récapitulatif des dépenses depuis la date de commencement établi selon le modèle
- Attestation par un auditeur
- Document précisant la qualité de PME du titulaire
- Etat récapitulatif de l'ensemble des aides publiques obtenues par le titulaire

30/03/2021

Indicateur spécifique

art 13 CP
art 11.2 CP

- Liste actualisée des opérations de fusion ou acquisition réalisées
- Chiffre d'affaires global au cours de l'exercice précédent et celui lié au projet OSTV
- Relevé d'exploitation commerciale selon le modèle établi
- Attestation par un auditeur

30/09/2021

Remboursement de l'avance récupérable R&D

art 11.2 CP

Première échéance de 117 429 € à rembourser à BPIFrance

30/03/2022

Indicateur spécifique

art 11.2 CP

- Relevé d'exploitation commerciale selon le modèle établi
- Attestation par un auditeur

30/09/2022

Remboursement de l'avance récupérable R&D

art 11.2 CP

Deuxième échéance de 117 429 € à rembourser à BPIFrance

30/03/2023

Indicateur spécifique

art 11.2 CP

- Relevé d'exploitation commerciale selon le modèle établi
- Attestation par un auditeur

30/09/2023

Remboursement de l'avance récupérable R&D

art 11.2 CP

Troisième échéance de 176 144 € à rembourser à BPIFrance

30/03/2024

Indicateur spécifique

art 11.2 CP

- Relevé d'exploitation commerciale selon le modèle établi
- Attestation par un auditeur

30/09/2024

Remboursement de l'avance récupérable R&D

art 11.2 CP

Quatrième et dernière échance de 206 316 € à rembourser à BPIFrance

30/03/2025

Indicateur spécifique

art 11.2 CP

- Relevé d'exploitation commerciale selon le modèle établi
- Attestation par un auditeur



Présentation détaillée de l’ensemble des livrables associés aux travaux prévus dans l’Annexe technique


Nous présentons dans cette partie la liste détaillée des tâches affectées à chaque partenaire.

Les durées de chaque tâche et livrable sont calculées en jour-homme.

L’état d’avancement de chaque tâche et livrable est indiqué en pourcentage.


WP0 - Gestion de projet

ID : SO-OSTV-10

Début : 01/10/2016 Fin : 30/09/2019

Temps : 150.0

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Le sous-projet WP0 vise à produire les états financiers et administratifs du projet. Il s'agit notamment des rapports annuels, des réunions annuelles de suivi et de la gestion des relations avec BPI France.


WP1 - Pilote Mayotte centralise

ID : SO-OSTV-20

Début : 01/10/2016 Fin : 30/09/2019

Temps :

Leader : Nexedi Ressource : Amarisoft, BJT, SDS Location : Amarisoft, BJT, SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Le sous-projet WP1 se concentre sur le pilote de Mayotte en mode centralisé. Il est piloté par BJT Partners avec la participation des tous les partenaires. Il utilise un cœur de réseau centralisé afin de limiter le nombre de problèmes à résoudre simultanément. On y trouve donc le logiciel de base station (Amarisoft), le cœur de réseau centralisé (Amarisoft), le système d'accélération http (Nexedi), le réseau mesh re6st/babel sur du Wifi ou sur du xDSL (Nexedi), des ruggedPOD et leurs tours (SDS) et des amplificateurs de fréquence (AW2S).

Le transfert de compétence autour des technologies associées au POD est en cours auprès des équipes de BJT. Une adaptation du back office permettant d’administrer à distance le réseau est nécessaire et sera effectuée conjointement entre les équipes de SDS et BJT Partners en se basant sur l’API de management à distance des POD. Nous étudions en parallèle l’impact matériel du POD et les éventuelles adaptations nécessaires pour lutter notamment contre le vandalisme et les vols une fois sur le terrain.


Déploiement eNodeB en France

ID : SO-OSTV-20-10

Début : 01/10/2016 Fin : 31/12/2016

Temps : 100.0

Leader : BJT Ressource : BJT Location : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Un eNodeB sera déployé en France par BJT Partners dans le cadre de la licence expérimentale fournie par l'ARCEP à SDS. Cet eNodeB permettra de tester en grandeur nature le fonctionnement de la tour, du Rugged POD et de la stack LTE d'Amarisoft. Cette expérience de 3 mois doit permettre à BJT Partners de préparer le déploiement de la 4G à Mayotte.

Nous déploierons ainsi la RRH AW2S BlackHawk 2*20W qui sera interfacée avec le calculateur de la BBU via un carte PCIe CPRI. La BBU utilisera le logiciel Amarisoft Amari LTE 100. Les équipements radioélectriques LTE seront connectés aux antennes que nous fournit la filiale française de Kathrein.

La RRH AW2S BlackHawk 2*20W se connecte au calculateur de la BBU via une interface CPRI. L'équipement est alimenté en -48VDC par une alimentation MeanWell HEP-600-48. Intégrée dans un boîtier IP67, la RRH s'installe à proximité de l'antenne (afin de limiter les pertes dans les feeders) et se connecte à 2 ports d'une antenne X-Pol via 2 connecteurs RF (4.3/10 côté RRH et 7/16 côté antenne). Le calculateur de la BBU se connecte à la RRH via une carte PCIe CPRI également fournie par AW2S. Une carte permet de connecter jusqu'à 4 RRH via une liaison CPRI (4 secteurs sur une seule bande fréquence ou 2 secteurs lorsque l'on utilise la Carrier Aggregation sur deux bandes de fréquence). La carte dispose également d'un connecteur SMA qui permet de connecter une antenne GPS afin de fournir au lien CPRI une source d'horloge précise et stable utilisée comme référence par la RRH afin de maintenir la fréquence de son oscillateur ajustée avec la précision exigée par la norme LTE (50 ppb). Le calculateur est intégré dans un boîtier extérieur installé au pied de la tour. Il se connecte au switch local du site par une interface Ethernet afin de s'interconnecter au cœur de réseau via le backhaul IP. La BBU communique avec le cœur de réseau via une interface S1.


Déploiement eNodeB Mayotte

ID : SO-OSTV-20-20

Début : 01/01/2017 Fin : 31/03/2017

Temps : 150.0

Leader : BJT Ressource : BJT Location : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Une fois que la tour, le Rugged POD et l'eNodeB sont fonctionnels, BJT Partners transportera à Mayotte le matériel nécessaire pour installer une tour 4G et fournir un service LTE à quelques utilisateurs test.

Nous nous chargerons de la recherche du site pouvant accueillir ce premier point haut. Nous travaillerons également avec nos partenaires locaux afin de réaliser les travaux de génies civils nécessaires à la construction, pour chaque site, de la tour et du local technique nécessaires à l'installation des équipements.

La faible consommation électrique des équipements radioélectrique que nous avons sélectionnés nous permet de réduire le coût des équipements électriques nécessaires lors de l'installation (onduleurs, batteries, etc.). Cela permet de réduire les coûts de l'installation électrique, les coûts engendrés par la consommation d'électricité et l'empreinte écologique du réseau.

Pour les besoins de notre déploiement expérimental et pour assurer une continuité de service, chacun des sites disposera d'un local technique sécurisé, d'une climatisation redondante et d'un groupe électrogène 6 à 12.

KVA SDMO (selon les besoins de chacun des sites). Chaque site disposera également de deux onduleurs EATON 9SX 6KVA avec des racks d'extension de batteries 9SXEBM180RT.


Déploiement 7 eNodeB Mayotte

ID : SO-OSTV-20-30

Début : 01/04/2017 Fin : 30/09/2017

Temps : 400.0

Leader : BJT Ressource : BJT Location : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











7 tours seront ensuite déployées et connectées au core network de BJT Partners. Une architecture traditionnelle de backhaul centralisé sera utilisée à ce stade. Elle pourra reposer sur des réseaux filaires entre tours ou un mesh Wifi.

Nous travaillons avec nos partenaires de Mayotte afin de déployer les points hauts nécessaires à l'installation des équipements. Nous nous chargerons de la recherche des sites pouvant accueillir ces points hauts. Nous travaillerons également avec nos partenaires locaux afin de réaliser les travaux de génies civils nécessaires à la construction, pour chaque site, de la tour et du local technique nécessaires à l'installation des équipements.

En ce qui concerne le backhaul, nous souhaitons privilégier l'utilisation de Faisceaux Hertziens par rapport aux liaisons filaires. En effet, à l'emplacement de la plupart des sites sur lesquels seront installés les équipements et sans les possibilités offertes par la technologie distribuée et décentralisée que nous souhaitons déployer dans un second temps, la technologie DSL ne nous permet pas d'atteindre un débit suffisant pour fournir un service très haut débit mobile. Parallèlement, le déploiement d'un réseau de fibres optiques ne nous semble pas aujourd'hui économiquement raisonnable. Par ailleurs, considérant les limites du débit du réseau imposées par le coût très élevé du transit IP via le câble sous-marin LION2 et considérant l'augmentation significative des capacités des équipements FH, nous considérons que l'utilisation d'un backhaul constitué de radioélectrique ne constituera pas de goulet d'étranglement pour notre réseau. Ainsi, nous déploierons des équipements de type WiFi point à points et, lorsque la distance et le débit ne permettra pas l'utilisation de cette solution, nous déploierons des équipements 3Roam AREO et AREO HCR utilisant les bandes 8, 13 et 18 GHz.

Le transit IP sera fourni via une interconnexion Orange CIDOM / TIPV2. Cette interconnexion entre notre cœur de réseau et notre transitaire IP se fera via des routeurs Juniper SRX. Configurés en cluster, ces SRX nous permettent d'implémenter les politiques de routage (dynamique ou statique) et de sécurité (firewall). La technologie SRX Chassis Cluster permet d’assurer un partage de la charge ainsi qu'une bascule transparente d’un nœud à l’autre en cas de défaillance d’un des nœuds du cluster. Les switchs Juniper EX seront configurés en Virtual Chassis et connectés aux routeurs SRX, aux liaisons avec les opérateurs (transit IP, interconnexions SIP ou SIGTRAN...) et aux équipements de notre cœur de réseau. Déjà utilisés sur notre réseau en métropole et pour notre réseau GSM, ces équipements Juniper se montrent extrêmement stables et présentent d'excellentes performances. En effet, nous utilisons des routeurs SRX240H2 avec des switchs EX2200-48T-4G. Or, même un modèle comme le SRX240H2 permet d'assurer la commutation, le routage et la sécurité avec une connectivité de 1,5 Gbps. Afin d'augmenter la capacité et les débits du réseau et afin de diminuer les temps de réponse et les coûts de transit IP, nous installerons une batterie de serveurs de cache (serveurs proxys Squid sous Linux) et de serveurs de stockage (serveurs QNAP TS-EC1280U-RP) entre notre interconnexion IP et notre cœur de réseau. Les serveurs de stockage sur lesquels seront stockées les données seront configurés en RAID et seront eux même redondés et mutuellement répliqués afin d'éviter les risques de perte de données ou d'interruption de service. Afin d'éviter les risques liés aux défaillances mécaniques, nous stockerons l'ensemble des données sur SSD. Nous nous veillerons également à utiliser exclusivement des SSD qui assurent un MTBF supérieur ou égal à 2 millions d'heures.

Dans la mesure du possible, afin de se prémunir également contre les défaillances matérielles, nous déploierons les logiciels du cœur de réseau sur des machines virtuelles afin de faciliter les processus de sauvegarde à chaud et afin de rendre transparente la migration d'une machine physique à l'autre. Les images des machines virtuelles seront aussi sauvegardées régulièrement afin de pouvoir être remontées immédiatement en cas de défaillance matérielle ou de manipulation accidentelle entraînant la corruption ou la destruction du système.


Extensions fonctionnelles du réseau

ID : SO-OSTV-20-40

Début : 01/10/2017 Fin : 30/09/2018

Temps : 400.0

Leader : BJT Ressource : BJT Location : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











L'expérience sur 7 tours sera poursuivie pendant un an avec une extension progressive des fonctions du service LTE.

En utilisant du matériel standard et massivement adopté par l'industrie, notre cœur de réseau est prêt à profiter des dernières évolutions technologiques qui permettront d'augmenter la capacité et les débits sans nécessiter une remise en cause de l'architecture du réseau ou une augmentation du coût des équipements.

Nous déploierons aussi progressivement une évolution du logiciel BBU qui permettra d'utiliser les RRH LTE pour fournir également un service GSM qui cohabitera sur la même bande de fréquence que le service LTE. En effet, il nous semble utile de maintenir durablement le service GSM qui permet d'offrir un service de base qui n'exclue pas les utilisateurs qui n'ont pas les moyens ou qui ne souhaitent pas acquérir un terminal 3G ou 4G.

De plus, outre le coût intrinsèquement et durablement plus bas d'un terminal GSM, la norme GSM (notamment du fait de sa modulation à enveloppe constante) permet l'utilisation de terminaux présentant une consommation électrique extrêmement réduite. Ces avantages entraînent encore aujourd'hui un déploiement important de lignes GSM pour les applications Machine à Machine. Notamment afin de garantir une compatibilité durable pour les utilisateurs et les entreprises qui exploitent ces objets connectés, nous considérons qu'il est utile de garantir à long terme un réseau GSM fiable et universellement accessible qui pourra cohabiter avec le service LTE sans pour autant exiger l'utilisation de bandes de fréquences dédiées comme c'est le cas pour les réseaux déployés actuellement.


Développement extensions eNodeB

ID : SO-OSTV-20-100

Début : 01/10/2016 Fin : 30/09/2018

Temps : 50.0

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Pendant l'ensemble de la durée du déploiement, Amarisoft apportera son soutien à BJT Partners pour corriger ou étendre son logiciel d'eNodeB LTE et permettre ainsi à BJT Partners d'atteindre un niveau de service comparable aux technologies traditionnelles.

Le pilote permettra la remontée de données terrain sur l'utilisation et le fonctionnement de la stack. Ces données permettront de corriger le logiciel ainsi que d'affiner son paramétrage afin d'en optimiser le niveau de performance.

L'expérience accumulée sera utilisée pour le développement de technique SON déployable à plus grande échelle. En outre, l'environnement permettra de mettre en œuvre des techniques avancées de gestion d'interférence multi-cellule telle que l'iCiC ou le CoMP ainsi que l'implémentation de technique innovante de scheduling MAC. Cela passera par la validation des simulations faites en laboratoire et la prise en compte des spécificités du terrain.

Avec le déploiement du premier site, un premier niveau d’intégration est en cours de réalisation avec le back office de BJT Partners afin d’assurer une connectivité basique des abonnés au réseau.

Les évolutions logicielles nécessaires ont été identifiées afin d’assurer un fonctionnement optimal.

Des premières simulations et expérimentations en laboratoire ont été réalisés dans le cadre de la gestion des interférences pour le multi site.

Ces dernières devront être validés par la suite sur le terrain.


Tour de télécommunication

ID : SO-OSTV-20-200

Début : 01/10/2016 Fin : 30/09/2019

Temps :

Leader : SDS Ressource : SDS Location : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Déploiement sur site d'une tour de télécommunication avec RuggedPOD

Les développements associés aux tours de télécommunication se sont focalisés en 2017 sur les améliorations nécessaires au logiciel de CAO FreeCAD employé pour le projet. FreeCAD dispose d’un module de calcul de structure basique, qui nécessité dans le cas de Mayotte d’être enrichi d’un module de calcul de mécanique de fluides afin de coupler logiciel à Elmer un solveur 3D multi physique permettant de garantir la conception des équipements. Les efforts se sont principalement portes dans la restructuration du code permettant de supporter facilement :

Nous pensons que le couplage sera terminé durant l’été 2018, ce qui permettra de lancer une phase de calcul complète sur le quatrième trimestre et ainsi de lancer en parallèle la fabrication des tours.

RuggedPOD Outdoor

ID : SO-OSTV-20-200-10

Début : 01/10/2016 Fin : 30/09/2017

Temps : 200.0

Leader : SDS Ressource : SDS Location : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











RuggedPOD est un projet communautaire de microdatacenter outdoor. Actuellement industrialisé par Splitted-Desktop Systems, le projet est au stade de pré-industrialisation et livré dans des laboratoires à des usagers formés à cet équipement. Le système est une boite à vide qui contient 2/3 d'huile diélectrique dans laquelle des cartes de calculs sont immergées. Le mise sous vide garantie la pérennité de l'huile qui s'oxyderait en présence d'oxygène. Cette contrainte forte rend RuggedPOD complexe à maintenir et à industrialiser. Des tests complémentaires doivent ainsi être réalisés pour s'assurer qu'une maintenance en terrain hostile soit envisageable notamment dans les cas :

Il est aussi nécessaire d'améliorer l'ergonomie du produit afin de faciliter la maintenance de celui-ci par une seule personne (contrainte de poids et de temps pour réaliser les opérations). L'objectif de ce work package est donc de réaliser un état des lieux de l'ergonomies et des capacités d'un RuggedPOD actuel en milieu outdoor contraint, de proposer des améliorations et de les implémenter sur une série de prototypes qui seront utilisés ultérieurement.

Les prototypes de POD déployés sur l’année 2017 (1 sur Saclay et 1 sur Lannion) ont rencontrés différents problèmes techniques qui ont engendrés des délais dans le programme de développement. L’équipe s’est focalisée à résoudre ces problèmes parmi lesquels :

Ces problèmes divers sont longs et difficiles à identifier. L’équipe de développement ne dispose pas d’un accès à un laboratoire climatique permettant d’accélérer les cycles de vieillissements c’est pourquoi nous avons préféré nous concentrer à réaliser un cycle climatique complet avant l’envoie des premiers POD à plus de 10 000 km de Paris où se trouve l’équipe de développement.

L’équipe est maintenant plus confiante sur les capacités du POD, et nous pensons lancer la production des 7 POD requis pour Mayotte sur le premier trimestre 2018 et les mettre à disposition sur site au second trimestre.

Open Telecom Tower POC

ID : SO-OSTV-20-200-20

Début : 01/10/2016 Fin : 30/09/2017

Temps : 200.0

Leader : SDS Ressource : SDS Location : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Le projet Open Tower est une tour dont le développement a été initiée en collaboration avec Facebook, dont l'enjeu consiste à créer une solution modulaire, capable de porter à 24 m de haut des équipements télécom permettant de constituer un macro site. Le poids des équipements supporte en tête est supérieur a 200kg sans inclure le poids de deux hommes susceptibles de gravir la tour. Afin de garantir un maximum de sécurité le design de la tour est fait sous forme d'escalier en colimaçon avec un cœur central et des poutres latérales de maintien sur le principe des grattes ciel. Le projet est conçu avec une grande modularité aussi bien architecturale que technique. Les matières premières utilisées peuvent être aussi bien du bois, du béton ou de l'acier galvanise. Un mixte des trois matières est envisageable en fonction de leur exposition au vol et de leur valeur de revente dans les pays ou les déploiements auront lieux.

La version béton de la tour est base sur des marches qui s'emboitent et se hissent de manière autobloquante et auto suffisante. Des moules sont nécessaires pour les réaliser ainsi que des tests structuraux. Ces tests doivent être effectués sur le site de production, en même temps que le transfert de compétence nécessaire à assurer la sécurité de l'édifice. L'objectif de ce work package consiste donc à :

Les contraintes climatiques liées au pays nous ont amené à revalider la structure de la tour au travers de l’usage de la simulation numérique notamment pour soutenir les vents susceptibles d’apparaître dans cette zone tropicale. Le développement de la solution logicielle progresse bien et nous pensons pouvoir réaliser une campagne de tests sur l’année 2018 avec les premiers éléments mécaniques.

Open Telecom Power Solar

ID : SO-OSTV-20-200-30

Début : 01/10/2017 Fin : 30/09/2018

Temps : 200.0

Leader : SDS Ressource : SDS Location : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Un RuggedPOD munis des cartes électroniques et amplificateur radio consomme environ 800W en mode émission/réception MIMO. Lors de l'émission SISO, la consommation des RRH est divisée par deux et la consommation globale du système tombe alors sous les 400W. Il est donc envisageable de munir les tours de solution solaire pour apporter les ressources énergétiques nécessaires à une macro cell. Cette installation devra avoir suffisamment de panneau pour couvrir à la fois les besoins journalier et nocturne. Elle devra être auto pilote à distance en fonction des données météo et pouvoir piloter l'installation pour fonctionner en mode dégradée en fonction du niveau d’énergie restant. L'objectif de ce work package est de réaliser et tester une installation solaire pour le projet Open Tower et RuggedPOD, de valider son bon fonctionnement et ses limites en fonction de l'état de l'art.

Les travaux de R&D liés à cette tâche n’ont pas débuté, l’équipe est restée concentrée sur la résolution des problèmes techniques rencontrés en 2017

Open Telecom Power Wind

ID : SO-OSTV-20-200-40

Début : 01/10/2017 Fin : 30/09/2018

Temps : 200.0

Leader : SDS Ressource : SDS Location : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











En complément d'une solution solaire, nous pensons qu'il est possible d'associer la tour a une génératrice éolienne de par les capacités structurelles de l'édifice. L'éolien pouvant service de complément efficace aux solutions solaires dans les régions situes au nord.

Nous envisageons pour ce faire de coupler une solution standard du marché à la solution de stockage d’énergie solaire dans l'optique de pouvoir apporter cette alternative. Cette solution engendre des problèmes de gestion de foudre qui devront être adresse durant ce work-package.

Les travaux de R&D liés à cette tâche n’ont pas débuté, l’équipe est restée concentrée sur la résolution des problèmes techniques rencontrés en 2017

Open Telecom Power Wind (maintenance)

ID : SO-OSTV-20-200-50

Début : 01/10/2018 Fin : 30/09/2019

Temps : 400.0

Leader : SDS Ressource : SDS Location : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Même si la structure a été conçue d'une manière plus pérenne et sécuritaire que les structures traditionnelles, il est nécessaire d'étudier son vieillissement notamment sous des climats tropicaux avec des taux d'humidité élevés et des vents supérieurs aux tests que nous pouvons effectuer en France métropolitaine. L'objectif de ce work package est donc de démonter et analyser par ultrason une partie des pièces de structures d'une tour de test afin de valider que le vieillissement est conforme aux attentes. Nous analyserons aussi plus précisément le taux d'oxydation de l'aluminium du POD associe afin de valider les calculs théoriques effectués.

Les travaux de R&D liés à cette tâche n’ont pas débuté, l’équipe est restée concentrée sur la résolution des problèmes techniques rencontrés en 2017


WP2 - Prototype décentralisé

ID : SO-OSTV-30

Début : 01/10/2016 Fin : 30/09/2019

Temps :

Leader : Nexedi Ressource : Amarisoft, AW2S, Paris 7, Nexedi
Location : Nexedi, AW2S, Paris 7, Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Le sous-projet WP2 vise à construire en laboratoire un prototype de réseau 4G décentralisé. Chaque base station comprend donc tous les éléments d'un réseau complet. Il faut alors imaginer et comparer plusieurs solutions d'overlay pour garantir la continuité des connexions. Ce projet sera tiré par Amarisoft avec la participation de Nexedi et de Paris 7. On y trouve donc :


4G/5G Mesh

ID : SO-OSTV-30-10

Début : 01/10/2016 Fin : 30/09/2019

Temps :

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Amarisoft va étendre le protocole LTE pour lui permettre à la fois de fonctionner au-dessus d'un mesh, quelle que soit la technologie de lien sous-jacente (xDSL, Ethernet sur paire torsadée, Ethernet sur fibre optique, etc.), et pour lui permettre également d'agir comme support à un mesh point à point entre stations. Cette extension permet de se passer d'un backhaul dédié -- les liaisons existant entre les stations sont automatiquement configurées pour former un backhaul virtuel.

L'utilisation d'un mesh pour simuler un backhaul avec une qualité de service suffisante pour le transfert simultané de voix et de trafic de données requiert un contrôle fin du routage, ce qui demandera le développement et l'évaluation d'extensions aux protocoles de routage utilisés.

4G/5G Mesh POC

ID : SO-OSTV-30-10-10

Début : 01/10/2016 Fin : 30/09/2017

Temps : 600.0

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Amarisoft va commencer par réaliser un prototype de mesh 4G. Ce prototype fera l'objet d'une démonstration dans un bureau.

Afin de réaliser un réseau MESH entre les stations de base tout en restant pleinement compatible avec la norme LTE, Amarisoft utilisera le mode TDD afin de définir des paquets spéciaux dédié à la communication entre eNodeB.

Cela implique le prototypage d'un nouveau scheduler MAC et l'ajout de protocoles spécifiques à la gestion du MESH entre stations aussi bien au niveau des couches basse de contrôle LTE (Control plane) que du routage de haut niveau de données (Data plane). On permettra ainsi d'allouer dynamiquement une partie du spectre à cette communication sans interférer sur la communication avec les terminaux commerciaux.

Un premier prototype a été réalisé en 2 phases.

La première phase a consisté à intégrer un UE dans 2 eNodeB en allouant de façon statique le spectre. Cela a permis de valider la communication et le routage des données entre 2 nœuds aussi bien au niveau radio que IP et de préparer l’intégration future du travail théorique de Paris VII sur la mise en place du MESH.

La deuxième étape a consisté à pousser plus en avant l’intégration de l’UE dans l’eNodeB afin de le fondre totalement dans le protocole LTE et ainsi gardé la compatibilité avec l’existant, en particulier en utilisant les canaux de broadcast MBMS.

Un certain nombre d’hypothèses simplificatrice ont été posées afin d’éviter une augmentation trop importante de la complexité, notamment en limitant le nombre de liens maximum avec des eNodeB voisins à 3.

En tant que POC, un certain nombre d’aspects ont été hardcodé et restent à améliorer : allocation dynamique des ressources, propagation des informations de routage...

4G/5G Mesh Peer

ID : SO-OSTV-30-10-20

Début : 01/10/2017 Fin : 30/09/2018

Temps : 600.0

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Une fois ce prototype réalisé, Amarisoft l'intégrera à sa stack commerciale en y ajoutant des API permettant d'utiliser le mesh 4G comme s'il s'agissait d'un réseau de niveau 2 (type Ethernet) ou 3 (type gre) destiné à transporter TCP/IP. Une démonstration sera effectuée en intérieur en démontrant la facilité de configuration et l'interopérabilité entre les stations de base wireless et le backhaul classique.

En particulier Amarisoft étendra son scheduler MAC afin d'optimiser l'allocation du spectre entre communication vers les terminaux et communication entre stations et garantir une utilisation optimale des ressources radio. Cela nécessitera l'extension des techniques de gestion d'interférence puisqu'on impliquera un type nouveau de communication nécessitant une gestion spécifique de paramètres de modulation et de contrôle de puissance. Enfin, afin d'améliorer la mobilité dans un contexte non standard et sans avoir à modifier les terminaux, Amarisoft intégrera de nouvelles techniques de handover entre EPC et ainsi rendre totalement transparent aux terminaux mobiles le caractère décentralisé de l'architecture.

Une partie des développements servant au prototype a déjà été réintégré dans la stack commerciale. Cela correspond à des changements d’architecture logicielle qui permettront d’intégrer par la suite plus facilement le travail réalisé.

Le code a passé les tests de validations de production.

4G/5G Mesh Standardization

ID : SO-OSTV-30-10-30

Début : 01/10/2018 Fin : 30/09/2019

Temps : 600.0

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Amarisoft proposera dans le cadre de la future norme 5G d'intégrer la notion de mesh afin de faciliter le déploiement de réseaux autonomes.

Amarisoft participera donc à la standardisation 3GPP en poussant les techniques mises au point au court des différentes expérimentations et en apportant un retour d'expérience concret.

Les efforts se poseront sur les 2 aspects principaux que sont la partie RAN et la gestion des ressources radio ainsi que l'intégration du MESH directement au sein du core network.


Core Network décentralisé

ID : SO-OSTV-30-20

Début : 01/10/2016 Fin : 30/09/2019

Temps :

Leader : Nexedi Ressource : Nexedi, Paris 7 Location : Nexedi, Paris 7

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Nexedi et Paris 7 concevront une architecture de core network décentralisé. L'idée sous-jacente est que chaque eNodeB soit en mesure de prendre en charge de façon autonome les communications de tout utilisateur enregistré sur un portail central. Le portail central gère l'allocation d'adresses, la facturation et les accords de peering avec d'autres opérateurs. Chaque eNodeB dispose de son côté d'une copie partielle de l'annuaire des utilisateurs afin de pouvoir les prendre en charge de façon autonome. Afin de pouvoir publier un résultat sous forme libre partagée avec une communauté, ces travaux seront réalisés sur la base de YateBTS, une version améliorée de OpenBTS simple à prendre en main. Ces travaux seront ensuite portés pour le logiciel d'eNodeB d'Amarisoft. Un mécanisme de déploiement automatique permettra de choisir le logiciel utilisé pour le réseau (GSM avec YateBTS ou LTE avec Amarisoft) et facturer le cas échéant une licence pour le mode LTE.

Paris 7 a trouvé la solution au problème du handover TCP/IP, ce qui est en soi déjà extra-ordinaire. La solution a été validée sur le principe avec Nexedi et présentée à Amarisoft. Un premier test est en cours sur un simulateur à base de Wifi pour valider le concept.


Profil SlapOS 2G

ID : SO-OSTV-30-20-10

Début : 01/10/2016 Fin : 30/09/2019

Temps : 400.0

Leader : Nexedi Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Développement d'un profil SlapOS permettant de déployer automatiquement une station (OSTV Node) configurée par défaut pour fournir un service 2.5G de façon autonome.

Chaque matériel OSTV est en réalité un serveur sous GNU/Linux (Debian) configuré avec le système d'exploitation hyper-convergent "SlapOS". SlapOS permet d'assurer le lien automatique entre l'appstore de services "OSTVStore" et chaque matériel. Un utilisateur commence donc par connecter son matériel à "OSTVStore". L'utilisateur choisit alors un service à déployer sur son matériel (ex. une radio logicielle GSM). SlapOS assure alors automatiquement le déploiement du service de radio logicielle GSM sur le matériel.

Les couches système de base GNU/Linux (Debian) et SlapOS sont indépendantes. La mise à jour d'un service par SlapOS n'a aucun impact sur le système de base. Cette approche permet de réduire considérablement les risques d'échec de mise à jour bien connue dans les systèmes de paquetages.

L'objectif ce cette tâche est de réaliser un premier profil SlapOS pour OSTV sur un logiciel libre, YateBTS. Ce profil a deux objectifs :


Réalisation avec Ansible d'un système de déploiement automatique à base de SlapOS permettant d'automatiser le déploiement du master comme du node slapos. Automatisation de déploiement des composants de base. Tests sur lien satellite. Test autimatique d'installation reproductible.


Accès internet réparti

ID : SO-OSTV-30-20-20

Début : 01/10/2016 Fin : 30/09/2019

Temps : 400.0

Leader : Paris 7 Ressource : Paris 7 Location : Paris 7

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Extension de babel et re6st pour fournir un accès Internet réparti à chaque utilisateur connecté à un OSTV Node. On suppose ici que certains nœuds OSTV Node disposent de leur propre accès Internet et d'autre ne disposent que d'une connexion privée (ex. Wifi, 4G) à un autre OSTV Node. La combinaison du protocole Babel et re6st doit permettre de fournir une route disposant d'une qualité de service suffisante pour le type de service sollicité (voix ou données), ce qui peut demander un routage spécifique à un type de service, y compris en cas de handover d'un nœud OSTV à un autre.

Le routage sensible au ToS est une technique de routage des données dans les réseaux internet qui permet, dans des topologies complexes, de séparer le trafic de données du trafic de la voix, ce qui permet d'éviter que la voix soit retardée par les données, ce qui causerait des artefacts audibles.

En collaboration avec Gwendoline CHOUASNE, nous avons développé une technologie de routage spécifique au ToS pour les protocoles de routage à vecteur de distance qui a un certain nombre de bonnes propriétés :

Le gros du travail a été réalisé entre mars et juillet 2017 dans le cadre du stage de M2 de Gwendoline CHOUASNE (financé sur les crédits propres du laboratoire IRIF). Les travaux suivants ont été réalisés :

Le document IETF préliminaire décrivant le protocole est disponible en ligne. Les travaux réalisés sont décrits en détail dans le rapport de stage de Gwendoline CHOUASNE.

Nous considérons donc que nos engagements vis-à-vis du projet ont été réalisés. Cependant, le travail n'est pas fini, et si notre technologie s'avère utile en déploiement, il nous faudra réaliser les tâches suivantes :

Il est difficile de donner une estimation du temps que ces tâches prendront ; en particulier, l'IETF est une organisation internationale qui obéit à son propre calendrier, qu'il serait mal venu de vouloir bousculer.

Portail inscription et facturation

ID : SO-OSTV-30-20-30

Début : 01/10/2016 Fin : 30/09/2019

Temps : 200.0

Leader : Nexedi Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Nexedi réalisera un portail pour enregistrer des utilisateurs, enregistrer des "OSTV Node", automatiser le déploiement des "OSTV Node" et produire automatiquement les factures aussi bien pour les utilisateurs que pour les exploitants de nœuds "OSTV Node". Ce portal deviendra à terme le cœur du service "OSTV Cloud".

La réalisation de ce portail est obtenue par une extension du master "SlapOS": en y intégrant une nouvelle API REST/HATEOAS d'une part et en y intégrant un processus de revue des applications soumises et un paiement de licence. Le système de mise aux enchères suppose de définir de nouveaux rôles dans SlapOS et un nouveau modèle de sécurité.

Divers tests de montée en charge seront effectués pour s'assurer de la possibilité de déployer à terme 10.000 nœuds sur le master SlapOS. A ce jour, les plus gros master SlapOS comportent uniquement quelques centaines de nœuds.

Une première version d'un portail d'inscription a été lancée lors du MWC 2017 à Bercelone : signal5g.com

Profil SlapOS LTE

ID : SO-OSTV-30-20-110

Début : 01/10/2017 Fin : 30/09/2018

Temps : 200.0

Leader : Nexedi Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Intégration au profil SlapOS initial de la stack Amarisoft pour le support LTE optionnel (licence payante). Unification de la gestion du core network local LTE et GSM.

L'intégration du logiciel Amarisoft soulève plusieurs difficultés. S'agissant d'un logiciel propriétaire, il est nécessaire d''intégrer un mécanisme de contrôle de la copie. Ce type de mécanisme nécessite une extension de SlapOS ainsi probablement que du logiciel Amarisoft.

Il est également possible qu'il soit nécessaire d'exécuter la stack Amarisoft d'eNodeB dans un namespace Linux en mode privilégié, ce qui est contraire aux principes de SlapOS d'absence d'utilisateur privilégié. Nous envisagerons soit une modification du logiciel Amarisoft avec l'éditeur, soit l'intégration à SlapOS de conteneurs LXC classiques en supplément des micro-conteneurs aujourd'hui disponibles.

Une première version de profil SlapOS a été réalisée avec un extension de SlapOS pour la gestion de cgroups. Ce profil est en cours de test sur un réseau.

Optimisation des routes pour la voix

ID : SO-OSTV-30-20-120

Début : 01/10/2017 Fin : 30/09/2018

Temps : 400.0

Leader : Paris 7 Ressource : Paris 7 Location : Paris 7

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Optimisation du routage babel en fonction du type de service (voix ou données) de façon à optimiser la qualité de service pour la voix.

Mise aux enchères et refacturation

ID : SO-OSTV-30-20-130

Début : 01/10/2017 Fin : 30/09/2018

Temps : 200.0

Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Extension du portail pour y intégrer les opérateurs tiers avec un mécanisme de mise aux enchères de l'accès aux "OSTV Node". Ce mécanisme permet à un opérateur de bénéficier d'un "OSTV Node" dans une zone non couverte pour fournir du service LTE. L'exploitant ayant investi dans le "OSTV Node" est alors rémunéré par l'opérateur. OSTV reçoit 20% des gains de l'exploitant. Ce mécanisme est inspiré du fonctionnement de Uber. Il favorise l'investissement local pour améliorer la couverture réseau en proposant un mécanisme de rémunération de l'investisseur par l'opérateur.

Cette tâche comprend deux aspects : le mécanisme de mise aux enchères et de refacturation en tant que tel (environ 100 jours) et le mécanisme de communication avec les opérateurs (100 jours).

Le mécanisme de communication avec les opérateurs est encore inconnu : courrier recommandé automatique, flux RSS, envoi d'un email, etc. Diverses solutions seront testées en pratique, en fonction de la réglementation applicable et de la volonté de coopération des opérateurs.

Intégration mesh 4G/5G

ID : SO-OSTV-30-20-210

Début : 01/10/2018 Fin : 30/09/2019

Temps : 400.0

Leader : Nexedi Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Intégration au profil SlapOS d'un mesh 4G LTE pour relier deux "SlapOS Node" sans passer par un réseau filaire ou Wifi. La partie "noble" de cette tâche consiste à intégrer à SlapOS les mécanismes de routage prioritaire selon le service, comme une extension des mécanismes d'isolation déjà présentes et déployés sur Teralab.

Mais cette tâche devrait également conduire à résoudre des problèmes de configuration réseau en lien avec le système de mesh LTE. Ces problèmes anodins peuvent prendre un temps important. Ainsi, dans le projet Teralab, les questions de configuration réseau pourtant simples ont ajouté 3 mois homme d'effort (https://www.nexedi.com/success/slapos-IMT-Documents.Teralab.Success.Case). La résolution d'un problème d'apparence simple (ex. mauvaise gestion des caches de tables de routage dans le noyau Linux) peut se traduire par un effort de plusieurs mois homme.

Dans le cas du mesh 4G/5G, nous allons devoir assurer le fonctionnement d'une combinaison d'un noyau

Linux, d'un démon babel et d'un réseau point-à-point expérimental avec des objectifs de qualité de services. Les bogues que nous allons rencontrer et que nous devrons résoudre pour assurer un premier niveau d'intégration suffisant devraient coûter 1 à 2 homme année.

Ce facteur de risque est donc intégré à cette tâche en termes d'effort.

Redirection de session voix

ID : SO-OSTV-30-20-220

Début : 01/10/2018 Fin : 30/09/2019

Temps : 400.0

Leader : Paris 7 Ressource : Paris 7 Location : Paris 7

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Extension de re6st/babel pour rediriger automatiquement les téléphones vers le core network initial d'une session avant le handover vers une autre base station. Ce mécanisme permet de fournir des services de type téléphonie / vidéo aussi bien pour de la 4G que pour d'autres protocoles comme WebRTC déployé sur un réseau Wifi mesh.

Facturation répartie temps réel

ID : SO-OSTV-30-20-230

Début : 01/10/2018 Fin : 30/09/2019

Temps : 200.0

Leader : Nexedi Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Extension du portail pour permettre de facturer les utilisateurs en temps réel y compris en cas de déconnexion partielle du réseau mesh. L'objectif est de pouvoir couper facilement une conversation ou de l'usage de données en cas de dépassement de crédit, y compris en cas de handover entre stations de base.

Aujourd'hui, la facturation dans SlapOS est centralisée. Un service est désactivé sous 24 heures en cas de non-paiement. Notre objectif ici est de déployer automatiquement des limites de consommation de trafic sur les nœuds OSTV voire des systèmes prédictifs, afin d'éviter qu'un mauvais payeur ne puisse profiter du réseau.

Dans un mode intégralement réparti, cela suppose d'attacher à chaque entrée de la base client un profil de limite de consommation mis à jour de façon régulière. La principale difficulté de cette tâche réside dans le processus de mise à jour régulière sur une base client importante et sur l'optimisation du trafic réseau afin d'éviter que la facturation en temps réel ne coûte plus cher qu'elle ne rapporte.


RRH Ethernet

ID : SO-OSTV-30-30

Début : 01/10/2016 Fin : 30/09/2018

Temps :

Leader :AW2S Ressource : AW2S Location : AW2S

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











AW2S va concevoir et produire une RRH de 20W avec carte radio intégrée et interface Ethernet vers l'extérieur.

A ce jour, AW2S commercialise des RRH embarquant le protocole CPRI, pour « Common Public Radio Interface », protocole utilisé par les grands OEM télécom.

Pour pouvoir utiliser l’Ethernet et s’affranchir de ce protocole dédié nécessitant une interface enodeB exploitant également le CPRI, AW2S doit développer le produit de manière prendre en compte nativement le transport sur Ethernet des données.

Ce type de RRH intégrée permet de réduire les coûts de déploiement d'une infrastructure répartie dans laquelle la RRH peut être distante de l'eNodeB sans utilisation de réseaux spécialisés. Dans le cadre de ce projet, AW2S mettra à disposition les drivers permettant une communication aisée avec la RRH.

Prototype RRH Ethernet

ID : SO-OSTV-30-30-10

Début : 01/10/2016 Fin : 30/09/2017

Temps : 500.0

Leader : AW2S Ressource : AW2S Location : AW2S

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Comme évoqué ci-dessus, la difficulté du développement réside dans l’adaptation d’un protocole conçu spécialement pour des applications télécom, à savoir le CPRI vers un protocole sur Ethernet.

Par exemple, le CPRI permet la synchronisation de plusieurs dizaines à milliers de RRHs dans le but de garantir un réseau optimisé. L’Ethernet, dans son état le plus utilisé ne permet pas le transport de la synchronisation des données.

Il faut donc pouvoir y remédier :

Ceux-ci permettront à chaque RRH d’être synchronisé à une horloge unique et d’atteindre les mêmes besoins que le CPRI.

Par ailleurs, le CPRI est adapté aux débits que le LTE prévoit en fonction des différentes configurations existantes, comme par exemple les différentes largeurs de bande, les différents modes MIMO 2x2 ou 4x4… Plus le besoin en bande passante ou en débit sera important et plus le rate CPRI sera élevé.

Pour pouvoir répondre aux mêmes besoins, l’Ethernet ayant des limites plus contraignantes que le CPRI et surtout des catégories de débits en puissance de 10.

Pour limiter encore les coûts, les données doivent être compressées pour être véhiculées par Ethernet.

La compression de données n’est pas sans risque sur les performances générales du système et selon le taux de compression utilisé, le RRH peut ne plus être conforme aux spécifications 3GPP.

Il y a donc un juste milieu à trouver pour rendre le produit conforme. Cette activité demande donc un effort important en termes de ressources humaines.

La compression est une partie du développement ; en effet, une fois celle-ci réalisée, il faut encore écrire le protocole de transport de données par Ethernet intégrant les aspects de compression évoqués ci-dessus.

Une fois l’intégration réalisée dans le RRH, il conviendra également d’écrire les drivers permettant l’utilisation de la RRH par Ethernet.

Il y aura donc une partie développement/test/validation de la partie logicielle mais également une qualification complète dans les différents modes d’utilisation pour vérifier que l’utilisation de l’Ethernet peut être une alternative crédible au CPRI et de valider son fonctionnement en qualifiant la RRH selon la spec ETSI 36.104.

Il faudra ajouter à cela :

Sur la base de la plateforme Blackhawk (RRH sur lien CPRI), AW2S a commencé le développement de l’adaptation du protocole CPRI sur Ethernet. Il a dans un premier fallu mettre en place un algorithme de compression I/Q de manière à pouvoir transporter les échantillons I/Q sur un lien Gigabit Ethernet ainsi que la conception d’un FPGA gérant le transport sur Ethernet que nous appelons RoE (Radio over Ethernet). Une première adaptation de la plateforme Blackhawk a été réalisée et proposée au dernier Mobile World Congress de Barcelone en Février 2017 montrant la faisabilité du transport sur Ethernet. Lors de cette année écoulée, AW2S a donc développé une nouvelle plateforme appelée Jaguar dédiée pour le transport sur Ethernet. Celle-ci embarque un FPGA dimensionné pour le protocole 10GBeth. En effet, le LTE, au fil des releases propose des débits de plus en plus conséquents, le GBeth ne permet pas de répondre favorablement à cette augmentation de capacité et le 10GBeth s’impose naturellement. Cette plateforme peut donc supporter les agrégations de porteuses en minimisant la compression de données. Mais celle-ci embarque également un GPS permettant la synchronisation entre les différents sites. L’un des avantages du protocole CPRI est justement le transport de la synchro. Il faut donc pouvoir récupérer cette dernière dans chaque RRH et le GPS est une première approche pour sa récupération. Et pour finir, cette plateforme, contrairement à la plateforme Blackhawk embarque le protocole AISG permettant le contrôle des antennes.

Durant l’année écoulée, pour répondre également aux attentes de BJT Partners et d’un déploiement sur Mayotte, nous avons dû développer toute la partie radio pour la bande de fréquence 2100MHz, bande de fréquence privilégiée par BJT Partners pour une expérimentation sur Mayotte. A chaque bande de fréquence nouvellement développée, nous devons valider l’ensemble des performances radio pour savoir si elles répondent au standard ETSI et si l’équipement peut être installé sur site. A ce jour, nous démarrons les premières intégrations de cette nouvelle plateforme de RRH.

Reste à faire :

Batch de test

ID : SO-OSTV-30-30-20

Début : 01/10/2017 Fin : 30/09/2018

Temps : 600.0

Leader : AW2S Ressource : AW2S Location : AW2S

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Dans le cadre de ce projet, nous serons donc amenés à réaliser plusieurs prototypes dans le cadre d’un site pilote réel.

Les essais terrains étant les plus propices pour la mise en situation réelle, plusieurs prototypes seront à prévoir.

Comme mentionné dans le paragraphe précédent, il est important de vérifier que chaque RRH se synchronise sur une même horloge dans le but de pouvoir proposer le hand-over, c’est-à-dire la capacité pour un téléphone mobile de basculer d’une eNodeB sur une autre sans perte de communication.

Cela est aussi plus contraignant et surtout indispensable pour gérer les modes TDDs pour synchroniser le moment d'émission et réception entre des cellules adjacentes.

A ce jour, nous avons lancé 5 prototypes et nous sommes en phase d’intégration et de portage de FPGA vers cette nouvelle plateforme. De ce batch, nous fournirons BJT Partners pour lui permettre de commencer à prendre en main cette nouvelle plateforme avant le déploiement sur différents sites à Mayotte.

Reste à faire :

Normalisation RRH Ethernet

ID : SO-OSTV-30-30-30

Début : 01/10/2018 Fin : 30/09/2019

Temps : 400.0

Leader : AW2S Ressource : AW2S Location : AW2S

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Participation à l'effort de normalisation des RRH Ethernet dans le cadre des projets de réseau 5G auprès de l’ETSI et de l’IEEE.


WP3 - Pilote Mayotte décentralisé

ID : SO-OSTV-40

Début : 01/10/2017 Fin : 30/09/2019

Temps :

Leader : Nexedi Ressource : Nexedi, BJT, Amarisoft Location : Nexedi, BJT, Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Le sous-projet WP3 vise à déployer à Mayotte les résultats du sous-projet WP2 en utilisant un cœur de réseau décentralisé sur une partie des base stations. Ce sous-projet est piloté par BJT Partners et repose sur tous les partenaires.


Accès LTE individuel

ID : SO-OSTV-40-10

Début : 01/10/2017 Fin : 30/09/2018

Temps :

Leader : Nexedi Ressource : Nexedi, BJT, Amarisoft Location : Nexedi, BJT, Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Un premier accès LTE individuel sera déployé à Mayotte. Il sera par exemple installé dans une maison individuelle et raccordé à Internet par ADSL. Ce déploiement nécessite une collaboration étroite entre Amarisoft, Nexedi et BJT Partners. Dans ce premier test, le problème du handover n'est pas pris en compte. L'objectif est uniquement de fournir un accès data et voix stable en s'appuyant sur le réseau voix de BJT Partners et sur le portail "OSTV Cloud".

Test et intégration système

ID : SO-OSTV-40-10-10

Début : 01/10/2017 Fin : 30/09/2018

Temps : 100.0

Leader : Nexedi Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Intégration de la base utilisateur de "OSTV Cloud" et de celle de "BJT Partners" pour permettre la prise en charge des abonnés "BJT Partners" par une base station connectée à "OSTV Cloud".

Dans un système décentralisé, chaque eNodeB joue le rôle de core network. Il est donc indispensable lorsqu'un utilisateur se connecte à une eNodeB de pouvoir l'autoriser. Deux types d'autorisation existent : celle de l'opérateur annoncé sur l'eNodeB et celle d'un opérateur ayant un accord de roaming.

Pour l'autorisation des utilisateurs de l'opérateur, il est nécessaire de télécharger ou de cacher le fichier des utilisateurs de l'opérateur (BJT Partners). Ce mécanisme nécessite des optimisations similaires à celles de la facturation.

Pour le roaming, il est nécessaire de télécharger les accords de roaming de l'opérateur.

Des extensions des profils SlapOS doivent être prévues pour couvrir ces deux cas et s'assurer de leur bonne intégration au réseau de BJT Partners.

Test et intégration core network

ID : SO-OSTV-40-10-20

Début : 01/10/2017 Fin : 30/09/2018

Temps : 300.0

Leader : BJT Ressource : BJT Location : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Intégration de la base utilisateur de "OSTV Cloud" et de celle de "BJT Partners" pour permettre la prise en charge des abonnes "BJT Partners" par une base station connectée à "OSTV Cloud". Interconnexion du core network de "OSTV Node" au réseau voix "BJT Partners". Fourniture des éléments de facturation voix.

Un cœur de réseau unifié qui intègre l'ensemble des fonctionnalités sur un équipement unique sera déployé sur chacun des sites afin de permettre l'utilisation de la capacité de connectivité IP locale. Cette connectivité fournira l'accès aux utilisateurs connectés à l'équipement radioélectrique ainsi que l'échange des éléments de signalisation nécessaires entre l'eNodeB local et le cœur de réseau centralisé, notamment pour assurer la communication avec certains éléments non décentralisables du HSS. Cette connectivité permettra également une interconnexion SIP avec le commutateur permettant l'interconnexion voix et SMS avec les autres opérateurs.

Afin de permettre également une interconnexion voix avec les réseaux des autres opérateurs, nous utiliserons la solution que nous utilisons actuellement pour notre interconnexion SS7 TDM avec la DIVOP Orange. Cette solution a été validée par Orange lors des tests d'interconnexions et permet, depuis 2007, de traiter l'ensemble des appels de notre réseau en métropole et dans les 5 Départements d'Outre-Mer. Pour l'interconnexion SMS, nous utilisons une solution logicielle développée en interne permettant une interconnexion SIGTRAN avec le hub de signalisation d'Orange. Pour le transit IP, nous utiliserons les équipements Juniper, approvisionnés via notre distributeur Klee Group, similaires à ceux que nous utilisons pour nous interconnecter à nos différents transitaires en métropole. Pour les SMS, la signalisation transitera par le hub d'Orange (IPX OINIS TK1 et TK2). Orange permettant une interconnexion SIGTRAN, notre SMSC est uniquement constituée d'un logiciel déployé sur un serveur x86 et n'exige donc pas de matériel dédié.

Adaptations eNodeB

ID : SO-OSTV-40-10-30

Début : 01/10/2017 Fin : 30/09/2018

Temps : 100.0

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Ce pilote permettra la mise au point des techniques développées en laboratoire afin d'optimiser les jeux de paramètre en fonction de spécificités de chaque site.

Amarisoft ajoutera un ensemble de jeux d'indicateurs permettant de contrôler et d'améliorer le système.

L'intégration de technique de SON permettra en outre de valider l'extension du réseau de manière simple et transparente.

Une première étape basique a été implémentée dans l’auto configuration du réseau. Les mécanismes de mesures de cellules sont désormais gérés en partie dans l’eNodeB en réduisant la part statique de la configuration.


Accès LTE individuels multiples

ID : SO-OSTV-40-20

Début : 01/10/2018 Fin : 30/09/2019

Temps :

Leader : Nexedi Ressource : Nexedi, BJT, Amarisoft Location : Nexedi, BJT, Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Le deuxième déploiement vise à disposer plusieurs "OSTV Node" sur des maisons individuelles pas trop éloignées afin de tester le mécanisme de mesh 4G entre "OSTV Node" et le mécanisme de handover entre core network décentralisés.

Test et intégration système

ID : SO-OSTV-40-20-10

Début : 01/10/2018 Fin : 30/09/2019

Temps : 100.0

Leader : Nexedi Ressource : Nexedi Location : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Mise en place d'un mécanisme de voisinage prédictif permettant à un "OSTV Node" voisin de disposer en avance de la base des utilisateurs connectés à un autre "OSTV Node". Mise en place d'une facturation data capable de prendre en compte les échanges entre "OSTV Node" et de les refacturer entre exploitants de "OSTV Node".

Test et intégration core network

ID : SO-OSTV-40-20-20

Début : 01/10/2018 Fin : 30/09/2019

Temps : 200.0

Leader : BJT Ressource : BJT Location : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Intégration du handover entre "OSTV Node" et core network centralisé.

Nous déploierons ainsi les évolutions logicielles qui permettront à l'utilisateur de maintenir sa session en commutant en toute transparence entre un accès fourni via un "OSTV Node" et un accès fournir via le core network centralisé.

L'objectif de nos travaux est également de faire évoluer les équipements déployés afin de mettre en œuvre une architecture de type mesh, via WiFi et aussi via LTE, afin d'assurer, notamment pour le transit IP, un équilibrage dynamique de la capacité de l'eNodeB avec le besoin local des utilisateurs. Les équipements déployés dans des zones offrant une connectivité IP supérieure au besoin local pourront partager leur capacité avec des équipements déployés dans des zones voisines ne disposant pas localement d'une capacité suffisante. La technologie ainsi déployée pourra permettre un rééquilibrage durable entre le besoin et la capacité des différentes zones couvertes. On pourra aussi absorber des pointes de trafic ponctuelles qui seront alors réparties sur plusieurs points d'accès à la connectivité IP.

Le cœur de réseau unifié qui intègre l'ensemble des fonctionnalités sur un équipement unique permettra de distribuer les fonctionnalités et la capacité sur plusieurs serveurs afin de permettre de suivre l'augmentation des besoins de capacité du réseau. Dans la même optique que pour la BBU, l'ensemble des fonctionnalités du cœur de réseau unifié choisi pour notre réseau est constitué par des briques logicielles fonctionnant sur du matériel x86 standard. En plus d'utiliser une architecture distribuée, il est donc également possible de suivre l'augmentation du nombre d'utilisateurs et l'évolution de leurs usages en installant la solution logicielle sur des calculateurs offrant plus de ressources que la configuration initiale.

Adaptations eNodeB

ID : SO-OSTV-40-20-30

Début : 01/10/2018 Fin : 30/09/2019

Temps : 100.0

Leader : Amarisoft Ressource : Amarisoft Location : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Extension du logiciel eNodeB Amarisoft pour faciliter son intégration au deuxième pilote décentralisé, notamment pour tout ce qui concerne la gestion du handover entre core networks.

Les phases d’études et de spécifications ont commencé et devraient déboucher sur des spécifications fonctionnelles à implémenter.


Jalons

  1. Pilote France 1 antenne

ID : SO-OSTV-M-10

Début : 01/10/2016 Fin : 01/01/2017

Lieu : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Déploiement d'une antenne en France avec essai réussi d'eNodeB Amarisoft dans un village.


  1. Pilote Mayotte 1 antenne

ID : SO-OSTV-M-20

Début : 01/10/2016 Fin : 01/04/2017

Lieu : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Déploiement d'une antenne à Mayotte avec essai réussi d'eNodeB Amarisoft dans une ville sur le réseau BJT.


  1. Pilote Mayotte 7 antennes

ID : SO-OSTV-M-30

Début : 01/10/2016 Fin : 01/10/2017

Lieu : BJT

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Déploiement complet de la 4G à Mayotte avec eNodeB Amarisoft sur le core network BJT.

L'aménagement des sites à Mayotte en vue d’accueillir les équipements nécessaires a pris du retard.

En effet, le versement de la BPI ayant été décalé, le projet a été, faute de moyens, reporté d’autant.

Cela dit, fort de l’expérience acquise avec l’installation du premier site en service depuis novembre 2017, nous œuvrons aujourd’hui afin de combler le retard du projet.

Toutefois, pour pouvoir déployer 7 antennes et non plus seulement une seule, il nous faut trouver des fréquences disponibles sur une partie plus importante du territoire de Mayotte. Ainsi, nous devrons réaliser ces déploiements dans la bande 1 FDD dont nous disposons et qui n’est pas utilisé pour notre déploiement GSM actuellement en service.

Cela exige que AW2S nous fournisse des équipements spécialement conçus pour cette bande. Cela a entraîné du retard supplémentaire compte tenu des délais d’approvisionnement plus importants que prévu de certains composants dont AW2S a besoin pour fabriquer la RRH pour la bande 1 FDD.

Parallèlement, profitant de ce retard, la conception du POD a été améliorée. Les prototypes seront bientôt prêts à être expédiés mais, compte tenu du poids et du volume des POD, ils devront être livrés par transport maritime. En prenant en compte le transport terrestre vers le port de Marseille, les formalités douanières, l’embarquement, le transport de Marseille à Longoni, le transport prend au minimum 6 semaines, hors délai de dédouanement lors de l’importation à Mayotte.

Par ailleurs, l’entrée dans la saison des pluies (décembre à mars/avril) à Mayotte rend les points hauts inaccessibles aux engins nécessaires à l’aménagement des sites. Il nous faudra donc attendre que les chemins d’accès aux sites sèchent afin de reprendre les travaux. Cela exige un minimum de 2 semaines sans pluie. Ainsi, nous prévoyons une reprise effective des travaux d’aménagement des sites au plus tôt pour le mois d’avril.

Ainsi, ce jalon pourra être réalisé fin juillet 2018 compte tenu des contraintes terrain et matériel :


  1. Liaison data mesh entre 2 eNodeB

ID : SO-OSTV-M-100

Début : 01/10/2016 Fin : 01/10/2017

Lieu : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Preuve de la possibilité d'exploiter les trous du protocole LTE pour réaliser une liaison eNodeB à eNodeB sur un lien TDD.


  1. OSTV Cloud v1

ID : SO-OSTV-M-110

Début : 01/10/2016 Fin : 01/10/2017

Lieu : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Première version du portail OSTV : inscription des eNodeB et facturation.


  1. OSTV Node v1

ID : SO-OSTV-M-120

Début : 01/10/2016 Fin : 01/10/2017

Lieu : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Première version de l’image OSTV Node : lien avec OSTV Cloud et déploiement automatique de réseau mesh et de réseau 2G autonome.


  1. Interface mesh layer 2

ID : SO-OSTV-M-200

Début : 01/10/2016 Fin : 01/10/2018

Lieu : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Accès au réseau 4G mesh sous forme d'interface niveau 2 de type Ethernet.


  1. OSTV Cloud v2

ID : SO-OSTV-M-210

Début : 01/10/2016 Fin : 01/10/2018

Lieu : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Deuxième version de OSTV Cloud : gestion de la mise aux enchères et refacturation interne.


  1. OSTV Node v2

ID : SO-OSTV-M-220

Début : 01/10/2016 Fin : 01/10/2018

Lieu : Nexedi

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Deuxième version de OSTV Node : 4G mesh et handover data.


  1. RRH Ethernet

ID : SO-OSTV-M-230

Début : 01/10/2016 Fin : 01/10/2018

Lieu : AW2S

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Livraison de la RRH Ethernet pour OSTV Node.


  1. Norme mesh 5G

ID : SO-OSTV-M-300

Début : 01/10/2016 Fin : 01/10/2019

Lieu : Amarisoft

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Norme pour le mesh en 5G.


  1. Norme service based routing babel

ID : SO-OSTV-M-310

Début : 01/10/2016 Fin : 01/10/2019

Lieu : Paris 7

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Extension de IETF Homenet avec le routage par service.


  1. Norme RRH Ethernet

ID : SO-OSTV-M-320

Début : 01/10/2016 Fin : 01/10/2019

Lieu : AW2S

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Normalisation de l'accès RRH Ethernet dans le cadre de la 5G.


  1. POC Tour Télécom

ID : SO-OSTV-M-400

Début : 01/10/2016 Fin : 01/10/2017

Lieu : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











POC de tour de télécommunication déployée en situation réelle avec un RuggedPOD en opération


  1. Tour Télécom auto-alimentée

ID : SO-OSTV-M-410

Début : 01/10/2016 Fin : 01/10/2018

Lieu : SDS

10%

20%

30%

40%

50%

60%

70%

80%

90%

Fait











Tour de télécommunication déployée en situation réelle avec un RuggedPOD en opération et une auto-alimentation (solaire ou vent)

Etat des dépenses


Modèle de tableau de la BPI

Cf. CG annexe 1