FR3067210A1 - Procede de communication directe entre terminaux - Google Patents
Procede de communication directe entre terminaux Download PDFInfo
- Publication number
- FR3067210A1 FR3067210A1 FR1754857A FR1754857A FR3067210A1 FR 3067210 A1 FR3067210 A1 FR 3067210A1 FR 1754857 A FR1754857 A FR 1754857A FR 1754857 A FR1754857 A FR 1754857A FR 3067210 A1 FR3067210 A1 FR 3067210A1
- Authority
- FR
- France
- Prior art keywords
- message
- frame
- transmission
- data
- resources
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 79
- 230000006854 communication Effects 0.000 title claims abstract description 79
- 238000000034 method Methods 0.000 title claims abstract description 55
- 230000005540 biological transmission Effects 0.000 claims abstract description 225
- 238000012360 testing method Methods 0.000 claims abstract description 131
- 230000011664 signaling Effects 0.000 claims abstract description 80
- 230000004044 response Effects 0.000 claims abstract description 20
- 238000005259 measurement Methods 0.000 claims description 14
- 230000008859 change Effects 0.000 claims description 10
- 238000004364 calculation method Methods 0.000 claims description 6
- 235000019800 disodium phosphate Nutrition 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 11
- 230000006870 function Effects 0.000 description 8
- 230000002452 interceptive effect Effects 0.000 description 7
- 230000002457 bidirectional effect Effects 0.000 description 5
- 235000008694 Humulus lupulus Nutrition 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 230000003595 spectral effect Effects 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000007175 bidirectional communication Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 230000001747 exhibiting effect Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/14—Direct-mode setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0079—Formats for control data
- H04L1/008—Formats for control data where the control data relates to payload of a different packet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/005—Discovery of network devices, e.g. terminals
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
L'invention concerne un procédé de communication directe entre au moins deux terminaux d'un réseau mobile, sur un ensemble de blocs de ressources radio définies selon une ou plusieurs dimensions, organisé en trame, le procédé étant mis en œuvre par un terminal émetteur et comprenant les étapes suivantes : - transmission test (40), à au moins un terminal récepteur, d'au moins un message de signalisation fonction d'un premier sous-ensemble de blocs de ressources radio ; et - en fonction d'au moins un message d'acquittement reçu en réponse à la transmission test, transmission (44), à l'au moins un terminal récepteur, de données sur le premier sous-ensemble de blocs.
Description
DOMAINE DE L’INVENTION
L’invention est dans le domaine des télécommunications. Elle concerne en particulier les communications directes entre terminaux, normalisées par le standard LTE (pour Long Term Evolution) à partir de la release 12 sous le nom de « Sidelink communications ».
CONTEXTE DE L’INVENTION
De manière générale, un réseau de téléphonie mobile permet l'utilisation simultanée d’équipements mobiles (e.g. téléphones portables et tablettes numériques équipés de cartes SIM) pour communiquer par radio avec une infrastructure terrestre comprenant notamment stations de base (comportant typiquement des antennes) couvrant une étendue géographique déterminée (cellule), ainsi qu’un cœur de réseau chargé de gérer l’acheminement des communications mobiles.
Ces éléments (notamment antennes, cartes SIM et équipements mobiles) peuvent provenir de divers fabricants. Il est donc nécessaire de respecter certaines spécifications techniques, et d’appliquer les mêmes règles pour permettre à ces éléments d’origines diverses de pouvoir interagir, par exemple pour l’établissement et l’acheminement des communications.
C’est pour faire face à cette problématique que L’ETSI (pour European Télécommunications Standards Institute) coopère depuis la fin des années 90 notamment avec ses équivalents américains et asiatiques sur un projet en partenariat appelé 3GPP (pour 3rd Génération Partnership Project). Cette coopération a permis l’élaboration et la publication de spécifications techniques pour les réseaux mobiles à partir de la 3ème génération (3G).
Pour répondre à des besoins croissants en débit dus notamment à la démocratisation du streaming video et des applications mobiles, la 4G est née avec le
LTE (pour Long Term Evolution), optimisé pour transporter des données.
Les groupes de travail 3GPP développent également la 5G qui vise à adresser les besoins accrus des applications complexes nécessitant du très haut débit et une haute fiabilité, par exemple le cloud computing et le big data, la domotique ou encore les communications mettant en jeu des véhicules autonomes (sans chauffeur).
En plus des communications uplink (de l’équipement mobile vers le réseau) et downlink (du réseau vers l’équipement mobile) classiques dans les réseaux mobiles, la norme LTE (à partir de la release 12) prévoit la mise en place de communications sidelink (SL) directes entre équipements mobiles voisins, c’est-à-dire sans passer par l’infrastructure réseau. On connaît par exemple les communications D2D (pour Device to Device) entre terminaux, mais aussi les communications V2V (pour Vehicle to Vehicle) entre véhicules intelligents, par exemple autonomes (sans chauffeur).
Ce nouveau type de communications est possible notamment grâce à une interface radio spécifique PC5 qui permet de créer un réseau WLAN (pour Wireless Local Area Network) entre des équipements mobiles voisins.
Concernant l’allocation des ressources pour les communications SL, deux modes sont prévus dans la norme LTE (Release 13). Dans le premier mode appelé « scheduled mode », l’allocation des ressources est gérée par la station de base et indiquée aux terminaux via un message de signalisation. Dans le second mode appelé « autonomous mode », l’allocation des ressources est gérée par les terminaux euxmêmes (c’est-à-dire les terminaux communiquant directement), en choisissant les ressources de leur choix parmi un ensemble de ressources préconfiguré.
Le second mode permet une plus grande autonomie des terminaux et une meilleure utilisation des ressources. En effet, chaque terminal est libre de choisir les ressources qu’il souhaite qu’il soit ou non dans la portée d’une station de base et il est ainsi possible de satisfaire des besoins de différents services notamment en débit.
Afin de fiabiliser les transmissions de données et diminuer le nombre de collisions dues au fait que les terminaux ne savent pas quelles ressources seront choisies par d’autres terminaux voisins pour leurs propres transmissions de données, des mécanismes de répétition et de sauts en fréquence sont mis en œuvre.
Cependant, ces mécanismes ne permettent pas d’atteindre une bonne efficacité spectrale (c’est-à-dire une bonne répartition orthogonale des fréquences et plus généralement des ressources radio, entre les terminaux voisins) ni d’offrir des garanties de qualité de service.
De manière générale, la norme LTE, en particulier la spécification
ETSI TS 136 213 V14.2.0 (2017-04), ne prévoit pas de mécanisme efficace permettant de diminuer les risques de collisions sans affecter l’efficacité spectrale ni la qualité de service. Il existe donc un besoin de proposer un tel mécanisme.
RESUME DE L’INVENTION
La présente invention a ainsi pour objet de pallier au moins un de ces inconvénients.
Dans ce contexte, un premier aspect de l’invention concerne un procédé de communication directe entre au moins deux terminaux d’un réseau mobile, sur un ensemble de blocs de ressources radio définies selon une ou plusieurs dimensions, organisé en trame, le procédé étant mis en œuvre par un terminal émetteur et comprenant les étapes suivantes :
- transmission test, à au moins un terminal récepteur, d’au moins un message de signalisation fonction d’un premier sous-ensemble de blocs de ressources radio ; et
- en fonction d’au moins un message d’acquittement reçu en réponse à la transmission test, transmission, à l’au moins un terminal récepteur, de données sur le premier sous-ensemble de blocs.
Avantageusement, les risques de collision sont drastiquement diminués puisque la transmission des données n’est réellement effectuée ou complétée qu’après une phase de test permettant de confirmer que les ressources choisies ne sont pas en conflit.
De plus, l’efficacité spectrale est améliorée puisque la répétition n’est pas nécessaire.
Corrélativement, un deuxième aspect de l’invention concerne un dispositif de communication conforme à la norme LTE et mettant en œuvre le procédé susmentionné.
Les avantages, buts et caractéristiques particulières de ce dispositif sont similaires à ceux du procédé précité.
D’autres caractéristiques du procédé et du dispositif selon des modes de réalisation de l’invention sont décrites dans les revendications dépendantes.
Le message d’acquittement peut être fonction de la qualité radio de réception par le terminal récepteur et/ou du schéma de modulation et de codage (MCS) employé pour la transmission test. Ainsi par exemple, lorsque la qualité est trop mauvaise, le terminal récepteur peut décider de ne pas renvoyer d’acquittement, ou bien indiquer dans cet acquittement que la qualité de réception est mauvaise. Selon un autre exemple, l’acquittement peut indiquer le nouvel MCS à utiliser pour la transmission des données sur le premier sous-ensemble de blocs.
Dans des modes particuliers de réalisation, la trame comprend une pluralité de configurations prédéfinies de blocs de ressources radio et le premier sousensemble est une configuration prédéfinie de blocs de ressources radio.
Dans des modes particuliers de réalisation, la trame comprend au moins une partie contrôle et l’au moins un message de signalisation est transmis sur un bloc de ressources radio de l’au moins une partie contrôle associé à la configuration prédéfinie correspondant au premier sous-ensemble de blocs, permettant ainsi l’identification du premier sous-ensemble de blocs.
Ce message de signalisation indique par exemple que les données vont être transmises sur le premier sous-ensemble de blocs.
La trame peut également comprendre une ou plusieurs parties réservées à la transmission de données.
Lorsque la trame est organisée en configurations, dans certains modes de réalisation, il peut y avoir une correspondance unique entre des ressources de la partie contrôle et chaque configuration de la partie données. Ceci facilite l'identification de la ou des configurations de la partie données concernée(s) par les messages de signalisation envoyés sur la partie contrôle.
Dans des modes particuliers de réalisation, la transmission test comprend une transmission de données de test sur un second sous-ensemble de blocs de ressources radio représentatif du premier sous-ensemble de blocs de ressources radio.
Dans ce cas, le message d’acquittement peut indiquer la bonne réception des données de test sur le second sous-ensemble.
Typiquement, ces données de test peuvent consister en un échantillon des données à transmettre sur le premier sous-ensemble de blocs.
Selon les modes, les données de test peuvent être transmises dans la partie contrôle de la trame ou dans la partie données.
Dans des modes particuliers de réalisation, la transmission test est effectuée sur une première trame tandis que la transmission des données est effectuée sur une seconde trame comprenant le premier sous-ensemble de blocs de ressources radio, la seconde trame étant différente de la première trame.
Dans des modes particuliers de réalisation, les blocs de ressources radio situés entre les blocs de ressources radio utilisés pour la transmission test et la réception du ou des messages d’acquittement sont réservés pour transmettre des données directes courtes DSSL et/ou transmettre ou recevoir d’autres messages d’acquittement ou de demande d’acquittement.
Dans des modes particuliers de réalisation, la trame peut comprendre une pluralité de parties contrôle.
Dans des modes particuliers de réalisation, la transmission test et la réception de l’au moins un message d’acquittement en réponse à la transmission test sont effectués sur une même partie contrôle de la trame.
Dans des modes particuliers de réalisation, les blocs de ressources radio utilisés pour la transmission test sont également utilisés par le terminal émetteur pour la transmission de données, qu’elle soit étalée sur une ou plusieurs trames.
Dans des modes particuliers de réalisation, le procédé comprend la réception d’un autre message d’acquittement sur des parties contrôle prédéfinies de la trame, en réponse aux données transmises sur le premier sous-ensemble de blocs, l’autre message d’acquittement notifiant le terminal émetteur d’un changement d’un schéma de modulation et de codage MCS employé par l’au moins un terminal récepteur et/ou acquittant les données reçues jusque-là.
Dans des modes particuliers de réalisation, le procédé comprend la réception d’un message de réservation d’un troisième sous-ensemble de blocs de ressources radio de la trame courante ou d’une trame future.
Dans des modes particuliers de réalisation, le procédé comprend la transmission d’un autre message de signalisation à l’au moins un terminal récepteur, indiquant au moins un bloc de ressources radio en cours d’utilisation sur la trame courante par le terminal émetteur.
Dans des modes particuliers de réalisation, le procédé comprend la réception de mesures de qualité de connexion entre le terminal émetteur et chaque terminal récepteur d’une pluralité de terminaux récepteurs, le procédé comprenant en outre une étape de sélection d’au moins un terminal relai parmi les terminaux récepteurs de la pluralité en fonction des mesures de qualité, un identifiant de l’au moins un terminal relai étant indiqué dans un message d’en-tête transmis avec les données sur le premier sous-ensemble de blocs.
Dans des modes particuliers de réalisation, le procédé comprend la réception de mesures de qualité de la connexion entre les deux terminaux d’une pluralité de paires de terminaux, le procédé comprenant en outre une étape de calcul d’un graphe de diffusion multicast à partir des mesures de qualité reçues.
Dans des modes particuliers de réalisation, le procédé comprend en outre les étapes suivantes :
- réception d’un message de réservation d’un sous-ensemble de blocs de ressources radio envoyé par un terminal du réseau mobile à un autre terminal différent de l’émetteur ;
- mesure de la qualité de réception du message de réservation ; et
- en fonction du résultat de la comparaison de la qualité de réception mesurée avec une valeur seuil, réservation ou non dudit sous-ensemble de blocs de ressources radio.
Dans des modes particuliers de réalisation, le message de réservation indique un niveau de qualité de réception de messages par ledit terminal du réseau mobile.
Dans des modes particuliers de réalisation, la réservation du sousensemble de blocs de ressources radio est également fonction du résultat de la comparaison de la qualité de réception indiquée dans le message de réservation avec une valeur seuil.
Dans des modes particuliers de réalisation, la trame future est séparée de la trame courante par une durée prédéfinie fonction d’au moins un bloc de ressources radio dédié au message de réservation et/ou signalée dans le message de réservation.
Dans des modes particuliers de réalisation, au moins un premier bloc de ressources radio est dédié à l’au moins un message de signalisation et au moins un second bloc de ressources radio est dédié à l’au moins un message d’acquittement, l’au moins un premier bloc et l’au moins un second bloc étant espacés d’une durée prédéfinie au moins égale au temps nécessaire au décodage de l’au moins un message d’acquittement.
Dans des modes particuliers de réalisation, au moins un troisième bloc de ressources radio est dédié au message de réservation, l’au moins un premier bloc et l’au moins un troisième bloc étant espacés d’une durée prédéfinie au moins égale au temps nécessaire au décodage du message de réservation.
Dans des modes particuliers de réalisation, le troisième sous-ensemble de blocs de ressources radio réservé correspond au premier sous-ensemble de blocs.
Dans des modes particuliers de réalisation, l’au moins un message de signalisation indique des informations de réservation, ces informations de réservation comprenant l’ensemble des ressources radio et identifiant au moins une trame future qu’au moins un terminal du réseau mobile autre que le terminal émetteur a réservé.
Dans des modes particuliers de réalisation, les informations de réservation sont associées à une durée de validité limitée dans le temps débutant à l’émission de l’au moins un message de signalisation.
Dans des modes particuliers de réalisation, le procédé comprend en outre les étapes suivantes :
- calcul d’une probabilité de succès de la transmission test en fonction d’un nombre de messages de signalisation reçus d’autres terminaux du réseau mobile et indiquant le premier ensemble de blocs de ressources radio et d’un nombre total de messages de signalisation reçus d’autres terminaux du réseau mobile depuis la transmission test; et
- en fonction de la probabilité de succès calculée, transmission ou non des données sur le premier sous-ensemble de blocs.
En pratique, le nombre total de messages de signalisation inclus également les messages de signalisation reçus qui n’indiquent pas le premier ensemble de blocs de ressources radio.
Dans des modes particuliers de réalisation, l’au moins un message de signalisation indique un indice de priorité associé à chaque transmission future et l’étape de calcul prend en compte cet indice de priorité.
Dans des modes particuliers de réalisation, des blocs de ressources radio dédiés aux messages de signalisation et/ou d’acquittement sont de taille réduite par rapport aux autres blocs de ressources radio de la trame ou ont des dimensions différentes par rapport aux autres blocs de ressources radio de la trame.
Dans des modes particuliers de réalisation, les différentes étapes des procédés précités sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre par un microprocesseur, ce programme comprenant des instructions adaptées à la mise en œuvre des étapes du procédé tel que mentionné ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en œuvre.
BREVE DESCRIPTION DES FIGURES
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures :
- La figure 1 illustre le sens des communications downlink et uplink entre un terminal et le réseau mobile ainsi que les communications sidelink entre deux terminaux ;
- La figure 2 illustre un bloc de ressources ;
- La figure 3 illustre un exemple de format de trame pour la gestion des communications sidelink ;
- La figure 4 représente, sous forme d’organigramme, les principales étapes d’un procédé de communication directe entre terminaux conforme à des modes de réalisation de l’invention ;
- La figure 5 illustre un premier exemple de transmission SL conforme à la mise en œuvre du procédé de la figure 4 ;
- La figure 6 illustre un second exemple de transmission SL conforme à la mise en œuvre du procédé de la figure 4 ;
- La figure 7 illustre un troisième exemple de transmission SL conforme à la mise en œuvre du procédé de la figure 4 ;
- La figure 8 illustre un exemple de transmission SL unicast étalée sur plusieurs trames avec libre choix des ressources du DP (Open DSP) ;
- Les figures 9a et 9b illustrent un exemple de répartition des ressources dédiées aux DCH (figure 9a) et aux messages de signalisation (figure 9b) d’une SCPeriod SL ;
- La figure 9c illustre un exemple de transmission SL unicast étalée sur plusieurs trames dont les ressources sont organisées conformément aux figures 9a et 9b (Closed DSP) ;
- La figure 10 illustre un exemple de transmission SL unicast sur une seule trame avec libre choix des ressources du DP (Open DSP) ;
- La figure 11 illustre un exemple de transmission SL unicast sur une seule trame avec choix limité aux configurations du DP (Closed DSP) ;
- La figure 12 illustre un exemple de transmission SL unicast étalée sur plusieurs trames avec choix limité aux configurations du DP (Closed DSP) sans données de test ;
- La figure 13 illustre un exemple de transmission SL sur une trame comprenant plusieurs parties contrôle SP ;
- La figure 14 représente un exemple d’un lien de communication multicast dans un groupe multicast ;
- La figure 15 illustre un exemple d’établissement de communication SL multicast sur des trames composées d’un certain nombre de parties contrôle SP.
DESCRIPTION DETAILLEE DE L’INVENTION
De façon générale, la présente invention permet de contrôler l’accès à un ensemble de blocs de ressources radio d’une trame de gestion de communications sidelink. Typiquement, le procédé est mis en œuvre par un nœud émetteur et comprend une première phase comprenant une transmission test de la qualité du lien radio durant laquelle un message de signalisation fonction d’un premier sous-ensemble de blocs de ressources radio de la trame et éventuellement des données de test sont transmis à au moins un nœud récepteur. En pratique, les données de test constituent un échantillon (une première partie) des données que le nœud émetteur souhaite envoyer.
Ensuite, le nœud émetteur attend de recevoir un ou plusieurs messages d’acquittement signifiant que la transmission test s’est bien passée ou non.
Une fois ce message d’acquittement reçu, une seconde phase démarre, durant laquelle une transmission classique de données a lieu vers le nœud récepteur sur le premier sous-ensemble de blocs de ressources radio. Dans le cas où un échantillon de ces données (données de test) a déjà été envoyé pendant la phase de test, la transmission classique consiste à envoyer le reste des données.
Cette seconde phase n’a lieu que sous réserve que la première phase (de test) se soit terminée par la réception d’un (ou plusieurs) message(s) d’acquittement attestant du bon déroulement du test.
Ainsi, les risques de collisions dues au fait que des nœuds émetteurs ont choisi les mêmes blocs de ressources radio sont évités.
Des exemples vont maintenant être décrits.
La figure 1 illustre le sens des communications downlink et uplink entre un terminal 10 et le réseau mobile (antenne 12) ainsi que les communications sidelink entre deux terminaux 10 et 14.
De tels terminaux sont typiquement des téléphones mobiles ou tablettes équipés de carte USIM, ou de tout autre équipement utilisateur UE au sens de la norme LTE. La présente invention n’est pas limitée à cette norme et peut s’appliquer dans d’autres contextes.
La figure 2 illustre un bloc de ressources RB (pour Resource Block).
L’unité de transmission de base est le RB. Un RB a une certaine durée correspondant à un certain nombre Nsym de symboles de transmission et il est défini sur un nombre Nsc de sous-porteuses. Un RB (ou un ensemble de RB) transporte soit des messages de signalisation (SIG) soit des paquets de données (DATA). La taille de l’information transportée par un ensemble de RB est définie en fonction du schéma de modulation et de codage (MCS) employé (e.g. SC-FDMA, RSMA).
Dans cet exemple, les ressources radio sont représentées en RB à deux dimensions temps/fréquence. Cependant, un nombre différent de dimensions et/ou des dimensions de nature différente que le temps et la fréquence peuvent être envisagées. Par exemple, les RB pourraient être à trois dimensions (e.g. temps, fréquence et code) ou à une dimension (temps).
Également, dans la suite de la description, les RB considérés seront de même dimension et de nature identique. Toutefois, l’invention n’est pas limitée à cela et les RB peuvent aussi être de tailles différentes (e.g. petits RB pour la signalisation et plus grands pour les données) voire de nature différente (e.g. transmission des données par SC-FDMA sur des RB temps/fréquence et transmission de la signalisation par RSMA sur des RB temps/fréquence/code).
La figure 3 illustre un exemple de format de trame pour la gestion des communications sidelink.
La norme LTE a défini une trame pour la gestion des communications SL, appelée SC-Period. Une SC-Period est composée d’une 1ère partie de contrôle ou de signalisation SP (pour Signaling Pool) suivie d’une 2ème partie de transmission de données DP (pour Data Pool). Le SP est utilisé pour la transmission du message de signalisation SCI0 appelé aussi SA (Scheduling Assignment). Ce message est émis par un terminal émetteur appelé par la suite « nœud source », « nœud émetteur » ou « émetteur» vers un ou plusieurs terminaux récepteurs appelés par la suite « nœuds destinataires », « nœuds récepteurs » ou « récepteurs ». Ce message transporte les informations nécessaires pour permettre au(x) destinataire(s) de s’identifier et d’identifier la source, et de décoder la transmission de données qui a lieu dans le DP. Le DP et le SP sont composés de RB, comme représenté sur la figure.
Comme on le verra par la suite, dans certains modes de réalisation de la présente invention, on utilise la trame SC-Period telle qu’elle est connue de la norme
LTE, c’est-à-dire avec une séparation temporelle entre les parties contrôle SP et données DP (voir par exemple figures 5 à 12). Dans d’autres modes de réalisation, on utilise une trame SC-Period modifiée, dans laquelle les parties contrôle SP et données
DP ne sont pas séparées temporellement de sorte que des communications peuvent être initiées à différents endroits de la trame (voir par exemple figure 13).
Dans les deux cas (SP et DP séparés temporellement ou non), il est ici proposé de partitionner la partie données DP de chaque trame en plusieurs sousparties notées DSP (pour Data Sub-Pool). Une sous-partie DSP diffère du T-RPT prévu par la norme LTE en ce que la répétition des données sur plusieurs DSP n’est pas nécessaire. De plus, les ressources choisies pour une transmission peuvent être identiques sur tous les DSP de la trame (pas de saut de fréquence entre plusieurs DSP).
La figure 4 illustre le principe général du contrôle d’accès effectué lors de la communication directe entre terminaux conformément à des modes de réalisation de l’invention.
Au cours d’une étape 40, une transmission test est effectuée par un émetteur vers un ou plusieurs récepteurs. Selon l’invention, cette transmission test est fonction d’un premier sous-ensemble de blocs de ressources radio sur lequel des données vont être transmises par la suite.
Ainsi, cette transmission test consiste notamment à transmettre un message de signalisation SCI0 appelé aussi SA (pour Scheduling Assignment) sur un bloc de la partie contrôle SP de la trame. Ce message SA indique typiquement l’identité du ou des récepteurs visés. Il indique de plus le premier sous-ensemble de blocs de ressource sur lequel il a l’intention de transmettre des données.
Par exemple, ce premier sous-ensemble de blocs de ressource est un ensemble de RB choisi librement (situation appelée « Open DSP ») par l’émetteur dans un DSP.
En variante, les blocs de ressources radio de la partie données DP de la trame peuvent être organisés en une pluralité de configurations de ressources prédéfinies notées DCH (pour Data CHannel). Dans ce cas, le premier sous-ensemble de blocs de ressource est un DCH choisi parmi l’ensemble des configurations disponibles (situation appelée « Closed DSP »). Dans ce cas, il peut suffire d’indiquer l’identifiant du DCH dans le message SA.
Selon un mode de réalisation particulier, la partie contrôle SP de la trame peut comprendre des ressources dédiées aux messages SA par DCH. Autrement dit, une correspondance unique est prévue entre chaque DCH et chaque bloc de ressources dédié aux messages SA. Dans ce cas, il n’est pas nécessaire d’indiquer l’identifiant du DCH dans le message SA car le récepteur pourra identifier le DCH correspondant en fonction de la ressource utilisée pour envoyer le message SA.
Dans des modes de réalisation, la transmission test comprend également la transmission de données de test qui consistent typiquement en un échantillon (i.e. une première partie) des données que l’on enverrait au cours d’une transmission classique. Ces données de test sont typiquement transmises sur un second sousensemble (T-DSP) de blocs de ressources radio représentatif du premier sousensemble de blocs.
Selon des modes de réalisation particuliers, ce second sous-ensemble est localisé dans la partie contrôle SP de la trame.
Selon d’autres modes de réalisation particuliers, les données de test sont envoyées dans la partie données DP d’une première trame, ainsi réservée au test. Ces modes de réalisation sont particulièrement avantageux lorsque la transmission s’étale sur plusieurs trames
Au cours d’une étape 42, l’émetteur surveille la réception d’un message d’acquittement de la transmission test. Ce message d’acquittement atteste du bon déroulement ou non de la transmission test.
Selon des modes de réalisation, le message d’acquittement peut être reçu sur la partie contrôle SP de la même trame sur laquelle a été effectuée la transmission test. Dans ce cas, ce message d’acquittement est par exemple noté SAA (pour Scheduling Assignment Acknowledgment).
En variante, le message d’acquittement peut être reçu sur la partie contrôle SP d’une trame suivante. Dans ce cas, ce message d’acquittement est par exemple noté ARM (pour Acknowledgment Réservation MCS).
Le message d’acquittement indique en plus le schéma de modulation et de codage (MCS) à employer par la suite pour la transmission des données.
D’autres messages d’acquittement remplissant des fonctions additionnelles pourraient être utilisés.
De retour à notre exemple, si un message d’acquittement est reçu et que ce message atteste du bon déroulement de la transmission test, la véritable transmission de données peut avoir lieu sur le premier sous-ensemble de blocs de ressources radio au cours d’une étape 44.
Si un message d’acquittement est reçu mais qu’il indique un problème de transmission test ou si aucun message d’acquittement n’est reçu au niveau des ressources dédiées aux messages d’acquittement, la transmission est interrompue au cours d’une étape 46 et l’envoi des données n’a pas lieu.
L’exemple décrit peut être adapté au cas multidiffusion ou multicast (multiples récepteurs formant un groupe). Dans ce cas particulier, un acquittement positif peut être attendu de la part de chaque membre du groupe multicast, sans quoi la transmission test ne saurait être un succès. Ainsi, par exemple, si l’émetteur ne reçoit qu’un nombre donné d’acquittements positifs alors que le message SA visait un groupe multicast comprenant davantage de récepteurs, ces acquittements peuvent ne pas suffire pour valider la transmission test et la communication peut être abandonnée.
Ainsi, de manière générale, en fonction du nombre d’acquittements reçus et de leur nature (acquittements positifs ou négatifs), l’émetteur peut conclure à une transmission test réussie ou non, et décider de poursuivre ou non la transmission des données en conséquence.
Avantageusement, la solution proposée permet de gérer à la fois les communications unicast et les communications multicast.
Des exemples de trame SC-Period vont maintenant être décrits en référence aux figures 5, 6 et 7. Les figures 5 et 6 concernent des exemples dans lesquels la transmission test est effectuée sur la partie contrôle SP d’une trame et la transmission des données qui s’ensuit est effectuée sur la partie données DP de la même trame. La figure 7 concerne quant à elle une variante dans laquelle la transmission test est effectuée sur une première trame et l’acquittement ainsi que la transmission des données sont effectués sur une autre trame.
Dans les prochaines figures, les données (de test ou pas) sont notées DATA, par opposition aux messages de signalisation.
Sur la figure 5, un message de signalisation SA est transmis sur la partie contrôle SP de la trame. Dans cet exemple, le nœud émetteur est libre de choisir les ressources sur lesquelles il souhaite transmettre les données, parmi les ressources des sous-parties DSP (situation appelée « Open DSP »).
Après un laps de temps suffisant pour que le message SA soit décodé par les nœuds récepteurs concernés, des données de test (constituant ici une première partie des données à transmettre) sont transmises au(x) récepteur(s) visé par le message SA, sur un sous-bloc de ressources dédié (second sous-ensemble) noté TDSP (pour Test Data Sub-Pool). Après un laps de temps suffisant pour que les données de test soient décodées par les nœuds récepteurs concernés, un message d’acquittement SAA est reçu par le nœud émetteur. On suppose dans cet exemple que cet acquittement SAA est positif en ce qu’il atteste de la bonne réception des données de test sur le T-DSP. La transmission du reste des données peut donc avoir lieu sur la partie données DP de la trame. Dans cet exemple, on remarque que le motif tempsfréquence utilisé pour les données de test dans le T-DSP est identique au motif utilisé pour la transmission des données sur les sous-parties DSP du DP.
Sur la figure 6, un message de signalisation SA est transmis sur la partie contrôle SP de la trame.
Dans cet exemple, des configurations de ressources DCH (pour Data Channel) sont prédéfinies dans chaque DSP. Le nœud émetteur est libre de choisir la configuration de son choix sur laquelle il souhaite transmettre les données (situation appelée « Closed DSP»), En l’occurrence, on suppose qu’il existe une correspondance unique entre la ressource utilisée pour envoyer le message SA et une configuration donnée de la partie DP.
Ainsi, l’envoi du message SA sur cette ressource dédiée permet au(x) récepteur(s) d’identifier la configuration (DCH) choisie par l’émetteur pour la future transmission de données. Dans cet exemple, la transmission test est principalement constituée par l’envoi du message de signalisation SA.
Après un laps de temps suffisant pour que le message SA soit décodé par les nœuds récepteurs concernés, un message d’acquittement SAA est reçu par le nœud émetteur.
On suppose dans cet exemple que cet acquittement SAA est positif en ce qu’il atteste de la bonne réception du message SA. La transmission des données peut donc avoir lieu sur la partie données DP de la trame, en particulier sur la configuration DCH correspondant au message SA.
Sur la figure 7, la transmission des données est étalée sur plusieurs trames.
Un message de signalisation SA est transmis sur la partie contrôle SP d’une première trame SC-Period.
Après un laps de temps suffisant pour que le message SA soit décodé par les nœuds récepteurs concernés, des données de test sont transmises au(x) récepteur(s) visé par le message SA, sur un sous-bloc de ressources de la partie DP.
Ces données de test sont constituées par une première partie des données que l’émetteur veut transmettre au(x) récepteur(s).
Lors d’une trame SC-Period future, par exemple la trame suivante, un message d’acquittement ARM est reçu par le nœud émetteur. On suppose dans cet exemple que cet acquittement ARM est positif en ce qu’il atteste de la bonne réception des données de test envoyées sur la trame précédente. La transmission du reste des données peut donc avoir lieu sur la partie données DP de la nouvelle trame. Ainsi, la transmission de la première partie des données effectuée sur la trame précédente sert de transmission test pour la trame future. Dans cet exemple, le motif temps-fréquence utilisé pour les données de test dans la première trame est identique au motif utilisé pour la transmission des données sur les sous-blocs DSP de la trame suivante.
Ces trois exemples décrits en référence aux figures 5, 6 et 7 ne sont que des exemples simplifiés visant à illustrer le principe à la base de l’invention.
Des exemples plus détaillés vont maintenant être décrits en référence aux figures suivantes.
La figure 8 illustre un exemple de transmission SL étalée sur plusieurs trames SC-Period avec libre choix des ressources du DP (Open DP).
Sur la figure 8, seules quelques trames sont représentées, en particulier les deux premières et la dernière trame. Toutefois, l’invention n’est pas limitée à cette représentation. Dans certains modes de réalisation, des transmissions sont mises en œuvre sur plusieurs trames consécutives ou en variante espacées dans le temps.
En général, la transmission est étalée sur plusieurs trames lorsque le volume des données à envoyer est important et/ou en cas de trafic en temps réel ou périodique.
Dans cet exemple, l’émetteur transmet un message de signalisation SA dans la partie contrôle SP d’une première trame.
L’émetteur choisit les ressources radio sur lesquelles il transmet le message SA. En pratique, cette sélection peut être aléatoire (après ou sans mécanisme de Backoff) parmi les ressources dédiées aux messages SA. Alternativement, les ressources SA peuvent être pré-allouées aux nœuds.
Si un mécanisme de Backoff est employé alors le compteur de Backoff est stoppé ou décrémenté à la détection ou non d’un message d’acquittement (par exemple message ARM).
Dans cet exemple, le choix de ressources pour la transmission de données dans le DSP est libre (Open-DSP). Autrement dit, l’émetteur peut choisir les ressources qu’il va utiliser pour transmettre les données.
Ainsi, dans le message de signalisation SA, l’émetteur signale explicitement les ressources choisies dans le DSP ainsi que les informations nécessaires à leur décodage. C’est ce qu’on appelle une « réservation » de ressources.
Si la transmission doit se poursuivre sur une future trame alors l’émetteur signale l’identifiant de cette trame future soit dans le message SA soit conjointement avec les données. Comme on le verra par la suite, selon des modes de réalisation de l’invention, cette réservation peut être acceptée ou refusée par le ou les récepteurs du message SA, en fonction de conflits existant avec d’autres réservations de ressources ou en fonction de la qualité du lien radio ou d’autres critères.
Ensuite, l’émetteur transmet des données sur les ressources choisies dans la partie données DP de cette première trame. Cette transmission sert de test de la qualité du lien radio entre l’émetteur et le(s) récepteur(s).
En réponse à la transmission test, l’émetteur reçoit un message d’acquittement ARM dans la partie contrôle SP de la trame suivante.
En pratique, le récepteur choisit les ressources radio sur lesquelles il transmet le message ARM à l’émetteur du message SA. Cette sélection peut être aléatoire parmi des ressources dédiées aux messages ARM ou signalée par l’émetteur dans son message SA. Cette dernière solution est utile dans le cas d’une transmission multicast (multiples récepteurs) car l’émetteur peut indiquer des ressources séparées pour les différents récepteurs. Une autre solution possible est de prévoir une correspondance prédéfinie entre les ressources utilisées pour la transmission du message SA et les ressources à utiliser pour la transmission du message ARM. Selon une variante, les ressources dédiées pour les messages ARM sont pré-allouées aux nœuds.
De retour à notre exemple, le message ARM atteste de la bonne réception des données de test par le ou les récepteurs visé(s) dans le message SA. Cet acquittement permet à l’émetteur de connaître l’état de la transmission précédente.
Si la transmission n’est pas réussie, le message ARM indique une réponse négative ou il n’est pas envoyé et l’émetteur abandonne la transmission des données qu’il comptait faire suite à la réception du message ARM (cas non représenté sur la figure 8).
Dans le cas contraire (représenté sur la figure 8), le message ARM peut identifier la trame où aura lieu la future transmission et indique le schéma de modulation et de codage MCS que l’émetteur pourrait employer lors de cette future transmission.
Avantageusement, l’émetteur a tout intérêt à utiliser le MCS indiqué dans le message ARM car celui-ci est représentatif de la qualité du lien radio actuel entre l’émetteur et le récepteur. En effet, le MCS indiqué est basé sur une mesure récente de la qualité du lien radio entre l’émetteur et le récepteur que l’on notera RLQI (pour Radio Link Quality Indication).
Par exemple, cette mesure prend en compte le RSRP (pour Reference signal Receive Power) lequel permet d’obtenir une valeur moyenne de la puissance reçue d’un signal de référence par bloc de ressources, le RSSI (pour Reference Signal Strength Indicator) lequel permet d’obtenir une valeur moyenne de la puissance reçue d’un signal de référence sur toute la bande de fréquence et/ou le SI N R (pour Signal-toInterference-plus-Noise Ratio).
Dans un mode de réalisation particulier, le message de signalisation SA indique un MCS seuil au-dessous duquel la transmission ne peut se faire. Lorsque le MCS mesuré par le récepteur et qui devrait être utilisé pour la transmission des données par l’émetteur est inférieur au MCS seuil indiqué dans le message SA, le récepteur envoie un acquittement ARM négatif de sorte que la transmission s’arrête.
Dans un mode de réalisation particulier, le message ARM peut également indiquer des commandes de contrôle de puissance PC (pour Power Control), d’avance de temps TA (pour Timing Advance) prévus dans la norme LTE ou toute autre information utile.
En pratique, la trame et les ressources à réserver pour la transmission future des données sont indiquées par l’émetteur dans son message SA ou conjointement avec les données. Lorsque le récepteur détecte que cette trame (à réserver) ou ces ressources sont en conflit avec ses propres réservations, celui-ci peut refuser la réservation, par exemple en acquittant négativement la transmission test (message ARM négatif).
En effet, dans un mode particulier de réalisation, le récepteur peut lui-aussi réserver des ressources pour protéger sa réception, par exemple en utilisant le message d’acquittement ARM. Pour ce faire, il peut indiquer dans le message ARM l’identifiant de la trame future ainsi que les ressources radio à réserver dans cette trame future. Dans ce cas, un autre terminal, différent de l’émetteur, situé dans le voisinage du récepteur, peut arriver à décoder le message ARM transmis par le récepteur. Ce terminal voisin peut alors mesurer la qualité de la réception de ce message ARM, notée RLQIrx. Lorsque la qualité de la réception RLQIrx est suffisamment bonne (ce critère étant évalué en fonction de l’implémentation), ceci signifie que le terminal voisin ne peut utiliser les ressources réservées sans gêner la communication entre le récepteur et l’émetteur. Par conséquent, ce terminal voisin s’abstient d’utiliser les ressources radio réservées durant la trame future indiquée dans le message ARM. On évite ainsi les conflits de d’accès entre terminaux voisins du récepteur.
Dans une variante de ce mode particulier de réalisation, le message ARM peut aussi indiquer une mesure de la qualité du lien radio avec l’émetteur notée RLQIsig, basée sur la réception des données de test (soit les données transmises dans la trame précédente ici) et/ou du message SA. Dans ce cas, le terminal voisin susmentionné prend en compte cette mesure pour déterminer s’il peut utiliser les ressources réservées sans gêner la communication entre le récepteur et l’émetteur ou s’il doit au contraire s’abstenir d’utiliser les ressources radio réservées durant la trame future indiquée dans le message ARM.
En cas de réservation par le récepteur pour protéger la réception des données, le message ARM doit pouvoir être décodé avant l’occurrence d’une ressource dédiée aux messages SA de la trame réservée. En pratique, c’est l’organisation des ressources dédiées aux messages de signalisation dans la trame qui le permet. Ceci laisse le temps aux voisins du récepteur de prendre en compte la réservation avant d’essayer d’accéder aux ressources de la trame.
En pratique, suite à une réservation par message ARM, une communication peut s’établir sur la trame réservée soit en transmettant un nouveau message SA sur la partie contrôle SP de la trame réservée, soit en procédant directement à la transmission des données sur la partie données DP de la trame réservée.
Dans cet exemple, le message ARM servant à acquitter la transmission test est utilisé comme message de réservation. Toutefois, l’invention n’est pas limitée à cela et un autre message de réservation, par exemple indépendant de l’acquittement, pourrait être utilisé.
De retour à notre exemple, après un certain laps de temps nécessaire au décodage du message ARM ici positif, l’émetteur transmet un message de signalisation SA dans la partie contrôle SP de la deuxième trame puis démarre la transmission des autres données dans la partie données DP de cette trame.
Dans cet exemple, cette transmission s’effectue sur les mêmes ressources radio RB que la précédente, c’est-à-dire sur les ressources ayant servi à la transmission test dans la première trame. En effet, la transmission test a été faite avec succès sur ces ressources et le message ARM a permis d’avertir les voisins du récepteur de l’utilisation future de ces ressources.
L’envoi d’un message SA sur chaque trame réservée peut être utile par exemple pour changer le MCS afin de prendre en compte un changement des conditions radio. Typiquement, un tel changement des conditions radio peut être observé suite à une modification de la topologie du réseau (par exemple déplacement des nœuds). Dans ce cas, le nœud émetteur peut procéder directement à la transmission des données dans le DP avec le nouveau MCS.
Également, l’envoi d’un message SA sur chaque trame réservée peut être utile dans le cas d’une transmission point-à-multipoints, c’est-à-dire d’un émetteur vers une pluralité de récepteurs d’un groupe donné appelé «groupe multicast», où les membres du groupe multicast changent au cours de la communication. En effet, le message SA indique l’identité des récepteurs visés.
De retour à notre exemple, l’émetteur reçoit suite à la dernière transmission un message d’acquittement ACK signifiant la bonne réception de l’ensemble des données (de la première jusqu’à la dernière trame).
De même que pour le message ARM, le récepteur choisit les ressources radio sur lesquelles il transmet le message ACK à l’émetteur du message SA. Cette sélection peut être aléatoire parmi des ressources dédiées aux messages ARM/ACK ou signalée par l’émetteur dans son message SA. Cette dernière solution est utile dans le cas d’une transmission multicast (multiples récepteurs formant un groupe) car l’émetteur peut indiquer des ressources séparées pour les différents récepteurs. Une autre solution possible est de prévoir une correspondance prédéfinie entre les ressources utilisées pour la transmission du message SA et les ressources à utiliser pour la transmission des messages ARM/ACK. Selon une variante, les ressources dédiées pour les messages ARM/ACK sont pré-allouées aux nœuds.
Ainsi, tandis que le message d’acquittement ARM concerne les données de test, le message d’acquittement ACK concerne l’ensemble des données transmises durant la communication.
En variante, le message ARM peut aussi jouer le rôle d’un message ACK.
Dans ce cas, il est envoyé sans indication de réservation future ni de MCS.
Avantageusement, les mécanismes d’acquittement des données de test selon l’invention permettent d’activer des schémas de contrôle d’erreur FEC (pour
Forward Error Correction) rapides au niveau des différentes couches (notamment
RLC/MAC/PHY) des terminaux et de rendre ainsi les communications plus fiables.
Dans certains modes de réalisation, la partie contrôle SP des trames peut être utilisée pour introduire tout type de messages de signalisation (SA, ARM, ACK...) ou même de service de données courts sans signalisation comme par exemple des messages de découverte de voisinage, des messages de signalisation routage ou de signalisation applicative, ou encore pour faire du trafic broadcast (en diffusion).
Dans la partie contrôle SP, des ressources peuvent être dédiées à chaque type de messages de signalisation. En variante, plusieurs types de messages de signalisation peuvent partager les mêmes ressources.
En pratique, les différents messages de signalisation peuvent être transmis sur des ressources de dimensions différentes. Également ou en variante, la dimension des ressources sur lesquelles sont envoyés les messages de signalisation et la dimension des ressources dédiées aux données peuvent être différentes. À titre d’illustration, les messages ARM peuvent être transmis sur des RB de taille réduite en sous-porteuse ou sur 3 dimensions temps/fréquence/code.
Dans un mode de réalisation particulier, les ressources de la partie contrôle SP peuvent être utilisées pour l’envoi de messages de demande d’acquittement ACKREQ et la réception des messages de réponse ACK-RSP correspondants.
Le message de demande d’acquittement ACK-REQ est typiquement envoyé par l’émetteur suite à une ou plusieurs transmissions de données déjà effectuées mais pour lesquelles il n’a pas reçu de messages ACK, soit parce que le système ne prévoit pas de message ACK soit car il n’a pas réussi à le décoder correctement (perte radio). Le message de demande d’acquittement ACK-REQ peut être destiné à un seul récepteur et correspondre à une ou plusieurs transmissions de données. En variante, il peut être destiné à plusieurs récepteurs et correspondre à une ou plusieurs transmissions de données communes (multicast) ou distinctes (unicast).
En pratique, l’émetteur choisit les ressources radio sur lesquelles il transmet le message de demande d’acquittement ACK-REQ. Cette sélection peut être aléatoire parmi des ressources dédiées aux messages ACK-REQ ou dépendre de la sélection des ressources pour l’envoi du message SA.
Le message de réponse ACK-RSP est typiquement envoyé par un récepteur en réponse à un message de demande d’acquittement ACK-REQ. Il peut donc correspondre à une ou plusieurs transmissions de données déjà effectuées. En variante, un récepteur peut répondre à plusieurs messages ACK-REQ d’un même émetteur ou de plusieurs émetteurs différents dans le même message ACK-RSP.
En pratique, le récepteur choisit les ressources radio sur lesquelles il transmet le message de réponse ACK-RSP. Cette sélection peut être aléatoire parmi les ressources dédiées aux messages ACK-RSP ou signalée par l’émetteur dans son message de demande d’acquittement ACK-REQ, ou encore être dépendante de la sélection des ressources dédiées aux messages ARM ou ACK ou ACK-REQ.
Les ressources de la partie contrôle SP peuvent être utilisées aussi pour des transmissions de données directes courtes DSSL (pour Direct Short Side Link) avec envoi préalable de message SA. Les ressources dédiées à ce type de transmission sont notées DSSLP (pour DSSL Pool).
De manière générale, l’organisation des ressources des parties contrôle SP et données DP, c’est-à-dire les ressources dédiées aux différents types de messages, est soit signalée par le réseau (message RRC par exemple dans le cadre de la norme LTE) soit préconfigurée dans les terminaux.
La figure 9a illustre un exemple de répartition des ressources dédiées aux différentes configurations DCH (Closed DSP) dans la partie DP pour une transmission SL unicast étalée sur plusieurs trames.
Ainsi, contrairement à l’exemple décrit en référence à la figure 8, le choix de ressources pour la transmission de données dans le DP n’est pas libre ici mais est limité à un nombre fini de configurations prédéfinies DCH.
Dans cet exemple, chaque DSP de la partie DP est organisé en deux configurations notées DCH #1 et DCH #2.
Ainsi, l’émetteur peut seulement choisir la configuration préfinie qu’il va utiliser pour transmettre les données, mais pas les ressources qui la compose.
En pratique, un DCH peut être partagé entre les terminaux ou en variante être pré-alloué à un sous-ensemble de terminaux.
La figure 9b illustre quant à elle un exemple de répartition des ressources dédiées aux différents types de messages de signalisation (et éventuellement à des données DSSL) dans la partie SP de la trame.
Dans cet exemple, la partie SP contient des ressources dédiées par DCH (DCH #1 et DCH #2 de la figure 9a) aux messages ARM, aux acquittements ACK et aux messages SA. Elle contient de plus des ressources dédiées à des données directes courtes DSSL.
Avantageusement, lorsqu’il y a correspondance unique entre les ressources dédiées aux messages SA, ARM et ACK et les différents DCH, la ressource choisie pour la transmission d’un de ces messages permet au récepteur d’identifier le DCH concerné. Il n’est donc pas nécessaire d’indiquer l’identifiant du
DCH choisi dans le message SA, ARM ou ACK.
En variante (non représentée), les ressources dédiées aux différents types de messages de signalisation, notamment les messages SA, ARM et ACK, pourraient être partagées entre plusieurs DCH. Dans ce cas, le message devrait indiquer explicitement l’identifiant du DCH concerné afin de permettre au récepteur du message d’identifier le DCH concerné.
Bien évidemment, toutes les ressources dédiées à ces messages/données ne sont pas forcément effectivement utilisées au cours d’une transmission. Par exemple, même s’il y a deux RB dédiés aux messages SA relatifs au DCH #1 et deux RB dédiés aux messages SA relatifs au DCH #2, seul un RB dédié peut être effectivement utilisé pour envoyer un message SA pour un DCH donné, comme on le verra dans l’exemple de transmission de la figure 9c.
La figure 9c illustre un exemple de transmission SL unicast étalée sur plusieurs trames avec choix limité aux configurations du DSP (Closed DSP).
Dans cet exemple, chaque trame est organisée comme illustré sur les figures 9a et 9b.
Dans cet exemple, l’émetteur transmet un message de signalisation SA dans la partie contrôle SP d’une première trame.
Ensuite, l’émetteur transmet une première partie des données qui servent de test du lien radio sur la configuration DCH choisie dans la partie données DP de cette première trame.
En réponse à la transmission des données de test, l’émetteur reçoit un message d’acquittement ARM dans la partie contrôle SP de la trame suivante.
De même que dans l’exemple précédent, ce message ARM atteste de la bonne réception des données de test par un récepteur visé dans le message SA. Cet acquittement permet à l’émetteur de connaître l’état de la transmission.
Si la transmission n’est pas réussie, le message ARM n’est pas envoyé par le récepteur ou sinon il indique une réponse négative et l’émetteur abandonne la transmission des données qu’il comptait faire suite à la réception du message ARM (cas non représenté sur la figure 9c).
Dans le cas contraire (représenté sur la figure 9c), le message ARM identifie la trame où aura lieu la future transmission et le schéma de modulation et de codage MCS que l’émetteur pourrait employer lors de cette future transmission.
Dans un mode particulier de réalisation, le récepteur peut lui-aussi réserver les ressources pour protéger sa future réception, par exemple en utilisant le message d’acquittement ARM.
Dans ce cas, de même que pour les ressources dédiées aux messages SA, si les ressources dédiées aux messages ARM sont partagées entre les différents DCH, le récepteur doit indiquer l’identifiant du DCH réservé dans le message ARM.
En revanche, s’il y a correspondance entre les ressources dédiées aux messages ARM et les DCH, la ressource choisie pour la transmission du message ARM permet d’identifier le DCH réservé. Il n’est donc pas nécessaire d’indiquer l’identifiant du DCH choisi dans le message ARM.
Avantageusement, grâce à la correspondance unique entre les ressources dédiées aux messages ARM et les DCH, même si le message ARM n’est pas correctement décodé par un terminal voisin du récepteur autre que l’émetteur, ce terminal voisin peut mesurer la qualité de la réception RLQIrx du message ARM et déterminer s’il peut utiliser le DCH identifié (grâce à la ressource sur laquelle est transmis le message ARM) sans gêner la communication entre le récepteur et l’émetteur. Le cas échéant, le terminal voisin s’abstient d’utiliser le DCH réservé durant la trame future. On évite ainsi les conflits de réservations entre terminaux voisins.
En pratique, afin de permettre à un terminal voisin du récepteur de déterminer la trame future réservée par un message ARM sans nécessairement le décoder correctement pour en extraire le contenu, chaque ensemble de ressources dédiées aux messages ARM et correspondant à un DCH peut être divisé en un certain nombre de sous-ensembles de ressources. Chaque sous-ensemble de ressources ainsi constitué permet de transporter un ou plusieurs messages ARM et correspond à une demande de réservation sur une trame future distante d’un certain temps prédéfini de la trame où le message ARM a été envoyé. Comme mentionné précédemment, un message ARM peut éventuellement permettre de réserver le DCH correspondant dans une trame future. Cependant, ce n’est pas toujours le cas car un message ARM peut simplement servir à acquitter la bonne réception des données.
De préférence, dans un mode d’émission/réception half-duplex (HD), un nœud qui est en émission sur un slot contenant des ressources dédiées aux messages
ARM s’interdit d’accéder à tous les DCH susceptibles d’être réservés par messages
ARM sur ce slot pendant les trames futures que ces messages ARM pourraient réserver. Une solution possible pour palier à cette contrainte est de regrouper les ressources dédiées aux messages ARM de différents DCH correspondant à la même trame future sur le ou les mêmes slots.
Les exemples décrits en référence aux figures 8 et 9 concernent plus particulièrement les transmissions étalées sur plusieurs trames. Comme mentionné, les conflits concernant l’accès aux ressources dans de telles situations sont évités en utilisant la transmission effectuée sur une trame précédente comme moyen de tester si les ressources radio choisies seront en conflits ou non sur la trame suivante. Le mécanisme de réservation par message ARM permet d’éviter de nouveaux conflits lors des transmissions futures.
Les exemples décrits en références aux figures 10, 11 et 12 permettent plus particulièrement d’éviter les conflits avant même d’accéder pour la première fois à la partie données DP d’une trame.
Pour ce faire, il est proposé d’effectuer une transmission test directement dans la partie contrôle SP de la trame et d’y prévoir des ressources dédiées aux messages d’acquittement (tel que le message SAA pour Scheduling Assignment Acknowledgment). Dans un premier mode de réalisation, des ressources spécifiques notées T-DSP (pour Test DSP) sont dédiées à l’envoi d’une première partie des données servant de données de test (figures 10 et 11). Dans un second mode de réalisation, des ressources dédiées aux messages de signalisation SA par DCH sont prévues (figure 12).
La figure 10 illustre un exemple de transmission SL unicast sur une seule trame avec libre choix des ressources du DSP (Open DSP).
Cet exemple diffère de celui décrit en référence à la figure 8 en ce que la transmission test et l’acquittement sont effectuées dans la partie SP de la trame et la transmission de données qui s’ensuit est effectuée dans la même trame.
Dans cet exemple, l’émetteur transmet un message de signalisation SA dans la partie contrôle SP de la trame.
L’émetteur choisit les ressources radio sur lesquelles il transmet le message SA. En pratique, cette sélection peut être aléatoire (après ou sans mécanisme de Backoff) parmi les ressources dédiées aux messages SA.
Alternativement, les ressources SA peuvent être pré-allouées aux nœuds.
Si un mécanisme de Backoff est employé alors le compteur de Backoff est stoppé ou décrémenté à la détection ou non d’un message d’acquittement (par exemple message SAA).
Dans cet exemple, le choix de ressources pour la transmission de données dans les DSP est libre (Open-DSP). Autrement dit, l’émetteur peut choisir les ressources qu’il va utiliser pour transmettre les données en cas de test positif.
Ainsi, dans le message de signalisation SA, l’émetteur signale explicitement les ressources choisies ainsi que les informations nécessaires à leur décodage.
Ensuite, l’émetteur transmet des données de test sur des ressources dédiées T-DSP.
Le récepteur décode le message SA qui lui est destiné, procède au décodage des données de test transmises dans le T-DSP et envoie un message d’acquittement SAA à l’émetteur sur la ressource dédiée dans la partie contrôle SP de la trame.
En pratique, le récepteur choisit les ressources radio sur lesquelles il transmet le message SAA. Cette sélection peut être aléatoire parmi les ressources dédiées aux messages SAA ou signalée par l’émetteur dans son message SA. Une autre solution possible est qu’il y ait une correspondance prédéfinie entre les ressources utilisées pour la transmission du message SA et les ressources à utiliser pour la transmission du message SAA. En variante, les ressources dédiées aux messages SAA sont pré-alloués aux nœuds.
De manière générale, les ressources dédiées aux messages SAA sont séparées de celles du T-DSP par un temps «Tp» permettant d’une part le décodage des données de test envoyées sur le T-DSP et d’autre part le codage du message SAA par le récepteur. À titre d’illustration, dans le standard actuel LTE, «Tp» correspond à 4ms.
Ce message SAA atteste de la bonne réception des données de test par le ou les récepteurs visé(s) dans le message SA. Cet acquittement permet à l’émetteur de connaître l’état de la transmission.
Si la transmission test n’est pas réussie, le message SAA n’est pas envoyé ou sinon il indique une réponse négative et l’émetteur abandonne la transmission des données qu’il comptait faire suite à la réception du message SAA (cas non représenté sur la figure 10).
Dans le cas contraire (représenté sur la figure 10), après un certain laps de temps nécessaire au décodage du message SAA ici positif, l’émetteur démarre la transmission de données dans la partie DP de cette trame.
Dans cet exemple, le motif temps-fréquence des ressources RB utilisées pour l’envoi des données dans les DSP est identique au motif temps-fréquence des ressources qui sont utilisées pour envoyer les données de test dans le T-DSP.
Enfin, au début de la trame suivante, l’émetteur reçoit un message d’acquittement ACK signifiant la bonne réception de l’ensemble des données.
La figure 11 illustre un autre exemple de transmission SL unicast sur une seule trame avec choix des configurations du DSP (Closed DSP).
Cet exemple diffère de celui décrit en référence à la figure 9 en ce que la transmission test et l’acquittement sont effectuées dans la partie SP de la trame et la transmission de données qui s’ensuit est effectuée dans la même trame.
De plus, contrairement à l’exemple décrit en référence à la figure 10, le choix de ressources pour la transmission de données dans les DSP n’est pas libre ici (Closed-DSP) mais est limité à un nombre fini de configurations prédéfinies DCH. Chaque DSP est par exemple organisé comme illustré sur la figure 9a. En général, un DCH peut avoir des configurations de ressources différentes dans chaque DSP de la trame.
Ainsi, l’émetteur peut seulement choisir la configuration prédéfinie qu’il va utiliser pour transmettre les données en cas de test positif, mais pas les ressources qui la compose.
Dans cet exemple, l’émetteur transmet un message de signalisation SA dans la partie contrôle SP de la trame.
Ensuite, l’émetteur transmet des données de test sur des ressources dédiées T-DSP. Il est rappelé que ces données de test constituent une partie des données « utiles » que l’émetteur souhaite transmettre au(x) récepteur(s) indiqués dans le message SA.
Dans ce schéma Closed-DSP, la taille du T-DSP peut être réduite par rapport à \’Open-DSP. En effet, il suffit que chaque DCH soit représenté dans le T-DSP par au moins un RB.
Le récepteur décode le message SA qui lui est destiné, procède au décodage des données de test transmises dans le T-DSP et envoie un message d’acquittement SAA à l’émetteur sur la ressource dédiée dans la partie contrôle SP de la trame.
Si la transmission test n’est pas réussie, le message SAA indique une réponse négative ou n’est pas envoyé et l’émetteur abandonne la transmission des autres données qu’il comptait faire suite à la réception du message SAA (cas non représenté sur la figure 11).
Dans le cas contraire (représenté sur la figure 11), après un certain laps de temps nécessaire au décodage du message SAA ici positif, l’émetteur démarre la transmission de données dans la partie DP de cette trame.
Dans cet exemple, le motif temps-fréquence des ressources RB utilisées pour l’envoi des données dans les DSP correspond aux configurations du DCH dans ces DSP et peut être différent du motif temps-fréquence des ressources qui sont utilisées pour envoyer les données de test dans le T-DSP. Ceci est dû au fait qu’il suffit que chaque DCH soit représenté par au moins un RB dans le T-DSP.
Dans cet exemple, l’émetteur reçoit un message d’acquittement ARM au début de la trame suivante, acquittant d’une part la réception de l’ensemble des données sur la trame précédente et d’autre part valant message de réservation pour une trame future, tel qu’expliqué précédemment en référence à la figure 9.
Dans cet exemple, suite au message ARM, une nouvelle transmission test a lieu sur la trame future réservée. Les différents messages et données mentionnés dans cet exemple (SA, données de test sur le T-DSP, SAA, données) sont échangés de nouveau sur la trame réservée par le message ARM.
La figure 12 illustre un exemple de transmission SL unicast étalée sur plusieurs trames avec choix limité aux configurations du DSP (Closed DSP).
Dans cet exemple, l’émetteur transmet un message de signalisation SA dans la partie contrôle SP de la trame. Cette transmission constitue la transmission test. En effet, dans cet exemple, il y a correspondance unique entre les ressources dédiées aux messages SA et les DCH, et le message SA est utilisé pour à la fois signaler et tester la qualité du lien radio entre l’émetteur et le récepteur sur le DCH choisi. Ainsi, contrairement à l’exemple décrit en référence à la figure 11, pendant la transmission test, on n’envoie pas de données en plus du message SA.
Il est important de noter que le message SA doit être transmis sur toutes les ressources SA dédiées au DCH en question. En l’occurrence, dans cet exemple, un seul RB est dédié par DCH donc un seul message SA est nécessaire. Cependant, si deux (ou plus) RB étaient dédiés aux messages SA, il faudrait envoyer autant de messages SA.
Avantageusement, il n’est pas nécessaire d’indiquer l’identifiant du DCH dans le message SA car le récepteur pourra identifier le DCH correspondant en fonction de la ressource utilisée pour envoyer le message SA.
Le récepteur décode le message SA qui lui est destiné et envoie un message d’acquittement SAA à l’émetteur sur la ressource dédiée dans la partie contrôle SP de la trame pour indiquer qu’il a correctement reçu le message SA.
Le message SAA peut indiquer le MCS à utiliser par la suite dans la transmission des données, une commande de contrôle de puissance ou d’avance de temps ou toute autre information utile.
Si l’émetteur reçoit correctement le message SAA, la transmission des données peut avoir lieu sur le DCH correspondant à la ressource sur laquelle le message SA a été reçu. Un émetteur qui ne reçoit pas de message SAA ne procède pas à la transmission de données.
Dans cet exemple, l’émetteur reçoit un message d’acquittement ARM au début de la trame suivante, acquittant d’une part la réception de l’ensemble des données sur la trame précédente et d’autre part valant message de réservation pour une trame future, tel qu’expliqué précédemment.
Dans cet exemple, suite au message ARM, une nouvelle transmission test a lieu sur la trame future réservée. En pratique, cette transmission test comprend l’envoi d’un message SA sur la trame réservée. Les différents messages et données mentionnés dans cet exemple (SA, SAA, données) sont échangés de nouveau sur la trame réservée par le message ARM.
Dans des modes de réalisation, une trame peut contenir des DSP de tailles différentes. En cas d’Open-DSP, un T-DSP correspondant à chaque type de DSP peut être prévu dans la partie SP. En cas de Closed-DSP, un T-DSP où chaque DCH est représenté ou une ressource dédiée au message SA correspondant à chaque DCH peut être prévu dans la partie SP.
Les ressources dédiées aux messages de signalisation peuvent être partagées entre différents types de DSP ou être divisées en configuration fixes où chacune est dédiée à un type de DSP. Si les ressources dédiées aux messages SA sont partagées entre différents types de DSP, le message SA identifie explicitement le DSP utilisé.
La figure 13 illustre un exemple de transmission SL sur une trame comprenant plusieurs parties contrôle SP de sorte que des communications peuvent être initiées et se terminer à différents endroits de la trame. Une telle configuration permet à plusieurs terminaux d’accéder aux ressources radio d’une même trame SCPeriod successivement et tout en évitant les conflits. En effet, grâce à la pluralité de parties SP, une communication peut être initiée à plusieurs endroit de la trame.
Une partie SP peut contenir des ressources dédiées à la signalisation mais aussi aux données (Open-DSP ou Closed-DSP). Dans certains cas, un même RB peut être partagé entre la signalisation et les données.
De préférence, une partie SP qui contient des ressources dédiées aux messages SA contient des ressources dédiées aux messages SAA correspondants. Dans ce cas, la partie SP doit être suffisamment longue dans le temps pour permettre l’établissement d’une communication, c’est-à-dire pour permettre l’envoi par un émetteur d’un message SA et éventuellement de données de test (constituées généralement par une partie des données « utiles » à envoyer), la réception de la réponse SAA et le décodage de cette réponse.
La trame peut éventuellement comprendre une partie DP uniquement dédiée aux données, composée de DSP et/ou de DCH.
De manière générale, les ressources dédiées aux messages SA, aux données de test le cas échéant et aux messages SAA, peuvent être disposées n’importe où dans les parties SP. Toutefois, les ressources dédiées aux messages SA et SAA utilisés pour l’établissement d’une communication doivent être suffisamment espacées dans le temps pour permettre le décodage du message SA, le décodage des éventuelles données de test et le décodage du message SAA avant l’occurrence d’une nouvelle ressource dédiée aux messages SA.
Dans l’exemple illustré sur la figure 13, la trame se compose de trois parties SP et il n’y a pas de partie DP. Chaque partie SP se compose d’un slot dédié aux messages SA (première colonne de RB) puis d’un premier DSP suivi d’un T-DSP puis d’un second DSP, puis d’un slot dédié aux messages d’acquittement (SAA/ACK) puis d’un dernier DSP. Les ressources pour la transmission de données sont au libre choix de l’émetteur (Open-DSP).
Comme visible sur la figure 13, dans une première partie SP, un terminal A transmet à un terminal B un message SA puis des données de test sur une première partie des ressources dédiées dans le T-DSP. Le terminal B décode le message SA du terminal A ainsi que les données de test et transmet un acquittement SAA au terminal
A afin d’autoriser la transmission de données. Cette transmission de données a lieu sur les ressources correspondantes des DSP et T-DSP des SP suivants de la trame. On remarque que le motif temps-fréquence est identique sur les DSP et T-DSP des SP suivant et sur le T-DSP de la première partie SP où a été effectuée la transmission test de A vers B.
Dans cet exemple, un terminal C voisin du terminal B reçoit également l’acquittement SAA transmis par le terminal B et détecte ainsi qu’il est trop proche de celui-ci pour utiliser les mêmes ressources pour ses propres transmissions.
Ainsi, dans la seconde partie SP, le terminal C transmet à un terminal D un message SA indiquant des ressources différentes de celles utilisées par B pour recevoir des données de A.
Le terminal C transmet également des données de test sur une deuxième partie des ressources dédiées dans le T-DSP. Le terminal D décode le message SA du terminal C ainsi que les données de test et envoie un acquittement SAA au terminal C afin d’autoriser la transmission de données sur les ressources correspondantes. Cette transmission de données a lieu sur les ressources correspondantes des DSP et T-DSP de la partie SP suivante. On remarque que le motif temps-fréquence est identique sur les DSP et T-DSP de la partie SP suivante et sur le T-DSP de la seconde partie SP où a été effectuée la transmission test de C vers D.
Ces modes de réalisation permettent ainsi de réduire les conflits entre terminaux voisins, tout en permettant une utilisation optimale des ressources radio.
Bien que l’exemple décrit en référence à la figure 13 concerne un cas Open-DSP, l’homme du métier pourra sans difficulté transposer les enseignements au cas Closed-DSP où des configurations de données sont prédéfinies de sorte que l’émetteur n’a pas la possibilité de choisir individuellement les ressources RB.
De manière générale, des modes de réalisation permettent à une communication initiée dans une partie SP de se poursuivre après la réception de l’acquittement SAA sur tous les DSP/DCH suivants de la trame, qu’ils soient dans des parties SP ou dans des parties DP.
Ainsi, lorsque l’émetteur peut choisir les ressources (Open-DSP) lors de l’établissement d’une communication à un certain SP #i de la trame, les T-DSP des SP suivants sont utilisés comme des DSP réguliers de données. Ceci permet aux communications qui s’établiront aux SP suivants de prendre en compte la présence des communications déjà établies sur les ressources de la trame.
Lorsqu’il y a correspondance unique entre les ressources dédiées aux messages SA et les DCH (Closed-DSP), le message SA doit être transmis sur les ressources correspondant au DCH choisi pour la transmission de données. Une fois qu’une communication est établie, les ressources dédiées aux messages SA et au
DCH sont utilisées par cette communication. Ceci permet aussi aux terminaux voisins de prendre en compte les communications déjà établies sur les DCH de la trame.
Dans un mode de réalisation particulier, le message d’acquittement SAA peut indiquer les ressources ou le DCH réservé par le message SA. Un autre terminal, différent de l’émetteur, situé dans le voisinage du récepteur, peut arriver à décoder ce message d’acquittement SAA et peut alors mesurer la qualité de la réception RLQIrx de ce message. Lorsque la qualité de la réception RLQIrx est suffisamment bonne (ce critère étant évalué en fonction de l’implémentation), ceci signifie que le terminal voisin ne peut utiliser les ressources ou le DCH réservés sans gêner la communication entre le récepteur et l’émetteur. Par conséquent, ce terminal voisin s’abstient d’utiliser les ressources radio / le DCH réservés par le message SA. On évite ainsi les conflits de réservations entre terminaux voisins.
Dans une variante de ce mode particulier de réalisation, le message SAA peut aussi indiquer une mesure de la qualité du lien radio avec l’émetteur notée RLQIsig, basée sur la réception du message SA et/ou des données de test s’il y en a. Dans ce cas, le terminal voisin susmentionné prend en compte cette mesure pour déterminer s’il peut utiliser les ressources ou le DCH réservés sans gêner la communication entre le récepteur et l’émetteur ou s’il doit au contraire s’abstenir d’utiliser les ressources radio / le DCH réservés par le message SA.
Avantageusement, en cas de correspondance unique entre les ressources dédiées aux messages SAA et les DCH, même si le message SAA n’est pas correctement décodé pour en extraire le contenu par un terminal voisin du récepteur autre que l’émetteur, ce terminal voisin peut mesurer la qualité de la réception RLQIrx du message SAA et déterminer s’il peut utiliser le DCH identifié (grâce à la ressource sur laquelle est transmis le message SAA) sans gêner la communication entre le récepteur et l’émetteur. Le cas échéant, le terminal voisin s’abstient d’utiliser le DCH réservé durant le reste de la trame.
Ainsi, le message SAA permet de protéger une communication établie sur une trame et d’éviter que des terminaux voisins établissent eux-mêmes une communication sur les ressources utilisées.
De préférence, dans un mode d’émission/réception half-duplex (HD), un nœud qui est en émission sur un slot contenant des ressources dédiées aux messages
SAA s’interdit d’accéder à toutes les ressources / DCH susceptibles d’être réservés par messages SAA sur ce slot pendant la trame courante.
Le fait d’interdire les voisins d’un récepteur, par le biais du message SAA, d’accéder aux ressources utilisées par ce récepteur permet de résoudre le problème bien connu du terminal caché.
Il est rappelé que le problème du terminal caché se pose lorsqu’un terminal A est dans le voisinage d’un terminal B lui-même dans le voisinage d’un terminal C, les terminaux A et C n’étant pas dans le voisinage l’un de l’autre. Ainsi, le terminal A est un terminal caché pour le terminal C et réciproquement. Ce problème a pour conséquence que si le terminal A émet vers le terminal B, le terminal C ne le voit pas et peut donc décider d’émettre vers le terminal B, auquel cas il y aura collision (et le terminal A ne s’en rendra pas compte).
Les modes de réalisation dans lesquels les ressources dédiées aux messages SAA ne sont pas partagées avec d’autres messages de signalisation ou avec des données permettent en plus de résoudre les problèmes bien-connus du terminal masqué et du terminal exposé ce qui permet une réutilisation spatiale maximale des ressources radio.
Il est rappelé que le problème du terminal masqué se pose lorsqu’un terminal A émet vers un terminal B voisin d’un terminal C et qu’un terminal D voisin du terminal C est déjà en émission vers un terminal E. Le terminal C est un terminal masqué pour B car les messages de signalisation émis par le B sont masqués par la transmission de D. Cette situation est fréquente dans les topologies à plusieurs bonds radio et dégrade les performances en termes de débit.
Il est également rappelé que le problème du terminal exposé se pose lorsqu’un terminal B émet vers un terminal A et que le terminal B est voisin d’un terminal C que le terminal A ne voit pas. Le terminal C s’interdit d’émettre vers un autre terminal voisin D car il entend que B est en émission (vers le terminal A), il est donc exposé à B, alors qu’il pourrait tout à fait émettre vers le terminal D sans gêner la communication de B vers A.
Il est fait remarquer que le problème du terminal masqué est résolu même en cas de non réception du message SAA lorsqu’il y a correspondance entre la ressource utilisée pour envoyer le SAA et un DCH (Closed-DSP) puisque la détection d’une transmission sur une ressource dédiée aux messages SAA permet à elle seule de protéger la réception sur le DCH en question jusqu’à la fin de la trame.
De manière générale, le fait de prévoir des ressources dédiées aux messages SA sur plusieurs SP permet, avec un minimum de ressources, à plusieurs liens de communications qui ne sont pas mutuellement en conflit de s’établir tout au long de la trame. La solution ainsi présentée permet d’atteindre une réutilisation spatiale maximale des ressources radio avec un minimum de ressources dédiées aux messages SA.
Selon des modes de réalisation particuliers, le message SAA pourrait être envoyé après l’établissement de la communication. Ceci est optionnel et pourrait être avantageux dans diverses situations, par exemple en cas de changement de MCS.
Dans un mode de réalisation particulier, le récepteur envoie plusieurs messages SAA, par exemple à intervalles réguliers, sur plusieurs parties SP prédéfinies de la trame. Ceci permet par exemple de mettre à jour le MCS employé et d’acquitter les données jusque-là reçues.
En effet, le fait que les communications puissent s’initier et se terminer à n’importe quelle partie SP d’une trame peut provoquer des changements de la qualité radio des communications établies. Un changement du MCS employé est souhaitable dans ce cas pour s’adapter aux éventuels changements de la qualité du lien radio.
Avantageusement, un nouveau message SAA étant envoyé en cours de communication (c’est-à-dire après la phase de test), il permet d’employer des schémas de contrôle d’erreur FEC rapides, par exemple de type H-ARQ (pour Hybrid Automatic Repeat reQuest) au niveau des différentes couches (notamment RLC/MAC/PHY).
Selon un mode de réalisation particulier, le nouveau message SAA peut aussi servir à protéger les ressources radio en réception sur une trame. Dans ce cas le nouveau message SAA protège les ressources en réception jusqu’à la prochaine occurrence après un intervalle prédéfini d’une ressource dédiée aux messages SAA dans la trame où le renvoi est prévu ou le cas échéant jusqu’à la fin de la trame.
Ce schéma a l’avantage de libérer des nœuds qui ne pouvaient pas accéder aux ressources protégées (c’est-à-dire en cours d’utilisation) au cours de la transmission suite à des changements de leur qualité de lien radio vers le récepteur.
Si un schéma de réservation par message SAA est utilisé et qu’un récepteur souhaite faire une réservation des mêmes ressources pour une trame future alors le message SAA est envoyé sur chaque ressource dédiée aux messages SAA de la trame où le renvoi est prévu même si la transmission des données s’arrête avant la fin de la trame.
Dans un mode d’émission/réception half-duplex, un nœud en émission sur un slot contenant des ressources dédiées aux messages SAA (ou tout autre message de réservation) s’interdit d’accéder à toutes les ressources de données que les messages SAA (ou tout autre message de réservation) de ce slot pourraient réserver jusqu’à l’occurrence des prochaines ressources dédiées aux messages SAA dans la trame où le renvoi est prévu ou le cas échéant jusqu’à la fin de la trame.
Dans des modes de réalisation particuliers, il peut être intéressant d’établir une communication SL bidirectionnelle sur une même trame.
Dans ce cas, l’émetteur qui initie une communication bidirectionnelle (appelé par la suite « premier émetteur » ou « second récepteur ») indique dans son message SA les ressources radio / le DCH sur lesquelles il est déjà en émission ou en réception dans la trame courante. Il indique par la suite, conjointement avec les données, tout changement de ressources / de DCH qu’il utilise en attendant que le récepteur (appelé par la suite « premier récepteur » ou « second émetteur ») établisse la communication dans l’autre sens.
Dans le cas d’émission/réception Half-Duplex bidirectionnelle, le premier récepteur établit la communication vers le premier émetteur en choisissant des ressources pour la transmission du message SA et les données qui ne sont pas sur des slots sur lesquels le premier émetteur est en émission et qui ne sont pas déjà utilisées en réception par ce premier émetteur.
Pour permettre l’établissement d’une communication SL bidirectionnelle, la 1ère partie contrôle SP de la trame contenant une signalisation SA/SAA doit contenir des ressources pour le transport de deux messages SA sur deux slots distincts, ainsi que pour le transport de deux messages SAA sur deux slots distincts. En cas de réservation d’une trame future par message ARM, la première partie contrôle SP de cette trame doit également contenir des ressources pour deux messages SA et SAA.
De manière similaire, la trame doit contenir des ressources pour le transport de deux messages ACK et ARM sur deux slots distincts, si ceux-ci sont utilisés.
En pratique, le premier récepteur (i.e. le second émetteur) peut indiquer dans son message SA les ressources qu’il utilisera pour la transmission des messages ACK et ARM. De même, l’émetteur (i.e. le second récepteur) peut indiquer dans son message SAA les ressources qu’il utilisera pour la transmission des messages ACK et ARM. Également, le premier émetteur et le premier récepteur peuvent indiquer dans leurs message ARM les ressources qu’ils utiliseront dans la trame future réservée pour la transmission de leurs messages SA et SAA.
On notera que pour les trafics bidirectionnels rapides ou présentant une asymétrie dans le volume de données échangées dans les différents sens (signalisation SIP, session TCP, http, etc.), il est préférable d’établir une communication SL bidirectionnelle dans une même trame.
Dans des modes de réalisation particuliers, il peut être intéressant d’établir une communication entre deux terminaux en utilisant une multiplicité de communications SL établies entre des relais situés entre ces terminaux.
Dans ce cas la communication est relayée par un ou plusieurs terminaux relai sur un ou plusieurs bonds radio. Le choix des relais se fait sur la base d’une certaine connaissance de l’état des liens entre terminaux, mais généralement sans relation prise en compte des communications existantes ce qui peut conduire à des conflits au niveau de l’accès à la ressource.
Afin de résoudre ce problème, il est proposé d’utiliser la transmission test pour obtenir des mesures de qualité des chemins entre les terminaux éloignés (appelés nœud source et nœud destination) passant par différents relais.
Pour ce faire, il est proposé d’adresser le message SA aux différents relais possibles. Un nœud source ayant le choix entre un nombre k de relais potentiels vers sa destination finale qui est à un nombre B de bond radio envoie un message SA contenant l’information d’identification de ces relais et l’identifiant du nœud destination.
Chaque relai k décode le message SA et mesure la qualité de la réception RLQIrx du message SA et/ou des données de test s’il y en a. Il calcule ensuite une indication de la qualité des chemins entre le nœud source et le nœud destination passant par lui, notée PQlE2N(k) (pour Path Quality Indication). Cette indication peut être par exemple une moyenne des débits espérés sur tous ou une sélection des chemins possibles entre le nœud source et nœud destination passant par le relai. Le relai k envoie par la suite un message SAA de réponse. Ce message SAA contient, entre autres informations, le MCS entre le relai et le nœud source et le PQlE2N(k).
Le nœud émetteur peut ainsi, à partir des messages SAA et notamment des différents PQlE2N(k) reçus, choisir un des relais. Il indique l’identifiant de ce relai dans un message d’entête (J-leader) transmis avec les données.
Ensuite, un relai qui décode correctement cet entête et qui est désigné comme relai poursuit la réception des données. En cas d’échec du décodage de l’entête ou en cas de non sélection par le nœud source, le relai abandonne la réception des données.
Dans certains cas, il est possible que le débit entre le nœud source et le nœud destination soit inférieur au débit cumulé entre le nœud source et le relai d’une part et d’autre part entre le relai et le nœud destination.
Dans ce cas, il peut être avantageux de passer par ce relai même si le nœud source et le nœud destination sont dans la portée l’un de l’autre et peuvent communiquer directement.
Dans un mode particulier de réalisation, le nœud source peut indiquer dans le message SA un seuil THpqi tel que lorsqu’un relai k ne répond avec un message SAA que si l’indication de qualité des chemins PQlE2N(k)est supérieure à ce seuil.
Également, le nœud source peut indiquer dans le message SA le nombre de bonds radio max que le calcul de l’indication de qualité des chemins PQlE2N<k) doit prendre en compte.
Le nœud source peut indiquer dans le message SA un seuil RLQImin sur le RLQI tels que seuls les chemins ayant un RLQI supérieurs à ce seuil sont pris en compte dans le calcul de l’indication PQI e2n par les relais.
Dans des modes de réalisation particuliers, une transmission point-àmultipoints, c’est-à-dire d’un émetteur vers une pluralité de récepteurs d’un groupe donné appelé «groupe multicast », peut être établie. De telles transmissions sont utilisées par exemple dans le cadre de services de sécurité publique.
Dans cet exemple, on considère un groupe multicast constitué de N (N > 2) nœuds dont K (1 < k < N) sont des émetteurs potentiels PT (pour Potentiel Transmitters). Plusieurs groupes multicast notés MG (pour Multicast Group) partagent des ressources radio du système et un nœud peut appartenir à plusieurs MG.
Le message SA envoyé durant la transmission test identifie le MG visé et le MCS que l’émetteur a l’intention d’employer pour la transmission des données.
Afin de pouvoir adapter le MCS utilisé aux conditions radio entre l’émetteur et les récepteurs, le MCS indiqué dans le message SA n’est utilisé que sur les premiers slots contenant des ressources choisies par l’émetteur.
Sur la base du nombre de messages SAA reçus et de l'information qu’ils contiennent, l’émetteur peut décider de procéder à la transmission des données ou non.
Dans le premier cas, il envoie un message d’entête, transmis exclusivement ou conjointement avec les données, sur les premiers slots contenant des ressources qu’il a choisi, en y indiquant le MCS qui sera employé pour la suite de la transmission. Les premiers slots doivent être en nombre suffisant pour permettre de transporter le message d’entête et donner aux récepteurs le temps nécessaire pour le décoder. Ce nombre peut être signalé dans le message SA ou être préconfiguré dans le système.
Les nœuds d’un MG peuvent ne pas être tous dans la portée radio les uns des autres. Un nœud peut indiquer dans son message SAA les RLQI de ses liens radio avec tous ou une sélection de nœuds du MG. Une sélection peut être faite par un seuil sur le RLQI par exemple signalé dans le message SA ou préconfiguré. Sur la base des informations reçues dans les messages SAA, l’émetteur décide du MCS à employer pour la transmission, calcule un graphe de diffusion dans le groupe et désigne une liste des relais ainsi qu’une liste des nœuds vers lesquels chaque relai doit relayer la transmission, directement et éventuellement via d’autres relais.
Ces informations sont transmises aussi dans le message d’entête des données. Un relai k avec une transmission à relayer vers une partie des nœuds du MG procède de la même façon que le nœud source à l’exception de l’identité des nœuds destinataires et des relais suivants. Un émetteur peut aussi indiquer dans le message d’entête sur quelle trame et quelles ressources radio (pour la signalisation et les données) ses relais peuvent établir les communications pour le relayage des données.
Un relai peut informer le relai qui le précède ou le nœud source de l’état de sa propre transmission (établissement ou non, identité de ses récepteurs effectifs, ressources utilisées, MCS employé, ...) via des messages SAA, ARM, ou ACK.
Un émetteur peut indiquer lors d’une communication multicast sur plusieurs trames le changement des informations relatives aux nœuds destinataires et au relayage. Cette indication peut être faite via le message SA ou conjointement avec les données via un message d’entête. Un changement peut intervenir en cas de mobilité des nœuds par exemple.
Un nœud qui reçoit plusieurs messages SA pour rejoindre la même communication multicast peut décider de rejoindre la meilleure en termes de qualité radio ou de distance par rapport au nœud source en nombre de bonds radio.
En pratique, des ressources suffisantes sont prévues pour les messages SAA. Notamment, les ressources SAA peuvent être sur des RB de taille réduite (en temps et/ou en fréquence par exemple) par rapport aux autres RB de la trame. Ils peuvent aussi être sur des RB ayant une dimension supplémentaire par rapport aux autres RB de la trame.
La figure 14 représente un exemple d’un lien de communication multicast dans un groupe multicast MG. D’autres MG peuvent partager les ressources radio avec ce MG mais ne sont pas représentés. Dans cet exemple, le MG est composé de nœuds (A, B, C, D, E, F, G et H). La transmission du nœud A vers le groupe nécessite un relayage du nœud E vers les nœuds F, G et H.
La figure 15 illustre un exemple d’établissement de communication SL multicast sur des trames composées d’un certain nombre de SP.
Les ressources dédiées à la signalisation SAA sont pré-allouées à chaque nœud du MG ou signalées par le nœud émetteur dans le message SA. Les ressources dédiées à la signalisation SAA sont sur des RB de taille réduite correspondant à la moitié de la taille d’un RB régulier en termes de sous-porteuse. Au cours d’une première trame, le nœud A réussi la transmission test vers B, C, D, et E. Sur la trame suivante, le nœud E, désigné par A, relaie cette transmission vers F, G et H.
Dans des modes de réalisation particuliers, il peut être intéressant d’établir une communication de type broadcast (diffusion), entre un émetteur et tout récepteur se trouvant dans la portée de l’émetteur. Dans ce cas, les récepteurs visés n’appartiennent pas à un groupe donné comme pour le multicast.
Une difficulté qui se pose alors est que l’émetteur ne connaît pas le nombre d’acquittements qu’il est sensé recevoir suite à la transmission test puisqu’il ne vise pas de récepteur précis lors de cette transmission test.
Pour pallier à cette difficulté, il est possible de prévoir un acquittement implicite, notamment lorsque la communication broadcast est étalée sur plusieurs trames.
En pratique, l’émetteur signale la trame future sur laquelle il souhaite transmettre des données dans son message SA envoyé pendant la transmission test. Dans ce mode de réalisation, la transmission test s’effectue par exemple sur le même ensemble de ressources que celui souhaité pour la transmission des données.
Chaque nœud recevant le message SA et décodant son contenu peut identifier puis mémoriser l’ensemble des ressources radio qui vont être utilisées lors des futures trames. Ainsi, lorsqu’il souhaite lui-même établir une communication, le nœud peut indiquer cette information (i.e. la liste des ressources qui vont être utilisées par l’émetteur, et d’autres émetteurs s’il y en a) dans son propre message SA. Par exemple, l’information peut être associée à une durée de validité limitée dans le temps.
Quand vient le moment de la transmission de données souhaitée par l’émetteur initial, celui peut calculer un rapport entre le nombre de messages SA indiquant les ressources qu’il a lui-même réservées et le nombre total de messages SA reçus depuis la transmission test (incluant également les messages SA qui n’indiquent pas les ressources qu’il a réservées). L’émetteur initial peut décider de procéder à la transmission souhaitée en fonction du rapport calculé. Plus celui-ci est proche de 1, plus la probabilité que la transmission test ait été un succès pour l’ensemble des nœuds à portée est élevée.
Ainsi, chaque transmission sert de test pour la transmission suivante et les messages SA envoyés par les nœuds situés dans son voisinage et indiquant les 5 ressources réservées par l’émetteur initial permettent à celui-ci de savoir que la transmission test s’est bien passée au moins pour une certaine proportion des nœuds. En ce sens, ces messages SA constituent des acquittements (implicites) de la transmission test.
Ce mécanisme peut également s’appliquer aux cas de communications 10 unicast ou multicast où des ressources dédiées aux messages d’acquittement (SAA, ARM) ne sont pas disponibles dans la trame.
Dans un mode particulier de réalisation, le message SA signale également un indice de priorité associé à chaque transmission future et le rapport calculé prend en compte cet indice de priorité.
Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.
Claims (27)
- REVENDICATIONS1. Procédé de communication directe entre au moins deux terminaux d’un réseau mobile, sur un ensemble de blocs de ressources radio définies selon une ou plusieurs dimensions, organisé en trame (SC-Period), le procédé étant mis en œuvre par un terminal émetteur et comprenant les étapes suivantes :- transmission test (40), à au moins un terminal récepteur, d’au moins un message de signalisation (SA) fonction d’un premier sous-ensemble (DSP ; DCH) de blocs de ressources radio ; et- en fonction d’au moins un message d’acquittement (SAA ; ARM) reçu en réponse à la transmission test, transmission (44), audit au moins un terminal récepteur, de données sur ledit premier sous-ensemble de blocs.
- 2. Procédé selon la revendication 1, dans lequel la trame comprend une pluralité de configurations prédéfinies de blocs de ressources radio (DCH) et ledit premier sous-ensemble est une configuration prédéfinie de blocs de ressources radio.
- 3. Procédé selon la revendication 2, dans lequel ladite trame comprend au moins une partie contrôle (SP) et l’au moins un message de signalisation (SA) est transmis sur un bloc de ressources radio de ladite au moins une partie contrôle (SP) associé à la configuration prédéfinie correspondant au premier sous-ensemble de blocs, permettant ainsi l’identification du premier sous-ensemble de blocs.
- 4. Procédé selon la revendication 1 ou 2, dans lequel la transmission test comprend une transmission de données de test sur un second sous-ensemble (TDSP) de blocs de ressources radio représentatif du premier sous-ensemble de blocs de ressources radio.
- 5. Procédé selon l’une quelconque des revendications 1 à 4, dans lequel la transmission test est effectuée sur une première trame tandis que la transmission des données est effectuée sur une seconde trame comprenant ledit premier sous-ensemble (DSP ; DCH) de blocs de ressources radio, la seconde trame étant différente de la première trame.
- 6. Procédé selon l’une quelconque des revendications 1 à 5, dans lequel les blocs de ressources radio situés entre les blocs de ressources radio utilisés pour la transmission test et la réception du ou des messages d’acquittement sont réservés pour transmettre des données directes courtes (DSSL) et/ou transmettre ou recevoir d’autres messages d’acquittement (ACK/ACK-RSP) ou de demande d’acquittement (ACK-REQ).
- 7. Procédé selon l’une quelconque des revendications 1 à 6, dans lequel ladite trame comprend une pluralité de parties contrôle (SP).
- 8. Procédé selon la revendication 7, dans lequel la transmission test et la réception dudit au moins un message d’acquittement en réponse à la transmission test sont effectués sur une même partie contrôle (SP) de la trame.
- 9. Procédé selon l’une quelconque des revendications 1 à 8, dans lequel les blocs de ressources radio utilisés pour la transmission test sont également utilisés par le terminal émetteur pour ladite transmission de données, qu’elle soit étalée sur une ou plusieurs trames.
- 10. Procédé selon l’une quelconque des revendications 1 à 9, comprenant la réception d’un autre message d’acquittement (SAA) sur des parties contrôle (SP) prédéfinies de la trame, en réponse aux données transmises sur ledit premier sous-ensemble de blocs, ledit autre message d’acquittement (SAA) notifiant le terminal émetteur d’un changement d’un schéma de modulation et de codage (MCS) employé par ledit au moins un terminal récepteur et/ou acquittant les données reçues jusque-là.
- 11. Procédé selon l’une quelconque des revendications 1 à 10, comprenant la réception d’un message de réservation (SAA, ARM) d’un troisième sous-ensemble de blocs de ressources radio de la trame courante ou d’une trame future.
- 12. Procédé selon l’une quelconque des revendications 1 à 11, comprenant la transmission d’un autre message de signalisation (SA) audit au moins un terminal récepteur, indiquant au moins un bloc de ressources radio en cours d’utilisation sur la trame courante par le terminal émetteur.
- 13. Procédé selon l’une quelconque des revendications 1 à 12, comprenant la réception de mesures de qualité de connexion entre le terminal émetteur et chaque terminal récepteur d’une pluralité de terminaux récepteurs, le procédé comprenant en outre une étape de sélection d’au moins un terminal relai parmi les terminaux récepteurs de ladite pluralité en fonction des mesures de qualité, un identifiant dudit au moins un terminal relai étant indiqué dans un message d’en-tête transmis avec lesdites données sur ledit premier sous-ensemble de blocs.
- 14. Procédé selon l’une quelconque des revendications 1 à 13, comprenant la réception de mesures de qualité de la connexion entre les deux terminaux d’une pluralité de paires de terminaux, le procédé comprenant en outre une étape de calcul d’un graphe de diffusion multicast à partir des mesures de qualité reçues.
- 15. Procédé selon l’une quelconque des revendications 1 à 14, comprenant en outre les étapes suivantes :- réception d’un message de réservation d’un sous-ensemble de blocs de ressources radio envoyé par un terminal du réseau mobile à un autre terminal différent de l’émetteur ;- mesure de la qualité de réception dudit message de réservation (RLQIrx) ; et- en fonction du résultat de la comparaison de la qualité de réception mesurée avec une valeur seuil, réservation ou non dudit sous-ensemble de blocs de ressources radio.
- 16. Procédé selon la revendication 15, dans lequel ledit message de réservation indique un niveau de qualité de réception de messages (RLQIsig) par ledit terminal du réseau mobile.
- 17. Procédé selon la revendication 16, dans lequel ladite réservation dudit sous-ensemble de blocs de ressources radio est également fonction du résultat de la comparaison de la qualité de réception indiquée dans le message de réservation (RLQIsig) avec une valeur seuil.
- 18. Procédé selon la revendication 11, dans lequel ladite trame future est séparée de la trame courante par une durée prédéfinie fonction d’au moins un bloc de ressources radio dédié audit message de réservation et/ou signalée dans ledit message de réservation.
- 19. Procédé selon l’une quelconque des revendications 1 à 18, dans lequel au moins un premier bloc de ressources radio est dédié audit au moins un message de signalisation (SA) et au moins un second bloc de ressources radio est dédié audit au moins un message d’acquittement (SAA ; ARM), lesdits au moins un premier bloc et au moins un second bloc étant espacés d’une durée prédéfinie au moins égale au temps nécessaire au décodage dudit au moins un message d’acquittement (SAA ; ARM).
- 20. Procédé selon les revendications 11 et 19, dans lequel au moins un troisième bloc de ressources radio est dédié audit message de réservation (SAA ; ARM), lesdits au moins un premier bloc et au moins un troisième bloc étant espacés d’une durée prédéfinie au moins égale au temps nécessaire au décodage dudit message de réservation.
- 21. Procédé selon la revendication 11, dans lequel ledit troisième sousensemble de blocs de ressources radio réservé correspond audit premier sousensemble de blocs.
- 22. Procédé selon la revendication 1 ou 2, dans lequel ledit au moins un message de signalisation (SA) indique des informations de réservation, lesdites informations de réservation comprenant l’ensemble des ressources radio et identifiant au moins une trame future qu’au moins un terminal du réseau a réservé.
- 23. Procédé selon la revendication 22, dans lequel lesdites informations de réservation sont associées à une durée de validité limitée dans le temps débutant à l’émission dudit au moins un message de signalisation.
- 24. Procédé selon la revendication 1, 2, 22 ou 23, comprenant en outre les étapes suivantes :- calcul d’une probabilité de succès de la transmission test en fonction d’un nombre de messages de signalisation (SA) reçus d’autres terminaux du réseau mobile et indiquant ledit premier ensemble de blocs de ressources radio et d’un nombre total de messages de signalisation (SA) reçus d’autres terminaux du réseau mobile depuis la transmission test ; et- en fonction de la probabilité de succès calculée, transmission ou non desdites données sur ledit premier sous-ensemble de blocs.
- 25. Procédé selon la revendication 24, dans lequel ledit au moins un message de signalisation (SA) indique un indice de priorité associé à chaque transmission future et ladite étape de calcul prend en compte ledit indice de priorité.
- 26. Procédé selon l’une quelconque des revendications 1 à 25, dans lequel des blocs de ressources radio dédiés aux messages de signalisation (SA) et/ou d’acquittement (SAA ; ACK ; ARM) sont de taille réduite par rapport aux autres blocs de ressources radio de la trame ou ont des dimensions différentes par rapport aux autres blocs de ressources radio de la trame.
- 27. Dispositif de communication mettant en œuvre une méthode selon l’une quelconque des revendications 1 à 26 pour communiquer avec un autre dispositif de communication.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1754857A FR3067210B1 (fr) | 2017-06-01 | 2017-06-01 | Procede de communication directe entre terminaux |
| PCT/FR2018/050923 WO2018220301A1 (fr) | 2017-06-01 | 2018-04-12 | Procede de communication directe entre terminaux |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1754857A FR3067210B1 (fr) | 2017-06-01 | 2017-06-01 | Procede de communication directe entre terminaux |
| FR1754857 | 2017-06-01 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3067210A1 true FR3067210A1 (fr) | 2018-12-07 |
| FR3067210B1 FR3067210B1 (fr) | 2021-09-17 |
Family
ID=59746064
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1754857A Expired - Fee Related FR3067210B1 (fr) | 2017-06-01 | 2017-06-01 | Procede de communication directe entre terminaux |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3067210B1 (fr) |
| WO (1) | WO2018220301A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3644644B1 (fr) * | 2017-06-26 | 2023-03-22 | LG Electronics Inc. | Procédé permettant de mettre en oeuvre une communication v2x dans un système de communication sans fil et terminal utilisant ce procédé |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016163972A1 (fr) * | 2015-04-08 | 2016-10-13 | Intel Corporation | Mécanismes de signalisation de commande pour communication de dispositif à dispositif (d2d) améliorée |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3281489A1 (fr) * | 2015-04-08 | 2018-02-14 | Interdigital Patent Holdings, Inc. | Réalisation de relais mobiles pour communications de dispositif à dispositif (d2d) |
-
2017
- 2017-06-01 FR FR1754857A patent/FR3067210B1/fr not_active Expired - Fee Related
-
2018
- 2018-04-12 WO PCT/FR2018/050923 patent/WO2018220301A1/fr not_active Ceased
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016163972A1 (fr) * | 2015-04-08 | 2016-10-13 | Intel Corporation | Mécanismes de signalisation de commande pour communication de dispositif à dispositif (d2d) améliorée |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3067210B1 (fr) | 2021-09-17 |
| WO2018220301A1 (fr) | 2018-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3360384B1 (fr) | Methode et dispositif de communication sans fil entres des objets connectés et des passerelles | |
| US8594123B2 (en) | Method for detecting distributed peer to transmit multimedia data in wireless peer-to-peer network | |
| FR3044198A1 (fr) | Procede de configuration d’une passerelle | |
| EP2705723A1 (fr) | Procede d'etablissement d'une premiere et d'une deuxieme association decouplees | |
| CN102237978A (zh) | 一种协作链路的建立和维护方法及相关设备 | |
| EP2512201B1 (fr) | Station émettrice/réceptrice pour former un noeud d'un réseau de télécommunications et procédé de télécommunications associé | |
| Adam et al. | Medium access with adaptive relay selection in cooperative wireless networks | |
| EP2832169B1 (fr) | Routage de données dans un réseau de capteurs | |
| EP2786629B1 (fr) | Procédé de communication dans un réseau ad hoc, station émettrice/réceptrice et programme d'ordinateur associés | |
| FR3067210A1 (fr) | Procede de communication directe entre terminaux | |
| EP3329702B1 (fr) | Procede de decouverte d'un noeud d'un reseau ad hoc | |
| Liu et al. | A MAC-PHY cross-layer protocol for ad hoc wireless networks | |
| FR2892591A1 (fr) | Gestion des transferts intercellulaires dans les communications de groupe | |
| EP3646505B1 (fr) | Procédé de transmission de données et de retransmission harq | |
| EP2854467A1 (fr) | Système et procédé de partage de capacité distribué dans un réseau ad-hoc | |
| WO2021116572A1 (fr) | Procédé et dispositif mettant en œuvre ce procédé pour accéder à un canal partagé pour répondre à une requête de demande de relais | |
| EP2198661B1 (fr) | Procede de communication de donnees dans un reseau cellulaire cooperatif, dispositif, et produit programme d'ordinateur correspondants | |
| FR2993736A1 (fr) | Procede de communication aerien - terrestre, programme, terminaux, installation | |
| EP4142171B1 (fr) | Procede de transmission et dispositif noeud implementant ledit procede | |
| Alhajj | Impact of centralized-radio access network architecture on 5G performance | |
| EP3619990B1 (fr) | Procédé et système de distribution dans un réseau mixte point-à-multipoint et point-à-point (d2d) | |
| EP4142169B1 (fr) | Procédé de transmission et dispositif noeud implementant ledit procédé | |
| Feng et al. | Compatible QPP Scheduling for LTE D2D in Out-of-Coverage Public Safety Scenarios | |
| EP3563593B1 (fr) | Procede et systeme d'echanges de donnees | |
| FR3144462A1 (fr) | Procédé de communication et système OMAMRC avec une sélection lors de retransmissions tenant compte d’un unique échange conditionnel de CSI |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20181207 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| ST | Notification of lapse |
Effective date: 20240205 |