Pile de protocoles UniPro

Dans la technologie de téléphonie mobile, la pile de protocoles UniPro suit l'architecture du modèle de référence OSI classique . Dans UniPro , la couche physique OSI est divisée en deux sous-couches : la couche 1 (la couche physique proprement dite) et la couche 1.5 (la couche d'adaptateur PHY) qui fait abstraction des différences entre les technologies de couche 1 alternatives. La couche physique proprement dite est une spécification distincte car les différentes options PHY sont réutilisées dans d'autres spécifications de l'Alliance MIPI .

La spécification UniPro elle-même couvre les couches 1.5, 2, 3, 4 et le DME (Device Management Entity). La couche d'application (LA) n'est pas couverte car différentes utilisations d'UniPro nécessiteront des protocoles LA différents. La couche physique (L1) est couverte par des spécifications MIPI distinctes afin de permettre à la PHY d'être réutilisée par d'autres protocoles (moins génériques) si nécessaire.

Les couches OSI 5 (Session) et 6 (Présentation) sont, le cas échéant, comptées comme faisant partie de la couche Application.

Les versions 1.0 et 1.1 d'UniPro utilisent la technologie D-PHY de MIPI pour la couche physique hors puce. Cette couche physique permet la communication entre puces. Les débits de données de la couche D-PHY sont variables, mais se situent dans la plage de 500 à 1 000 Mbit/s (des vitesses inférieures sont prises en charge, mais avec une efficacité énergétique réduite). La couche D-PHY doit son nom au nombre romain pour 500 (« D »).

Le D-PHY utilise une signalisation différentielle pour transmettre les symboles PHY via un câblage micro-stripline. Une seconde paire de signaux différentiels est utilisée pour transmettre le signal d'horloge associé de la source à la destination. La technologie D-PHY utilise donc un total de 2 fils d'horloge par direction plus 2 fils de signal par voie et par direction. Par exemple, un D-PHY peut utiliser 2 fils pour l'horloge et 4 fils (2 voies) pour les données dans le sens direct, mais 2 fils pour l'horloge et 6 fils (3 voies) pour les données dans le sens inverse. Le trafic de données dans les sens direct et inverse est totalement indépendant à ce niveau de la pile de protocoles.

Dans UniPro, le D-PHY est utilisé dans un mode (appelé codage « 8b9b ») qui transmet des octets de 8 bits sous forme de symboles de 9 bits. Le protocole UniPro l'utilise pour représenter des symboles de contrôle spéciaux (en dehors des valeurs habituelles de 0 à 255). Le PHY lui-même l'utilise pour représenter certains symboles spéciaux qui ont une signification pour le PHY lui-même (par exemple les symboles IDLE). Notez que le rapport 8:9 peut entraîner une certaine confusion lors de la spécification du débit de données du D-PHY : une implémentation PHY fonctionnant avec une fréquence d'horloge de 450 MHz est souvent classée comme un PHY de 900 Mbit/s, alors que seulement 800 Mbit/s sont alors disponibles pour la pile UniPro.

Le D-PHY prend également en charge un mode de transmission de données à faible consommation d'énergie (LPDT) et divers autres modes à faible consommation d'énergie à utiliser lorsqu'aucune donnée ne doit être envoyée.

Les versions 1.4 et suivantes d'UniPro prennent en charge à la fois les technologies D-PHY et M-PHY . La technologie M-PHY est encore à l'état de projet, mais elle prend en charge des débits de données à haut débit à partir d'environ 1 000 Mbit/s (le M-PHY doit son nom au nombre romain pour 1 000). En plus de vitesses plus élevées, le M-PHY utilisera moins de fils de signal car le signal d'horloge est intégré aux données grâce à l'utilisation du codage 8b10b standard de l'industrie . Là encore, un PHY capable de transmettre des données utilisateur à 1 000 Mbit/s est généralement spécifié comme étant en mode 1 250 Mbit/s en raison du codage 8b10b.

Les technologies D-PHY et M-PHY devraient coexister pendant plusieurs années. La technologie D-PHY est moins complexe, la technologie M-PHY offre des bandes passantes plus élevées avec moins de câbles de signal et la technologie C-PHY offre une faible consommation d'énergie.

Il convient de noter qu'UniPro prend en charge les modes de communication à faible vitesse et à faible consommation d'énergie fournis par les technologies D-PHY (10 Mbit/s) et M-PHY (3 Mbit/s jusqu'à 500 Mbit/s). Dans ces modes, la consommation d'énergie est proportionnelle à la quantité de données envoyées. De plus, les deux technologies PHY offrent des modes d'économie d'énergie supplémentaires car elles ont été optimisées pour une utilisation dans des appareils alimentés par batterie.

D'un point de vue architectural, la couche d'adaptateur PHY sert à masquer les différences entre les différentes options PHY (D- et M-PHY). Cette abstraction offre donc principalement une flexibilité architecturale. Les détails PHY abstraits incluent les différents états d'alimentation et les schémas de codage de symboles utilisés.

L1.5 possède donc son propre codage de symboles (conceptuel) composé de symboles de 17 bits. Ces symboles de 17 bits n'apparaissent jamais sur les câbles, car ils sont d'abord convertis par L1.5 en une paire de symboles PHY. Le 17e bit de contrôle supplémentaire indique des symboles de contrôle spéciaux qui sont utilisés par le protocole (L1.5 et L2) lui-même. Dans les figures, les bits de contrôle sont représentés en « L1.5 rouge » pour rappeler qu'ils sont définis et utilisés par la couche de protocole 1.5.

La principale caractéristique offerte aux utilisateurs par L1.5 est de permettre d'augmenter la bande passante d'une liaison UniPro en utilisant 2, 3 ou 4 voies lorsqu'une seule voie ne fournit pas suffisamment de bande passante. Pour l'utilisateur, une telle liaison à plusieurs voies ressemble simplement à une couche physique plus rapide car les symboles sont envoyés sur 2, 3 ou 4 voies. Les applications qui nécessitent une bande passante plus élevée dans une direction mais moins dans la direction opposée peuvent avoir un nombre différent de voies par direction.

À partir de la version 1.4 d'UniPro, L1.5 détecte automatiquement le nombre de voies M-PHY utilisables pour chaque direction de la liaison. Cela implique un protocole de découverte simple au sein de L1.5 qui est exécuté lors de l'initialisation. Le protocole transmet des données de test sur chaque voie sortante disponible et reçoit des informations en retour de l'entité homologue sur les données sur quelle voie ont réellement atteint l'autre extrémité de la liaison. Le mécanisme prend également en charge le remappage transparent des voies pour offrir aux concepteurs de circuits imprimés une certaine flexibilité dans la manière dont les voies sont physiquement câblées.

Depuis UniPro v1.4, L1.5 dispose d'un protocole intégré appelé PACP (PA Control Protocol) qui permet à L1.5 de communiquer avec son entité homologue L1.5 à l'autre extrémité d'une liaison basée sur M-PHY. Son utilisation principale est de fournir un moyen simple et fiable pour un contrôleur situé à une extrémité de la liaison de modifier les modes d'alimentation des directions avant et arrière de la liaison. Cela signifie qu'un contrôleur situé à une extrémité de la liaison peut modifier le mode d'alimentation des deux directions de la liaison en une seule opération atomique. Les étapes complexes requises pour effectuer cette opération de manière totalement fiable sont gérées de manière transparente dans L1.5.

En plus de la gestion de l'alimentation de la liaison L1.5, le PACP est également utilisé pour accéder aux paramètres de contrôle et d'état du périphérique UniPro homologue.

Les mécanismes de L1.5 garantissent les éléments suivants aux protocoles de couche supérieure :

• après la réinitialisation, chaque émetteur L1.5 attendra que le récepteur L1.5 connecté soit reconnu comme actif (géré via une poignée de main)
• si plusieurs voies sont utilisées, l'ordre du flux de symboles d'origine est préservé (malgré l'utilisation de plusieurs voies et la liberté d'interconnecter ces voies)
• les changements de mode d'alimentation sont exécutés de manière fiable (même en présence d'erreurs de bits)

La tâche principale de la couche de liaison de données (L2) d'UniPro est de permettre une communication fiable entre deux nœuds adjacents du réseau - malgré des erreurs binaires occasionnelles au niveau de la couche physique ou une congestion potentielle de la liaison si le récepteur ne peut pas absorber les données suffisamment rapidement.

L2 regroupe les symboles UniPro L1.5 17 bits dans des trames de données de type paquet (le terme paquet est réservé à L3). Ces trames de données commencent par un symbole de contrôle de début de trame de 17 bits, suivi d'un maximum de 288 octets de données (144 symboles de données) et suivi d'un symbole de contrôle de fin de trame et d'une somme de contrôle.

Notez que deux ou plusieurs des 288 octets sont utilisés par les couches supérieures du protocole UniPro. La taille de trame maximale de 288 octets de charge utile par trame a été choisie pour garantir que l'ensemble de la pile de protocoles puisse facilement transmettre 256 octets de données d'application en un seul bloc. Les charges utiles constituées d'un nombre impair d'octets sont prises en charge en complétant la trame avec un nombre pair d'octets et en insérant un indicateur correspondant dans la fin.

En plus des trames de données qui contiennent des données utilisateur, L2 transmet et reçoit également des trames de contrôle. Les trames de contrôle se distinguent des trames de données par trois bits dans le premier symbole. Il existe deux types de trames de contrôle :

• Un type (« AFC- Acknowledgement and L2 Flow Control », 3 symboles) sert à accuser réception des trames de données reçues avec succès.
• L'autre type (« NAC », 2 symboles) notifie à l'émetteur correspondant qu'une trame incorrecte a été reçue.

Notez que ces types de trames de contrôle L2 sont envoyés de manière autonome par L2.

Les communications à haut débit à faible puissance peuvent entraîner des erreurs occasionnelles dans les données reçues. La couche de liaison de données contient un protocole permettant d'accuser réception automatiquement des trames de données correctement reçues (à l'aide de trames de contrôle AFC) et de signaler activement les erreurs pouvant être détectées au niveau L2 (à l'aide de trames de contrôle NAC). La cause la plus probable d'une erreur au niveau L2 est qu'une trame de données a été corrompue au niveau électrique (bruit, EMI). Cela entraîne une somme de contrôle de données ou de trame de contrôle incorrecte côté récepteur et entraînera sa retransmission automatique. Notez que les trames de données sont reconnues (AFC) ou reconnues négativement (NAC). Les trames de contrôle corrompues sont détectées par des temporisateurs qui surveillent les réponses attendues ou requises.

Une bande passante de 1 Gbit/s et un taux d'erreur binaire de 10 ⁻¹² à une vitesse de 1 gigabit/s impliqueraient une erreur toutes les 1000 secondes ou une fois tous les 1000 Gbit transmis. La couche 2 corrige donc automatiquement ces erreurs au prix d'une perte marginale de bande passante et au prix de l'espace tampon nécessaire dans la couche L2 pour stocker des copies des trames de données transmises en vue d'une éventuelle retransmission ou « relecture ».

Une autre caractéristique de L2 est la capacité d'un émetteur L2 à savoir s'il y a de l'espace tampon pour la trame de données à l'extrémité réceptrice. Cela repose à nouveau sur les trames de contrôle L2 (AFC) qui permettent à un récepteur d'indiquer à l'émetteur de l'homologue la quantité d'espace tampon disponible. Cela permet au récepteur de mettre l'émetteur en pause si nécessaire, évitant ainsi le débordement de la mémoire tampon de réception. Les trames de contrôle ne sont pas affectées par le contrôle de flux L2 : elles peuvent être envoyées à tout moment et le récepteur L2 est censé les traiter à la vitesse à laquelle elles arrivent.

UniPro prend actuellement en charge deux niveaux de priorité pour les trames de données, appelés Traffic Class 0 (TC0) et Traffic Class 1 (TC1). TC1 a une priorité plus élevée que TC0. Cela signifie que si un émetteur L2 doit envoyer un mélange de trames de données TC0 et TC1, les trames de données TC1 seront envoyées en premier. En supposant que la plupart du trafic de données utilise TC0 et que le réseau est encombré, cela permet de garantir que les trames de données TC1 arrivent à destination plus rapidement que les trames de données TC0 (de manière analogue aux véhicules d'urgence et au trafic routier normal). De plus, L2 peut même interrompre ou « préempter » une trame de données TC0 sortante pour transmettre une trame de données TC1. Des règles d'arbitrage supplémentaires s'appliquent aux trames de contrôle : en substance, celles-ci reçoivent une priorité plus élevée que les trames de données car elles sont petites et essentielles pour maintenir la fluidité du trafic.

Dans un réseau multi-sauts, l'arbitrage est effectué au sein de chaque émetteur L2 à chaque saut. La classe de trafic attribuée aux données ne change normalement pas à mesure que les données progressent sur le réseau. Il appartient aux applications de décider comment utiliser le système de priorité.

Dans la version 1.1 d'UniPro, une option a été introduite pour permettre aux périphériques de point d'extrémité simples d'implémenter uniquement l'une des deux classes de trafic s'ils le souhaitent. Cela peut être utile lorsque les concepteurs de périphériques sont plus préoccupés par le coût d'implémentation que par le contrôle de l'arbitrage des trames. Le périphérique homologue L2 connecté détecte ces périphériques pendant la phase d'initialisation de la liaison et peut éviter d'utiliser la classe de trafic manquante.

Les différents mécanismes L2 offrent un certain nombre de garanties aux protocoles de couche supérieure :

• une trame de données reçue contiendra la charge utile correcte (vérifiée à l'aide d'une somme de contrôle)
• une trame de données transmise atteindra le récepteur du pair (après d'éventuelles retransmissions)
• il y aura de la place pour accueillir les trames de données reçues (contrôle de flux L2)
• le contenu d'une trame de données ne sera transmis qu'une seule fois à la couche de protocole supérieure (les trames de données en double sont supprimées)
• les trames de données au sein de la même classe de trafic seront reçues et transmises aux couches de protocole supérieures dans l'ordre

Les liaisons individuelles assurent ainsi de manière autonome un transfert fiable des données. Cela diffère par exemple du protocole TCP largement utilisé, qui détecte les erreurs aux points d'extrémité et s'appuie sur une retransmission de bout en bout en cas de données corrompues ou manquantes.

La couche réseau est destinée à acheminer les paquets à travers le réseau vers leur destination. Les commutateurs d'un réseau multi-sauts utilisent cette adresse pour décider dans quelle direction acheminer les paquets individuels. Pour ce faire, un en-tête contenant une adresse de destination de 7 bits est ajouté par L3 à toutes les trames de données L2. Dans l'exemple illustré dans la figure, cela permet au périphérique n°3 de communiquer non seulement avec les périphériques n°1, n°2 et n°5, mais également avec les périphériques n°4 et n°6.

La version 1.4 de la spécification UniPro ne spécifie pas les détails d'un commutateur, mais en spécifie suffisamment pour permettre à un périphérique de fonctionner dans un futur environnement en réseau.

Bien que le rôle de l'adresse L3 soit le même que celui de l'adresse IP dans les paquets sur Internet, une adresse UniPro DeviceID ne fait que 7 bits de long. Un réseau peut donc contenir jusqu'à 128 périphériques UniPro différents. Notez que, en ce qui concerne UniPro, tous les périphériques UniPro sont créés égaux : contrairement à PCI Express ou USB, n'importe quel périphérique peut prendre l'initiative de communiquer avec n'importe quel autre périphérique. Cela fait d'UniPro un véritable réseau plutôt qu'un bus avec un seul maître.

Le diagramme montre un exemple de paquet L3 qui commence au premier octet de charge utile L2 d'une trame L2 et se termine au dernier octet de charge utile L2 d'une trame L2. Pour des raisons de simplicité et d'efficacité, un seul paquet L3 peut être transporté par une trame L2. Cela implique que, dans UniPro, les concepts de trame L2, de paquet L3 et de segment L4 (voir ci-dessous) sont si étroitement alignés qu'ils sont presque synonymes. La distinction (et la « coloration ») est cependant toujours faite pour garantir que la spécification peut être décrite de manière strictement stratifiée.

Les paquets à en-tête court UniPro utilisent un seul octet d'en-tête pour les informations L3. Il comprend l'adresse de destination L3 sur 7 bits. Le bit restant indique le format du paquet à en-tête court. Pour les paquets à en-tête court, l'adresse source L3 n'est pas incluse dans l'en-tête car on suppose que les deux appareils communicants ont échangé ces informations au préalable ( communication orientée connexion ).

Les paquets à en-tête long sont destinés à être introduits dans une future version de la spécification UniPro, leur format n'est donc pas défini (à l'exception d'un bit) dans la spécification UniPro v1.4 actuelle. Cependant, UniPro v1.4 définit un hook qui permet aux paquets à en-tête long d'être reçus ou transmis par un périphérique conforme à UniPro v1.4 en supposant que ce dernier puisse être mis à niveau via un logiciel. Le mécanisme de « piège à en-tête long » d'UniPro v1.4 transmet simplement la charge utile d'une trame de données L2 reçue (à savoir le paquet L3 avec son en-tête et sa charge utile) à l'extension L3 (par exemple, le logiciel) pour traitement. Le mécanisme peut également accepter la charge utile de la trame L2 de l'extension L3 pour la transmission. Ce mécanisme vise à permettre aux périphériques UniPro v1.4 de pouvoir être mis à niveau afin de prendre en charge les protocoles qui nécessitent les paquets à en-tête long encore non définis.

Bien que les détails des commutateurs ne soient pas encore abordés dans la spécification UniPro v1.4, L3 permet aux périphériques UniPro v1.0/v1.1/v1.4 de servir de points de terminaison sur un réseau. Il garantit donc un certain nombre de propriétés aux protocoles de couche supérieure :

• que les paquets seront livrés au périphérique de destination adressé (et les paquets adressés à des périphériques inexistants sont rejetés)
• cette charge utile envoyée par une source L3 à une seule destination L3 sous la forme d'une série d'un ou plusieurs paquets à en-tête court dans une seule classe de trafic arrivera dans l'ordre et avec la charge utile correcte (fiabilité)

Les fonctionnalités de la couche Transport d'UniPro ne sont pas particulièrement complexes, car les services de communication de base sont déjà pris en charge par les couches de protocole inférieures. La couche L4 consiste essentiellement à permettre à plusieurs périphériques sur le réseau ou même à plusieurs clients au sein de ces périphériques de partager le réseau de manière contrôlée. Les fonctionnalités de la couche L4 ont tendance à être à peu près comparables à celles que l'on trouve dans les réseaux informatiques (par exemple TCP et UDP ), mais qui sont moins fréquemment rencontrées dans les bus locaux comme PCI Express, USB ou les bus sur puce.

La couche L4 d'UniPro a également une importance particulière car elle constitue la couche de protocole supérieure dans la spécification UniPro. Les applications doivent utiliser l'interface supérieure de L4 pour interagir avec UniPro et ne doivent pas contourner L4 pour accéder directement aux couches inférieures. Notez que l'interface située au sommet de L4 prévue pour la transmission ou la réception de données est définie au niveau comportemental ou fonctionnel. Ce niveau élevé d'abstraction évite de restreindre les options d'implémentation. Ainsi, bien que la spécification contienne une annexe avec une interface de niveau signal comme exemple non normatif, une implémentation UniPro n'est pas obligée d'avoir un ensemble spécifique de signaux matériels ou d'appels de fonctions logicielles sur son interface supérieure.

La couche de transport d'UniPro peut être considérée comme fournissant un niveau d'adressage supplémentaire au sein d'un périphérique UniPro.

• permet à un appareil UniPro de communiquer avec un autre appareil UniPro à l'aide de plusieurs flux de données logiques (exemple : envoi d'informations audio, vidéo et de contrôle séparément).
• permet à un périphérique UniPro de se connecter simultanément à plusieurs autres périphériques (cela nécessite des commutateurs tels que pris en charge dans une future version d'UniPro ) à l'aide de plusieurs flux de données logiques.
• fournit des mécanismes pour réduire le risque de congestion sur le réseau.
• fournit un mécanisme permettant de structurer un flux d'octets sous forme de flux de messages.

Ces points sont expliqués plus en détail ci-dessous.

Un segment L4 est essentiellement la charge utile d'un paquet L3. L'en-tête L4, dans sa forme courte, se compose d'un seul octet. Le champ principal de l'en-tête L4 court est un identifiant « CPort » de 5 bits qui peut être considéré comme une sous-adresse au sein d'un périphérique UniPro et est quelque peu analogue aux numéros de port utilisés dans TCP ou UDP . Ainsi, chaque segment (avec un en-tête court) est adressé à un CPort spécifique d'un périphérique UniPro spécifique.

Un seul bit dans l'en-tête du segment permet également de définir des segments avec des en-têtes de segment longs. UniPro v1.4 ne définit pas la structure de tels formats de segment (à l'exception de ce seul bit). Les segments d'en-tête longs peuvent être générés via le piège d'en-tête long décrit dans la section L3.

UniPro appelle une paire de CPorts qui communiquent entre eux une connexion (d'où le C dans CPort). La configuration d'une connexion signifie qu'un CPort a été initialisé pour créer des segments adressés à un CPort L4 spécifique d'un DeviceID L3 spécifique à l'aide d'une classe de trafic L2 particulière. Les connexions UniPro étant bidirectionnelles, le CPort de destination est également configuré pour permettre le renvoi des données au CPort source.

Dans UniPro 1.0/1.1, la configuration de la connexion est spécifique à l'implémentation.

Dans UniPro v1.4, la configuration des connexions est supposée être relativement statique : les paramètres des CPorts appariés sont configurés en définissant les attributs de connexion correspondants dans les périphériques locaux et homologues à l'aide du DME. Ceci sera complété par un protocole de gestion de connexion dynamique dans une future version d'UniPro.

Les CPorts contiennent également des variables d'état qui peuvent être utilisées pour suivre la quantité d'espace tampon dont dispose le CPort homologue ou connecté. Cela permet d'éviter la situation dans laquelle un CPort envoie des segments à un CPort qui ne dispose pas d'un espace tampon suffisant pour contenir les données, ce qui entraîne un blocage du trafic de données. À moins d'être résolu rapidement, cet embouteillage à la destination se transforme rapidement en un blocage à l'échelle du réseau. Cela est hautement indésirable car cela peut affecter considérablement les performances du réseau pour tous les utilisateurs ou, pire, peut conduire à des situations de blocage. Le mécanisme L4 décrit est connu sous le nom de contrôle de flux de bout en bout (E2E FC) car il implique les points de terminaison d'une connexion.

Le contrôle de flux L4 est complémentaire du contrôle de flux L2. Les deux fonctionnent en faisant en sorte que l'émetteur s'arrête jusqu'à ce qu'il sache qu'il y a suffisamment d'espace tampon au niveau du récepteur. Mais le contrôle de flux L4 fonctionne entre une paire de CPorts (potentiellement à plusieurs sauts d'intervalle) et vise à isoler les connexions les unes des autres (analogie du « fil virtuel »). En revanche, le contrôle de flux L2 s'effectue par saut et évite la perte de données de base due au manque d'espace tampon du récepteur.

Le protocole E2E FC n'est possible que pour les communications orientées connexion, mais le protocole L4 d'UniPro ne prend actuellement pas en charge d'autres options. Le protocole E2E FC est activé par défaut, mais peut toutefois être désactivé. Cela n'est généralement pas recommandé.

UniPro fournit des mécanismes de « filet de sécurité » qui imposent à un CPort d'absorber toutes les données qui lui sont envoyées sans se bloquer. Si un blocage est détecté, le point de terminaison rejette les données entrantes arrivant à ce CPort afin de maintenir le flux de données sur le réseau. Cela peut être considéré comme une forme de dégradation gracieuse au niveau du système : si une connexion sur le réseau ne peut pas suivre la vitesse des données reçues, les autres périphériques et les autres connexions ne sont pas affectés.

UniPro L4 permet à une connexion entre une paire de CPorts de transmettre un flux de messages (chacun composé d'une série d'octets) plutôt qu'un seul flux d'octets. Les limites de message sont déclenchées par le protocole de niveau application utilisant UniPro et sont signalées via un bit dans l'en-tête du segment. Ce bit de fin de message indique que le dernier octet du segment L4 est le dernier octet du message de niveau application.

L'application doit indiquer à UniPro où et quand insérer les limites de message dans le flux d'octets : les limites n'ont aucune signification particulière pour UniPro lui-même et sont fournies en tant que service pour créer des protocoles de couche supérieure sur UniPro. Les messages peuvent être utilisés pour indiquer (par exemple via une interruption) à l'application qu'une unité de données est complète et peut donc être traitée. Les messages peuvent également être utiles comme mécanisme robuste et efficace pour implémenter des points de resynchronisation dans certaines applications.

UniPro v1.4 introduit la notion de fragment de message, un fragment étant une partie d'un message transmis entre l'application et le CPort. Cette option peut être utile lors de la spécification d'applications sur UniPro qui doivent interrompre la création de messages en fonction des informations de la pile UniPro, par exemple des messages entrants ou une contre-pression.

Les mécanismes de L4 fournissent un certain nombre de garanties aux protocoles de couche supérieure :

• Un CPort ne peut pas stagner, dans le sens où il continuera toujours à accepter les données aussi rapidement que le lien ou le réseau peut les fournir.
• Si une application liée au CPort d'une connexion se bloque et ne parvient donc pas (pour des périodes brèves ou longues) à absorber des données, les autres connexions aux mêmes périphériques ou à des périphériques différents ne sont pas affectées.
• Un flux de données envoyé d'un CPort à un autre arrivera toujours intact, dans l'ordre et avec les informations de limite de message correctes si le CPort est capable de suivre le flux de données entrant.
• Si le CPort ne peut pas suivre le flux de données entrant, un ou plusieurs messages peuvent être corrompus (en raison de données manquantes) et le récepteur est averti de cette condition d'erreur.
• Il est sans danger pour un protocole de niveau application d'attendre la réponse d'un homologue (par exemple une réponse ou un accusé de réception) à un message L4 envoyé (par exemple une question ou une commande). Mais il est dangereux pour un protocole de niveau application d'attendre la réponse d'un homologue à un message partiel envoyé.
• Le contenu des paquets/segments d'en-tête courts reçus sera toujours correct. Bien que la livraison à l'interface de trap d'en-tête long ne soit pas garantie, une future extension du protocole prévoit de rendre la livraison de ces paquets fiable. Cette extension du protocole pourrait être implémentée dans un logiciel au-dessus du trap d'en-tête long.

L'entité DME (Device Management Entity) contrôle les couches de la pile UniPro. Elle permet d'accéder aux paramètres de contrôle et d'état de toutes les couches, gère les transitions de mode d'alimentation du Link et gère le démarrage, la mise en veille prolongée et la réinitialisation de la pile. De plus, elle fournit des moyens de contrôler la pile UniPro homologue sur le Link.