DLNA et OCF: interopérabilité media + IoT

Auteur Hugues Orgitello Mis à jour le 3 juillet 2026 ~13 min de lecture

Guide · DLNA / OCF

Deux marques d'interopérabilité occupent le même créneau historique, le streaming media et la découverte de devices sur réseau local IP, avec des trajectoires inverses. DLNA, Digital Living Network Alliance, a structure pendant quinze ans le marche du media partage entre TV, NAS, smartphones et set-top boxes, avant de dissoudre son organisation en janvier 2017. OCF, Open Connectivity Foundation, formée en 2016 par la fusion d'UPnP Forum et d'AllSeen Alliance, reprend une partie du substrat UPnP et l'étend a l'Internet of Things avec un schéma de sécurité propre. La confusion la plus frequente consiste a traiter ces deux programmes comme équivalents ou interchangeables. Ils ne le sont pas, et l'arrivée de Matter a redistribue une partie du périmètre. Cette page detaille séparément le statut DLNA en tant que reference héritée et OCF en tant que programme actif, puis situe les deux par rapport a Matter et aux solutions propriétaires d'écosystème.

DLNA (legacy)

Origine et périmètre historique

La Digital Living Network Alliance a ete fondée en 2003 sous le nom Digital Home Working Group, par un consortium d'industriels mene par Sony, Intel, Microsoft, Samsung, HP et Nokia. Son objectif: définir un cadre commun pour que les équipements grand public puissent découvrir, lister et lire les contenus media (audio, vidéo, image) présents sur d'autres équipements du même réseau domestique, sans configuration manuelle.

Le périmètre technique s'est cristallise autour de deux livrables:

• les DLNA Guidelines, ensemble de profils d'usage qui contraignent et complémentent les spécifications sous-jacentes (UPnP AV, HTTP, codecs, formats container);
• le programme DLNA Certified, qui validait la conformité d'un produit a un ou plusieurs profils DLNA et autorisait l'apposition du logo.

La dernière édition publique des Guidelines, Home Networked Device Interoperability Guidelines version 2 (HNv2), a ete publiée en 2014. Les Guidelines couvraient le réseau (IPv4 unicast/multicast, découverte SSDP), le contenu (codecs MP3, AAC, H.264, JPEG, et profils vidéo MPEG), la sécurité (DTCP-IP pour les contenus proteges), et les rôles fonctionnels.

Roles DLNA, la nomenclature

DLNA décomposait l'écosystème media en plusieurs rôles, qu'un même équipement physique pouvait cumuler. La nomenclature reste utile a connaître car de nombreuses fiches produits anciennes y font reference:

Sigle	Role	Exemple typique
DMS	Digital Media Server, hôte des contenus	NAS, ordinateur, smartphone partageant des photos
DMR	Digital Media Renderer, lecteur pilote a distance	TV connectée, enceinte réseau, chaine hi-fi
DMP	Digital Media Player, lecteur autonome avec interface	TV connectée parcourant elle-même un NAS
DMC	Digital Media Controller, telecommande virtuelle	Smartphone qui pilote un DMR a partir d'un DMS
DMPr	Digital Media Printer, impression depuis le réseau	Imprimante réseau acceptant des contenus DLNA
M-DMS, M-DMP, M-DMR, M-DMC, M-DMPr	Variantes Mobile, profils contraints pour smartphone	Application photo DLNA d'un smartphone
MPP	Mobile Network Connectivity Function	Couche d'adaptation pour réseaux mobiles

Le succès commercial de DLNA s'est concentre sur le triplet DMS/DMR/DMC, typiquement un NAS qui sert les contenus, une TV qui les rend, et un smartphone qui pilote l'ensemble. Les rôles DMP et DMC autonomes ont vu un usage plus dilue.

Fondement UPnP

DLNA n'a jamais reinvente la couche de découverte ni la couche de controle. L'ensemble repose sur UPnP (Universal Plug and Play), specifie historiquement par le UPnP Forum, et plus particulièrement sur le profil UPnP AV qui modélisé les MediaServer, MediaRenderer et leurs ContentDirectory, AVTransport, RenderingControl. DLNA ajoute par-dessus des contraintes de profil (codecs autorises, formats de container, comportement réseau, mécanismes de mise en pause, sequencing) qui assurent qu'un DMS d'un fabricant A est consommable par un DMR d'un fabricant B sans surprise.

Cette dépendance a UPnP est ce qui a permis le transfert ultérieur des spécifications UPnP a OCF en 2016, lors de la fusion UPnP Forum / AllSeen Alliance. Les Guidelines DLNA, en revanche, n'ont pas ete reprises par OCF, elles restent un livrable historique consultable via les archives.

Dissolution en 2017

En janvier 2017, la DLNA a annonce la dissolution de l'organisation. Les raisons publiquement évoquées combinaient le déclin du marche du media partage local (la consommation s'est déplacée vers le streaming OTT, Netflix, YouTube, et vers des écosystèmes ferme tels qu'AirPlay et Chromecast), la maturité des Guidelines (HNv2 étant juge stable), et l'arrivée d'OCF qui reprenait le substrat UPnP pour le porter vers l'IoT.

Concrètement, depuis 2017:

• aucun nouveau Guidelines DLNA n'est publie;
• aucun nouveau produit n'est certifie DLNA par l'organisation historique;
• la base des produits certifies est gelée, consultable via les archives;
• les logos DLNA Certified déjà apposes sur des produits existants restent juridiquement utilisables selon les termes de la licence d'origine, mais sans renouvellement actif.

Une société dénommée SpireSpark International, qui opérait déjà les tests DLNA, a annonce avoir repris une partie de l'activité de test sous forme privée. Ce service ne reproduit cependant pas le programme DLNA Certified au sens originel, et ne fait pas autorité pour l'apposition du logo. Pour tout produit nouveau, considérer DLNA comme un programme héritage est la lecture industrielle prudente.

Sort moderne, qui a pris la place

Le périmètre fonctionnel autrefois couvert par DLNA s'est fragmente sur plusieurs technologies:

• HTTPS Adaptive Streaming (DASH, HLS) pour le streaming vidéo, qui domine aujourd'hui la consommation et qui n'a pas besoin d'un logo d'interopérabilité spécifique;
• UPnP AV subsiste de fait, en tant que substrat technique, dans de nombreux NAS et lecteurs media, mais sans contrainte DLNA active sur les codecs;
• OCF pour la découverte et le controle de devices IoT au sens large, voir la section suivante;
• Matter pour le smart home grand public, avec un périmètre delibrement restreint aux équipements domestiques (éclairage, prises, thermostats, etc.) et pas au media;
• Apple AirPlay et Google Cast (Chromecast) pour le casting media, sur des modeles propriétaires qui ne dépendent ni de DLNA ni de Matter;
• Amazon Fire TV / Roku / Apple TV pour le hub media, avec leurs propres SDK partenaires.

Sur les fiches techniques de produits 2020+ qui mentionnent encore DLNA, la mention reflete généralement la prise en charge d'UPnP AV plus que la possession d'une certification DLNA active. La lecture marketing du logo a perdu sa valeur initiale.

OCF (current)

Formation et périmètre

L'Open Connectivity Foundation a ete formée en 2016 par la fusion de l'UPnP Forum, de l'AllSeen Alliance (qui portait AllJoyn) et de l'Open Interconnect Consortium (OIC, fonde par Intel, Samsung et d'autres en 2014). Le mandat: définir un cadre commun d'interopérabilité pour l'Internet of Things, couvrant la découverte, le controle et la sécurité des devices, indépendamment de la couche de transport.

Contrairement a DLNA qui restait centre sur le media domestique, OCF cible un périmètre IoT large, comprenant:

• le smart home (concurremment a Matter, voir plus loin);
• le smart building (HVAC, éclairage commercial, controle d'accès, supervision);
• l'industrial IoT (capteurs industriels, M2M, supervision de chaines de production);
• l'automotive latéral (voiture connectée au domicile, infrastructures de recharge);
• la santé connectée non médicale (télésurveillance bien-être, fitness).

Specifications OCF, la pile

OCF publie un ensemble de spécifications cohérent, gere par version, dont les principales pour un projet de certification sont:

Specification	Perimetre
Core Specification	Modele de ressource, framework REST, transport CoAP/HTTP, découverte multicast
Security Specification	Authentification, autorisation, ACL2, Device Onboarding, profils de sécurité
Resource Type Specification	Catalogue des Resource Types (oic.r.switch.binary, oic.r.temperature, etc.)
Device Specification	Profils de devices types et leur composition de ressources
Wi-Fi Easy Setup Specification	Procedure d'onboarding initial via Wi-Fi pour devices headless
Cloud API Specification	Interface entre OCF Server et un cloud OCF
Bridging Specification	Pont entre OCF et autres protocoles (Zigbee, BLE, Z-Wave, etc.)

La pile est conçue pour être stateless cote modele, avec une représentation des ressources de chaque device qui suit la philosophie RESTful (GET, PUT, POST, DELETE, OBSERVE), portée sur CoAP en transport principal et HTTP en transport secondaire.

OCF Certified et ICAID

Le programme OCF Certified valide la conformité d'un produit a un ensemble de spécifications. La certification couvre:

• conformité Core, verification que le device implemente correctement la découverte, la représentation des ressources, le routing REST;
• conformité Resource Type, verification que chaque Resource Type déclarée respecte exactement le schéma (attributs, types, plages de valeurs);
• conformité Security, verification de la mise en oeuvre du profil de sécurité choisi (Baseline, Black, Blue, Purple), de la chaine de certificats, du provisioning d'usine;
• interopérabilité, verification que le device interagit correctement avec d'autres devices certifies OCF.

Au coeur du schéma de sécurité OCF se trouve l'ICAID, Identifier Certificate Authority Identifier, attribue par OCF a chaque autorité de certification reconnue. Le Manufacturer Certificate provisionne dans le device en usine est émis sous un ICAID, et le commissioner verifie au moment de l'onboarding que la chaine remonte a une CA reconnue. L'analogie conceptuelle avec la PAA de Matter est forte, le périmètre fonctionnel est cependant plus large dans OCF.

Un identifiant additionnel, le Vendor ID (di + Vendor ID + Model + serial number), identifie de maniere unique un device dans l'écosystème OCF. L'enregistrement OCF Certified pousse cet identifiant dans la base publique des produits OCF certifies, consultable via le portail OCF.

IoTivity, l'implémentation de reference

IoTivity est l'implémentation open-source de reference des spécifications OCF. Le projet est heberge par l'Open Connectivity Foundation et distribue sous licence Apache 2.0. Plusieurs branches ont existe au fil du temps:

• IoTivity-Classic, base C portée par Intel/Samsung historiquement, riche en fonctionnalités;
• IoTivity-Lite, base C orientée constrained device (microcontrôleur avec quelques dizaines de kilo-octets de RAM);
• ports communautaires en Java, Python pour le prototypage.

Un fabricant n'est pas tenu d'utiliser IoTivity, il peut implémenter sa propre pile a partir des spécifications OCF et la soumettre a certification. IoTivity réduit cependant le coût d'entrée, en particulier pour les petites equipes et pour le prototypage.

Securite OCF, ACL2 et profils

La sécurité OCF s'articule autour de quatre profils, qu'un produit choisit lors de la certification:

Profil	Cryptographie	Cible
Baseline	TLS/DTLS, certificats X.509, PSK	Smart home standard, résidentiel
Black	Cipher suites renforces, audit logs étendus	Smart building professionnel
Blue	Renforce, exigences additionnelles d'isolation	Industrial IoT
Purple	Reservation pour profils gouvernementaux	Defense, infrastructure critique

Le choix du profil n'est pas anodin, il conditionne le périmètre cryptographique, la complexité de l'onboarding et le coût de certification. Un produit smart home grand public se contente typiquement de Baseline. Un produit industriel doit sélectionner Blue. Le profil declare doit être cohérent avec la cible commerciale.

Le coeur du modele de controle d'accès est l'ACL2, Access Control List version 2, qui specifie pour chaque ressource du device quels sujets (identités de devices ou de groupes) ont quels droits (CRUD plus Notify). L'ACL2 est provisionnée initialement par l'OBT a l'onboarding, puis modifiable par les sujets autorises selon les politiques OCF. Le schéma ACL2 a explicitement influence la conception du système de fabric et d'ACL de Matter, qui en reprend la philosophie sans en être un sous-ensemble strict.

Onboarding, le rôle de l'OBT

L'OBT (Onboarding Tool) est le composant qui met en service un nouveau device OCF dans un réseau existant. La séquence typique:

1. Le device se met en mode onboarding (Random PIN, Just Works, ou Manufacturer Certificate selon le profil).
2. L'OBT découvre le device via multicast CoAP.
3. Authentification mutuelle entre le device et l'OBT, en utilisant le mode d'onboarding choisi.
4. Transfert d'ownership, le device adopte l'OBT comme propriétaire initial.
5. Provisioning des credentials, l'OBT écrit dans le device les certificats d'identité definitifs.
6. Provisioning des ACL2 initiales, qui déterminent qui peut faire quoi sur le device.
7. Bascule du device en mode opérationnel, l'OBT relache son rôle exclusif.

Cette séquence est l'analogue OCF du commissioning Matter, avec ses propres spécificités de profil de sécurité et de rôle d'ownership. Un point souvent sous-estime, l'OBT n'est pas nécessairement un équipement dedie: dans un déploiement smart home OCF, l'OBT est typiquement integre a l'application mobile du fabricant ou a un hub OCF, dans un déploiement industriel il peut être un poste de mise en service dedie.

OCF vs Matter vs DLNA, périmètres compares

Le diagramme de positionnement le plus parlant resume les trois programmes sur trois axes, périmètre, statut, couches couvertes:

Axe	DLNA	OCF	Matter
Domaine cible	Media domestique (audio, vidéo, image)	IoT large (smart home, smart building, industrial)	Smart home grand public (devices domestiques)
Statut	Programme héritage, organisation dissoute en 2017	Programme actif, spécifications versionnées	Programme actif, specs CSA versionnées
Couche réseau	UPnP sur IPv4	CoAP/HTTP sur IPv4/IPv6	IPv6 sur Thread / Wi-Fi
Securite native	DTCP-IP pour contenus proteges, sinon limitée	ACL2, profils Baseline/Black/Blue/Purple, OBT	DAC/PAI/PAA, fabric, ACL inspire d'OCF
Logo actif	Non	Oui (OCF Certified)	Oui (Matter logo)
Frais membre	Sans objet	Adhesion OCF, voir grille publique	Adhesion CSA, voir grille publique
Outil de certification	Sans objet (gel)	Test plans OCF Certification Testing Tool (CTT)	ATL CSA + chip-tool + TestHarness

Lecture pratique:

• Pour un produit media domestique en 2026, ni DLNA ni OCF ne sont la bonne réponse en premier lieu. Le marche s'est deplace vers AirPlay, Cast, et les apps natives. Un support UPnP AV sans certification reste possible techniquement, comme fonctionnalité secondaire.
• Pour un produit smart home grand public (éclairage, prise, thermostat, capteur), Matter est aujourd'hui la cible réglementaire la plus pertinente. OCF reste possible mais le marche pousse vers Matter, en particulier parce que les principaux écosystèmes consommateurs (Apple Home, Google Home, Amazon Alexa, SmartThings) imposent Matter pour le commissioning utilisateur. Voir certification Matter.
• Pour un produit smart building professionnel, OCF garde une pertinence réelle, en particulier sur les profils Black et les Resource Types orientes gestion technique du batiment.
• Pour un produit industrial IoT, OCF profil Blue reste une option, en compétition avec OPC UA (qui n'est pas OCF) et avec des protocoles industriels métier (Modbus TCP, BACnet, etc.). Matter ne couvre pas ce segment.

Articulation avec les régimes radio réglementaires

OCF et Matter sont des programmes d'interopérabilité applicative, ils ne couvrent pas la conformité radio. Un produit OCF Wi-Fi commercialise en Europe doit être conforme a la directive RED (articles 3.1, 3.2, 3.3), un produit commercialise aux Etats-Unis doit être conforme a FCC Part 15. Aucune de ces obligations n'est levée par la certification OCF. Symétriquement, un produit OCF qui n'a pas sa conformité radio ne peut pas être mis sur le marche, même s'il est techniquement certifie OCF.

Pour les produits Bluetooth qui utilisent OCF Bridging pour exposer un device BLE comme ressource OCF, la qualification Bluetooth SIG reste nécessaire pour l'usage du logo Bluetooth, en plus de la certification OCF. Voir le glossaire des certifications pour la définition des termes ICAID, OBT, ACL2, Resource Type, PAA et DAC.

Pieges récurrents

Sur les premières soumissions OCF et sur les projets qui supposent un statut DLNA actif, les non-conformites suivantes reviennent régulièrement:

• Supposer que DLNA est encore activement certifie. Aucune nouvelle certification DLNA n'est émise depuis 2017. Concevoir un produit en prétendant viser le logo DLNA n'a pas de sens commercial actuel.
• Confondre DLNA et UPnP AV. UPnP AV existe toujours en tant que substrat technique, sans contrainte DLNA active sur les codecs. Annoncer "compatible DLNA" sur un produit 2026 induit en erreur, l'annonce correcte serait "compatible UPnP AV".
• Omettre le choix du Security Profile OCF. Le profil (Baseline, Black, Blue, Purple) est une décision précoce qui conditionne l'architecture cryptographique. Un produit qui demarre en Baseline et qui doit basculer en Blue tard dans le cycle subit une refonte couteuse.
• Sous-estimer le provisioning d'usine OCF. Le Manufacturer Certificate doit être provisionne en usine de maniere sécurisée, avec une cle privée qui ne quitte jamais le secure storage. C'est un sujet de chaine de production, pas un sujet de firmware.
• Croire que Matter dispense de OCF. Pour un produit smart home grand public, oui, en pratique Matter remplace OCF. Pour un produit smart building ou industrial IoT, non, Matter ne couvre pas le périmètre, OCF reste pertinent.
• Confondre ICAID OCF et PAA Matter. Les deux jouent un rôle analogue de racine d'identité, mais ce sont deux PKI distinctes, gérées par deux organisations distinctes (OCF et CSA). Un certificat sous ICAID OCF n'est pas reconnu par un commissioner Matter, et inversement.
• Ignorer la coexistence avec les radios sous-jacentes. Une certification OCF ne dispense d'aucune certification radio réglementaire (RED, FCC, RCM, etc.) ni d'aucune certification d'écosystème radio (Wi-Fi Alliance, Bluetooth SIG, Thread Group). Voir les guides dedies pour chacun de ces régimes.
• Mauvaise lecture du logo sur produit ancien. Un équipement neuf vendu en 2026 avec un logo DLNA Certified visible est typiquement un produit dont la conception remonte a une fenetre ou la certification était encore active. Cela ne dit rien de la pertinence du logo en 2026 du point de vue marketing ou interop.

Synthese opérationnelle

Pour un fabricant qui demarre un projet IoT ou media en 2026, le découpage décisionnel se resume ainsi:

1. Smart home grand public, produit domestique standard: cibler Matter, traiter OCF comme complémentaire au plus, ignorer DLNA.
2. Smart building professionnel ou industrial IoT: OCF reste pertinent, choisir tot le Security Profile, traiter Matter comme hors-périmètre.
3. Media streaming domestique: ni DLNA ni OCF en premier lieu, regarder les écosystèmes propriétaires (AirPlay, Cast) et le streaming standardise (DASH, HLS).
4. Maintenance d'un produit DLNA Certified existant: la marque reste juridiquement utilisable selon la licence d'origine, mais sans renouvellement actif et avec une valeur marketing fortement diminuee. Une migration vers Matter ou OCF est a évaluer selon la roadmap du produit.

Dans tous les cas, la conformité radio réglementaire (CE/RED en Europe, FCC aux Etats-Unis, plus les régimes nationaux équivalents) reste obligatoire et indépendante de tout programme d'interopérabilité applicative.

Voir aussi

• HDMI Forum et HDMI LA: certification cable et appareil
• NFC Forum : certification et marque N-Mark
• Zigbee + CSA: certification du protocole 802.15.4 mesh
• Wi-SUN Alliance : certification IPv6 mesh sub-GHz
• Certification Matter (CSA): processus, DAC et DCL
• Certification KNX, DALI-2 et EnOcean
• Sans fil de niche : ANT+, KNX-RF, DECT ULE, 6LoWPAN

Besoin d’un appui ?

Un audit de 30 minutes avec les ingénieurs AESTECHNO.

AESTECHNO est le bureau d'études qui édite spilma. Nous aidons les équipes produit à cadrer leur démarche de certification et à éviter les pièges classiques.

Réserver un audit gratuit

Un cas concret de positionner un produit IoT entre Matter, OCF et les ecosystemes proprietaires ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Sources & références

1. Open Connectivity Foundation , Open Connectivity Foundation openconnectivity.org/
2. OCF spécifications portal , Open Connectivity Foundation openconnectivity.org/developer/specifications/
3. IoTivity open-source project , IoTivity / OCF iotivity.org/
4. DLNA Guidelines and Certified database (archive) , Digital Living Network Alliance (dissolved 2017) web.archive.org/web/2017/https://www.dlna.org/
5. UPnP spécifications archive (transferred to OCF, 2016) , Open Connectivity Foundation openconnectivity.org/developer/specifications/upnp-resources/upnp/
6. CSA Matter, overview , Connectivity Standards Alliance csa-iot.org/all-solutions/matter/