Opérations de contexte provisionnées MB

L’approvisionnement est essentiel pour les appareils mobiles connectés, car chaque opérateur mobile a des configurations APN différentes pour son réseau. Les configurations APN peuvent généralement être divisées en deux catégories :

1. Configurations APN connues du système d’exploitation, car il existe des applications ou des clients au-dessus du système d’exploitation qui nécessitent ces connexions.
2. Configurations APN qui ne sont pas connues du système d’exploitation, car elles sont consommées en interne par le modem pour les connexions qui ne sont pas exploitées par le système d’exploitation et ses clients.

Dans l’idéal, le modem ne doit stocker que les configurations APN que le système d’exploitation n’a pas à connaître. Toutefois, les partenaires IHV et OEM ont traditionnellement fourni les APN Internet et Achat, configurations reconnues par le système d’exploitation, dans le modem également. Avant la version 1703 de Windows 10, Windows ne lisait que les configurations Internet et les configurations APN d'achat à partir du modem pour établir des connexions Internet. À compter de Windows 10, version 1703, il peut y avoir des cas supplémentaires dans lesquels la configuration APN du modem doit être gérée par Windows, en particulier s’il existe des clients dans le système d’exploitation, tels que les paramètres utilisateur ou les OMA-DM qui souhaitent modifier la configuration cellulaire. Cela peut également affecter la configuration APN du modem. Par exemple, il peut y avoir une pile IMS dans le modem qui utilise l’APN IMS pour SMS via IMS. En règle générale, ces connexions ne sont pas exposées au système d’exploitation, mais dans certains scénarios, la configuration APN IMS peut être modifiée. Cette modification peut être effectuée via le système d’exploitation. Pour prendre en charge cela, à compter de Windows 10, version 1703, le système d’exploitation peut configurer différents types d’API dans le modem.

Le forum USB MBIM 1.0 et Microsoft NDIS ont chacun un CID et un OID existants pour permettre au système d’exploitation de définir et d’interroger les configurations APN dans le modem. Pour MBIM 1.0, il effectue cette opération via MBIM_CID_PROVISIONED_CONTEXT tandis que pour NDIS, il le fait via OID_WWAN_PROVISIONED_CONTEXTS. Toutefois, le CID et l’OID existants n’ont pas été conçus avec des instructions claires sur le comportement du modem dans différentes situations telles qu’un cycle d’alimentation ou un échange SIM. Les appareils qui souhaitent prendre en charge la configuration et la mise à jour du système d’exploitation des contextes approvisionnés par modem à l’avenir devront implémenter la version la plus récente du CID et de l’OID dans Windows 10, version 1703. Pour garantir la compatibilité descendante, pour les IHVS/OEM qui souhaitent prendre en charge de nouveaux matériels sur les versions du système d’exploitation antérieures à 1703, ils devront continuer à prendre en charge les MBIM_CID_PROVISIONED_CONTEXT et les OID_WWAN_PROVISIONED_CONTEXTS existants. À partir de Windows 10, version 1703, si l’appareil prend en charge la nouvelle version du CID et de l’OID, le système d’exploitation utilise uniquement la version la plus récente de la commande pour interroger et définir la configuration du contexte APN dans le modem.

Mise à jour de l'interface MB pour les opérations de contexte provisionnées

Bien que MBIM ait une commande permettant de récupérer et de remplacer les contextes stockés dans le modem, il n’a pas de champ pour « désactiver » ou « activer » un profil. Par conséquent, la MBIM_CID_PROVISIONED_CONTEXT existante doit être mise à jour pour Windows 10, version 1703 pour inclure cette fonctionnalité. Étant donné que MBIM n’a pas de mécanisme de contrôle de version, un nouveau CID propriétaire MSFT est défini comme MBIM_CID_MS_PROVISIONED_CONTEXT_V2.

Nom du service = Extensions de connexion de base

UUID = UUID_BASIC_CONNECT_EXTENSIONS

Valeur UUID = 3d01dcc5-fef5-4d05-0d3abef7058e9aaf

MBIM_CID_MS_PROVISIONED_CONTEXT_V2

Descriptif

Bien que MBIM 1.0 ait défini MBIM_CID_PROVISIONED_CONTEXT pour le système d’exploitation et ses clients supérieurs afin de gérer les contextes provisionnés dans le modem, Windows interroge traditionnellement uniquement le contexte dans le modem, mais ne l’a pas défini à partir du système d’exploitation. À compter de Windows 10, version 1703, il est nécessaire que le système d’exploitation puisse configurer les contextes dans le modem. Par exemple, s’il existe une pile IMS dans le modem opaque au système d’exploitation, le système d’exploitation doit être en mesure de spécifier l’APN IMS que le modem doit utiliser. Étant donné que chaque modem IHV peut avoir son propre moyen propriétaire de stocker des contextes dans le modem, il est impossible pour le système d’exploitation de gérer les profils au niveau ContextId de la façon MBIM_CID_PROVISIONED_CONTEXT peut suggérer. Au lieu de cela, du point de vue du système d’exploitation, il est plus important de prescrire le contexte à utiliser pour chaque type de contexte. Retour à l’exemple IMS, quel que soit le nombre de contextes provisionnés existants dans le modem, si le système d’exploitation définit un contexte qui a MBIM_CONTEXT_TYPE = IMS, tout le trafic IMS initié par le modem ne doit être tenté que sur ce contexte.

MBIM 1.0 spécifie que MBIM_CID_PROVISIONED_CONTEXT ne peut appeler la requête que sur les contextes qui correspondent à l’ID du fournisseur (paire MCC/MNC) de la carte SIM insérée. Pour les requêtes de configuration, MBIM_CID_PROVISIONED_CONTEXT peut spécifier l’ID de fournisseur du contexte qu’il souhaite stocker. MBIM_CID_MS_PROVISIONED_CONTEXT_V2 spécifie un comportement similaire mais différent de MBIM 1.0. Pour chaque requête, le système d’exploitation continue de s’attendre à ce que le modem retourne uniquement des contextes qui correspondent à l’ID du fournisseur de la carte SIM insérée. Pour Set, la commande n’autorise plus le système d’exploitation à définir des contextes qui ne correspondent pas à l’ID de fournisseur actuel dans la carte SIM. Il est prévu que la demande Set crée un contexte pour l’ID de fournisseur actuel de la carte SIM présentée. Par exemple, l’utilisateur passe de SIM 1 à SIM 2, puis revient à SIM 1. Il est prévu que lors du premier échange SIM, le modem doit résoudre tous ses contextes avant de charger le contexte pour SIM 2. Lorsque l’utilisateur bascule vers SIM 1, la configuration par défaut usine de SIM 1 doit être restaurée. Il n’est pas prévu que le modem enregistre la configuration du runtime sur les permutations SIM.

Le diagramme suivant illustre un exemple de flux pour lequel un utilisateur passe d’un SIM à un autre, puis revient au premier.

Les oem et les IHD qui ont préconfiguré le modem doivent conserver la configuration d’usine d’origine si le système d’exploitation ou l’utilisateur souhaite restaurer les paramètres de contexte dans le modem aux paramètres d’origine. Seuls les contextes d'origine de l'identifiant du fournisseur pour la carte SIM actuellement insérée doivent être restaurés. Les contextes préconfigurés des paramètres d'usine d'origine ne doivent jamais être remplacés par la configuration du système d'exploitation. Le diagramme suivant est un exemple de flux pour lequel un utilisateur choisit de restaurer les paramètres d’usine :

Il est prévu que le modem échoue aux requêtes de consultation ou de configuration lorsque la carte SIM est manquante, verrouillée, ou lorsque l'ID du fournisseur est inaccessible. Le modem ne doit avoir qu’un seul contexte par CONTEXT_TYPE par ID de fournisseur. Si l’IHV ou l’OEM décide de préconfigurer les contextes de modem dans le modem, il est important de s’assurer que les contextes sont configurés correctement pour chaque fournisseur pour lequel il choisit de le faire. Dans le cas où la carte SIM insérée n’a pas de contexte préconfiguré IHV, le modem ne doit pas avoir de contextes sans configuration du système d’exploitation. Les IHD et les OEM doivent s’assurer que MBIM_MS_CONTEXT_SOURCE = MbimMsContextSourceModemProvisioned afin que le système d’exploitation utilise le contexte du modem pour la connexion, s’il existe, et ne le remplace pas à partir de la base de données APN de Windows.

La façon dont le modem mappe le contexte et le présente à travers le MBIM_CID_PROVISIONED_CONTEXT existant dépend de chaque IHV et est hors du cadre de cette documentation.

La nouvelle commande MBIM_CID_MS_PROVISONED_CONTEXT_V2 est presque identique à la commande MBIM_CID_PROVISIONED_CONTEXT existante de MBIM 1.0, mais avec plusieurs ajouts. Le premier fournit au système d’exploitation la possibilité d’activer ou de désactiver le contexte associé à un type de contexte dans le modem. Lorsque le contexte est désactivé dans le modem, le modem est censé ne pas utiliser le contexte stocké pour toute connexion avec le réseau, même ceux qui ne sont pas informés du système d’exploitation. Si le système d’exploitation demande une connexion correspondant à un contexte désactivé dans le modem, le modem doit échouer immédiatement sans signaler au réseau. Le processus de correspondance doit prendre en compte tous les champs de la structure MBIM_MS_CONTEXT_V2.

La structure MBIM_CONTEXT_IP_TYPE de MBIM 1.0 est utilisée uniquement pour MBIM_CID_CONNECT. Dans MBIM_CID_MS_PROVISIONED_CONTEXT_V2, Microsoft a ajouté le type IP comme l’un des paramètres de chaque contexte. Le modem doit signaler MBIMContextIPTypeDefault s’il n’est pas configuré pour le contexte donné.

Dans Windows 10, version 1703, avec un nouveau matériel prenant en charge MBIM_CID_MS_PROVISIONED_CONTEXT_V2, le MBIM_CID_PROVISIONED_CONTEXT hérité ne sera pas utilisé à partir de composants internes. S’il existe d’autres composants client/système d’exploitation hérités qui envoient des MBIM_CID_PROVISIONED_CONTEXT, le modem est censé retourner des résultats comme il l’a fait dans les versions de Windows antérieures à Windows 10, version 1703.

Requête

MBIM_MS_PROVISIONED_CONTEXTS_INFO est retourné à la fois par requête et par les messages de complétion de Set dans InformationBuffer.

Pour la requête, InformationBuffer a la valeur Null.

Définissez

Pour Set, InformationBuffer contient une structure MBIM_MS_SET_PROVISIONED_CONTEXT_V2. Dans l’opération Set, étant donné que chaque modem IHV peut avoir des moyens propriétaires de gérer le stockage de contexte, le système d’exploitation ne spécifie plus le champ ContextId et s’attend à ce que le modem mappe les contextes à l’emplacement approprié. Lorsque le système d’exploitation définit des contextes, il s’attend à ce que le modem l’utilise pour toutes les connexions qui correspondent à la MBIM_CONTEXT_TYPE du contexte donné. Si le MBIM_CONTEXT_TYPE n’est pas reconnu par le modem, il doit toujours le stocker même s’il ne peut pas se connecter avec lui.

Événement non sollicité

Event InformationBuffer contient une structure MBIM_MS_PROVISIONED_CONTEXTS_INFO_V2. Dans certains cas, la liste des contextes provisionnés est mise à jour par le réseau soit par Over-The-Air (OTA), soit par le Service de Messages Courts (SMS) sans passer par la commande MBIM_CID_MS_PROVISIONED_CONTEXT_V2 du système d'exploitation. La fonction doit mettre à jour la liste des contextes provisionnés et des balises MBIM_MS_CONTEXT_SOURCE = MbimMsContextSourceOperatorProvisioned en conséquence. Après cela, les fonctions doivent informer l'hôte des mises à jour en utilisant cet événement avec la liste mise à jour.

Paramètres

Structures de données

Requête

InformationBuffer doit être NULL et InformationBufferLength doit être égal à zéro.

Définissez

La structure de données MBIM_SET_MS_PROVISIONED_CONTEXT_V2 suivante doit être utilisée dans InformationBuffer.

Les structures de données suivantes sont utilisées dans le tableau précédent.

MBIM_MS_CONTEXT_ROAMING_CONTROL spécifie la stratégie d’itinérance par contexte. Le système d’exploitation peut spécifier si le contexte donné peut être activé pendant l’itinérance ou non. Le modem ne doit pas activer automatiquement le contexte sans intervention du système d’exploitation si l’état d’itinérance ne répond pas aux conditions spécifiées. Dans les cas où le modem ne prend pas en charge les partenaires, toutes les configurations de partenaires doivent être traitées comme équivalentes à la maison.

MBIM_MS_CONTEXT_MEDIA_TYPE a été ajouté pour pouvoir spécifier si le contexte est utilisé pour les réseaux cellulaires ou iWLAN lorsque le déport Wi-Fi sera pris en charge dans les futures plateformes. Par exemple, si un contexte est défini comme cellulaire et que le modem effectue actuellement un déchargement vers Wi-Fi, il ne doit pas établir de connexion en utilisant ce contexte.

MBIM_MS_CONTEXT_ENABLE spécifie si un contexte est activé ou désactivé.

MBIM_MS_CONTEXT_SOURCE a été ajouté pour donner la visibilité du système d’exploitation sur la façon dont le contexte de modem a été créé. Cela permet au système d’exploitation de se comporter correctement après diverses situations telles que la réinitialisation d’usine, afin qu’il puisse savoir ce qui doit persister et ce qui doit être retourné à l’état par défaut en fonction des différentes exigences de l’opérateur.

MBIM_MS_CONTEXT_OPERATIONS spécifie les opérations que le système d’exploitation peut effectuer pour configurer des contextes dans le modem.

Le MBIM_CONTEXT_TYPES d’origine de MBIM 1.0 est toujours valide. Microsoft ajoute des types de contexte supplémentaires, car d’autres types de contextes ont été introduits depuis que MBIM 1.0 a été défini. Le tableau suivant définit les nouveaux types introduits. Les IMV et les OEM peuvent définir d’autres types de contexte propriétaires avec d’autres valeurs UUID uniques qui ne seront pas reconnaissables par le système d’exploitation à ses propres fins.

Réponse

La structure de MBIM_MS_PROVISIONED_CONTEXT_INFO_V2 suivante doit être utilisée dans InformationBuffer.

MBIM_MS_CONTEXT_V2, utilisé dans le tableau précédent, fournit des informations sur un contexte donné.

Notification

Pour plus d’informations, consultez la table MBIM_MS_PROVISIONED_CONTEXT_V2.

Codes de statut

Pour les opérations de requête et de définition :

Pour les opérations Set uniquement :

Initialisation des dispositifs avec un contexte provisionné

Initialisation d’un appareil GPRS sans verrouillage SIM avec un contexte configuré

Le diagramme suivant représente l’expérience utilisateur optimale pour les appareils MO basés sur GSM. L’expérience prête à l’emploi ne nécessite aucune configuration utilisateur. Il est présumé que l'appareil est configuré pour le choix automatique du réseau auquel s'enregistrer. Les étiquettes en gras représentent les identificateurs OID ou le contrôle de flux transactionnel. Les étiquettes dans le texte normal représentent les indicateurs importants dans la structure OID.

Pour initialiser un appareil GSM non verrouillé par SIM, implémentez les étapes suivantes :

1. Le service MB envoie une requête asynchrone (non bloquante) OID_WWAN_READY_INFO au pilote miniport pour identifier l'état de préparation de l'appareil. Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a bien reçu la demande et qu'il enverra ultérieurement une notification avec les informations demandées.

2. Le pilote miniport envoie une notification NDIS_STATUS_WWAN_READY_INFO au service MB qui indique au service MB que l’état de l’appareil MB est WwanReadyStateInitialized.

3. Le service MB envoie une requête asynchrone (non bloquante) OID_WWAN_REGISTER_STATE au pilote miniport pour identifier l'état d'enregistrement de l'appareil. Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a bien reçu la demande et qu'il enverra ultérieurement une notification avec les informations demandées.

4. Le pilote miniport envoie une notification NDIS_STATUS_WWAN_REGISTER_STATE au service MB qui indique que le mode d’inscription de l’appareil est WwanRegistraterModeAutomatic et que son état d’inscription actuel est WwanRegisterStateSearching.

5. Plus tard, lorsque l’appareil est inscrit auprès d’un fournisseur de réseau, le pilote miniport envoie une notification NDIS_STATUS_WWAN_REGISTER_STATE non sollicitée au service MB qui indique que l’état d’inscription actuel de l’appareil est WwanRegisterStateHome.

6. L’appareil tente de se connecter au service de paquets. Lorsque l'état du service de paquets passe à l'état attaché, le pilote miniport envoie une notification NDIS_STATUS_WWAN_PACKET_SERVICE non sollicitée au MB Service, indiquant que le service de paquets est attaché et que la classe de données actuelle est WWAN_DATA_CLASS_GPRS.

7. Le MB Service envoie une requête asynchrone (non bloquante) OID_WWAN_HOME_PROVIDER au pilote miniport pour récupérer les informations du fournisseur principal. Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) indiquant qu'il a reçu la demande et qu'il enverra une notification avec les informations demandées à l’avenir.

8. Le pilote miniport envoie une notification NDIS_STATUS_WWAN_HOME_PROVIDER au service de bande large mobile qui indique les détails du fournisseur de réseau principal.

9. Le service MB envoie une requête asynchrone (non bloquante) OID_WWAN_PROVISIONED_CONTEXTS au pilote miniport pour récupérer la liste des contextes provisionnés. Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a bien reçu la demande et qu'il enverra ultérieurement une notification avec les informations demandées.

10. Le pilote miniport envoie une notification NDIS_STATUS_WWAN_PROVISIONED_CONTEXTS au Service MB, laquelle contient une liste de structures WWAN_CONTEXT.

11. Le service MB envoie une requête asynchrone (non bloquante) OID_WWAN_CONNECT au pilote miniport pour activer le contexte PDP (Packet Data Protocol). Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a bien reçu la demande et qu'il enverra ultérieurement une notification avec les informations demandées.

12. Le pilote miniport envoie une notification NDIS_STATUS_WWAN_CONTEXT_STATE au service MB qui indique que le contexte PDP est activé.

13. Le pilote miniport envoie une notification NDIS_STATUS_LINK_STATE pour indiquer que l’état de connexion multimédia est MediaConnectStateConnected.

Initialisation d’un périphérique de paquet CDMA avec un contexte provisionné

Le diagramme suivant illustre l’expérience utilisateur optimale pour les appareils CDMA. L'expérience prête à l'emploi ne nécessite aucune configuration de la part de l'utilisateur. Ce scénario suppose que le compte CDMA n’a pas été activé. Contrairement aux appareils GSM, un appareil CDMA démarre automatiquement l’inscription auprès du réseau une fois l’activation terminée. Les étiquettes en gras sont des identificateurs OID ou un contrôle de flux transactionnel. Les étiquettes dans le texte normal sont les indicateurs importants dans la structure OID.

Pour initialiser un périphérique de paquets basé sur CDMA avec un contexte provisionné, implémentez les étapes suivantes :

1. Le service MB envoie au pilote de miniport une OID_WWAN_READY_INFO asynchrone (non bloquante). Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a reçu la demande et qu'il enverra une notification avec les informations demandées ultérieurement.

2. Le pilote miniport envoie NDIS_STATUS_WWAN_FAILURE au MB Service.

3. Le service MB envoie une OID_WWAN_SERVICE_ACTIVATION asynchrone (non-bloquante) au pilote miniport. Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a reçu la demande et qu'il enverra une notification avec les informations demandées ultérieurement.

4. Le pilote miniport envoie NDIS_STATUS_WWAN_SUCCESS au MB Service.

5. Le pilote miniport envoie NDIS_STATUS_WWAN_REGISTER_STATE au service MB.

6. Le pilote miniport envoie NDIS_STATUS_WWAN_REGISTER_STATE au MB Service.

7. Le pilote miniport envoie NDIS_STATUS_WWAN_PACKET_SERVICE au service MB.

8. Le MB Service envoie une commande OID_WWAN_HOME_PROVIDER asynchrone (non-bloquante) au pilote miniport. Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a reçu la demande et qu'il enverra une notification avec les informations demandées ultérieurement.

9. Le pilote miniport envoie NDIS_STATUS_WWAN_SUCCESS au MB Service.

10. Le service MB envoie un OID_WWAN_PROVISIONED_CONTEXTS asynchrone (non-bloquant) au pilote miniport. Le pilote miniport répond par un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) indiquant qu'il a reçu la demande et qu'une notification contenant les informations demandées sera envoyée ultérieurement.

11. Le pilote miniport envoie NDIS_STATUS_WWAN_SUCCESS au MB Service.

12. Le service MB envoie un OID_WWAN_PROVISIONED_CONTEXTS de manière asynchrone (non bloquante) au pilote miniport. Le pilote miniport répond avec un accusé de réception provisoire (NDIS_STATUS_INDICATION_REQUIRED) qu’il a bien reçu la demande et qu'il enverra ultérieurement une notification avec les informations demandées.

13. Le pilote miniport envoie NDIS_STATUS_WWAN_SUCCESS au MB Service.

14. Le pilote miniport envoie NDIS_STATUS_LINK_STATE au service MB.

Voir aussi

Préparation de l’appareil MB