journalisation des modems Mo avec DSS
Remarque
Si vous envisagez de prendre en charge MBIM_CID_MODEM_LOGGING_CONFIGvotre modem, veuillez fournir des commentaires sur cette page afin que nous puissions vous aider le mieux. Ce CID est actuellement expérimental et n’a pas encore été testé avec un modem, car aucun ne le prend en charge.
Cette rubrique décrit une nouvelle interface de journalisation windows mobile standard (Mo B) via les extensions Microsoft vers la spécification USB Mo IM 1.0, disponible dans Windows 10, version 1903 et ultérieure.
Avec cette nouvelle interface de journalisation, le système d’exploitation peut informer l’appareil Mo B de démarrer, d’arrêter et de vider les journaux sur le système de fichiers du système d’exploitation via les commandes CID Mo IM. Étant donné la nature non IP de la charge utile de journalisation du modem, le canal de données utilisé par le service Mo B pour transmettre des charges utiles de journalisation au système d’exploitation utilise le flux de service de données Mo B (DSS). DSS est défini dans la spécification du modèle d’interface haut débit mobile (Mo IM) 1.0.
Le système d’exploitation extrait les fonctionnalités et configurations de diagnostic du modem dans l’ensemble de l’écosystème Mo B avec un ensemble de configurations de journalisation Mo B spécifiques à Windows. Ces configurations de journalisation Mo B permettent au fournisseur d’un modem de mapper les exigences de journalisation du système d’exploitation Mo B aux configurations de journalisation internes appropriées. Les configurations de journalisation abstraites et définies par le système d’exploitation incluent les niveaux de détail de journalisation Mo B et la durée de vidage maximale.
Un modem continue de remplir sa mémoire tampon de journalisation, jusqu’à ce que le segment soit rempli et que l’infrastructure Mo IM transmet le segment au système d’exploitation ou qu’il vide le contenu de sa mémoire tampon lorsque la durée de vidage maximale est atteinte (même si le segment n’est pas rempli). Le système d’exploitation définit un ensemble de niveaux de configuration de journalisation Windows Mo B standard, décrits plus loin dans cette rubrique. Chaque niveau de configuration spécifie une abstraction du système d’exploitation des détails de journalisation Mo B et des verbes.
L’abstraction du système d’exploitation des niveaux de configuration Mo B est mappée à la configuration de modem interne appropriée par les modems. Le système d’exploitation ne fournit aucune charge utile de configuration supplémentaire, comme les filtres de journalisation ou les masques, aux modems autres que le niveau de configuration du système d’exploitation Mo B.
Pour les modems qui prennent en charge la journalisation Mo B, tous les niveaux de configuration de journalisation Mo B à l’exception de Mo IMLoggingLevelOem doivent être présents sur toutes les variantes BSP. En d’autres termes, l’IHV ou l’OEM doit prendre en charge les niveaux PROD ou LAB de la journalisation Mo B dans les versions de production et R&D du BSP. Les niveaux lab de la journalisation Mo B ne peuvent être désactivés qu’à partir du système d’exploitation.
Cette nouvelle interface de journalisation utilise le canal de contrôle pour définir les paramètres de journalisation et utilise le canal de données pour recevoir les journaux de modem, car le canal de données est conçu pour transférer des données de modem en bloc. L’avantage de cette conception est que les données en bloc n’ont pas besoin d’être transférées sur le canal de contrôle, ce qui permet de maintenir la cohérence des performances des appareils. Il s’adapte également bien pour un débit plus élevé. Le canal de données est géré par des commandes DSS. Un exemple de flux pour un modem peut ressembler à ceci :
- Le système d’exploitation envoie la Mo IM_CID_MODEM_LOGGING_CONFIG CID au modem pour configurer des paramètres de journalisation tels que MaxSegmentSize, MaxFlushTime et LoggingLevel.
- Une fois que le système d’exploitation reçoit une réponse réussie du modem, il envoie la commande Mo IM_CID_DSS_CONNECT DSS au modem avec un GUID spécifique pour la journalisation des modems, l’état Mo IMDssLinkActivate et un ID de session DSS unique.
- Une fois qu’il reçoit un code d’état de réussite, le système d’exploitation se prépare à recevoir des fragments du modem. Ces fragments sont appelés paquets DataServiceSessionRead.
- Les paquets DataServiceSessionRead continuent d’arriver jusqu’à ce que le système d’exploitation émet une autre commande Mo IM_CID_DSS_CONNECT avec le même ID de session DSS et un état Mo IMDSLinkDeactivate.
Une fois que le modem écrit tous les journaux dans le canal de données nouvellement créé, le modem appelle MbbDeviceReceiveDeviceServiceSessionData, les données disponibles pour les applications via la couche WinRT : MobileBroadbandDeviceService. Les journaux de modem doivent être mis en forme en tant que données de chaîne imprimables qui peuvent être redirigées vers une session ETW.
Chemin des données de journalisation du modem
La journalisation des modems utilise le flux de service de données Mo IM (DSS) pour transférer les données pour la journalisation des charges utiles. Pour plus d’informations sur DSS, consultez la section 10.5.38 de la spécification Mo IM 1.0.
Lors de la connexion ou de la déconnexion de DSS, le GUID suivant est utilisé pour la journalisation des modems :
| GUID | Valeur |
|---|---|
| ModemFileTransfer GUID | 0EBB1CEB-AF2D-484D-8DF3-53BC51FD162C |
Le diagramme de flux suivant illustre le processus d’installation et de destruction de DSS.
Extension d’interface NDIS
L’OID suivant a été défini dans Windows 10 version 1903 pour prendre en charge la journalisation des modems.
Mo IM et valeurs CID
| Nom du service | UUID | Valeur UUID |
|---|---|---|
| Extensions d’Connecter ivity IP de base Microsoft | UUID_BASIC_CONNECT_EXTENSIONS | 3d01dcc5-fef5-4d05-9d3a-bef7058e9aaf |
Le tableau suivant spécifie le code UUID et le code de commande pour chaque CID, ainsi que si le CID prend en charge les requêtes Set, Query ou Event (notification). Consultez la section individuelle de chaque CID dans cette rubrique pour plus d’informations sur ses paramètres, structures de données et notifications.
| CID | UUID | Code de commande | Définissez | Requête | Notifier |
|---|---|---|---|---|---|
| Mo IM_CID_MODEM_LOGGING_CONFIG | UUID_BASIC_CONNECT_EXTENSIONS | À définir | A | O | A |
Mo IM_CID_MODEM_LOGGING_CONFIG
Ce CID est utilisé pour configurer les journaux collectés par le modem et la fréquence à laquelle ils seront envoyés du modem à l’hôte via DSS. La journalisation doit être configurée avant le démarrage d’une session de journalisation. Étant donné que ce CID fait partie des extensions de connexion, il est facultatif pour les IHD de prendre en charge ce CID. Si un IHV prend en charge la journalisation des modems via le canal de données DSS, il doit spécifier cette fonctionnalité. La fonctionnalité peut être annoncée à l’aide de l’Mo IM_BASIC_CID_DEVICE_SERVICES CID.
Paramètres
| Opération | Définissez | Requête | Notification |
|---|---|---|---|
| Commande | Mo IM_MODEM_LOGGING_CONFIG | Non applicable | Non applicable |
| Response | Mo IM_MODEM_LOGGING_CONFIG | Mo IM_MODEM_LOGGING_CONFIG | Mo IM_MODEM_LOGGING_CONFIG |
Requête
Interroge la configuration actuelle de journalisation du modem. Le fichier InformationBuffer de Mo IM_COMMAND_MSG n’est pas utilisé. La structure Mo IM_MODEM_LOGGING_CONFIG suivante est utilisée dans le fichier InformationBuffer de Mo IM_COMMAND_DONE.
Mo IM_MODEM_LOGGING_CONFIG
| Décalage | Size | Champ | Type | Description |
|---|---|---|---|---|
| 0 | 4 | Version | UINT32 | Numéro de version de cette structure. Ce champ doit être défini sur 1 pour la version 1 de cette structure. |
| 4 | 4 | MaxSegmentSize | UINT32 | Spécifie la taille du segment, en kilo-octets, pour chaque fragment envoyé par le modem. Si la taille maximale de fragment prise en charge par le modem pour la commande Device Service dépasse le jeu de valeurs, cette valeur est définie sur la taille maximale du segment pris en charge. |
| 8 | 4 | MaxFlushTime | UINT32 | Temps, en millisecondes, indiquant la durée maximale d’attente du modem avant d’envoyer un fragment de journal. Si les journaux collectés n’atteignent pas MaxSegmentSize dans la durée MaxFlushTime depuis le dernier fragment de journal envoyé, un fragment de journal est envoyé indépendamment de sa taille. S’il n’existe aucune donnée de journalisation, aucune notification n’est envoyée. Si l’appareil ne peut pas gérer les temps de vidage plus petits, l’appareil retourne le temps qu’il peut gérer dans la réponse. La réponse à une requête ou à un jeu contient le MaxFlushTime actuellement configuré. |
| 12 | 4 | LevelConfig | Mo IM_LOGGING_LEVEL_CONFIG | Configure le niveau pour lequel les journaux sont collectés. La réponse à une requête ou à un jeu contient le LevelConfig actuellement configuré. |
Remarque
Si le modem n’est pas en mesure de fournir des données de journal au système d’exploitation au niveau du système d’exploitation demandé maxSegmentSize et MaxFlushTimer, il peut choisir ses propres valeurs pour ces paramètres et mettre à jour le système d’exploitation en tant que réponse définie ou événement non sollicité. Le comportement du système d’exploitation ne change pas si MaxSegmentSize ou MaxFlushTimer change, car il reçoit les paquets de données indépendamment et les vide dans un fichier.
L’énumération Mo IM_LOGGING_LEVEL_CONFIG suivante est utilisée dans la structure Mo IM_MODEM_LOGGING_CONFIG précédente.
| Type | Value | Description |
|---|---|---|
| Mo IMLoggingLevelProd | 0 | Destiné à la collecte de données de télémétrie à partir d’une population commerciale ou de production. Le journal résultant doit être dimensionné par capsule et contient un modem clé ou des informations d’état ou d’échec Mo B uniquement. |
| Mo IMLoggingLevelLabVerbose | 1 | Destiné au développement de produits Mo B avec une maturité faible. Capture détaillée de pile complète des modems. La capture de modem résultante doit permettre à l’IHV de relire et de récupérer entièrement la capture pendant le journal. |
| Mo IMLoggingLevelLabMedium | 2 | Destiné à la vérification et au test sur le terrain des produits Mo B avec maturité et stabilité relatives. Le niveau de détail et de détail fournit suffisamment de points de données pour les ingénieurs IHV afin de trier la plupart des défaillances Mo B. |
| Mo IMLoggingLevelLabLow | 3 | Destiné à la journalisation au niveau de l’hôte automatique. Capture au niveau résumé des modems de capture de pile complète. Permet une compréhension en surbrillance de l’état et des interactions du système d’exploitation du modem. |
| Mo IMLoggingLevelOem | 4 | Réservé à l’utilisation interne oem et IHV. |
Définissez
Une commande set est utilisée pour configurer le niveau, la taille du segment et le temps de vidage maximal pour la journalisation des modems. Une structure Mo IM_MODEM_LOGGING_CONFIG est utilisée dans InformationBuffer.
Response
InformationBuffer dans Mo IM_COMMAND_DONE contient une structure Mo IM_MODEM_LOGGING_CONFIG.
Événements non sollicités
Les événements non sollicités sont pris en charge pour les scénarios où le modem doit informer le système d’exploitation des modifications internes. Actuellement, dans Windows 10 version 1903, ces scénarios ne se produisent pas.
Codes d’état
Ce CID utilise uniquement les codes d’état génériques définis dans la section 9.4.5 de la révision de spécification Mo IM 1.0.
Comportement de session DSS pendant l’inactivité
Le tableau suivant décrit le comportement de la session DSS pendant différentes étapes d’inactivité :
| Scénario | État de session DSS |
|---|---|
| Veille système, veille du modem uniquement, réinitialisation et récupération | Session DSS ouverte |
| Arrêt du système, redémarrage, mise en veille prolongée | Session DSS fermée |
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour