Documento del processo di gestione delle specifiche (SMPD)

Questo documento, indipendentemente dal titolo o dal contenuto, non è una Specifica Bluetooth soggetta alle licenze concesse da Bluetooth SIG Inc. ("Bluetooth SIG") e dai suoi membri ai sensi del Contratto di licenza di brevetto / copyright Bluetooth e del Contratto di licenza del marchio Bluetooth.

QUESTO DOCUMENTO VIENE FORNITO "COSÌ COM'È" E BLUETOOTH SIG, I SUOI MEMBRI E LE LORO AFFILIATE NON FORNISCONO ALCUNA DICHIARAZIONE O GARANZIA E NON RICONOSCONO ALCUNA GARANZIA, ESPLICITA O IMPLICITA, INCLUSA QUALSIASI GARANZIA DI COMMERCIABILITÀ, TITOLO, NON VIOLAZIONE DI PARTE, CHE IL CONTENUTO DI QUESTO DOCUMENTO È PRIVO DI ERRORI.

NELLA MISURA NON PROIBITA DALLA LEGGE, BLUETOOTH SIG, I SUOI MEMBRI E LE LORO AFFILIATE DECLINANO OGNI RESPONSABILITÀ DERIVANTE O RELATIVA ALL'UTILIZZO DI QUESTO DOCUMENTO E QUALSIASI INFORMAZIONE CONTENUTA IN QUESTO DOCUMENTO, INCLUSE LE PERDITE DI ENTRATE, PROFITTI, DATI O PROGRAMMI O INTERRUZIONE, O PER DANNI SPECIALI, INDIRETTI, CONSEQUENZIALI, ACCIDENTALI O PUNITIVI, TUTTAVIA CAUSATI E INDIPENDENTEMENTE DALLA TEORIA DELLA RESPONSABILITÀ, E ANCHE SE BLUETOOTH SIG, I SUOI MEMBRI O LE LORO AFFILIATE SIANO STATI INFORMATI DELLA POSSIBILITÀ DI TALI DANNI.

Questo documento è di proprietà di Bluetooth SIG. Questo documento può contenere o coprire argomenti che sono proprietà intellettuale di Bluetooth SIG e dei suoi membri. La fornitura di questo documento non concede alcuna licenza a nessuna proprietà intellettuale di Bluetooth SIG o dei suoi membri.

Il presente documento è soggetto a modifiche senza preavviso.

1. Introduzione

Il Documento del Processo di Gestione delle Specifiche (SMPD) descrive i processi che gli autori delle specifiche e rielaboranoviewGli utenti devono seguire per sviluppare nuove specifiche e migliorare le specifiche esistenti (ad esempio, aggiungere o rimuovere funzionalità o modificare funzionalità specifiche in una specifica adottata), mantenere le specifiche adottate e gestire la fine del ciclo di vita delle specifiche adottate. Inoltre, questo documento descrive il processo per creare, riviewing e l'approvazione dei white paper.

Vi sono differenze nel processo di sviluppo delle specifiche tra lo sviluppo di nuove specifiche e il miglioramento delle specifiche esistenti a causa delle differenze intrinseche nella portata di tali compiti; tali differenze sono evidenziate in questo documento.

Il processo di sviluppo delle specifiche include:

Una fase dei requisiti (descritta nella sezione 3) per definire i requisiti funzionali
Una fase di sviluppo (descritta nella sezione 4) per sviluppare e riview specifiche

Una fase di convalida (descritta nella sezione 5) per convalidare le specifiche mediante test del prototipo interoperabile (IOP)
Una fase di adozione / approvazione (descritta nella Sezione 6) per presentare le specifiche al Consiglio di amministrazione (CdA) di Bluetooth SIG per l'adozione / approvazione

Il documento Specification Errata Process (EPD) [3] descrive il processo per proporre e riviewerrata specificazione, e approvarli come correzioni Errata (come definito nello Statuto [2]) alle specifiche adottate. Se non diversamente specificato, tutti i riferimenti agli errata in questo SMPD significano errata di specifica.

1.1 Precedenza

Lo Statuto di Bluetooth SIG, Inc. (Statuto) e gli accordi di adesione [2] hanno la precedenza su qualsiasi contenuto in conflitto in tali documenti e nell'SMPD. Nonostante quanto contenuto in questo documento, il CdA conserva la massima discrezione e autorità di agire e prendere decisioni anche se tali azioni e decisioni non seguono, o sono in conflitto con, qualsiasi cosa in questo documento, e nulla in questo documento limita o limita l'autorità indipendente del CdA e discrezione.

In caso di conflitto tra il testo nell'SMPD e le figure, il testo ha la precedenza.

1.2 Gruppi e comitati referenziati

In questo documento si fa riferimento ai seguenti tipi di gruppi: gruppi di studio (SG), gruppi di esperti (EG) e gruppi di lavoro (WG). Un gruppo di lavoro può anche avere un sottogruppo che riferisce al gruppo di lavoro. Allo stesso modo, in questo documento si fa riferimento ai seguenti tipi di comitati: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI) e Bluetooth Qualification Review Consiglio (BQRB). Questo documento fa riferimento anche allo Staff tecnico Bluetooth SIG (BSTS) e al CdA.

1.3 Comitato reviewse approvazioni

Un comitato riview è un review che è condotto dai membri di un comitato (tipicamente 3 membri) per fornire feedback entro un tempo specificato (tipicamente 2-3 settimane), tuttavia il riview il tempo può variare a seconda della lunghezza e della complessità del materiale e di altre priorità all'interno del comitato. Il gruppo che chiede il review e il comitato che conduce il review ciascuno concordare la durata del review. Il gruppo e i membri del comitato utilizzano gli strumenti Bluetooth SIG per notificare e registrare l'inizio e la fine del review. Il gruppo elaborerà generalmente il feedback del comitato quando viene ricevuto. Quando il comitato riview scade il tempo, il gruppo completa l'indirizzamento del feedback del comitato e dovrebbe anche prendere in considerazione qualsiasi review feedback tenendo presente che il materiale potrà essere soggetto a successiva approvazione da parte della commissione.

L'approvazione del comitato si ottiene con il voto dei membri del comitato in conformità con il documento sul processo del gruppo di lavoro [4].

1.4 Avvisi ai membri e accessibilità dei materiali

Tutti gli avvisi forniti ai membri ai sensi del presente documento possono essere forniti tramite posta elettronica, come ad esempio un aggiornamento tecnico periodico. Le notifiche che devono essere fornite a tutti i membri verranno inviate a tutti i membri attivi (ad esempio, dove l'iscrizione non è stata sospesa, terminata o ritirata). Quando le notifiche vengono inviate tramite e-mail, verranno inviate all'ultimo indirizzo e-mail noto (come indicato nei record correnti di Bluetooth SIG) di ogni individuo che si è registrato con l'account di appartenenza dell'azienda membro e che non ha rinunciato a ricevere notifiche e-mail. Nulla in questo documento altera gli obblighi oi requisiti di Bluetooth SIG in relazione alla fornitura di avviso ai sensi dello Statuto o di qualsiasi altro accordo tra Bluetooth SIG e qualsiasi membro.

Ovunque questo documento si riferisca a a websito accessibile a tutti i membri, questo si riferisce all'accessibilità alle persone che hanno un account SIG Bluetooth attivo. I membri che non hanno un account attivo possono creare un account tramite Bluetooth SIG websito.

1.5 Modelli

Per ogni tipo di documento (ad es. specifiche, white paper, documenti di prova) a cui si fa riferimento in questo SMPD, Bluetooth SIG fornisce un modello. Il modello deve essere utilizzato come base per ogni documento prodotto in conformità con questo SMPD. Il mancato utilizzo del modello corretto può comportare la mancata approvazione del documento. I modelli sono disponibili sul Bluetooth SIG websito [8].

1.6 Tipi di specifiche

Esistono diversi tipi di specifiche Bluetooth SIG. Gerarchicamente, tutte le specifiche dipendono dalla Bluetooth Core Specification. Specifiche come il tradizionale profileS; protocolli tradizionali; e professionisti basati su GATTfiles, servizi basati su GATT e protocolli basati su GATT dipendono tutti dalle funzionalità all'interno della specifica principale. Altre specifiche, come le specifiche del modello Mesh, dipendono da Mesh Profile specifica che a sua volta dipende dalla specifica principale.

La specifica Core Specification Supplement (CSS) definisce i tipi di dati, i formati di dati e i profile e codici di errore del servizio che vengono utilizzati dalla specifica principale e da altre specifiche e non definiscono alcun comportamento.

La specifica GATT Specification Supplement (GSS) definisce i formati delle caratteristiche e dei descrittori utilizzati da Profiles e Servizi e non definisce alcun comportamento.
La specifica Mesh Device Properties (MDP) definisce le proprietà della mesh utilizzate da Mesh Profile e le specifiche del modello mesh e non definisce di per sé alcun comportamento.

2. Finitaview

Questa sezione fornisce una panoramicaview dei processi e non intende includere tutti i dettagli.

La Figura 2.1 mostra le sei fasi principali che compongono il processo di gestione delle specifiche.

Le prime quattro fasi si verificano durante il processo di sviluppo delle specifiche e consistono nella fase dei requisiti (sezione 3), nella fase di sviluppo (sezione 4), nella fase di convalida (sezione 5) e nella fase di adozione / approvazione (sezione 6). Seguono due fasi post-adozione: la fase di mantenimento delle specifiche (sezione 7) e la fase di fine vita delle specifiche (sezione 8).

La Figura 2.2 illustra i dettagli delle quattro fasi all'interno del processo di sviluppo delle specifiche. Le caselle grigie indicano i principali risultati finali per ciascuna fase. Le caselle arancioni riassumono le tappe del processo.

Nella fase dei requisiti (descritta nella sezione 3), una proposta per iniziare un nuovo lavoro (una nuova proposta di lavoro (NWP)) avvia il processo di sviluppo delle specifiche definendo gli scenari utente da abilitare se il nuovo lavoro procede. Se il NWP è approvato, un gruppo assegnato crea un documento dei requisiti funzionali (FRD). Una volta che l'FRD è stato approvato e assegnato a un gruppo, inizia la fase di sviluppo.

Durante la fase di sviluppo (descritta nella Sezione 4), lo sviluppo delle specifiche procede attraverso una sequenza di stages (0.5/DIPD a 0.9/CR) culminando in una bozza completa della specifica. La specifica 0.9/CR viene messa a disposizione di tutti i soci, quindi sottoposta al CdA che la valuta per approvazione. Una volta approvato, inizia la fase di convalida.

Durante la fase di convalida dello sviluppo della specifica (descritta nella sezione 5), la specifica 0.9/CR approvata dal CdA è messa a disposizione di tutti i membri per la riformulazione.view e convalidare, e membro Review è avviato. La convalida viene eseguita tramite test di interoperabilità (IOP) tra prototipi creati dai membri. Una volta che il test IOP è stato completato (se richiesto per la specifica) e BARB approva il rapporto del test IOP, inizia la fase di adozione/approvazione.

Durante la Fase di Adozione / Approvazione (descritta nella Sezione 6), vengono finalizzate le specifiche ed i relativi documenti di prova; Vengono ricevute le approvazioni BARB, BQRB e BTI; e il pacchetto di specifica finale viene presentato al CdA che considera la specifica per l'adozione (cioè l'approvazione finale).

Una specifica potrebbe dover tornare a una fase precedente o stage se vengono apportate modifiche significative. In alcuni casi, può anche essere possibile rinunciare a parte di una fase come descritto nella Sezione 4.4.

La fase di mantenimento delle specifiche (descritta nella Sezione 7) inizia dopo che una specifica è stata adottata dal CdA. Durante questa fase vengono segnalati e valutati potenziali errori riscontrati in una specifica adottata e (se necessario) vengono apportate correzioni errata alla specifica. La fase di mantenimento delle specifiche continua fino a quando la specifica non viene deprecata o ritirata (vedere Fase di fine vita delle specifiche nel paragrafo successivo).

La fase di fine vita delle specifiche (descritta nella sezione 8) descrive il processo di deprecazione e ritiro delle specifiche adottate.

3. Fase dei requisiti

La fase dei requisiti inizia con un NWP (che afferma il desiderio di iniziare il lavoro su uno o più scenari utente) o dopo la determinazione che il nuovo lavoro desiderato è già coperto dalla loro carta del WG. Se un gruppo di lavoro desidera iniziare un nuovo lavoro che ritiene sia già nell'ambito della sua carta del gruppo di lavoro, il gruppo di lavoro deve seguire il processo definito nella sezione 3.1 per procedere direttamente allo sviluppo di un FRD. Per tutti gli altri elementi di lavoro, il gruppo di lavoro deve seguire il processo definito nella sezione 3.2. L'FRD definisce l'ambito dei requisiti funzionali utilizzati per creare le specifiche nella fase di sviluppo. La fase Requisiti è illustrata nella Figura 3.1.

3.1 Nuovo lavoro coperto da una carta del gruppo di lavoro

Quando un gruppo di lavoro desidera iniziare un nuovo lavoro e ritiene ragionevolmente che la funzionalità che desidera aggiungere rientri già nell'ambito della sua carta del gruppo di lavoro, il gruppo di lavoro può iniziare a lavorare sull'FRD, a condizione che informi immediatamente BARB. Il gruppo di lavoro includerà nella sua notifica a BARB una descrizione del nuovo lavoro proposto e una copia della carta del gruppo di lavoro con la lingua evidenziata che li autorizza a iniziare il nuovo lavoro.

Se BARB rifiuta l'analisi del gruppo di lavoro, il gruppo di lavoro deve interrompere il lavoro sull'FRD e procedere con il processo NWP delineato nella sezione 3.2. Se BARB approva l'analisi del gruppo di lavoro, il gruppo di lavoro informerà immediatamente BSTS (via e-mail a specific.manager@bluetooth.com) e BSTS aggiungerà l'elemento al prossimo programma del CdA.

Il gruppo di lavoro includerà nella sua notifica a BSTS le stesse informazioni che ha fornito a BARB. Se il CdA rifiuta l'analisi del WG, il WG deve interrompere il lavoro sull'FRD e procedere con il processo NWP delineato nella Sezione 3.2. Se il CdA approva l'analisi del WG, il WG può continuare a lavorare sull'FRD come indicato nella Sezione 3.3.

3.2 Nuova proposta di lavoro (NWP)

Qualsiasi membro, WG, SG o EG può creare e inviare un NWP (tramite Bluetooth SIG websito [10]). Un NWP deve includere, come minimo, informazioni su quanto segue utilizzando il modello ufficiale fornito in [8]:

Scenari utente
Impegno dei membri a sviluppare il FRD e in quale/i area/e (ad es. Collaboratore, Autore, Reviewehm, prototipazione)

Proposta di leadership del lavoro FRD
Proposta di assegnazione di gruppo per il lavoro FRD
Indirizzo email degli autori principali

Nota: La guida al processo NWP è disponibile sul Bluetooth SIG websito [10].

BSTS eseguirà le seguenti attività durante lo sviluppo del NWP:

Fornire all'autore o agli autori un avviso di ricevimento (in genere entro sette giorni di calendario dal ricevimento) e delineare i passaggi successivi.

Se necessario, collaborare con l'autore o gli autori in modo che il NWP sia chiaro e completo. Ciò potrebbe richiedere diverse iterazioni del NWP.
Se la NWP contiene dichiarazioni su errori nelle specifiche Bluetooth adottate, collaborare con gli autori per file voci nel sistema di errata.
Se si nota che il NWP sta potenzialmente duplicando un lavoro che è già in corso o è già stato completato, avvisare l'autore o gli autori dell'altro lavoro per la loro valutazione.

Pubblica il NWP sul NWP websito accessibile a tutti i membri.
Comunica a tutti i membri che la NWP è disponibile per il riview e se è necessario un impegno aggiuntivo da parte dei membri per sviluppare la FRD.

I membri possono contattare l'autore o gli autori per porre domande o fornire feedback in merito al NWP.

Almeno tre aziende associate devono impegnarsi a partecipare al completamento dell'FRD risultante affinché il NWP diventi un candidato per l'approvazione del CdA, e almeno un'azienda membro deve essere un membro Associato o Promotore. Dopo l'approvazione del CdA del NWP, il CdA assegnerà il NWP a un sottogruppo del Gruppo di lavoro composto da tutti i membri esistente o SG per lavorare sul FRD (descritto nella Sezione 3.3). Se non esiste un sottogruppo WG o SG appropriato, è possibile crearne uno.

Per le NWP che hanno un impegno membro sufficiente, BSTS eseguirà le seguenti attività aggiuntive:

Almeno 13 giorni prima che il NWP venga proposto per essere approvato dal CdA, notificare a BARB, e al gruppo a cui il NWP è consigliato per l'assegnazione, l'approvazione in sospeso. Questo viene fatto per fornire un'opportunità di feedback in aree come il gruppo proposto, se il NWP è già coperto dal lavoro esistente, ecc.

Invia il NWP completato al CdA.

Se il NWP è presentato da membri non associati a un gruppo, fare in modo che uno dei membri presenti il NWP al CdA.
Se il NWP è presentato da un gruppo, fare in modo che il presidente del gruppo presenti il NWP al CdA.

Invitare alla riunione del CdA il presidente del BARB e i presidenti del gruppo a cui si consiglia l'assegnazione del NWP.
Se il NWP è approvato e assegnato dal CdA, avvisare il gruppo a cui è stato assegnato; gli autori); i membri identificati nel NWP come impegnati a sviluppare la FRD corrispondente; e se il NWP è proposto da un gruppo, il gruppo del risultato e le fasi successive.

Dopo che una NWP è stata approvata dal CdA, aggiornare lo stato sulla NWP websito.

Qualsiasi NWP può essere rifiutato dal CdA a sua discrezione, ad esample, a causa delle limitazioni delle risorse, se il lavoro è già completamente completato, il lavoro non rientra nell'ambito dei documenti governativi di Bluetooth SIG (ad esempio, l'Application Programming Interface (API)) [2], o se il lavoro proposto dovrebbe essere filed come erratum. Se il NWP viene rifiutato, BSTS notificherà l'autore(i), i membri identificati nel NWP come impegnati a sviluppare il corrispondente FRD e, se il NWP è proposto da un gruppo, il gruppo. La notifica includerà tutti i motivi del rifiuto. L'autore(i), i membri impegnati o il gruppo possono richiedere tempo all'ordine del giorno del CdA per appellarsi al rifiuto.

Se un membro o un gruppo desidera proporre la rimozione di una funzione da una specifica adottata, il gruppo o il membro deve preparare una NWP. Il NWP deve includere un'analisi dell'impatto che la rimozione avrà sulla compatibilità con le versioni precedenti e sull'interoperabilità, inclusa un'analisi dell'impatto sui casi di test.

Le NWP non sono necessarie per i miglioramenti alle specifiche CSS, GSS o MDP: in genere, gli aggiornamenti alle specifiche CSS, GSS o MDP derivano da aggiornamenti ad altre specifiche che hanno i propri NWP.

3.3 Documento sui requisiti funzionali (FRD)

Gli FRD definiscono i requisiti funzionali per abilitare gli scenari utente. Un FRD deve includere, come minimo, informazioni su quanto segue utilizzando il modello ufficiale fornito in [8]:

Scenari utente
Requisiti funzionali basati sugli scenari utente

Impegno dei membri a sviluppare le specifiche risultanti
Supporto prototipo opzionale da parte dei membri per i ruoli previsti
WG consigliato per sviluppare le specifiche risultanti

Sviluppo FRD

Gli FRD vengono creati dal sottogruppo WG a tutti i membri assegnato o dai membri SG con il supporto editoriale di BSTS. Qualsiasi membro interessato a partecipare allo sviluppo di FRD può unirsi al gruppo.

Gli FRD devono indicare un impegno da parte di almeno due (sebbene tre siano incoraggiate) aziende associate a livello di Associato o Promotore a partecipare allo sviluppo della specifica risultante. I gruppi di lavoro o le SG che presentano un FRD dovrebbero tentare di ottenere un ampio sostegno dalle società membri del gruppo che rappresentano il segmento industriale target previsto identificato nell'FRD.

La nuova funzionalità proposta in un FRD dovrebbe essere supportata sul maggior numero possibile di trasporti e dispositivi esistenti. Questo include, per esample, che supporta i pro basati su GATTfiles e servizi sia sul trasporto Basic Rate/Extended Data Rate (BR/EDR) che sul trasporto Bluetooth Low Energy (LE). Se la nuova funzionalità manca di un supporto membro sufficiente per un trasporto, ad esample a causa della mancanza di impegno dei membri nella definizione dell'uso del trasporto o di un numero potenzialmente insufficiente di piattaforme di test IOP per uno o più ruoli, il supporto su quel trasporto può essere escluso dal FRD.

Salvo diversa giustificazione, nuove funzionalità, profilese i servizi devono essere conformi ai requisiti di compatibilità con le versioni precedenti descritti nella Sezione 3.3.2.

Il WG o SG deve presentare il FRD a BARB per riview e approvazione. BARB deve approvare o rifiutare l'FRD in base al proprio giudizio ingegneristico. Se approvato da BARB, il FRD sarà reso disponibile a tutti i membri e la notifica della sua disponibilità sarà emessa da BSTS.

Gli FRD non sono necessari per i miglioramenti alle specifiche CSS, GSS o MDP: in genere, gli aggiornamenti alle specifiche CSS, GSS o MDP derivano da aggiornamenti ad altre specifiche che hanno i propri FRD.

Requisiti di compatibilità con le versioni precedenti

Compatibilità con le versioni precedenti per BR / EDR

Per il funzionamento BR / EDR, il requisito di compatibilità con le versioni precedenti è definito come interoperabilità con la parte BR / EDR della specifica Bluetooth Core v1.1 e successive.

Compatibilità con le versioni precedenti per Bluetooth Low Energy

Per il funzionamento LE, il requisito di compatibilità con le versioni precedenti è definito come l'interoperabilità con la parte LE della specifica Bluetooth Core v4.0 e successive.

Compatibilità con le versioni precedenti per specifiche diverse dalla specifica di base

Per le specifiche diverse dalla specifica Bluetooth Core, è necessario mantenere la compatibilità con le versioni precedenti di una determinata versione con tutte le versioni precedenti che hanno lo stesso numero di versione principale. Ad esempioample, la versione 1.3 deve essere compatibile con le versioni 1.2, 1.1 e 1.0, ma la versione 2.0 potrebbe non essere compatibile con le versioni 1.0, 1.1, 1.2 e 1.3. Si noti che un incremento al numero di versione principale della specifica principale non implica una mancanza di compatibilità con le versioni precedenti.

Esenzione dai requisiti di compatibilità con le versioni precedenti

Il WG o SG può proporre di esentare funzionalità specifiche dal requisito di compatibilità con le versioni precedenti se viene fornita una giustificazione. Ad esempioample, se si dimostra che la funzionalità ha bassi tassi di adozione sul mercato o, a causa di problemi di interoperabilità, è meglio rimuovere o sostituire la funzionalità piuttosto che modificarla. Il WG o SG deve includere eventuali esenzioni di retrocompatibilità nell'FRD, che sono approvate da BARB dopo l'approvazione dell'FRD. Eventuali esenzioni approvate da BARB saranno presentate al CdA per l'approvazione al 0.9/CR Stage.

3.4 Carta del gruppo di lavoro

Quando BARB approva un FRD che si propone di assegnare a un gruppo di lavoro esistente, quel gruppo di lavoro deve preparare una bozza di aggiornamento alla sua carta per aggiungere la nuova funzionalità allo scopo (a meno che il CdA non abbia precedentemente approvato l'analisi del gruppo di lavoro che un aggiornamento della carta del gruppo di lavoro è non richiesto). Tuttavia, quando BARB approva un FRD che si propone di assegnare a un nuovo WG, BARB e i membri interessati a sviluppare la funzionalità delineata nell'FRD devono preparare una bozza di carta per un nuovo WG con la nuova funzionalità inclusa nello scopo della charter .

Una volta che la nuova o aggiornata carta del gruppo di lavoro è stata preparata, deve essere presentata a BARB per la revisioneview e approvazione. Una volta che BARB avrà approvato la carta, la bozza della nuova o aggiornata carta del gruppo di lavoro sarà sottoposta all'approvazione del CdA.

Una volta che il CdA ha approvato lo statuto, il WG a cui il lavoro di sviluppo delle specifiche è stato assegnato dal CdA deve lavorare a stretto contatto con il gruppo che ha preparato l'FRD nel caso siano necessari eventuali aggiornamenti o chiarimenti a tale FRD. Se è necessario un aggiornamento FRD durante la fase di sviluppo, è necessario seguire i processi descritti nella sezione 3.3 e in questa sezione; tuttavia, lo sviluppo delle specifiche può avvenire in parallelo con gli aggiornamenti della carta FRD e WG.

3.5 Requisiti Requisiti per l'uscita dalla fase

La fase dei requisiti è completa e la fase di sviluppo inizia quando una carta del WG con lo scopo necessario per l'FRD è confermata o approvata dal CdA e sono stati soddisfatti i seguenti requisiti:

Il NWP è stato approvato dal CdA o il CdA ha convenuto che un NWP non è necessario.

La carta FRD e corrispondente WG è stata approvata da BARB.

4. Fase di sviluppo

Durante la fase di sviluppo, i gruppi di lavoro assegnati creano la nuova specifica e / o migliorano una specifica esistente. L'FRD definisce i requisiti della specifica Bluetooth nuova o migliorata. Nessuna funzionalità è consentita nella specifica che non sia ragionevolmente correlata ai requisiti dell'FRD. L'obiettivo è creare una specifica 0.9 / CR che sia pronta per la fase di convalida (descritta nella sezione 5) al termine della fase di sviluppo.
Durante la fase di sviluppo, una specifica (o miglioramento della specifica) avanza attraverso tre stages.

Per una nuova specifica, i tre stagsono:

0.5 annitage
0.7 annitage

0.9 annitage

Per un miglioramento delle specifiche, i tre stagsono:

Bozza di documento di proposta di miglioramento (DIPD) Stage

Documento di proposta di miglioramento finale (FIPD) Stage
Richiesta di modifica (CR) Stage

ogni stage è descritto ulteriormente nelle sottosezioni che seguono. La Figura 4.1 che segue illustra i vari documenti che il GL predisporrà ad ogni stage.

Figura 4.1: Oltreview della specifica stagche si verificano durante la fase di sviluppo

Il ruolo di BARB durante tutto il processo di sviluppo delle specifiche è fornire ai gruppi di lavoro consulenza e assistenza tecnica. I gruppi di lavoro possono, in qualsiasi momento, fare richieste a BARB per consulenza tecnica in merito allo sviluppo delle specifiche e ai concetti architettonici da utilizzare in una specifica. I gruppi di lavoro sono particolarmente incoraggiati a sollecitare un feedback precoce da BARB per le funzionalità che hanno considerazioni architettoniche più complesse.

4.1 0.5/DIPD Stage

Durante il 0.5/DIPD Stage, il GL svilupperà quanto segue utilizzando i modelli ufficiali forniti in [8]:

Per una nuova specifica, una bozza della specifica 0.5, che deve includere, come minimo, informazioni su quanto segue:

Architettura per coprire i requisiti come indicato nella FRD

Per i protocolli, punti di accesso al servizio definiti
Per servizi, dati esposti e comportamento
Per i professionistifiles, protocolli identificati e funzionalità specificate

2. Per un miglioramento delle specifiche, una bozza del DIPD, che deve includere, come minimo, informazioni su quanto segue:

Sfondo: Lo scopo del lavoro, gli obiettivi che guidano il lavoro e il modo in cui questa proposta specifica si inserisce nello scopo
Sopraview di proposta: Un riepilogo della funzionalità estesa (maggiore flessibilità, prestazioni migliorate, ecc.) Fornita dal DIPD, inclusa una chiara descrizione di come la nuova funzionalità si adatta alla versione della specifica corrente. Se il gruppo di lavoro ha valutato più proposte, queste dovrebbero essere incluse per consentire a BARB l'opportunità di determinare se è stata effettuata una due diligence sufficiente nella selezione della proposta preferita.

Copertura dei requisiti: Un riepilogo della copertura dei requisiti funzionali fornita dalla proposta, con riferimento ai requisiti di sistema appropriati e agli scenari di utilizzo forniti nell'FRD associato
Definizione del problema: Una dichiarazione dei problemi risolti dalle proposte
Criteri di selezione: Una dichiarazione riguardante i criteri di selezione / prestazione dalle metriche di valutazione associate che hanno guidato il processo di selezione

Giustificazione della scelta: Un esame delle metriche di valutazione che giustificano la scelta tra le proposte e rivelano compromessi
Descrizione: Una descrizione della funzionalità e dei protocolli estesi. Questa sezione può adattarsi a diverse esigenze aggiungendo sottosezioni pertinenti.

3. Strategia di test: Una descrizione della funzionalità proposta per essere testata (o non testata) come parte del Programma di qualificazione Bluetooth e come la funzionalità si propone di testare (ad es., aspettative sui tester inferiori o sui tester superiori), e se i test saranno attribuiti come test di conformità o di interoperabilità o una combinazione di entrambi). Questo può essere in un documento separato o in una sezione separata all'interno della specifica 0.5/DIPD. Le convenzioni da utilizzare in una strategia di test sono descritte in Strategia di test e terminologia Overview documento (TSTO) [5].

Il pubblico principale dei documenti in questo stage sono i membri del WG e BARB che review le proposte architettoniche e la copertura dei requisiti, e ITV che reviews la strategia di prova. Nella maggior parte dei casi, i documenti in questo stage non sono destinati a contenere testo che è previsto per l'inclusione nella specifica finale.

BSTS deve riview tutti i documenti per la coerenza con le linee guida di redazione Bluetooth [1] e identificare i problemi per il WG da affrontare. BARB deve rifareview la specifica 0.5/DIPD. Per un miglioramento delle specifiche, BARB deve anche riview il DIPD per la conformità ai requisiti di retrocompatibilità descritti nella Sezione 3.3.2. L'ITV deve riview la strategia di prova.

BARB deve approvare o rifiutare la specifica 0.5/DIPD in base al proprio giudizio tecnico. Se approvato da BARB, la specifica 0.5/DIPD sarà resa disponibile sul Bluetooth SIG websito a tutti i membri associati e promotori e la notifica della sua disponibilità sarà emessa da BSTS. A 0.5/DIPD Stage, non è richiesta l'approvazione della Strategia di test.
Il 0.5/DIPD Stage non è richiesto per miglioramenti alle specifiche CSS, GSS o MDP

0.5/DIPD Stage requisiti di uscita

Il 0.5/DIPD Stage è completo e 0.7/FIPD Stage inizia quando sono soddisfatti i seguenti requisiti di uscita:

BSTS ha completato il reviewla specifica 0.5/DIPD e la strategia di test.

BARB ha approvato la specifica 0.5 / DIPD.
BTI ha completato il suo review della strategia di prova.
BSTS ha reso disponibile la specifica approvata 0.5 / DIPD a tutti i membri associati e promotori.

4.2 0.7/FIPD Stage

Durante il 0.7/FIPD Stage, il GL svilupperà quanto segue utilizzando i modelli ufficiali forniti in [8]:

Per una nuova specifica, una bozza della specifica 0.7, che deve includere, come minimo, informazioni su quanto segue:

Una descrizione di tutte le modifiche apportate dopo l'approvazione da parte del BARB 0.5, comprese le proposte nuove o modificate, i criteri di selezione e la giustificazione della scelta. Le modifiche devono essere descritte allo stesso livello di dettaglio richiesto in 0.5 Stage.

Tutti i requisiti funzionali dalla FRD affrontati.

2. Per un miglioramento delle specifiche, una bozza del FIPD, che deve includere, come minimo, informazioni su quanto segue:

Una descrizione di tutte le modifiche apportate dal DIPD approvato da BARB, comprese le proposte nuove o modificate, i criteri di selezione e la giustificazione della scelta. Le modifiche devono essere descritte con lo stesso livello di dettaglio richiesto nel DIPD Stage.

Se necessario, aree ulteriormente sviluppate che sono state descritte nella sezione 4.1 per quanto riguarda il DIPD.
Una descrizione completa del miglioramento.
Una descrizione architettonica aggiornata.
Tutti i requisiti funzionali dalla FRD affrontati.

3. 0.7 / Documenti di prova FIPD, che devono includere, come minimo, informazioni su quanto segue:

Una suite di test, costituita da un elenco di scopi di test come descritto nel TSTO [5].
Una dichiarazione di conformità dell'implementazione (ICS), come descritto nel TSTO [5].

Per migliorare le specifiche, Test Suite e ICS possono essere forniti come documenti separati o come sezioni aggiuntive nel FIPD.

Il pubblico principale dei documenti prodotti in questo stage sono i membri del WG e BARB che review la descrizione completa della caratteristica o del miglioramento compreso del testo previsto per l'inclusione nella specifica finale. BTI è il pubblico per review dei documenti di prova.

BSTS rifaràview le parti nuove o modificate della specifica 0.7/FIPD e i documenti di prova per la coerenza con le Linee guida per la redazione di Bluetooth, comprese le convenzioni linguistiche stabilite da Bluetooth SIG. BARB rifaràview la specifica 0.7/FIPD.

BSTS assisterà il gruppo di lavoro nella preparazione dei documenti di prova 0.7 / FIPD in conformità con il TSTO [5].

L'ITV deve riview i documenti di prova 0.7/FIPD. Il GL deve fornire la specifica 0.7/FIPD a BTI come riferimento quando reviewi documenti di prova 0.7/FIPD, che BTI riview in conformità con la specifica BTI Review Lista di controllo del processo [6].

Dopo che BARB ha completato il suo review della specifica 0.7/FIPD e BTI ha completato la sua review dei documenti di prova 0.7/FIPD, BSTS effettuerà il reviewed 0.7/FIPD specifica disponibile per tutti i membri associati e promotori.

Lo 0.7/FIPD Stage non è richiesto per miglioramenti alle specifiche CSS, GSS o MDP.

0.7/FIPD Stage requisiti di uscita

Lo 0.7/FIPD Stage è completo e 0.9/CR Stage inizia quando sono soddisfatti i seguenti requisiti di uscita:

BSTS ha completato il reviewla specifica 0.7/FIPD e i documenti di prova.
BARB ha completato reviewnella specifica 0.7/FIPD.
BTI ha completato review0.7/FIPD Test Suite (scopi di test) e 0.7/FIPD ICS.
BSTS ha fatto il reviewed 0.7/FIPD specifica disponibile per tutti i membri associati e promotori.

4.3 0.9/CR Stage

Esistono due tipi di CR: una CR integrata, che è un documento di tracciamento delle modifiche di un'intera specifica adottata che mostra tutte le modifiche rispetto alla versione precedente, e una CR abbreviata, che è un documento che fornisce istruzioni per modificare solo le sezioni interessate di la versione della specifica su cui si basa il CR.

Durante lo 0.9/CR Stage, il GL svilupperà quanto segue utilizzando i modelli ufficiali forniti in [8]:

Per una nuova specifica, una bozza completa del contenuto della specifica 0.9, che deve includere, come minimo, informazioni su quanto segue:

Una descrizione di tutte le modifiche apportate dal BARB-reviewed 0.7 (o dalla specifica 0.5 se la produzione della specifica 0.7 era stata omessa), inclusa la nuova o
proposte modificate, criteri di selezione e giustificazione della scelta. Le modifiche devono essere descritte allo stesso livello di dettaglio richiesto in 0.5 Stagee 0.7 Stage.

2. Per un miglioramento delle specifiche:

O una CR integrata, che deve includere, come minimo, informazioni su quanto segue:
Una descrizione di tutte le modifiche apportate dal BARB-reviewed FIPD (o dal DIPD se il FIPD è stato derogato) comprese le proposte nuove o modificate, i criteri di selezione e la giustificazione della scelta. Le modifiche devono essere descritte con lo stesso livello di dettaglio richiesto nel DIPD Stage e FIPD Stage.
Tutte le modifiche proposte alla specifica adottata in precedenza utilizzando il rilevamento delle modifiche.
Tutti gli errata tecnici approvati (con ogni erratum referenziato con un numero di erratum), mostrati utilizzando il rilevamento delle modifiche, che devono ancora essere incorporati nella versione della specifica adottata in precedenza e quel testo di impatto associato al miglioramento della specifica; o che altrimenti influiscono sui test IOP.

3. O una risposta predefinita abbreviata, che deve includere, come minimo, informazioni su quanto segue:

Una descrizione di tutte le modifiche apportate dal BARB-reviewed FIPD (o dal DIPD se il FIPD è stato derogato) comprese le proposte nuove o modificate, i criteri di selezione e la giustificazione della scelta. Le modifiche devono essere descritte con lo stesso livello di dettaglio richiesto nel DIPD Stage e FIPD Stage.
Tutte le modifiche proposte a ciascuna sezione e paragrafo interessato della specifica che la CR propone di modificare.
Tutti gli errata tecnici approvati (con ogni erratum referenziato con un numero di erratum), mostrati utilizzando il markup, che devono ancora essere incorporati nella versione della specifica adottata in precedenza, e quel testo di impatto che è associato al miglioramento della specifica; o che altrimenti influiscono sui test IOP.

4. Una CR CSS (se le nuove voci sono richieste dalla specifica), che può essere incorporata in una CR abbreviata della specifica.
5. Una CR GSS (se nuove voci sono richieste dalla specifica), che può essere incorporata in una CR abbreviata della specifica.
6. Una CR MDP (se le nuove voci sono richieste dalla specifica), che può essere incorporata in una CR abbreviata della specifica.
7. Documenti di prova 0.9 / CR, che devono includere, come minimo, informazioni su quanto segue utilizzando il modello ufficiale fornito in [8]:

0.9 / CR Test Suite, che include casi di test completi di contenuto e la tabella di mappatura dei casi di test associata (TCMT), come descritto nel TSTO [5].
Lo 0.9 / CR ICS, come descritto nel TSTO [5].
Se la configurazione dei test richiede parametri specifici per Implementation Under Test (IUT), 0.9 / CR Implementation eXtra Information for Testing (IXIT).
La 0.9 / CR Test Case Reference List (TCRL) (opzionale per gli aggiornamenti delle specifiche di base).

8. Un'analisi della copertura del test che indica quali requisiti delle specifiche sono testati o non testati all'interno della suite di test 0.9 / CR (per i miglioramenti delle specifiche, l'analisi della copertura del test deve includere solo le nuove funzionalità aggiunte e interessate, e non le aree non la specifica originale).
9. Un piano di test IOP.

Per i miglioramenti alle specifiche, Test Suite, ICS e IXIT possono essere forniti come documenti separati o come sezioni aggiuntive nella CR abbreviata.

Nella maggior parte dei casi, una CR integrata o abbreviata dovrebbe essere basata sulla versione della specifica adottata in precedenza, ma potrebbe anche essere basata sull'ultima bozza intermedia. Il numero di versione della specifica della bozza intermedia più recente deve essere il numero di versione associato a una versione del documento che è bloccata e che non cambierà nel tempo. In caso contrario, ulteriori informazioni di identificazione (come la data del documento e un file URL in una posizione permanente) deve essere fornito per identificare la specifica versione "di base". Se viene utilizzata una bozza intermedia, eventuali modifiche non direttamente correlate alla CR all'interno di una data sezione che la CR sta modificando devono essere incluse, ma non è necessario che vengano mostrate utilizzando il markup. Se le parti rilevanti della bozza intermedia vengono successivamente aggiornate, la CR deve essere aggiornata per riflettere gli aggiornamenti alla bozza intermedia.

Idealmente, il materiale CR abbreviato è integrato rispettivamente in una bozza della specifica completa e dei documenti di prova completi, prima della fase di convalida, ma possono anche essere integrati all'inizio della fase di convalida. Se vengono sviluppate più funzionalità per una specifica (ad esempio, la specifica di base), potrebbe essere desiderabile integrare le funzionalità in una singola bozza dopo il completamento del test IOP.

BSTS rifaràview la specifica 0.9/CR e i documenti di prova per la coerenza con le linee guida di redazione Bluetooth. Allora BARB rifaràview la specifica 0.9/CR seguita in seguito dal piano di test IOP (come descritto nella Sezione 4.3.1). Una volta che la specifica 0.9/CR è stata presentata dal WG a BARB per il review, BSTS lo renderà accessibile a tutti i membri per riview e notificare a tutti i membri la sua disponibilità. Da questo punto in avanti nel processo di sviluppo delle specifiche, BSTS renderà disponibili a tutti i membri le bozze delle specifiche presentate a BARB con avvisi periodici inviati a tutti i membri.

Per un miglioramento delle specifiche, il gruppo di lavoro raccomanderà al CdA se le versioni precedenti della specifica debbano essere deprecate o ritirate, comprese le ragioni tecniche per le raccomandazioni.

BARB rifaràview l'analisi del WG della conformità della specifica 0.9/CR ai requisiti indicati nella FRD, eventuali problemi di sicurezza, eventuali problemi normativi, conformità con l'architettura Bluetooth e, per un miglioramento delle specifiche, conformità ai requisiti di compatibilità con le versioni precedenti descritti nella Sezione 3.3.2 .XNUMX. Se BARB identifica potenziali problemi di sicurezza, BARB notificherà BSTS per riview e coordinamento con il Security Expert Group; e se BARB identifica eventuali implicazioni normative, BARB notificherà a BSTS di review e coordinarsi con il Comitato di regolamentazione e il consulente legale di Bluetooth SIG. BARB deve approvare o rifiutare la specifica 0.9/CR in base al proprio giudizio ingegneristico e alla considerazione dei fattori descritti in questo paragrafo.

ITV rifaràview i documenti di prova 0.9/CR tenendo conto dell'analisi di copertura del test. BTI deve approvare o rifiutare i documenti di prova 0.9/CR.

Dopo che BARB ha approvato la specifica 0.9/CR, il gruppo di lavoro invia il piano di test IOP a BARB per la revisioneview.

La specifica 0.9 / CR approvata da BARB viene presentata al CdA per approvare l'inizio del test IOP e la pubblicazione della specifica 0.9 / CR a tutti i membri.

Per evidenziare potenziali problemi legali, i gruppi di lavoro possono richiedere una specifica review dal consulente legale di Bluetooth SIG (riferimento legaleview) prima dell'obbligatorietà del review avviene durante la Fase di Adozione/Approvazione. Tuttavia, per i miglioramenti delle specifiche, il review dovrebbe essere fatto su una CR integrata (al contrario di una CR abbreviata) e questo dovrebbe essere programmato il prima possibile in modo che le risorse siano disponibili.

Piano di test IOP

Il WG svilupperà un piano di test IOP scritto che deve soddisfare tutti i requisiti definiti di seguito per l'uso durante la fase di convalida agli eventi di test IOP. I gruppi di lavoro devono presentare il piano di test IOP a BARB per riview prima dell'inizio degli eventi di test IOP. Per semplici miglioramenti delle specifiche (specialmente quelli che non richiedono la modifica o l'aggiunta di casi di test nella suite di test), il test IOP potrebbe non essere necessario e il WG può inviare una richiesta a BARB per una deroga dal test IOP utilizzando il processo definito nella Sezione 4.4.

Il piano di test IOP deve includere:

Test case per verificare tutte le nuove funzionalità obbligatorie, facoltative e condizionali
Almeno un test case per ogni codice operativo
Almeno un test case per ogni parametro
Almeno un test case per ogni tipo di pacchetto
Casi di test di compatibilità con le versioni precedenti per miglioramenti delle specifiche in modo che i requisiti elencati nella Sezione 3.3.2 siano soddisfatti per tutte le funzionalità avanzate (vedere anche la Sezione 4.3.1.1).
Casi di test in cui l'IUT è esposto a valori al di fuori degli intervalli definiti o ad aspetti comportamentali considerati non validi o inattesi (casi di test di comportamento non valido). Si noti che ci si aspetta che un tester come PTS o un altro strumento di test sia l'iniziatore di qualsiasi comportamento non valido.
Qualsiasi numero assegnato temporaneo (selezionato in coordinamento con BSTS per evitare la sovrapposizione nei prossimi eventi di test IOP) da utilizzare durante l'evento di test IOP, come descritto nella Sezione 4.3.1.2.
Identificazione del numero richiesto di implementazioni indipendenti che devono superare ogni caso di test, tenendo conto dei requisiti di copertura descritti nella Sezione 4.3.1.3
Identificazione di eventuali casi di test nella Test Suite che il gruppo di lavoro ritiene debbano essere esclusi e la giustificazione della loro esclusione. Questi includono tipicamente: • Casi di test Future Proofing (ad esempio, test comuni in modo che possano essere adattate possibili aggiunte future, come caratteristiche aggiuntive, caratteristiche estese o l'uso di bit o campi riservati per uso futuro (RFU))
• Scenari di test che sono un sottoinsieme di altri test inclusi
• Casi di test generici che sono virtualmente identici ai test eseguiti per diverse altre specifiche (ad esempio, che attivano codici di errore comuni)
• Scenari di test con lo stesso scopo di test dei casi di test che vengono eseguiti su un altro trasporto (ad esempio, un caso di test BR / EDR simile a un caso di test LE)
• Robustezza o stress test dell'implementazione

Il piano di test IOP può anche includere test esclusivi per i test IOP come casi di test end-to-end che mettono insieme sequenze più complesse che possono assomigliare a un tipico scenario utente.

Sebbene l'approvazione BARB del piano di test IOP non sia richiesta (a condizione che il piano di test IOP continuerà a essere modificato e migliorato con ogni evento di test IOP), è richiesta l'approvazione BARB del report di test IOP (vedere la Sezione 5.1.1) . Se un piano di test IOP non soddisfa tutti i requisiti definiti nella Sezione 4.3.1, il gruppo di lavoro deve presentare un riepilogo di tutte le varianze note e la motivazione di ciascuna varianza a BARB prima dell'inizio degli eventi di test IOP.

Il piano di test IOP e gli scenari di test dovrebbero essere basati principalmente sul contenuto all'interno dei documenti di test della specifica associata.

Per rendere efficienti gli eventi di test IOP, il gruppo di lavoro dovrebbe avere il piano di test IOP e tutti i casi di test associati completati e disponibili agli implementatori, idealmente almeno un mese prima del primo evento di test IOP.

Pianificazione per test di compatibilità con le versioni precedenti
Per i miglioramenti delle specifiche, i test IOP della compatibilità con le versioni precedenti devono considerare la verifica rispetto a tutte le versioni attive e deprecate della specifica poiché tali specifiche e funzionalità comunemente presenti nei prodotti Bluetooth possono avere una durata molto lunga (ad esempio, veicoli). Il gruppo di lavoro deve analizzare il livello appropriato di test di compatibilità con le versioni precedenti necessari (se presenti), comprese le versioni da testare e i test da eseguire, e fornire questa analisi a BARB. BARB deve rifareview l'analisi e suggerire le modifiche (se presenti) per il gruppo di lavoro da incorporare nel piano di test IOP.

I membri che partecipano ai test di compatibilità con le versioni precedenti sono incoraggiati a portare dispositivi legacy che sono stati qualificati rispetto alle versioni precedenti delle specifiche. Il gruppo di lavoro deve segnalare eventuali errori di compatibilità con le versioni precedenti nel rapporto di prova IOP. Le aziende membri sono inoltre incoraggiate a eseguire test di compatibilità con le versioni precedenti nei propri laboratori al di fuori della sede dell'evento di test IOP ea segnalare eventuali problemi relativi alle specifiche al gruppo di lavoro.

Numeri assegnati temporanei utilizzati nei test IOP
BSTS e BARB devono essere consultati per coordinare l'assegnazione temporanea dei numeri assegnati che verranno utilizzati durante l'evento di test IOP in modo che non vi siano sovrapposizioni o conflitti con altre specifiche. Questi valori temporanei devono essere inclusi nel piano di test IOP e non saranno assegnati per l'uso da nessuna specifica adottata.

Per i test IOP in cui vengono proposti uno o più nuovi valori UUID a 16 bit, i valori compresi nell'intervallo da 0x7F00 a 0x7FFF sono riservati per il test IOP.

Per i test IOP in cui vengono proposti uno o più nuovi valori PSM (Fixed Protocol Service Multiplexer), verranno utilizzati i valori a partire dalla fine dell'intervallo valido da 0x0000 a 0x007F, come specificato nelle specifiche di base.

Requisiti di copertura
Il gruppo di lavoro deve fornire la prova a BARB che il numero richiesto (come descritto nelle sezioni seguenti) di implementazioni indipendenti ha superato ogni caso di test. Qualsiasi richiesta di WG per eccezioni al numero richiesto di implementazioni indipendenti deve essere indicata nel piano di test IOP presentato a BARB.

Le implementazioni sono considerate indipendenti l'una dall'altra fintanto che tutte le parti rilevanti per la convalida sono state sviluppate in modo indipendente, ovvero da team diversi (che non provengono necessariamente da società diverse). BSTS può aiutare a valutare se i prototipi possono essere considerati indipendenti l'uno dall'altro al fine di preservare l'anonimato e la riservatezza dei dettagli di implementazione.

Si noti che gli strumenti di test, incluso PTS, non sono considerati implementazioni indipendenti.

Requisiti di copertura IOP delle specifiche di base
Una funzionalità di specifica di base definisce in genere uno o più ruoli in cui ogni ruolo è progettato per interagire con uno o più altri ruoli o possibilmente con se stesso.

Per ogni coppia di ruoli progettati per interagire tra loro, è necessario dimostrare che almeno tre implementazioni indipendenti di ciascun ruolo interagiscono con tre implementazioni indipendenti del ruolo complementare.

Per ogni ruolo che può interagire con un altro dispositivo nello stesso ruolo, almeno tre implementazioni indipendenti di quel ruolo devono dimostrare che possono interagire tra loro in quel ruolo.

Requisiti di copertura IOP della specifica del servizio
Almeno tre implementazioni di servizi indipendenti devono dimostrare di interagire con almeno un'implementazione client, che può essere PTS.

Professionistafile e requisiti di copertura IOP delle specifiche del protocollo
Professionistafile e le specifiche del protocollo in genere definiscono uno o più ruoli in cui ciascun ruolo è progettato per interagire con uno o più altri ruoli, o eventualmente con se stesso.

Per ogni coppia di ruoli progettati per interagire tra loro, almeno due implementazioni indipendenti di ciascun ruolo devono dimostrare di interagire con due implementazioni indipendenti del ruolo complementare.

Per ogni ruolo che può interagire con un altro dispositivo nello stesso ruolo, almeno tre implementazioni indipendenti di quel ruolo devono dimostrare di interagire tra loro in quel ruolo.

Requisiti di copertura IOP della specifica del modello
Almeno tre implementazioni del modello di server o di controllo indipendenti devono dimostrare di interagire con almeno un'implementazione del client (che può essere PTS) e almeno un'implementazione del modello client deve dimostrare che interagisce con almeno un'implementazione del modello di server e PTS.

Numerazione della versione delle specifiche

Durante lo 0.9/CR Stage, il GL deve preparare una raccomandazione da presentare al CdA riguardo al numero di versione da applicare alla specifica una volta adottata.

Le versioni delle specifiche rientrano in due tipi: versioni di rilascio completo, che includono funzionalità nuove o aggiornate, e versioni di rilascio di manutenzione (note anche come "versioni punto-Z"), che integrano errata tecniche ed editoriali, ma non includono nuove o aggiornate Caratteristiche. Le versioni di rilascio complete hanno numeri in due parti sotto forma di XY, come 2.1 o 5.0, mentre le versioni di rilascio di manutenzione hanno numeri in tre parti sotto forma di XYZ, come 2.1.2. Il valore di Z non può essere 0.

Per due versioni qualsiasi, una viene definita "versione superiore" e l'altra è "versione inferiore". Questo è determinato in base alle seguenti regole:

Se i componenti X differiscono, quello con il valore X più alto è la "versione superiore".
Se i componenti X sono gli stessi, ma i componenti Y differiscono, quello con il valore Y più alto è la "versione superiore".
Se i componenti XY sono gli stessi, ma i componenti Z differiscono, quello con il valore Z più alto è la "versione superiore". A tale scopo, un numero XY in due parti viene trattato come un numero in tre parti XY0.

Per esempioample, i seguenti numeri di versione sarebbero in ordine dalla versione più bassa alla versione più alta: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Per CSS, ogni aggiornamento incrementa solo il componente X del numero di versione.

Prerequisiti per l'approvazione del CdA
Al termine della fase di sviluppo delle specifiche devono essere soddisfatti i seguenti requisiti prima che una specifica 0.9 / CR sia sottoposta all'approvazione del CdA:

Il gruppo di lavoro ha completato l'analisi della copertura del test.
BSTS ha completato il reviewla specifica 0.9/CR e i documenti di prova.
BARB ha approvato la specifica 0.9 / CR.
BARB ha approvato la CSS CR (se le nuove voci sono richieste dalla specifica) che può essere incorporata in una CR abbreviata della specifica.
BARB ha approvato GSS CR e MDP CR (se le nuove voci sono richieste dalla specifica).
BTI ha approvato la 0.9/CR Test Suite, ICS e TCRL, insieme a un IXIT (a condizione che l'IXIT sia necessario per eseguire i test nella Test Suite). Il TCRL è facoltativo in questo stage per gli aggiornamenti alla specifica di base.
Il WG ha presentato il piano di test IOP a BARB per riview (se il test non è rinunciato da BARB).

I documenti presentati al CdA devono includere la specifica 0.9 / CR approvata da BARB e una presentazione al CdA che deve includere:

Qualsiasi richiesta nota di rinuncia al test IOP o uno qualsiasi dei requisiti definiti nella Sezione 4.3.1
Un elenco di trasporti supportati dalla specifica (ad es. BR / EDR, LE. Ecc.)
Per un miglioramento delle specifiche, qualsiasi esenzione dai requisiti di compatibilità con le versioni precedenti (descritti nella sezione 3.3.2) richiesta dal gruppo di lavoro
Per un miglioramento delle specifiche, una raccomandazione dal gruppo di lavoro per il numero di versione da applicare alla specifica adottata
Per un miglioramento delle specifiche, la raccomandazione di fine vita del gruppo di lavoro per le versioni precedenti della specifica adottata, inclusi eventuali motivi tecnici per cui la deprecazione o il ritiro di qualsiasi versione precedente della specifica è o non è raccomandata e la giustificazione per la raccomandazione
Qualsiasi problema serio irrisolto da parte dei membri BARB o BTI (ad esempio, motivi per eventuali voti negativi durante le approvazioni, problemi derivanti da riview di documenti di prova, o timori che la specifica 0.9/CR sia al di fuori dell'ambito della FRD o della carta)
Lo stato di preparazione del Profile Tuning Suite (PTS) o altri strumenti necessari associati all'adozione preparati da BSTS

Il CdA può scegliere di approvare la specifica 0.9 / CR per il test IOP come richiesto dallo Statuto [2], prima che BTI approvi i documenti del test 0.9 / CR e prima che il WG confermi che il piano di test IOP soddisfa i requisiti definiti nella Sezione 4.3.1. 0.9. Il CdA può anche subordinare l'approvazione della specifica 0.9 / CR per il test IOP all'approvazione da parte di ITV dei documenti del test XNUMX / CR.

0.9/CR Stage requisiti di uscita
Lo 0.9/CR Stage si completa e la Fase di Validazione inizia quando il CdA approva l'inizio del test IOP.

4.4 Deroghe al processo di sviluppo delle specifiche

Un gruppo di lavoro può richiedere di rinunciare a una o più delle seguenti fasi del processo:

Il 0.5/DIPD Stage
Lo 0.7/FIPD Stage
Test IOP durante la fase di convalida

Per richiedere una deroga, il GL deve utilizzare il modello di rinuncia al processo fornito da Bluetooth SIG [8] e presentare una richiesta di deroga a ciascun comitato (vale a dire, BARB o ITV) che è tenuto a riview o approvare la bozza delle specifiche o i documenti di prova associati presso la stage che il GL propone di rinunciare, e ciascuno di questi comitati deve approvare la richiesta di rinuncia.

Una richiesta di rinuncia deve includere quanto segue:

Un'identificazione del stage(s) a cui il GL vuole rinunciare
Una giustificazione perché il stage(s) dovrebbe essere rinunciato
Un'identificazione di ciascun comitato (cioè, BTI e/o BARB) che è tenuto a riview e approvare la richiesta di rinuncia

Il comitato che considera la rinuncia può richiedere che un rappresentante del gruppo di lavoro faccia una presentazione per giustificare la rinuncia al processo SMPD prima di decidere sulla richiesta di rinuncia.

Se una rinuncia richiede di rinunciare a più passaggi e una parte della rinuncia viene rifiutata e una parte viene approvata, la risposta del comitato deve indicare quali passaggi della richiesta di rinuncia sono stati approvati e quali sono stati rifiutati. Se una richiesta di rinuncia viene rifiutata, la notifica di rifiuto deve includere i motivi del rifiuto.

5. Fase di convalida

Durante la fase di convalida, il gruppo di lavoro eseguirà test IOP sulla specifica 0.9/CR con l'obiettivo di fornire un rapporto di test IOP per BARB review e approvazione. Quando possibile, il test IOP dei miglioramenti delle specifiche dovrebbe essere condotto rispetto alla bozza di specifica integrata. Inoltre, il membro Review, come previsto dallo Statuto [2], inizia in questa fase.

Se la specifica (o il miglioramento) non richiede il test IOP, è possibile rinunciare al test IOP durante la fase di convalida utilizzando il processo descritto nella Sezione 4.4.

Durante il corso del test IOP (che può essere uno o più eventi), il WG dovrebbe tenere traccia dei problemi utilizzando il sistema di tracciamento dei problemi di Bluetooth SIG e iterare per incorporare gli aggiornamenti alla bozza delle specifiche, ai documenti di test e al piano di test IOP. Una volta concluso il test IOP, il gruppo di lavoro deve completare gli aggiornamenti alla bozza delle specifiche e ai documenti di test per affrontare tutti i problemi e preparare e inviare un rapporto di test IOP a BARB per la riformulazione.view e approvazione. Ciò è illustrato nella Figura 5.1.

Durante la Fase di Validazione ci sono diverse attività che possono iniziare. Queste attività possono verificarsi in parallelo e includono quanto segue:

La specifica 0.9/CR approvata dal CdA è messa a disposizione di tutti i membri da BSTS con la notifica dell'inizio del Membro Review periodo previsto dallo Statuto.
Tutti gli aggiornamenti richiesti sono incorporati in CSS (che può essere incorporato in una risposta predefinita abbreviata della specifica).
Le definizioni delle caratteristiche o dei descrittori sono incorporate nella specifica GSS e nel PTS per i test IOP.
Le definizioni delle proprietà della mesh sono incorporate nella specifica MDP e nel PTS per i test IOP.
BSTS consente la registrazione della piattaforma IOP e lo strumento di immissione dei risultati in preparazione per i test IOP.
Test IOP, se necessario (vedere la Sezione 5.1).
Review commenti e problemi, inclusi quelli inviati come risultato del test IOP, vengono elaborati e le modifiche vengono incorporate nella bozza delle specifiche.

5.1 Test IOP

L'obiettivo principale del test IOP è convalidare la specifica, ad esample, verificando l'accuratezza e l'ambiguità all'interno del testo, reviewindividuare eventuali errori e omissioni di progettazione fondamentali e fornire la convalida rispetto ai requisiti stabiliti in precedenza sviluppati in precedenza nel processo di sviluppo delle specifiche. Il test IOP può comportare modifiche alla bozza della specifica e potrebbero essere necessari più eventi di test IOP per completare tutti i test richiesti.

È importante dare ai membri al di fuori del gruppo di lavoro l'opportunità di partecipare ai test IOP perché forniscono un'attività indipendente view del disciplinare e possono far emergere aree di ambiguità nel disciplinare che potrebbero non essere evidenti ai membri del gruppo di lavoro che hanno sviluppato la bozza. Prima di ogni evento di test IOP, BSTS renderà disponibili i dettagli dell'evento, l'ultima bozza delle specifiche, la suite di test e il piano di test IOP e informerà tutti i membri, idealmente un mese prima di ogni evento. La bozza della specifica aggiornata, la suite di test e il piano di test IOP utilizzati in un evento di test IOP dovrebbero essere disponibili almeno una settimana prima di ogni evento.

Durante il test IOP, le combinazioni a coppie di piattaforme tenteranno di eseguire i test ei partecipanti al test IOP registreranno i risultati pass / fail di ciascun test e commenti. Un riepilogo anonimo di questi risultati (riferito ad es., "Piattaforma A", "Piattaforma B", ecc.) E qualsiasi commento, verrà raccolto durante gli eventi di test IOP e reso disponibile ai membri del gruppo di lavoro durante e dopo lo IOP evento di prova. Nel caso in cui siano necessarie ulteriori informazioni per ottenere una migliore comprensione di eventuali commenti o errori verificatisi durante il test IOP, BSTS può agire come intermediario per raccogliere ulteriori informazioni dal membro richiedente.

Se possibile, PTS deve essere aggiornato per supportare i test IOP con piattaforme a tutti i livelli sopra l'Host Controller Interface (HCI) ed essere presente agli eventi di test IOP per quei livelli. Altri strumenti di test possono essere presenti anche agli eventi di test IOP. Un riepilogo dei risultati dei test con PTS o altri strumenti di test (se presenti) dovrebbe essere incluso nel rapporto del test IOP.

Il test IOP sarà aperto a tutti i membri che desiderano fornire un'implementazione del prototipo, tuttavia, Bluetooth SIG può condizionare la partecipazione all'accettazione di accordi con Bluetooth SIG (inclusi accordi di partecipazione e riservatezza). Il gruppo di lavoro è responsabile dell'elaborazione e della risoluzione dei problemi rilevati durante i test IOP e dell'aggiornamento dei documenti interessati; Le modifiche approvate dal gruppo di lavoro devono essere incorporate come aggiornamenti alla bozza delle specifiche e ai documenti di prova da utilizzare in ogni evento di prova IOP.

Prima della fase di convalida, i gruppi di lavoro possono eseguire test preliminari della PIO in occasione di eventi aperti solo ai membri del gruppo di lavoro, tuttavia i risultati dei test informali potrebbero non essere inclusi nei risultati del test della PIO.

Può accadere che vengano seguiti tutti i passaggi che portano al primo evento di test IOP, inclusa una data e un luogo IOP annunciati con l'intenzione di iniziare il test IOP, ma l'approvazione del CdA non era stata ottenuta prima dell'inizio dell'evento di test. In questo caso, il CdA può autorizzare l'inclusione dei risultati dei test raccolti prima dell'approvazione del CdA per l'avvio del test IOP, a condizione che i risultati raccolti fossero basati sulla stessa specifica e Test Suite in corso di approvazione da parte del CdA.

Il test IOP non è richiesto per i miglioramenti alle specifiche CSS, GSS o MDP.

Rapporto di prova IOP
Dopo che il test IOP è stato completato, il WG deve presentare il rapporto di test IOP a BARB con l'obiettivo di dimostrare che il numero richiesto di piattaforme indipendenti ha superato i test richiesti. BARB deve rifareview e approvare o rifiutare il rapporto del test IOP e notificherà al GL se sono necessari ulteriori test IOP prima di inviare il pacchetto di specifiche Voting Draft al CdA. BSTS e il WG devono garantire che nessuna informazione identificativa del membro compaia nel rapporto del test IOP prima di inviare il rapporto a BARB.

Il rapporto di prova IOP deve includere:

Un elenco di tutti gli eventi di test IOP che si sono verificati durante la fase di convalida, comprese le date e le posizioni.
Il numero di aziende associate e piattaforme indipendenti che hanno partecipato a ciascun evento IOP, incluso se è stato utilizzato PTS.
Un elenco delle versioni del piano di test delle specifiche, della suite di test e dell'IOP utilizzate in ogni evento.
Un riepilogo esecutivo che indica se tutti i casi di test soddisfacevano o meno i criteri di superamento minimo.
Un riepilogo di eventuali scostamenti dai requisiti del piano di test IOP definiti nella Sezione 4.3.1 e la motivazione di ogni scostamento.
Un riepilogo della copertura PTS per i casi di test nella Test Suite.
Un elenco di tutti i test case (inclusi i test di compatibilità con le versioni precedenti) dal piano di test IOP, il numero di test superati, il numero di test falliti e se i criteri minimi sono stati soddisfatti per test case inclusa una spiegazione del motivo per cui i requisiti non sono stati soddisfatti incontrato.
Un riepilogo di problemi, commenti e domande ad ogni evento (compresi quelli filed rispetto alla specifica durante il test IOP) e l'impatto sulla specifica e sui documenti di test.

5.2 Requisiti di uscita dalla fase di convalida

La fase di convalida è completa e la fase di approvazione / adozione inizia quando BARB ha approvato il report del test IOP (a meno che il test non sia stato annullato da BARB) e tutti i seguenti requisiti sono stati soddisfatti:

BSTS ha reso disponibile a tutti i membri la specifica 0.9/CR approvata per Member Review come previsto dallo Statuto e comunicato a tutti i soci la propria disponibilità.
Tutti i problemi che sono stati identificati durante il test IOP e che hanno un impatto sul test, sono stati incorporati e testati.
WG ha completato il test IOP (a meno che il test non sia stato annullato da BARB).

6. Fase di adozione / approvazione

Durante la Fase di Adozione/Approvazione, viene finalizzata la specifica e i relativi documenti di prova, viene ricevuta l'approvazione BARB, BQRB e BTI, viene emessa la comunicazione della data di adozione proposta insieme alla versione finale della bozza della specifica presentata al CdA per l'adozione ( Voting Draft) e il pacchetto di specifiche finale viene presentato al CdA. Dopo la durata minima del Membro Review previsto dallo Statuto [2]), il CdA valuterà il disciplinare per l'adozione alla Data di Adozione. Dopo l'adozione, la specifica viene pubblicata e il sistema di qualificazione viene abilitato. La fase di adozione/approvazione è illustrata nella Figura 6.1.

6.1 Bozza di voto

La bozza di voto viene creata incorporando gli aggiornamenti (forniti nella fase di convalida) nei documenti delle specifiche richieste e preparando una bozza finale della nuova specifica. Per i miglioramenti delle specifiche, BSTS creerà la specifica integrata integrando una o più CR nella versione superiore della specifica precedentemente adottata (vedere la Sezione 4.3.2) se non è già stata completata prima della Fase di convalida.

Se vengono apportate modifiche alla specifica durante questa fase e il gruppo di lavoro, il BARB o l'ITV determinano che qualsiasi modifica richiede ulteriori test IOP, la specifica tornerà alla parte di test IOP della fase di convalida affinché il gruppo di lavoro possa eseguire i test aggiuntivi. Durante la Fase di Adozione / Approvazione, i seguenti documenti saranno completati e messi a disposizione del CdA prima della Data di Adozione:

Il progetto di voto
Tutte le specifiche di supporto (ad es. CSS, GSS, MDP) come richiesto per il tipo di specifica (o miglioramento) pertinente, se non adottato in precedenza
Per i miglioramenti delle specifiche, una versione con traccia delle modifiche della versione delle specifiche adottata che mostra le modifiche proposte nella bozza di voto
Una descrizione dal gruppo di lavoro di eventuali requisiti di compatibilità con le versioni precedenti (come descritto nella sezione 3.3.2) che non sono stati soddisfatti e la giustificazione di eventuali esenzioni
Una descrizione dal GL di eventuali requisiti del piano di test IOP (come descritto nella Sezione 4.3.1) che non sono stati soddisfatti e la giustificazione di eventuali deviazioni insieme al rapporto di test IOP (che può essere fornito fornendo un collegamento a una copia su il Bluetooth SIG websito)
Una raccomandazione del GL per la deprecazione o il ritiro di qualsiasi versione precedente della specifica adottata insieme a una giustificazione, che metta in evidenza le modifiche rispetto alla 0.9/CR Stage raccomandazione di fine vita
Un riepilogo, preparato dal gruppo di lavoro, delle modifiche a caratteristiche o funzionalità dalla specifica 0.9 / CR (se presente)
Un riassunto, preparato da BARB, delle preoccupazioni sollevate dai membri BARB che la specifica prodotta dal WG esula dallo scopo della carta approvata dal CdA (se presente)
Un elenco di questioni legali irrisolte rimanenti da legali review (se presente)
La suite di test approvata da ITV, insieme al riepilogo approvato dal gruppo di lavoro della copertura dei test delle specifiche della bozza di voto. In caso di funzionalità appena aggiunte o modificate senza copertura del test, è richiesta una giustificazione scritta per l'omissione
ICS e IXIT approvati da ITV (se richiesto dalla specifica)
Il TCRL è stato approvato sia da BTI che da BQRB
Un rapporto preparato da BSTS insieme a BTI riguardante lo stato di disponibilità dello strumento (ad esempio, PTS e altri strumenti di test, Bluetooth Launch Studio) incluso se eventuali casi di test nel TCRL non sono supportati dagli strumenti di test
Un riepilogo, preparato dal gruppo di lavoro, di tutti i numeri assegnati necessari
Una lista di controllo per l'adozione preparata da BSTS e dal gruppo di lavoro che mostra che tutti i risultati di questa sezione sono stati completati
Tutte le altre informazioni richieste dal CdA

Durante la fase di adozione / approvazione, il gruppo di lavoro dovrebbe utilizzare il sistema di tracciamento dei problemi di Bluetooth SIG per acquisire problemi e commenti rispetto alla bozza di specifica e ai documenti di prova in modo che siano presi in considerazione nella finalizzazione delle specifiche della bozza di voto. Per un miglioramento delle specifiche, tutti gli errata pertinenti approvati (cioè gli errata approvati non ancora integrati) devono essere incorporati e devono essere identificati utilizzando le modifiche rilevate.

Il gruppo di lavoro deve presentare la bozza finale delle specifiche a BSTS per la revisione legaleview. Per le nuove specifiche, il legale review includerà l'intera specifica. Per i miglioramenti delle specifiche, il review si concentrerà principalmente sulle parti modificate della specifica. Lo scopo del re legaleview è principalmente quello di identificare i rischi legali che il gruppo di lavoro dovrebbe considerare e cercare di risolvere. Il feedback legale sarà classificato in base alla gravità. Se un diritto legale facoltativo review è stata eseguita a 0.9/CR Stage, la versione sottoposta a revisione legaleview deve mostrare, come modifiche rilevate, tutte le modifiche apportate da quella versione (generate dal WG o da BSTS). Al termine della revisione legaleview, il WG e BSTS concorderanno sul feedback da incorporare nella bozza delle specifiche. Se ci sono commenti legali irrisolti da parte del legale review sulla bozza di specifica, il presidente del gruppo di lavoro può richiedere tempo all'ordine del giorno del CdA per concordare una risoluzione.

In parallelo con il re legaleview, il GL deve presentare la bozza di specifica a BARB per riview. Al momento della presentazione iniziale a BARB, BSTS notificherà a tutti i membri che la bozza della specifica è stata presentata a BARB per la revisioneview e che è disponibile anche per i membri Review. Se il WG invia aggiornamenti alla bozza delle specifiche per BARB re-review, BSTS invierà periodicamente ulteriori comunicazioni a tutti i membri.

Al completamento di BARB review, il WG e BARB concorderanno il feedback da incorporare nella bozza delle specifiche.

Se il legale review comporta eventuali modifiche sostanziali, ulteriori riview da BARB potrebbe essere richiesto. Allo stesso modo, se il BARB review comporta eventuali modifiche sostanziali, BSTS determinerà se un'ulteriore riforma legaleview di tali modifiche è necessario. Al termine della revisione legaleview e BARB review, BARB deve approvare o rifiutare la bozza di voto.

Se qualsiasi documento di prova richiede l'aggiornamento, BSTS assisterà il gruppo di lavoro nell'aggiornamento dei documenti di prova. BTI deve approvare o rifiutare i documenti di prova. Se approvato da BTI, BTI assisterà nella finalizzazione del TCRL e consegnerà questo documento a BQRB insieme a ICS, IXIT e Test Suite associati. BSTS stimerà la data della riunione del CdA in cui il CdA intende votare sull'adozione della Bozza di voto (Data di adozione) e la fornirà ITV da utilizzare nel TCRL. L'approvazione BARB della specifica, l'approvazione ITV di tutti i documenti di prova (inclusi Test Suite, TCRL, ICS e IXIT) e l'approvazione BQRB del TCRL devono avvenire alla o prima della Data di adozione.

BSTS informerà tutti i membri della finalizzazione e disponibilità della Bozza di Voto e della Data di Adozione. La data di adozione sarà fissata non prima di 60 giorni dopo che i membri sono stati informati della specifica 0.9/CR approvata dal CdA, a meno che il membro nonview il termine è abbreviato dal CdA ai sensi di Statuto, e almeno 14 giorni dopo la comunicazione della Data di Adozione è fornita ai membri ai sensi di Statuto. Per i casi in cui più CR sono state integrate in una bozza di voto, l'inizio del Member Review è la data in cui ai membri è stata notificata l'ultima CR approvata dal CdA.

Dopo aver comunicato ai membri la Data di Adozione, sono consentite correzioni approvate dal CdA di errori tipografici nella Bozza di Votazione. La sequenza temporale per l'adozione delle specifiche è illustrata nella Figura 6.2.

6.2 Numeri assegnati

Bluetooth SIG mantiene una serie di numeri assegnati pubblicamente disponibili sui numeri assegnati di Bluetooth SIG websito [7]. Questi numeri assegnati sono raggruppati in vari spazi numerici (un insieme correlato di numeri senza duplicati). I numeri assegnati possono sovrapporsi ad altri numeri assegnati in spazi numerici diversi, ma nessun numero all'interno di uno spazio numerico può essere riutilizzato. I vari spazi numerici sono definiti nella specifica che definisce l'utilizzo dei numeri assegnati.

Dopo che BARB avrà approvato il rapporto di prova IOP, il WG presenterà a BARB una richiesta per l'assegnazione di nuovi numeri all'interno dello spazio o degli spazi numerici richiesti dalla specifica finale. BARB rifaràview la richiesta e collaborare con BSTS per determinare i numeri assegnati. Dopo l'approvazione di BARB, BSTS pianificherà la pubblicazione dei numeri assegnati da rendere pubblicamente disponibili sui numeri assegnati Bluetooth SIG websito [7] entro una settimana dall'adozione del disciplinare.

Una volta che la pubblicazione dei numeri assegnati sul Bluetooth SIG Assigned Numbers websito o all'interno di una specifica adottata, i numeri assegnati sono destinati ad essere immutabili (per non cambiare né nel valore né nel significato). Se diventano inutilizzabili per qualche motivo, diventano valori riservati e non possono essere riutilizzati.

6.3 Requisiti di uscita dalla fase di adozione / approvazione

La Fase di Approvazione / Adozione è conclusa quando il CdA ha adottato il disciplinare e sono state completate le seguenti attività post adozione:

BSTS ha reso pubblicamente disponibili i numeri finali assegnati sul Bluetooth SIG websito.
BSTS ha reso pubblicamente disponibile la specifica adottata sul Bluetooth SIG websito
BSTS ha reso disponibili pubblicamente sul Bluetooth SIG tutti i documenti di supporto (ad es. CSS, GSS, MDP) richiesti per la specifica pertinente websito.
BSTS ha reso disponibili i documenti di prova associati a tutti i membri sul Bluetooth SIG websito.
Per i miglioramenti delle specifiche, BSTS ha realizzato una versione informativa tracciata delle modifiche della versione delle specifiche precedentemente adottata con tutte le modifiche apportate dalla versione appena adottata e l'ha resa disponibile a tutti i membri sul Bluetooth SIG websito.
BSTS ha abilitato il sistema di qualificazione.
BSTS ha notificato a tutti i membri la disponibilità della specifica adottata e di tutti i documenti giustificativi.

Bluetooth SIG prevede di completare queste attività post-adozione entro una settimana dall'adozione della specifica.

7. Fase di mantenimento delle specifiche

La fase di mantenimento delle specifiche inizia al termine della fase di adozione / approvazione. Se vengono rilevati problemi (ad esempio, ambiguità di formulazione o errori tecnici) con le specifiche oi documenti di test associati, è necessario documentarli creando proposte di errata utilizzando lo strumento Bluetooth SIG Errata. Le proposte di erratum delle specifiche saranno elaborate, classificate e approvate secondo l'EPD [3]. Gli errori di test Suite vengono elaborati e classificati in base al TSTO [5]. In caso di conflitti tra SMPD e EPD o TSTO, SMPD ha la precedenza.

L'erratum delle specifiche deve essere utilizzato solo per correggere errori tecnici o editoriali nelle specifiche Bluetooth adottate. L'aggiunta, le modifiche e la rimozione di funzionalità possono essere effettuate solo tramite il processo di miglioramento delle specifiche definito in precedenza in questo documento.

7.1 Processo di erratum accelerato

Quando un erratum è approvato seguendo il processo definito nell'EPD [3], il WG, BARB o BSTS può raccomandare che sia considerato urgente e dovrebbe essere accelerato. Quando ciò si verifica, BSTS insieme al WG o BARB presenterà la raccomandazione al CdA. Il CdA deciderà se accettare o meno la raccomandazione. Se la raccomandazione viene accettata, BSTS incorporerà immediatamente l'erratam approvato nel modello di erratum [8] e collaborerà con il GL responsabile per finalizzare una correzione accelerata dell'errata da presentare al GL per il review e approvazione.

Un oltreview del processo di erratum accelerato è illustrato nella Figura 7.1.

I seguenti documenti devono essere compilati e messi a disposizione del CdA prima della Data di Adozione:

La bozza di correzione rapida degli Errata approvata da BARB.
Una descrizione dal gruppo di lavoro di eventuali requisiti di compatibilità con le versioni precedenti (come descritto nella sezione 3.3.2) che non sono stati soddisfatti e la giustificazione per eventuali esenzioni.
Un elenco di questioni legali irrisolte rimanenti da legali review (se presente).
Test Suite, ICS e IXIT approvati da ITV (se richiesto dall'erratum).
Il TCRL approvato da BTI e BQRB (se richiesto dall'erratum).
Un rapporto completato da BSTS insieme a BTI riguardante lo stato di disponibilità dello strumento (ad esempio, PTS e altri strumenti di test, Bluetooth Launch Studio) incluso se eventuali casi di test nel TCRL non sono supportati dagli strumenti di test e una spiegazione (se richiesta dall'erratum ).
Una lista di controllo per l'adozione completata da BSTS e dal gruppo di lavoro che mostra che i risultati in questa sezione sono stati tutti completati.
Tutte le altre informazioni richieste dal CdA.

BSTS lavorerà con il GL responsabile per finalizzare la bozza di Expedited Errata Correction e creare una versione da presentare al GL responsabile per il review e approvazione.

Il gruppo di lavoro deve presentare la correzione rapida dell'errata a BSTS per il riesame legaleview. Al termine della revisione legaleview, il WG e il BSTS concorderanno sul feedback da incorporare nella correzione accelerata dell'errata. Se ci sono commenti legali irrisolti da parte del legale review sulla correzione rapida dell'errata, il presidente del gruppo di lavoro può richiedere tempo all'ordine del giorno del CdA per chiedere il parere del CdA sulla risoluzione.

In parallelo con il re legaleview, il GL deve presentare la correzione errata accelerata a BARB per riview. Una volta che la correzione rapida dell'errata è stata inviata a BARB, BSTS lo renderà accessibile a tutti i membri per riview e notificare a tutti i membri la sua disponibilità. Al completamento di BARB review, il WG e BARB concorderanno il feedback da incorporare nella correzione accelerata dell'errata.

Se qualsiasi documento di prova richiede l'aggiornamento, BSTS assisterà il gruppo di lavoro nell'aggiornamento dei documenti di prova. Dopo l'approvazione da parte di ITV dei documenti di prova, BTI assisterà nella finalizzazione del TCRL e consegnerà il documento a BQRB insieme a ICS, IXIT e Test Suite associati, ove applicabile. BSTS stimerà la data di adozione e la fornirà a ITV per l'utilizzo nel TCRL. L'approvazione BARB della Correzione Errata Rapida, l'approvazione ITV di tutti i documenti del test (inclusi Test Suite, TCRL, ICS e IXIT a seconda dei casi) e l'approvazione BQRB del TCRL devono avvenire entro la Data di adozione.

BSTS informerà tutti i membri della finalizzazione e della disponibilità della Correzione Errata Rapida e della Data di Adozione proposta. La Data di adozione sarà fissata e notificata a tutti i membri in conformità con lo Statuto [2] e la Data di adozione dovrà essere di almeno 14 giorni dopo che l'avviso è stato fornito ai membri. Dopo la comunicazione della Data di Adozione proposta ai membri, il CdA può approvare le correzioni di errori tipografici nella Correzione Errata Rapida senza fornire un avviso aggiuntivo della Data di Adozione proposta e attendere i 14 giorni richiesti.

Bluetooth SIG renderà disponibile pubblicamente la Correzione Errata Rapida adottata e prevede di farlo entro una settimana dall'adozione. La notifica della sua disponibilità sarà inviata da BSTS a tutti i membri.

Il processo di erratum accelerato è completo quando il CdA ha adottato la Correzione Errata Rapida e le seguenti attività post-adozione sono state completate:

BSTS ha reso pubblicamente disponibili sul Bluetooth SIG la correzione rapida dell'errata adottata e i documenti di test associati (se richiesti dall'errata). websito.
BSTS ha abilitato il sistema di qualificazione (se richiesto dall'erratum).
BSTS ha notificato a tutti i membri la disponibilità della Correzione Errata Rapida adottata.

Al completamento di queste attività, la Correzione Errata verrà pianificata per l'integrazione nelle specifiche interessate o come parte di un miglioramento delle specifiche pianificato o in una versione di manutenzione imminente come descritto nella Sezione 7.2.

7.2 Processo di rilascio della manutenzione (specifiche .Z)

Su base approssimativamente annuale, BSTS determinerà se ci sono degli errata approvati (indicati come Correzioni Errata) che sono classificati come Tecnico / Alto o Tecnico / Critico e che devono ancora essere incorporati nel testo di qualsiasi specifica attiva (cioè, una specifica adottata che non è stata deprecata o ritirata). Vedere l'Appendice A per le definizioni di classificazione degli errata. Un proprietario della specifica (o il gruppo di lavoro noleggiato per mantenere la specifica, o BARB se nessun gruppo di lavoro è noleggiato per mantenere la specifica) può anche richiedere un rilascio di manutenzione precedente di una specifica attiva in cui incorporare eventuali errata approvati. Dopo la determinazione del BSTS o la richiesta del proprietario delle specifiche, inizierà il processo di rilascio della manutenzione.

Un oltreview del processo di rilascio di manutenzione è illustrato in Error! Fonte di riferimento non trovata.

All'inizio del processo di rilascio della manutenzione, BSTS insieme al proprietario delle specifiche, BARB e BTI svilupperanno e presenteranno un piano al CdA per incorporare le correzioni degli Errata nella versione delle specifiche pubblicata. Il piano proposto deve indicare se le Correzioni Errata saranno incorporate in una versione di manutenzione della specifica (cioè, una versione .Z) o un miglioramento della specifica che è già in corso (cioè, una versione XY). Il piano proposto dovrebbe tenere conto dell'eventuale aggiunta di nuove caratteristiche obbligatorie tra le versioni delle specifiche adottate, del tempo stimato in cui è pianificato l'adozione del successivo miglioramento delle specifiche e di altri fattori.

Dopo l'approvazione di un piano da parte del CdA, BSTS insieme al proprietario delle specifiche procederà a incorporare tutte le correzioni Errata Tecniche / Medie, Tecniche / Elevate e Tecniche / Critiche in una bozza di specifica denominata "Bozza di rilascio di manutenzione". Per correzioni editoriali o tecniche / Errata corretti bassi, se la Correzione errata si applica a più di una versione della specifica, BSTS, a meno che il CdA non indichi diversamente, integrerà quegli errata solo nella versione con specifica superiore più recente al prossimo aggiornamento di quella versione . Nessuna modifica può essere inclusa in una bozza di rilascio di manutenzione se non incorporando correzioni errata. Ogni Bozza del rilascio di manutenzione deve identificare tutte le correzioni errata incorporate utilizzando il rilevamento delle modifiche per mostrare le modifiche proposte alla versione precedentemente adottata della specifica pubblicata.

La tempistica dell'incorporazione proposta per ogni Correzione Errata in una Bozza di Rilascio di Manutenzione dipenderà dall'impatto della Suite di Test: tutte le Correzioni di Errata che non hanno un impatto di Suite di Test possono essere incorporate immediatamente, ma le Correzioni di Errata che hanno un impatto sulla Suite di Test saranno elaborati in modo che la tempistica coincida con un aggiornamento al TCRL.

BTI e BSTS stabiliranno una scadenza per l'inclusione di Correzioni Errata con impatto su Test Suite in una bozza di rilascio di manutenzione. Questa scadenza è in genere da 3 a 6 mesi prima della data di approvazione pianificata del prossimo rilascio principale del TCRL. Le correzioni Errata con impatto su Test Suite che non rispettano la scadenza per l'inclusione verranno elaborate come parte della prossima versione annuale del TCRL. Pertanto, a meno che non sia richiesta una versione precedente, il tempo massimo per le correzioni Errata Tecniche / Elevate o Tecniche / Critiche da includere in un aggiornamento delle specifiche è di circa 15-18 mesi.

Il proprietario della specifica deve presentare la bozza di rilascio di manutenzione che ha approvato come definitiva per la revisione legaleview. Il legale review si concentrerà principalmente sulle parti modificate della specifica. Al termine della revisione legaleview, il proprietario della specifica e BSTS concorderanno il feedback da incorporare nella bozza di rilascio di manutenzione. Se ci sono commenti legali irrisolti da parte del legale review sulla Maintenance Release Draft, il Proprietario della Specifica può richiedere del tempo all'ordine del giorno del CdA per richiedere l'input del CdA sulla delibera.

In parallelo con il re legaleview, il proprietario della specifica deve presentare la bozza di rilascio di manutenzione a BARB per la revisioneview. Una volta che la bozza di rilascio di manutenzione è stata inviata a BARB, BSTS la renderà accessibile a tutti i membri per la revisioneview e notificare a tutti i membri la sua disponibilità. Al completamento di BARB review, il proprietario della specifica e BARB concorderanno il feedback da incorporare nella bozza della specifica.

Per le correzioni degli Errata che influiscono sui documenti del test e dove gli errata del test corrispondenti verranno elaborati in tempo per il prossimo rilascio del TCRL, BSTS collaborerà con il proprietario delle specifiche e ITV per aggiornare i documenti del test. Dopo l'approvazione da parte dell'ITV dei documenti di prova, BSTS stimerà la Data di adozione e fornirà la Data di adozione proposta all'ITV da utilizzare nel TCRL. BTI consegnerà il TCRL a BQRB insieme a ICS, IXIT e Test Suite associati, se applicabile. L'approvazione BARB della specifica, l'approvazione ITV di tutti i documenti di prova (inclusi Test Suite, TCRL, ICS e IXIT a seconda dei casi) e l'approvazione BQRB del TCRL devono avvenire alla o prima della Data di adozione.

BSTS informerà tutti i membri della finalizzazione e della disponibilità della bozza di votazione e della data di adozione proposta. La Data di adozione sarà fissata e notificata a tutti i membri in conformità con lo Statuto e la Data di adozione dovrà essere di almeno 14 giorni dopo la comunicazione della comunicazione ai membri. Dopo aver comunicato ai membri la data di adozione proposta, il CdA può approvare le correzioni di errori tipografici nella bozza di votazione senza fornire un avviso aggiuntivo di una data di adozione proposta e attendere i 14 giorni richiesti.

I seguenti documenti devono essere compilati e messi a disposizione del CdA prima della Data di Adozione:

Il progetto di voto
Una versione con tracciamento delle modifiche della bozza di voto che mostra tutte le modifiche alla versione adottata della specifica che ha lo stesso valore XY (ad esempio, se la bozza di voto è proposta come versione 1.4.2, le modifiche verranno tracciate rispetto alla 1.4.1 versione della specifica)
Una raccomandazione del proprietario della specifica per la deprecazione o il ritiro di qualsiasi versione precedente della specifica adottata insieme a una giustificazione
Un elenco di questioni legali irrisolte rimanenti da legali review (se presente)
Test Suite, ICS e IXIT approvati da BTI (se richiesto dalla versione di manutenzione)
Il TCRL approvato da BTI e BQRB (se richiesto dalla versione di manutenzione)
Un rapporto completato da BSTS insieme a BTI riguardante lo stato di disponibilità dello strumento (ad esempio, PTS e altri strumenti di test, Bluetooth Launch Studio) inclusi eventuali casi di test nel TCRL che non sono supportati dagli strumenti di test e spiegazione (se richiesta dalla manutenzione pubblicazione)
Una lista di controllo per l'adozione completata da BSTS e dal proprietario delle specifiche che mostra che i risultati in questa sezione sono stati tutti completati
Tutte le altre informazioni richieste dal CdA

Il processo di rilascio di mantenimento è completo quando il CdA ha adottato la Bozza del voto e sono state completate le seguenti attività post-adozione:

BSTS ha reso pubblicamente disponibili sul Bluetooth SIG . la specifica adottata e i documenti di prova associati (se richiesti dalla versione di manutenzione) websito.
BSTS ha reso disponibile a tutti i membri sul Bluetooth SIG una versione tracciata delle modifiche informativa della versione delle specifiche precedentemente adottata con tutte le modifiche incorporate nella versione appena adottata websito.
BSTS ha abilitato il sistema di qualificazione.
BSTS ha notificato a tutti i membri la disponibilità della specifica adottata e dei documenti giustificativi.

Bluetooth SIG prevede di completare queste attività post-adozione entro una settimana dall'adozione della specifica.

Al completamento di queste attività, la specifica rimane nella fase di mantenimento della specifica fino a quando la specifica non viene deprecata o ritirata, come definito nella Sezione 8.

8. Fase di fine vita delle specifiche

Le specifiche possono essere deprecate o ritirate quando vengono sostituite da versioni più recenti, ritenute tecnicamente insufficienti o per altri motivi. Le specifiche obsolete e ritirate vengono archiviate e non vengono più aggiornate. Le specifiche obsolete e ritirate vengono trattate in modo diverso nel programma di qualificazione Bluetooth.

Qualsiasi membro, gruppo o comitato può inviare raccomandazioni per deprecare o ritirare una specifica insieme a una sequenza temporale associata a BSTS (via e-mail a

specifica.manager@bluetooth.com) in qualsiasi momento. BSTS può anche raccomandare la deprecazione o il ritiro di una specifica e della relativa tempistica. BSTS riferirà la raccomandazione a BARB e al gruppo o comitato responsabile del mantenimento delle specifiche per il review e feedback.

BARB e il gruppo o il comitato responsabile valuteranno le raccomandazioni per deprecare o ritirare una specifica e prendere in considerazione i seguenti criteri (non esaustivi):

In una versione precedente della specifica sono presenti funzionalità obsolete o che non dovrebbero essere utilizzate?
È stata aggiunta una nuova funzionalità obbligatoria alle versioni successive?
Sono presenti carenze nelle versioni precedenti che compromettono il funzionamento o l'interoperabilità che sono state corrette nelle versioni successive e sono necessarie per far avanzare gli scenari utente esistenti?
Sono necessarie funzionalità aggiuntive nelle versioni successive per far avanzare nuovi scenari utente?
C'è una migliore usabilità e interoperabilità nelle versioni successive?
Ci sono miglioramenti della sicurezza nelle versioni successive?

BARB e il gruppo o la commissione competente possono proporre una raccomandazione alternativa.

Dopo aver ricevuto feedback da BARB o dal gruppo o comitato responsabile del mantenimento della specifica, BSTS sottoporrà le raccomandazioni e il feedback al CdA per l'esame. Il CdA può invitare il gruppo o il comitato responsabile del mantenimento delle specifiche interessate a soddisfare e discutere le raccomandazioni. Il CdA prenderà in considerazione raccomandazioni e feedback e potrà concordare o modificare la proposta. Il CdA chiederà a BSTS di notificare a tutti i membri le proposte di deprecare o ritirare le specifiche e le tempistiche associate per un rinnovo di 30 giorni.view periodo per consentire a tutti i membri di fornire un feedback aggiuntivo prima di prendere la decisione finale.

Il CdA valuterà i feedback ricevuti dai membri. Una volta che il CdA ha approvato la deprecazione o il ritiro di una specifica, BSTS informerà tutti i membri della decisione e della relativa tempistica.

8.1 Deprecazione

Una volta che una specifica è obsoleta, si verificherà quanto segue:

La specifica non verrà più aggiornata.
Il WG responsabile riview tutte le errata in sospeso scritte contro la specifica deprecata per determinare se si applicano ad altre specifiche. L'errata può essere rifiutata nel sistema di errata e riscritta rispetto alle specifiche applicabili.
Il gruppo di lavoro o BSTS creerà errata per aggiornare eventuali riferimenti necessari a specifiche obsolete in altre specifiche.
BTI aggiornerà i documenti di prova applicabili per indicare la deprecazione della specifica.
BSTS aggiornerà il Bluetooth SIG websito con indicazioni relative a specifiche alternative da utilizzare.
Non è più possibile inviare nuovi errata per una specifica deprecata.
La specifica non sarà referenziata in nessuna specifica futura.
BSTS archivierà una versione della specifica contrassegnata come deprecata affinché i membri possano accedervi per scopi storici.

8.2 Recesso

Una volta ritirata una specifica, oltre ai passaggi che richiedono la deprecazione, si verificherà quanto segue:

BTI aggiornerà i documenti di prova applicabili per indicare il ritiro della specifica.
BSTS aggiornerà il Bluetooth SIG websito con indicazioni relative a specifiche alternative da utilizzare.
BSTS archivierà una versione della specifica contrassegnata come ritirata affinché i membri possano accedervi per scopi storici.

Il CdA può scegliere di ritirare immediatamente una specifica senza prima deprecarla.

9. Processo del libro bianco

I white paper vengono creati solo a scopo informativo. Il seguente processo di white paper si applica a tutti i gruppi di lavoro Bluetooth, EG, SG e comitati. Questa sezione non si applica ai documenti informativi da utilizzare solo all'interno di Bluetooth SIG.

Questo processo è illustrato nella Figura 9.1 di seguito.

Prima che qualsiasi gruppo o comitato inizi a lavorare su un white paper che intendono essere pubblicato da Bluetooth SIG, il gruppo o il comitato preparerà sia una proposta di aggiornamento della carta che definisce chiaramente i contenuti proposti del white paper sia una presentazione della proposta di white paper.

La presentazione della proposta di white paper deve includere almeno:

La necessità del white paper
Una sintesi dei contenuti proposti del white paper
Una spiegazione del motivo per cui si sconsiglia di includere il contenuto come parte di una specifica
Il pubblico previsto
Eventuali piani di manutenzione (ad esempio, il tempo stimato prima del prossimo rilascio di questo white paper potrebbe essere necessario)
Raccomandazioni su come gestire le versioni precedenti del white paper, se presenti (ad esempio, archiviazione)

L'aggiornamento della carta e la presentazione della proposta di white paper devono essere presentati per BARB review. su review e l'approvazione dell'aggiornamento della carta da parte di BARB, BSTS sottoporrà l'aggiornamento della carta al CdA per l'approvazione insieme alla presentazione della proposta di white paper di supporto.

Se il CdA approva l'aggiornamento della Carta, il gruppo o il comitato può procedere con lo sviluppo del white paper.

Quando il gruppo o il comitato ha completato lo sviluppo del white paper, BSTS eseguirà una revisione editorialeview per coerenza con le linee guida di redazione Bluetooth.

Dopo la risoluzione dei commenti BSTS, il gruppo deve inviare il white paper a BSTS per la revisione legaleview. Al termine della revisione legaleview, il gruppo e BSTS concorderanno il feedback da incorporare nel white paper. Se ci sono commenti legali irrisolti da parte legale review sul white paper, il presidente del gruppo può richiedere tempo all'ordine del giorno del CdA per chiedere il parere del CdA sulla delibera.

In parallelo con il re legaleview, il gruppo deve presentare il white paper a BARB per riview. Come parte del loro review, BARB può raccomandare se qualsiasi parte del white paper debba essere rimossa dal white paper e incorporata in una specifica seguendo il processo nella Sezione 3. BARB può anche decidere di presentare il white paper ad altri gruppi o comitati per il riesame.view. Al completamento di BARB review, il gruppo e BARB concorderanno il feedback da incorporare nel white paper.

Dopo l'approvazione del white paper da parte di BARB, il white paper approvato da BARB sarà presentato dal gruppo di autori o dal comitato al CdA per l'approvazione.

Il processo del white paper è completo quando il CdA ha approvato il white paper e le seguenti attività post-approvazione sono state completate:

BSTS ha reso pubblico il white paper approvato sul Bluetooth SIG websito.
BSTS notifica a tutti i membri del white paper approvato.
Se il white paper è un miglioramento di un white paper esistente, BSTS archivierà una versione del white paper affinché i membri possano accedervi per scopi storici.

Il Bluetooth SIG prevede di completare le attività di post-approvazione entro una settimana dall'approvazione del white paper.

10. Riferimenti

I documenti Bluetooth referenziati sono disponibili dal Bluetooth websito http://www.bluetooth.com.

Linee guida per la redazione Bluetooth (disponibili nella pagina Modelli e documenti del gruppo di lavoro, all'indirizzo https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Statuto di Bluetooth SIG, Inc. (disponibile alla pagina Documenti governativi, all'indirizzo https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Documento di elaborazione degli errori di specifica Bluetooth (disponibile nella pagina Modelli e documenti del gruppo di lavoro, all'indirizzo https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Documento di elaborazione del gruppo di lavoro (disponibile nella pagina Modelli e documenti del gruppo di lavoro, all'indirizzo https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Strategia di test e terminologia finitaview documento (disponibile nella pagina Requisiti del test di qualificazione, su https://www.bluetooth.com/specifications/qualification-test-requirements)
Specifica BTI Review Elenco di controllo del processo (disponibile nella pagina Modelli e documenti del gruppo di lavoro, su https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Numeri assegnati Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Modelli e documenti del gruppo di lavoro (disponibili nella pagina Modelli e documenti del gruppo di lavoro, all'indirizzo https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
GATT Specification Supplement (GSS) (disponibile sulla pagina delle specifiche GATT, all'indirizzo https://www.bluetooth.com/specifications/gatt)
Invia un'idea per una nuova specifica https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Acronimi e abbreviazioni

Tabella A: Acronimi e abbreviazioni

Appendice A - Classificazione della gravità degli errori

Questa appendice riassume le linee guida per la classificazione della gravità per un erratum di specifica. Questa tabella verrà aggiunta a una futura revisione dell'EPD, quindi questa sezione verrà eliminata.

Leggi di più su questo manuale e scarica il PDF:

Documento sul processo di gestione delle specifiche (SMPD) - PDF ottimizzato
Documento sul processo di gestione delle specifiche (SMPD) - PDF originale

Domande sul tuo Manuale? Pubblicale nei commenti!

Riferimenti

Manuale d'uso