L’interface DECT-2020 NR

I) Les applications visées par le DECT-2020-NR 

L’interface radio 5G NR+ ou DECT-2020 NR utilise les principes du DECT ULE et s’intègre avec le cœur de réseau 5G. La 5G NR+ est donc une évolution de la 5G radio non cellulaire. L’objectif de cette nouvelle interface est d’apporter une autre solution que la 5G licenciée pour les applications suivantes :

  • DECT
  • Audio Professionnels (spectacles, évènementiels) – figure 1
  • IoT – Smartgrid et Compteur intelligent
  • BIM (batiment)

Figure 1 : Applications pour l’audio professionnels

La technologie DECT NR+ est conçue pour les applications de type mMTC et URLLC.

Le DECT-2020-NR s’appuie sur la modulation OFDM avec un préfixe cyclique (CP-OFDM). Le partage d’accès se fait en TDMA/FDMA dans un duplexage en temps (TDD).

A l’instar de l’interface 5G –NR, la trame est de 10 ms et l’espacement entre sous porteuses OFDM est définie selon une numérologie de 0, 1, 2, 4 et 8. Pour être compatible avec le DECT, la durée d’un slot est de 0,41677 ms. L’espacement entre sous porteuses pour la numérologie 1 est de 27 kHz.

II) Les topologies réseaux : Simple cellule, multi-cellules et MESH

Les terminaux radios peuvent communiquer en point à point ou en point à multipoints.

On définit deux modes opérationnels de connexions :

  • Le mode de connexion fixe FT (Fixed Termination Point) pour lequel le dispositif radio (RD) initie l’allocation des ressources radios locales et transmet les informations (voie balise) aux autres dispositifs radio à l’écoute de la balise. Le dispositif radio en mode FT prendrai une partie des fonctions de la station de base en 5G
  • Le mode de connexion PT (Portable Termination Point) permet à un dispositif radio de s’associer avec un autre RD qui fonctionne en mode FT

Un dispositif radio peut fonctionner en mode PT uniquement, FT uniquement ou dans les deux modes.

Une topologie réseau implique par conséquent des RD qui fonctionnent en mode FT et en mode PT.  Le type de réseau peut être de topologie à une seule station de base (un seul RD en mode FT) ou à plusieurs stations de base (plusieurs RD en mode FT)

Chaque RD apporte une couverture radio sur sa zone de couverture et peuvent se déplacement d’une aire de couverture vers une autre aire.

La topologie MESH est également supportée pour les applications mMTC. En effet, un RD pouvant fonctionner dans les deux modes FT et PT devient un nœud intermédiaire. Ce nœud apportant une latence plus importante, cette topologie n’est pas adaptée pour les services URLLC. L’intérêt principal est la réduction de la consommation énergétique sur le lien global (entre le dispositif émettant et le dispositif récepteur).

Le routage de la topologie MESH est basée sur une optimisation du cout (minimum de saut) tout en maintenant une connectivité entre les nœuds. La décision de routage est distribuée au niveau de chaque RD à partir des ressources radio.

III) Le routage MESH

Un réseau maillé DECT-NR est un réseau dans lequel les dispositifs radios sont connectés de telle sorte qu’au moins certains, et parfois tous, aient des chemins multiples vers d’autres nœuds. Les connexions multiples augmentent la résilience du réseau.

La topologie MESH nécessite donc un routage dynamique au niveau de chaque nœud afin de définir le prochain nœud. La création d’un cluster suit les étapes suivantes :

  • Définition des RD qui ont un accès à Internet : RD en mode FT émet cette information sur une fréquence balise. Cela permet aux autres RD de s’associer à ce dernier pour un accès extérieur. L’information balise contient de plus l’allocation des ressources radios
  • Chaque RD évalue la connexion radio en fonction de la puissance de réception de la voie balise (RSRI) et chaque RD décide s’il est RD FT ou RD FT et PT avec ses voisins.

Figure 2 : Mise en place du réseau MESH [1]

Dans le cas ou un RD détecte plusieurs voies balises dont le niveau de RSSI est suffisant pour une communication bidirectionnelle, le RD définit chaque RD comme prochain nœud potentiel et choisit le RD en fonction du critère de cout de routage. Ce critère est laissé libre à l’équipementier mais peut dépendre d’une réduction du nombre de nœud, du maximum de la capacité, ou du minimum d’erreurs paquets, ou de l’énergie disponible pour le prochain nœud.

A l’issu de la procédure d’association, chaque RD est en mesure de transmettre vers le prochain nœud, chaque nœud étant identifié par une adresse RD ID de 32 bits.

IV) La couche radio

La trame radio a une durée de 10 ms découpée en slot de 0,41677 ms. Chaque slot contient 10 ou 20 ou 40 ou 80 symboles.

La couche radio utilise la modulation OFDM avec un espacement entre sous porteuses (SCS) de 27 kHz (µ=1), 54 kHz (µ=2), 108 kHz (µ=4) ou 216 kHz (µ=16).

  • Pour µ=1, la trame est composée de 10 slots.
  • Pour µ=2, la trame est composée de 20 slots.

La largeur de bande dépend du facteur β et vaut 64* β*SCS. β prend pour valeur 1, 2 , 4, 8, 12 et 16

  • Si µ=1 et β =1, on utilise une IFFT de tailles 64 soit 1728 MHz. La fréquence d’échantillonnage est de 1/1728 ms soit 5,787 10-7s
  • Si µ=2 et β =1, on utilise une IFFT de tailles 64 soit 3456 MHz. La fréquence d’échantillonnage est de 1/3456 ms soit 2,893 10-7s
  • Si µ=1 et β =2, on utilise une IFFT de tailles 128 soit 3456 MHz. La fréquence d’échantillonnage est de 1/3456 ms soit 2,893 10-7s

 

La fréquence porteuse est définie dans une bande comprise entre 450 MHz et 5875 MHz.

La couche physique réalise les fonctions suivantes :

  • Détection d’erreurs CRC
  • Codage canal par un Turbo code
  • Algorithme HARQ
  • Adaptation de débit
  • Correspondance des canaux physique sur le canal radio
  • Modulation / démodulation (BPSK, QPSK, 16-QAM, 64-QAM, 256-QAM et 1024-QAM)
  • Mesures radios
  • Diversité de transmission MISO/SIMO/MIMO

IV) Le cœur de réseau

L’interface DECT-2020-NR est une interface radio non cellulaire. Comme les points d’accès WiFi, le RD FT est connecté au cœur de réseau 5G via la fonction N3IWF.

Figure 3 : Interconnexion avec le cœur de réseau 5G

Le dispositif radio RD PT et la station de base RD FT contiennent respectivement le stack 5G NAS et NGAP afin de pouvoir communiquer avec la fonction AMF.

Références :

[1] TS 103.636-1, V1.3.1, DECT-2020 New Radio Part 1: Overview https://www.etsi.org/deliver/etsi_ts/103600_103699/10363601/01.03.01_60/ts_10363601v010301p.pdf

Du Maillage de service au Service Communication Proxy SCP

  1. Introduction : du SOA aux micro-services

L’évolution majeure entre le réseau 4G-CUPS et le réseau 5G repose sur le choix d’une architecture orientée service (demandeur de services/fournisseur de services). Les fonctions réseaux sont des composantes logicielles (NF : Network Function) ré-utilisables, qui échangent des informations les unes vers les autres à travers une interface de service SBI (Service Based Interface).

Les services sont exposés en utilisant des protocoles standards (SOAP, Thrift, JSON) permettant d’imposer le format des messages échangés. Dans le cas de la 5G, le format des données est le JSON et le protocole d’échange se fait en HTTP2. Chaque service récupère, crée ou modifie une ressource. L’écriture se fait en utilisant les commandes POST ou PUT et la lecture en utilisant la commande WGET.

 

Une composante réseau logicielle (NF) est une unité autonome qui réalise une ou plusieurs tâches.

 

Chaque fonction est conçue pour réaliser une tâche ou des tâches précises comme récupérer des informations (exemple : l’identité du mobile lors de son attachement) ou exécuter une opération (exemple : mettre en œuvre un tunnel). Une fonction contient le code logiciel et les données nécessaire pour réaliser la liste des tâches associées à cette fonction.

 

Dans une architecture orientée services, les services communiquent entre eux via un système de couplage faible. Le couplage faible permet de réduire la dépendance entre les éléments du réseau, ce qui permet d’accélérer les mises à jour de fonctionnalité du réseau pour répondre à de multiples cas d’usages (Segments verticaux du marché).

Ainsi, par rapport aux entités fonctionnelles monolithiques du cœur de réseau 4G (cf. https://blogs.univ-poitiers.fr/f-launay/2021/02/26/architecture-sba-du-reseau-5g-microservices-et-soa/), l’architecture basée sur les services permet :

  • Une plus grande flexibilité et une innovation plus rapide : la ré-utilisation des fonctions accélère la mise en production d’une application car les développeurs utilisent des lignes de codes déjà exploitables
  • Une ouverture vers des nouveaux segments (agriculture, entreprise, …) par le biais d’exposition de service (API ouvertes)
  • Une maintenance et une évolution facile : les services étant autonomes (couplage lâche), il est plus facile de les modifier sans impacter le réseau, ou de créer des fonctions évoluées pour des solutions innovantes tout en maintenant les précédentes versions.

Le concept SOA est un des pilier du Cloud Computing. Le Cloud Computing porte l’architecture SOA à une échelle plus importante (en comparaison, le Cloud Computing est au WAN ce que le SOA est au LAN).

Plus précisément, le Cloud Computing exploite des composantes logicielles pouvant communiquer entre eux sans états (stateless) nommées micro-services. Le langage de programmation d’un micro-service est indépendant des autres micro-services.

L’usage des micro-services est grandement facilité par les techniques de conteneurisation. Les micro-services faiblement couplés sont déployés dans des conteneurs et connectés via des API ou via un réseau de services maillé (MESH Service) pour le routage des messages.

Lorsque le nombre de micro-service augmente, la gestion des communications entre chaque micro-service se complexifie. Le premier rôle du maillage de service (MESH Service) est de gérer l’échange très important des données entre les micro-services.

L’architecte 5G est une architecture basée sur le service (SBA : Service Base Architecture). L’architecture SBA fournit une architecture orientée services (SOA) pour héberger des composants de plan de contrôle distincts de différents fournisseurs avec des cycles de développement disparates qui pourraient facilement inter fonctionner et interagir pour fournir un sous-système 5G complet ou une offre de services.

Avec l’architecture SOA et SBA, de nombreuses fonctions réseaux sont lancées, avec un nombre d’instances permettant de prendre en charge le trafic de signalisation. A la différence du SOA, l’architecture SBA introduit la fonction NRF qui est un annuaire listant les instances déployées : chaque instance d’une fonction de réseau annonce sa disponibilité à la fonction NRF avant d’initier une connexion est-ouest et participer à la livraison d’une application ou d’un service plus important.

Figure 1 : L’architecture SBA et la fonction de découverte NRF

Toutefois, à l’instar du SOA, la difficulté est la répartition de charge de trafic de signalisation entre les fonctions.

 

2. Le maillage de service – Service MESH

Un service MESH a pour objectif de contrôler l’échange des données de services partagées entre les instances logicielles (micro-service ou fonctions NF).

Un micro-service est conçu pour échanger des données au niveau applicatif. Le service MESH introduit une couche d’infrastructure dédiée en intégrant dans l’application des PROXYS nommés SIDECAR (imaginez le sidecar d’une moto pour prendre en charge non pas une personne mais un service) afin d’optimiser l’échange de données.

Avec le maillage de service, les requêtes s’effectuent à travers des PROXYS implémentés en sortie des micro-services.

Figure 2 : Modèle SideCar [1]

Sans Sidecar, la composante logicielle devait compiler une bibliothèque de communication spécifique au langage pour gérer la découverte de services, les routages et les exigences de communication non fonctionnelles au niveau applicatif (couche 7).

Figure 3 : De kubernetes au Maillage de services [2]

Le maillage de service permet de plus de réaliser de la surveillance réseau en fournissant des statistiques sur les performances des communications entre les services. Ces performances permettent ainsi de mettre en œuvre des fonctionnalités d’équilibrage de charge, de modification de route (exemple : la réponse d’une instance à un service met trop de temps par rapport à une autre instance pour le même service, le proxy va donc choisir cette dernière instance).

La solution de maillage de service OpenSource ISTIO [3,4] permet ainsi :

  • La gestion de trafic par une configuration des règles de services entre les micro-services
  • La sécurité en introduisant des fonctions d’authentification, d’autorisation (OAuth2) et de chiffrement des communications
  • Observabilité

Figure 4 : La journalisation des messages

3. SCP : Service Communication Proxy

Le service side-car ne fait pas nécessairement partie de l’application, mais il est connecté à celle-ci. Il est présent partout où l’application parente est présente.

Figure 5 : Le principe du maillage de service [5]

Le service n’a pas connaissance du réseau, mais ne connait que le proxy sur lequel il est connecté.

Le proxy réalisant les fonctions suivantes :

  • La découverte de services
  • Le routage
  • L’équilibrage de charges
  • L’authentification et l’autorisation
  • L’observabilité (statistique, log, traces)
  • Le bon fonctionnement (et éventuellement le transfert via une réponse 3XX ou une erreur de service 5XX)

Le standard 3GPP a introduit le proxy SCP dans la R16 [6]. De ce fait, l’architecture SBA n’a pas besoin du proxy SCP dans son principe de fonctionnement. Mais dans le cas de fonction NF multi-distribués, le SCP va résoudre les problématiques de trafic de signalisation en fournissant un point d’entrée unique pour un groupe de fonctions réseau (qui sont enregistrées dans la fonction NRF). Cela permet au SCP de devenir le point de découverte délégué dans un centre de données, déchargeant le NRF des nombreux maillages de services distribués. Les règles de routage du SCP peuvent s’appuyer sur une ressource, un numéro de téléphone ou un identifiant IMSI. Dans le monde des Télécom, par comparaison (et abus de langage), le SCP joue un rôle similaire au proxy et routeur DIAMETER. Il s’agit d’une simple comparaison, le SCP permet l’échange de signalisation dans le réseau d’un opérateur, les agents DIAMETER DRA permettaient de mettre en relation tous les HSS/MME inter-opérateurs (et auparavant, le routage de la signalisation était géré par le réseau SS7 et les points sémaphores STP).

Figure 6 : SS7 -> DIAMETER -> HTTP2 – SCP

Le SCP est un sidecar centralisé, il a pour rôle de gérer la communication de services à services s’il est impliqué. En ce sens le SCP est attaché à chaque NF. Le rôle du SCP inclut l’interfonctionnement entre NF, la segmentation des services, le contrôle d’accès centré sur les services et l’équilibrage de charge. Le SCP apporte donc une abstraction réseau ce qui permet aux développeurs d’applications d’être indépendants de l’infrastructure.

Le SCP n’est pas une fonction réseau, il n’expose pas de service contrairement aux NF. Deux fonctions NF peuvent s’échanger des services directement ou indirectement en passant par le proxy SCP.

Figure 7 : Communication directe/indirecte de deux NF [6 – Fig 7.1.1.1]

Les rôles du SCP sont :

  • D’apporter une fiabilité des services NF.

[6] 5.21.3.4 Reliability of NF Services Si une défaillance de l’instance de service NF est détectée ou notifiée par la NRF (exemple plus disponible), le consommateur de service NF ou SCP sélectionne un autre NF Service Instance de service du même ensemble de services NF dans l’instance NF.

  • De sélectionner la fonction NF adéquate : une fonction NF (consommateur de service) interroge le SCP en transmettant les attributs souhaités de la fonction NF (producteur de service). A partir de ces informations suivantes permettent au SCP de trouver la fonction SMF (DNN, capacité UE, localisation)
  • Le transfert et le routage de message de signalisation
  • Les services de sécurités (ex : autorisation qu’un consommateur de service puisse accéder à l’API d’un producteur de service)
  • L’équilibrage de charge et contrôle de surcharge de trafic
  • Surveillance du réseau
  • Optionnellement interagit avec la base de donnée unifiée UDR pour la résolution de nom (IMSI, IMPI/IMPU, Identité UDM/HSS

 

Figure 8 : Implémentation du maillage de service via le SCP

Le maillage de service et le proxy SCP ajoute de la latence. Dans le cas du service MESH, au moins deux sauts de réseau supplémentaires sont ajoutés lorsqu’un service communique avec un autre service (le premier provient du proxy qui gère la connexion sortante de la source et le second provient du proxy qui gère la connexion entrante de la destination).

Pour l’architecture SBA, la communication entre service peut être directe ou indirecte, c’est-à-dire en passant par le SCP. Quoiqu’il en soit, la latence est sur le plan de contrôle et non le plan de transport.

 

Pour en savoir plus :

  • Linkerd, Istio, Consul, Kuma et Maesh.
  • https://www.infoq.com/fr/articles/service-mesh-ultimate-guide/
  • https://carrier.huawei.com/~/media/cnbgv2/download/products/core/strategy-analytics-5g-signaling-en.pdf

Références :

[1] https://docs.microsoft.com/fr-FR/azure/architecture/patterns/sidecarTS23.501 – System architecture

[2] https://jimmysong.io/en/blog/service-mesh-the-microservices-in-post-kubernetes-era/

[3] https://istio.io/

[4]  https://www.redhat.com/fr/topics/microservices/what-is-istio

[5] https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc

[6]  TS 23.501(3GPP  version 16.6.0)  System Architecture for the 5G System.

[7] https://www.metaswitch.com/blog/the-service-communication-proxy-5g-caught-up-in-a-service-mesh