Aller au contenu

DLNA et OCF: interoperabilite media + IoT

Guide · DLNA / OCF

Deux marques d'interoperabilite occupent le meme creneau historique, le streaming media et la decouverte de devices sur reseau 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, formee en 2016 par la fusion d'UPnP Forum et d'AllSeen Alliance, reprend une partie du substrat UPnP et l'etend a l'Internet of Things avec un schema de securite propre. La confusion la plus frequente consiste a traiter ces deux programmes comme equivalents ou interchangeables. Ils ne le sont pas, et l'arrivee de Matter a redistribue une partie du perimetre. Cette page detaille separement le statut DLNA en tant que reference heritee et OCF en tant que programme actif, puis situe les deux par rapport a Matter et aux solutions proprietaires d'ecosysteme.

La Digital Living Network Alliance a ete fondee 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: definir un cadre commun pour que les equipements grand public puissent decouvrir, lister et lire les contenus media (audio, video, image) presents sur d'autres equipements du meme reseau domestique, sans configuration manuelle.

Le perimetre technique s'est cristallise autour de deux livrables:

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

La derniere edition publique des Guidelines, Home Networked Device Interoperability Guidelines version 2 (HNv2), a ete publiee en 2014. Les Guidelines couvraient le reseau (IPv4 unicast/multicast, decouverte SSDP), le contenu (codecs MP3, AAC, H.264, JPEG, et profils video MPEG), la securite (DTCP-IP pour les contenus proteges), et les roles fonctionnels.

DLNA decomposait l'ecosysteme media en plusieurs roles, qu'un meme equipement physique pouvait cumuler. La nomenclature reste utile a connaitre car de nombreuses fiches produits anciennes y font reference:

SigleRoleExemple typique
DMSDigital Media Server, hote des contenusNAS, ordinateur, smartphone partageant des photos
DMRDigital Media Renderer, lecteur pilote a distanceTV connectee, enceinte reseau, chaine hi-fi
DMPDigital Media Player, lecteur autonome avec interfaceTV connectee parcourant elle-meme un NAS
DMCDigital Media Controller, telecommande virtuelleSmartphone qui pilote un DMR a partir d'un DMS
DMPrDigital Media Printer, impression depuis le reseauImprimante reseau acceptant des contenus DLNA
M-DMS, M-DMP, M-DMR, M-DMC, M-DMPrVariantes Mobile, profils contraints pour smartphoneApplication photo DLNA d'un smartphone
MPPMobile Network Connectivity FunctionCouche d'adaptation pour reseaux mobiles

Le succes 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 roles DMP et DMC autonomes ont vu un usage plus dilue.

DLNA n'a jamais reinvente la couche de decouverte ni la couche de controle. L'ensemble repose sur UPnP (Universal Plug and Play), specifie historiquement par le UPnP Forum, et plus particulierement sur le profil UPnP AV qui modelise les MediaServer, MediaRenderer et leurs ContentDirectory, AVTransport, RenderingControl. DLNA ajoute par-dessus des contraintes de profil (codecs autorises, formats de container, comportement reseau, mecanismes 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 dependance a UPnP est ce qui a permis le transfert ulterieur des specifications 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.

En janvier 2017, la DLNA a annonce la dissolution de l'organisation. Les raisons publiquement evoquees combinaient le declin du marche du media partage local (la consommation s'est deplacee vers le streaming OTT, Netflix, YouTube, et vers des ecosystemes ferme tels qu'AirPlay et Chromecast), la maturite des Guidelines (HNv2 etant juge stable), et l'arrivee d'OCF qui reprenait le substrat UPnP pour le porter vers l'IoT.

Concretement, 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 gelee, consultable via les archives;
  • les logos DLNA Certified deja apposes sur des produits existants restent juridiquement utilisables selon les termes de la licence d'origine, mais sans renouvellement actif.

Une societe denommee SpireSpark International, qui operait deja les tests DLNA, a annonce avoir repris une partie de l'activite de test sous forme privee. Ce service ne reproduit cependant pas le programme DLNA Certified au sens originel, et ne fait pas autorite pour l'apposition du logo. Pour tout produit nouveau, considerer DLNA comme un programme heritage est la lecture industrielle prudente.

Le perimetre fonctionnel autrefois couvert par DLNA s'est fragmente sur plusieurs technologies:

  • HTTPS Adaptive Streaming (DASH, HLS) pour le streaming video, qui domine aujourd'hui la consommation et qui n'a pas besoin d'un logo d'interoperabilite specifique;
  • 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 decouverte et le controle de devices IoT au sens large, voir la section suivante;
  • Matter pour le smart home grand public, avec un perimetre delibrement restreint aux equipements domestiques (eclairage, prises, thermostats, etc.) et pas au media;
  • Apple AirPlay et Google Cast (Chromecast) pour le casting media, sur des modeles proprietaires qui ne dependent 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 generalement 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.

L'Open Connectivity Foundation a ete formee 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: definir un cadre commun d'interoperabilite pour l'Internet of Things, couvrant la decouverte, le controle et la securite des devices, independamment de la couche de transport.

Contrairement a DLNA qui restait centre sur le media domestique, OCF cible un perimetre IoT large, comprenant:

  • le smart home (concurremment a Matter, voir plus loin);
  • le smart building (HVAC, eclairage commercial, controle d'acces, supervision);
  • l'industrial IoT (capteurs industriels, M2M, supervision de chaines de production);
  • l'automotive lateral (voiture connectee au domicile, infrastructures de recharge);
  • la sante connectee non medicale (telesurveillance bien-etre, fitness).

OCF publie un ensemble de specifications coherent, gere par version, dont les principales pour un projet de certification sont:

SpecificationPerimetre
Core SpecificationModele de ressource, framework REST, transport CoAP/HTTP, decouverte multicast
Security SpecificationAuthentification, autorisation, ACL2, Device Onboarding, profils de securite
Resource Type SpecificationCatalogue des Resource Types (oic.r.switch.binary, oic.r.temperature, etc.)
Device SpecificationProfils de devices types et leur composition de ressources
Wi-Fi Easy Setup SpecificationProcedure d'onboarding initial via Wi-Fi pour devices headless
Cloud API SpecificationInterface entre OCF Server et un cloud OCF
Bridging SpecificationPont entre OCF et autres protocoles (Zigbee, BLE, Z-Wave, etc.)

La pile est concue pour etre stateless cote modele, avec une representation des ressources de chaque device qui suit la philosophie RESTful (GET, PUT, POST, DELETE, OBSERVE), portee sur CoAP en transport principal et HTTP en transport secondaire.

Le programme OCF Certified valide la conformite d'un produit a un ensemble de specifications. La certification couvre:

  • conformite Core, verification que le device implemente correctement la decouverte, la representation des ressources, le routing REST;
  • conformite Resource Type, verification que chaque Resource Type declaree respecte exactement le schema (attributs, types, plages de valeurs);
  • conformite Security, verification de la mise en oeuvre du profil de securite choisi (Baseline, Black, Blue, Purple), de la chaine de certificats, du provisioning d'usine;
  • interoperabilite, verification que le device interagit correctement avec d'autres devices certifies OCF.

Au coeur du schema de securite OCF se trouve l'ICAID, Identifier Certificate Authority Identifier, attribue par OCF a chaque autorite de certification reconnue. Le Manufacturer Certificate provisionne dans le device en usine est emis 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 perimetre 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'ecosysteme OCF. L'enregistrement OCF Certified pousse cet identifiant dans la base publique des produits OCF certifies, consultable via le portail OCF.

IoTivity est l'implementation open-source de reference des specifications 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 portee par Intel/Samsung historiquement, riche en fonctionnalites;
  • IoTivity-Lite, base C orientee constrained device (microcontroleur 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 implementer sa propre pile a partir des specifications OCF et la soumettre a certification. IoTivity reduit cependant le cout d'entree, en particulier pour les petites equipes et pour le prototypage.

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

ProfilCryptographieCible
BaselineTLS/DTLS, certificats X.509, PSKSmart home standard, residentiel
BlackCipher suites renforces, audit logs etendusSmart building professionnel
BlueRenforce, exigences additionnelles d'isolationIndustrial IoT
PurpleReservation pour profils gouvernementauxDefense, infrastructure critique

Le choix du profil n'est pas anodin, il conditionne le perimetre cryptographique, la complexite de l'onboarding et le cout de certification. Un produit smart home grand public se contente typiquement de Baseline. Un produit industriel doit selectionner Blue. Le profil declare doit etre coherent avec la cible commerciale.

Le coeur du modele de controle d'acces est l'ACL2, Access Control List version 2, qui specifie pour chaque ressource du device quels sujets (identites de devices ou de groupes) ont quels droits (CRUD plus Notify). L'ACL2 est provisionnee initialement par l'OBT a l'onboarding, puis modifiable par les sujets autorises selon les politiques OCF. Le schema ACL2 a explicitement influence la conception du systeme de fabric et d'ACL de Matter, qui en reprend la philosophie sans en etre un sous-ensemble strict.

L'OBT (Onboarding Tool) est le composant qui met en service un nouveau device OCF dans un reseau existant. La sequence typique:

  1. Le device se met en mode onboarding (Random PIN, Just Works, ou Manufacturer Certificate selon le profil).
  2. L'OBT decouvre 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 proprietaire initial.
  5. Provisioning des credentials, l'OBT ecrit dans le device les certificats d'identite definitifs.
  6. Provisioning des ACL2 initiales, qui determinent qui peut faire quoi sur le device.
  7. Bascule du device en mode operationnel, l'OBT relache son role exclusif.

Cette sequence est l'analogue OCF du commissioning Matter, avec ses propres specificites de profil de securite et de role d'ownership. Un point souvent sous-estime, l'OBT n'est pas necessairement un equipement dedie: dans un deploiement smart home OCF, l'OBT est typiquement integre a l'application mobile du fabricant ou a un hub OCF, dans un deploiement industriel il peut etre un poste de mise en service dedie.

Le diagramme de positionnement le plus parlant resume les trois programmes sur trois axes, perimetre, statut, couches couvertes:

AxeDLNAOCFMatter
Domaine cibleMedia domestique (audio, video, image)IoT large (smart home, smart building, industrial)Smart home grand public (devices domestiques)
StatutProgramme heritage, organisation dissoute en 2017Programme actif, specifications versionneesProgramme actif, specs CSA versionnees
Couche reseauUPnP sur IPv4CoAP/HTTP sur IPv4/IPv6IPv6 sur Thread / Wi-Fi
Securite nativeDTCP-IP pour contenus proteges, sinon limiteeACL2, profils Baseline/Black/Blue/Purple, OBTDAC/PAI/PAA, fabric, ACL inspire d'OCF
Logo actifNonOui (OCF Certified)Oui (Matter logo)
Frais membreSans objetAdhesion OCF, voir grille publiqueAdhesion CSA, voir grille publique
Outil de certificationSans 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 reponse 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 fonctionnalite secondaire.
  • Pour un produit smart home grand public (eclairage, prise, thermostat, capteur), Matter est aujourd'hui la cible reglementaire la plus pertinente. OCF reste possible mais le marche pousse vers Matter, en particulier parce que les principaux ecosystemes 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 reelle, 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 competition avec OPC UA (qui n'est pas OCF) et avec des protocoles industriels metier (Modbus TCP, BACnet, etc.). Matter ne couvre pas ce segment.

Articulation avec les regimes radio reglementaires

Section intitulée « Articulation avec les regimes radio reglementaires »

OCF et Matter sont des programmes d'interoperabilite applicative, ils ne couvrent pas la conformite radio. Un produit OCF Wi-Fi commercialise en Europe doit etre conforme a la directive RED (articles 3.1, 3.2, 3.3), un produit commercialise aux Etats-Unis doit etre conforme a FCC Part 15. Aucune de ces obligations n'est levee par la certification OCF. Symetriquement, un produit OCF qui n'a pas sa conformite radio ne peut pas etre mis sur le marche, meme 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 necessaire pour l'usage du logo Bluetooth, en plus de la certification OCF. Voir le glossaire des certifications pour la definition des termes ICAID, OBT, ACL2, Resource Type, PAA et DAC.

Sur les premieres soumissions OCF et sur les projets qui supposent un statut DLNA actif, les non-conformites suivantes reviennent regulierement:

  • Supposer que DLNA est encore activement certifie. Aucune nouvelle certification DLNA n'est emise depuis 2017. Concevoir un produit en pretendant 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 decision precoce 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 etre provisionne en usine de maniere securisee, avec une cle privee 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 perimetre, OCF reste pertinent.
  • Confondre ICAID OCF et PAA Matter. Les deux jouent un role analogue de racine d'identite, mais ce sont deux PKI distinctes, gerees 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 reglementaire (RED, FCC, RCM, etc.) ni d'aucune certification d'ecosysteme radio (Wi-Fi Alliance, Bluetooth SIG, Thread Group). Voir les guides dedies pour chacun de ces regimes.
  • Mauvaise lecture du logo sur produit ancien. Un equipement neuf vendu en 2026 avec un logo DLNA Certified visible est typiquement un produit dont la conception remonte a une fenetre ou la certification etait encore active. Cela ne dit rien de la pertinence du logo en 2026 du point de vue marketing ou interop.

Pour un fabricant qui demarre un projet IoT ou media en 2026, le decoupage decisionnel se resume ainsi:

  1. Smart home grand public, produit domestique standard: cibler Matter, traiter OCF comme complementaire au plus, ignorer DLNA.
  2. Smart building professionnel ou industrial IoT: OCF reste pertinent, choisir tot le Security Profile, traiter Matter comme hors-perimetre.
  3. Media streaming domestique: ni DLNA ni OCF en premier lieu, regarder les ecosystemes proprietaires (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 evaluer selon la roadmap du produit.

Dans tous les cas, la conformite radio reglementaire (CE/RED en Europe, FCC aux Etats-Unis, plus les regimes nationaux equivalents) reste obligatoire et independante de tout programme d'interoperabilite applicative.

Sources & références

  1. Open Connectivity Foundation , Open Connectivity Foundation openconnectivity.org/
  2. OCF specifications 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 specifications 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/