FR2941830A1 - Procede pour le transfert sequentiel d'une suite de donnees entre une unite emettrice et une unite receptrice - Google Patents

Procede pour le transfert sequentiel d'une suite de donnees entre une unite emettrice et une unite receptrice Download PDF

Info

Publication number
FR2941830A1
FR2941830A1 FR0900419A FR0900419A FR2941830A1 FR 2941830 A1 FR2941830 A1 FR 2941830A1 FR 0900419 A FR0900419 A FR 0900419A FR 0900419 A FR0900419 A FR 0900419A FR 2941830 A1 FR2941830 A1 FR 2941830A1
Authority
FR
France
Prior art keywords
data
frame
unit
received
transfer
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.)
Pending
Application number
FR0900419A
Other languages
English (en)
Inventor
Pierre Andre Genel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
IXEL
Original Assignee
IXEL
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by IXEL filed Critical IXEL
Priority to FR0900419A priority Critical patent/FR2941830A1/fr
Publication of FR2941830A1 publication Critical patent/FR2941830A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809Selective-repeat protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1671Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H04L1/1678Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/187Details of sliding window management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un procédé pour le transfert séquentiel d'une suite de données D à D entre une unité émettrice E et une unité réceptrice R, dans lequel : • le transfert des données D à D , avec m ≥ i > 0, s'effectue à la suite d'une requête de transfert Req, transmise à l'unité émettrice E par l'unité réceptrice R ; • le transfert d'une donnée D , avec m ≥ j > i, s'effectue à la suite de la réception de l'acquittement ACK - par l'unité émettrice E en provenance de l'unité réceptrice R, d'une donnée D _ ; antérieurement transférée à l'unité réceptrice R ; caractérisé en ce que la réception de l'acquittement ACK par l'unité émettrice E, d'une donnée transférée D , engendrant le transfert de la donnée D ainsi que le transfert de la donnée suivante D , dans le cas où le transfert de cette donnée suivante D n'a pas été déclenché par la réception par l'unité émettrice E de l'acquittement ACK du transfert de la donnée précédente D .

Description

10 La présente invention a pour objet un procédé permettant d'assurer le transfert séquentiel d'une suite de données entre une unité émettrice et une unité réceptrice. Elle s'applique notamment, mais non exclusivement, à un procédé permettant de transférer des données comprises dans un appareil - enregistreur, au travers d'un réseau, vers un serveur informatique, l'appareil - 15 enregistreur étant relié à un appareil de mesure de type compteur électrique.
D'une façon générale, on sait qu'il existe des compteurs dont les données enregistrées peuvent être relevées à distance, en utilisant notamment le réseau GSM ("Global System for Mobile communications"). 20 Généralement, les protocoles mis en oeuvre pour permettre la transmission des données enregistrées dans ces compteurs "télé û relevables" sont notamment : • des protocoles propriétaires tels que le protocole "Trimaran" d'EDF ("Électricité de France"), qui sont liés à des modems anciens tels que le 25 V23HD, ce qui se traduit par une transmission lente des données. En outre, les acquittements nécessaires à chaque échange de données pénalisent fortement les adaptations aux réseaux de type GSM data ; • des protocoles propriétaires ultérieurs tels que les protocoles "DLMS" ("Device Language Message Specification") et "Trimaran +", qui sont 30 liés à des modems tels que le V22bis, la transmission des données en 1 2941830 -2- mettant en oeuvre ces protocoles, bien que plus rapide que celle reposant sur les protocoles précédents, demeure lente ; • des protocoles génériques tels que le protocole "DLMS / COSEM" ("Companion Specification for Energy Metering") qui permettent de transmettre les données plus rapidement que dans les cas précédents néanmoins, ce type de protocoles nécessite la transmission d'une quantité importante de données en raison d'un codage réalisé quasi - exclusivement en ASCII.
L'invention a donc plus particulièrement pour but de supprimer ces inconvénients en proposant un procédé qui permet de transférer des données comprises dans un appareil - enregistreur, au travers d'un réseau, vers un serveur informatique, la mise en oeuvre de ce procédé permettant une transmission rapide des données même en circulant sur des réseaux à "allers ù retours" lents, tels que les réseaux du type GSM data.
À cet effet, l'invention propose un procédé pour le transfert séquentiel d'une suite de données Do à Dm entre une unité émettrice E et une unité réceptrice R, dans lequel : • le transfert des données Do à Di _ 1, avec m > i > 0. s'effectue à la suite d'une requête de transfert Req, transmise à l'unité émettrice E par l'unité réceptrice R, i étant une constante ; • le transfert d'une donnée avec m > j > i, s'effectue à la suite de la réception de l'acquittement ACKK _ i par l'unité émettrice E en provenance de l'unité réceptrice R, d'une donnée Di _ i antérieurement transférée à l'unité réceptrice R, j étant une variable ; caractérisé en ce que : • les données Do à Dm sont transmises de façon à ce que le délai de transfert normal de deux données successives Dnt et Dnt +1, avec m > nt 0, soit sensiblement égal à une période T ; 2941830 -3- • la réception de l'acquittement ACKK _ i par l'unité émettrice E, d'une donnée transférée Di _ i, engendrant le transfert de la donnée Di ainsi que le transfert de la donnée suivante Di + 1, dans le cas où le transfert de cette donnée suivante Di + n'a pas été déclenché par la réception par 5 l'unité émettrice E de l'acquittement ACKU _ j) + du transfert de la donnée précédente Da _ j) + 1.
Ainsi, à titre d'exemple, lorsque i = 2, la suite de données Do à Dm comprend deux séries de données entrelacées à savoir, une série de rang pair et une série 10 de rang impair. De cette façon, la réception d'un acquittement ACKK _ 2 par l'unité émettrice E, d'une donnée transférée Di _ 2 d'une série (par exemple de rang pair), engendrant le transfert de la donnée suivante Di de la même série, ainsi que le transfert de la donnée suivante Di + 1 de l'autre série (cette dernière étant dans ce cas, de rang impair) dans le cas où le transfert de cette donnée 15 suivante Di + 1 n'a pas été déclenché par la réception par l'unité émettrice E de l'acquittement ACKK du transfert de la donnée précédente Di de cette autre série.
De cette manière, la mise en oeuvre du procédé selon l'invention permet le 20 transfert d'au moins i données successives d'une suite de données Do à Dm sans attendre la réception de l'acquittement de ces i données successives, ce qui permet de ne pas être pénalisé par les délais relativement longs des échanges "allers ù retours" des réseaux du type GSM data. En outre, l'absence de réception d'un acquittement par l'unité émettrice E n'interrompt pas forcément 25 le transfert des données, la réception d'un acquittement pouvant permettre de commander le transfert de plusieurs données.
Avantageusement, le procédé selon l'invention peut comprendre une étape supplémentaire permettant de retransmettre des données dans l'hypothèse où 30 plusieurs acquittements consécutifs n'ont pas été reçus par l'unité émettrice E, au terme d'un délai prédéterminé.
Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence aux dessins annexés dans lesquels : La figure 1 est une représentation schématique des échanges des données et des acquittements correspondants entre une unité émettrice et une unité réceptrice.
La figure 2 est une représentation schématique des échanges des données et des acquittements correspondants entre une unité émettrice et une unité réceptrice, dans le cas où un acquittement n'est pas reçu par l'unité émettrice.
La figure 3 est une représentation schématique d'un organigramme d'étapes dont la mise en oeuvre permet l'initialisation de requêtes de transfert par l'unité réceptrice.
La figure 4 est une représentation schématique d'un organigramme d'étapes dont la mise en oeuvre permet la réception des données et l'envoi des acquittements correspondants par l'unité réceptrice.
La figure 5 est une représentation schématique d'un organigramme d'étapes dont la mise en oeuvre permet l'envoi des données par l'unité émettrice. La figure 6 est une représentation schématique de la structure et du format des trames échangées entre l'unité émettrice et l'unité réceptrice.
La figure 7 est une représentation schématique du champ fonction codé 30 sur un octet d'une trame émise par l'unité réceptrice en direction de l'unité émettrice.25 La figure 8 est une représentation schématique du champ fonction codé sur un octet d'une trame émise par l'unité émettrice en direction de l'unité réceptrice. La figure 9 est une représentation schématique du champ fonction codé sur deux octets d'une trame émise par l'unité réceptrice en direction de l'unité émettrice.
10 À titre d'exemple non limitatif, tel que cela est illustré sur les figures 1 et 2, la mise en oeuvre du procédé selon l'invention, qui permet le transfert séquentiel d'une suite de données Do à Dm entre une unité émettrice E et une unité réceptrice R, se traduit par : • l'émission d'une requête de transfert Req par l'unité réceptrice R à 15 l'unité émettrice E ; • le transfert des données Do à Di _ 1, avec m > i > 0, qui s'effectue à la suite de la réception de la requête de transfert Req par l'unité émettrice E ; en l'espèce, i, qui définit la dimension d'une fenêtre d'émission, est égal à 2 par conséquent, dans cet exemple, les données Do à D1 sont 20 transmises à la suite de la réception de la requête de transfert Req ; • le transfert d'une donnée avec m > j > i, qui s'effectue à la suite de la réception de l'acquittement ACKi _ i par l'unité émettrice E en provenance de l'unité réceptrice R, d'une donnée Di _ i antérieurement transférée à l'unité réceptrice R ; à titre d'exemple, si j est égal à 3, la 25 donnée D3 est transmise à la réception de l'acquittement ACK1 par l'unité émettrice E ; • la réception de l'acquittement ACKi _ i par l'unité émettrice E, d'une donnée transférée Di _ i, engendrant le transfert de la donnée Di ainsi que le transfert de la donnée suivante Di + 1, dans le cas où le transfert de 30 cette donnée suivante Di + 1 n'a pas été déclenché par la réception par l'unité émettrice E de l'acquittement ACKü _ i) + 1 du transfert de la 2941830 -6- donnée précédente Do _ j) + 1 ; ainsi, tel que cela est représenté sur la figure 2, en prenant j égal à 3, la réception de l'acquittement ACK1 par l'unité émettrice E, de la donnée transférée D1, engendre le transfert de la donnée D3 ainsi que le transfert de la donnée suivante D4 même si le 5 transfert de cette donnée suivante D4 n'a pas été déclenché par la réception par l'unité émettrice E de l'acquittement ACK2 du transfert de la donnée précédente D2.
A titre d'exemple, le processus d'initialisation de requêtes de transfert Req par l'unité réceptrice R est représenté schématiquement, sous forme d'organigramme, sur la figure 3. Ainsi, ce processus d'initialisation peut comprendre les étapes suivantes : • 1) la mise à o, à l'état inactif, des paramètres suivants : o "nrq" qui correspond au nombre de fois où une même requête de transfert Req est émise par l'unité réceptrice R ; o "nt" qui correspond au numéro de trame de chaque donnée de la suite de données Do à Dm à émettre ; o "tabort" qui est un compteur temps ; • 2) l'envoi par l'unité réceptrice R de la requête de transfert Req et le déclenchement du compteur temps "trep" qui était initialement à 0, le système passant d'un état inactif à un état d'initialisation de transaction ; • 3) la détermination du point de savoir si la durée définie par le compteur "trep" est supérieure à une constante "TR" qui correspond au délai au ù delà duquel l'émission de la requête de transfert Req est répétée ; • 4.a) si ce délai "TR" est dépassé sans qu'aucune réponse n'ait été reçue en retour par l'unité réceptrice R, le paramètre "nrq" est incrémenté d'une unité ; • 4.b) la détermination du point de savoir si la valeur du paramètre "nrq" est supérieure à une constante "NRP" qui correspond au nombre maximum possible de répétitions de l'émission de la requête de transfert Req en cas d'absence de réponse ; • 4.c.1) si la valeur du paramètre "nrq" est supérieure à la constante "NRP", la mise en oeuvre dudit processus d'initialisation est abandonnée; • 4.c.2) si la valeur du paramètre "nrq" n'est pas supérieure à la constante "NRP", le processus d'initialisation reprend à l'étape 2), la requête de transfert Req étant retransmise ; • 5) à la suite de l'étape 3), si le délai "TR" n'est pas dépassé, la détermination du point de savoir si la réponse reçue par l'unité réceptrice R consiste en une trame de numéro "nt", à savoir une trame de numéro 0 ; • 6) si cette réponse ne consiste pas une trame du type susdit, le processus d'initialisation reprend à l'étape 3) ; • 7) si cette réponse consiste en une trame du type susdit, la détermination du point de savoir s'il s'agit d'une trame de FIN ou NACK (non accusé de réception) ; • 8) si cette trame est une trame de FIN ou NACK, la constatation selon laquelle les données demandées ne sont pas disponibles ; • 9) si cette trame n'est pas une trame de FIN ou NACK, la détermination du point de savoir s'il s'agit d'une trame de données ; • 10) si cette trame n'est pas une trame de données, le processus d'initialisation reprend à l'étape 3) ; • 11) si cette trame est une trame de données, la constatation selon laquelle les données sont reçues.
Le processus de réception de données par l'unité réceptrice R qui suit le processus d'initialisation de requêtes de transfert Req est représenté schématiquement, sous forme d'organigramme, sur la figure 4. Ainsi, ce processus de réception de données peut comprendre les étapes suivantes : • 1) l'envoi de l'acquittement ACK "nt" par l'unité réceptrice R dans le cas où cette dernière a reçu la trame de données de numéro "nt" ; • 2) l'enregistrement de cette trame de données de numéro "nt" par l'unité réceptrice R, l'incrémentation de "nt", et la mise à zéro suivie de l'initialisation du compteur "tabort" ; • 3) la détermination du point de savoir si la trame de données de numéro "nt" ("nt" ayant été incrémenté à l'étape précédente) a été reçue par l'unité réceptrice R ; • 4.a) si cette trame de numéro "nt" n'a pas été reçue par l'unité réceptrice R, la détermination du point de savoir si la durée définie par la valeur du paramètre "tabort" est supérieure à la constante "TAB" qui correspond à la durée de temporisation maximale avant arrêt du processus dans le cas où la trame de données de numéro "nt" n'a pas été reçue ; • 4.b.1) si la valeur du paramètre "tabort" est supérieure à la constante "TAB", la mise en oeuvre dudit processus de réception des données est abandonnée; • 4.b.2) si la valeur du paramètre "tabort" n'est pas supérieure à la constante "TAB", le processus de réception des données reprend à l'étape 3) ; • 5) à la suite de l'étape 3), si cette trame de numéro "nt" a été reçue par l'unité réceptrice R, la détermination du point de savoir s'il s'agit d'une trame de données ; • 6) si cette trame est une trame de données, le processus d'initialisation reprend à l'étape 1) ; • 7) si cette trame n'est pas une trame de données, la détermination du point de savoir s'il s'agit d'une trame de FIN ; • 8) si cette trame n'est pas une trame de FIN, le processus de réception des données reprend à l'étape 3) ; • 9) si cette trame est une trame de FIN, l'envoi par l'unité réceptrice R à l'unité émettrice E de l'acquittement ACK "nt" ; • 10) à la suite de l'étape 9), le passage de l'unité réceptrice R en état de veille.
Le processus d'envoi des données par l'unité émettrice E est représenté 5 schématiquement, sous forme d'organigramme, sur la figure 5. Ainsi, ce processus d'envoi des données peut comprendre les étapes suivantes : • 1) la mise à 0, à l'état inactif, des paramètres suivants : o "nt" qui correspond au numéro de trame de chaque donnée de la suite de données Do à Dm à émettre ; 10 o "nta" qui correspond au numéro de la dernière trame acceptée par l'unité réceptrice R au moyen d'un acquittement ACK ; o "tabort" qui est un compteur temps ; o "trep" qui est un compteur temps ; • 2) la détermination du point de savoir si la requête de numéro "nt" a été 15 reçue par l'unité réceptrice R ; • 3.a) si cette requête de numéro "nt" n'a pas été reçue par l'unité réceptrice R, la détermination du point de savoir : o si la durée définie par la valeur du paramètre "tabort" est égale à la constante "TAB" qui correspond à la durée de temporisation 20 maximale avant arrêt du processus dans le cas où la requête de numéro "nt" n'a pas été reçue ; ou o si une trame FIN a été reçue ; • 3.b) si la valeur du paramètre "tabort" est égale à la constante "TAB" ou si une trame FIN a été reçue, la mise en oeuvre dudit processus d'envoi 25 des données est abandonnée ; • 3.c) si la valeur du paramètre "tabort" n'est pas égale à la constante "TAB" ou si une trame FIN n'a pas été reçue, le processus d'envoi des données reprend à l'étape 2) ; • 4) à la suite de l'étape 2), si ladite requête a été reçue, l'analyse de cette 30 dernière est effectuée, à cette étape, le système passe d'un état inactif à un état de transaction ; 2941830 - 10- • 5) la préparation de la page de numéro "nt" ; • 6) l'envoi de la trame "nt" par l'unité émettrice E ; • 7) la détermination du point de savoir si l'acquittement ACK de numéro "x" a été reçu par l'unité émettrice E ; • 8.a) si cet acquittement ACK de numéro "x" a été reçu par l'unité émettrice E, la détermination du point de savoir si : "nta" < "x" < "nt" ; • 8.b) si "x" ne satisfait pas à cette double inégalité, la mise en oeuvre dudit processus d'envoi des données est abandonnée ; • 8.c) si "x" satisfait à cette double inégalité : o la variable "nta" est affectée de la valeur "x", la dernière trame acceptée par l'unité réceptrice R étant celle de numéro "x" ; o les compteurs "tabort" et "trep" sont mis à zéro ; • 9) à la suite de l'étape 7), si l'acquittement ACK de numéro "x" n'a pas été reçu par l'unité émettrice E, ou à la suite de l'étape 8.c), la détermination du point de savoir : o si la durée définie par la valeur du paramètre "tabort" est supérieure à la constante "TAB" ; ou o si une trame FIN a été reçue ; • 10) si la valeur du paramètre "tabort" est supérieure à la constante "TAB" ou si une trame FIN a été reçue, la mise en oeuvre dudit processus d'envoi des données est abandonnée ; • 11) si la valeur du paramètre "tabort" n'est pas supérieure à la constante "TAB" ou si une trame FIN n'a pas été reçue, la détermination du point de savoir si la page de numéro "nt" est la dernière page ; • 12.a) s'il s'agit de la dernière page, la détermination du point de savoir si "nt" = "nta" • 12.b) si "nt" = "nta", le processus d'envoi des données reprend à l'étape 1); • 13.a) à la suite de l'étape 1l, s'il ne s'agit pas de la dernière page, la détermination du point de savoir si "nt" ≠ "nta" + "i", "i" étant la dimension de la fenêtre d'émission ; 2941830 -11- • 13.b) si "nt" ≠ "nta" + "i", "nt" est incrémenté et le processus de réception des données reprend à l'étape 5) ; • 14) à la suite de l'étape 12.a) si "nt" ≠ "nta" ou à la suite de l'étape 13.b) si "nt" = "nta" + "i", la détermination du point de savoir si la durée 5 définie par le compteur "trep" est supérieure à une constante "TRP" qui correspond au délai au ù delà duquel l'émission de la dernière trame non acquittée est répétée ; • 15) si la durée définie par le compteur "trep" n'est pas supérieure à la constante "TRP", le processus d'envoi des données reprend à l'étape 7) ; 10 • 16) si la durée définie par le compteur "trep" est supérieure à la constante "TRP" : o "nt" est affectée de la valeur "nta" ; o "trep" est mis à zéro ; • 17) à la suite de l'étape 16, la variable "nt" est incrémentée ; 15 • 18) le processus d'envoi des données reprend à l'étape 5).
L'unité émettrice E et l'unité réceptrice R peuvent chacune comprendre notamment mais non exclusivement : • une unité centrale de traitement (UCT ù non représentée) qui permet 20 notamment de procéder aux traitements nécessaires à l'exécution desdites étapes ; • des moyens de mémoire (non représentés) tels que de la mémoire permanente (ROM) et/ou volatile (RAM) permettant notamment d'enregistrer les données reçues ou à émettre ; 25 • un moyen de gestion (non représenté) de transfert des données.
Tel que cela est représenté sur la figure 6, une trame 1 échangée entre une unité émettrice E et une unité réceptrice R peut comprendre : • un champ "L" qui indique le nombre total d'octets de la trame, le 30 codage de cette longueur s'effectuant préférentiellement sur un octet ; • un champ "Fonction" ; 2941830 - 12 - • au moins un champ "Data" qui comprend les données à transférer ; • au moins un champ "CRC" ("Cyclic redundancy check" - "CRC h", "CRC 1") qui correspond à un contrôle de redondance cyclique.
5 Tel que cela est représenté sur la figure 7, dans le cas d'une trame émise par l'unité réceptrice R en direction de l'unité émettrice E, le champ "Fonction" peut être codé sur un seul octet et peut correspondre : • à un acquittement ACK : o les quatre premiers bits pouvant correspondre au numéro de la 10 dernière trame de la fenêtre ; o les quatre bits suivants pouvant eux équivaloir à "0 0 0 0" ; ou • à un non ù acquittement NACK : o les quatre premiers bits pouvant correspondre au numéro de la dernière trame de la fenêtre ; 15 o les quatre bits suivants pouvant eux équivaloir à "1 1 1 1" ; ou • à une fin de session "FIN SESSION".
Tel que cela est représenté sur la figure 8, dans le cas d'une trame émise par l'unité émettrice E en direction de l'unité réceptrice R, le champ "Fonction" 20 peut être codé sur un seul octet et peut correspondre : • à l'indication ("FIN DATA") selon laquelle les données ont été toutes transmises ; ou • à l'indication ("DATA") selon laquelle la trame comprend des données.
25 Selon une variante d'exécution de l'invention, tel que cela est représenté sur la figure 9, dans le cas d'une trame émise par l'unité réceptrice R en direction de l'unité émettrice E, le champ "Fonction" peut être codé sur deux octets et peut permettre d'indiquer la date ou plus précisément la périodicité à laquelle les données seront transférées de l'unité émettrice E vers l'unité réceptrice R, ce 30 qui est particulièrement avantageux lorsque l'unité émettrice E est un appareil 2941830 - 13 - de mesure de type compteur électrique et l'unité réceptrice R un serveur informatique. A titre d'exemple non limitatif, le codage peut s'effectuer de la manière 5 suivante : • les cinq premiers bits de l'octet de poids faible peuvent correspondre au jour ; • le sixième bit de cet octet de poids faible est mis par défaut à zéro ; • les deux derniers bits de cet octet de poids faible peuvent correspondre 10 à l'intervalle (en minutes) de mémorisation des données ; dans ce cas, à titre d'exemple : o "0 0" peut correspondre à une minute ; o "0 1" peut correspondre à cinq minutes ; o "1 0" peut correspondre à dix minutes ; 15 o "1 1" peut correspondre à trente minutes ; • les quatre premiers bits de l'octet de poids fort peuvent correspondre au mois ; • le cinquième bit de l'octet de poids fort correspond à la valeur "Z" qui est une variable permettant d'augmenter les possibilités de codage ; 20 • les trois derniers bits de cet octet de poids fort sont mis par défaut à zéro.

Claims (18)

  1. Revendications1. Procédé pour le transfert séquentiel d'une suite de données Do à Dm entre une unité émettrice E et une unité réceptrice R, dans lequel : • le transfert des données Do à D, _ 1, avec m > i > 0, s'effectue à la suite d'une requête de transfert Req, transmise à l'unité émettrice E par l'unité réceptrice R ; • le transfert d'une donnée avec m > j > i, s'effectue à la suite de la réception de l'acquittement ACKi _ ; par l'unité émettrice E en provenance de l'unité réceptrice R, d'une donnée Di _ ; antérieurement transférée à l'unité réceptrice R ; caractérisé en ce que : • les données Do à Dm sont transmises de façon à ce que le délai de transfert normal de deux données successives Dm et Dm +1, avec m > n > 0, soit sensiblement égal à une période T ; • la réception de l'acquittement ACKK _ ; par l'unité émettrice E, d'une donnée transférée Di _;, engendrant le transfert de la donnée Di ainsi que le transfert de la donnée suivante Di + 1, dans le cas où le transfert de cette donnée suivante Di + 1 n'a pas été déclenché par la réception par l'unité émettrice E de l'acquittement ACKa _ j) + du transfert de la donnée précédente Dü _ j) +1.
  2. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une étape supplémentaire permettant de retransmettre des données dans l'hypothèse où plusieurs acquittements consécutifs n'ont pas été reçus par l'unité émettrice E, au terme d'un délai prédéterminé.
  3. 3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que le processus d'initialisation de requêtes de transfert Req par l'unité réceptrice R comprend les étapes suivantes : 2941830 -15- • 1) la mise à o. à l'état inactif, des paramètres suivants : o "nrq" qui correspond au nombre de fois où une même requête de transfert Req est émise par l'unité réceptrice R ; o "nt" qui correspond au numéro de trame de chaque donnée de la 5 suite de données Do à Dm à émettre ; o "tabort" qui est un compteur temps ; • 2) l'envoi par l'unité réceptrice R de la requête de transfert Req et le déclenchement du compteur temps "trep" qui était initialement à 0, le système passant d'un état inactif à un état d'initialisation de transaction ; 10 • 3) la détermination du point de savoir si la durée définie par le compteur "trep" est supérieure à une constante "TR" qui correspond au délai au û delà duquel l'émission de la requête de transfert Req est répétée ; •
  4. 4.a) si ce délai "TR" est dépassé sans qu'aucune réponse n'ait été reçue 15 en retour par l'unité réceptrice R, le paramètre "nrq" est incrémenté d'une unité ; • 4.b) la détermination du point de savoir si la valeur du paramètre "nrq" est supérieure à une constante "NRP" qui correspond au nombre maximum possible de répétitions de l'émission de la requête de transfert 20 Req en cas d'absence de réponse ; • 4.c.1) si la valeur du paramètre "nrq" est supérieure à la constante "NRP", la mise en oeuvre dudit processus d'initialisation est abandonnée; • 4.c.2) si la valeur du paramètre "nrq" n'est pas supérieure à la constante 25 "NRP", le processus d'initialisation reprend à l'étape 2), la requête de transfert Req étant retransmise ; •
  5. 5) à la suite de l'étape 3), si le délai "TR" n'est pas dépassé, la détermination du point de savoir si la réponse reçue par l'unité réceptrice R consiste en une trame de numéro "nt", à savoir une trame 30 de numéro 0 ; 2941830 - 16- •
  6. 6) si cette réponse ne consiste pas une trame du type susdit, le processus d'initialisation reprend à l'étape 3) ; •
  7. 7) si cette réponse consiste en une trame du type susdit, la détermination du point de savoir s'il s'agit d'une trame de FIN ou 5 NACK (non accusé de réception) ; •
  8. 8) si cette trame est une trame de FIN ou NACK, la constatation selon laquelle les données demandées ne sont pas disponibles ; •
  9. 9) si cette trame n'est pas une trame de FIN ou NACK, la détermination du point de savoir s'il s'agit d'une trame de données ; 10 •
  10. 10) si cette trame n'est pas une trame de données, le processus d'initialisation reprend à l'étape 3) ; •
  11. 11) si cette trame est une trame de données, la constatation selon laquelle les données sont reçues. 15 4. Procédé selon la revendication 3, caractérisé en ce que le processus de réception de données par l'unité réceptrice R, qui suit le processus d'initialisation de requêtes de transfert Req, comprend les étapes suivantes : • 1) l'envoi de l'acquittement ACK "nt" par l'unité réceptrice R dans le 20 cas où cette dernière a reçu la trame de données de numéro "nt" ; • 2) l'enregistrement de cette trame de données de numéro "nt" par l'unité réceptrice R, l'incrémentation de "nt", et la mise à zéro suivie de l'initialisation du compteur "tabort" ; • 3) la détermination du point de savoir si la trame de données de numéro 25 "nt" ("nt" ayant été incrémenté à l'étape précédente) a été reçue par l'unité réceptrice R ; • 4.a) si cette trame de numéro "nt" n'a pas été reçue par l'unité réceptrice R, la détermination du point de savoir si la durée définie par la valeur du paramètre "tabort" est supérieure à la constante "TAB" qui 30 correspond à la durée de temporisation maximale avant arrêt du 2941830 -17- processus dans le cas où la trame de données de numéro "nt" n'a pas été reçue ; • 4.b.1) si la valeur du paramètre "tabort" est supérieure à la constante "TAB", la mise en oeuvre dudit processus de réception des données est 5 abandonnée; • 4.b.2) si la valeur du paramètre "tabort" n'est pas supérieure à la constante "TAB", le processus de réception des données reprend à l'étape 3) ; • 5) à la suite de l'étape 3), si cette trame de numéro "nt" a été reçue par 10 l'unité réceptrice R, la détermination du point de savoir s'il s'agit d'une trame de données ; • 6) si cette trame est une trame de données, le processus d'initialisation reprend à l'étape 1) ; • 7) si cette trame n'est pas une trame de données, la détermination du 15 point de savoir s'il s'agit d'une trame de FIN ; • 8) si cette trame n'est pas une trame de FIN, le processus de réception des données reprend à l'étape 3) ; • 9) si cette trame est une trame de FIN, l'envoi par l'unité réceptrice R à l'unité émettrice E de l'acquittement ACK "nt" ; 20 • 10) à la suite de l'étape 9), le passage de l'unité réceptrice R en état de veille. 5. Procédé selon l'une des revendications 3 et 4, caractérisé en ce que le processus d'envoi des données par l'unité émettrice E 25 comprend les étapes suivantes : • 1) la mise à 0, à l'état inactif, des paramètres suivants : o "nt" qui correspond au numéro de trame de chaque donnée de la suite de données Do à Dm à émettre ; o "nta" qui correspond au numéro de la dernière trame acceptée 30 par l'unité réceptrice R au moyen d'un acquittement ACK ; o "tabort" qui est un compteur temps ; 2941830 -18- o "trep" qui est un compteur temps ; • 2) la détermination du point de savoir si la requête de numéro "nt" a été reçue par l'unité réceptrice R ; • 3.a) si cette requête de numéro "nt" n'a pas été reçue par l'unité 5 réceptrice R, la détermination du point de savoir : o si la durée définie par la valeur du paramètre "tabort" est égale à la constante "TAB" qui correspond à la durée de temporisation maximale avant arrêt du processus dans le cas où la requête de numéro "nt" n'a pas été reçue ; ou 10 o si une trame FIN a été reçue ; • 3.b) si la valeur du paramètre "tabort" est égale à la constante "TAB" ou si une trame FIN a été reçue, la mise en oeuvre dudit processus d'envoi des données est abandonnée ; • 3.c) si la valeur du paramètre "tabort" n'est pas égale à la constante 15 "TAB" ou si une trame FIN n'a pas été reçue, le processus d'envoi des données reprend à l'étape 2) ; • 4) à la suite de l'étape 2), si ladite requête a été reçue, l'analyse de cette dernière est effectuée, à cette étape, le système passe d'un état inactif à un état de transaction ; 20 • 5) la préparation de la page de numéro "nt" ; • 6) l'envoi de la trame "nt" par l'unité émettrice E ; • 7) la détermination du point de savoir si l'acquittement ACK de numéro "x" a été reçu par l'unité émettrice E ; • 8.a) si cet acquittement ACK de numéro "x" a été reçu par l'unité 25 émettrice E, la détermination du point de savoir si : "nta" < "x" < "nt" ; • 8.b) si "x" ne satisfait pas à cette double inégalité, la mise en oeuvre dudit processus d'envoi des données est abandonnée ; • 8.c) si "x" satisfait à cette double inégalité : o la variable "nta" est affectée de la valeur "x", la dernière trame 30 acceptée par l'unité réceptrice R étant celle de numéro "x" ; o les compteurs "tabort" et "trep" sont mis à zéro ; 2941830 - 19- • 9) à la suite de l'étape 7), si l'acquittement ACK de numéro "x" n'a pas été reçu par l'unité émettrice E, ou à la suite de l'étape 8.c), la détermination du point de savoir : o si la durée définie par la valeur du paramètre "tabort" est 5 supérieure à la constante "TAB" ; ou o si une trame FIN a été reçue ; • 10) si la valeur du paramètre "tabort" est supérieure à la constante "TAB" ou si une trame FIN a été reçue, la mise en oeuvre dudit processus d'envoi des données est abandonnée ; 10 • 11) si la valeur du paramètre "tabort" n'est pas supérieure à la constante "TAB" ou si une trame FIN n'a pas été reçue, la détermination du point de savoir si la page de numéro "nt" est la dernière page ; •
  12. 12.a) s'il s'agit de la dernière page, la détermination du point de savoir si "nt" = "nta" 15 • 12.b) si "nt" = "nta", le processus d'envoi des données reprend à l'étape 1); •
  13. 13.a) à la suite de l'étape 11, s'il ne s'agit pas de la dernière page, la détermination du point de savoir si "nt" ≠ "nta" + "i", "i" étant la dimension de la fenêtre d'émission ; 20 • 13.b) si "nt" ≠ "nta" + "i", "nt" est incrémenté et le processus de réception des données reprend à l'étape 5) ; •
  14. 14) à la suite de l'étape 12.a) si "nt" ≠ "nta" ou à la suite de l'étape 13.b) si "nt" = "nta" + "i", la détermination du point de savoir si la durée définie par le compteur "trep" est supérieure à une constante "TRP" qui 25 correspond au délai au ù delà duquel l'émission de la dernière trame non acquittée est répétée ; •
  15. 15) si la durée définie par le compteur "trep" n'est pas supérieure à la constante "TRP", le processus d'envoi des données reprend à l'étape 7) ; •
  16. 16) si la durée définie par le compteur "trep" est supérieure à la 30 constante "TRP" : o "nt" est affectée de la valeur "nta" ; 2941830 - 20 - o "trep" est mis à zéro ; •
  17. 17) à la suite de l'étape 16, la variable "nt" est incrémentée ; •
  18. 18) le processus d'envoi des données reprend à l'étape 5). 5 6. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une trame (1) échangée entre une unité émettrice E et une unité réceptrice R comprend : • un champ "L" qui indique le nombre total d'octets de la trame ; • un champ "Fonction" ; 10 • au moins un champ "Data" qui comprend les données à transférer ; • au moins un champ "CRC" qui correspond à un contrôle de redondance cyclique. 7. Procédé selon la revendication 6, 15 caractérisé en ce que dans le cas d'une trame émise par l'unité réceptrice R en direction de l'unité émettrice E, le champ "Fonction" est codé sur un seul octet et correspond : • à un acquittement ACK ; ou • à un non ù acquittement NACK ; ou 20 • à une fin de session "FIN SESSION". 8. Procédé selon l'une des revendications 6 et 7, caractérisé en ce que dans le cas d'une trame émise par l'unité émettrice E en direction de l'unité réceptrice R, le champ "Fonction" est codé sur un seul octet 25 et correspond : • à l'indication ("FIN DATA") selon laquelle les données ont été toutes transmises ; ou • à l'indication ("DATA") selon laquelle la trame comprend des données. 30 2941830 - 21 - 9. Procédé selon la revendication 6, caractérisé en ce que dans le cas d'une trame émise par l'unité réceptrice R en direction de l'unité émettrice E, le champ "Fonction" est codé sur deux octets afin d'indiquer la date ou plus précisément la périodicité à laquelle les données 5 seront transférées de l'unité émettrice E vers l'unité réceptrice R. 10. Procédé selon la revendication 9, caractérisé en ce que le codage s'effectue de la manière suivante : • les cinq premiers bits de l'octet de poids faible correspondent au jour ; 10 • le sixième bit de cet octet de poids faible est mis par défaut à zéro ; • les deux derniers bits de cet octet de poids faible correspondent à l'intervalle (en minutes) de mémorisation des données ; • les quatre premiers bits de l'octet de poids fort correspondent au mois ; • le cinquième bit de l'octet de poids fort correspond à la valeur "Z" qui 15 est une variable permettant d'augmenter les possibilités de codage ; • les trois derniers bits de cet octet de poids fort sont mis par défaut à zéro. 11. Dispositif pour la mise en oeuvre du procédé selon la revendication 20 1, caractérisé en ce que l'unité émettrice E et l'unité réceptrice R comprennent chacune: • une unité centrale de traitement (UCT) ; • des moyens de mémoire tels que de la mémoire permanente (ROM) 25 et/ou volatile (RAM) ; • un moyen de gestion de transfert des données.
FR0900419A 2009-01-30 2009-01-30 Procede pour le transfert sequentiel d'une suite de donnees entre une unite emettrice et une unite receptrice Pending FR2941830A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0900419A FR2941830A1 (fr) 2009-01-30 2009-01-30 Procede pour le transfert sequentiel d'une suite de donnees entre une unite emettrice et une unite receptrice

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0900419A FR2941830A1 (fr) 2009-01-30 2009-01-30 Procede pour le transfert sequentiel d'une suite de donnees entre une unite emettrice et une unite receptrice

Publications (1)

Publication Number Publication Date
FR2941830A1 true FR2941830A1 (fr) 2010-08-06

Family

ID=41226016

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0900419A Pending FR2941830A1 (fr) 2009-01-30 2009-01-30 Procede pour le transfert sequentiel d'une suite de donnees entre une unite emettrice et une unite receptrice

Country Status (1)

Country Link
FR (1) FR2941830A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1463228A2 (fr) * 2003-03-25 2004-09-29 NTT DoCoMo, Inc. Dispositif de communication, procédé de contrôle de transmission, et programme informatique pour contrôler la retransmission de données
US7099273B2 (en) * 2001-04-12 2006-08-29 Bytemobile, Inc. Data transport acceleration and management within a network communication system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7099273B2 (en) * 2001-04-12 2006-08-29 Bytemobile, Inc. Data transport acceleration and management within a network communication system
EP1463228A2 (fr) * 2003-03-25 2004-09-29 NTT DoCoMo, Inc. Dispositif de communication, procédé de contrôle de transmission, et programme informatique pour contrôler la retransmission de données

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TANNENBAUM A S ED - TANENBAUM A S: "COMPUTER NETWORKS", 1 January 1996, COMPUTER NETWORKS, LONDON : PRENTICE-HALL INTERNATIONAL; GB, PAGE(S) 202 - 219, ISBN: 9780133942484, XP002155806 *

Similar Documents

Publication Publication Date Title
EP1217778B1 (fr) Procédé et dispositif de communication de données avec demande de répétition automatique
EP0239453B1 (fr) Procédé et dispositif de transmission de données numériques par messages organisés en trames
AU2005203662B2 (en) Reliable messaging using clocks with synchronized rates
US9438653B2 (en) Method for providing an adaptive streaming service
FR2906428A1 (fr) Procede, dispositif et application logicielle pour la transmission de paquets de donnees dands un systeme de communication.
FR2927749A1 (fr) Procede et dispositif de transmission de donnees, notamment video.
KR20160135200A (ko) 확장된 송신 제어 기능을 구현하는 송신 가속기
US8341272B2 (en) Method for improving a TCP data transmission in case the physical transmission medium is disconnected
WO2008075600A1 (fr) Système de réseau de communications mobiles, et dispositif serveur
US20180109455A1 (en) Congestion management and latency prediction in csma media
CN108173851B (zh) 一种用于空间信息网络的高效多媒体传输方法
EP3637845A1 (fr) Procédé de communication basé sur un protocole de transmission par trames
FR2946164A1 (fr) Procede de telechargement de donnees de grande taille vers un grand nombre de machines clientes en reseau a partir d&#39;un serveur unique
FR2941830A1 (fr) Procede pour le transfert sequentiel d&#39;une suite de donnees entre une unite emettrice et une unite receptrice
EP1161023A1 (fr) Procédé et système de transmission de données bi-mode, émetteur et récepteur correspondants
FR3095568A1 (fr) Procédé de relevé de compteurS A fluides
EP1745603B8 (fr) Procede et dispositif d&#39;emission de paquets de donnees
EP2122895B1 (fr) Procede de retransmission a redondance incrementale pour des paquets fragmentes
FR2585909A1 (fr) Procede de transmission de donnees par paquets a travers un reseau ou une chaine de transmission, et dispositif de mise en oeuvre
EP1411689A1 (fr) Procédé de contrôle de retransmission de données et unité de contrôle pour mettre en oeuvre le procédé
WO2023169938A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par un nœud intermédiaire appartenant audit chemin
EP1199832B1 (fr) Procédé de transmission sécurisé évitant les retransmission inutiles
EP1649666A2 (fr) Procede pour evaluer la bande passante disponible d&#39;un canal de transmission lors d&#39;une transmission de donnees et dispositif d&#39;emission pour la mise en oeuvre du procede
FR2988947A1 (fr) Procede d&#39;optimisation du debit descendant d&#39;une ligne d&#39;acces asymetrique, dispositif, produit programme d&#39;ordinateur et support de stockage correspondants
FR2925806A1 (fr) Procede de transmission de donnees et dispositif correspondant