FR3129265A1

FR3129265A1 - Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d’ordinateur correspondants.

Info

Publication number: FR3129265A1
Application number: FR2112016A
Authority: FR
Inventors: Jean-Marc Kelif; Emile Stephan
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2021-11-12
Filing date: 2021-11-12
Publication date: 2023-05-19
Also published as: WO2023083763A1

Abstract

Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d’ordinateur correspondants. L’invention concerne un procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio, mettant met en œuvre les étapes suivantes, pour un flux de données dudit au moins un faisceau radio : obtention (41) du nombre de phases individuelles associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,détection (42) d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile, si une phase individuelle est disponible pour ledit flux : transmission (431) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt, si aucune phase individuelle n’est disponible pour ledit flux : transmission (432) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible. Figure pour l’abrégé : Figure 4

Description

Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d’ordinateur correspondants.

1. Domaine de l’invention

Le domaine de l’invention est celui des télécommunications.

Plus précisément, l’invention concerne les communications en voie descendante, entre un équipement intermédiaire mobile (par exemple un satellite, un avion, un ballon, un drone, une plateforme de haute altitude HIBS (« High Altitude Platform Station »), etc) et au moins un équipement utilisateur (ou UE pour « User Equipment », par exemple de type « smartphone », ordinateur portable, TV connectée, etc).

A titre d’exemple, l’invention s’applique aux réseaux de téléphonie mobile satellitaires.

Elle peut notamment, mais non exclusivement, s’appliquer aux systèmes cellulaires fondés sur une technologie d’accès de type OFDMA (en anglais « Orthogonal Frequency-Division Multiple Access »), tels que le LTE-A (en anglais « Long Term Evolution – Advanced) ou la 5G. L’invention peut également s’appliquer aux systèmes satellitaires embarquant un réseau mobile non cellulaire.

2. Art antérieur

Contrairement aux générations précédentes, la 5G propose de découper le réseau d’accès radio (RAN, en anglais « Radio Access Network ») en blocs fonctionnels, indépendants des éléments de réseau physiques. Il s’agit principalement des fonctions suivantes : une unité radio distante RU (en anglais « Remote Unit »), une unité distribuée de traitement et ordonnancement radio DU (en anglais « Distribution Unit ») et une unité centralisée vers le cœur de réseau CU (en anglais « Centralized Unit »). Plusieurs variantes de répartition de ces fonctions, appelées « splits » ont été proposées, suivant les objectifs de concentration des fonctions du RAN.

Il convient néanmoins de trouver un compromis entre les bénéfices de la centralisation et le coût des liaisons supplémentaires induites par la répartition de ces fonctions sur plusieurs éléments de réseau physiques, notamment les liaisons entre les fonctions DU et RU. En effet, chaque split a une contrainte de débit et de latence.

La présente une famille de « splits » dite intra couche physique connue de l’état de la technique (variantes 8, 7.1, 7.2 et 7.3 ), où CN correspond au cœur de réseau (en anglais « Core Network »), BH à la liaison entre le cœur de réseau et la fonction CU (en anglais « Backhaul »), MH la liaison entre les fonctions CU et DU (en anglais « Midhaul ») et FH la liaison entre les unités DU et RU (an anglais « Fronthaul »). Selon cette famille, les opérations de codage ENC/décodage DEC, de poinçonnage PUNCT/ dé-poinçonnage DE-PUNCT peuvent être mises en œuvre par la fonction DU. Les opérations de modulation MOD / démodulation DEMOD, mappage des éléments de ressource RE-MAP et démappage RE-DEMAP, et transformation IFFT / FFT peuvent être mises en œuvre par la fonction RU.

Cette famille de « splits » intra couche physique est particulièrement étudiée, grâce aux bénéfices de coopération radio entre cellules qui permettrait de réduire les interférences et augmenter le débit utilisateur (formation de faisceau – en anglais « beamforming », transmission conjointe – en anglais « joint transmission », multi-trajets – en anglais « multi-paths », etc).

La illustre les interfaces entre les fonctions réseau virtualisées CU, DU et RU.

L’interface F1 entre les fonctions CU et DU, également appelée HLS (en anglais « Higher Layer Split »), est spécifiée en partie par le 3GPP. L’alliance de normalisation O-RAN a notamment défini des scenarii de déploiement dans lesquels l’interface F1 est entièrement interopérable.

L’interface F2 entre les fonctions DU et RU, également appelée LLS (en anglais « Lower Layer Split ») ou « Open FrontHaul », est une interface ouverte (à la différence d’une interface de type CPRI (en anglais « Common Public Radio Interface ») classiquement utilisée entre une station de base et ses antennes). Elle est aussi spécifiée par le 3GGP notamment pour la variante 7.2.

En parallèle, et afin notamment d’améliorer la couverture radio dans certaines zones géographiques, des architectures de réseau 5G basées sur l’utilisation d’équipements non-terrestres pour l’accès radio (en anglais « Non Terrestrial Network »), comme des satellites, des avions ou encore des ballons, ont été proposées.

La illustre un exemple de RAN satellitaire, mettant en œuvre deux satellites SAT1 et SAT2. Chacun de ces satellites génère au moins un faisceau radio, également appelé spot. La zone géographique terrestre couverte par ce faisceau radio correspond à une cellule radio, bénéficiant d’une couverture radio. On peut donc considérer qu’un satellite émule une cellule radio. Une telle cellule radio est appelée RaF par la suite, pour RAN terrestre fixe émulé. En particulier, une telle cellule radio peut être associée à au moins un identifiant de cellule.

Selon cet exemple, un équipement utilisateur UE peut se connecter à un serveur S, par exemple un serveur web, par l’intermédiaire du réseau radio RAN comprenant le satellite SAT1 qui embarque les fonctions RU et DU selon l’architecture illustrée, et une station terrestre GW1 (en anglais « terrestrial gateway ») qui embarque la fonction CU, gérée par exemple par un centre d’opérations du réseau NoC (en anglais « Network Operations Center ») qui regroupe l’opérateur du réseau mobile MNO (en anglais « Mobile Network Operator ») et l’opérateur du réseau satellite SNO (en anglais « Satellite Network Operator »). Les routeurs entre différents réseaux de communication (réseau régional, réseau national par exemple) entre la station terrestre GW1 et le serveur S sont illustrés par un « X ».

Différentes architectures de RAN satellitaire peuvent être mises en œuvre :

« Nothing onboard », i.e. les différentes fonctions sont mises en œuvre par des équipements terrestres :
1. la fonction DU et la fonction RU sont co-localisées dans la station terrestre, et la fonction CU dans un centre de données (« data center ») distant du MNO,
2. la fonction DU et la fonction CU sont co-localisées dans un centre de données distant du MNO, et la fonction RU co-localisée avec la station terrestre,
« RU onboard » : i.e. la fonction RU est mise en œuvre par le satellite :
1. la fonction DU et la fonction CU sont distantes, et la fonction RU localisée dans le satellite,
2. la fonction DU est co-localisée avec la station terrestre, la fonction CU est distante, et la fonction RU localisée dans le satellite,
« RU+DU onboard », i.e. les fonctions RU et DU sont mises en œuvre par le satellite :
1. les fonctions RU et DU sont localisées dans le satellite, la fonction CU est distante,
2. les fonctions RU et DU sont localisées dans le satellite, la fonction CU est co-localisée avec la station terrestre,
« RU+DU+CU onboard » i.e. les fonctions RU, DU et CU sont mises en œuvre par le satellite :
1. les fonctions RU, DU et CU sont localisées dans le satellite,
2. les fonctions RU, DU, CU et UPF (en anglais « User Plane Function ») sont localisées dans le satellite.

Plus généralement, tout ou partie des fonctions virtualisées (RU, DU, CU) du RAN satellitaire peuvent être réparties sur un ou plusieurs satellites d’une constellation et une ou plusieurs stations terrestres. Comparé à un réseau d’accès radio RAN terrestre, le RAN satellitaire implique au moins une connexion radio supplémentaire, par exemple de type e-CPRI, afin de relier le satellite à la station terrestre puis au cœur de réseau mobile, voire plus lorsque les fonctions virtualisées sont réparties sur plusieurs satellites, avec l’usage de liens ISL (pour « Inter Satellite Link », en anglais) entre satellites.

Quelle que soit la configuration choisie, la distance entre ces fonctions virtualisées (et par conséquence la latence) doit être minimisée pour tenir les délais établis pour la 5G. Notamment, la latence entre la fonction RU et la fonction DU doit être inférieure à une milliseconde. Autrement dit, lorsque la fonction DU est elle aussi localisée dans l’espace (comme la fonction RU), le système est moins sensible à la latence entre le satellite et la station terrestre au moins en ce qui concerne le traitement radio mobile.

De même, la fonction CU peut aussi être placée dans la constellation de satellites, dans la station terrestre ou même dans un équipement d’un centre de données (pour « data center », en anglais) distant.

On note par ailleurs que la capacité d’un satellite à émuler une cellule 5G terrestre est limitée. En effet, du fait de la distance entre le satellite et l’équipement utilisateur (par exemple 500 km pour un RAN satellitaire au lieu de 5km pour un RAN terrestre) et/ou de l’angle du faisceau radio émulant la cellule radio, la taille de la cellule émulée est très grande (par exemple 50km de diamètre pour une cellule radio RaF émulée par un RAN satellitaire au lieu de 5km de diamètre pour une cellule terrestre associée à une antenne terrestre).

Or certaines applications, par exemple les applications Web commerciales, nécessitent de télécharger et traiter un volume important de données à l’initialisation de la connexion entre l’équipement utilisateur et le serveur de données. De la même façon, l’échange de certificats (par exemple lors des « handshake » des protocoles TLS ou QUIC) nécessite un débit important lors de l’initialisation de la connexion.

Il existe donc un besoin pour fournir un débit minimum aux équipements utilisateurs en début de connexion, notamment lorsqu’ils sont présents dans une cellule émulée par un RAN satellitaire, ou plus généralement émulée par un équipement intermédiaire mobile (i.e. distinct d’une station fixe terrestre) entre l’équipement utilisateur et un serveur de données.

3. Exposé de l’invention

L’invention propose une solution ne présentant pas l’ensemble des inconvénients de l’art antérieur, sous la forme d’un procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio.

Selon l’invention, un tel procédé met en œuvre les étapes suivantes, pour un flux de données dudit au moins un faisceau radio :

obtention du nombre de phases individuelles, associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,
détection d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
si une phase individuelle est disponible pour ledit flux : transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt,
si aucune phase individuelle n’est disponible pour ledit flux : transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible.

Par phase individuelle, on entend ici un ensemble de ressources radio du flux de données du faisceau radio, utilisé pour les transmissions entre l’équipement intermédiaire mobile et la cellule radio, permettant d’atteindre un débit cible. Plus généralement, si le flux dispose deNphases individuelles ( ), cela signifie qu’il dispose de ressources radio disponibles pour les transmissions entre l’équipement intermédiaire mobile et la cellule radio permettant d’atteindreNdébits cibles. Par exemple, deux utilisateurs présents dans la cellule radio peuvent recevoir simultanément le flux de données portant d’une part des données de début de connexion à un premier débit cible en provenance du premier serveur de données, et d’autre part des données de début de connexion à un deuxième débit cible en provenance d’un deuxième serveur de données. Les débits cibles peuvent être différents.

L’invention propose ainsi d’estimer la capacité d’une cellule radio émulée par un faisceau radio, i.e. le nombre d’équipements utilisateurs pouvant simultanément recevoir des données avec un débit cible, correspondant au nombre de phases individuelles du flux de données. De cette façon, à chaque nouvelle connexion d’un équipement utilisateur, il est possible de vérifier si une phase individuelle est disponible, et si tel est le cas, de transmettre les données de début de connexion sur la phase individuelle du flux, i.e. avec le débit cible de la phase individuelle.

La solution proposée permet ainsi, selon au moins un mode de réalisation, d’améliorer la qualité de l’expérience utilisateur en accélérant le début des connexions.

Le reste de la bande passante radio, non utilisé par la ou les phases individuelles, peut être utilisé par les connexions des autres équipements utilisateurs, notamment pour la transmission de données de « poursuite » de connexion.

La solution proposée permet ainsi, selon au moins un mode de réalisation, d’utiliser de façon efficace l’ensemble de la bande passante radio.

Par exemple, lorsqu’un équipement utilisateur se connecte à une application Web, il est possible de fournir dès le début de la connexion un débit cible d’environ 8 Mbps (soit un volume de 2 Mega octets de données durant une durée de 2 secondes) afin de supporter des interactions à un rythme suffisamment élevé pour maintenir l’attention et la confiance des utilisateurs.

Pour la suite de la connexion, le débit nécessaire dépend des usages et de l’activité de l’utilisateur. Il est souvent moindre compte tenu de la réutilisation des données téléchargées au début de connexions par l’application Web (CSS, librairies javascript, images en cache…), et du temps de traitement des données (par exemple la concentration de l’attention de l’utilisateur sur la page en cours). Ainsi, la transmission des données entre l’équipement intermédiaire mobile et l’équipement utilisateur peut s’effectuer au débit cible de la phase individuelle jusqu’à un critère d’arrêt, puis à un débit inférieur au débit cible.

En particulier, ces différentes étapes peuvent être mises en œuvre par un même équipement (par exemple un équipement géré par l’opérateur de l’équipement intermédiaire ou un équipement géré par l’opérateur de l’équipement utilisateur). En variante, du fait de la virtualisation de certaines fonctions, ces étapes peuvent être mises en œuvre par différents équipements (par exemple les étapes d’obtention du nombre de phases individuelles et de détection d’un début de connexion peuvent être mises en œuvre par au moins un équipement géré par l’opérateur de l’équipement utilisateur, et les étapes de transmission par au moins un équipement géré par l’opérateur de l’équipement intermédiaire).

Selon un mode de réalisation particulier, le nombre de phases individuelles du flux du faisceau radio est défini à partir d’au moins un paramètre appartenant au groupe comprenant :

ledit débit cible ,
une puissance d’émission dudit équipement intermédiaire mobile,
un facteur de propagation entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,
une bande passante dudit équipement intermédiaire mobile,
un angle d’ouverture de l’antenne d’émission dudit équipement intermédiaire mobile,
une distance entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,
un nombre de faisceaux radio interférents entre ledit équipement intermédiaire mobile et au moins une autre cellule radio,
un bruit thermique ,
la variance, ou écart-type, de l’effet de masque (en anglais « shadowing ») ,
une probabilité de non-couverture .

La capacité d’une cellule radio dépend donc des caractéristiques du faisceau radio généré par l’équipement intermédiaire.

En particulier, un tel équipement intermédiaire est mobile, i.e. distinct d’une station terrestre fixe. Il s’agit par exemple d’un équipement terrestre ou d’un équipement non-terrestre, comme un satellite, un avion, un ballon, un drone, une HIBS etc.

Un tel équipement intermédiaire est également appelé équipement d’accès, en ce qu’il peut se connecter directement à un équipement utilisateur (i.e. sans passage par une antenne terrestre fixe).

Selon un mode de réalisation particulier, le nombre de phases individuelles du flux est égal à la partie entière de la capacité du faisceau radio généré par l’équipement intermédiaire mobile :

)

avec :

).

La partie décimale de la capacité correspond au débit restant pour les transmissions en dehors de la ou des phases individuelles, dites de « poursuite ».

La solution proposée selon ce mode de réalisation permet ainsi de déterminer simplement la répartition des ressources radio du flux, entre la ou les phases individuelles et le reste du flux. La répartition selon ce mode de réalisation se fait par une division entière et un modulo.

Par exemple, le critère d’arrêt d’une transmission au débit cible d’une phase individuelle appartient au groupe comprenant :

une période donnée (par exemple de l’ordre de 2 à 4 secondes),
un volume donné (par exemple de l’ordre de 2 à 4 méga-octets),
une fin de connexion dudit premier équipement utilisateur avec ledit premier serveur de données,
une détection d’un début de connexion d’un deuxième équipement utilisateur, présent dans ladite cellule radio, à un deuxième serveur de données prioritaire par rapport audit premier serveur de données.

Ainsi, il est possible de libérer une phase individuelle du flux après le début de la connexion, puisque la « poursuite de connexion » nécessite en général un débit inférieur au « début de connexion ». La libération d’une phase individuelle du flux permet à un autre équipement utilisateur de bénéficier du débit cible en début de connexion (ou au premier équipement utilisateur de bénéficier du débit cible en début de connexion pour une nouvelle connexion).

Ainsi, selon la solution proposée, les connexions « établies » (également appelées « poursuite de connexion ») ne capturent pas toute la bande passante radio, et des ressources radio restent disponibles pour de nouvelles connexions.

Ce point est important parce que les contrôles de congestion des connexions de bout en bout deviennent de plus en plus agressifs et préemptent un maximum de bande passante au détriment des nouvelles connexions.

Selon un mode de réalisation particulier, le critère d’arrêt d’une transmission au débit cible d’une phase individuelle dépend d’un type de service ou du domaine demandé.

Ainsi, si le service ou le domaine demandé est de type vidéo par exemple, le temps alloué pour la phase individuelle peut être plus long, par exemple de l’ordre de 4 à 10 secondes, ou le volume de données alloué pour la phase individuelle peut être supérieur, par exemple de l’ordre de 4 à 10 mégaoctets.

Il est également possible de libérer une phase individuelle du flux si un équipement utilisateur souhaite établir une connexion avec un service d’urgence.

Selon un mode de réalisation particulier, l’étape d’obtention du nombre de phases individuelles est mise à jour :

périodiquement, ou
suite à une modification d’un paramètre dudit équipement intermédiaire mobile, ou
suite à une modification d’un paramètre du faisceau radio généré par l’équipement intermédiaire mobile, ou
suite à une modification dudit critère d’arrêt.

Le nombre de phases individuelles du flux peut ainsi être ajusté dynamiquement, notamment de manière asynchrone. Par exemple, le nombre de phases individuelles peut être augmenté suite à un besoin du cœur de réseau 5G du à une saturation ou un incident sur une cellule terrestre appartenant à la zone géographique terrestre couverte par le faisceau radio .

Selon un mode de réalisation particulier, l’étape de détection d’un début de connexion met en œuvre la détection d’un échange de données de sécurisation de la connexion entre ledit premier équipement utilisateur et ledit premier serveur de données.

Selon un mode de réalisation particulier, la détection d’un début de connexion comprend :

l’identification des données de début de connexion, à partir d’au moins un marqueur inséré par un module de type RRC (en anglais « Radio Resource Control ») dans au moins un paquet de données en provenance dudit premier serveur de données,
l’insertion des données de début de connexion dans ladite phase individuelle disponible pour ledit flux par un module de type MAC (en anglais « Medium Access Layer »).

Selon ce mode de réalisation, la solution proposée encourage ainsi l’exposition de la signalisation de bout en bout des connexions.

Selon un mode de réalisation particulier, le procédé met en œuvre le stockage d’informations relatives à ladite au moins une phase individuelle dans une table de gestion des phases individuelles.

En particulier, seules les informations relatives à la ou aux phases individuelles sont stockées dans une table. De cette façon, la taille des données stockées est faible.

L’invention concerne également un système de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio.

Selon l’invention, un tel équipement comprend, pour un flux de données dudit au moins un faisceau radio :

un module d’obtention du nombre de phases individuelles associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,
un module de détection d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt, activés si une phase individuelle est disponible pour ledit flux,
un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible, activés si aucune phase individuelle n’est disponible pour ledit flux.

Par exemple, un tel système comprend un ou plusieurs équipements gérés par l’opérateur de l’équipement intermédiaire (par exemple l’opérateur satellite) et/ou l’opérateur de l’équipement utilisateur.

Ces différents modules peuvent notamment être co-localiés ou distants. Par exemple, les modules d’obtention du nombre de phases individuelles et de détection d’un début de connexion appartiennent à au moins un équipement géré par l’opérateur de l’équipement utilisateur, et les modules de transmission appartiennent à au moins un équipement géré par l’opérateur de l’équipement intermédiaire. Selon un autre exemple, certains modules peuvent être localisés sur des satellites différents.

Selon d’autres modes de réalisation, ces différents modules correspondent à des blocs fonctionnels, qui peuvent être co-localisés ou distants.

L’invention concerne encore un ou plusieurs programmes d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de gestion des communications tel que décrit ci-dessus lorsque ce ou ces programmes sont exécutés par au moins un processeur.

4. Liste des figures

D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :

- la , introduite dans la partie art antérieur, illustre la virtualisation des fonctions d’un réseau d’accès radio selon la norme 5G ;

- la , également introduite dans la partie art antérieur, illustre les interfaces entre les différentes fonctions virtualisées d’un réseau d’accès radio selon la norme 5G ;

- la , également introduite dans la partie art antérieur, présente un exemple d’architecture de réseau d’accès radio comprenant un satellite ;

- la présente les principales étapes mises en œuvre par le procédé de gestion des communications selon un mode de réalisation particulier de l’invention ;

- la présente les principales étapes mises en œuvre lorsqu’un équipement utilisateur cherche à se connecter à un serveur, via l’équipement intermédiaire mobile ;

- la illustre un exemple d’architecture de réseau d’accès radio comprenant un satellite selon un mode de réalisation de l’invention ;

- la illustre les messages échangés entre les différentes entités du réseau d’accès radio selon la ;

- la présente la structure simplifiée d’au moins un équipement d’un système de gestion des communications selon un mode de réalisation particulier.

5. Description d’un mode de réalisation particulier

5.1 Principe général

L’invention se place dans le contexte d’un réseau de communication mettant en œuvre un équipement intermédiaire mobile de transmission (i.e. au moins une antenne radio qui se déplace, par exemple un satellite, un avion, un ballon, un drone, une HIBS, etc), et propose une solution pour améliorer les communications via l’équipement intermédiaire mobile de transmission.

Le principe général de l’invention repose sur l’estimation du nombre de phases individuelles disponible dans le flux de données du faisceau radio généré par l’équipement intermédiaire mobile de transmission et émulant une cellule radio, et sur l’allocation d’une phase individuelle en début de connexion (si une phase individuelle est disponible) permettant une transmission des données à un débit souhaité (dit débit cible) en début de connexion. La solution proposée permet ainsi d’accélérer le début des connexions.

La illustre les principales étapes pour la gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement utilisateur et au moins un équipement intermédiaire mobile.

On considère un équipement intermédiaire mobile générant un faisceau radio « éclairant » une cellule radio, également appelée RaF. Le flux de données du faisceau radio émis par l’équipement intermédiaire mobile est reçu par l’ensemble des équipements utilisateurs présents dans la cellule radio. Un tel flux peut donc porter des données destinées aux différents équipements utilisateurs, sous la forme d’un multiplex.

Au cours d’une première étape 41, on obtient le nombre de phases individuelles, associées chacune à un débit cible dans le flux, à servir pour des transmissions de l’équipement intermédiaire mobile vers la cellule radio.

Au cours d’une deuxième étape 42, on détecte qu’un premier équipement utilisateur, présent dans la cellule radio, se connecte avec un premier serveur de données, via l’équipement intermédiaire mobile.

On vérifie alors (43) si une phase individuelle est disponible (i.e. si des ressources radio pour la transmission au débit cible sont disponibles).

Si une phase individuelle est disponible pour le flux (431) : les données de début de connexion en provenance du premier serveur de données peuvent être transmise, entre l’équipement intermédiaire mobile et le premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt.

Par exemple, le critère d’arrêt appartient au groupe comprenant :

une période donnée ,
un volume donné ,
une fin de connexion du premier équipement utilisateur avec le premier serveur de données,
une détection d’un début de connexion d’un deuxième équipement utilisateur, présent dans la cellule radio, à un deuxième serveur de données prioritaire par rapport audit premier serveur de données,
etc.

Si aucune phase individuelle n’est disponible pour le flux (432) : les données de début de connexion en provenance du premier serveur de données peuvent être transmise, entre l’équipement intermédiaire mobile et le premier équipement utilisateur, à un débit inférieur au débit cible de la phase individuelle.

On utilise de cette façon la bande passante radio de façon efficace, en réservant une partie de la bande passante pour les débuts de connexion et le reste de la bande passante pour la poursuite des connexions.

Il est ainsi possible de servir une ou plusieurs connexions à la fois, par exemple à un débit pour une nouvelle connexion et pour une poursuite de connexion, en utilisant toute la bande passante radio. Si on considère ressources radio pour la transmission de données dans le flux du faisceau radio, on a ,

avec :

le nombre de phases individuelles,

le nombre de ressources radio permettant d’atteindre un débit cible (i.e. utilisées pendant la phase individuelle) ;

le nombre de ressources radio restantes.

On note que les différentes étapes présentées ci-dessus peuvent être mises en œuvre par l’équipement intermédiaire mobile ou par un équipement géré par l’opérateur de l’équipement intermédiaire mobile. Toutefois, du fait de la virtualisation de certaines fonctions, certaines étapes pourraient être mises en œuvre par un équipement non mobile, par exemple une station fixe terrestre.

5.2 Description d’un mode de réalisation particulier

On présente ci-après un exemple de mise en œuvre de l’invention.

On considère par exemple que l’équipement intermédiaire mobile est un satellite, géré par un opérateur de réseau satellite SNO. Un tel satellite est appelé satellite d’accès, en ce qu’il peut se connecter directement à un équipement utilisateur.

Le SNO, par exemple l’OSS (« Operations Support System »), configure un RAN satellitaire.

Par exemple, un satellite peut générer un ou plusieurs faisceaux radio, également appelés spots. Les caractéristiques du satellite, ou des faisceaux radio du satellite, peuvent être définis à partir de différents paramètres :

Paramètre	Définition
	puissance d’émission du spot
	facteur de propagation qui dépend de la fréquence
	bande passante (MHz) du spot
	, avec le débit cible (Mbits/s) d’une phase individuelle du flux
	nombre de spots interférents
	écart type du shadowing (dB)
,	bruit thermique au récepteur (constante)
	distance satellite - récepteur
	angle d’ouverture de l’antenne d’émission du spot, typiquement 2 à 5 degrés

Table 1 : Table des caractéristiques (paramètres) des spots

Ces paramètres peuvent être différents pour chaque spot généré par le satellite. En particulier, certains paramètres peuvent être liés aux caractéristiques physiques des équipements (satellite notamment), aux caractéristiques souhaitées par l’opérateur de réseau mobile MNO (par exemple un débit de réception de 5Mbps en début de connexion pour un équipement utilisateur, etc), etc.

Par exemple, les paramètres P de puissance d’émission du spot, W de bande passante du spot peuvent être choisis par le SNO, et le paramètre correspondant au débit cible d’une phase individuelle peut être choisi par le MNO.

Ainsi, pour chaque spot, l’OSS du SNO collecte les différentes informations d’états du satellite (états principaux et caractéristiques principales de la propagation) et des besoins (venant par exemple par les MNOs) et les stocke dans une table.

Un exemple de table d’états des spots est donné ci-après, pour des satellites en orbite basse à environ 500km :

Spot_ID			_UE
1	45 dBm	10 MHz	5 Mbits/s	6	mW	500 km
2	50 dBm	10 MHz	6 Mbits/s	6	mW	600 km
…	50 dBm	10 MHz	5 Mbits/s	6	mW	700 km
1000	55 dBm	10 MHz	5 Mbits/s	6	mW	600 km

Table 2 : Table d’états des spots

Cette table peut notamment être échangée entre l’OSS du SNO et le satellite.

Le nombre de phases individuelles d’un flux de données d’un spot peut être déterminé à partir d’un ou plusieurs paramètres définis dans les tables ci-dessus.

Par exemple, le nombre de phases individuelles du flux est égal à la partie entière de la capacité du faisceau radio, telle que :

) (1)

avec :

(2)
(3)
) (4) et
.

En d’autres termes, considérant un utilisateur utilisant un service donné avec une contrainte de débit minimum (débit cible), et utilisant une bande passante W, la solution proposée permet d’établir la capacité d’un spot à l’aide de l’expression (1) ci-dessus.

Cette capacité caractérise le nombre d’équipements utilisateurs recevant simultanément des données avec le débit cible . Autrement dit, cette expression répond aux contraintes en termes de débit minimum à atteindre par chaque équipement utilisateur.

La capacité du faisceau radio, à un instant donné, tient notamment compte :

de la valeur moyennemde la puissance reçue par l’équipement utilisateur,
des contraintes liées à l’environnement de l’équipement utilisateur au sol, caractérisées par l’écart type due au shadowing, au niveau du récepteur connecté à un spot donné. On note que la valeur de ce dernier paramètre peut être fournie par le MNO pour chaque RAN émulé,
de la probabilité de non-couverture , ou probabilité « d’outage ». Il s’agit de la probabilité qu’il n’y ait pas suffisamment de ressources radio pour une transmission au débit cible au moment où l’équipement utilisateur se connecte. En d’autres termes, l’équipement utilisateur a une probabilité de ne pas pouvoir se connecter au spot avec le débit cible . Cette valeur peut également être choisie par le MNO.

En effet, comme le spot doit fournir un service sur une zone donnée, avec une probabilité de non couverturePoutgarantie par l’opérateur, ces contraintes ont un impact sur la détermination de la capacité du spot.

La capacité peut également s’exprimer sous la forme suivante :

On obtient ainsi le nombre de connexions (i.e. de phases individuelles de flux) pouvant recevoir le débit cible sous contrainte de pendant une durée donnée.

La partie décimale de la capacité correspond au débit restant pour les transmissions en dehors de la ou des phases individuelles.

Les paramètres, notamment la probabilité de non-couverture , peuvent être ajustés pour augmenter le nombre de phases individuelles quand nécessaire. La probabilité de non-couverture peut notamment être choisie parmi une liste de valeurs possibles ( ; etc). Ces différentes informations peuvent être ajoutées dans la table d’états des spots.

Spot_ID			Commentaire
1	;	2	appartenant à un intervalle permettant d’obtenir si possible 2 phases individuelles
2	;	1	appartenant à un intervalle permettant d’obtenir une seule phase individuelle
…
1000	;

On distingue ainsi plusieurs phases dans le flux du faisceau radio ainsi généré : au moins une phase individuelle, notée DebCo, servant les données du début de chaque connexion, et une phase dite « commune », notée ContCo, regroupant les données suivantes des connexions existantes.

Comme indiqué précédemment, ces différentes phases permettent notamment d’utiliser efficacement la bande passante radio et d’améliorer la qualité de l’expérience utilisateur.

En particulier, le nombre de phases individuelles peut être mis à jour :

périodiquement, ou
suite à une modification d’un paramètre de l’équipement intermédiaire mobile, ou
suite à une modification d’un paramètre du faisceau radio généré par l’équipement intermédiaire mobile, ou
suite à une modification d’un critère d’arrêt,
etc.

Par exemple, périodiquement ou de manière asynchrone (sur évènement, par exemple, suite à un besoin du cœur 5G du une saturation ou un incident sur un RAN terrestre), l’OSS du MNO estime le nombre de nouvelles connexions à servir par le RAN satellitaire, puis détermine ou met à jour les différents paramètres à partir de l’expression (1) ci-dessus et de la table courante des états des spots, notamment :

les phases individuelles en cours d’utilisation dans les connexions (i.e. le nombre de connexions recevant le débit cible),
le nombre de nouvelles connexions pouvant recevoir le débit cible sous contrainte de pendant une durée donnée, correspondant à ,
le débit individuel , en Mbps, par exemple 5 Mbps,
la durée du débit individuel (i.e. la durée d’une phase individuelle), en seconde, par exemple 3 s,
ou le volume individuel (i.e. le volume de données transmis dans une phase individuelle), en Mo, par exemple 2,5 Mo,
la probabilité de non-couverture .

Ces différents paramètres peuvent également être ajoutés dans la table d’états des spots.

En particulier, les valeurs de , , et peuvent être ajustées dynamiquement pour optimiser le multiplexage statistique.

Ces paramètres peuvent notamment être choisis en fonction du service ou du domaine du serveur demandé. Par exemple, une connexion vers un domaine video.example.com peut obtenir au démarrage le double de temps ou de mega octets par rapport à des valeurs par défaut.

L’OSS du MNO ou du SNO peut notamment mettre à jour ces paramètres pour les connexions existantes en cours. Par exemple, si un équipement utilisateur se connecte à un service d’urgence, l’OSS peut raccourcir (au moins temporairement) la durée d’une phase individuelle d’une connexion existante, pour libérer la phase individuelle de la connexion existante. De cette façon, le satellite peut récupérer la phase individuelle pour le début de connexion de l’équipement utilisateur avec le service d’urgence.

L’OSS du SNO peut notamment communiquer cette table d’états des spots au satellite.

On décrit ci-après, en relation avec la , les différentes étapes mises en œuvre lorsqu’un équipement utilisateur cherche à se connecter à un serveur, via l’équipement intermédiaire mobile. Ces différentes étapes permettent de générer, en sortie du satellite, un flux de données distribué sur l’ensemble de la cellule radio.

Au cours d’une première étape 51, un module RRC cherche à détecter les nouvelles connexions dans le flux des paquets IP reçus en entrée du satellite, à partir de la signalisation de début de connexion, de la taille, de l’encodage, de la signature temporelle des paquets, des champs des entêtes des paquets IP identifiant le flux IP (adresse source, adresse destination, protocole, port source, port destination, etc). En variante, une telle étape peut être mise en œuvre par un module RLC (en anglais « Radio Link Control »), voire MAC.

On considère par exemple qu’un équipement utilisateur présent dans la cellule radio cherche à se connecter à un site internet monexemple.com, hébergé sur un serveur de données. Une phase de négociation est classiquement mise en œuvre entre l’équipement utilisateur et le serveur de données, via le satellite si l’on considère un RAN satellitaire.

Par exemple, lors de l’établissement d’une connexion HTTPS, un processus de type « Handshake TLS » est mis en œuvre entre l’équipement utilisateur et le serveur de données, via le satellite. Ce processus inclut une phase non chiffrée lors du téléchargement des certificats. Le module RRC peut ainsi détecter les différentes phases des connexions sécurisées des protocoles QUIC, TLS, DTLS, EDHOC et similaires, et détecter le début d’une connexion internet.

Si l’on considère le protocole QUIC, le module RRC peut identifier à partir de la taille, de l’encodage, et/ou de la présence d’un message de type « ClientHello » les phases transportant les certificats correspondant à une première connexion (QUIC 1-RTT), des phases de reconnexion avec reprise de sessions (reprise du contexte de la connexion précédente, dite QUIC 0-RTT crypto).

Le module RRC peut ainsi détecter le début d’une nouvelle connexion.

Le module RRC peut également classer les paquets reçus (comme étant à transmettre sur une phase individuelle ou sur une phase commune) à partir de la signalisation de début de connexion, de la taille, de l’encodage, de la signature temporelle des paquets …

Si l’on considère le protocole QUIC ou TLS, le module RRC peut identifier à partir de la présence d’un message de type « ClientHello » les phases transportant les certificats correspondant à une première connexion (QUIC 1-RTT), des phases de reconnexion avec reprise de sessions (reprise du contexte de la connexion précédente, dite QUIC 0-RTT crypto) et classer les phases 1-RTT pour les transmettre sur une phase individuelle et les phases 0-RTT pour les transmettre sur une phase commune.

Optionnellement, pour éviter qu’un équipement utilisateur se connecte de multiples fois avec le même serveur pour bénéficier à chaque fois de la phase individuelle qui permet d’atteindre un débit cible (i.e. « charding » consistant à créer plus de connexion pour capturer plus de bande passante), une connexion peut être identifiée au niveau 3 (adresse source, adresse destination, protocole, port source, port destination, etc).

A détection d’un début de connexion, le module RRC peut transmettre un indicateur de début de connexion DebCoFlag au module RLC au cours d’une étape 521, ou directement au module MAC au cours d’une étape 522.

Selon un premier exemple, un tel indicateur de début de connexion peut être destiné au module RLC. Ainsi, un tel indicateur de début de connexion peut être inséré dans un entête propriétaire ou à la place d’un bit inutilisé, par exemple un bit réservé du protocole QUIC, par exemple le « spin bit ». Afin de permettre une interopérabilité, un tel indicateur de début de connexion peut en variante être inséré dans un message non propriétaire, par exemple l’entête iOAM (« In-situ OAM), un message ECN (« Explicit Congestion Notification »), etc.

Selon un deuxième exemple, un tel indicateur de début de connexion est directement envoyé au module MAC.

La détection d’un tel indicateur de début de connexion permet d’identifier les paquets des flux IP reçus par le satellite qui doivent être transmis dans la ou les phases individuelles en sortie du satellite.

Éventuellement, un indicateur de fin de connexion FinCoFlag peut être transmis au module RLC ou au module MAC. En variante, une information de durée DebCoDuration ou de volume DebCoVol peut être transmise au module RLC ou au module MAC. Il est ainsi possible de marquer tous les paquets successifs comme étant à transmettre sur une phase individuelle, ou uniquement le premier et le dernier paquet concernés.

Encore en variante, l’indicateur de début de connexion DebCoFlag peut être un entier correspondant à DebCoDuration ou à DebCoVol.

Cet indicateur de fin de connexion FinCoFlag, ou ces informations DebCoDuration ou DebCoVol, peuvent être utilisées pour déterminer quand arrêter la transmission dans la ou les phases individuelles en sortie du satellite.

Selon le premier exemple présenté ci-dessus (indicateur de début de connexion destiné au module RLC), si le module RLC reçoit un indicateur de début de connexion DebCoFlag, il peut l’ajouter (54) dans les premières trames (ou « subframes ») destinées au module MAC, puis transmettre les premières trames avec l’indicateur de début de connexion DebCoFlag.

Si l’indicateur de début de connexion DebCoFlag est un entier correspondant à la durée DebCoDuration, il peut être décrémenté avec le temps (par exemple, si DebCoDuration est égal à 5 secondes, la première trame porte l’indicateur 5, la deuxième trame porte l’indicateur 4, …, la cinquième trame porte l’indicateur 1 et la sixième trame ne porte pas d’indicateur).

Si l’indicateur de début de connexion DebCoFlag est un entier correspondant au volume DebCoVol, il peut être décrémenté en tenant compte de la taille de chaque trame.

Passé ce délai DebCoDuration, ou une fois atteint ce volume DebCoVol, ou à détection d’un indicateur de type fin de connexion FinCoFlag, le module RLC ne marque plus les trames (i.e. n’insère plus d’indicateur dans les trames).

Selon un mode de réalisation particulier, en l’absence de ressource radio, le module RLC ne transmet pas au module MAC les trames non marquées. En variante, selon le type du module RLC (par exemple « Transparent Mode (TM) », « Unacknowledged Mode (UM) » ou « Acknowledged Mode (AM) », tel que défini par exemple dans la spécification technique 3GPP TS 38.322 version 15.3.0 Release 15), le module RLC ne transmet pas au module MAC les trames non marquées. Ces trames sont considérées comme jetées ou « poubellisées ».

Par ailleurs, si le module RLC ne reçoit pas d’indicateur de début de connexion DebCoFlag, il peut directement transmettre les premières trames au module MAC, sans les marquer.

A réception des trames marquées selon le premier exemple présenté ci-dessus (indicateur de début de connexion destiné au module RLC), le module MAC détecte l’indicateur de début de connexion inséré dans les trames par le module RLC, et émet (55) les trames dans la phase individuelle du flux de données.

Par exemple, le module MAC identifie les données de début de connexion à partir d’au moins un marqueur/indicateur inséré par le module RRC dans au moins un paquet de données en provenance du premier serveur de données (premières trames). Le module MAC peut ainsi insérer les données de début de connexion dans la phase individuelle du flux du faisceau radio.

Si le module MAC reçoit d’une part des trames non marquées du module RLC et d’autre part l’indicateur de début de connexion en provenance du module RRC selon le deuxième exemple présenté ci-dessus (indicateur de début de connexion destiné directement au module MAC), il peut directement émettre (55) les trames identifiées à partir de l’indicateur de début de connexion dans la phase individuelle du flux de données.

Le module MAC peut émettre les trames restantes dans la phase commune (i.e. avec un débit inférieur au débit cible) s’il lui reste des ressources.

Selon un mode de réalisation particulier, en l’absence de ressource radio, le module MAC ne transmet pas les trames restantes. Ces trames sont considérées comme jetées ou « poubellisées ».

Dans le mode de réalisation décrit ci-dessus, on suppose que les modules RRC, RLC et MAC sont co-localisés dans le satellite. En variante, le module RRC et/ou le module RLC peuvent être distants, et notamment localisés dans un équipement terrestre fixe.

A titre d’exemple, on détaille ci-après en relation avec les figures 6 et 7 la génération d’un RAN satellitaire et la mise en œuvre de la solution proposée pour fournir un débit minimum aux services d’urgences par exemple.

Par exemple, des RAN satellitaires peuvent être déployés pour compléter ou remplacer les RAN terrestres :

la nuit ou en heure creuse pour arrêter les antennes terrestres et diminuer la puissance consommée et les radiations émises ;
en cas de panne d’un RAN terrestre ;
pour délester un RAN terrestre aux heures de pointe ;
pour effectuer la maintenance d’un RAN terrestre ;
etc.

L’exemple ci-dessous développe le cas de la maintenance d’un RAN terrestre d’un MNO. Un exemple d’usage du procédé par un MNO consiste à utiliser la capacité d’un RAN satellitaire lors d’une opération de maintenance planifiée d’un RAN terrestre (par exemple changement de carte, redémarrage…). Cette opération peut être réalisée la nuit en heure creuse. Le RAN satellitaire doit avoir une capacité minimale suffisante pour remplacer le RAN terrestre, notamment pour fournir du débit aux services d’urgences.

On se place dans le contexte du réseau de la , selon lequel un satellite SAT génère un faisceau radio 61 émulant une cellule radio (RaF), dans laquelle trois équipements utilisateurs UE1, UE2 et UE3 sont présents.

Le satellite SAT est connecté au réseau terrestre 62 (comprenant l’opérateur du réseau satellite SNO et l’opérateur du réseau mobile MNO) par l’intermédiaire d’une passerelle terrestre GW. Les équipements utilisateurs UE1, UE2 et UE3 peuvent se connecter à l’un ou l’autre des serveurs S1, S2 et/ou S3 via le satellite SAT.

La illustre les messages échangés entre les différentes entités, selon un mode de réalisation de l’invention.

Au cours d’une première étape 71, l’OSS du SNO configure le satellite SAT. Par exemple, l’OSS du MNO transmet des messages de type « bootstrapping » et configuration aux différents modules du satellite SAT (RRC, RLC et MAC notamment).

A titre d’exemple, on considère que le MNO souhaite effectuer la maintenance d’un RAN dont la cellule est à la position géographique Pgeo. Le cœur 5G de ce MNO demande la création d’un RaF RaF1 (61) dont les caractéristiques sont décrites par une entrée d’une table d’états des spots, telle que la table 2 présentée ci-dessus.

On considère par exemple que le nombre de phases individuelles du flux de données du spot est égal à 1. Le RaF RaF1 implémente donc une unique phase individuelle associée à un débit cible. Le débit inutilisé par la phase individuelle du flux de données est utilisé par une phase dite commune.

Le SNO peut ainsi générer le RaF1 dans le satellite avec ces valeurs.

Le SNO peut également créer une table de gestion des phases individuelles, permettant de suivre la ou les phases individuelles du flux de données du faisceau radio du RaF1. Une telle table de gestion peut également être prévue dans la table d’états des spots.

Au cours d’une étape suivante 72, dite « boucle de contrôle », le MNO collecte les différentes informations d’états du satellite et des besoins (par exemple , , , , etc) et les transmet au SNO. Le SNO peut notamment déterminer la capacité du Raf Raf1 à partir de ces informations.

Par exemple, l’OSS/BSS du cœur de réseau 5G (MNO) estime le nombre de nouvelles connections à servir par le RAN satellitaire puis à l’aide du traitement analytique de calcul de la capacité présenté ci-dessus, et de la table d’état des spots du satellite et/ou de la table de gestion des phases individuelles (l’informant notamment du nombre de phases individuelles en cours d’utilisation), il met à jour :

le nombre de nouvelles connexions pouvant recevoir le débit cible (i.e. le nombre de connexions disposant d’une phase individuelle DebCo, correspondant à ) ;
le débit individuel , en Mbps, par exemple 5 Mbps ;
la durée du débit individuel, en seconde, par exemple 3 s ;
ou le volume individuel , en Mo, par exemple 2,5 Mo ;
la probabilité de non-couverture .

Le MNO peut également compléter et/ou mettre à jour la table de gestion des phases individuelles avec ces différentes valeurs.

On note que les valeurs de , , et peuvent être ajustées dynamiquement pour optimiser le multiplexage statistique. Il s’agit d’une plage d’ajustement de chaque paramètre par rapport à la valeur nominale. Par exemple, l’étape d’estimation du nombre de nouvelles connexions à servir par le RAN satellitaire génère cinq scenarii à l’aide du traitement analytique en jouant sur les valeurs de , , et en faisant varier leurs valeurs, par exemple de 1 à 5% par pas de 1%. Par exemple, il est possible d’augmenter , pour tendre vers une valeur de de 2. L’algorithme peut chercher à se rapprocher de la valeur sans chercher à l’atteindre.

Le satellite et le SNO peuvent mettre à jour la table d’états / table de gestion du spot avec ces différentes valeurs (73).

La table de gestion des phases individuelles contient notamment les informations de contrôle de la ou des phases individuelles. Elle est utilisée pour échanger à la fois les informations de contrôle et les instances des phases individuelles.

Un exemple de table est présenté ci-après.

La première ligne de valeurs indique les paramètres de contrôle d’une phase individuelle. Les lignes suivantes décrivent l’avancement des phases individuelles.

Flux Raf1	Nombre de phases individuelles libres (ou type de l’instance)	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)
Contrôle	1	1	5	3	3

Table 3 : Table de gestion des phases individuelles

A ce stade la table de gestion de la phase individuelle est vide.

On note qu’une telle table de gestion des phases individuelles ne contient pas nécessairement d’information sur la phase commune. De cette façon, la taille de la table de gestion reste faible, et sa transmission reste peu coûteuse. Toutefois, afin de faciliter la compréhension de l’invention, les informations sur la phase commune sont précisées dans la table dans la suite de la description.

Par la suite, afin de montrer le fonctionnement du procédé, on considère que trois équipements utilisateurs (UE1, UE2 et UE3, tels qu’illustrés en ) se connectent sur le RaF1. Comme détaillé ci-après, suivant l’espacement temporel de leur connexion, ils disposent ou non d’une phase individuelle. Ainsi, comme illustré en , l’équipement utilisateur UE1 dispose de la phase individuelle du flux pendant une durée Ti_1, et l’équipement utilisateur UE3 dispose de la phase individuelle du flux pendant une durée Ti_3, qui ne chevauche pas Ti_1. En revanche, l’équipement utilisateur UE2 ne dispose pas de la phase individuelle.

Plus précisément, au cours d’une étape 74, l’équipement utilisateur UE1 souhaite établir une connexion avec le serveur S1. Par exemple, l’UE1 envoie un message de type « ClientHello » CHO (« Connexion UE1.Cnx1 end to end starts : ClientHello 1 RTT phase ») au serveur S1, et le serveur répond par un message de type « ServerHello » SHO (« Connexion UE1.Cnx1 end to end signalling : ServerHello »).

Comme indiqué précédemment, le module RRC peut notamment identifier les différentes phases des connexions sécurisées des protocoles QUIC, TLS, DTLS, EDHOC et similaires, en détectant la présence de la signalisation initiale (« handshake »). En particulier, le handshake TLS d’une connexion HTTPS (idem pour QUIC et DTLS et EDHOC) inclut une partie non chiffrée dans le message « ClientHello », notamment la phase dite 1-RTT qui inclut le téléchargement des certificats. Pour QUIC et TLS, le module RRC distingue à partir de la présence du message « ClientHello » les phases transportant les certificats (phase QUIC 1-RTT) des phases de reconnexion avec reprise de sessions (reprise du contexte crypto, dite 0-RTT, de la connexion précédente).

Le module RRC peut donc détecter une nouvelle connexion UE1.CNX1 dans le ou les flux IP reçus par le satellite.

L’OSS du SNO ou le satellite vérifie si une phase individuelle est libre pour la transmission de données de début de connexion du satellite vers l’équipement utilisateur UE1 en consultant la table de gestion des phases individuelles du spot.

Comme le nombre de phases individuelles libre est égal à 1 (cf table 3), cela signifie qu’une phase individuelle est disponible pour le flux quand le début de la connexion UE1.CNX1 est détecté. Il est donc possible de transmettre les données de début de connexion en provenance du serveur de données S1, entre le satellite SAT et l’équipement utilisateur UE1, au débit cible de la phase individuelle (Di_1 = 5 Mbps), jusqu’à un critère d’arrêt (par exemple pendant une durée Ti_1 = 3 s).

Flux Raf1	Nombre de phases individuelles libres ou type de l’instance	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)
Contrôle	0	1	5	3	3
UE1.CNX1	Individuel	1	5	3	3

Table 4 : Table de gestion des phases individuelles

(t = 0 s après le début de la connexion UE1.CNX1)

On suppose que l’équipement utilisateur UE2 souhaite établir une connexion avec le serveur S1 ou le serveur S2. Par exemple, l’UE2 envoie un message de type « ClientHello » au serveur S2.

Le module RRC détecte cette nouvelle connexion UE2.CNX1 dans les flux IP reçu par le satellite, par exemple une seconde après le début de la connexion UE1.CNX1.

L’OSS du SNO ou le satellite vérifie si une phase individuelle est libre pour la transmission de données de début de connexion du satellite vers l’équipement utilisateur UE2 en consultant la table de gestion des phases individuelles du spot.

Comme le nombre de phases individuelles libre est égal à 0 (cf table 4), cela signifie qu’aucune phase individuelle n’est disponible pour le flux. Les données de début de connexion en provenance du serveur S2 sont donc transmises du satellite SAT vers l’équipement utilisateur UE2 à un débit inférieur au débit cible de la phase individuelle. En d’autres termes, les paquets de la connexion UE2.CNX1 sont échangés dans la phase commune du flux.

Flux Raf1	Nombre de phases individuelles libres ou type de l’instance	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)
Contrôle	0	1	5	3	3
UE1.CNX1	Individuel	1	5	2	2
UE2.CNX1	commun	0	0	0	0

Table 5 : Table de gestion des phases individuelles

(t = 1 s après le début de la connexion UE1.CNX1)

On note que comme l’équipement utilisateur UE2 est arrivé une seconde après l’équipement utilisateur UE1, le temps restant pour la connexion UE1.CNX1 sur la phase individuelle du flux n’est plus que de 2s.

Lorsque le critère d’arrêt pour la transmission sur la phase individuelle est atteint, la phase individuelle est libérée et disponible pour une autre transmission.

Ainsi, si l’on se place 3,5 secondes après début de la connexion UE1.CNX1 (avec Ti_1 = 3 s), la phase individuelle utilisée pour la transmission des données de début de connexion vers l’équipement utilisateur UE1 est libérée, et la transmission des données UE1.CNX1 se poursuit sur la phase commune du flux, à un débit inférieur au débit cible :

Flux Raf1	Nombre de phases individuelles libres ou type de l’instance	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)
Contrôle	1	1	5	3	3
UE1.CNX1	Commun	0	0	0	0
UE2.CNX1	Commun	0	0	0	0

Table 6 : Table de gestion des phases individuelles

(t = 3,5 s après le début de la connexion UE1.CNX1)

On suppose désormais que l’équipement utilisateur UE3 souhaite établir une connexion avec le serveur S3. Par exemple, l’UE3 envoie un message de type « ClientHello » au serveur S3.

Le module RRC détecte cette nouvelle connexion UE3.CNX1 dans les flux IP reçu par le satellite, par exemple 4 secondes après le début de la connexion UE1.CNX1.

Comme le nombre de phases individuelles libre est égal à 1 (cf table 6), cela signifie qu’une phase individuelle est disponible pour le flux quand le début de la connexion UE3.CNX1 est détecté. Il est donc possible de transmettre les données de début de connexion en provenance du serveur de données S3, entre le satellite SAT et l’équipement utilisateur UE3, au débit cible de la phase individuelle (Di_1 = 5 Mbps), jusqu’à un critère d’arrêt (par exemple pendant une durée Ti_3 = 3 s).

Flux Raf1	Nombre de phases individuelles libres ou type de l’instance	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)
Contrôle	0	1	5	3	3
UE1.CNX1	Commun	0	0	0	0
UE2.CNX1	Commun	0	0	0	0
UE3.CNX1	Individuel	1	5	3	3

Table 7 : Table de gestion des phases individuelles

(t = 4 s après le début de la connexion UE1.CNX1)

Le module RRC peut notamment envoyer un signal de début de connexion individuelle DebCoFlag au module RLC, ou directement au module MAC, dans une étape 75. Comme indiqué précédemment, un tel signal, également appelé indicateur de début de connexion, peut être transporté de différentes manières :

dans un entête propriétaire,
dans un bit inutilisé, par exemple un des bits réservés du « spin-bit » du protocole QUIC,
dans un entête non propriétaire, par exemple iOAM, ECN, etc, pour accroitre l’interopérabilité,
etc.

Le choix du transport du signal dépend notamment de la localisation des blocs RLC, RRC et MAC, qui dépend du « split » choisi et/ou des constructeurs de ces blocs. Par exemple, dans le cas du split eCPRI A ou B (3GPP option 1 ou 2) et d’une implémentation du bloc MAC et du bloc RRC par des constructeurs différents, ce signal est préférentiellement transporté d’une façon prédéterminée entre ces blocs.

Dans une étape 76, un tel signal de début de connexion est par exemple ajouté par le module RLC dans les premières trames des paquets portant les données de début de connexion reçues du serveur S1 (UE1.Cnx1_data).

Éventuellement, un indicateur de fin de connexion FinCoFlag peut être transmis (77) au module RLC ou au module MAC. Par exemple, l’indicateur de début de connexion DebCoFlag et l’indicateur de fin de connexion FinCoFlag sont transmis dans des signaux séparés, et marquent uniquement le premier et le dernier paquet portant les données de début de connexion reçues du serveur S1. Ces signaux peuvent être envoyés directement au module MAC.

En variante, une information de durée DebCoDuration ou de volume DebCoVol peut être transmise au module RLC ou au module MAC. L’information de durée DebCoDuration correspond notamment à la durée d’une phase individuelle telle que définie dans la table de gestion des phases individuelles. L’information de volume DebCoVol correspond notamment à un volume de données à transmettre dans une phase individuelle tel que défini dans la table de gestion des phases individuelles. Par exemple l’indicateur de début de connexion DebCoFlag peut être un entier correspondant à l’information de durée DebCoDuration et donc décrémenté avec le temps. En variante, l’indicateur de début de connexion DebCoFlag correspond à l’information de volume DebCoVol et donc décrémenté avec la taille de chaque trame des paquets accélérés.

A réception des trames, le module MAC vérifie la présence d’un signal de début de connexion DebCoFlag. Si un signal de début de connexion DebCoFlag est détecté, il émet les données correspondantes dans la phase individuelle du flux du spot (781). Sinon, il émet les trames dans la phase commune du flux du spot, s’il dispose de ressources radio en émission. Sinon, les trames peuvent être mises en mémoire (« buffer ») ou « poubellisées » par le module MAC.

Passé le délai DebCoDuration ou le volume DebCoVol, ou à réception d’un signal de fin de connexion FinCoFlag, le module RLC ne marque plus les trames (79). Le module MAC émet donc les trames portant des données de « poursuite de connexion » dans la phase commune du flux du spot (782), s’il dispose de ressources radio en émission. Sinon, les trames peuvent être mises en mémoire (« buffer ») ou poubellisées par le module MAC.

En variante, le module RLC peut mettre en mémoire ou « poubelliser » les trames non marquées suivant le type de module RLC (Transparent Mode (TM), Unacknowledged Mode (UM) ou Acknowledged Mode (AM)).

Si l’équipement utilisateur UE1 se reconnecte ultérieurement au même serveur S1, la phase 0-RTT du protocole QUIC est mise en œuvre (UE1.Cnx2 end to end starts : ClientHello 0-RTT phase »). Dans ce cas, le module MAC peut directement émettre les trames portant des données reçues du serveur S1 dans la phase commune du flux du spot.

5.3 Variantes

On a décrit ci-dessus des exemples dans lesquels l’équipement intermédiaire mobile est un satellite. D’autres équipements d’accès mobiles peuvent bien entendu être utilisés, par exemple un avion, un ballon, un drone, une HIBS, etc.

De même, on a décrit une mise en œuvre de l’invention lorsque les modules RRC, RLC et MAC sont co-localisés dans l’équipement intermédiaire mobile. En variante, selon le « split » choisi, certains modules peuvent être localisés à distance. Dans ce cas, les différents signaux échangés (indicateur de début et/ou fin de connexion, tables, etc) devront présenter un format compatible avec les différents modules pour pouvoir être traités.

Plus généralement, l’invention peut être mise en œuvre dans les différentes architectures décrites en relation avec la (« Nothing on board », « RU onboard », « RU+DU onboard », « RU+DU+CU onboard »).

On a également présenté un exemple selon lequel une seule phase individuelle est disponible. Dans d’autres modes de réalisation, plusieurs phases individuelles peuvent être disponibles.

En revenant à l’exemple décrit ci-dessus en relation avec les figures 6 et 7, on présente ci-après quelques variantes.

Selon un mode de réalisation particulier, l’OSS du MNO peut mettre à jour certains paramètres, notamment pour les connexions existantes en cours sur la phase individuelle.

Par exemple, si l’algorithme de calcul de la capacité présenté ci-dessus propose de raccourcir la durée d’une phase individuelle pour répondre à l’arrivée de plusieurs nouveaux équipements utilisateurs dans la cellule radio, en plus de UE1, alors la durée de la connexion en cours UE1.CNX1 peut être réduite, par exemple de 5%, pour accepter un peu plus tôt la connexion UE2.CNX2 dans la phase individuelle.

Selon un autre exemple, il est possible de donner la priorité à une demande de création d’une connexion UE2.CNX2 d’un service de secours. Dans ce cas, la durée de la connexion en cours UE1.CNX1 peut être forcée par l’OSS du MNO ou du SNO, par exemple à 95%, pour accélérer le passage en phase commune de la transmission, afin d’accepter immédiatement la connexion UE2.CNX2 au service de secours dans la phase individuelle.

Ces différents exemples illustrent que les paramètres peuvent être choisis ou mis à jour en tenant compte du service ou du domaine du serveur demandé. Par exemple, une connexion vers un domaine video.example.com peut obtenir au démarrage le double de temps ou de mega octets .

Ce cas s’applique notamment aux connexions affichant leur type d’application (comme IETF APN BoF, MASQUE WG) ou dans le cas d’une coopération d’un des BSS avec un CDN (« Content Delivery Network ») souhaitant accélérer un service.

Par ailleurs, comme indiqué ci-dessus, dans l’implémentation la plus simple, le module RRC peut classer les phases 1-RTT pour transmettre les données correspondantes sur une phase individuelle du flux, et les phases 0-RTT pour les transmettre sur une phase commune.

Dans un mode plus perfectionné, les phases initiales des connexions QUIC 0-RTT peuvent également être transmises sur une phase individuelle du flux si une telle phase individuelle est disponible. Cette phase individuelle peut avoir des paramètres différents (notamment , et/ou ), par exemple avec un basculement sur la phase commune plus rapide ( par exemple). Cette réduction tient compte du moindre besoin de données en début de reconnexion du fait de la présence de données applicatives dans le cache de l’équipement utilisateur.

Dans un autre mode de réalisation, les champs du certificat CN (« Common Name ») ou SAN (« Subject Alternative Name ») peuvent être utilisés par le module RRC ou l’un des BSS pour identifier un partenaire CDN, un type de service ou un nom de domaine, et lui associer un contrôle personnalisé. Optionnellement ces paramètres diffèrent avec le service ou le domaine du serveur demandé.

Dans une première implémentation, le BSS peut fournir ces règles au module RRC dans une table de personnalisation des phases individuelles. Cette implémentation permet le classement de la connexion dès la détection de la connexion.

Par exemple, dans la table de personnalisation ci-dessous, une connexion vers un domaine video.example.com obtient au démarrage le double de temps ou de mega octets . En revanche, le domaine foo.example.com sera lui toujours classé pour être transmis dans la phase commune.

De plus, les connexions venant du sous réseau IP 192.168.1.0/24 ou du domaine samu.example.com préemptent les connexions en cours sur la phase individuelle, sans prendre les ressources de la phase commune, avec une durée infinie et un volume illimité.

service	(Mbps)	(s)	(Mo)
video.example.com	5	6	6
foo.example.com	0	0	0
IP source 192.168.1.0/24	5	0	0
Domaine source samu.example.com	10	0	0

Table 8 : Table de personnalisation des phases individuelles

Dans une seconde implémentation, une colonne « service », recevant le domaine de la connexion peut être ajoutée à la table de gestion des phases individuelles afin que l’OSS/BSS du MNO applique ces règles aux connexions en cours. Cette implémentation permet le classement des connexions en cours après réception de la table de gestion des phases individuelles.

Selon cette implémentation, en reprenant les tables 5, 6 et 7 présentées ci-dessus, lorsque le module RRC détecte la nouvelle connexion UE2.CNX1 dans les flux IP reçu par le satellite, par exemple une seconde après le début de la connexion UE1.CNX1, on a :

Flux Raf1	Nombre de phases individuelles libres ou type de l’instance	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)	Service
Contrôle	0	1	5	3	3
UE1.CNX1	Individuel	1	5	2	2	video.example.com
UE2.CNX1	commun	0	0	0	0	foo.example.com

Table 9 : Table de gestion des phases individuelles après personnalisation, reçue de RaF1 une seconde après le début de la connexion UE1.CNX1

Flux Raf1	Nombre de phases individuelles libres ou type de l’instance	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)	Service
Contrôle	0	1	5	3	3
UE1.CNX1	individuel	1	5	5	5	video.example.com
UE2.CNX1	commun	0	0	0	0	foo.example.com
UE2.CNX1	commun	0	0	0	0	foo.example.com

Table 10 : Table de gestion des phases individuelles après personnalisation, émise par l’OSS/BSS vers le RaF1

Lorsque le module RRC détecte la nouvelle connexion UE3.CNX1 dans les flux IP reçu par le satellite, par exemple 4 secondes après le début de la connexion UE1.CNX1, on a :

Flux Raf1	Nombre de phases individuelles libres ou type de l’instance	Nombre total de phases individuelles (ou utilisé par une instance)	(Mbps)	(s)	(Mo)	service
Contrôle	0	1	5	3	3
UE1.CNX1	individuel	1	5	1	1
UE2.CNX1	commun	0	0	0	0
UE3.CNX1	commun	0	0	0	0

Table 7 : Table de gestion des phases individuelles après personnalisation

On note que la transmission avec le premier équipement utilisateur UE1.CNX1 est toujours dans la phase individuelle du flux du spot. En revanche, la transmission avec le troisième équipement utilisateur UE3.CNX1 est dans la phase commune du flux, puisque le nombre de phases individuelles libre est toujours à zéro.

En particulier, le choix de l’implémentation de la personnalisation ci-dessus dépend de la localisation du bloc RRC de l’unité centralisée CU. Une localisation « embarquée » du CU (distante de l’OSS/BSS) implique le choix d’un mode de transport commun (une standardisation) de la table de personnalisation des phases individuelles / table de gestion des phases individuelles après personnalisation.

5.4 Système correspondant

On présente finalement la structure simplifiée d’un système de gestion des communications selon au moins un mode de réalisation décrit ci-dessus, comprenant des modules d’obtention du nombre de phases individuelles, de détection d’un début de connexion, et de transmission de données de début de connexion.

Comme déjà indiqué, ces modules peuvent être co-localisés au sein d’un même équipement (par exemple un équipement géré par l’opérateur mobile ou par l’opérateur satellite), ou distants.

Selon l’exemple illustré en , au moins un équipement d’un tel système comprend au moins une mémoire 81 comprenant une mémoire tampon, au moins une unité de traitement 82, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 83, mettant en œuvre des étapes du procédé de gestion des communications selon au moins un mode de réalisation de l’invention.

A l’initialisation, les instructions de code du programme d’ordinateur 83 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 82.

Le processeur de l’unité de traitement 82 met en œuvre des étapes du procédé de gestion des communications décrit précédemment, selon les instructions du programme d’ordinateur 83, pour :

obtenir un nombre de phases individuelles associées chacune à un débit cible dans ledit flux, à servir pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,
détecter un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
transmettre des données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt, si une phase individuelle est disponible pour ledit flux, ou
transmettre des données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible, si aucune phase individuelle n’est disponible pour ledit flux.

Selon un mode de réalisation particulier, ces différentes étapes peuvent être mises en œuvre par des modules physiques ou logiciels, co-localisés ou distants.

Claims

Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio, caractérisé en ce qu’il met en œuvre les étapes suivantes, pour un flux de données dudit au moins un faisceau radio :
obtention (41) du nombre de phases individuelles associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,

détection (42) d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,

si une phase individuelle est disponible pour ledit flux : transmission (431) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt,

si aucune phase individuelle n’est disponible pour ledit flux : transmission (432) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible.
Procédé selon la revendication 1, caractérisé en ce que le nombre de phases individuelles dudit flux est défini à partir d’au moins un paramètre appartenant au groupe comprenant :
ledit débit cible ,

une puissance d’émission dudit équipement intermédiaire mobile,

un facteur de propagation entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,

une bande passante dudit équipement intermédiaire mobile,

un angle d’ouverture de l’antenne d’émission dudit équipement intermédiaire mobile,

une distance entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,

un nombre de faisceaux radio interférents entre ledit équipement intermédiaire mobile et au moins une autre cellule radio,

un bruit thermique ,

la variance de l’effet de masque ,

une probabilité de non-couverture .
Procédé selon la revendication 2, caractérisé en ce que le nombre de phases individuelles dudit flux est égal à la partie entière de la capacité dudit faisceau radio ) avec :
).
Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit critère d’arrêt dépend d’un type de service.
Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit critère d’arrêt appartient au groupe comprenant :
une période donnée ,

un volume donné ,

une fin de connexion dudit premier équipement utilisateur avec ledit premier serveur de données,

une détection d’un début de connexion d’un deuxième équipement utilisateur, présent dans ladite cellule radio, à un deuxième serveur de données prioritaire par rapport audit premier serveur de données.
Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite étape d’obtention du nombre de phases individuelles est mise à jour :
périodiquement, ou

suite à une modification d’un paramètre dudit équipement intermédiaire mobile, ou

suite à une modification d’un paramètre dudit faisceau radio généré par ledit équipement intermédiaire mobile, ou

suite à une modification dudit critère d’arrêt.
Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite détection d’un début de connexion met en œuvre la détection d’un échange de données de sécurisation de la connexion entre ledit premier équipement utilisateur et ledit premier serveur de données.
Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ladite détection d’un début de connexion comprend :
l’identification desdites données de début de connexion, à partir d’au moins un marqueur inséré par un module de type RRC dans au moins un paquet de données en provenance dudit premier serveur de données,

l’insertion desdites données de début de connexion dans ladite phase individuelle disponible pour ledit flux par un module de type MAC.
Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu’il met en œuvre le stockage d’informations relatives à ladite au moins une phase individuelle dans une table de gestion des phases individuelles.
Système de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio, caractérisé en ce qu’il comprend, pour un flux de données dudit au moins un faisceau radio :
un module d’obtention du nombre de phases individuelles associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,

un module de détection d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,

un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt, activés si une phase individuelle est disponible pour ledit flux, et

un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible, activés si aucune phase individuelle n’est disponible pour ledit flux.
Programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 9, lorsqu’il est exécuté par un processeur.