ਨਿਰਧਾਰਨ ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ (SMPD)

ਇਹ ਦਸਤਾਵੇਜ਼, ਇਸਦੇ ਸਿਰਲੇਖ ਜਾਂ ਸਮੱਗਰੀ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਬਲੂਟੁੱਥ SIG Inc. (“Bluetooth SIG”) ਅਤੇ ਇਸਦੇ ਮੈਂਬਰਾਂ ਦੁਆਰਾ ਬਲੂਟੁੱਥ ਪੇਟੈਂਟ/ਕਾਪੀਰਾਈਟ ਲਾਇਸੰਸ ਸਮਝੌਤੇ ਅਤੇ ਬਲੂਟੁੱਥ ਟ੍ਰੇਡਮਾਰਕ ਲਾਈਸੈਂਸ ਸਮਝੌਤੇ ਦੇ ਅਧੀਨ ਦਿੱਤੇ ਗਏ ਲਾਇਸੰਸਾਂ ਦੇ ਅਧੀਨ ਬਲੂਟੁੱਥ ਨਿਰਧਾਰਨ ਨਹੀਂ ਹੈ।

ਇਹ ਦਸਤਾਵੇਜ਼ "ਜਿਵੇਂ ਹੈ" ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਬਲੂਟੁੱਥ ਸਿਗ, ਇਸਦੇ ਮੈਂਬਰ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਸਹਿਯੋਗੀ ਕੋਈ ਪ੍ਰਤੀਨਿਧਤਾ ਜਾਂ ਵਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ ਹਨ ਅਤੇ ਸਾਰੀਆਂ ਵਾਰੰਟੀਆਂ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦੇ ਹਨ -ਉਲੰਘਣ, ਕਿਸੇ ਖਾਸ ਉਦੇਸ਼ ਲਈ ਤੰਦਰੁਸਤੀ, ਕਿ ਇਸ ਦਸਤਾਵੇਜ਼ ਦੀ ਸਮੱਗਰੀ ਗਲਤੀਆਂ ਤੋਂ ਮੁਕਤ ਹੈ।

ਕਾਨੂੰਨ ਦੁਆਰਾ ਵਰਜਿਤ ਨਾ ਹੋਣ ਦੀ ਹੱਦ ਤੱਕ, ਬਲੂਟੁੱਥ ਸਿਗ, ਇਸਦੇ ਮੈਂਬਰ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਸਹਿਯੋਗੀ ਇਸ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਕਿਸੇ ਵੀ ਸੂਚਨਾ, ਸੂਚਨਾ ਦੀ ਵਰਤੋਂ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੀ ਸਾਰੀ ਦੇਣਦਾਰੀ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦੇ ਹਨ UE, ਲਾਭ, ਡੇਟਾ ਜਾਂ ਪ੍ਰੋਗਰਾਮ, ਜਾਂ ਕਾਰੋਬਾਰ ਰੁਕਾਵਟ, ਜਾਂ ਵਿਸ਼ੇਸ਼, ਅਪ੍ਰਤੱਖ, ਪਰਿਣਾਮੀ, ਇਤਫਾਕ ਜਾਂ ਦੰਡਕਾਰੀ ਨੁਕਸਾਨਾਂ ਲਈ, ਹਾਲਾਂਕਿ, ਜਵਾਬਦੇਹੀ ਦੇ ਸਿਧਾਂਤ ਦੇ ਕਾਰਨ ਅਤੇ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਅਤੇ ਭਾਵੇਂ ਬਲੂਟੁੱਥ ਸਿਗ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅਜਿਹੇ ਨੁਕਸਾਨ ਦੀ ਸੰਭਾਵਨਾ ਦੇ.

ਇਹ ਦਸਤਾਵੇਜ਼ ਬਲੂਟੁੱਥ SIG ਦੀ ਮਲਕੀਅਤ ਹੈ। ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਬਲੂਟੁੱਥ SIG ਅਤੇ ਇਸ ਦੇ ਮੈਂਬਰਾਂ ਦੀ ਬੌਧਿਕ ਸੰਪੱਤੀ ਹੋਣ ਵਾਲੇ ਵਿਸ਼ਾ ਵਸਤੂ ਨੂੰ ਸ਼ਾਮਲ ਜਾਂ ਕਵਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ ਬਲੂਟੁੱਥ SIG ਜਾਂ ਇਸਦੇ ਮੈਂਬਰਾਂ ਦੀ ਕਿਸੇ ਬੌਧਿਕ ਸੰਪੱਤੀ ਨੂੰ ਕੋਈ ਲਾਇਸੈਂਸ ਨਹੀਂ ਦਿੰਦਾ ਹੈ।

ਇਹ ਦਸਤਾਵੇਜ਼ ਬਿਨਾਂ ਨੋਟਿਸ ਦੇ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।

1. ਜਾਣ-ਪਛਾਣ

ਨਿਰਧਾਰਨ ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ (SMPD) ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਨਿਰਧਾਰਨ ਲੇਖਕ ਅਤੇ ਮੁੜviewers ਨੂੰ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿਕਸਤ ਕਰਨ ਅਤੇ ਮੌਜੂਦਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵਧਾਉਣ ਲਈ (ਭਾਵ, ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਜੋੜਨ ਜਾਂ ਹਟਾਉਣ ਲਈ ਜਾਂ ਇੱਕ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਬਦਲਣ ਲਈ), ਅਪਣਾਏ ਗਏ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ, ਅਤੇ ਅਪਣਾਏ ਗਏ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅੰਤ ਦੇ ਜੀਵਨ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਮੁੜviewing, ਅਤੇ ਵਾਈਟ ਪੇਪਰ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ।

ਉਹਨਾਂ ਕਾਰਜਾਂ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਅੰਦਰੂਨੀ ਅੰਤਰ ਦੇ ਕਾਰਨ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਅਤੇ ਮੌਜੂਦਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵਧਾਉਣ ਦੇ ਵਿਚਕਾਰ ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਅੰਤਰ ਹਨ; ਉਹ ਅੰਤਰ ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਉਜਾਗਰ ਕੀਤੇ ਗਏ ਹਨ।

ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਲੋੜਾਂ ਦਾ ਪੜਾਅ (ਸੈਕਸ਼ਨ 3 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ)
ਇੱਕ ਵਿਕਾਸ ਪੜਾਅ (ਸੈਕਸ਼ਨ 4 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ) ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਅਤੇ ਦੁਬਾਰਾ ਕਰਨ ਲਈview ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਇੰਟਰਓਪਰੇਬਲ ਪ੍ਰੋਟੋਟਾਈਪ (IOP) ਟੈਸਟਿੰਗ ਦੇ ਜ਼ਰੀਏ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ (ਸੈਕਸ਼ਨ 5 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ)
ਗੋਦ ਲੈਣ/ਮਨਜ਼ੂਰੀ ਲਈ ਬਲੂਟੁੱਥ SIG ਬੋਰਡ ਆਫ਼ ਡਾਇਰੈਕਟਰਜ਼ (BoD) ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪੇਸ਼ ਕਰਨ ਲਈ ਇੱਕ ਗੋਦ/ਪ੍ਰਵਾਨਗੀ ਪੜਾਅ (ਸੈਕਸ਼ਨ 6 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ)

ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਇਰੱਟਾ ਪ੍ਰੋਸੈਸ ਦਸਤਾਵੇਜ਼ (EPD) [3] ਪ੍ਰਸਤਾਵਿਤ ਕਰਨ ਅਤੇ ਦੁਬਾਰਾ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।viewਨਿਰਧਾਰਨ ਇਰੱਟਾ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਵਜੋਂ ਮਨਜ਼ੂਰੀ ਦੇਣਾ (ਜਿਵੇਂ ਕਿ ਉਪ-ਨਿਯਮਾਂ [2] ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ) ਅਪਣਾਏ ਗਏ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ। ਜਦੋਂ ਤੱਕ ਹੋਰ ਨੋਟ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਇਸ SMPD ਵਿੱਚ ਇਰੱਟਾ ਦੇ ਸਾਰੇ ਹਵਾਲਿਆਂ ਦਾ ਮਤਲਬ ਨਿਰਧਾਰਨ ਇਰੱਟਾ ਹੈ।

1.1 ਤਰਜੀਹ

ਬਲੂਟੁੱਥ SIG, Inc. (Bylaws) ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਸਮਝੌਤਿਆਂ [2] ਦੇ ਉਪ-ਨਿਯਮਾਂ ਉਹਨਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ SMPD ਵਿੱਚ ਕਿਸੇ ਵੀ ਵਿਰੋਧੀ ਸਮੱਗਰੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ। ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕੁਝ ਵੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, BoD ਕੋਲ ਕਾਰਵਾਈ ਕਰਨ ਅਤੇ ਫੈਸਲੇ ਲੈਣ ਦਾ ਅੰਤਮ ਵਿਵੇਕ ਅਤੇ ਅਧਿਕਾਰ ਬਰਕਰਾਰ ਹੈ ਭਾਵੇਂ ਉਹ ਕਾਰਵਾਈਆਂ ਅਤੇ ਫੈਸਲੇ ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੇ, ਜਾਂ ਵਿਰੋਧ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕੁਝ ਵੀ BoD ਦੇ ਸੁਤੰਤਰ ਅਥਾਰਟੀ ਨੂੰ ਸੀਮਿਤ ਜਾਂ ਪ੍ਰਤਿਬੰਧਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਅਤੇ ਵਿਵੇਕ.

ਜੇਕਰ SMPD ਵਿੱਚ ਟੈਕਸਟ ਅਤੇ ਅੰਕੜਿਆਂ ਵਿੱਚ ਕੋਈ ਟਕਰਾਅ ਹੈ, ਤਾਂ ਟੈਕਸਟ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

1.2 ਸੰਦਰਭਿਤ ਸਮੂਹ ਅਤੇ ਕਮੇਟੀਆਂ

ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਿਮਨਲਿਖਤ ਕਿਸਮਾਂ ਦੇ ਸਮੂਹਾਂ ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ: ਅਧਿਐਨ ਸਮੂਹ (SG), ਮਾਹਰ ਸਮੂਹ (EG), ਅਤੇ ਕਾਰਜ ਸਮੂਹ (WG)। ਇੱਕ WG ਦਾ ਇੱਕ ਉਪ ਸਮੂਹ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਜੋ WG ਨੂੰ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਕਿਸਮਾਂ ਦੀਆਂ ਕਮੇਟੀਆਂ ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ: ਬਲੂਟੁੱਥ ਆਰਕੀਟੈਕਚਰਲ ਰੀview ਬੋਰਡ (BARB), ਬਲੂਟੁੱਥ ਟੈਸਟ ਅਤੇ ਇੰਟਰਓਪਰੇਬਿਲਟੀ (BTI), ਅਤੇ ਬਲੂਟੁੱਥ ਯੋਗਤਾ ਰੀview ਬੋਰਡ (BQRB)। ਇਹ ਦਸਤਾਵੇਜ਼ ਬਲੂਟੁੱਥ SIG ਟੈਕਨੀਕਲ ਸਟਾਫ (BSTS), ਅਤੇ BoD ਦਾ ਵੀ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ।

1.3 ਕਮੇਟੀ ਮੁੜviews ਅਤੇ ਪ੍ਰਵਾਨਗੀਆਂ

ਇੱਕ ਕਮੇਟੀ ਰੀview ਇੱਕ ਮੁੜ ਹੈview ਜੋ ਕਿ ਇੱਕ ਕਮੇਟੀ ਦੇ ਮੈਂਬਰਾਂ (ਆਮ ਤੌਰ 'ਤੇ 3 ਮੈਂਬਰ) ਦੁਆਰਾ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ (ਆਮ ਤੌਰ 'ਤੇ 2-3 ਹਫ਼ਤਿਆਂ) ਦੇ ਅੰਦਰ ਫੀਡਬੈਕ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਆਯੋਜਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਦੁਬਾਰਾview ਸਮਗਰੀ ਦੀ ਲੰਬਾਈ ਅਤੇ ਗੁੰਝਲਤਾ ਅਤੇ ਕਮੇਟੀ ਦੇ ਅੰਦਰ ਹੋਰ ਤਰਜੀਹਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸਮਾਂ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ। ਦੀ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਸਮੂਹ ਨੇ ਰੀview ਅਤੇ ਮੁੜ ਸੰਚਾਲਨ ਕਰਨ ਵਾਲੀ ਕਮੇਟੀview ਹਰ ਇੱਕ ਰੀ ਦੀ ਮਿਆਦ 'ਤੇ ਸਹਿਮਤ ਹੈview. ਗਰੁੱਪ ਅਤੇ ਕਮੇਟੀ ਮੈਂਬਰ ਰੀ ਦੀ ਸ਼ੁਰੂਆਤ ਅਤੇ ਅੰਤ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਅਤੇ ਰਿਕਾਰਡ ਕਰਨ ਲਈ ਬਲੂਟੁੱਥ SIG ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨview. ਜਦੋਂ ਇਹ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸਮੂਹ ਆਮ ਤੌਰ 'ਤੇ ਕਮੇਟੀ ਦੇ ਫੀਡਬੈਕ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰੇਗਾ। ਜਦੋਂ ਕਮੇਟੀ ਨੇ ਰੀview ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਸਮੂਹ ਕਮੇਟੀ ਫੀਡਬੈਕ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਦੇਰੀ ਨਾਲ ਪਹੁੰਚਣ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।view ਫੀਡਬੈਕ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਸਮੱਗਰੀ ਕਮੇਟੀ ਦੁਆਰਾ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਵਾਨਗੀ ਦੇ ਅਧੀਨ ਹੋ ਸਕਦੀ ਹੈ.

ਵਰਕਿੰਗ ਗਰੁੱਪ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ [4] ਦੀ ਪਾਲਣਾ ਵਿੱਚ ਕਮੇਟੀ ਮੈਂਬਰਾਂ ਦੀ ਵੋਟ ਦੁਆਰਾ ਇੱਕ ਕਮੇਟੀ ਦੀ ਪ੍ਰਵਾਨਗੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

1.4 ਮੈਂਬਰਾਂ ਲਈ ਨੋਟਿਸ ਅਤੇ ਸਮੱਗਰੀ ਦੀ ਪਹੁੰਚਯੋਗਤਾ

ਇਸ ਦਸਤਾਵੇਜ਼ ਦੇ ਅਨੁਸਾਰ ਮੈਂਬਰਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਸਾਰੇ ਨੋਟਿਸ ਈਮੇਲ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਤਕਨੀਕੀ ਅੱਪਡੇਟ। ਸੂਚਨਾਵਾਂ ਜੋ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਹਨ, ਉਹ ਸਾਰੇ ਸਰਗਰਮ ਮੈਂਬਰਾਂ ਨੂੰ ਭੇਜੀਆਂ ਜਾਣਗੀਆਂ (ਭਾਵ, ਜਿੱਥੇ ਮੈਂਬਰਸ਼ਿਪ ਨੂੰ ਮੁਅੱਤਲ, ਸਮਾਪਤ ਜਾਂ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਗਿਆ ਹੈ)। ਜਦੋਂ ਸੂਚਨਾਵਾਂ ਈਮੇਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਹਰੇਕ ਵਿਅਕਤੀ ਦੇ ਆਖਰੀ-ਜਾਣਿਆ ਈਮੇਲ ਪਤੇ (ਜਿਵੇਂ ਕਿ ਬਲੂਟੁੱਥ SIG ਦੇ ਉਸ ਸਮੇਂ ਦੇ ਮੌਜੂਦਾ ਰਿਕਾਰਡਾਂ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ) 'ਤੇ ਭੇਜਿਆ ਜਾਵੇਗਾ ਜਿਸ ਨੇ ਮੈਂਬਰ ਕੰਪਨੀ ਦੇ ਮੈਂਬਰਸ਼ਿਪ ਖਾਤੇ ਦੇ ਅਧੀਨ ਰਜਿਸਟਰ ਕੀਤਾ ਹੈ ਅਤੇ ਜਿਸ ਨੇ ਈਮੇਲ ਸੂਚਨਾਵਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਚੋਣ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕੁਝ ਵੀ ਬਲੂਟੁੱਥ SIG ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਜਾਂ ਲੋੜਾਂ ਨੂੰ ਬਾਈਲਾਜ਼ ਜਾਂ ਬਲੂਟੁੱਥ SIG ਅਤੇ ਕਿਸੇ ਮੈਂਬਰ ਵਿਚਕਾਰ ਕਿਸੇ ਹੋਰ ਸਮਝੌਤੇ ਦੇ ਤਹਿਤ ਨੋਟਿਸ ਦੇ ਪ੍ਰਬੰਧ ਦੇ ਸਬੰਧ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ ਹੈ।

ਜਿੱਥੇ ਕਿਤੇ ਵੀ ਇਹ ਦਸਤਾਵੇਜ਼ ਏ webਸਾਈਟ ਜੋ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਹੈ, ਇਹ ਉਹਨਾਂ ਵਿਅਕਤੀਆਂ ਲਈ ਪਹੁੰਚਯੋਗਤਾ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਇੱਕ ਸਰਗਰਮ ਬਲੂਟੁੱਥ SIG ਖਾਤਾ ਹੈ। ਜਿਨ੍ਹਾਂ ਮੈਂਬਰਾਂ ਕੋਲ ਕੋਈ ਕਿਰਿਆਸ਼ੀਲ ਖਾਤਾ ਨਹੀਂ ਹੈ, ਉਹ ਬਲੂਟੁੱਥ SIG ਰਾਹੀਂ ਖਾਤਾ ਬਣਾ ਸਕਦੇ ਹਨ webਸਾਈਟ.

1.5 ਨਮੂਨੇ

ਇਸ SMPD ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਰੇਕ ਦਸਤਾਵੇਜ਼ ਦੀ ਕਿਸਮ (ਉਦਾਹਰਨ ਲਈ, ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਸਫੈਦ ਕਾਗਜ਼, ਟੈਸਟ ਦਸਤਾਵੇਜ਼) ਲਈ, ਬਲੂਟੁੱਥ SIG ਇੱਕ ਟੈਂਪਲੇਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਟੈਂਪਲੇਟ ਨੂੰ ਇਸ SMPD ਦੇ ਅਨੁਸਾਰ ਤਿਆਰ ਕੀਤੇ ਹਰੇਕ ਦਸਤਾਵੇਜ਼ ਲਈ ਆਧਾਰ ਵਜੋਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਹੀ ਟੈਮਪਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਅਸਫਲਤਾ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਮਨਜ਼ੂਰੀ ਨਹੀਂ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਟੈਂਪਲੇਟ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਉਪਲਬਧ ਹਨ webਸਾਈਟ [8].

1.6 ਨਿਰਧਾਰਨ ਕਿਸਮਾਂ

ਬਲੂਟੁੱਥ SIG ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀਆਂ ਕਈ ਕਿਸਮਾਂ ਹਨ। ਲੜੀਵਾਰ ਤੌਰ 'ਤੇ, ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਲੂਟੁੱਥ ਕੋਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਵੇਂ ਕਿ ਰਵਾਇਤੀ ਪ੍ਰੋfiles; ਰਵਾਇਤੀ ਪ੍ਰੋਟੋਕੋਲ; ਅਤੇ GATT-ਅਧਾਰਿਤ ਪ੍ਰੋfiles, GATT-ਅਧਾਰਿਤ ਸੇਵਾਵਾਂ, ਅਤੇ GATT-ਅਧਾਰਿਤ ਪ੍ਰੋਟੋਕੋਲ ਸਾਰੇ ਕੋਰ ਨਿਰਧਾਰਨ ਦੇ ਅੰਦਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਜਿਵੇਂ ਕਿ ਮੇਸ਼ ਮਾਡਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਮੇਸ਼ ਪ੍ਰੋ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨfile ਨਿਰਧਾਰਨ ਜੋ ਬਦਲੇ ਵਿੱਚ ਕੋਰ ਨਿਰਧਾਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਕੋਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਸਪਲੀਮੈਂਟ (CSS) ਨਿਰਧਾਰਨ ਡੇਟਾ ਕਿਸਮਾਂ, ਡੇਟਾ ਫਾਰਮੈਟਾਂ ਅਤੇ ਆਮ ਪ੍ਰੋ.file ਅਤੇ ਸੇਵਾ ਅਸ਼ੁੱਧੀ ਕੋਡ ਜੋ ਕੋਰ ਨਿਰਧਾਰਨ ਅਤੇ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਿਸੇ ਵਿਵਹਾਰ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦੇ ਹਨ।

GATT ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਸਪਲੀਮੈਂਟ (GSS) ਨਿਰਧਾਰਨ ਵਿਸ਼ੇਸ਼ਤਾ ਅਤੇ ਵਰਣਨ ਕਰਨ ਵਾਲੇ ਫਾਰਮੈਟਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰੋ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨfiles ਅਤੇ ਸੇਵਾਵਾਂ ਅਤੇ ਖੁਦ ਕੋਈ ਵਿਵਹਾਰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ।
ਮੈਸ਼ ਡਿਵਾਈਸ ਪ੍ਰਾਪਰਟੀਜ਼ (MDP) ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਮੇਸ਼ ਪ੍ਰੋ ਦੁਆਰਾ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਜਾਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈfile ਅਤੇ ਜਾਲ ਮਾਡਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੋਈ ਵਿਵਹਾਰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ।

2. ਓਵਰview

ਇਹ ਭਾਗ ਇੱਕ ਓਵਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈview ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਅਤੇ ਸਾਰੇ ਵੇਰਵਿਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਹੈ।

ਚਿੱਤਰ 2.1 ਛੇ ਮੁੱਖ ਪੜਾਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਨਿਰਧਾਰਨ ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬਣਾਉਂਦੇ ਹਨ।

ਪਹਿਲੇ ਚਾਰ ਪੜਾਅ ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ ਹੁੰਦੇ ਹਨ ਅਤੇ ਲੋੜਾਂ ਦੇ ਪੜਾਅ (ਸੈਕਸ਼ਨ 3), ਵਿਕਾਸ ਪੜਾਅ (ਸੈਕਸ਼ਨ 4), ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ (ਸੈਕਸ਼ਨ 5), ਅਤੇ ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਪੜਾਅ (ਸੈਕਸ਼ਨ 6) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਾਅਦ ਗੋਦ ਲੈਣ ਤੋਂ ਬਾਅਦ ਦੇ ਦੋ ਪੜਾਅ ਆਉਂਦੇ ਹਨ: ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਮੇਨਟੇਨੈਂਸ ਫੇਜ਼ (ਸੈਕਸ਼ਨ 7) ਅਤੇ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਐਂਡ-ਆਫ-ਲਾਈਫ ਫੇਜ (ਸੈਕਸ਼ਨ 8)।

ਚਿੱਤਰ 2.2 ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ ਚਾਰ ਪੜਾਵਾਂ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਸਲੇਟੀ ਬਕਸੇ ਹਰੇਕ ਪੜਾਅ ਲਈ ਮੁੱਖ ਡਿਲੀਵਰੇਬਲ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਸੰਤਰੀ ਬਕਸੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਮੀਲਪੱਥਰ ਨੂੰ ਸੰਖੇਪ ਕਰਦੇ ਹਨ।

ਲੋੜਾਂ ਦੇ ਪੜਾਅ ਵਿੱਚ (ਸੈਕਸ਼ਨ 3 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ), ਨਵਾਂ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ (ਇੱਕ ਨਵਾਂ ਕੰਮ ਪ੍ਰਸਤਾਵ (NWP)) ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਕੇ ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਦਾ ਹੈ ਜੇਕਰ ਨਵਾਂ ਕੰਮ ਅੱਗੇ ਵਧਦਾ ਹੈ। ਜੇਕਰ NWP ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਨਿਰਧਾਰਤ ਸਮੂਹ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਦਸਤਾਵੇਜ਼ (FRD) ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ FRD ਨੂੰ ਮਨਜ਼ੂਰੀ ਮਿਲ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਸੌਂਪਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵਿਕਾਸ ਪੜਾਅ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਵਿਕਾਸ ਪੜਾਅ ਦੇ ਦੌਰਾਨ (ਸੈਕਸ਼ਨ 4 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ), ਨਿਰਧਾਰਨ ਵਿਕਾਸ s ਦੇ ਇੱਕ ਕ੍ਰਮ ਦੁਆਰਾ ਅੱਗੇ ਵਧਦਾ ਹੈtages (0.5/DIPD ਤੋਂ 0.9/CR) ਨਿਰਧਾਰਨ ਦੇ ਇੱਕ ਪੂਰੇ ਡਰਾਫਟ ਵਿੱਚ ਸਮਾਪਤ ਹੁੰਦਾ ਹੈ। 0.9/CR ਨਿਰਧਾਰਨ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਉਪਲਬਧ ਕਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ BoD ਨੂੰ ਜਮ੍ਹਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਪ੍ਰਵਾਨਗੀ ਲਈ ਨਿਰਧਾਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਬਾਅਦ, ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਦੇ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ (ਸੈਕਸ਼ਨ 5 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ) ਦੇ ਦੌਰਾਨ, BoD-ਪ੍ਰਵਾਨਿਤ 0.9/CR ਨਿਰਧਾਰਨ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਉਪਲਬਧ ਕਰਾਇਆ ਜਾਂਦਾ ਹੈview ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਅਤੇ ਮੈਂਬਰ ਰੀview ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਮੈਂਬਰਾਂ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਵਿਚਕਾਰ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ (IOP) ਟੈਸਟਿੰਗ ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਪੂਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਾਰ IOP ਟੈਸਟਿੰਗ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ (ਜੇਕਰ ਨਿਰਧਾਰਨ ਲਈ ਲੋੜ ਹੁੰਦੀ ਹੈ) ਅਤੇ BARB IOP ਟੈਸਟ ਰਿਪੋਰਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਗੋਦ ਲੈਣ/ਮਨਜ਼ੂਰੀ ਪੜਾਅ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਦੇ ਪੜਾਅ (ਸੈਕਸ਼ਨ 6 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ) ਦੌਰਾਨ, ਨਿਰਧਾਰਨ ਅਤੇ ਸੰਬੰਧਿਤ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; BARB, BQRB, ਅਤੇ BTI ਪ੍ਰਵਾਨਗੀਆਂ ਪ੍ਰਾਪਤ ਹੁੰਦੀਆਂ ਹਨ; ਅਤੇ ਅੰਤਮ ਨਿਰਧਾਰਨ ਪੈਕੇਜ BoD ਨੂੰ ਜਮ੍ਹਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਗੋਦ ਲੈਣ ਲਈ ਨਿਰਧਾਰਨ (ਭਾਵ, ਅੰਤਮ ਪ੍ਰਵਾਨਗੀ) 'ਤੇ ਵਿਚਾਰ ਕਰਦਾ ਹੈ।

ਇੱਕ ਨਿਰਧਾਰਨ ਨੂੰ ਇੱਕ ਪਿਛਲੇ ਪੜਾਅ 'ਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਐੱਸtage ਜੇਕਰ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸੈਕਸ਼ਨ 4.4 ਵਿੱਚ ਦੱਸੇ ਅਨੁਸਾਰ ਪੜਾਅ ਦੇ ਕੁਝ ਹਿੱਸੇ ਨੂੰ ਛੱਡਣਾ ਵੀ ਸੰਭਵ ਹੋ ਸਕਦਾ ਹੈ।

ਨਿਰਧਾਰਨ ਮੇਨਟੇਨੈਂਸ ਪੜਾਅ (ਸੈਕਸ਼ਨ 7 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ) BoD ਦੁਆਰਾ ਇੱਕ ਨਿਰਧਾਰਨ ਅਪਣਾਏ ਜਾਣ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇਸ ਪੜਾਅ ਦੇ ਦੌਰਾਨ ਇੱਕ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਵਿੱਚ ਪਾਈਆਂ ਗਈਆਂ ਸੰਭਾਵੀ ਗਲਤੀਆਂ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ (ਜੇ ਲੋੜ ਹੋਵੇ) ਨਿਰਧਾਰਨ ਵਿੱਚ ਇਰੱਟਾ ਸੁਧਾਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਨਿਰਧਾਰਨ ਰੱਖ-ਰਖਾਅ ਦਾ ਪੜਾਅ ਉਦੋਂ ਤੱਕ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਨਿਰਧਾਰਨ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਜਾਂਦਾ (ਹੇਠ ਦਿੱਤੇ ਪੈਰੇ ਵਿੱਚ ਨਿਰਧਾਰਨ ਅੰਤ-ਆਫ-ਲਾਈਫ ਪੜਾਅ ਦੇਖੋ)।

ਜੀਵਨ ਦੇ ਅੰਤ ਦੇ ਪੜਾਅ (ਸੈਕਸ਼ਨ 8 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ) ਨਿਰਧਾਰਨ ਅਪਣਾਏ ਗਏ ਵਿਵਰਣ ਨੂੰ ਨਾਪਸੰਦ ਕਰਨ ਅਤੇ ਵਾਪਸ ਲੈਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

3. ਲੋੜਾਂ ਦਾ ਪੜਾਅ

ਲੋੜਾਂ ਦਾ ਪੜਾਅ ਜਾਂ ਤਾਂ ਇੱਕ NWP (ਜੋ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ਾਂ 'ਤੇ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਇੱਛਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ) ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਾਂ ਇਹ ਨਿਸ਼ਚਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਿ ਲੋੜੀਂਦਾ ਨਵਾਂ ਕੰਮ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਦੇ WG ਚਾਰਟਰ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਜੇਕਰ ਕੋਈ WG ਨਵਾਂ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਜਿਸ ਬਾਰੇ ਉਹ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਇਸਦੇ WG ਚਾਰਟਰ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਹੈ, ਤਾਂ WG ਨੂੰ ਇੱਕ FRD ਵਿਕਸਿਤ ਕਰਨ ਲਈ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਅੱਗੇ ਵਧਣ ਲਈ ਸੈਕਸ਼ਨ 3.1 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਹੋਰ ਸਾਰੀਆਂ ਕੰਮ ਦੀਆਂ ਚੀਜ਼ਾਂ ਲਈ, WG ਨੂੰ ਸੈਕਸ਼ਨ 3.2 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। FRD ਉਹਨਾਂ ਕਾਰਜਾਤਮਕ ਲੋੜਾਂ ਦੇ ਦਾਇਰੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਵਿਕਾਸ ਪੜਾਅ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਲੋੜਾਂ ਦੇ ਪੜਾਅ ਨੂੰ ਚਿੱਤਰ 3.1 ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

3.1 WG ਚਾਰਟਰ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਗਿਆ ਨਵਾਂ ਕੰਮ

ਜਦੋਂ ਇੱਕ WG ਨਵਾਂ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ ਵਾਜਬ ਤੌਰ 'ਤੇ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹੈ ਕਿ ਜੋ ਕਾਰਜਸ਼ੀਲਤਾ ਉਹ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਹ ਪਹਿਲਾਂ ਹੀ ਇਸਦੇ WG ਚਾਰਟਰ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਹੈ, WG FRD 'ਤੇ ਕੰਮ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਬਸ਼ਰਤੇ ਉਹ BARB ਨੂੰ ਤੁਰੰਤ ਸੂਚਿਤ ਕਰੇ। WG BARB ਨੂੰ ਆਪਣੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਨਵੇਂ ਕੰਮ ਦਾ ਵੇਰਵਾ ਅਤੇ WG ਚਾਰਟਰ ਦੀ ਇੱਕ ਕਾਪੀ ਨੂੰ ਹਾਈਲਾਈਟ ਕੀਤੀ ਭਾਸ਼ਾ ਦੇ ਨਾਲ ਸ਼ਾਮਲ ਕਰੇਗਾ ਜੋ ਉਹਨਾਂ ਨੂੰ ਨਵਾਂ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ ਕਰਦਾ ਹੈ।

ਜੇਕਰ BARB WG ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ WG ਨੂੰ FRD 'ਤੇ ਕੰਮ ਬੰਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸੈਕਸ਼ਨ 3.2 ਵਿੱਚ ਦੱਸੀ ਗਈ NWP ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ BARB WG ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, ਤਾਂ WG ਤੁਰੰਤ BSTS ਨੂੰ ਸੂਚਿਤ ਕਰੇਗਾ (email ਰਾਹੀਂ specification.manager@bluetooth.com) ਅਤੇ BSTS ਆਈਟਮ ਨੂੰ ਅਗਲੇ BoD ਏਜੰਡੇ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੇਗਾ।

WG BSTS ਨੂੰ ਆਪਣੀ ਸੂਚਨਾ ਵਿੱਚ ਉਹੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਕਰੇਗਾ ਜੋ ਉਸਨੇ BARB ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੀ ਹੈ। ਜੇਕਰ BoD WG ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ WG ਨੂੰ FRD 'ਤੇ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸੈਕਸ਼ਨ 3.2 ਵਿੱਚ ਦੱਸੀ ਗਈ NWP ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ BoD WG ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, WG FRD 'ਤੇ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਸੈਕਸ਼ਨ 3.3 ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ।

3.2 ਨਵਾਂ ਕੰਮ ਪ੍ਰਸਤਾਵ (NWP)

ਕੋਈ ਵੀ ਮੈਂਬਰ, WG, SG, ਜਾਂ EG ਇੱਕ NWP ਬਣਾ ਸਕਦਾ ਹੈ ਅਤੇ ਜਮ੍ਹਾਂ ਕਰ ਸਕਦਾ ਹੈ (ਬਲੂਟੁੱਥ SIG ਰਾਹੀਂ webਸਾਈਟ [10]). ਇੱਕ NWP ਵਿੱਚ, ਘੱਟੋ-ਘੱਟ, [8] ਵਿੱਚ ਦਿੱਤੇ ਅਧਿਕਾਰਤ ਟੈਮਪਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼
ਐਫਆਰਡੀ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਸਦੱਸ ਦੀ ਵਚਨਬੱਧਤਾ ਅਤੇ ਕਿਹੜੇ ਖੇਤਰ(ਆਂ) ਵਿੱਚ (ਜਿਵੇਂ, ਯੋਗਦਾਨੀ, ਲੇਖਕ, ਮੁੜviewer, ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ)

FRD ਕੰਮ ਦੀ ਪ੍ਰਸਤਾਵਿਤ ਅਗਵਾਈ
FRD ਕੰਮ ਲਈ ਪ੍ਰਸਤਾਵਿਤ ਸਮੂਹ ਅਸਾਈਨਮੈਂਟ
ਪ੍ਰਾਇਮਰੀ ਲੇਖਕ (ਲੇਖਕਾਂ) ਦਾ ਈਮੇਲ ਪਤਾ

ਨੋਟ: NWP ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ ਮਾਰਗਦਰਸ਼ਨ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਉਪਲਬਧ ਹੈ webਸਾਈਟ [10].

BSTS NWP ਦੇ ਵਿਕਾਸ ਦੌਰਾਨ ਹੇਠ ਲਿਖੇ ਕੰਮ ਕਰੇਗਾ:

ਲੇਖਕ(ਆਂ) ਨੂੰ ਰਸੀਦ ਦੀ ਰਸੀਦ ਪ੍ਰਦਾਨ ਕਰੋ (ਆਮ ਤੌਰ 'ਤੇ ਰਸੀਦ ਦੇ ਸੱਤ ਕੈਲੰਡਰ ਦਿਨਾਂ ਦੇ ਅੰਦਰ) ਅਤੇ ਅਗਲੇ ਕਦਮਾਂ ਦੀ ਰੂਪਰੇਖਾ ਬਣਾਓ।

ਜੇ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਲੇਖਕ (ਲੇਖਕਾਂ) ਨਾਲ ਕੰਮ ਕਰੋ ਤਾਂ ਜੋ NWP ਸਪਸ਼ਟ ਅਤੇ ਸੰਪੂਰਨ ਹੋਵੇ। ਇਸ ਲਈ NWP ਦੇ ਕਈ ਦੁਹਰਾਓ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਜੇ NWP ਵਿੱਚ ਅਪਣਾਏ ਗਏ ਬਲੂਟੁੱਥ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਤਰੁੱਟੀਆਂ ਬਾਰੇ ਬਿਆਨ ਹਨ, ਤਾਂ ਲੇਖਕ(ਆਂ) ਨਾਲ ਕੰਮ ਕਰੋ file ਇੱਰਟਾ ਸਿਸਟਮ ਵਿੱਚ ਐਂਟਰੀਆਂ।
ਜੇਕਰ ਇਹ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ ਕਿ NWP ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਕੰਮ ਦੀ ਡੁਪਲੀਕੇਟ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਪ੍ਰਗਤੀ ਵਿੱਚ ਹੈ ਜਾਂ ਪਹਿਲਾਂ ਹੀ ਪੂਰਾ ਹੋ ਚੁੱਕਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੇ ਮੁਲਾਂਕਣ ਲਈ ਦੂਜੇ ਕੰਮ ਦੇ ਲੇਖਕ (ਲੇਖਕਾਂ) ਨੂੰ ਸੂਚਿਤ ਕਰੋ।

NWP ਨੂੰ NWP ਨੂੰ ਪੋਸਟ ਕਰੋ webਸਾਈਟ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਹੈ।
ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੋ ਕਿ NWP ਦੁਬਾਰਾ ਲਈ ਉਪਲਬਧ ਹੈview ਅਤੇ ਕੀ FRD ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਵਾਧੂ ਮੈਂਬਰ ਪ੍ਰਤੀਬੱਧਤਾ ਦੀ ਲੋੜ ਹੈ।

ਮੈਂਬਰ NWP ਬਾਰੇ ਸਵਾਲ ਪੁੱਛਣ ਜਾਂ ਫੀਡਬੈਕ ਦੇਣ ਲਈ ਲੇਖਕ (ਲੇਖਕਾਂ) ਨਾਲ ਸੰਪਰਕ ਕਰ ਸਕਦੇ ਹਨ।

ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਮੈਂਬਰ ਕੰਪਨੀਆਂ ਨੂੰ BoD ਪ੍ਰਵਾਨਗੀ ਲਈ ਉਮੀਦਵਾਰ ਬਣਨ ਲਈ NWP ਲਈ ਨਤੀਜੇ ਵਜੋਂ FRD ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਲਈ ਵਚਨਬੱਧ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਮੈਂਬਰ ਕੰਪਨੀ ਇੱਕ ਐਸੋਸੀਏਟ ਜਾਂ ਪ੍ਰਮੋਟਰ ਮੈਂਬਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। NWP ਦੀ BoD ਦੀ ਮਨਜ਼ੂਰੀ 'ਤੇ, BoD NWP ਨੂੰ ਇੱਕ ਮੌਜੂਦਾ ਸਾਰੇ-ਮੈਂਬਰ WG ਸਬਗਰੁੱਪ ਜਾਂ SG ਨੂੰ FRD (ਸੈਕਸ਼ਨ 3.3 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ) 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਸੌਂਪੇਗਾ। ਜੇਕਰ ਕੋਈ ਢੁਕਵਾਂ WG ਸਬਗਰੁੱਪ ਜਾਂ SG ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਇੱਕ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

NWPs ਲਈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਲੋੜੀਂਦੀ ਮੈਂਬਰ ਪ੍ਰਤੀਬੱਧਤਾ ਹੈ, BSTS ਹੇਠਾਂ ਦਿੱਤੇ ਵਾਧੂ ਕਾਰਜ ਕਰੇਗਾ:

NWP ਨੂੰ BoD ਦੁਆਰਾ ਮਨਜ਼ੂਰ ਕੀਤੇ ਜਾਣ ਦੇ ਪ੍ਰਸਤਾਵ ਤੋਂ ਘੱਟੋ-ਘੱਟ 13 ਦਿਨ ਪਹਿਲਾਂ, BARB ਨੂੰ ਸੂਚਿਤ ਕਰੋ, ਅਤੇ ਉਸ ਸਮੂਹ ਨੂੰ ਜਿਸ ਨੂੰ NWP ਨੂੰ ਅਸਾਈਨਮੈਂਟ ਲਈ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਗਈ ਹੈ, ਲੰਬਿਤ NWP ਮਨਜ਼ੂਰੀ ਬਾਰੇ। ਇਹ ਪ੍ਰਸਤਾਵਿਤ ਸਮੂਹ ਵਰਗੇ ਖੇਤਰਾਂ ਵਿੱਚ ਫੀਡਬੈਕ ਦਾ ਮੌਕਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਕੀ NWP ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦਾ ਕੰਮ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਆਦਿ।

ਪੂਰਾ ਹੋਇਆ NWP BoD ਨੂੰ ਜਮ੍ਹਾ ਕਰੋ।

ਜੇਕਰ NWP ਉਹਨਾਂ ਮੈਂਬਰਾਂ ਦੁਆਰਾ ਜਮ੍ਹਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਕਿਸੇ ਸਮੂਹ ਨਾਲ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੈਂਬਰ ਨੂੰ NWP ਨੂੰ BoD ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰੋ।
ਜੇਕਰ NWP ਨੂੰ ਇੱਕ ਸਮੂਹ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ NWP ਨੂੰ BoD ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ ਗਰੁੱਪ ਚੇਅਰ ਦੀ ਵਿਵਸਥਾ ਕਰੋ।

BARB ਦੀ ਚੇਅਰ ਅਤੇ ਗਰੁੱਪ ਦੀਆਂ ਚੇਅਰਾਂ ਨੂੰ, ਜਿਨ੍ਹਾਂ ਨੂੰ NWP ਦੁਆਰਾ ਅਸਾਈਨਮੈਂਟ ਲਈ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਨੂੰ BoD ਮੀਟਿੰਗ ਵਿੱਚ ਸੱਦਾ ਦਿਓ।
ਜੇਕਰ NWP ਨੂੰ BoD ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਗਈ ਹੈ ਅਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਉਸ ਸਮੂਹ ਨੂੰ ਸੂਚਿਤ ਕਰੋ ਜਿਸ ਨੂੰ ਇਹ ਨਿਯੁਕਤ ਕੀਤਾ ਗਿਆ ਸੀ; ਲੇਖਕ(s); NWP ਵਿੱਚ ਸਬੰਧਿਤ FRD ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਵਚਨਬੱਧ ਵਜੋਂ ਪਛਾਣੇ ਗਏ ਮੈਂਬਰ; ਅਤੇ ਜੇਕਰ NWP ਇੱਕ ਸਮੂਹ ਦੁਆਰਾ ਪ੍ਰਸਤਾਵਿਤ ਹੈ, ਨਤੀਜੇ ਦਾ ਸਮੂਹ ਅਤੇ ਅਗਲੇ ਕਦਮ।

BoD ਦੁਆਰਾ NWP ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਬਾਅਦ, NWP 'ਤੇ ਸਥਿਤੀ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ webਸਾਈਟ.

ਕਿਸੇ ਵੀ NWP ਨੂੰ BoD ਦੁਆਰਾ ਆਪਣੀ ਮਰਜ਼ੀ ਅਨੁਸਾਰ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈample, ਸਰੋਤ ਸੀਮਾਵਾਂ ਦੇ ਕਾਰਨ, ਜੇਕਰ ਕੰਮ ਪਹਿਲਾਂ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ, ਤਾਂ ਕੰਮ ਬਲੂਟੁੱਥ SIG (ਉਦਾਹਰਨ ਲਈ, ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਗਰਾਮਿੰਗ ਇੰਟਰਫੇਸ (API)) [2] ਦੇ ਸੰਚਾਲਨ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ, ਜਾਂ ਜੇਕਰ ਕੰਮ ਪ੍ਰਸਤਾਵਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ filed ਇੱਕ ਇਰੱਟਮ ਵਜੋਂ। ਜੇਕਰ NWP ਨੂੰ ਅਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ BSTS ਲੇਖਕ(ਆਂ), NWP ਵਿੱਚ ਪਛਾਣੇ ਗਏ ਮੈਂਬਰਾਂ ਨੂੰ ਸੰਬੰਧਿਤ FRD ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਵਚਨਬੱਧ ਵਜੋਂ ਸੂਚਿਤ ਕਰੇਗਾ, ਅਤੇ, ਜੇਕਰ NWP ਇੱਕ ਸਮੂਹ ਦੁਆਰਾ ਪ੍ਰਸਤਾਵਿਤ ਹੈ, ਸਮੂਹ। ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿੱਚ ਅਸਵੀਕਾਰ ਕਰਨ ਦਾ ਕੋਈ ਵੀ ਕਾਰਨ ਸ਼ਾਮਲ ਹੋਵੇਗਾ। ਲੇਖਕ, ਵਚਨਬੱਧ ਮੈਂਬਰ, ਜਾਂ ਸਮੂਹ ਅਸਵੀਕਾਰ ਦੀ ਅਪੀਲ ਕਰਨ ਲਈ BoD ਏਜੰਡੇ 'ਤੇ ਸਮੇਂ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹਨ।

ਜੇਕਰ ਕੋਈ ਮੈਂਬਰ ਜਾਂ ਸਮੂਹ ਇੱਕ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਵਿੱਚੋਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਹਟਾਉਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਮੂਹ ਜਾਂ ਮੈਂਬਰ ਨੂੰ ਇੱਕ NWP ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। NWP ਵਿੱਚ ਟੈਸਟ ਦੇ ਕੇਸਾਂ 'ਤੇ ਪ੍ਰਭਾਵ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਸਮੇਤ, ਪਛੜੇ ਅਨੁਕੂਲਤਾ ਅਤੇ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ 'ਤੇ ਹਟਾਉਣ ਦੇ ਪ੍ਰਭਾਵ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

CSS, GSS, ਜਾਂ MDP ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਸੁਧਾਰਾਂ ਲਈ NWPs ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ: ਆਮ ਤੌਰ 'ਤੇ, CSS, GSS, ਜਾਂ MDP ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅੱਪਡੇਟ ਉਹਨਾਂ ਦੇ ਆਪਣੇ NWPs ਵਾਲੇ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅੱਪਡੇਟ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੁੰਦੇ ਹਨ।

3.3 ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਦਸਤਾਵੇਜ਼ (FRD)

FRDs ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਇੱਕ FRD ਵਿੱਚ, ਘੱਟੋ-ਘੱਟ, [8] ਵਿੱਚ ਦਿੱਤੇ ਅਧਿਕਾਰਤ ਟੈਮਪਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼
ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ਾਂ ਦੇ ਅਧਾਰ ਤੇ ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ

ਨਤੀਜੇ ਵਜੋਂ ਵਿਸ਼ਿਸ਼ਟਤਾ (ਵਾਂ) ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਸਦੱਸ ਦੀ ਵਚਨਬੱਧਤਾ
ਅਨੁਮਾਨਿਤ ਭੂਮਿਕਾਵਾਂ ਲਈ ਮੈਂਬਰਾਂ ਦੁਆਰਾ ਵਿਕਲਪਿਕ ਪ੍ਰੋਟੋਟਾਈਪ ਸਮਰਥਨ
ਨਤੀਜੇ ਵਜੋਂ ਵਿਸ਼ਿਸ਼ਟਤਾ(ਆਂ) ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਸਿਫਾਰਸ਼ੀ WG

FRD ਵਿਕਾਸ

FRDs ਨੂੰ BSTS ਤੋਂ ਸੰਪਾਦਕੀ ਸਹਾਇਤਾ ਨਾਲ ਨਿਰਧਾਰਤ ਸਾਰੇ-ਮੈਂਬਰ WG ਸਬਗਰੁੱਪ ਜਾਂ SG ਮੈਂਬਰਾਂ ਦੁਆਰਾ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। FRD ਵਿਕਾਸ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲਾ ਕੋਈ ਵੀ ਮੈਂਬਰ ਗਰੁੱਪ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ।

FRDs ਨੂੰ ਨਤੀਜੇ ਵਜੋਂ ਨਿਰਧਾਰਨ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਦੋ (ਹਾਲਾਂਕਿ ਤਿੰਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ) ਐਸੋਸੀਏਟ- ਜਾਂ ਪ੍ਰਮੋਟਰ-ਪੱਧਰ ਦੀਆਂ ਮੈਂਬਰ ਕੰਪਨੀਆਂ ਦੀ ਪ੍ਰਤੀਬੱਧਤਾ ਦਰਸਾਉਣੀ ਚਾਹੀਦੀ ਹੈ। WGs ਜਾਂ SGs ਜੋ ਇੱਕ FRD ਜਮ੍ਹਾਂ ਕਰਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਸਮੂਹ ਮੈਂਬਰ ਕੰਪਨੀਆਂ ਤੋਂ ਵਿਆਪਕ ਸਮਰਥਨ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ FRD ਵਿੱਚ ਪਛਾਣੇ ਗਏ ਟੀਚੇ ਵਾਲੇ ਉਦਯੋਗ ਦੇ ਹਿੱਸੇ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ।

FRD ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਨਵੀਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵੱਧ ਤੋਂ ਵੱਧ ਟ੍ਰਾਂਸਪੋਰਟਾਂ ਅਤੇ ਮੌਜੂਦਾ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਮਰਥਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ, ਸਾਬਕਾ ਲਈample, GATT-ਅਧਾਰਿਤ ਪ੍ਰੋ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈfileਬੇਸਿਕ ਰੇਟ/ਐਕਸਟੈਂਡਡ ਡਾਟਾ ਰੇਟ (BR/EDR) ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਬਲੂਟੁੱਥ ਲੋ ਐਨਰਜੀ (LE) ਟ੍ਰਾਂਸਪੋਰਟ ਦੋਵਾਂ 'ਤੇ ਸੇਵਾਵਾਂ ਅਤੇ ਸੇਵਾਵਾਂ। ਜੇਕਰ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਟਰਾਂਸਪੋਰਟ ਲਈ ਲੋੜੀਂਦੇ ਮੈਂਬਰ ਸਮਰਥਨ ਦੀ ਘਾਟ ਹੈ, ਸਾਬਕਾ ਲਈampਟਰਾਂਸਪੋਰਟ ਦੀ ਵਰਤੋਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਮੈਂਬਰ ਪ੍ਰਤੀਬੱਧਤਾ ਦੀ ਘਾਟ ਜਾਂ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਭੂਮਿਕਾਵਾਂ ਲਈ IOP ਟੈਸਟ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਨਾਕਾਫ਼ੀ ਸੰਖਿਆ ਦੇ ਕਾਰਨ, ਉਸ ਟ੍ਰਾਂਸਪੋਰਟ 'ਤੇ ਸਮਰਥਨ ਨੂੰ FRD ਤੋਂ ਬਾਹਰ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਤੱਕ ਹੋਰ ਜਾਇਜ਼ ਨਹੀਂ, ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ, ਪ੍ਰੋfiles, ਅਤੇ ਸੇਵਾਵਾਂ ਸੈਕਸ਼ਨ 3.3.2 ਵਿੱਚ ਵਰਣਿਤ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

WG ਜਾਂ SG ਨੂੰ ਦੁਬਾਰਾ ਲਈ FRD ਨੂੰ BARB ਕੋਲ ਜਮ੍ਹਾਂ ਕਰਾਉਣਾ ਚਾਹੀਦਾ ਹੈview ਅਤੇ ਪ੍ਰਵਾਨਗੀ. BARB ਨੂੰ ਆਪਣੇ ਇੰਜੀਨੀਅਰਿੰਗ ਨਿਰਣੇ ਦੇ ਆਧਾਰ 'ਤੇ FRD ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ BARB ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ FRD ਨੂੰ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਉਪਲਬਧ ਕਰਾਇਆ ਜਾਵੇਗਾ ਅਤੇ ਇਸਦੀ ਉਪਲਬਧਤਾ ਦੀ ਸੂਚਨਾ BSTS ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੀ ਜਾਵੇਗੀ।

CSS, GSS, ਜਾਂ MDP ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਸੁਧਾਰਾਂ ਲਈ FRDs ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ: ਆਮ ਤੌਰ 'ਤੇ, CSS, GSS, ਜਾਂ MDP ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅੱਪਡੇਟ ਉਹਨਾਂ ਦੇ ਆਪਣੇ FRDs ਵਾਲੇ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅੱਪਡੇਟ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੁੰਦੇ ਹਨ।

ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ

BR/EDR ਲਈ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ

BR/EDR ਓਪਰੇਸ਼ਨ ਲਈ, ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਲੋੜ ਨੂੰ ਬਲੂਟੁੱਥ ਕੋਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ v1.1 ਅਤੇ ਬਾਅਦ ਦੇ BR/EDR ਹਿੱਸੇ ਦੇ ਨਾਲ ਇੰਟਰਓਪ੍ਰੇਸ਼ਨ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਬਲੂਟੁੱਥ ਲੋਅ ਐਨਰਜੀ ਲਈ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ

LE ਓਪਰੇਸ਼ਨ ਲਈ, ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਲੋੜ ਨੂੰ ਬਲੂਟੁੱਥ ਕੋਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ v4.0 ਅਤੇ ਬਾਅਦ ਦੇ LE ਹਿੱਸੇ ਦੇ ਨਾਲ ਇੰਟਰਓਪਰੇਸ਼ਨ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਕੋਰ ਨਿਰਧਾਰਨ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ

ਬਲੂਟੁੱਥ ਕੋਰ ਨਿਰਧਾਰਨ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ, ਦਿੱਤੇ ਗਏ ਸੰਸਕਰਣ ਦੀ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਨੂੰ ਉਹਨਾਂ ਸਾਰੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਨਾਲ ਬਣਾਈ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਹਨਾਂ ਦਾ ਇੱਕੋ ਵੱਡਾ ਸੰਸਕਰਣ ਨੰਬਰ ਹੈ। ਸਾਬਕਾ ਲਈample, ਸੰਸਕਰਣ 1.3 ਦਾ ਸੰਸਕਰਣ 1.2, 1.1, ਅਤੇ 1.0 ਦੇ ਅਨੁਕੂਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਸੰਸਕਰਣ 2.0 ਸੰਸਕਰਣ 1.0, 1.1, 1.2, ਅਤੇ 1.3 ਦੇ ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਕੋਰ ਨਿਰਧਾਰਨ ਦੇ ਪ੍ਰਮੁੱਖ ਸੰਸਕਰਣ ਸੰਖਿਆ ਵਿੱਚ ਵਾਧਾ ਪਿਛਲੇ ਸੰਸਕਰਣਾਂ ਦੇ ਨਾਲ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਦੀ ਕਮੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਨਹੀਂ ਹੈ।

ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ ਤੋਂ ਛੋਟ

WG ਜਾਂ SG ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ ਤੋਂ ਖਾਸ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਛੋਟ ਦੇਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ ਉਚਿਤਤਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਾਬਕਾ ਲਈample, ਜੇਕਰ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਘੱਟ ਮਾਰਕੀਟ ਗੋਦ ਲੈਣ ਦੀਆਂ ਦਰਾਂ ਦਿਖਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜਾਂ, ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ ਮੁੱਦਿਆਂ ਦੇ ਕਾਰਨ, ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਸੋਧਣ ਨਾਲੋਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਹਟਾਉਣਾ ਜਾਂ ਬਦਲਣਾ ਬਿਹਤਰ ਹੈ। WG ਜਾਂ SG ਨੂੰ FRD ਵਿੱਚ ਕੋਈ ਵੀ ਪਛੜੀਆਂ ਅਨੁਕੂਲਤਾ ਛੋਟਾਂ ਸ਼ਾਮਲ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਜੋ FRD ਦੀ ਮਨਜ਼ੂਰੀ 'ਤੇ BARB ਦੁਆਰਾ ਮਨਜ਼ੂਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਕੋਈ ਵੀ BARB-ਪ੍ਰਵਾਨਿਤ ਛੋਟਾਂ ਨੂੰ 0.9/CR S 'ਤੇ ਮਨਜ਼ੂਰੀ ਲਈ BoD ਨੂੰ ਪੇਸ਼ ਕੀਤਾ ਜਾਵੇਗਾtage.

3.4 ਵਰਕਿੰਗ ਗਰੁੱਪ ਚਾਰਟਰ

ਜਦੋਂ BARB ਇੱਕ FRD ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਮੌਜੂਦਾ WG ਨੂੰ ਸੌਂਪੇ ਜਾਣ ਦੀ ਤਜਵੀਜ਼ ਹੈ, ਤਾਂ WG ਨੂੰ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਸਕੋਪ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਆਪਣੇ ਚਾਰਟਰ ਲਈ ਇੱਕ ਡਰਾਫਟ ਅੱਪਡੇਟ ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਜਦੋਂ ਤੱਕ BoD ਨੇ ਪਹਿਲਾਂ WG ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਮਨਜ਼ੂਰੀ ਨਹੀਂ ਦਿੱਤੀ ਸੀ ਕਿ ਇੱਕ WG ਚਾਰਟਰ ਅੱਪਡੇਟ ਹੈ। ਲੋੜ ਨਹੀਂ). ਹਾਲਾਂਕਿ, ਜਦੋਂ BARB ਇੱਕ FRD ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਨਵੇਂ WG ਨੂੰ ਸੌਂਪੇ ਜਾਣ ਦਾ ਪ੍ਰਸਤਾਵ ਹੈ, BARB ਅਤੇ FRD ਵਿੱਚ ਦੱਸੇ ਗਏ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੇ ਮੈਂਬਰਾਂ ਨੂੰ ਚਾਰਟਰ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਸ਼ਾਮਲ ਨਵੀਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੇ ਨਾਲ ਇੱਕ ਨਵੇਂ WG ਲਈ ਇੱਕ ਡਰਾਫਟ ਚਾਰਟਰ ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। .

ਇੱਕ ਵਾਰ ਨਵਾਂ ਜਾਂ ਅੱਪਡੇਟ ਕੀਤਾ WG ਚਾਰਟਰ ਤਿਆਰ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਇਸਨੂੰ ਦੁਬਾਰਾ ਲਈ BARB ਕੋਲ ਜਮ੍ਹਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈview ਅਤੇ ਪ੍ਰਵਾਨਗੀ. ਇੱਕ ਵਾਰ ਜਦੋਂ BARB ਚਾਰਟਰ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਨਵੇਂ ਜਾਂ ਅੱਪਡੇਟ ਕੀਤੇ WG ਚਾਰਟਰ ਦਾ ਖਰੜਾ ਪ੍ਰਵਾਨਗੀ ਲਈ BoD ਨੂੰ ਜਮ੍ਹਾ ਕੀਤਾ ਜਾਵੇਗਾ।

ਇੱਕ ਵਾਰ ਜਦੋਂ BoD ਚਾਰਟਰ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੰਦਾ ਹੈ, ਤਾਂ WG ਜਿਸ ਨੂੰ BoD ਦੁਆਰਾ ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਕਾਰਜ ਸੌਂਪਿਆ ਗਿਆ ਸੀ, ਨੂੰ ਉਸ ਸਮੂਹ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨੇ FRD ਨੂੰ ਤਿਆਰ ਕੀਤਾ ਹੈ ਜੇਕਰ ਉਸ FRD ਲਈ ਕੋਈ ਜ਼ਰੂਰੀ ਅੱਪਡੇਟ ਜਾਂ ਸਪੱਸ਼ਟੀਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਵਿਕਾਸ ਪੜਾਅ ਦੌਰਾਨ ਇੱਕ FRD ਅੱਪਡੇਟ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸੈਕਸ਼ਨ 3.3 ਅਤੇ ਇਸ ਭਾਗ ਵਿੱਚ ਦਰਸਾਏ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਪਾਲਣਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ; ਹਾਲਾਂਕਿ, ਨਿਰਧਾਰਨ ਵਿਕਾਸ FRD ਅਤੇ WG ਚਾਰਟਰ ਅੱਪਡੇਟਾਂ ਦੇ ਸਮਾਨਾਂਤਰ ਹੋ ਸਕਦਾ ਹੈ।

3.5 ਲੋੜਾਂ ਪੜਾਅ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦੀਆਂ ਲੋੜਾਂ

ਲੋੜਾਂ ਦਾ ਪੜਾਅ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਵਿਕਾਸ ਪੜਾਅ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ FRD ਲਈ ਲੋੜੀਂਦੇ ਸਕੋਪ ਵਾਲੇ WG ਚਾਰਟਰ ਦੀ BoD ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਾਂ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:

NWP ਨੂੰ ਜਾਂ ਤਾਂ BoD ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਗਈ ਹੈ, ਜਾਂ BoD ਨੇ ਸਹਿਮਤੀ ਦਿੱਤੀ ਹੈ ਕਿ ਇੱਕ NWP ਬੇਲੋੜੀ ਹੈ।

FRD ਅਤੇ ਸੰਬੰਧਿਤ WG ਚਾਰਟਰ ਨੂੰ BARB ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਗਈ ਹੈ।

4. ਵਿਕਾਸ ਪੜਾਅ

ਵਿਕਾਸ ਪੜਾਅ ਦੇ ਦੌਰਾਨ, ਨਿਰਧਾਰਤ WG(s) ਨਵੀਂ ਨਿਰਧਾਰਨ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ/ਜਾਂ ਮੌਜੂਦਾ ਨਿਰਧਾਰਨ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ। FRD ਨਵੇਂ ਜਾਂ ਵਿਸਤ੍ਰਿਤ ਬਲੂਟੁੱਥ ਨਿਰਧਾਰਨ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਨਿਰਧਾਰਨ ਵਿੱਚ ਕਿਸੇ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ ਜੋ FRD ਵਿੱਚ ਲੋੜਾਂ ਨਾਲ ਵਾਜਬ ਤੌਰ 'ਤੇ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹੈ। ਉਦੇਸ਼ ਇੱਕ 0.9/CR ਨਿਰਧਾਰਨ ਬਣਾਉਣਾ ਹੈ ਜੋ ਵਿਕਾਸ ਪੜਾਅ ਦੀ ਸਮਾਪਤੀ 'ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ (ਸੈਕਸ਼ਨ 5 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ) ਲਈ ਤਿਆਰ ਹੈ।
ਵਿਕਾਸ ਪੜਾਅ ਦੇ ਦੌਰਾਨ, ਇੱਕ ਸਪੈਸੀਫਿਕੇਸ਼ਨ (ਜਾਂ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਇਨਹਾਂਸਮੈਂਟ) ਤਿੰਨ ਐੱਸtages.

ਨਵੇਂ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲਈ ਤਿੰਨ ਐੱਸtagਇਹ ਹਨ:

0.5 ਐੱਸtage
0.7 ਐੱਸtage

0.9 ਐੱਸtage

ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਵਧਾਉਣ ਲਈ, ਤਿੰਨ ਐੱਸtagਇਹ ਹਨ:

ਡਰਾਫਟ ਸੁਧਾਰ ਪ੍ਰਸਤਾਵ ਦਸਤਾਵੇਜ਼ (DIPD) ਐੱਸtage

ਅੰਤਿਮ ਸੁਧਾਰ ਪ੍ਰਸਤਾਵ ਦਸਤਾਵੇਜ਼ (FIPD) ਐੱਸtage
ਤਬਦੀਲੀ ਦੀ ਬੇਨਤੀ (CR) ਐੱਸtage

ਹਰੇਕ ਐੱਸtage ਦਾ ਅੱਗੇ ਉਪਭਾਗਾਂ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਹੇਠਾਂ ਚਿੱਤਰ 4.1 ਵੱਖ-ਵੱਖ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਡਬਲਯੂ.ਜੀ. ਹਰ ਇੱਕ 'ਤੇ ਤਿਆਰ ਕਰੇਗਾtage.

ਚਿੱਤਰ 4.1: ਵੱਧview ਨਿਰਧਾਰਨ ਦੇ ਐੱਸtages ਜੋ ਵਿਕਾਸ ਪੜਾਅ ਦੌਰਾਨ ਵਾਪਰਦਾ ਹੈ

ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ BARB ਦੀ ਭੂਮਿਕਾ WGs ਨੂੰ ਸਲਾਹ ਅਤੇ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ। ਡਬਲਯੂ.ਜੀ., ਕਿਸੇ ਵੀ ਸਮੇਂ, ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਅਤੇ ਆਰਕੀਟੈਕਚਰਲ ਸੰਕਲਪਾਂ ਬਾਰੇ ਤਕਨੀਕੀ ਸਲਾਹ ਲਈ BARB ਨੂੰ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹਨ। ਡਬਲਯੂ.ਜੀ. ਨੂੰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ BARB ਤੋਂ ਸ਼ੁਰੂਆਤੀ ਫੀਡਬੈਕ ਮੰਗਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਆਰਕੀਟੈਕਚਰਲ ਵਿਚਾਰ ਹਨ।

4.1 0.5/DIPD ਐੱਸtage

0.5/DIPD ਦੇ ਦੌਰਾਨ ਐੱਸtage, WG [8] ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਅਧਿਕਾਰਤ ਟੈਂਪਲੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਾਸ ਕਰੇਗਾ:

ਇੱਕ ਨਵੇਂ ਨਿਰਧਾਰਨ ਲਈ, 0.5 ਨਿਰਧਾਰਨ ਦਾ ਇੱਕ ਡਰਾਫਟ, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠ ਲਿਖੀਆਂ ਜਾਣਕਾਰੀਆਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

FRD ਵਿੱਚ ਦੱਸੇ ਅਨੁਸਾਰ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਆਰਕੀਟੈਕਚਰ

ਪ੍ਰੋਟੋਕੋਲ ਲਈ, ਸੇਵਾ ਪਹੁੰਚ ਪੁਆਇੰਟ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ
ਸੇਵਾਵਾਂ ਲਈ, ਉਜਾਗਰ ਡੇਟਾ ਅਤੇ ਵਿਵਹਾਰ
ਪ੍ਰੋ ਲਈfiles, ਪ੍ਰੋਟੋਕੋਲ ਪਛਾਣੇ ਗਏ ਅਤੇ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ

2. ਨਿਰਧਾਰਨ ਵਧਾਉਣ ਲਈ, DIPD ਦਾ ਇੱਕ ਡਰਾਫਟ, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠ ਲਿਖੀਆਂ ਜਾਣਕਾਰੀਆਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

ਪਿਛੋਕੜ: ਕੰਮ ਦਾ ਦਾਇਰਾ, ਕੰਮ ਦੀ ਅਗਵਾਈ ਕਰਨ ਵਾਲੇ ਉਦੇਸ਼, ਅਤੇ ਇਹ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਸਤਾਵ ਦਾਇਰੇ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ
ਵੱਧview ਪ੍ਰਸਤਾਵ ਦਾ: ਡੀਆਈਪੀਡੀ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਵਿਸਤ੍ਰਿਤ ਕਾਰਜਸ਼ੀਲਤਾ (ਜੋੜੀ ਗਈ ਲਚਕਤਾ, ਸੁਧਾਰੀ ਕਾਰਗੁਜ਼ਾਰੀ, ਆਦਿ) ਦਾ ਇੱਕ ਸਾਰ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਵਰਣਨ ਸ਼ਾਮਲ ਹੈ ਕਿ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਮੌਜੂਦਾ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੈ। ਜੇਕਰ WG ਨੇ ਕਈ ਤਜਵੀਜ਼ਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ ਹੈ, ਤਾਂ BARB ਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦਾ ਮੌਕਾ ਦੇਣ ਲਈ ਇਹਨਾਂ ਪ੍ਰਸਤਾਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਤਰਜੀਹੀ ਪ੍ਰਸਤਾਵ ਦੀ ਚੋਣ ਵਿੱਚ ਲੋੜੀਂਦੀ ਮਿਹਨਤ ਕੀਤੀ ਗਈ ਸੀ।

ਲੋੜਾਂ ਦੀ ਕਵਰੇਜ: ਸੰਬੰਧਿਤ FRD ਵਿੱਚ ਦਿੱਤੀਆਂ ਉਚਿਤ ਸਿਸਟਮ ਲੋੜਾਂ ਅਤੇ ਵਰਤੋਂ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਦੇ ਸੰਦਰਭ ਦੇ ਨਾਲ, ਪ੍ਰਸਤਾਵ ਦੁਆਰਾ ਦਿੱਤੀਆਂ ਗਈਆਂ ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਦੇ ਕਵਰੇਜ ਦਾ ਸਾਰ
ਸਮੱਸਿਆ ਦੀ ਪਰਿਭਾਸ਼ਾ: ਪ੍ਰਸਤਾਵ (ਨਾਂ) ਦੁਆਰਾ ਹੱਲ ਕੀਤੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਬਿਆਨ
ਚੋਣ ਮਾਪਦੰਡ: ਸੰਬੰਧਿਤ ਮੁਲਾਂਕਣ ਮੈਟ੍ਰਿਕਸ ਤੋਂ ਚੋਣ/ਪ੍ਰਦਰਸ਼ਨ ਮਾਪਦੰਡਾਂ ਬਾਰੇ ਇੱਕ ਬਿਆਨ ਜਿਸ ਨੇ ਚੋਣ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੇਧ ਦਿੱਤੀ ਹੈ

ਚੋਣ ਦਾ ਪ੍ਰਮਾਣ: ਮੁਲਾਂਕਣ ਮੈਟ੍ਰਿਕਸ ਦੀ ਇੱਕ ਜਾਂਚ ਜੋ ਪ੍ਰਸਤਾਵਾਂ ਵਿਚਕਾਰ ਚੋਣ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦੀ ਹੈ ਅਤੇ ਵਪਾਰ-ਆਫਾਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੀ ਹੈ
ਵਰਣਨ: ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਵੇਰਵਾ। ਇਹ ਸੈਕਸ਼ਨ ਸੰਬੰਧਿਤ ਉਪ-ਭਾਗਾਂ ਨੂੰ ਜੋੜ ਕੇ ਵੱਖ-ਵੱਖ ਲੋੜਾਂ ਮੁਤਾਬਕ ਢਾਲ ਸਕਦਾ ਹੈ।

3. ਟੈਸਟ ਰਣਨੀਤੀ: ਬਲੂਟੁੱਥ ਯੋਗਤਾ ਪ੍ਰੋਗਰਾਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਟੈਸਟ ਕੀਤੇ ਜਾਣ ਦੀ ਤਜਵੀਜ਼ ਕੀਤੀ ਗਈ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦਾ ਵਰਣਨ (ਜਾਂ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ) ਅਤੇ ਇਸ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਤਜਵੀਜ਼ ਕੀਤੀ ਗਈ ਕਾਰਜਕੁਸ਼ਲਤਾ (ਜਿਵੇਂ ਕਿ ਹੇਠਲੇ ਟੈਸਟਰ(ਜ਼) ਜਾਂ ਉਪਰਲੇ ਟੈਸਟਰ(ਜ਼) 'ਤੇ ਉਮੀਦਾਂ, ਅਤੇ ਜੇਕਰ ਟੈਸਟਾਂ ਨੂੰ ਅਨੁਕੂਲਤਾ ਜਾਂ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ ਟੈਸਟਾਂ ਜਾਂ ਦੋਵਾਂ ਦੇ ਸੁਮੇਲ ਵਜੋਂ ਮੰਨਿਆ ਜਾਵੇਗਾ)। ਇਹ 0.5/DIPD ਨਿਰਧਾਰਨ ਦੇ ਅੰਦਰ ਇੱਕ ਵੱਖਰੇ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਇੱਕ ਵੱਖਰੇ ਭਾਗ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ। ਟੈਸਟ ਰਣਨੀਤੀ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸੰਮੇਲਨਾਂ ਦਾ ਵਰਣਨ ਟੈਸਟ ਰਣਨੀਤੀ ਅਤੇ ਸ਼ਬਦਾਵਲੀ ਓਵਰ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਹੈview ਦਸਤਾਵੇਜ਼ (TSTO) [5].

ਇਸ 'ਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕ ਐੱਸtage WG ਮੈਂਬਰ ਅਤੇ BARB ਹਨ ਜੋ ਮੁੜview ਆਰਕੀਟੈਕਚਰਲ ਪ੍ਰਸਤਾਵਾਂ ਅਤੇ ਲੋੜਾਂ ਦੀ ਕਵਰੇਜ, ਅਤੇ ਬੀ.ਟੀ.ਆਈviewਟੈਸਟ ਦੀ ਰਣਨੀਤੀ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਸ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਐੱਸtage ਦਾ ਉਦੇਸ਼ ਉਹ ਟੈਕਸਟ ਸ਼ਾਮਲ ਕਰਨਾ ਨਹੀਂ ਹੈ ਜੋ ਅੰਤਮ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਯੋਜਨਾ ਹੈ।

BSTS ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview ਬਲੂਟੁੱਥ ਡਰਾਫਟ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ [1] ਨਾਲ ਇਕਸਾਰਤਾ ਲਈ ਸਾਰੇ ਦਸਤਾਵੇਜ਼ ਅਤੇ WG ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਮੁੱਦਿਆਂ ਦੀ ਪਛਾਣ ਕਰੋ। BARB ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview 0.5/DIPD ਨਿਰਧਾਰਨ। ਇੱਕ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਲਈ, BARB ਨੂੰ ਵੀ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview ਸੈਕਸ਼ਨ 3.3.2 ਵਿੱਚ ਵਰਣਿਤ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ ਲਈ DIPD। BTI ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview ਟੈਸਟ ਦੀ ਰਣਨੀਤੀ.

BARB ਨੂੰ ਆਪਣੇ ਇੰਜੀਨੀਅਰਿੰਗ ਨਿਰਣੇ ਦੇ ਆਧਾਰ 'ਤੇ 0.5/DIPD ਨਿਰਧਾਰਨ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ BARB ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ 0.5/DIPD ਨਿਰਧਾਰਨ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਉਪਲਬਧ ਕਰਾਇਆ ਜਾਵੇਗਾ। webਸਾਰੇ ਐਸੋਸੀਏਟ ਅਤੇ ਪ੍ਰਮੋਟਰ ਮੈਂਬਰਾਂ ਨੂੰ ਸਾਈਟ ਅਤੇ ਇਸਦੀ ਉਪਲਬਧਤਾ ਦੀ ਸੂਚਨਾ BSTS ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੀ ਜਾਵੇਗੀ। 0.5/DIPD 'ਤੇ ਐੱਸtage, ਟੈਸਟ ਰਣਨੀਤੀ ਦੀ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
0.5/DIPD ਐੱਸtage ਦੀ CSS, GSS, ਜਾਂ MDP ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਸੁਧਾਰਾਂ ਲਈ ਲੋੜ ਨਹੀਂ ਹੈ

0.5/DIPD ਐੱਸtage ਬਾਹਰ ਜਾਣ ਦੀਆਂ ਲੋੜਾਂ

0.5/DIPD ਐੱਸtage ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ ਅਤੇ 0.7/FIPD Stage ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਨਿਮਨਲਿਖਤ ਨਿਕਾਸ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ:

ਬੀ.ਐੱਸ.ਟੀ.ਐੱਸ. ਨੇ ਮੁੜ ਮੁਕੰਮਲ ਕਰ ਲਿਆ ਹੈview0.5/DIPD ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਰਣਨੀਤੀ ਨੂੰ ਲਾਗੂ ਕਰਨਾ।

BARB ਨੇ 0.5/DIPD ਨਿਰਧਾਰਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੱਤੀ ਹੈ।
ਬੀ.ਟੀ.ਆਈ. ਨੇ ਆਪਣਾ ਮੁੜ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈview ਟੈਸਟ ਰਣਨੀਤੀ ਦੇ.
BSTS ਨੇ ਸਾਰੇ ਐਸੋਸੀਏਟ ਅਤੇ ਪ੍ਰਮੋਟਰ ਮੈਂਬਰਾਂ ਲਈ ਮਨਜ਼ੂਰਸ਼ੁਦਾ 0.5/DIPD ਨਿਰਧਾਰਨ ਉਪਲਬਧ ਕਰਾਇਆ ਹੈ।

4.2 0.7/ਐਫਆਈਪੀਡੀ ਐਸtage

0.7/ਐਫਆਈਪੀਡੀ ਦੇ ਦੌਰਾਨ ਐਸtage, WG [8] ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਅਧਿਕਾਰਤ ਟੈਂਪਲੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਾਸ ਕਰੇਗਾ:

ਇੱਕ ਨਵੇਂ ਨਿਰਧਾਰਨ ਲਈ, 0.7 ਨਿਰਧਾਰਨ ਦਾ ਇੱਕ ਡਰਾਫਟ, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠ ਲਿਖੀਆਂ ਜਾਣਕਾਰੀਆਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

BARB-ਪ੍ਰਵਾਨਿਤ 0.5 ਤੋਂ ਬਾਅਦ ਕੀਤੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦਾ ਵੇਰਵਾ, ਜਿਸ ਵਿੱਚ ਨਵੇਂ ਜਾਂ ਸੋਧੇ ਹੋਏ ਪ੍ਰਸਤਾਵ, ਚੋਣ ਦੇ ਮਾਪਦੰਡ, ਅਤੇ ਚੋਣ ਦਾ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ ਸ਼ਾਮਲ ਹੈ। ਤਬਦੀਲੀਆਂ ਨੂੰ ਵੇਰਵੇ ਦੇ ਉਸੇ ਪੱਧਰ 'ਤੇ ਵਰਣਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਕਿ 0.5 S ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈtage.

FRD ਤੋਂ ਸਾਰੀਆਂ ਕਾਰਜਾਤਮਕ ਲੋੜਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕੀਤਾ ਗਿਆ।

2. ਨਿਰਧਾਰਨ ਵਧਾਉਣ ਲਈ, FIPD ਦਾ ਇੱਕ ਡਰਾਫਟ, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠ ਲਿਖੀਆਂ ਜਾਣਕਾਰੀਆਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

BARB-ਪ੍ਰਵਾਨਿਤ DIPD ਤੋਂ ਬਾਅਦ ਕੀਤੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦਾ ਵੇਰਵਾ, ਜਿਸ ਵਿੱਚ ਨਵੇਂ ਜਾਂ ਸੋਧੇ ਹੋਏ ਪ੍ਰਸਤਾਵ, ਚੋਣ ਮਾਪਦੰਡ, ਅਤੇ ਚੋਣ ਦਾ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ ਸ਼ਾਮਲ ਹੈ। ਤਬਦੀਲੀਆਂ ਦਾ ਵਰਣਨ ਉਸੇ ਪੱਧਰ 'ਤੇ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਕਿ DIPD S ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈtage.

ਲੋੜ ਪੈਣ 'ਤੇ, ਡੀਆਈਪੀਡੀ ਦੇ ਸਬੰਧ ਵਿੱਚ ਸੈਕਸ਼ਨ 4.1 ਵਿੱਚ ਵਰਣਨ ਕੀਤੇ ਗਏ ਖੇਤਰਾਂ ਨੂੰ ਹੋਰ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਹੈ।
ਸੁਧਾਰ ਦਾ ਪੂਰਾ ਵੇਰਵਾ।
ਇੱਕ ਅੱਪਡੇਟ ਕੀਤਾ ਆਰਕੀਟੈਕਚਰਲ ਵੇਰਵਾ।
FRD ਤੋਂ ਸਾਰੀਆਂ ਕਾਰਜਾਤਮਕ ਲੋੜਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕੀਤਾ ਗਿਆ।

3. 0.7/FIPD ਟੈਸਟ ਦਸਤਾਵੇਜ਼, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠ ਲਿਖੀਆਂ ਜਾਣਕਾਰੀਆਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

ਇੱਕ ਟੈਸਟ ਸੂਟ, ਜਿਸ ਵਿੱਚ TSTO [5] ਵਿੱਚ ਵਰਣਨ ਕੀਤੇ ਗਏ ਟੈਸਟ ਦੇ ਉਦੇਸ਼ਾਂ ਦੀ ਸੂਚੀ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਲਾਗੂਕਰਨ ਅਨੁਕੂਲਤਾ ਬਿਆਨ (ICS), ਜਿਵੇਂ ਕਿ TSTO [5] ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ।

ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ, ਟੈਸਟ ਸੂਟ ਅਤੇ ICS ਨੂੰ ਜਾਂ ਤਾਂ ਵੱਖਰੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਜੋਂ ਜਾਂ FIPD ਵਿੱਚ ਵਾਧੂ ਭਾਗਾਂ ਵਜੋਂ ਸਪਲਾਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕtage WG ਮੈਂਬਰ ਅਤੇ BARB ਹਨ ਜੋ ਮੁੜview ਵਿਸ਼ੇਸ਼ਤਾ ਜਾਂ ਸੁਧਾਰ ਦਾ ਪੂਰਾ ਵੇਰਵਾ ਜਿਸ ਵਿੱਚ ਅੰਤਿਮ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਗਈ ਹੈ। BTI ਦੁਬਾਰਾ ਲਈ ਦਰਸ਼ਕ ਹੈview ਟੈਸਟ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ.

BSTS ਮੁੜ ਕਰੇਗਾview 0.7/FIPD ਨਿਰਧਾਰਨ ਦੇ ਨਵੇਂ ਜਾਂ ਬਦਲੇ ਹੋਏ ਹਿੱਸੇ ਅਤੇ ਬਲੂਟੁੱਥ ਡਰਾਫਟ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਨਾਲ ਇਕਸਾਰਤਾ ਲਈ ਟੈਸਟ ਦਸਤਾਵੇਜ਼, ਬਲੂਟੁੱਥ SIG ਦੁਆਰਾ ਸਥਾਪਤ ਭਾਸ਼ਾ ਸੰਮੇਲਨਾਂ ਸਮੇਤ। BARB ਮੁੜ ਕਰੇਗਾview 0.7/FIPD ਨਿਰਧਾਰਨ।

BSTS TSTO [0.7] ਦੇ ਅਨੁਸਾਰ 5/FIPD ਟੈਸਟ ਦਸਤਾਵੇਜ਼ ਤਿਆਰ ਕਰਨ ਵਿੱਚ WG ਦੀ ਸਹਾਇਤਾ ਕਰੇਗਾ।

BTI ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview 0.7/FIPD ਟੈਸਟ ਦਸਤਾਵੇਜ਼। WG ਨੂੰ BTI ਨੂੰ 0.7/FIPD ਨਿਰਧਾਰਨ ਇੱਕ ਸੰਦਰਭ ਵਜੋਂ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਦੁਬਾਰਾview0.7/FIPD ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ, ਜੋ BTI ਦੁਬਾਰਾ ਕਰੇਗਾview BTI ਨਿਰਧਾਰਨ ਦੇ ਅਨੁਸਾਰ ਰੀview ਪ੍ਰਕਿਰਿਆ ਚੈੱਕਲਿਸਟ [6]।

ਬਾਰਬ ਨੇ ਆਪਣਾ ਮੁੜ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦview 0.7/ਐਫਆਈਪੀਡੀ ਨਿਰਧਾਰਨ ਅਤੇ ਬੀਟੀਆਈ ਨੇ ਆਪਣਾ ਮੁੜ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈview 0.7/FIPD ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚੋਂ, BSTS ਦੁਬਾਰਾ ਕਰੇਗਾviewed 0.7/FIPD ਨਿਰਧਾਰਨ ਸਾਰੇ ਐਸੋਸੀਏਟ ਅਤੇ ਪ੍ਰਮੋਟਰ ਮੈਂਬਰਾਂ ਲਈ ਉਪਲਬਧ ਹੈ।

0.7/ਐਫਆਈਪੀਡੀ ਐਸtage CSS, GSS, ਜਾਂ MDP ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਸੁਧਾਰਾਂ ਲਈ ਲੋੜੀਂਦਾ ਨਹੀਂ ਹੈ।

0.7/ਐਫਆਈਪੀਡੀ ਐਸtage ਬਾਹਰ ਜਾਣ ਦੀਆਂ ਲੋੜਾਂ

0.7/ਐਫਆਈਪੀਡੀ ਐਸtage ਪੂਰਾ ਹੈ ਅਤੇ 0.9/CR Stage ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਨਿਮਨਲਿਖਤ ਨਿਕਾਸ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ:

ਬੀ.ਐੱਸ.ਟੀ.ਐੱਸ. ਨੇ ਮੁੜ ਮੁਕੰਮਲ ਕਰ ਲਿਆ ਹੈview0.7/FIPD ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ।
BARB ਨੇ ਦੁਬਾਰਾ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈview0.7/FIPD ਨਿਰਧਾਰਨ ਨਾਲ।
BTI ਨੇ ਮੁੜ ਪੂਰਾ ਕੀਤਾ ਹੈview0.7/FIPD ਟੈਸਟ ਸੂਟ (ਟੈਸਟ ਉਦੇਸ਼) ਅਤੇ 0.7/FIPD ICS।
BSTS ਨੇ ਰੀviewed 0.7/FIPD ਨਿਰਧਾਰਨ ਸਾਰੇ ਐਸੋਸੀਏਟ ਅਤੇ ਪ੍ਰਮੋਟਰ ਮੈਂਬਰਾਂ ਲਈ ਉਪਲਬਧ ਹੈ।

4.3 0.9/CR Stage

ਦੋ ਕਿਸਮਾਂ ਦੇ ਸੀਆਰ ਹਨ: ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਸੀਆਰ, ਜੋ ਪਿਛਲੇ ਸੰਸਕਰਣ ਤੋਂ ਬਾਅਦ ਦੇ ਸਾਰੇ ਬਦਲਾਅ ਦਿਖਾਉਂਦੇ ਹੋਏ ਪੂਰੇ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਦਾ ਇੱਕ ਤਬਦੀਲੀ-ਟਰੈਕ ਕੀਤਾ ਦਸਤਾਵੇਜ਼ ਹੈ, ਅਤੇ ਇੱਕ ਸੰਖੇਪ ਸੀਆਰ, ਜੋ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਹੈ ਜੋ ਸਿਰਫ ਪ੍ਰਭਾਵਿਤ ਭਾਗਾਂ ਨੂੰ ਸੋਧਣ ਲਈ ਨਿਰਦੇਸ਼ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਜਿਸ 'ਤੇ CR ਅਧਾਰਤ ਹੈ।

0.9/CR ਦੇ ਦੌਰਾਨ ਐੱਸtage, WG [8] ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਅਧਿਕਾਰਤ ਟੈਂਪਲੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਾਸ ਕਰੇਗਾ:

ਇੱਕ ਨਵੇਂ ਨਿਰਧਾਰਨ ਲਈ, 0.9 ਨਿਰਧਾਰਨ ਦਾ ਇੱਕ ਸਮਗਰੀ-ਪੂਰਾ ਡਰਾਫਟ, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

BARB-re ਤੋਂ ਬਾਅਦ ਕੀਤੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦਾ ਵੇਰਵਾviewed 0.7 ਨਿਰਧਾਰਨ (ਜਾਂ 0.5 ਨਿਰਧਾਰਨ ਤੋਂ ਬਾਅਦ ਜੇ 0.7 ਨਿਰਧਾਰਨ ਦਾ ਉਤਪਾਦਨ ਕਰਨਾ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ), ਜਿਸ ਵਿੱਚ ਨਵਾਂ ਜਾਂ
ਸੰਸ਼ੋਧਿਤ ਪ੍ਰਸਤਾਵ, ਚੋਣ ਦੇ ਮਾਪਦੰਡ, ਅਤੇ ਚੋਣ ਦਾ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ। ਤਬਦੀਲੀਆਂ ਨੂੰ ਵੇਰਵੇ ਦੇ ਉਸੇ ਪੱਧਰ 'ਤੇ ਵਰਣਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਕਿ 0.5 S ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈtagਈ ਅਤੇ 0.7 ਐਸtage.

2. ਇੱਕ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਲਈ:

ਜਾਂ ਤਾਂ ਇੱਕ ਏਕੀਕ੍ਰਿਤ CR, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠ ਲਿਖੀਆਂ ਜਾਣਕਾਰੀਆਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
BARB-re ਤੋਂ ਬਾਅਦ ਕੀਤੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦਾ ਵੇਰਵਾviewed FIPD (ਜਾਂ DIPD ਤੋਂ ਬਾਅਦ ਜੇ FIPD ਨੂੰ ਮੁਆਫ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ) ਨਵੇਂ ਜਾਂ ਸੋਧੇ ਹੋਏ ਪ੍ਰਸਤਾਵਾਂ, ਚੋਣ ਦੇ ਮਾਪਦੰਡ, ਅਤੇ ਚੋਣ ਦੀ ਜਾਇਜ਼ਤਾ ਸਮੇਤ। ਤਬਦੀਲੀਆਂ ਦਾ ਵਰਣਨ ਉਸੇ ਪੱਧਰ 'ਤੇ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਕਿ DIPD S ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈtage ਅਤੇ FIPD ਐੱਸtage.
ਪਰਿਵਰਤਨ-ਟਰੈਕਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਲਈ ਪ੍ਰਸਤਾਵਿਤ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ।
ਸਾਰੇ ਪ੍ਰਵਾਨਿਤ ਤਕਨੀਕੀ ਇਰੱਟਾ (ਹਰੇਕ ਇਰੱਟਮ ਦੇ ਨਾਲ ਇੱਕ ਇਰੱਟਮ ਨੰਬਰ ਨਾਲ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ), ਪਰਿਵਰਤਨ-ਟਰੈਕਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦਿਖਾਇਆ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਅਜੇ ਤੱਕ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਉਹ ਪ੍ਰਭਾਵ ਟੈਕਸਟ ਜੋ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ; ਜਾਂ ਜੋ ਕਿ IOP ਟੈਸਟਿੰਗ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ।

3. ਜਾਂ ਇੱਕ ਸੰਖੇਪ CR, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, ਹੇਠ ਲਿਖੀਆਂ ਜਾਣਕਾਰੀਆਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

BARB-re ਤੋਂ ਬਾਅਦ ਕੀਤੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦਾ ਵੇਰਵਾviewed FIPD (ਜਾਂ DIPD ਤੋਂ ਬਾਅਦ ਜੇ FIPD ਨੂੰ ਮੁਆਫ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ) ਨਵੇਂ ਜਾਂ ਸੋਧੇ ਹੋਏ ਪ੍ਰਸਤਾਵਾਂ, ਚੋਣ ਦੇ ਮਾਪਦੰਡ, ਅਤੇ ਚੋਣ ਦੀ ਜਾਇਜ਼ਤਾ ਸਮੇਤ। ਤਬਦੀਲੀਆਂ ਦਾ ਵਰਣਨ ਉਸੇ ਪੱਧਰ 'ਤੇ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਕਿ DIPD S ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈtage ਅਤੇ FIPD ਐੱਸtage.
ਹਰੇਕ ਪ੍ਰਭਾਵਿਤ ਭਾਗ ਅਤੇ ਨਿਰਧਾਰਨ ਦੇ ਪੈਰਾਗ੍ਰਾਫ ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਜੋ ਕਿ CR ਬਦਲਣ ਦੀ ਤਜਵੀਜ਼ ਕਰਦਾ ਹੈ।
ਸਾਰੇ ਪ੍ਰਵਾਨਿਤ ਤਕਨੀਕੀ ਇਰੱਟਾ (ਹਰੇਕ ਇਰੱਟਮ ਦੇ ਨਾਲ ਇੱਕ ਇਰੱਟਮ ਨੰਬਰ ਦੇ ਨਾਲ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ), ਮਾਰਕਅੱਪ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦਿਖਾਇਆ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਉਹ ਪ੍ਰਭਾਵ ਟੈਕਸਟ ਜੋ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ; ਜਾਂ ਜੋ ਕਿ IOP ਟੈਸਟਿੰਗ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ।

4. ਇੱਕ CSS CR (ਜੇਕਰ ਨਵੀਆਂ ਐਂਟਰੀਆਂ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੁਆਰਾ ਲੋੜੀਂਦੀਆਂ ਹਨ), ਜੋ ਕਿ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਇੱਕ ਸੰਖੇਪ CR ਵਿੱਚ ਏਮਬੇਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
5. ਇੱਕ GSS CR (ਜੇਕਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੁਆਰਾ ਨਵੀਆਂ ਐਂਟਰੀਆਂ ਦੀ ਲੋੜ ਹੈ), ਜੋ ਕਿ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਇੱਕ ਸੰਖੇਪ CR ਵਿੱਚ ਏਮਬੇਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
6. ਇੱਕ MDP CR (ਜੇਕਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੁਆਰਾ ਨਵੀਆਂ ਐਂਟਰੀਆਂ ਦੀ ਲੋੜ ਹੈ), ਜੋ ਕਿ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਇੱਕ ਸੰਖੇਪ CR ਵਿੱਚ ਏਮਬੇਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
7. 0.9/CR ਟੈਸਟ ਦਸਤਾਵੇਜ਼, ਜਿਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ, [8] ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਅਧਿਕਾਰਤ ਟੈਮਪਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

0.9/CR ਟੈਸਟ ਸੂਟ, ਜਿਸ ਵਿੱਚ TSTO [5] ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਮੱਗਰੀ-ਸੰਪੂਰਨ ਟੈਸਟ ਕੇਸ ਅਤੇ ਸੰਬੰਧਿਤ ਟੈਸਟ ਕੇਸ ਮੈਪਿੰਗ ਟੇਬਲ (TCMT) ਸ਼ਾਮਲ ਹਨ।
0.9/CR ICS, ਜਿਵੇਂ ਕਿ TSTO [5] ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ।
ਜੇਕਰ ਟੈਸਟਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਲਈ ਇਮਪਲੀਮੈਂਟੇਸ਼ਨ ਅੰਡਰ ਟੈਸਟ (IUT), ਟੈਸਟਿੰਗ (IXIT) ਲਈ 0.9/CR ਲਾਗੂ ਕਰਨ ਦੀ ਵਾਧੂ ਜਾਣਕਾਰੀ ਲਈ ਖਾਸ ਮਾਪਦੰਡਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
0.9/CR ਟੈਸਟ ਕੇਸ ਹਵਾਲਾ ਸੂਚੀ (TCRL) (ਕੋਰ ਨਿਰਧਾਰਨ ਅੱਪਡੇਟ ਲਈ ਵਿਕਲਪਿਕ)।

8. ਇੱਕ ਟੈਸਟ ਕਵਰੇਜ ਵਿਸ਼ਲੇਸ਼ਣ ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਨਿਰਧਾਰਨ ਲੋੜਾਂ ਜਾਂ ਤਾਂ 0.9/CR ਟੈਸਟ ਸੂਟ ਦੇ ਅੰਦਰ ਟੈਸਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਜਾਂ ਨਹੀਂ ਪਰਖੀਆਂ ਗਈਆਂ ਹਨ (ਵਿਸ਼ੇਸ਼ਤਾ ਸੁਧਾਰਾਂ ਲਈ, ਟੈਸਟ ਕਵਰੇਜ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਸਿਰਫ ਨਵੀਂ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਗੈਰ-ਪ੍ਰਭਾਵਿਤ ਖੇਤਰਾਂ ਨੂੰ ਅਸਲੀ ਨਿਰਧਾਰਨ).
9. ਇੱਕ IOP ਟੈਸਟ ਯੋਜਨਾ।

ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ, ਟੈਸਟ ਸੂਟ, ICS, ਅਤੇ IXIT ਜਾਂ ਤਾਂ ਵੱਖਰੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਜੋਂ ਜਾਂ ਸੰਖੇਪ CR ਵਿੱਚ ਵਾਧੂ ਭਾਗਾਂ ਵਜੋਂ ਸਪਲਾਈ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਜਾਂ ਸੰਖੇਪ CR ਨਿਰਧਾਰਨ ਦੇ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਸੰਸਕਰਣ 'ਤੇ ਅਧਾਰਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਇਹ ਨਵੀਨਤਮ ਵਿਚਕਾਰਲੇ ਡਰਾਫਟ 'ਤੇ ਵੀ ਅਧਾਰਤ ਹੋ ਸਕਦਾ ਹੈ। ਨਵੀਨਤਮ ਇੰਟਰਮੀਡੀਏਟ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਸੰਸਕਰਣ ਸੰਸਕਰਣ ਨੰਬਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਦਸਤਾਵੇਜ਼ ਦੇ ਸੰਸਕਰਣ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਨਹੀਂ ਬਦਲੇਗਾ। ਨਹੀਂ ਤਾਂ, ਅਤਿਰਿਕਤ ਪਛਾਣ ਜਾਣਕਾਰੀ (ਜਿਵੇਂ ਕਿ ਦਸਤਾਵੇਜ਼ ਦੀ ਮਿਤੀ ਅਤੇ ਏ URL ਕਿਸੇ ਸਥਾਈ ਸਥਾਨ 'ਤੇ) ਨੂੰ ਖਾਸ "ਬੇਸਲਾਈਨ" ਸੰਸਕਰਣ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਵਿਚਕਾਰਲੇ ਡਰਾਫਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕਿਸੇ ਦਿੱਤੇ ਭਾਗ ਦੇ ਅੰਦਰ CR ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸੰਬੰਧਿਤ ਨਾ ਹੋਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਨੂੰ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਮਾਰਕਅੱਪ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦਿਖਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਵਿਚਕਾਰਲੇ ਡਰਾਫਟ ਦੇ ਸੰਬੰਧਿਤ ਭਾਗਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵਿਚਕਾਰਲੇ ਡਰਾਫਟ ਦੇ ਅੱਪਡੇਟ ਨੂੰ ਦਰਸਾਉਣ ਲਈ CR ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਸੰਖੇਪ CR ਸਮੱਗਰੀ ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰਮਵਾਰ ਸੰਪੂਰਨ ਨਿਰਧਾਰਨ ਅਤੇ ਸੰਪੂਰਨ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਡਰਾਫਟ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਵੀ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਨਿਰਧਾਰਨ (ਉਦਾਹਰਨ ਲਈ, ਕੋਰ ਨਿਰਧਾਰਨ) ਲਈ ਕਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿਕਸਿਤ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ, ਤਾਂ IOP ਟੈਸਟਿੰਗ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਇੱਕ ਡਰਾਫਟ ਵਿੱਚ ਜੋੜਨਾ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ।

BSTS ਮੁੜ ਕਰੇਗਾview ਬਲੂਟੁੱਥ ਡਰਾਫ਼ਟਿੰਗ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ ਇਕਸਾਰਤਾ ਲਈ 0.9/CR ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼। ਫਿਰ BARB ਮੁੜ ਜਾਵੇਗਾview 0.9/CR ਨਿਰਧਾਰਨ ਬਾਅਦ ਵਿੱਚ IOP ਟੈਸਟ ਯੋਜਨਾ (ਜਿਵੇਂ ਕਿ ਸੈਕਸ਼ਨ 4.3.1 ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ) ਦੁਆਰਾ ਬਾਅਦ ਵਿੱਚ। ਇੱਕ ਵਾਰ 0.9/CR ਨਿਰਧਾਰਨ WG ਦੁਆਰਾ BARB ਨੂੰ ਦੁਬਾਰਾ ਲਈ ਜਮ੍ਹਾ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈview, BSTS ਇਸ ਨੂੰ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਮੁੜ ਪਹੁੰਚਯੋਗ ਬਣਾ ਦੇਵੇਗਾview ਅਤੇ ਇਸਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੋ। ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇਸ ਬਿੰਦੂ ਤੋਂ ਅੱਗੇ, BSTS BARB ਨੂੰ ਜਮ੍ਹਾ ਕੀਤੇ ਗਏ ਨਿਰਧਾਰਨ ਦੇ ਡਰਾਫਟ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਭੇਜੇ ਗਏ ਨੋਟਿਸਾਂ ਦੇ ਨਾਲ ਉਪਲਬਧ ਕਰਵਾਏਗਾ।

ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਸੁਧਾਰ ਲਈ, WG BoD ਨੂੰ ਸਿਫ਼ਾਰਸ਼ ਕਰੇਗਾ ਕਿ ਕੀ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਿਫ਼ਾਰਸ਼ਾਂ ਦੇ ਤਕਨੀਕੀ ਕਾਰਨਾਂ ਸਮੇਤ।

BARB ਮੁੜ ਕਰੇਗਾview 0.9/CR ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੀ FRD ਵਿੱਚ ਦਿੱਤੀਆਂ ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ ਦਾ WG ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ, ਕਿਸੇ ਵੀ ਸੰਭਾਵੀ ਸੁਰੱਖਿਆ ਮੁੱਦੇ, ਕੋਈ ਰੈਗੂਲੇਟਰੀ ਮੁੱਦੇ, ਬਲੂਟੁੱਥ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ ਅਨੁਕੂਲਤਾ, ਅਤੇ, ਇੱਕ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਲਈ, ਸੈਕਸ਼ਨ 3.3.2 ਵਿੱਚ ਵਰਣਨ ਕੀਤੀਆਂ ਗਈਆਂ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ। .XNUMX. ਜੇਕਰ BARB ਕਿਸੇ ਸੰਭਾਵੀ ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਤਾਂ BARB BSTS ਨੂੰ ਦੁਬਾਰਾ ਲਈ ਸੂਚਿਤ ਕਰੇਗਾview ਅਤੇ ਸੁਰੱਖਿਆ ਮਾਹਰ ਸਮੂਹ ਨਾਲ ਤਾਲਮੇਲ; ਅਤੇ ਜੇਕਰ BARB ਕਿਸੇ ਰੈਗੂਲੇਟਰੀ ਪ੍ਰਭਾਵਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਤਾਂ BARB BSTS ਨੂੰ ਮੁੜ ਤੋਂ ਸੂਚਿਤ ਕਰੇਗਾview ਅਤੇ ਰੈਗੂਲੇਟਰੀ ਕਮੇਟੀ ਅਤੇ ਬਲੂਟੁੱਥ SIG ਦੇ ਕਾਨੂੰਨੀ ਸਲਾਹਕਾਰ ਨਾਲ ਤਾਲਮੇਲ ਕਰੋ। BARB ਨੂੰ ਆਪਣੇ ਇੰਜੀਨੀਅਰਿੰਗ ਨਿਰਣੇ ਅਤੇ ਇਸ ਪੈਰੇ ਵਿੱਚ ਵਰਣਿਤ ਕਾਰਕਾਂ ਦੇ ਵਿਚਾਰ ਦੇ ਆਧਾਰ 'ਤੇ 0.9/CR ਨਿਰਧਾਰਨ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

BTI ਮੁੜ ਕਰੇਗਾview ਟੈਸਟ ਕਵਰੇਜ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ 0.9/CR ਟੈਸਟ ਦਸਤਾਵੇਜ਼। BTI ਨੂੰ ਜਾਂ ਤਾਂ 0.9/CR ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

BARB ਦੁਆਰਾ 0.9/CR ਨਿਰਧਾਰਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਬਾਅਦ, WG ਦੁਬਾਰਾ ਲਈ BARB ਨੂੰ IOP ਟੈਸਟ ਯੋਜਨਾ ਜਮ੍ਹਾਂ ਕਰਾਉਂਦਾ ਹੈview.

BARB-ਪ੍ਰਵਾਨਿਤ 0.9/CR ਨਿਰਧਾਰਨ ਨੂੰ IOP ਟੈਸਟਿੰਗ ਦੀ ਸ਼ੁਰੂਆਤ ਅਤੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ 0.9/CR ਨਿਰਧਾਰਨ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਲਈ BoD ਨੂੰ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸੰਭਾਵੀ ਕਾਨੂੰਨੀ ਮੁੱਦਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਨ ਲਈ, ਡਬਲਯੂ.ਜੀview ਬਲੂਟੁੱਥ SIG ਦੇ ਕਾਨੂੰਨੀ ਸਲਾਹਕਾਰ ਦੁਆਰਾ (ਕਾਨੂੰਨੀ ਮੁੜview) ਲਾਜ਼ਮੀ ਕਾਨੂੰਨੀ ਮੁੜ ਤੋਂ ਪਹਿਲਾਂview ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਦੇ ਪੜਾਅ ਦੌਰਾਨ ਹੁੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ, ਕਾਨੂੰਨੀ ਰੀview ਇੱਕ ਏਕੀਕ੍ਰਿਤ CR (ਇੱਕ ਸੰਖੇਪ CR ਦੇ ਉਲਟ) 'ਤੇ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਸਰੋਤ ਉਪਲਬਧ ਹੋਣ।

IOP ਟੈਸਟ ਯੋਜਨਾ

WG ਇੱਕ ਲਿਖਤੀ IOP ਟੈਸਟ ਪਲਾਨ ਤਿਆਰ ਕਰੇਗਾ ਜੋ IOP ਟੈਸਟ ਇਵੈਂਟਾਂ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੌਰਾਨ ਵਰਤੋਂ ਲਈ ਹੇਠਾਂ ਪਰਿਭਾਸ਼ਿਤ ਸਾਰੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। WGs ਨੂੰ IOP ਟੈਸਟ ਪਲਾਨ ਦੁਬਾਰਾ ਲਈ BARB ਨੂੰ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview IOP ਟੈਸਟ ਇਵੈਂਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ। ਸਧਾਰਨ ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ (ਖਾਸ ਤੌਰ 'ਤੇ ਉਹ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੈਸਟ ਸੂਟ ਵਿੱਚ ਕਿਸੇ ਵੀ ਟੈਸਟ ਦੇ ਕੇਸਾਂ ਨੂੰ ਸੋਧਣ ਜਾਂ ਜੋੜਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ), IOP ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ WG ਪਰਿਭਾਸ਼ਿਤ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਤੋਂ ਕਰਕੇ IOP ਟੈਸਟਿੰਗ ਤੋਂ ਛੋਟ ਲਈ BARB ਨੂੰ ਇੱਕ ਬੇਨਤੀ ਦਰਜ ਕਰ ਸਕਦਾ ਹੈ। ਸੈਕਸ਼ਨ 4.4 ਵਿੱਚ।

IOP ਟੈਸਟ ਯੋਜਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

ਸਾਰੀਆਂ ਨਵੀਆਂ ਲਾਜ਼ਮੀ, ਵਿਕਲਪਿਕ ਅਤੇ ਸ਼ਰਤੀਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕੇਸਾਂ ਦੀ ਜਾਂਚ ਕਰੋ
ਹਰੇਕ ਓਪ ਕੋਡ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਟੈਸਟ ਕੇਸ
ਹਰੇਕ ਪੈਰਾਮੀਟਰ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਟੈਸਟ ਕੇਸ
ਹਰੇਕ ਪੈਕੇਟ ਕਿਸਮ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਟੈਸਟ ਕੇਸ
ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਟੈਸਟ ਦੇ ਕੇਸ ਤਾਂ ਜੋ ਸੈਕਸ਼ਨ 3.3.2 ਵਿੱਚ ਸੂਚੀਬੱਧ ਲੋੜਾਂ ਸਾਰੀਆਂ ਵਿਸਤ੍ਰਿਤ ਕਾਰਜਕੁਸ਼ਲਤਾਵਾਂ ਲਈ ਪੂਰੀਆਂ ਹੋਣ (ਸੈਕਸ਼ਨ 4.3.1.1 ਵੀ ਦੇਖੋ)।
ਟੈਸਟ ਕੇਸ ਜਿੱਥੇ IUT ਪਰਿਭਾਸ਼ਿਤ ਰੇਂਜਾਂ ਤੋਂ ਬਾਹਰ ਦੇ ਮੁੱਲਾਂ ਜਾਂ ਅਵੈਧ ਜਾਂ ਅਚਾਨਕ ਮੰਨੇ ਜਾਂਦੇ ਵਿਵਹਾਰਕ ਪਹਿਲੂਆਂ (ਅਵੈਧ ਵਿਵਹਾਰ ਟੈਸਟ ਕੇਸ) ਦੇ ਸੰਪਰਕ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਇੱਕ ਟੈਸਟਰ ਜਿਵੇਂ ਕਿ PTS ਜਾਂ ਹੋਰ ਟੈਸਟ ਟੂਲ ਕਿਸੇ ਅਵੈਧ ਵਿਵਹਾਰ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲਾ ਹੋਵੇਗਾ।
ਸੈਕਸ਼ਨ 4.3.1.2 ਵਿੱਚ ਦੱਸੇ ਅਨੁਸਾਰ, IOP ਟੈਸਟ ਇਵੈਂਟ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਲਈ ਕੋਈ ਵੀ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਨੰਬਰ (ਆਗਾਮੀ IOP ਟੈਸਟ ਇਵੈਂਟਾਂ 'ਤੇ ਓਵਰਲੈਪ ਤੋਂ ਬਚਣ ਲਈ BSTS ਨਾਲ ਤਾਲਮੇਲ ਵਿੱਚ ਚੁਣਿਆ ਗਿਆ)।
ਸੈਕਸ਼ਨ 4.3.1.3 ਵਿੱਚ ਵਰਣਿਤ ਕਵਰੇਜ ਲੋੜਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਲੋੜੀਂਦੇ ਸੁਤੰਤਰ ਲਾਗੂਕਰਨਾਂ ਦੀ ਪਛਾਣ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਰੇਕ ਟੈਸਟ ਕੇਸ ਪਾਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਟੈਸਟ ਸੂਟ ਵਿੱਚ ਕਿਸੇ ਵੀ ਟੈਸਟ ਦੇ ਕੇਸਾਂ ਦੀ ਪਛਾਣ ਜੋ WG ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੇ ਬੇਦਖਲੀ ਲਈ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ। ਇਹਨਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ: • ਭਵਿੱਖ ਦੀ ਪਰੂਫਿੰਗ ਟੈਸਟ ਦੇ ਕੇਸ (ਜਿਵੇਂ ਕਿ, ਆਮ ਟੈਸਟ ਤਾਂ ਜੋ ਭਵਿੱਖ ਵਿੱਚ ਸੰਭਾਵੀ ਜੋੜਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕੇ, ਜਿਵੇਂ ਕਿ ਵਾਧੂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਵਿਸਤਾਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਜਾਂ ਭਵਿੱਖ ਦੀ ਵਰਤੋਂ ਲਈ ਰਾਖਵੇਂਕਰਨ (RFU) ਬਿੱਟ ਜਾਂ ਖੇਤਰਾਂ ਦੀ ਵਰਤੋਂ)
• ਟੈਸਟ ਦੇ ਕੇਸ ਜੋ ਹੋਰ ਸ਼ਾਮਲ ਕੀਤੇ ਟੈਸਟਾਂ ਦਾ ਸਬਸੈੱਟ ਹਨ
• ਸਧਾਰਣ ਟੈਸਟ ਕੇਸ ਜੋ ਕਈ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਚੱਲਣ ਵਾਲੇ ਟੈਸਟਾਂ ਨਾਲ ਲੱਗਭਗ ਸਮਾਨ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਆਮ ਗਲਤੀ ਕੋਡ ਨੂੰ ਚਾਲੂ ਕਰਨਾ)
• ਟੈਸਟ ਕੇਸਾਂ ਦੇ ਟੈਸਟ ਦੇ ਇੱਕੋ ਜਿਹੇ ਉਦੇਸ਼ ਨਾਲ ਟੈਸਟ ਕੇਸ ਜੋ ਕਿਸੇ ਹੋਰ ਟ੍ਰਾਂਸਪੋਰਟ 'ਤੇ ਚੱਲਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ BR/EDR ਟੈਸਟ ਕੇਸ ਜੋ LE ਟੈਸਟ ਕੇਸ ਦੇ ਸਮਾਨ ਹੈ)
• ਲਾਗੂ ਕਰਨ ਦੀ ਮਜ਼ਬੂਤੀ ਜਾਂ ਤਣਾਅ ਦੀ ਜਾਂਚ

IOP ਟੈਸਟ ਪਲਾਨ ਵਿੱਚ ਉਹ ਟੈਸਟ ਵੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ ਜੋ IOP ਟੈਸਟਿੰਗ ਲਈ ਵਿਲੱਖਣ ਹਨ ਜਿਵੇਂ ਕਿ ਐਂਡ-ਟੂ-ਐਂਡ ਟੈਸਟ ਕੇਸ ਜੋ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਕ੍ਰਮਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ ਜੋ ਇੱਕ ਆਮ ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ ਦੇ ਸਮਾਨ ਹੋ ਸਕਦੇ ਹਨ।

ਹਾਲਾਂਕਿ IOP ਟੈਸਟ ਪਲਾਨ ਦੀ BARB ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ (ਇਹ ਸਮਝ 'ਤੇ ਕਿ IOP ਟੈਸਟ ਪਲਾਨ ਨੂੰ ਹਰ IOP ਟੈਸਟ ਇਵੈਂਟ ਨਾਲ ਸੋਧਿਆ ਅਤੇ ਸੁਧਾਰਿਆ ਜਾਣਾ ਜਾਰੀ ਰਹੇਗਾ), IOP ਟੈਸਟ ਰਿਪੋਰਟ ਦੀ BARB ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੈ (ਦੇਖੋ ਸੈਕਸ਼ਨ 5.1.1) . ਜੇਕਰ ਇੱਕ IOP ਟੈਸਟ ਪਲਾਨ ਸੈਕਸ਼ਨ 4.3.1 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਸਾਰੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ WG ਨੂੰ IOP ਟੈਸਟ ਇਵੈਂਟ (ਆਂ) ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ BARB ਲਈ ਕਿਸੇ ਵੀ ਜਾਣੇ-ਪਛਾਣੇ ਪਰਿਵਰਤਨਾਂ ਦਾ ਸਾਰ ਅਤੇ ਤਰਕ ਪੇਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

IOP ਟੈਸਟ ਪਲਾਨ ਅਤੇ ਟੈਸਟ ਦੇ ਕੇਸ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸੰਬੰਧਿਤ ਨਿਰਧਾਰਨ ਦੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅੰਦਰ ਸਮੱਗਰੀ 'ਤੇ ਅਧਾਰਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

IOP ਟੈਸਟ ਇਵੈਂਟਾਂ ਨੂੰ ਕੁਸ਼ਲ ਬਣਾਉਣ ਲਈ, WG ਕੋਲ IOP ਟੈਸਟ ਪਲਾਨ ਅਤੇ ਸਾਰੇ ਸਬੰਧਿਤ ਟੈਸਟ ਕੇਸ ਪੂਰੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਲਾਗੂ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਆਦਰਸ਼ ਤੌਰ 'ਤੇ ਪਹਿਲੇ IOP ਟੈਸਟ ਇਵੈਂਟ ਤੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਮਹੀਨਾ ਪਹਿਲਾਂ ਉਪਲਬਧ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਟੈਸਟਿੰਗ ਲਈ ਯੋਜਨਾ ਬਣਾ ਰਹੀ ਹੈ
ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ, ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਦੀ IOP ਜਾਂਚ ਨੂੰ ਨਿਰਧਾਰਨ ਦੇ ਸਾਰੇ ਕਿਰਿਆਸ਼ੀਲ ਅਤੇ ਬਰਤਰਫ਼ ਕੀਤੇ ਸੰਸਕਰਣਾਂ ਦੇ ਵਿਰੁੱਧ ਤਸਦੀਕ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਬਲੂਟੁੱਥ ਉਤਪਾਦਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਪਾਏ ਜਾਣ ਵਾਲੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਉਮਰ ਬਹੁਤ ਲੰਬੀ ਹੋ ਸਕਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਵਾਹਨ)। WG ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਲੋੜੀਂਦੇ ਪਛੜੇ ਅਨੁਕੂਲਤਾ ਟੈਸਟਿੰਗ ਦੇ ਉਚਿਤ ਪੱਧਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਜੇ ਕੋਈ ਹੋਵੇ) ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਕਿਹੜੇ ਸੰਸਕਰਣਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਹੈ ਅਤੇ ਟੈਸਟ ਕੀਤੇ ਜਾਣੇ ਹਨ, ਅਤੇ BARB ਨੂੰ ਇਹ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। BARB ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview WG ਨੂੰ IOP ਟੈਸਟ ਪਲਾਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਤਬਦੀਲੀਆਂ (ਜੇ ਕੋਈ ਹੋਵੇ) ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰੋ।

ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਟੈਸਟਿੰਗ ਵਿੱਚ ਭਾਗ ਲੈਣ ਵਾਲੇ ਸਦੱਸਾਂ ਨੂੰ ਪੁਰਾਣੇ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣਾਂ (ਵਾਂ) ਦੇ ਵਿਰੁੱਧ ਯੋਗਤਾ ਪ੍ਰਾਪਤ ਪੁਰਾਣੇ ਉਪਕਰਣਾਂ ਨੂੰ ਲਿਆਉਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। WG ਨੂੰ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਵਿੱਚ ਕਿਸੇ ਵੀ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਅਸਫਲਤਾਵਾਂ ਦੀ ਰਿਪੋਰਟ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਮੈਂਬਰ ਕੰਪਨੀਆਂ ਨੂੰ ਵੀ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ IOP ਟੈਸਟ ਇਵੈਂਟ ਦੇ ਸਥਾਨ ਤੋਂ ਬਾਹਰ ਆਪਣੀਆਂ ਲੈਬਾਂ ਵਿੱਚ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਟੈਸਟਿੰਗ ਕਰਨ ਅਤੇ WG ਨੂੰ ਕਿਸੇ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾ-ਸੰਬੰਧੀ ਮੁੱਦਿਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਲਈ।

IOP ਟੈਸਟਿੰਗ ਵਿੱਚ ਵਰਤੇ ਗਏ ਅਸਥਾਈ ਨਿਰਧਾਰਤ ਨੰਬਰ
ਨਿਰਧਾਰਤ ਨੰਬਰਾਂ ਦੀ ਅਸਥਾਈ ਅਸਾਈਨਮੈਂਟ ਨੂੰ ਤਾਲਮੇਲ ਕਰਨ ਲਈ BSTS ਅਤੇ BARB ਨਾਲ ਸਲਾਹ ਮਸ਼ਵਰਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ IOP ਟੈਸਟ ਇਵੈਂਟ ਵਿੱਚ ਵਰਤੇ ਜਾਣਗੇ ਤਾਂ ਜੋ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਕੋਈ ਓਵਰਲੈਪ ਜਾਂ ਟਕਰਾਅ ਨਾ ਹੋਵੇ। ਇਹ ਅਸਥਾਈ ਮੁੱਲ IOP ਟੈਸਟ ਪਲਾਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਕਿਸੇ ਵੀ ਅਪਣਾਏ ਗਏ ਵਿਵਰਣ ਦੁਆਰਾ ਵਰਤੋਂ ਲਈ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤੇ ਜਾਣਗੇ।

IOP ਟੈਸਟਿੰਗ ਲਈ ਜਿੱਥੇ ਇੱਕ ਜਾਂ ਵੱਧ ਨਵੇਂ 16-ਬਿੱਟ UUID ਮੁੱਲ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, 0x7F00 ਤੋਂ 0x7FFF ਦੀ ਰੇਂਜ ਦੇ ਅੰਦਰ ਮੁੱਲ IOP ਟੈਸਟਿੰਗ ਲਈ ਰਾਖਵੇਂ ਹਨ।

IOP ਟੈਸਟਿੰਗ ਲਈ ਜਿੱਥੇ ਇੱਕ ਜਾਂ ਵੱਧ ਨਵੇਂ ਫਿਕਸਡ ਪ੍ਰੋਟੋਕੋਲ ਸਰਵਿਸ ਮਲਟੀਪਲੈਕਸਰ (PSM) ਮੁੱਲ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, 0x0000 ਤੋਂ 0x007F ਤੱਕ ਵੈਧ ਰੇਂਜ ਦੇ ਅੰਤ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਮੁੱਲ, ਜਿਵੇਂ ਕਿ ਕੋਰ ਨਿਰਧਾਰਨ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਨ, ਵਰਤੇ ਜਾਣਗੇ।

ਕਵਰੇਜ ਦੀਆਂ ਲੋੜਾਂ
WG ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ BARB ਨੂੰ ਸਬੂਤ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸੁਤੰਤਰ ਲਾਗੂਕਰਨਾਂ ਦੀ ਲੋੜੀਂਦੀ ਸੰਖਿਆ (ਜਿਵੇਂ ਕਿ ਅਨੁਛੇਦ ਕੀਤੇ ਗਏ ਭਾਗਾਂ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ) ਨੇ ਹਰੇਕ ਟੈਸਟ ਕੇਸ ਪਾਸ ਕੀਤਾ ਹੈ। ਸੁਤੰਤਰ ਲਾਗੂਕਰਨਾਂ ਦੀ ਲੋੜੀਂਦੀ ਗਿਣਤੀ ਦੇ ਅਪਵਾਦਾਂ ਲਈ ਕੋਈ ਵੀ WG ਬੇਨਤੀ IOP ਟੈਸਟ ਯੋਜਨਾ ਵਿੱਚ ਦਰਸਾਈ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ BARB ਨੂੰ ਜਮ੍ਹਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਤੋਂ ਸੁਤੰਤਰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਨਾਲ ਸੰਬੰਧਿਤ ਸਾਰੇ ਹਿੱਸੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਵਿਕਸਤ ਕੀਤੇ ਗਏ ਹਨ, ਭਾਵ, ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਦੁਆਰਾ (ਜੋ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਤੋਂ ਨਹੀਂ ਆਉਂਦੇ)। BSTS ਇਹ ਮੁਲਾਂਕਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਵੇਰਵਿਆਂ ਦੀ ਗੁਮਨਾਮਤਾ ਅਤੇ ਗੁਪਤਤਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਇੱਕ ਦੂਜੇ ਤੋਂ ਸੁਤੰਤਰ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਨੋਟ ਕਰੋ ਕਿ ਟੈਸਟ ਟੂਲ, PTS ਸਮੇਤ, ਨੂੰ ਸੁਤੰਤਰ ਲਾਗੂ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

ਕੋਰ ਨਿਰਧਾਰਨ IOP ਕਵਰੇਜ ਲੋੜਾਂ
ਇੱਕ ਕੋਰ ਨਿਰਧਾਰਨ ਵਿਸ਼ੇਸ਼ਤਾ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਹਰੇਕ ਭੂਮਿਕਾ ਨੂੰ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਹੋਰ ਭੂਮਿਕਾਵਾਂ ਨਾਲ ਜਾਂ ਸੰਭਵ ਤੌਰ 'ਤੇ ਆਪਣੇ ਆਪ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।

ਰੋਲ ਦੇ ਹਰੇਕ ਜੋੜੇ ਲਈ ਜੋ ਇੱਕ ਦੂਜੇ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ, ਹਰ ਰੋਲ ਦੇ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਸੁਤੰਤਰ ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਪੂਰਕ ਭੂਮਿਕਾ ਦੇ ਤਿੰਨ ਸੁਤੰਤਰ ਲਾਗੂਕਰਨਾਂ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਨ ਲਈ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਹਰੇਕ ਭੂਮਿਕਾ ਲਈ ਜੋ ਉਸੇ ਭੂਮਿਕਾ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਡਿਵਾਈਸ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰ ਸਕਦੀ ਹੈ, ਉਸ ਭੂਮਿਕਾ ਦੇ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਸੁਤੰਤਰ ਅਮਲਾਂ ਨੂੰ ਇਹ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਉਸ ਭੂਮਿਕਾ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਨਾਲ ਗੱਲਬਾਤ ਕਰ ਸਕਦੇ ਹਨ।

ਸੇਵਾ ਨਿਰਧਾਰਨ IOP ਕਵਰੇਜ ਲੋੜਾਂ
ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਸੁਤੰਤਰ ਸੇਵਾ ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਇਹ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕਲਾਇੰਟ ਲਾਗੂਕਰਨ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ PTS ਹੋ ਸਕਦਾ ਹੈ।

ਪ੍ਰੋfile ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਨਿਰਧਾਰਨ IOP ਕਵਰੇਜ ਲੋੜਾਂ
ਪ੍ਰੋfile ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਹਰੇਕ ਭੂਮਿਕਾ ਨੂੰ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਹੋਰ ਭੂਮਿਕਾਵਾਂ, ਜਾਂ ਸੰਭਵ ਤੌਰ 'ਤੇ ਆਪਣੇ ਆਪ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।

ਰੋਲ ਦੇ ਹਰੇਕ ਜੋੜੇ ਲਈ ਜੋ ਇੱਕ ਦੂਜੇ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ, ਹਰੇਕ ਰੋਲ ਦੇ ਘੱਟੋ-ਘੱਟ ਦੋ ਸੁਤੰਤਰ ਅਮਲਾਂ ਨੂੰ ਇਹ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਪੂਰਕ ਭੂਮਿਕਾ ਦੇ ਦੋ ਸੁਤੰਤਰ ਲਾਗੂਕਰਨਾਂ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਦੇ ਹਨ।

ਹਰੇਕ ਭੂਮਿਕਾ ਲਈ ਜੋ ਉਸੇ ਭੂਮਿਕਾ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਡਿਵਾਈਸ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰ ਸਕਦੀ ਹੈ, ਉਸ ਭੂਮਿਕਾ ਦੇ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਸੁਤੰਤਰ ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਇਹ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਉਸ ਭੂਮਿਕਾ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਨਾਲ ਅੰਤਰਕਿਰਿਆ ਕਰਦੇ ਹਨ।

ਮਾਡਲ ਨਿਰਧਾਰਨ IOP ਕਵਰੇਜ ਲੋੜਾਂ
ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਸੁਤੰਤਰ ਸਰਵਰ ਮਾਡਲ ਜਾਂ ਕੰਟਰੋਲ ਮਾਡਲ ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਇਹ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕਲਾਇੰਟ ਲਾਗੂਕਰਨ (ਜੋ ਕਿ PTS ਹੋ ਸਕਦਾ ਹੈ), ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕਲਾਇੰਟ ਮਾਡਲ ਲਾਗੂਕਰਨ ਨੂੰ ਇਹ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਰਵਰ ਮਾਡਲ ਲਾਗੂਕਰਨ ਅਤੇ PTS ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰਦਾ ਹੈ।

ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਨੰਬਰਿੰਗ

0.9/CR ਦੇ ਦੌਰਾਨ ਐੱਸtage, WG ਨੂੰ ਅਪਣਾਏ ਜਾਣ 'ਤੇ ਨਿਰਧਾਰਨ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਸੰਸਕਰਣ ਨੰਬਰ ਦੇ ਸਬੰਧ ਵਿੱਚ BoD ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ ਇੱਕ ਸਿਫਾਰਸ਼ ਤਿਆਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਸੰਸਕਰਣ ਦੋ ਕਿਸਮਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਪੂਰੇ ਰੀਲੀਜ਼ ਸੰਸਕਰਣ, ਜਿਸ ਵਿੱਚ ਨਵੀਆਂ ਜਾਂ ਅੱਪਡੇਟ ਕੀਤੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਸੰਸਕਰਣ ("ਡੌਟ-ਜ਼ੈਡ ਵਰਜਨ" ਵਜੋਂ ਵੀ ਜਾਣੇ ਜਾਂਦੇ ਹਨ), ਜੋ ਤਕਨੀਕੀ ਅਤੇ ਸੰਪਾਦਕੀ ਇਰੱਟਾ ਨੂੰ ਜੋੜਦੇ ਹਨ, ਪਰ ਨਵੇਂ ਜਾਂ ਅੱਪਡੇਟ ਕੀਤੇ ਗਏ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੇ ਹਨ। ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ। ਪੂਰੇ ਰੀਲੀਜ਼ ਸੰਸਕਰਣਾਂ ਵਿੱਚ XY ਦੇ ਰੂਪ ਵਿੱਚ ਦੋ-ਭਾਗ ਨੰਬਰ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ 2.1 ਜਾਂ 5.0, ਜਦੋਂ ਕਿ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਸੰਸਕਰਣਾਂ ਵਿੱਚ XYZ ਦੇ ਰੂਪ ਵਿੱਚ ਤਿੰਨ-ਭਾਗ ਨੰਬਰ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ 2.1.2। Z ਦਾ ਮੁੱਲ 0 ਨਹੀਂ ਹੋ ਸਕਦਾ।

ਕਿਸੇ ਵੀ ਦੋ ਸੰਸਕਰਣਾਂ ਲਈ, ਇੱਕ ਨੂੰ "ਉੱਚ ਸੰਸਕਰਣ" ਅਤੇ ਦੂਜੇ ਨੂੰ "ਹੇਠਲਾ ਸੰਸਕਰਣ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

ਜੇਕਰ X ਭਾਗ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਉੱਚ X ਮੁੱਲ ਵਾਲਾ ਇੱਕ "ਉੱਚਾ ਸੰਸਕਰਣ" ਹੈ।
ਜੇਕਰ X ਕੰਪੋਨੈਂਟ ਇੱਕੋ ਜਿਹੇ ਹਨ, ਪਰ Y ਕੰਪੋਨੈਂਟ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਉੱਚ Y ਮੁੱਲ ਵਾਲਾ ਇੱਕ "ਉੱਚਾ ਸੰਸਕਰਣ" ਹੈ।
ਜੇਕਰ XY ਕੰਪੋਨੈਂਟ ਇੱਕੋ ਜਿਹੇ ਹਨ, ਪਰ Z ਕੰਪੋਨੈਂਟ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਉੱਚ Z ਮੁੱਲ ਵਾਲਾ ਇੱਕ "ਉੱਚਾ ਸੰਸਕਰਣ" ਹੈ। ਇੱਕ ਦੋ-ਭਾਗ ਸੰਖਿਆ XY, ਇਸ ਉਦੇਸ਼ ਲਈ, ਇੱਕ ਤਿੰਨ-ਭਾਗ ਸੰਖਿਆ XY0 ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

ਸਾਬਕਾ ਲਈample, ਨਿਮਨਲਿਖਤ ਸੰਸਕਰਣ ਨੰਬਰ ਸਭ ਤੋਂ ਹੇਠਲੇ ਸੰਸਕਰਣ ਤੋਂ ਉੱਚੇ ਸੰਸਕਰਣ ਤੱਕ ਕ੍ਰਮ ਵਿੱਚ ਹੋਣਗੇ: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2। CSS ਲਈ, ਹਰੇਕ ਅੱਪਡੇਟ ਵਰਜਨ ਨੰਬਰ ਦੇ ਸਿਰਫ਼ X ਹਿੱਸੇ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

BoD ਮਨਜ਼ੂਰੀ ਦੀਆਂ ਲੋੜਾਂ
ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪੜਾਅ ਦੇ ਅੰਤ 'ਤੇ ਮਨਜ਼ੂਰੀ ਲਈ BoD ਨੂੰ 0.9/CR ਨਿਰਧਾਰਨ ਜਮ੍ਹਾ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹੇਠ ਲਿਖੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ:

WG ਨੇ ਟੈਸਟ ਕਵਰੇਜ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ।
ਬੀ.ਐੱਸ.ਟੀ.ਐੱਸ. ਨੇ ਮੁੜ ਮੁਕੰਮਲ ਕਰ ਲਿਆ ਹੈview0.9/CR ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ।
BARB ਨੇ 0.9/CR ਨਿਰਧਾਰਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੱਤੀ ਹੈ।
BARB ਨੇ CSS CR ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੱਤੀ ਹੈ (ਜੇਕਰ ਨਿਰਧਾਰਨ ਦੁਆਰਾ ਨਵੀਆਂ ਐਂਟਰੀਆਂ ਦੀ ਲੋੜ ਹੈ) ਜੋ ਕਿ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਇੱਕ ਸੰਖੇਪ CR ਵਿੱਚ ਏਮਬੇਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
BARB ਨੇ GSS CR ਅਤੇ MDP CR ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੱਤੀ ਹੈ (ਜੇ ਵਿਸ਼ੇਸ਼ਤਾ ਦੁਆਰਾ ਨਵੀਆਂ ਐਂਟਰੀਆਂ ਦੀ ਲੋੜ ਹੈ)।
BTI ਨੇ ਇੱਕ IXIT ਦੇ ਨਾਲ 0.9/CR ਟੈਸਟ ਸੂਟ, ICS, ਅਤੇ TCRL ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਹੈ (ਬਸ਼ਰਤੇ ਕਿ ਟੈਸਟ ਸੂਟ ਵਿੱਚ ਟੈਸਟ ਕਰਨ ਲਈ IXIT ਦੀ ਲੋੜ ਹੋਵੇ)। TCRL ਇਸ 'ਤੇ ਵਿਕਲਪਿਕ ਹੈtage ਕੋਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਅੱਪਡੇਟ ਲਈ।
WG ਨੇ IOP ਟੈਸਟ ਪਲਾਨ ਨੂੰ ਦੁਬਾਰਾ ਲਈ BARB ਨੂੰ ਸੌਂਪ ਦਿੱਤਾ ਹੈview (ਜੇ BARB ਦੁਆਰਾ ਟੈਸਟਿੰਗ ਨੂੰ ਮੁਆਫ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)।

BoD ਨੂੰ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ BARB-ਪ੍ਰਵਾਨਿਤ 0.9/CR ਨਿਰਧਾਰਨ, ਅਤੇ BoD ਨੂੰ ਇੱਕ ਪੇਸ਼ਕਾਰੀ ਸ਼ਾਮਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

ਆਈਓਪੀ ਟੈਸਟਿੰਗ ਜਾਂ ਸੈਕਸ਼ਨ 4.3.1 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਲੋੜਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਛੱਡਣ ਲਈ ਕੋਈ ਜਾਣੀ-ਪਛਾਣੀ ਬੇਨਤੀ
ਟ੍ਰਾਂਸਪੋਰਟਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਜੋ ਨਿਰਧਾਰਨ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, BR/EDR, LE. ਆਦਿ)
ਇੱਕ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਲਈ, ਪਛੜੀਆਂ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ (ਸੈਕਸ਼ਨ 3.3.2 ਵਿੱਚ ਵਰਣਨ ਕੀਤੀ ਗਈ) ਤੋਂ ਕੋਈ ਵੀ ਛੋਟਾਂ ਜੋ WG ਦੁਆਰਾ ਬੇਨਤੀ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ।
ਇੱਕ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਲਈ, ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ 'ਤੇ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਜਨ ਨੰਬਰ ਲਈ WG ਤੋਂ ਇੱਕ ਸਿਫਾਰਸ਼
ਨਿਰਧਾਰਨ ਵਧਾਉਣ ਲਈ, ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣ (ਵਾਂ) ਲਈ ਡਬਲਯੂ.ਜੀ. ਦੀ ਅੰਤ-ਜੀਵਨ ਦੀ ਸਿਫ਼ਾਰਸ਼, ਜਿਸ ਵਿੱਚ ਕੋਈ ਤਕਨੀਕੀ ਕਾਰਨ ਸ਼ਾਮਲ ਹਨ ਕਿ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਕਿਸੇ ਵੀ ਪਿਛਲੇ ਸੰਸਕਰਣ ਨੂੰ ਬਰਤਰਫ਼ ਕਰਨ ਜਾਂ ਵਾਪਸ ਲੈਣ ਦੀ ਸਿਫਾਰਸ਼ ਕਿਉਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਜਾਇਜ਼ ਸਿਫਾਰਸ਼ ਲਈ
BARB ਜਾਂ BTI ਮੈਂਬਰਾਂ ਦੀਆਂ ਕੋਈ ਅਣਸੁਲਝੀਆਂ ਗੰਭੀਰ ਚਿੰਤਾਵਾਂ (ਉਦਾਹਰਨ ਲਈ, ਮਨਜ਼ੂਰੀਆਂ ਦੇ ਦੌਰਾਨ ਕੋਈ ਵੀ ਵੋਟ ਨਾ ਹੋਣ ਦੇ ਕਾਰਨ, ਮੁੜ ਤੋਂ ਨਤੀਜੇ ਵਜੋਂ ਚਿੰਤਾਵਾਂview ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ, ਜਾਂ ਚਿੰਤਾਵਾਂ ਕਿ 0.9/CR ਨਿਰਧਾਰਨ FRD ਜਾਂ ਚਾਰਟਰ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ)
ਦੀ ਤਿਆਰੀ ਦੀ ਸਥਿਤੀ ਪ੍ਰੋfile ਟਿਊਨਿੰਗ ਸੂਟ (ਪੀਟੀਐਸ) ਜਾਂ ਗੋਦ ਲੈਣ ਨਾਲ ਜੁੜੇ ਹੋਰ ਲੋੜੀਂਦੇ ਟੂਲ ਜੋ BSTS ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ

BTI ਦੁਆਰਾ 0.9/CR ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ WG ਵੱਲੋਂ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿ IOP ਟੈਸਟ ਪਲਾਨ ਸੈਕਸ਼ਨ 2 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ BoD ਉਪ-ਨਿਯਮਾਂ [0.9] ਦੁਆਰਾ ਲੋੜੀਂਦੇ IOP ਟੈਸਟਿੰਗ ਲਈ 4.3.1/CR ਨਿਰਧਾਰਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਦੀ ਚੋਣ ਕਰ ਸਕਦਾ ਹੈ। 0.9. BoD 0.9/CR ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ BTI ਦੀ ਮਨਜ਼ੂਰੀ 'ਤੇ IOP ਟੈਸਟਿੰਗ ਲਈ XNUMX/CR ਨਿਰਧਾਰਨ ਦੀ ਆਪਣੀ ਪ੍ਰਵਾਨਗੀ ਦੀ ਸ਼ਰਤ ਵੀ ਲਗਾ ਸਕਦਾ ਹੈ।

0.9/CR Stage ਬਾਹਰ ਜਾਣ ਦੀਆਂ ਲੋੜਾਂ
0.9/CR ਐੱਸtage ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ BoD IOP ਟੈਸਟਿੰਗ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ।

4.4 ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਛੋਟ

ਇੱਕ WG ਹੇਠਾਂ ਦਿੱਤੇ ਇੱਕ ਜਾਂ ਵੱਧ ਪ੍ਰਕਿਰਿਆ ਦੇ ਪੜਾਵਾਂ ਨੂੰ ਛੱਡਣ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ:

0.5/DIPD ਐੱਸtage
0.7/ਐਫਆਈਪੀਡੀ ਐਸtage
ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੇ ਅੰਦਰ ਆਈਓਪੀ ਟੈਸਟਿੰਗ

ਛੋਟ ਦੀ ਬੇਨਤੀ ਕਰਨ ਲਈ, ਡਬਲਯੂ.ਜੀ. ਨੂੰ ਬਲੂਟੁੱਥ SIG [8] ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਪ੍ਰਕਿਰਿਆ ਮੁਆਫੀ ਟੈਮਪਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਹਰੇਕ ਕਮੇਟੀ (ਜਿਵੇਂ, BARB ਜਾਂ BTI) ਨੂੰ ਮੁਆਫੀ ਦੀ ਬੇਨਤੀ ਜਮ੍ਹਾਂ ਕਰਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸਨੂੰ ਦੁਬਾਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।view ਜਾਂ s 'ਤੇ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਜਾਂ ਸੰਬੰਧਿਤ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿਓtage ਕਿ WG ਮੁਆਫੀ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਕਮੇਟੀਆਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੂੰ ਮੁਆਫੀ ਦੀ ਬੇਨਤੀ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇੱਕ ਛੋਟ ਦੀ ਬੇਨਤੀ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:

ਦੀ ਪਛਾਣ ਐੱਸtage(s) ਜੋ WG ਮੁਆਫ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ
ਇੱਕ ਜਾਇਜ਼ ਕਿਉਂ ਹੈ ਕਿ ਐੱਸtage(s) ਨੂੰ ਮੁਆਫ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ
ਹਰੇਕ ਕਮੇਟੀ (ਜਿਵੇਂ ਕਿ, BTI ਅਤੇ/ਜਾਂ BARB) ਦੀ ਇੱਕ ਪਛਾਣ ਜੋ ਦੁਬਾਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈview ਅਤੇ ਛੋਟ ਦੀ ਬੇਨਤੀ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿਓ

ਮੁਆਫੀ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਵਾਲੀ ਕਮੇਟੀ ਨੂੰ ਇਹ ਮੰਗ ਕਰ ਸਕਦੀ ਹੈ ਕਿ WG ਦਾ ਪ੍ਰਤੀਨਿਧੀ ਮੁਆਫੀ ਦੀ ਬੇਨਤੀ 'ਤੇ ਫੈਸਲਾ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ SMPD ਪ੍ਰਕਿਰਿਆ ਮੁਆਫੀ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਲਈ ਇੱਕ ਪੇਸ਼ਕਾਰੀ ਕਰੇ।

ਜੇਕਰ ਮੁਆਫੀ ਦੀ ਬੇਨਤੀ ਕਈ ਕਦਮਾਂ ਨੂੰ ਮੁਆਫ ਕਰਨ ਲਈ ਕਰਦੀ ਹੈ ਅਤੇ ਛੋਟ ਦੇ ਕੁਝ ਹਿੱਸੇ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਹਿੱਸੇ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕਮੇਟੀ ਦੇ ਜਵਾਬ ਵਿੱਚ ਇਹ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਛੋਟ ਦੀ ਬੇਨਤੀ ਵਿੱਚ ਕਿਹੜੇ ਕਦਮਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਗਈ ਸੀ ਅਤੇ ਕਿਨ੍ਹਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਜੇਕਰ ਛੋਟ ਦੀ ਬੇਨਤੀ ਨੂੰ ਅਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਸਵੀਕਾਰ ਸੂਚਨਾ ਵਿੱਚ ਅਸਵੀਕਾਰ ਕਰਨ ਦੇ ਕਾਰਨ ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

5. ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ

ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੇ ਦੌਰਾਨ, WG BARB ਰੀ ਲਈ ਇੱਕ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਉਦੇਸ਼ ਨਾਲ 0.9/CR ਨਿਰਧਾਰਨ 'ਤੇ IOP ਟੈਸਟਿੰਗ ਕਰੇਗਾ।view ਅਤੇ ਪ੍ਰਵਾਨਗੀ. ਜਦੋਂ ਵੀ ਸੰਭਵ ਹੋਵੇ, ਏਕੀਕ੍ਰਿਤ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਦੇ ਵਿਰੁੱਧ ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਦੀ IOP ਟੈਸਟਿੰਗ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ ਮੈਂਬਰ ਰੀview, ਉਪ-ਨਿਯਮਾਂ ਦੁਆਰਾ ਲੋੜ ਅਨੁਸਾਰ [2], ਇਸ ਪੜਾਅ ਦੌਰਾਨ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਜੇਕਰ ਨਿਰਧਾਰਨ (ਜਾਂ ਸੁਧਾਰ) ਨੂੰ IOP ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ ਸੈਕਸ਼ਨ 4.4 ਵਿੱਚ ਵਰਣਿਤ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੇ ਅੰਦਰ ਆਈਓਪੀ ਟੈਸਟਿੰਗ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ।

IOP ਟੈਸਟਿੰਗ (ਜੋ ਕਿ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਇਵੈਂਟਸ ਹੋ ਸਕਦੇ ਹਨ) ਦੇ ਦੌਰਾਨ, WG ਨੂੰ ਬਲੂਟੁੱਥ SIG ਦੇ ਮੁੱਦੇ ਟਰੈਕਿੰਗ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਮੁੱਦਿਆਂ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਡਰਾਫਟ ਨਿਰਧਾਰਨ, ਟੈਸਟ ਦਸਤਾਵੇਜ਼, ਅਤੇ IOP ਟੈਸਟ ਪਲਾਨ ਵਿੱਚ ਅੱਪਡੇਟ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਦੁਹਰਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਵਾਰ IOP ਟੈਸਟਿੰਗ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ, WG ਨੂੰ ਸਾਰੇ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅੱਪਡੇਟ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦੁਬਾਰਾ ਲਈ BARB ਨੂੰ ਇੱਕ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।view ਅਤੇ ਪ੍ਰਵਾਨਗੀ. ਇਹ ਚਿੱਤਰ 5.1 ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੇ ਦੌਰਾਨ ਕਈ ਗਤੀਵਿਧੀਆਂ ਹਨ ਜੋ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਗਤੀਵਿਧੀਆਂ ਸਮਾਨਾਂਤਰ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇਹਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

BoD-ਪ੍ਰਵਾਨਿਤ 0.9/CR ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਨੂੰ BSTS ਦੁਆਰਾ ਮੈਂਬਰ ਰੀ ਦੀ ਸ਼ੁਰੂਆਤ ਦੀ ਸੂਚਨਾ ਦੇ ਨਾਲ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਉਪਲਬਧ ਕਰਵਾਇਆ ਗਿਆ ਹੈ।view ਉਪ-ਨਿਯਮਾਂ ਦੁਆਰਾ ਲੋੜੀਂਦੀ ਮਿਆਦ।
ਕਿਸੇ ਵੀ ਲੋੜੀਂਦੇ ਅੱਪਡੇਟ ਨੂੰ CSS ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜੋ ਨਿਰਧਾਰਨ ਦੇ ਇੱਕ ਸੰਖੇਪ CR ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ)।
ਵਿਸ਼ੇਸ਼ਤਾ ਜਾਂ ਵਰਣਨਕਰਤਾ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ GSS ਨਿਰਧਾਰਨ ਦੇ ਨਾਲ-ਨਾਲ IOP ਟੈਸਟਿੰਗ ਲਈ PTS ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ।
ਮੈਸ਼ ਪ੍ਰਾਪਰਟੀ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ MDP ਨਿਰਧਾਰਨ ਦੇ ਨਾਲ-ਨਾਲ IOP ਟੈਸਟਿੰਗ ਲਈ PTS ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ।
BSTS IOP ਟੈਸਟਿੰਗ ਦੀ ਤਿਆਰੀ ਵਿੱਚ IOP ਪਲੇਟਫਾਰਮ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਨਤੀਜੇ ਐਂਟਰੀ ਟੂਲ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ।
IOP ਟੈਸਟਿੰਗ, ਜੇ ਲੋੜ ਹੋਵੇ (ਸੈਕਸ਼ਨ 5.1 ਦੇਖੋ)।
Review ਟਿੱਪਣੀਆਂ ਅਤੇ ਮੁੱਦੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ IOP ਟੈਸਟਿੰਗ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਹਨ, ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਤਬਦੀਲੀਆਂ ਨੂੰ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

5.1 IOP ਟੈਸਟਿੰਗ

IOP ਟੈਸਟਿੰਗ ਦਾ ਮੁੱਖ ਉਦੇਸ਼, ਉਦਾਹਰਨ ਲਈ, ਦੁਆਰਾ ਨਿਰਧਾਰਨ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈample, ਪਾਠ ਦੇ ਅੰਦਰ ਸ਼ੁੱਧਤਾ ਅਤੇ ਅਸਪਸ਼ਟਤਾ ਦੀ ਜਾਂਚ ਕਰਨਾ, ਮੁੜviewਕਿਸੇ ਵੀ ਬੁਨਿਆਦੀ ਡਿਜ਼ਾਇਨ ਦੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਭੁੱਲਾਂ ਲਈ, ਅਤੇ ਨਿਰਧਾਰਨ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਪਹਿਲਾਂ ਵਿਕਸਤ ਕੀਤੀਆਂ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ ਲੋੜਾਂ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਦਾਨ ਕਰਨਾ। IOP ਟੈਸਟਿੰਗ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਜਾਂਚਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਕਈ IOP ਟੈਸਟ ਇਵੈਂਟਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

WG ਤੋਂ ਬਾਹਰਲੇ ਮੈਂਬਰਾਂ ਨੂੰ IOP ਟੈਸਟਿੰਗ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਦਾ ਮੌਕਾ ਦੇਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਉਹ ਇੱਕ ਸੁਤੰਤਰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ view ਨਿਰਧਾਰਨ ਦਾ ਅਤੇ ਨਿਰਧਾਰਨ ਵਿੱਚ ਅਸਪਸ਼ਟਤਾ ਦੇ ਖੇਤਰਾਂ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਡਰਾਫਟ ਤਿਆਰ ਕਰਨ ਵਾਲੇ ਡਬਲਯੂ.ਜੀ. ਦੇ ਮੈਂਬਰਾਂ ਲਈ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ। ਹਰੇਕ IOP ਟੈਸਟ ਇਵੈਂਟ ਤੋਂ ਪਹਿਲਾਂ, BSTS ਘਟਨਾ ਦੇ ਵੇਰਵੇ, ਨਵੀਨਤਮ ਡਰਾਫਟ ਨਿਰਧਾਰਨ, ਟੈਸਟ ਸੂਟ, ਅਤੇ IOP ਟੈਸਟ ਪਲਾਨ ਉਪਲਬਧ ਕਰਵਾਏਗਾ ਅਤੇ ਹਰੇਕ ਇਵੈਂਟ ਤੋਂ ਇੱਕ ਮਹੀਨਾ ਪਹਿਲਾਂ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਸੂਚਿਤ ਕਰੇਗਾ। ਅੱਪਡੇਟ ਕੀਤਾ ਡਰਾਫਟ ਨਿਰਧਾਰਨ, ਟੈਸਟ ਸੂਟ, ਅਤੇ ਇੱਕ IOP ਟੈਸਟ ਇਵੈਂਟ ਵਿੱਚ ਵਰਤੀ ਗਈ IOP ਟੈਸਟ ਯੋਜਨਾ ਹਰੇਕ ਇਵੈਂਟ ਤੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਹਫ਼ਤਾ ਪਹਿਲਾਂ ਉਪਲਬਧ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

IOP ਟੈਸਟਿੰਗ ਦੇ ਦੌਰਾਨ, ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਜੋੜੇ ਅਨੁਸਾਰ ਸੰਜੋਗ ਟੈਸਟਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ ਅਤੇ IOP ਟੈਸਟਿੰਗ ਭਾਗੀਦਾਰ ਹਰੇਕ ਟੈਸਟ ਅਤੇ ਟਿੱਪਣੀਆਂ ਦੇ ਪਾਸ/ਫੇਲ ਨਤੀਜੇ ਰਿਕਾਰਡ ਕਰਨਗੇ। ਇਹਨਾਂ ਨਤੀਜਿਆਂ ਦਾ ਇੱਕ ਅਗਿਆਤ ਸਾਰਾਂਸ਼ (ਜਿਵੇਂ ਕਿ “ਪਲੇਟਫਾਰਮ ਏ”, “ਪਲੇਟਫਾਰਮ ਬੀ”, ਆਦਿ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹੋਏ) ਅਤੇ ਕੋਈ ਵੀ ਟਿੱਪਣੀਆਂ, IOP ਟੈਸਟ ਇਵੈਂਟਾਂ ਦੌਰਾਨ ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ ਅਤੇ IOP ਦੌਰਾਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ WG ਦੇ ਮੈਂਬਰਾਂ ਨੂੰ ਉਪਲਬਧ ਕਰਵਾਈਆਂ ਜਾਣਗੀਆਂ। ਟੈਸਟ ਘਟਨਾ. ਜੇਕਰ IOP ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਆਈਆਂ ਕਿਸੇ ਵੀ ਟਿੱਪਣੀਆਂ ਜਾਂ ਅਸਫਲਤਾਵਾਂ ਦੀ ਬਿਹਤਰ ਸਮਝ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਾਧੂ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ BSTS ਸਬਮਿਟ ਕਰਨ ਵਾਲੇ ਮੈਂਬਰ ਤੋਂ ਹੋਰ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਲਈ ਇੱਕ ਵਿਚੋਲੇ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।

ਜੇ ਸੰਭਵ ਹੋਵੇ, ਤਾਂ ਹੋਸਟ ਕੰਟਰੋਲਰ ਇੰਟਰਫੇਸ (HCI) ਦੇ ਉੱਪਰ ਸਾਰੀਆਂ ਪਰਤਾਂ 'ਤੇ ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਨਾਲ IOP ਟੈਸਟਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ PTS ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਲੇਅਰਾਂ ਲਈ IOP ਟੈਸਟ ਇਵੈਂਟਾਂ 'ਤੇ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਹੋਰ ਟੈਸਟਿੰਗ ਟੂਲ ਵੀ IOP ਟੈਸਟ ਸਮਾਗਮਾਂ ਵਿੱਚ ਮੌਜੂਦ ਹੋ ਸਕਦੇ ਹਨ। PTS ਜਾਂ ਹੋਰ ਟੈਸਟ ਟੂਲਸ (ਜੇ ਕੋਈ ਹੋਵੇ) ਨਾਲ ਟੈਸਟਿੰਗ ਦੇ ਨਤੀਜਿਆਂ ਦਾ ਸਾਰ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

IOP ਟੈਸਟਿੰਗ ਉਹਨਾਂ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਖੁੱਲੀ ਹੋਵੇਗੀ ਜੋ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਹਾਲਾਂਕਿ, ਬਲੂਟੁੱਥ SIG ਬਲੂਟੁੱਥ SIG (ਭਾਗੀਦਾਰੀ ਅਤੇ ਗੁਪਤਤਾ ਸਮਝੌਤਿਆਂ ਸਮੇਤ) ਨਾਲ ਸਮਝੌਤਿਆਂ ਦੀ ਸਵੀਕ੍ਰਿਤੀ 'ਤੇ ਭਾਗੀਦਾਰੀ ਦੀ ਸ਼ਰਤ ਲਗਾ ਸਕਦਾ ਹੈ। WG IOP ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਲੱਭੇ ਗਏ ਮੁੱਦਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਹੱਲ ਕਰਨ, ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ; WG-ਪ੍ਰਵਾਨਿਤ ਤਬਦੀਲੀਆਂ ਨੂੰ ਹਰੇਕ IOP ਟੈਸਟ ਇਵੈਂਟ ਵਿੱਚ ਵਰਤਣ ਲਈ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅੱਪਡੇਟ ਵਜੋਂ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਤੋਂ ਪਹਿਲਾਂ, WGs ਉਹਨਾਂ ਇਵੈਂਟਾਂ 'ਤੇ ਸ਼ੁਰੂਆਤੀ IOP ਟੈਸਟਿੰਗ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਸਿਰਫ WG ਦੇ ਮੈਂਬਰਾਂ ਲਈ ਖੁੱਲ੍ਹੇ ਹੁੰਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਗੈਰ-ਰਸਮੀ ਟੈਸਟਿੰਗ ਦੇ ਨਤੀਜੇ IOP ਟੈਸਟ ਦੇ ਨਤੀਜਿਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ IOP ਟੈਸਟਿੰਗ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਇਰਾਦੇ ਨਾਲ ਇੱਕ ਘੋਸ਼ਿਤ IOP ਮਿਤੀ ਅਤੇ ਸਥਾਨ ਸਮੇਤ, ਪਹਿਲੇ IOP ਟੈਸਟ ਇਵੈਂਟ ਤੱਕ ਜਾਣ ਵਾਲੇ ਸਾਰੇ ਕਦਮਾਂ ਦੀ ਪਾਲਣਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਟੈਸਟ ਇਵੈਂਟ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ BoD ਪ੍ਰਵਾਨਗੀ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, BoD IOP ਟੈਸਟਿੰਗ ਸ਼ੁਰੂ ਕਰਨ ਲਈ BoD ਦੀ ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਇਕੱਤਰ ਕੀਤੇ ਗਏ ਟੈਸਟ ਨਤੀਜਿਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ ਕਰ ਸਕਦਾ ਹੈ, ਬਸ਼ਰਤੇ ਕਿ ਇਕੱਠੇ ਕੀਤੇ ਨਤੀਜੇ ਉਸੇ ਨਿਰਧਾਰਨ ਅਤੇ BoD ਦੁਆਰਾ ਪ੍ਰਵਾਨਿਤ ਟੈਸਟ ਸੂਟ 'ਤੇ ਅਧਾਰਤ ਹੋਣ।

CSS, GSS, ਜਾਂ MDP ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਸੁਧਾਰਾਂ ਲਈ IOP ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

IOP ਟੈਸਟ ਰਿਪੋਰਟ
IOP ਟੈਸਟਿੰਗ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, WG ਨੂੰ ਇਹ ਦਿਖਾਉਣ ਦੇ ਉਦੇਸ਼ ਨਾਲ BARB ਨੂੰ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਜਮ੍ਹਾਂ ਕਰਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਸੁਤੰਤਰ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਲੋੜੀਂਦੀ ਗਿਣਤੀ ਨੇ ਲੋੜੀਂਦੇ ਟੈਸਟ ਪਾਸ ਕੀਤੇ ਹਨ। ਬਾਰਬ ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview ਅਤੇ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰੋ ਅਤੇ WG ਨੂੰ ਸੂਚਿਤ ਕਰੇਗਾ ਜੇਕਰ ਵੋਟਿੰਗ ਡਰਾਫਟ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਪੈਕੇਜ ਨੂੰ BoD ਨੂੰ ਜਮ੍ਹਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਾਧੂ IOP ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਹੈ। BSTS ਅਤੇ WG ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ BARB ਨੂੰ ਰਿਪੋਰਟ ਜਮ੍ਹਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੋਈ ਮੈਂਬਰ-ਪਛਾਣ ਵਾਲੀ ਜਾਣਕਾਰੀ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਵਿੱਚ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।

IOP ਟੈਸਟ ਰਿਪੋਰਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

ਉਹਨਾਂ ਸਾਰੀਆਂ IOP ਟੈਸਟ ਇਵੈਂਟਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੇ ਦੌਰਾਨ ਹੋਈਆਂ ਉਹਨਾਂ ਦੀਆਂ ਮਿਤੀਆਂ ਅਤੇ ਸਥਾਨਾਂ ਸਮੇਤ।
ਮੈਂਬਰ ਕੰਪਨੀਆਂ ਅਤੇ ਸੁਤੰਤਰ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਸੰਖਿਆ ਜਿਨ੍ਹਾਂ ਨੇ ਹਰੇਕ IOP ਇਵੈਂਟ ਵਿੱਚ ਹਿੱਸਾ ਲਿਆ ਜਿਸ ਵਿੱਚ PTS ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ ਜਾਂ ਨਹੀਂ।
ਹਰੇਕ ਇਵੈਂਟ ਵਿੱਚ ਵਰਤੇ ਗਏ ਨਿਰਧਾਰਨ, ਟੈਸਟ ਸੂਟ, ਅਤੇ IOP ਟੈਸਟ ਪਲਾਨ ਸੰਸਕਰਣਾਂ ਦੀ ਇੱਕ ਸੂਚੀ।
ਇੱਕ ਕਾਰਜਕਾਰੀ ਸੰਖੇਪ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਸਾਰੇ ਟੈਸਟ ਕੇਸ ਘੱਟੋ-ਘੱਟ ਪਾਸ ਮਾਪਦੰਡ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
ਸੈਕਸ਼ਨ 4.3.1 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ IOP ਟੈਸਟ ਪਲਾਨ ਲੋੜਾਂ ਤੋਂ ਕਿਸੇ ਵੀ ਪਰਿਵਰਤਨ ਦਾ ਸਾਰ ਅਤੇ ਹਰੇਕ ਵਿਭਿੰਨਤਾ ਲਈ ਤਰਕ।
ਟੈਸਟ ਸੂਟ ਵਿੱਚ ਟੈਸਟ ਕੇਸਾਂ ਲਈ PTS ਕਵਰੇਜ ਦਾ ਸਾਰ।
IOP ਟੈਸਟ ਪਲਾਨ ਤੋਂ ਸਾਰੇ ਟੈਸਟ ਕੇਸਾਂ (ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਟੈਸਟਾਂ ਸਮੇਤ) ਦੀ ਸੂਚੀ, ਟੈਸਟ ਪਾਸਾਂ ਦੀ ਗਿਣਤੀ, ਟੈਸਟ ਅਸਫਲਤਾਵਾਂ ਦੀ ਗਿਣਤੀ, ਅਤੇ ਕੀ ਪ੍ਰਤੀ ਟੈਸਟ ਕੇਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਮਾਪਦੰਡ ਪੂਰੇ ਕੀਤੇ ਗਏ ਸਨ, ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟੀਕਰਨ ਸਮੇਤ ਕਿ ਕੋਈ ਲੋੜਾਂ ਕਿਉਂ ਨਹੀਂ ਸਨ। ਮਿਲੇ
ਹਰੇਕ ਇਵੈਂਟ ਵਿੱਚ ਮੁੱਦਿਆਂ, ਟਿੱਪਣੀਆਂ ਅਤੇ ਸਵਾਲਾਂ ਦਾ ਸਾਰ (ਉਨ੍ਹਾਂ ਸਮੇਤ filed IOP ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਨਿਰਧਾਰਨ ਦੇ ਵਿਰੁੱਧ) ਅਤੇ ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ 'ਤੇ ਪ੍ਰਭਾਵ।

5.2 ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਨਿਕਾਸ ਦੀਆਂ ਲੋੜਾਂ

ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਪ੍ਰਵਾਨਗੀ/ਗੋਦ ਲੈਣ ਦਾ ਪੜਾਅ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ BARB ਨੇ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਹੁੰਦੀ ਹੈ (ਜਦੋਂ ਤੱਕ BARB ਦੁਆਰਾ ਜਾਂਚ ਨੂੰ ਮੁਆਫ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ) ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਸਾਰੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਹਨ:

BSTS ਨੇ ਮੈਂਬਰ ਰੀ ਲਈ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਪ੍ਰਵਾਨਿਤ 0.9/CR ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਉਪਲਬਧ ਕਰਾਇਆ ਹੈview ਉਪ-ਨਿਯਮਾਂ ਦੁਆਰਾ ਲੋੜ ਅਨੁਸਾਰ ਅਤੇ ਇਸਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕੀਤਾ।
IOP ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਪਛਾਣੇ ਗਏ ਸਾਰੇ ਮੁੱਦੇ, ਅਤੇ ਜਿਨ੍ਹਾਂ ਦਾ ਟੈਸਟ ਪ੍ਰਭਾਵ ਹੈ, ਨੂੰ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਹੈ।
WG ਨੇ IOP ਟੈਸਟਿੰਗ ਨੂੰ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ (ਜਦੋਂ ਤੱਕ BARB ਦੁਆਰਾ ਟੈਸਟਿੰਗ ਨੂੰ ਮੁਆਫ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ)।

6. ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਦਾ ਪੜਾਅ

ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਪੜਾਅ ਦੇ ਦੌਰਾਨ, ਨਿਰਧਾਰਨ ਅਤੇ ਸੰਬੰਧਿਤ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, BARB, BQRB, ਅਤੇ BTI ਪ੍ਰਵਾਨਗੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਨੋਟਿਸ ਗੋਦ ਲੈਣ ਲਈ BoD ਨੂੰ ਜਮ੍ਹਾ ਕੀਤੇ ਗਏ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਦੇ ਅੰਤਮ ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ( ਵੋਟਿੰਗ ਡਰਾਫਟ), ਅਤੇ ਅੰਤਿਮ ਨਿਰਧਾਰਨ ਪੈਕੇਜ BoD ਨੂੰ ਜਮ੍ਹਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੈਂਬਰ ਦੀ ਘੱਟੋ-ਘੱਟ ਮਿਆਦ ਤੋਂ ਬਾਅਦ ਰੀview ਉਪ-ਨਿਯਮਾਂ ਦੁਆਰਾ ਲੋੜੀਂਦਾ [2]) ਸੰਤੁਸ਼ਟ ਹੋ ਗਿਆ ਹੈ, BoD ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ 'ਤੇ ਗੋਦ ਲੈਣ ਲਈ ਨਿਰਧਾਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੇਗਾ। ਗੋਦ ਲੈਣ ਤੋਂ ਬਾਅਦ, ਨਿਰਧਾਰਨ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਯੋਗਤਾ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਦੇ ਪੜਾਅ ਨੂੰ ਚਿੱਤਰ 6.1 ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

6.1 ਵੋਟਿੰਗ ਡਰਾਫਟ

ਵੋਟਿੰਗ ਡਰਾਫਟ ਲੋੜੀਂਦੇ ਨਿਰਧਾਰਨ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਅੱਪਡੇਟ (ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ) ਨੂੰ ਸ਼ਾਮਲ ਕਰਕੇ, ਅਤੇ ਨਵੇਂ ਨਿਰਧਾਰਨ ਦਾ ਅੰਤਮ ਡਰਾਫਟ ਤਿਆਰ ਕਰਕੇ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ, BSTS ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ CR(ਆਂ) ਨੂੰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਉੱਚ ਸੰਸਕਰਣ (ਸੈਕਸ਼ਨ 4.3.2 ਵੇਖੋ) ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰਕੇ ਏਕੀਕ੍ਰਿਤ ਨਿਰਧਾਰਨ ਬਣਾਏਗਾ ਜੇਕਰ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਜੇਕਰ ਇਸ ਪੜਾਅ ਦੌਰਾਨ ਨਿਰਧਾਰਨ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ WG, BARB, ਜਾਂ BTI ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਲਈ ਵਾਧੂ IOP ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਨਿਰਧਾਰਨ ਵਾਧੂ ਟੈਸਟਾਂ ਨੂੰ ਕਰਨ ਲਈ WG ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ ਪੜਾਅ ਦੇ IOP ਟੈਸਟਿੰਗ ਹਿੱਸੇ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਵੇਗਾ। ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਦੇ ਪੜਾਅ ਦੌਰਾਨ, ਹੇਠ ਲਿਖੇ ਦਸਤਾਵੇਜ਼ ਪੂਰੇ ਕੀਤੇ ਜਾਣਗੇ ਅਤੇ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਤੋਂ ਪਹਿਲਾਂ BoD ਨੂੰ ਉਪਲਬਧ ਕਰਵਾਏ ਜਾਣਗੇ:

ਵੋਟਿੰਗ ਡਰਾਫਟ
ਸਾਰੀਆਂ ਸਹਾਇਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਜਿਵੇਂ ਕਿ, CSS, GSS, MDP) ਸੰਬੰਧਿਤ ਨਿਰਧਾਰਨ (ਜਾਂ ਸੁਧਾਰ) ਕਿਸਮ ਲਈ ਲੋੜੀਂਦੇ ਹਨ, ਜੇਕਰ ਪਹਿਲਾਂ ਨਹੀਂ ਅਪਣਾਇਆ ਗਿਆ
ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ, ਵੋਟਿੰਗ ਡਰਾਫਟ ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹੋਏ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਦਾ ਇੱਕ ਤਬਦੀਲੀ-ਟਰੈਕ ਕੀਤਾ ਸੰਸਕਰਣ
ਕਿਸੇ ਵੀ ਪਛੜੀਆਂ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ (ਜਿਵੇਂ ਕਿ ਸੈਕਸ਼ਨ 3.3.2 ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ) ਦਾ WG ਤੋਂ ਇੱਕ ਵੇਰਵਾ ਜੋ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਛੋਟ ਲਈ ਉਚਿਤਤਾ
ਕਿਸੇ ਵੀ IOP ਟੈਸਟ ਪਲਾਨ ਲੋੜਾਂ (ਜਿਵੇਂ ਕਿ ਸੈਕਸ਼ਨ 4.3.1 ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ) ਦਾ WG ਦਾ ਵਰਣਨ ਜੋ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਦੇ ਨਾਲ ਕਿਸੇ ਵੀ ਭਟਕਣ ਲਈ ਜਾਇਜ਼ ਠਹਿਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ (ਜੋ ਕਿ ਇੱਕ ਕਾਪੀ ਲਈ ਲਿੰਕ ਪ੍ਰਦਾਨ ਕਰਕੇ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਬਲੂਟੁੱਥ SIG webਸਾਈਟ)
0.9/CR S ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਉਚਿਤਤਾ ਦੇ ਨਾਲ, ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਦੇ ਕਿਸੇ ਵੀ ਪਿਛਲੇ ਸੰਸਕਰਣ (ਵਾਂ) ਨੂੰ ਬਰਤਰਫ਼ ਕਰਨ ਜਾਂ ਵਾਪਸ ਲੈਣ ਲਈ WG ਤੋਂ ਇੱਕ ਸਿਫ਼ਾਰਿਸ਼।tage ਜੀਵਨ ਦੇ ਅੰਤ ਦੀ ਸਿਫ਼ਾਰਸ਼
ਇੱਕ ਸੰਖੇਪ, WG ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ, 0.9/CR ਨਿਰਧਾਰਨ (ਜੇ ਕੋਈ ਹੈ) ਤੋਂ ਬਾਅਦ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਾਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦਾ
BARB ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਇੱਕ ਸੰਖੇਪ, BARB ਮੈਂਬਰਾਂ ਦੁਆਰਾ ਉਠਾਈਆਂ ਗਈਆਂ ਚਿੰਤਾਵਾਂ ਦਾ ਕਿ WG ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਨਿਰਧਾਰਨ BoD ਦੁਆਰਾ ਪ੍ਰਵਾਨਿਤ ਚਾਰਟਰ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ (ਜੇ ਕੋਈ ਹੈ)
ਕਾਨੂੰਨੀ ਮੁੜ ਤੋਂ ਬਾਕੀ ਅਣਸੁਲਝੇ ਕਾਨੂੰਨੀ ਮੁੱਦਿਆਂ ਦੀ ਸੂਚੀview (ਜੇ ਕੋਈ ਹੈ)
BTI-ਪ੍ਰਵਾਨਿਤ ਟੈਸਟ ਸੂਟ, ਵੋਟਿੰਗ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਦੇ ਟੈਸਟ ਕਵਰੇਜ ਦੇ WG-ਪ੍ਰਵਾਨਿਤ ਸਾਰਾਂਸ਼ ਦੇ ਨਾਲ। ਟੈਸਟ ਕਵਰੇਜ ਤੋਂ ਬਿਨਾਂ ਨਵੇਂ-ਜੋੜੇ ਜਾਂ ਸੰਸ਼ੋਧਿਤ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਭੁੱਲ ਲਈ ਇੱਕ ਲਿਖਤੀ ਤਰਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ
BTI-ਪ੍ਰਵਾਨਿਤ ICS ਅਤੇ IXIT (ਜੇਕਰ ਨਿਰਧਾਰਨ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ)
TCRL BTI ਅਤੇ BQRB ਦੋਵਾਂ ਦੁਆਰਾ ਪ੍ਰਵਾਨਿਤ ਹੈ
BSTS ਦੁਆਰਾ ਟੂਲ ਦੀ ਤਿਆਰੀ (ਉਦਾਹਰਨ ਲਈ, PTS ਅਤੇ ਹੋਰ ਟੈਸਟ ਟੂਲ, ਬਲੂਟੁੱਥ ਲਾਂਚ ਸਟੂਡੀਓ) ਦੀ ਸਥਿਤੀ ਬਾਰੇ BTI ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਤਿਆਰ ਕੀਤੀ ਗਈ ਇੱਕ ਰਿਪੋਰਟ ਜਿਸ ਵਿੱਚ TCRL ਵਿੱਚ ਕੋਈ ਵੀ ਟੈਸਟ ਕੇਸ ਟੈਸਟ ਟੂਲਸ ਦੁਆਰਾ ਸਮਰਥਿਤ ਨਹੀਂ ਹਨ।
ਸਾਰੇ ਜ਼ਰੂਰੀ ਨਿਰਧਾਰਤ ਸੰਖਿਆਵਾਂ ਦਾ ਇੱਕ ਸੰਖੇਪ, WG ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ
BSTS ਅਤੇ WG ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਗਈ ਗੋਦ ਲੈਣ ਦੀ ਚੈਕਲਿਸਟ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਸ ਸੈਕਸ਼ਨ ਵਿੱਚ ਸਾਰੇ ਡਿਲੀਵਰੇਬਲ ਪੂਰੇ ਹੋ ਗਏ ਹਨ
BoD ਦੁਆਰਾ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਹੋਰ ਸਾਰੀ ਜਾਣਕਾਰੀ

ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਦੇ ਪੜਾਅ ਦੇ ਦੌਰਾਨ, ਡਬਲਯੂਜੀ ਨੂੰ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਅਤੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਵਿਰੁੱਧ ਮੁੱਦਿਆਂ ਅਤੇ ਟਿੱਪਣੀਆਂ ਨੂੰ ਹਾਸਲ ਕਰਨ ਲਈ ਬਲੂਟੁੱਥ SIG ਦੇ ਮੁੱਦੇ ਟਰੈਕਿੰਗ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਵੋਟਿੰਗ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਵਿੱਚ ਉਹਨਾਂ ਦਾ ਲੇਖਾ-ਜੋਖਾ ਕੀਤਾ ਜਾ ਸਕੇ। ਇੱਕ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਲਈ, ਸਾਰੇ ਸੰਬੰਧਿਤ ਪ੍ਰਵਾਨਿਤ ਇਰੱਟਾ (ਭਾਵ ਉਹ ਪ੍ਰਵਾਨਿਤ ਇਰੱਟਾ ਜੋ ਅਜੇ ਤੱਕ ਏਕੀਕ੍ਰਿਤ ਨਹੀਂ ਹਨ) ਨੂੰ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਟਰੈਕ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਛਾਣਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਡਬਲਯੂ.ਜੀ. ਨੂੰ ਕਾਨੂੰਨੀ ਮੁੜ ਪ੍ਰਾਪਤੀ ਲਈ ਅੰਤਿਮ ਖਰੜਾ ਨਿਰਧਾਰਨ BSTS ਨੂੰ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview. ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ, ਕਾਨੂੰਨੀ ਰੀview ਪੂਰੀ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਸ਼ਾਮਲ ਹੋਵੇਗੀ। ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਵਧਾਉਣ ਲਈ, ਰੀview ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਬਦਲੇ ਹੋਏ ਹਿੱਸਿਆਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੇਗਾ। ਕਾਨੂੰਨੀ ਮੁੜ ਦਾ ਉਦੇਸ਼view ਮੁੱਖ ਤੌਰ 'ਤੇ ਕਾਨੂੰਨੀ ਜੋਖਮਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ WG ਨੂੰ ਵਿਚਾਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਕਾਨੂੰਨੀ ਫੀਡਬੈਕ ਨੂੰ ਗੰਭੀਰਤਾ ਦੇ ਆਧਾਰ 'ਤੇ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਜਾਵੇਗਾ। ਜੇਕਰ ਕੋਈ ਵਿਕਲਪਿਕ ਕਾਨੂੰਨੀ ਰੀview 0.9/CR S 'ਤੇ ਕੀਤਾ ਗਿਆ ਸੀtage, ਉਹ ਸੰਸਕਰਣ ਜੋ ਕਨੂੰਨੀ ਮੁੜ ਲਈ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈview ਉਸ ਸੰਸਕਰਣ ਤੋਂ ਬਾਅਦ ਕੀਤੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ (ਜਾਂ ਤਾਂ WG ਜਾਂ BSTS ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ) ਨੂੰ ਟਰੈਕ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview, WG ਅਤੇ BSTS ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ। ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀ ਤੋਂ ਕੋਈ ਅਣਸੁਲਝੀਆਂ ਕਾਨੂੰਨੀ ਟਿੱਪਣੀਆਂ ਹਨview ਡਰਾਫਟ ਨਿਰਧਾਰਨ 'ਤੇ, WG ਚੇਅਰ ਮਤੇ 'ਤੇ ਸਹਿਮਤ ਹੋਣ ਲਈ BoD ਏਜੰਡੇ 'ਤੇ ਸਮੇਂ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦੀ ਹੈ।

ਕਾਨੂੰਨੀ ਰੀ ਦੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚview, WG ਨੂੰ ਦੁਬਾਰਾ ਲਈ ਡਰਾਫਟ ਨਿਰਧਾਰਨ BARB ਨੂੰ ਜਮ੍ਹਾਂ ਕਰਾਉਣਾ ਚਾਹੀਦਾ ਹੈview. BARB ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਸਪੁਰਦਗੀ 'ਤੇ, BSTS ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੇਗਾ ਕਿ ਡਰਾਫਟ ਨਿਰਧਾਰਨ BARB ਨੂੰ ਦੁਬਾਰਾ ਲਈ ਜਮ੍ਹਾ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ।view ਅਤੇ ਇਹ ਕਿ ਇਹ ਮੈਂਬਰ ਰੀ ਲਈ ਵੀ ਉਪਲਬਧ ਹੈview. ਜੇਕਰ WG BARB ਰੀ-ਰੀ ਲਈ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਲਈ ਅੱਪਡੇਟ ਜਮ੍ਹਾਂ ਕਰਦਾ ਹੈview, BSTS ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਵਾਧੂ ਨੋਟਿਸ ਭੇਜੇਗਾ।

BARB ਦੇ ਪੂਰਾ ਹੋਣ 'ਤੇ ਮੁੜview, WG ਅਤੇ BARB ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ।

ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀview ਕਿਸੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਵਾਧੂ ਮੁੜview BARB ਦੁਆਰਾ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇਕਰ BARB ਮੁੜview ਕਿਸੇ ਵੀ ਠੋਸ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, BSTS ਇਹ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਕੀ ਕੋਈ ਵਾਧੂ ਕਾਨੂੰਨੀ ਰੀview ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੈ। ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview ਅਤੇ ਬਾਰਬ ਰੀview, BARB ਨੂੰ ਵੋਟਿੰਗ ਡਰਾਫਟ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇਕਰ ਕਿਸੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ BSTS ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਵਿੱਚ WG ਦੀ ਮਦਦ ਕਰੇਗਾ। BTI ਨੂੰ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ BTI ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, BTI TCRL ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਅਤੇ ਇਸ ਦਸਤਾਵੇਜ਼ ਨੂੰ BQRB ਨੂੰ ਸਬੰਧਿਤ ICS, IXIT, ਅਤੇ ਟੈਸਟ ਸੂਟ ਦੇ ਨਾਲ ਪ੍ਰਦਾਨ ਕਰੇਗਾ। BSTS BoD ਮੀਟਿੰਗ ਦੀ ਮਿਤੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਏਗਾ ਜਦੋਂ BoD ਵੋਟਿੰਗ ਡਰਾਫਟ (ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ) ਨੂੰ ਅਪਣਾਉਣ 'ਤੇ ਵੋਟ ਪਾਉਣ ਦਾ ਇਰਾਦਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ TCRL ਵਿੱਚ ਵਰਤਣ ਲਈ BTI ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਨਿਰਧਾਰਨ ਦੀ BARB ਪ੍ਰਵਾਨਗੀ, ਸਾਰੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ BTI ਪ੍ਰਵਾਨਗੀ (ਟੈਸਟ ਸੂਟ, TCRL, ICS, ਅਤੇ IXIT ਸਮੇਤ), ਅਤੇ TCRL ਦੀ BQRB ਪ੍ਰਵਾਨਗੀ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਨੂੰ ਜਾਂ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

BSTS ਵੋਟਿੰਗ ਡਰਾਫਟ ਅਤੇ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਅਤੇ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੇਗਾ। ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਮੈਂਬਰਾਂ ਨੂੰ BoD-ਪ੍ਰਵਾਨਿਤ 60/CR ਨਿਰਧਾਰਨ ਬਾਰੇ ਸੂਚਿਤ ਕੀਤੇ ਜਾਣ ਤੋਂ 0.9 ਦਿਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ, ਜਦੋਂ ਤੱਕ ਮੈਂਬਰ ਮੁੜview ਮਿਆਦ ਨੂੰ ਬੀਓਡੀ ਦੁਆਰਾ ਉਪ-ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਛੋਟਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਪ-ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਮੈਂਬਰਾਂ ਨੂੰ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦੇ ਨੋਟਿਸ ਦੇ ਘੱਟੋ-ਘੱਟ 14 ਦਿਨਾਂ ਬਾਅਦ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਲਈ ਜਿੱਥੇ ਇੱਕ ਤੋਂ ਵੱਧ ਸੀਆਰ ਇੱਕ ਵੋਟਿੰਗ ਡਰਾਫਟ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕੀਤੇ ਗਏ ਹਨ, ਮੈਂਬਰ ਰੀ ਦੀ ਸ਼ੁਰੂਆਤview ਉਹ ਤਾਰੀਖ ਹੈ ਜਿਸ 'ਤੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸਭ ਤੋਂ ਤਾਜ਼ਾ BoD-ਪ੍ਰਵਾਨਿਤ CR ਬਾਰੇ ਸੂਚਿਤ ਕੀਤਾ ਗਿਆ ਸੀ।

ਮੈਂਬਰਾਂ ਨੂੰ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਨੋਟਿਸ ਦਿੱਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਵੋਟਿੰਗ ਡਰਾਫਟ ਵਿੱਚ ਟਾਈਪੋਗ੍ਰਾਫਿਕਲ ਗਲਤੀਆਂ ਲਈ BoD-ਪ੍ਰਵਾਨਿਤ ਸੁਧਾਰਾਂ ਦੀ ਆਗਿਆ ਹੈ। ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਅਡੌਪਸ਼ਨ ਟਾਈਮਲਾਈਨ ਨੂੰ ਚਿੱਤਰ 6.2 ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

6.2 ਨਿਰਧਾਰਤ ਨੰਬਰ

ਬਲੂਟੁੱਥ SIG ਬਲੂਟੁੱਥ SIG ਅਸਾਈਨ ਕੀਤੇ ਨੰਬਰਾਂ 'ਤੇ ਨਿਰਧਾਰਤ ਨੰਬਰਾਂ ਦੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਸੈੱਟ ਨੂੰ ਕਾਇਮ ਰੱਖਦਾ ਹੈ। webਸਾਈਟ [7]. ਇਹ ਨਿਰਧਾਰਤ ਸੰਖਿਆਵਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਨੰਬਰ ਸਪੇਸ (ਬਿਨਾਂ ਡੁਪਲੀਕੇਟ ਦੇ ਸੰਖਿਆਵਾਂ ਦਾ ਇੱਕ ਸੰਬੰਧਿਤ ਸਮੂਹ) ਵਿੱਚ ਸਮੂਹਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ। ਨਿਰਧਾਰਤ ਨੰਬਰ ਵੱਖ-ਵੱਖ ਨੰਬਰ ਸਪੇਸ ਵਿੱਚ ਹੋਰ ਨਿਰਧਾਰਤ ਸੰਖਿਆਵਾਂ ਦੇ ਨਾਲ ਓਵਰਲੈਪ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਇੱਕ ਨੰਬਰ ਸਪੇਸ ਵਿੱਚ ਕਿਸੇ ਵੀ ਨੰਬਰ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ। ਵੱਖ-ਵੱਖ ਨੰਬਰ ਸਪੇਸ ਨਿਰਧਾਰਨ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ ਜੋ ਨਿਰਧਾਰਤ ਸੰਖਿਆਵਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ।

BARB ਦੁਆਰਾ IOP ਟੈਸਟ ਰਿਪੋਰਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਬਾਅਦ, WG ਅੰਤਿਮ ਨਿਰਧਾਰਨ ਦੁਆਰਾ ਲੋੜੀਂਦੇ ਨੰਬਰ ਸਪੇਸ ਦੇ ਅੰਦਰ ਨਵੇਂ ਨੰਬਰਾਂ ਦੇ ਅਸਾਈਨਮੈਂਟ ਲਈ BARB ਨੂੰ ਇੱਕ ਬੇਨਤੀ ਦਰਜ ਕਰੇਗਾ। BARB ਮੁੜ ਕਰੇਗਾview ਨਿਰਧਾਰਤ ਨੰਬਰਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਬੇਨਤੀ ਕਰੋ ਅਤੇ BSTS ਨਾਲ ਕੰਮ ਕਰੋ। BARB ਦੀ ਮਨਜ਼ੂਰੀ 'ਤੇ, BSTS ਬਲੂਟੁੱਥ SIG ਅਸਾਈਨ ਕੀਤੇ ਨੰਬਰਾਂ 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਵਾਏ ਜਾਣ ਵਾਲੇ ਨਿਰਧਾਰਤ ਨੰਬਰਾਂ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਨੂੰ ਤਹਿ ਕਰੇਗਾ। webਸਾਈਟ [7] ਨਿਰਧਾਰਨ ਨੂੰ ਅਪਣਾਉਣ ਦੇ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ.

ਬਲੂਟੁੱਥ SIG ਅਸਾਈਨ ਕੀਤੇ ਨੰਬਰਾਂ 'ਤੇ ਨਿਰਧਾਰਤ ਨੰਬਰਾਂ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਬਾਅਦ webਸਾਈਟ ਜਾਂ ਇੱਕ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਦੇ ਅੰਦਰ ਵਾਪਰਦਾ ਹੈ, ਨਿਰਧਾਰਤ ਸੰਖਿਆਵਾਂ ਨੂੰ ਅਟੱਲ ਹੋਣ ਦਾ ਇਰਾਦਾ ਹੈ (ਕਿਸੇ ਮੁੱਲ ਜਾਂ ਅਰਥ ਵਿੱਚ ਤਬਦੀਲੀ ਨਾ ਕਰਨ ਲਈ)। ਜੇਕਰ ਉਹ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਵਰਤੋਂਯੋਗ ਨਹੀਂ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਰਾਖਵੇਂ ਮੁੱਲ ਬਣ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੁੰਦੀ।

6.3 ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਦੇ ਪੜਾਅ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦੀਆਂ ਲੋੜਾਂ

ਪ੍ਰਵਾਨਗੀ/ਗੋਦ ਲੈਣ ਦਾ ਪੜਾਅ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ BoD ਨੇ ਨਿਰਧਾਰਨ ਨੂੰ ਅਪਣਾ ਲਿਆ ਹੈ ਅਤੇ ਗੋਦ ਲੈਣ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਹੇਠ ਲਿਖੀਆਂ ਗਤੀਵਿਧੀਆਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਹਨ:

BSTS ਨੇ ਅੰਤਿਮ ਨਿਰਧਾਰਤ ਨੰਬਰਾਂ ਨੂੰ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਾਇਆ ਹੈ webਸਾਈਟ.
BSTS ਨੇ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਨੂੰ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਾਇਆ ਹੈ webਸਾਈਟ
BSTS ਨੇ ਸੰਬੰਧਿਤ ਨਿਰਧਾਰਨ ਲਈ ਲੋੜੀਂਦੇ ਸਾਰੇ ਸਹਾਇਕ ਦਸਤਾਵੇਜ਼ (ਉਦਾਹਰਨ ਲਈ, CSS, GSS, MDP) ਬਲੂਟੁੱਥ SIG 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਵਾਏ ਹਨ। webਸਾਈਟ.
BSTS ਨੇ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਸੰਬੰਧਿਤ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ ਉਪਲਬਧ ਕਰਵਾਏ ਹਨ webਸਾਈਟ.
ਨਿਰਧਾਰਨ ਸੁਧਾਰਾਂ ਲਈ, BSTS ਨੇ ਨਵੇਂ ਅਪਣਾਏ ਗਏ ਸੰਸਕਰਣ ਦੁਆਰਾ ਕੀਤੀਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦੇ ਨਾਲ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਦਾ ਇੱਕ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਤਬਦੀਲੀ-ਟਰੈਕ ਕੀਤਾ ਸੰਸਕਰਣ ਬਣਾਇਆ ਹੈ ਅਤੇ ਇਸਨੂੰ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਉਪਲਬਧ ਕਰਾਇਆ ਹੈ। webਸਾਈਟ.
BSTS ਨੇ ਯੋਗਤਾ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ ਹੈ।
BSTS ਨੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਅਤੇ ਸਾਰੇ ਸਹਾਇਕ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸੂਚਿਤ ਕੀਤਾ ਹੈ।

ਬਲੂਟੁੱਥ SIG ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਨੂੰ ਅਪਣਾਉਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ ਇਹਨਾਂ ਪੋਸਟ-ਅਪਸ਼ਨ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ।

7. ਨਿਰਧਾਰਨ ਮੇਨਟੇਨੈਂਸ ਪੜਾਅ

ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਮੇਨਟੇਨੈਂਸ ਪੜਾਅ ਗੋਦ ਲੈਣ/ਪ੍ਰਵਾਨਗੀ ਪੜਾਅ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਜਾਂ ਸਬੰਧਿਤ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ (ਜਿਵੇਂ ਕਿ ਸ਼ਬਦਾਂ ਦੀ ਅਸਪਸ਼ਟਤਾ ਜਾਂ ਤਕਨੀਕੀ ਤਰੁੱਟੀਆਂ) ਪਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਬਲੂਟੁੱਥ SIG ਇਰੱਟਾ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਰੱਟਾ ਪ੍ਰਸਤਾਵ ਬਣਾ ਕੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਿਰਧਾਰਨ ਇਰੱਟਮ ਪ੍ਰਸਤਾਵਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਵੇਗੀ, ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤੀ ਜਾਵੇਗੀ, ਅਤੇ EPD [3] ਦੇ ਅਨੁਸਾਰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਵੇਗੀ। ਟੈਸਟ ਸੂਟ ਇਰੱਟਮ ਨੂੰ TSTO [5] ਦੇ ਅਨੁਸਾਰ ਸੰਸਾਧਿਤ ਅਤੇ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ SMPD ਅਤੇ EPD ਜਾਂ TSTO ਵਿਚਕਾਰ ਕੋਈ ਟਕਰਾਅ ਹੈ, ਤਾਂ SMPD ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਨਿਰਧਾਰਨ ਇਰੱਟਮ ਦੀ ਵਰਤੋਂ ਕੇਵਲ ਅੰਤਿਮ ਅਪਣਾਏ ਗਏ ਬਲੂਟੁੱਥ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਤਕਨੀਕੀ ਜਾਂ ਸੰਪਾਦਕੀ ਗਲਤੀਆਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਜੋੜਨਾ, ਇਸ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨਾ ਅਤੇ ਹਟਾਉਣਾ ਸਿਰਫ਼ ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਹੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

7.1 ਤੇਜ਼ ਇਰਟਮ ਪ੍ਰਕਿਰਿਆ

ਜਦੋਂ EPD [3] ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਪ੍ਰਕਿਰਿਆ ਦੇ ਬਾਅਦ ਇੱਕ ਇਰੱਟਮ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ WG, BARB, ਜਾਂ BSTS ਸਿਫਾਰਸ਼ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਇਸਨੂੰ ਜ਼ਰੂਰੀ ਸਮਝਿਆ ਜਾਵੇ ਅਤੇ ਇਸ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ ਜਾਵੇ। ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, BSTS WG ਜਾਂ BARB ਦੇ ਨਾਲ BoD ਨੂੰ ਸਿਫ਼ਾਰਸ਼ ਪੇਸ਼ ਕਰਨਗੇ। BoD ਫੈਸਲਾ ਕਰੇਗਾ ਕਿ ਕੀ ਸਿਫ਼ਾਰਿਸ਼ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ ਜਾਂ ਰੱਦ ਕਰਨਾ ਹੈ। ਜੇਕਰ ਸਿਫ਼ਾਰਿਸ਼ ਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ BSTS ਤੁਰੰਤ ਇਰੱਟਮ ਟੈਂਪਲੇਟ ਵਿੱਚ ਪ੍ਰਵਾਨਿਤ ਇਰੱਟਮ ਨੂੰ ਸ਼ਾਮਲ ਕਰੇਗਾ [8] ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ WG ਨਾਲ ਕੰਮ ਕਰੇਗਾ ਤਾਂ ਜੋ ਇੱਕ ਤੇਜ਼ ਇਰੱਟਾ ਸੁਧਾਰ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦਿੱਤਾ ਜਾ ਸਕੇ।view ਅਤੇ ਪ੍ਰਵਾਨਗੀ.

ਇੱਕ ਓਵਰview ਤੇਜ਼ ਇਰੱਟਮ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚਿੱਤਰ 7.1 ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਨਿਮਨਲਿਖਤ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰਾ ਕਰਨਾ ਅਤੇ BoD ਨੂੰ ਉਪਲਬਧ ਕਰਾਉਣਾ ਚਾਹੀਦਾ ਹੈ:

BARB-ਪ੍ਰਵਾਨਿਤ ਡਰਾਫਟ ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ।
ਕਿਸੇ ਵੀ ਪਛੜੀਆਂ ਅਨੁਕੂਲਤਾ ਲੋੜਾਂ (ਜਿਵੇਂ ਕਿ ਸੈਕਸ਼ਨ 3.3.2 ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ) ਦਾ WG ਤੋਂ ਇੱਕ ਵੇਰਵਾ ਜੋ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਛੋਟ ਲਈ ਜਾਇਜ਼ ਹੈ।
ਕਾਨੂੰਨੀ ਮੁੜ ਤੋਂ ਬਾਕੀ ਅਣਸੁਲਝੇ ਕਾਨੂੰਨੀ ਮੁੱਦਿਆਂ ਦੀ ਸੂਚੀview (ਜੇ ਕੋਈ ਹੋਵੇ)।
BTI-ਪ੍ਰਵਾਨਿਤ ਟੈਸਟ ਸੂਟ, ICS, ਅਤੇ IXIT (ਜੇਕਰ ਇੱਰਟਮ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ)।
BTI- ਅਤੇ BQRB-ਪ੍ਰਵਾਨਿਤ TCRL (ਜੇਕਰ ਇੱਰਟਮ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ)।
BSTS ਦੁਆਰਾ ਸੰਦ ਦੀ ਤਿਆਰੀ (ਉਦਾਹਰਨ ਲਈ, PTS ਅਤੇ ਹੋਰ ਟੈਸਟ ਟੂਲ, ਬਲੂਟੁੱਥ ਲਾਂਚ ਸਟੂਡੀਓ) ਦੀ ਸਥਿਤੀ ਬਾਰੇ BTI ਦੇ ਨਾਲ ਪੂਰੀ ਕੀਤੀ ਗਈ ਇੱਕ ਰਿਪੋਰਟ ਜਿਸ ਵਿੱਚ TCRL ਵਿੱਚ ਕੋਈ ਵੀ ਟੈਸਟ ਕੇਸ ਟੈਸਟ ਟੂਲਸ ਦੁਆਰਾ ਸਮਰਥਿਤ ਨਹੀਂ ਹਨ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟੀਕਰਨ (ਜੇਕਰ ਇਰਟਮ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ) ).
BSTS ਅਤੇ WG ਦੁਆਰਾ ਪੂਰੀ ਕੀਤੀ ਗਈ ਗੋਦ ਲੈਣ ਦੀ ਜਾਂਚ ਸੂਚੀ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਸ ਸੈਕਸ਼ਨ ਵਿੱਚ ਡਿਲੀਵਰੇਬਲ ਸਾਰੇ ਪੂਰੇ ਹੋ ਗਏ ਹਨ।
BoD ਦੁਆਰਾ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਹੋਰ ਸਾਰੀ ਜਾਣਕਾਰੀ।

BSTS ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਦੇ ਡਰਾਫਟ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ WG ਨਾਲ ਕੰਮ ਕਰੇਗਾ ਅਤੇ ਦੁਬਾਰਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ WG ਨੂੰ ਜਮ੍ਹਾਂ ਕਰਾਉਣ ਲਈ ਇੱਕ ਸੰਸਕਰਣ ਤਿਆਰ ਕਰੇਗਾ।view ਅਤੇ ਪ੍ਰਵਾਨਗੀ.

ਡਬਲਯੂ.ਜੀ. ਨੂੰ ਕਾਨੂੰਨੀ ਮੁੜ ਪ੍ਰਾਪਤੀ ਲਈ BSTS ਨੂੰ ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview. ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview, WG ਅਤੇ BSTS ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ। ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀ ਤੋਂ ਕੋਈ ਅਣਸੁਲਝੀਆਂ ਕਾਨੂੰਨੀ ਟਿੱਪਣੀਆਂ ਹਨview ਤੇਜ਼ ਇਰੱਟਾ ਸੁਧਾਰ 'ਤੇ, WG ਚੇਅਰ ਰੈਜ਼ੋਲਿਊਸ਼ਨ 'ਤੇ BoD ਇਨਪੁਟ ਲੈਣ ਲਈ BoD ਏਜੰਡੇ 'ਤੇ ਸਮਾਂ ਮੰਗ ਸਕਦੀ ਹੈ।

ਕਾਨੂੰਨੀ ਰੀ ਦੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚview, WG ਨੂੰ ਮੁੜ ਲਈ BARB ਨੂੰ ਤੇਜ਼ ਇਰੱਟਾ ਸੁਧਾਰ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview. ਇੱਕ ਵਾਰ ਤੇਜ਼ੀ ਨਾਲ ਇਰੱਟਾ ਸੁਧਾਰ BARB ਨੂੰ ਜਮ੍ਹਾ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, BSTS ਇਸਨੂੰ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਮੁੜ ਪਹੁੰਚਯੋਗ ਬਣਾ ਦੇਵੇਗਾ।view ਅਤੇ ਇਸਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੋ। BARB ਦੇ ਪੂਰਾ ਹੋਣ 'ਤੇ ਮੁੜview, WG ਅਤੇ BARB ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ।

ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀview ਕਿਸੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਵਾਧੂ ਮੁੜview BARB ਦੁਆਰਾ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇਕਰ BARB ਮੁੜview ਕਿਸੇ ਵੀ ਠੋਸ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, BSTS ਇਹ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਕੀ ਕੋਈ ਵਾਧੂ ਕਾਨੂੰਨੀ ਰੀview ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੈ। ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview ਅਤੇ ਬਾਰਬ ਰੀview, BARB ਨੂੰ ਜਾਂ ਤਾਂ ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇਕਰ ਕਿਸੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ BSTS ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਵਿੱਚ WG ਦੀ ਮਦਦ ਕਰੇਗਾ। ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ BTI ਦੀ ਮਨਜ਼ੂਰੀ 'ਤੇ, BTI TCRL ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਨੂੰ BQRB ਦੇ ਨਾਲ ਸੰਬੰਧਿਤ ICS, IXIT, ਅਤੇ ਟੈਸਟ ਸੂਟ ਦੇ ਨਾਲ ਲਾਗੂ ਕਰੇਗਾ। BSTS ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਅਨੁਮਾਨ ਲਗਾਏਗਾ ਅਤੇ ਇਸਨੂੰ TCRL ਵਿੱਚ ਵਰਤਣ ਲਈ BTI ਨੂੰ ਪ੍ਰਦਾਨ ਕਰੇਗਾ। ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਦੀ BARB ਪ੍ਰਵਾਨਗੀ, ਸਾਰੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ BTI ਪ੍ਰਵਾਨਗੀ (ਟੈਸਟ ਸੂਟ, TCRL, ICS, ਅਤੇ IXIT ਜਿਵੇਂ ਕਿ ਲਾਗੂ ਹੋਵੇ), ਅਤੇ TCRL ਦੀ BQRB ਪ੍ਰਵਾਨਗੀ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਨੂੰ ਜਾਂ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

BSTS ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਅਤੇ ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਅਤੇ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸੂਚਿਤ ਕਰੇਗਾ। ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਉਪ-ਨਿਯਮਾਂ [2] ਦੇ ਅਨੁਸਾਰ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਅਤੇ ਸੂਚਿਤ ਕੀਤੀ ਜਾਵੇਗੀ ਅਤੇ ਮੈਂਬਰਾਂ ਨੂੰ ਨੋਟਿਸ ਪ੍ਰਦਾਨ ਕੀਤੇ ਜਾਣ ਤੋਂ ਘੱਟੋ-ਘੱਟ 14 ਦਿਨ ਬਾਅਦ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਹੋਵੇਗੀ। ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਨੋਟਿਸ ਮੈਂਬਰਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, BoD ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਵਾਧੂ ਨੋਟਿਸ ਪ੍ਰਦਾਨ ਕੀਤੇ ਬਿਨਾਂ ਅਤੇ ਲੋੜੀਂਦੇ 14 ਦਿਨਾਂ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਐਕਸਪੀਡੀਟਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਵਿੱਚ ਟਾਈਪੋਗ੍ਰਾਫਿਕਲ ਗਲਤੀਆਂ ਦੇ ਸੁਧਾਰ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦਾ ਹੈ।

ਬਲੂਟੁੱਥ SIG ਅਪਣਾਏ ਗਏ ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਨੂੰ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਵਾਏਗਾ ਅਤੇ ਗੋਦ ਲੈਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ ਅਜਿਹਾ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਿਹਾ ਹੈ। ਇਸਦੀ ਉਪਲਬਧਤਾ ਦੀ ਸੂਚਨਾ BSTS ਦੁਆਰਾ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਜਾਰੀ ਕੀਤੀ ਜਾਵੇਗੀ।

ਤੇਜ਼ ਇਰੱਟਮ ਪ੍ਰਕਿਰਿਆ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ BoD ਨੇ ਤੇਜ਼ ਇਰੱਟਾ ਸੁਧਾਰ ਨੂੰ ਅਪਣਾ ਲਿਆ ਹੈ ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਪੋਸਟ-ਅਡੌਪਸ਼ਨ ਗਤੀਵਿਧੀਆਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਹਨ:

BSTS ਨੇ ਅਪਣਾਏ ਹੋਏ ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਅਤੇ ਸੰਬੰਧਿਤ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ (ਜੇਕਰ ਇਰੇਟਮ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ) ਨੂੰ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਵਾਇਆ ਹੈ। webਸਾਈਟ.
BSTS ਨੇ ਯੋਗਤਾ ਪ੍ਰਣਾਲੀ ਨੂੰ ਯੋਗ ਕੀਤਾ ਹੈ (ਜੇਕਰ ਇੱਰਟਮ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ)।
BSTS ਨੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਅਪਣਾਏ ਐਕਸਪੀਡਿਡ ਇਰੱਟਾ ਸੁਧਾਰ ਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸੂਚਿਤ ਕੀਤਾ ਹੈ।

ਇਹਨਾਂ ਗਤੀਵਿਧੀਆਂ ਦੇ ਪੂਰਾ ਹੋਣ 'ਤੇ, ਇਰੱਟਾ ਸੁਧਾਰ ਪ੍ਰਭਾਵਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਏਕੀਕਰਣ ਲਈ ਯੋਜਨਾਬੱਧ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਜਾਂ ਸੈਕਸ਼ਨ 7.2 ਵਿੱਚ ਦੱਸੇ ਅਨੁਸਾਰ ਆਉਣ ਵਾਲੇ ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਵਿੱਚ ਤਹਿ ਕੀਤਾ ਜਾਵੇਗਾ।

7.2 ਰੱਖ-ਰਖਾਅ ਜਾਰੀ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ (.Z ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ)

ਲਗਭਗ ਸਾਲਾਨਾ ਆਧਾਰ 'ਤੇ, BSTS ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੇਗਾ ਕਿ ਕੀ ਕੋਈ ਪ੍ਰਵਾਨਿਤ ਇਰੱਟਾ ਹੈ (ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਰੱਟਾ ਸੁਧਾਰ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ) ਜੋ ਕਿ ਤਕਨੀਕੀ/ਉੱਚ ਜਾਂ ਤਕਨੀਕੀ/ਨਾਜ਼ੁਕ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜੋ ਅਜੇ ਤੱਕ ਕਿਸੇ ਵੀ ਕਿਰਿਆਸ਼ੀਲ ਨਿਰਧਾਰਨ ਦੇ ਪਾਠ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣੇ ਹਨ (ਜਿਵੇਂ ਕਿ, ਇੱਕ ਅਪਣਾਇਆ ਗਿਆ ਨਿਰਧਾਰਨ ਜੋ ਬਰਤਰਫ਼ ਜਾਂ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਗਿਆ ਹੈ)। ਇਰੱਟਾ ਵਰਗੀਕਰਣ ਪਰਿਭਾਸ਼ਾਵਾਂ ਲਈ ਅੰਤਿਕਾ A ਵੇਖੋ। ਇੱਕ ਨਿਰਧਾਰਨ ਮਾਲਕ (ਜਾਂ ਤਾਂ ਨਿਰਧਾਰਨ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ WG ਚਾਰਟਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਾਂ BARB ਜੇਕਰ ਨਿਰਧਾਰਨ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਕੋਈ WG ਚਾਰਟਰਡ ਨਹੀਂ ਹੈ) ਵੀ ਇੱਕ ਸਰਗਰਮ ਨਿਰਧਾਰਨ ਦੇ ਪੁਰਾਣੇ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕਿਸੇ ਵੀ ਪ੍ਰਵਾਨਿਤ ਇਰੱਟਾ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਹੈ। ਜਾਂ ਤਾਂ BSTS ਨਿਰਧਾਰਨ, ਜਾਂ ਨਿਰਧਾਰਨ ਮਾਲਕ ਦੀ ਬੇਨਤੀ 'ਤੇ, ਰੱਖ-ਰਖਾਅ ਜਾਰੀ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗੀ।

ਇੱਕ ਓਵਰview ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਗਲਤੀ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ! ਹਵਾਲਾ ਸਰੋਤ ਨਹੀਂ ਮਿਲਿਆ।

ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ 'ਤੇ, BSTS ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਓਨਰ, BARB, ਅਤੇ BTI ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਪ੍ਰਕਾਸ਼ਿਤ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਸੰਸਕਰਣ ਵਿੱਚ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ BoD ਨੂੰ ਇੱਕ ਯੋਜਨਾ ਤਿਆਰ ਕਰਨਗੇ ਅਤੇ ਪੇਸ਼ ਕਰਨਗੇ। ਪ੍ਰਸਤਾਵਿਤ ਪਲਾਨ ਵਿੱਚ ਇਹ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਨੂੰ ਨਿਰਧਾਰਨ ਦੇ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਵੇਗਾ (ਜਿਵੇਂ, ਇੱਕ .Z ਸੰਸਕਰਣ) ਜਾਂ ਇੱਕ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਜੋ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਗਤੀ ਵਿੱਚ ਹੈ (ਭਾਵ, ਇੱਕ XY ਸੰਸਕਰਣ)। ਪ੍ਰਸਤਾਵਿਤ ਯੋਜਨਾ ਨੂੰ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਅਪਣਾਏ ਗਏ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਕੋਈ ਨਵੀਂ ਲਾਜ਼ਮੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਅਨੁਮਾਨਿਤ ਸਮਾਂ ਜਦੋਂ ਅਗਲਾ ਨਿਰਧਾਰਨ ਸੁਧਾਰ ਗੋਦ ਲੈਣ ਲਈ ਯੋਜਨਾਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਹੋਰ ਕਾਰਕਾਂ।

BoD ਦੁਆਰਾ ਇੱਕ ਯੋਜਨਾ ਦੀ ਮਨਜ਼ੂਰੀ 'ਤੇ, BSTS ਨਿਰਧਾਰਨ ਮਾਲਕ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਸਾਰੇ ਤਕਨੀਕੀ/ਮਾਧਿਅਮ, ਤਕਨੀਕੀ/ਉੱਚ, ਅਤੇ ਤਕਨੀਕੀ/ਨਾਜ਼ੁਕ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਨੂੰ ਇੱਕ ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧੇਗਾ ਜਿਸਨੂੰ "ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਸੰਪਾਦਕੀ ਜਾਂ ਤਕਨੀਕੀ/ਘੱਟ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਲਈ, ਜੇਕਰ ਇਰੱਟਾ ਸੁਧਾਰ ਨਿਰਧਾਰਨ ਦੇ ਇੱਕ ਤੋਂ ਵੱਧ ਸੰਸਕਰਣਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ BSTS, ਜਦੋਂ ਤੱਕ ਕਿ BoD ਹੋਰ ਸੰਕੇਤ ਨਹੀਂ ਦਿੰਦਾ, ਉਸ ਸੰਸਕਰਣ ਦੇ ਅਗਲੇ ਅੱਪਡੇਟ 'ਤੇ ਉਹਨਾਂ ਇਰੱਟਾ ਨੂੰ ਸਿਰਫ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਉੱਚ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਸੰਸਕਰਣ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰੇਗਾ। . ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਵਿੱਚ ਇੱਰਟਾ ਸੁਧਾਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਤਬਦੀਲੀਆਂ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਹਰ ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਨਿਰਧਾਰਨ ਦੇ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਸੰਸਕਰਣ ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਤਬਦੀਲੀ-ਟਰੈਕਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਾਰੇ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਦੀ ਪਛਾਣ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਵਿੱਚ ਹਰੇਕ ਇਰੱਟਾ ਸੁਧਾਰ ਲਈ ਪ੍ਰਸਤਾਵਿਤ ਸਮਾਯੋਜਨ ਦਾ ਸਮਾਂ ਟੈਸਟ ਸੂਟ ਪ੍ਰਭਾਵ 'ਤੇ ਨਿਰਭਰ ਕਰੇਗਾ: ਸਾਰੇ ਇਰੱਟਾ ਸੁਧਾਰ ਜਿਨ੍ਹਾਂ ਦਾ ਟੈਸਟ ਸੂਟ ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੈ, ਨੂੰ ਤੁਰੰਤ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਰੱਟਾ ਸੁਧਾਰ ਜੋ ਟੈਸਟ ਸੂਟ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਣਗੇ। ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਕਿ ਸਮਾਂ TCRL ਦੇ ਅਪਡੇਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ।

BTI ਅਤੇ BSTS ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਵਿੱਚ ਟੈਸਟ ਸੂਟ ਪ੍ਰਭਾਵ ਦੇ ਨਾਲ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਇੱਕ ਅੰਤਮ ਤਾਰੀਖ ਸਥਾਪਤ ਕਰਨਗੇ। ਇਹ ਸਮਾਂ-ਸੀਮਾ ਆਮ ਤੌਰ 'ਤੇ ਅਗਲੀ ਵੱਡੀ TCRL ਰੀਲੀਜ਼ ਦੀ ਯੋਜਨਾਬੱਧ ਪ੍ਰਵਾਨਗੀ ਮਿਤੀ ਤੋਂ 3 ਤੋਂ 6 ਮਹੀਨੇ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ। ਟੈਸਟ ਸੂਟ ਪ੍ਰਭਾਵ ਦੇ ਨਾਲ ਇਰੱਟਾ ਸੁਧਾਰ ਜੋ ਕਿ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਸਮਾਂ ਸੀਮਾ ਤੋਂ ਖੁੰਝ ਜਾਂਦੇ ਹਨ, ਅਗਲੀ ਸਾਲਾਨਾ TCRL ਰੀਲੀਜ਼ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਵੇਗੀ। ਇਸਲਈ, ਜਦੋਂ ਤੱਕ ਪਹਿਲਾਂ ਰੀਲੀਜ਼ ਦੀ ਬੇਨਤੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਤਕਨੀਕੀ/ਉੱਚ ਜਾਂ ਤਕਨੀਕੀ/ਨਾਜ਼ੁਕ ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਲਈ ਇੱਕ ਨਿਰਧਾਰਨ ਅੱਪਡੇਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲਗਭਗ 15 ਤੋਂ 18 ਮਹੀਨੇ ਹੈ।

ਨਿਰਧਾਰਨ ਦੇ ਮਾਲਕ ਨੂੰ ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨੂੰ ਇਸ ਨੇ ਕਾਨੂੰਨੀ ਮੁੜ ਲਈ ਅੰਤਿਮ ਰੂਪ ਵਿੱਚ ਮਨਜ਼ੂਰ ਕੀਤਾ ਹੈview. ਕਾਨੂੰਨੀ ਰੀview ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਬਦਲੇ ਹੋਏ ਹਿੱਸਿਆਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੇਗਾ। ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview, ਨਿਰਧਾਰਨ ਮਾਲਕ ਅਤੇ BSTS ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ। ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀ ਤੋਂ ਕੋਈ ਅਣਸੁਲਝੀਆਂ ਕਾਨੂੰਨੀ ਟਿੱਪਣੀਆਂ ਹਨview ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ 'ਤੇ, ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਮਾਲਕ ਰੈਜ਼ੋਲਿਊਸ਼ਨ 'ਤੇ BoD ਇਨਪੁਟ ਲੈਣ ਲਈ BoD ਏਜੰਡੇ 'ਤੇ ਸਮੇਂ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ।

ਕਾਨੂੰਨੀ ਰੀ ਦੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚview, ਨਿਰਧਾਰਨ ਮਾਲਕ ਨੂੰ ਮੁੜ ਲਈ BARB ਨੂੰ ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview. ਇੱਕ ਵਾਰ ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ BARB ਨੂੰ ਜਮ੍ਹਾ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, BSTS ਇਸਨੂੰ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਦੁਬਾਰਾ ਪਹੁੰਚਯੋਗ ਬਣਾ ਦੇਵੇਗਾview ਅਤੇ ਇਸਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੋ। BARB ਦੇ ਪੂਰਾ ਹੋਣ 'ਤੇ ਮੁੜview, ਨਿਰਧਾਰਨ ਮਾਲਕ ਅਤੇ BARB ਡਰਾਫਟ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ।

ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀview ਕਿਸੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਵਾਧੂ ਮੁੜview BARB ਦੁਆਰਾ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇਕਰ BARB ਮੁੜview ਕਿਸੇ ਵੀ ਠੋਸ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, BSTS ਇਹ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਕੀ ਕੋਈ ਵਾਧੂ ਕਾਨੂੰਨੀ ਰੀview ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੈ। ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview ਅਤੇ ਬਾਰਬ ਰੀview, BARB ਨੂੰ ਜਾਂ ਤਾਂ ਮੇਨਟੇਨੈਂਸ ਰੀਲੀਜ਼ ਡਰਾਫਟ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ BARB ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਵੋਟਿੰਗ ਡਰਾਫਟ ਬਣ ਜਾਂਦਾ ਹੈ।

ਇਰੱਟਾ ਸੁਧਾਰਾਂ ਲਈ ਜੋ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਜਿੱਥੇ ਆਗਾਮੀ TCRL ਰੀਲੀਜ਼ ਲਈ ਸੰਬੰਧਿਤ ਟੈਸਟ ਇਰੱਟਾ ਸਮੇਂ ਸਿਰ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਵੇਗੀ, BSTS ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ ਨਿਰਧਾਰਨ ਮਾਲਕ ਅਤੇ BTI ਨਾਲ ਕੰਮ ਕਰੇਗਾ। ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ BTI ਦੀ ਮਨਜ਼ੂਰੀ 'ਤੇ, BSTS ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਏਗਾ ਅਤੇ TCRL ਵਿੱਚ ਵਰਤਣ ਲਈ BTI ਨੂੰ ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਪ੍ਰਦਾਨ ਕਰੇਗਾ। BTI ਲਾਗੂ ਹੋਣ ਅਨੁਸਾਰ ਸੰਬੰਧਿਤ ICS, IXIT, ਅਤੇ ਟੈਸਟ ਸੂਟ ਦੇ ਨਾਲ BQRB ਨੂੰ TCRL ਪ੍ਰਦਾਨ ਕਰੇਗਾ। ਨਿਰਧਾਰਨ ਦੀ BARB ਪ੍ਰਵਾਨਗੀ, ਸਾਰੇ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ BTI ਪ੍ਰਵਾਨਗੀ (ਟੈਸਟ ਸੂਟ, TCRL, ICS, ਅਤੇ IXIT ਜਿਵੇਂ ਕਿ ਲਾਗੂ ਹੋਵੇ), ਅਤੇ TCRL ਦੀ BQRB ਪ੍ਰਵਾਨਗੀ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ 'ਤੇ ਜਾਂ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

BSTS ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਵੋਟਿੰਗ ਡਰਾਫਟ ਦੇ ਅੰਤਿਮ ਰੂਪ ਅਤੇ ਉਪਲਬਧਤਾ ਅਤੇ ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਬਾਰੇ ਸੂਚਿਤ ਕਰੇਗਾ। ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਉਪ-ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਅਤੇ ਸੂਚਿਤ ਕੀਤੀ ਜਾਵੇਗੀ ਅਤੇ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਮੈਂਬਰਾਂ ਨੂੰ ਨੋਟਿਸ ਦਿੱਤੇ ਜਾਣ ਤੋਂ ਘੱਟੋ-ਘੱਟ 14 ਦਿਨ ਬਾਅਦ ਹੋਵੇਗੀ। ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਨੋਟਿਸ ਮੈਂਬਰਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, BoD ਪ੍ਰਸਤਾਵਿਤ ਗੋਦ ਲੈਣ ਦੀ ਮਿਤੀ ਦਾ ਵਾਧੂ ਨੋਟਿਸ ਪ੍ਰਦਾਨ ਕੀਤੇ ਬਿਨਾਂ ਅਤੇ ਲੋੜੀਂਦੇ 14 ਦਿਨਾਂ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਵੋਟਿੰਗ ਡਰਾਫਟ ਵਿੱਚ ਟਾਈਪੋਗ੍ਰਾਫਿਕਲ ਗਲਤੀਆਂ ਦੇ ਸੁਧਾਰ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦਾ ਹੈ।

ਵੋਟਿੰਗ ਡਰਾਫਟ
ਵੋਟਿੰਗ ਡਰਾਫਟ ਦਾ ਇੱਕ ਬਦਲਾਵ-ਟਰੈਕ ਕੀਤਾ ਸੰਸਕਰਣ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਅਪਣਾਏ ਗਏ ਸੰਸਕਰਣ ਵਿੱਚ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸਦਾ XY ਮੁੱਲ ਸਮਾਨ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਵੋਟਿੰਗ ਡਰਾਫਟ ਨੂੰ ਸੰਸਕਰਣ 1.4.2 ਵਜੋਂ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ 1.4.1 ਦੇ ਵਿਰੁੱਧ ਟਰੈਕ ਕੀਤਾ ਜਾਵੇਗਾ। ਨਿਰਧਾਰਨ ਦਾ ਸੰਸਕਰਣ)
ਇੱਕ ਜਾਇਜ਼ਤਾ ਦੇ ਨਾਲ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਦੇ ਕਿਸੇ ਵੀ ਪਿਛਲੇ ਸੰਸਕਰਣ (ਵਾਂ) ਨੂੰ ਬਰਤਰਫ਼ ਕਰਨ ਜਾਂ ਵਾਪਸ ਲੈਣ ਲਈ ਨਿਰਧਾਰਨ ਮਾਲਕ ਤੋਂ ਇੱਕ ਸਿਫਾਰਸ਼
ਕਾਨੂੰਨੀ ਮੁੜ ਤੋਂ ਬਾਕੀ ਅਣਸੁਲਝੇ ਕਾਨੂੰਨੀ ਮੁੱਦਿਆਂ ਦੀ ਸੂਚੀview (ਜੇ ਕੋਈ ਹੈ)
BTI-ਪ੍ਰਵਾਨਿਤ ਟੈਸਟ ਸੂਟ, ICS, ਅਤੇ IXIT (ਜੇਕਰ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ)
BTI- ਅਤੇ BQRB-ਪ੍ਰਵਾਨਿਤ TCRL (ਜੇਕਰ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ)
BSTS ਦੁਆਰਾ ਟੂਲ ਦੀ ਤਿਆਰੀ (ਜਿਵੇਂ ਕਿ, PTS ਅਤੇ ਹੋਰ ਟੈਸਟ ਟੂਲ, ਬਲੂਟੁੱਥ ਲਾਂਚ ਸਟੂਡੀਓ) ਦੀ ਸਥਿਤੀ ਬਾਰੇ BSTS ਦੁਆਰਾ ਪੂਰੀ ਕੀਤੀ ਗਈ ਰਿਪੋਰਟ ਜਿਸ ਵਿੱਚ TCRL ਵਿੱਚ ਕੋਈ ਵੀ ਟੈਸਟ ਕੇਸ ਸ਼ਾਮਲ ਹਨ ਜੋ ਟੈਸਟ ਟੂਲਸ ਦੁਆਰਾ ਸਮਰਥਿਤ ਨਹੀਂ ਹਨ, ਅਤੇ ਸਪੱਸ਼ਟੀਕਰਨ (ਜੇਕਰ ਰੱਖ-ਰਖਾਅ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ) ਜਾਰੀ)
BSTS ਅਤੇ ਨਿਰਧਾਰਨ ਮਾਲਕ ਦੁਆਰਾ ਪੂਰੀ ਕੀਤੀ ਗਈ ਗੋਦ ਲੈਣ ਦੀ ਚੈਕਲਿਸਟ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਸ ਭਾਗ ਵਿੱਚ ਡਿਲੀਵਰੇਬਲ ਸਾਰੇ ਪੂਰੇ ਹੋ ਗਏ ਹਨ
BoD ਦੁਆਰਾ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਹੋਰ ਸਾਰੀ ਜਾਣਕਾਰੀ

ਰੱਖ-ਰਖਾਅ ਜਾਰੀ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ BoD ਨੇ ਵੋਟਿੰਗ ਡਰਾਫਟ ਨੂੰ ਅਪਣਾ ਲਿਆ ਹੈ ਅਤੇ ਗੋਦ ਲੈਣ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਹੇਠ ਲਿਖੀਆਂ ਗਤੀਵਿਧੀਆਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਹਨ:

BSTS ਨੇ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਅਤੇ ਸੰਬੰਧਿਤ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ (ਜੇਕਰ ਰੱਖ-ਰਖਾਅ ਰੀਲੀਜ਼ ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ) ਨੂੰ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਵਾਇਆ ਹੈ। webਸਾਈਟ.
BSTS ਨੇ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਲਈ ਉਪਲਬਧ ਨਵੇਂ ਅਪਣਾਏ ਗਏ ਸੰਸਕਰਣ ਵਿੱਚ ਸ਼ਾਮਲ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦੇ ਨਾਲ ਪਹਿਲਾਂ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਸੰਸਕਰਣ ਦਾ ਇੱਕ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਤਬਦੀਲੀ-ਟਰੈਕ ਕੀਤਾ ਸੰਸਕਰਣ ਬਣਾਇਆ ਹੈ। webਸਾਈਟ.
BSTS ਨੇ ਯੋਗਤਾ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ ਹੈ।
BSTS ਨੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਅਪਣਾਏ ਗਏ ਨਿਰਧਾਰਨ ਅਤੇ ਸਹਾਇਕ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਸੂਚਿਤ ਕੀਤਾ ਹੈ।

ਇਹਨਾਂ ਗਤੀਵਿਧੀਆਂ ਦੇ ਪੂਰਾ ਹੋਣ 'ਤੇ, ਸੈਕਸ਼ਨ 8 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਅਨੁਸਾਰ, ਨਿਰਧਾਰਨ ਨੂੰ ਬਰਤਰਫ਼ ਜਾਂ ਵਾਪਿਸ ਲੈਣ ਤੱਕ ਨਿਰਧਾਰਨ ਦੇ ਰੱਖ-ਰਖਾਅ ਦੇ ਪੜਾਅ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।

8. ਨਿਰਧਾਰਨ ਜੀਵਨ ਦਾ ਅੰਤ ਪੜਾਅ

ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਦੁਆਰਾ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਨਾਕਾਫ਼ੀ ਹੋਣ ਦਾ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਹੋਰ ਕਾਰਨਾਂ ਕਰਕੇ। ਨਾਪਸੰਦ ਅਤੇ ਵਾਪਸ ਲਏ ਗਏ ਵਿਵਰਣ ਨੂੰ ਪੁਰਾਲੇਖਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਹੁਣ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ। ਬਲੂਟੁੱਥ ਯੋਗਤਾ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਬਰਤਰਫ਼ ਕੀਤੇ ਗਏ ਅਤੇ ਵਾਪਸ ਲਏ ਗਏ ਵਿਵਰਣਾਂ ਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਕੋਈ ਵੀ ਮੈਂਬਰ, ਸਮੂਹ, ਜਾਂ ਕਮੇਟੀ BSTS (ਈਮੇਲ ਰਾਹੀਂ

specification.manager@bluetooth.com) ਕਿਸੇ ਵੀ ਸਮੇਂ। BSTS ਕਿਸੇ ਨਿਰਧਾਰਨ ਅਤੇ ਸੰਬੰਧਿਤ ਟਾਈਮਲਾਈਨ ਨੂੰ ਬਰਤਰਫ਼ ਕਰਨ ਜਾਂ ਵਾਪਸ ਲੈਣ ਦੀ ਵੀ ਸਿਫ਼ਾਰਸ਼ ਕਰ ਸਕਦਾ ਹੈ। BSTS ਸਿਫ਼ਾਰਸ਼ਾਂ ਨੂੰ BARB ਅਤੇ ਸਮੂਹ ਜਾਂ ਕਮੇਟੀ ਨੂੰ ਦੁਬਾਰਾ ਲਈ ਨਿਰਧਾਰਨ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਭੇਜੇਗਾview ਅਤੇ ਫੀਡਬੈਕ।

BARB ਅਤੇ ਸਮੂਹ ਜਾਂ ਕਮੇਟੀ ਜ਼ਿੰਮੇਵਾਰ ਕਿਸੇ ਨਿਰਧਾਰਨ ਨੂੰ ਨਾਪਸੰਦ ਕਰਨ ਜਾਂ ਵਾਪਸ ਲੈਣ ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਗੇ ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੇ (ਗੈਰ-ਸੰਪੂਰਨ) ਮਾਪਦੰਡਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨਗੇ:

ਕੀ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣ ਵਿੱਚ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹੈ ਜੋ ਪੁਰਾਣੀ ਹੈ ਜਾਂ ਨਹੀਂ ਵਰਤੀ ਜਾਣੀ ਚਾਹੀਦੀ?
ਕੀ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਨਵੀਂ ਲਾਜ਼ਮੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਹੈ?
ਕੀ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਕੋਈ ਕਮੀਆਂ ਹਨ ਜੋ ਸੰਚਾਲਨ ਜਾਂ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਵਿਗਾੜਦੀਆਂ ਹਨ ਜੋ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਠੀਕ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਅਤੇ ਮੌਜੂਦਾ ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ ਲਈ ਲੋੜੀਂਦੀਆਂ ਹਨ?
ਕੀ ਨਵੇਂ ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ ਲਈ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਵਾਧੂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਲੋੜ ਹੈ?
ਕੀ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਉਪਯੋਗਤਾ ਅਤੇ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਹੈ?
ਕੀ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ ਸੁਧਾਰ ਹਨ?

BARB ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਸਮੂਹ ਜਾਂ ਕਮੇਟੀ ਇੱਕ ਵਿਕਲਪਿਕ ਸਿਫ਼ਾਰਸ਼ ਦਾ ਪ੍ਰਸਤਾਵ ਦੇ ਸਕਦੇ ਹਨ।

BARB ਜਾਂ ਨਿਰਧਾਰਨ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਸਮੂਹ ਜਾਂ ਕਮੇਟੀ ਤੋਂ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, BSTS ਸਿਫ਼ਾਰਸ਼ਾਂ ਅਤੇ ਫੀਡਬੈਕ ਨੂੰ ਵਿਚਾਰ ਲਈ BoD ਨੂੰ ਸੌਂਪੇਗਾ। BoD ਉਸ ਸਮੂਹ ਜਾਂ ਕਮੇਟੀ ਨੂੰ ਸੱਦਾ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਪ੍ਰਭਾਵਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਅਤੇ ਸਿਫ਼ਾਰਸ਼ਾਂ 'ਤੇ ਚਰਚਾ ਕਰਨ ਲਈ। BoD ਸਿਫ਼ਾਰਸ਼ਾਂ ਅਤੇ ਫੀਡਬੈਕ 'ਤੇ ਵਿਚਾਰ ਕਰੇਗਾ ਅਤੇ ਪ੍ਰਸਤਾਵ ਨਾਲ ਸਹਿਮਤ ਜਾਂ ਸੋਧ ਸਕਦਾ ਹੈ। BoD ਬੇਨਤੀ ਕਰੇਗਾ ਕਿ BSTS ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ 30-ਦਿਨਾਂ ਦੀ ਮਿਆਦ ਲਈ ਸਪੈਸੀਫਿਕੇਸ਼ਨ (ਵਾਂ) ਅਤੇ ਸੰਬੰਧਿਤ ਸਮਾਂ-ਸੀਮਾ (ਵਾਂ) ਨੂੰ ਬਰਤਰਫ਼ ਕਰਨ ਜਾਂ ਵਾਪਸ ਲੈਣ ਲਈ ਪ੍ਰਸਤਾਵਾਂ ਦੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੇ।view ਅੰਤਮ ਫੈਸਲਾ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਵਾਧੂ ਫੀਡਬੈਕ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣ ਦੀ ਮਿਆਦ।

ਬੋਰਡ ਮੈਂਬਰਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਫੀਡਬੈਕ 'ਤੇ ਵਿਚਾਰ ਕਰੇਗਾ। ਇੱਕ ਵਾਰ ਜਦੋਂ BoD ਇੱਕ ਨਿਰਧਾਰਨ ਨੂੰ ਬਰਤਰਫ਼ ਕਰਨ ਜਾਂ ਵਾਪਸ ਲੈਣ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, BSTS ਫੈਸਲੇ ਅਤੇ ਸੰਬੰਧਿਤ ਸਮਾਂ-ਸੀਮਾ ਦੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰੇਗਾ।

8.1 ਬਰਬਾਦੀ

ਇੱਕ ਵਾਰ ਇੱਕ ਨਿਰਧਾਰਨ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤਾ ਗਿਆ ਹੈ, ਹੇਠ ਲਿਖੇ ਹੋਣਗੇ:

ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਨੂੰ ਹੁਣ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।
ਜ਼ਿੰਮੇਵਾਰ WG ਮੁੜ ਕਰੇਗਾview ਸਾਰੇ ਬਕਾਇਆ ਇਰੱਟਾ ਬਰਤਰਫ਼ ਕੀਤੇ ਨਿਰਧਾਰਨ ਦੇ ਵਿਰੁੱਧ ਲਿਖਿਆ ਗਿਆ ਹੈ ਤਾਂ ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕੇ ਕਿ ਕੀ ਉਹ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਇੱਰਟਾ ਸਿਸਟਮ ਵਿੱਚ ਇਰੱਟਾ ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਲਾਗੂ ਨਿਰਧਾਰਨ(ਆਂ) ਦੇ ਵਿਰੁੱਧ ਮੁੜ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।
WG ਜਾਂ BSTS ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਨਾਪਸੰਦ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਲੋੜੀਂਦੇ ਹਵਾਲਿਆਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਇਰੱਟਾ ਬਣਾਏਗਾ।
BTI ਨਿਰਧਾਰਨ ਦੇ ਬਰਤਰਫ਼ ਹੋਣ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਲਾਗੂ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੇਗਾ।
BSTS ਬਲੂਟੁੱਥ SIG ਨੂੰ ਅਪਡੇਟ ਕਰੇਗਾ webਵਰਤਣ ਲਈ ਵਿਕਲਪਕ ਨਿਰਧਾਰਨ(ਆਂ) ਦੇ ਸਬੰਧ ਵਿੱਚ ਮਾਰਗਦਰਸ਼ਨ ਵਾਲੀ ਸਾਈਟ।
ਨਵੀਂ ਇਰੱਟਾ ਨੂੰ ਹੁਣ ਬਰਤਰਫ਼ ਕੀਤੇ ਨਿਰਧਾਰਨ ਦੇ ਵਿਰੁੱਧ ਜਮ੍ਹਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਨਿਰਧਾਰਨ ਨੂੰ ਭਵਿੱਖ ਦੇ ਕਿਸੇ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਹਵਾਲਾ ਨਹੀਂ ਦਿੱਤਾ ਜਾਵੇਗਾ।
BSTS ਇਤਿਹਾਸਕ ਉਦੇਸ਼ਾਂ ਲਈ ਮੈਂਬਰਾਂ ਦੀ ਪਹੁੰਚ ਲਈ ਨਾਪਸੰਦ ਵਜੋਂ ਮਾਰਕ ਕੀਤੇ ਨਿਰਧਾਰਨ ਦੇ ਇੱਕ ਸੰਸਕਰਣ ਨੂੰ ਆਰਕਾਈਵ ਕਰੇਗਾ।

8.2 ਕਢਵਾਉਣਾ

ਇੱਕ ਵਾਰ ਨਿਰਧਾਰਨ ਵਾਪਸ ਲੈ ਲਏ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਬਰਤਰਫ਼ ਕਰਨ ਲਈ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਕਦਮਾਂ ਤੋਂ ਇਲਾਵਾ, ਹੇਠਾਂ ਦਿੱਤੇ ਹੋਣਗੇ:

BTI ਨਿਰਧਾਰਨ ਵਾਪਸ ਲੈਣ ਦਾ ਸੰਕੇਤ ਦੇਣ ਲਈ ਲਾਗੂ ਟੈਸਟ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੇਗਾ।
BSTS ਬਲੂਟੁੱਥ SIG ਨੂੰ ਅਪਡੇਟ ਕਰੇਗਾ webਵਰਤਣ ਲਈ ਵਿਕਲਪਕ ਨਿਰਧਾਰਨ(ਆਂ) ਦੇ ਸਬੰਧ ਵਿੱਚ ਮਾਰਗਦਰਸ਼ਨ ਵਾਲੀ ਸਾਈਟ।
BSTS ਇਤਿਹਾਸਕ ਉਦੇਸ਼ਾਂ ਲਈ ਮੈਂਬਰਾਂ ਦੀ ਪਹੁੰਚ ਲਈ ਵਾਪਿਸ ਲਏ ਗਏ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤੇ ਨਿਰਧਾਰਨ ਦੇ ਇੱਕ ਸੰਸਕਰਣ ਨੂੰ ਪੁਰਾਲੇਖ ਕਰੇਗਾ।

BoD ਪਹਿਲਾਂ ਨਿਰਧਾਰਨ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਨਿਰਧਾਰਨ ਨੂੰ ਤੁਰੰਤ ਵਾਪਸ ਲੈਣ ਦੀ ਚੋਣ ਕਰ ਸਕਦਾ ਹੈ।

9. ਵਾਈਟ ਪੇਪਰ ਪ੍ਰਕਿਰਿਆ

ਵ੍ਹਾਈਟ ਪੇਪਰ ਸਿਰਫ ਜਾਣਕਾਰੀ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ ਬਣਾਏ ਗਏ ਹਨ। ਨਿਮਨਲਿਖਤ ਵ੍ਹਾਈਟ ਪੇਪਰ ਪ੍ਰਕਿਰਿਆ ਸਾਰੀਆਂ ਬਲੂਟੁੱਥ ਡਬਲਯੂ.ਜੀ., ਈ.ਜੀ., ਐੱਸ.ਜੀ., ਅਤੇ ਕਮੇਟੀਆਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਇਹ ਸੈਕਸ਼ਨ ਸਿਰਫ਼ ਬਲੂਟੁੱਥ SIG ਦੇ ਅੰਦਰ ਵਰਤੋਂ ਲਈ ਜਾਣਕਾਰੀ ਵਾਲੇ ਦਸਤਾਵੇਜ਼ਾਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਹੇਠਾਂ ਚਿੱਤਰ 9.1 ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਕਿਸੇ ਵੀ ਗਰੁੱਪ ਜਾਂ ਕਮੇਟੀ ਵੱਲੋਂ ਬਲੂਟੁੱਥ SIG ਦੁਆਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਵਾਈਟ ਪੇਪਰ 'ਤੇ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਗਰੁੱਪ ਜਾਂ ਕਮੇਟੀ ਵਾਈਟ ਪੇਪਰ ਦੀ ਪ੍ਰਸਤਾਵਿਤ ਸਮੱਗਰੀ ਅਤੇ ਵਾਈਟ ਪੇਪਰ ਪ੍ਰਸਤਾਵ ਪੇਸ਼ਕਾਰੀ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋਏ ਪ੍ਰਸਤਾਵਿਤ ਚਾਰਟਰ ਅੱਪਡੇਟ ਤਿਆਰ ਕਰੇਗੀ।

ਵ੍ਹਾਈਟ ਪੇਪਰ ਪ੍ਰਸਤਾਵ ਪੇਸ਼ਕਾਰੀ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

ਵਾਈਟ ਪੇਪਰ ਦੀ ਲੋੜ ਹੈ
ਵ੍ਹਾਈਟ ਪੇਪਰ ਦੀ ਪ੍ਰਸਤਾਵਿਤ ਸਮੱਗਰੀ ਦਾ ਸਾਰ
ਇਸ ਗੱਲ ਦੀ ਵਿਆਖਿਆ ਕਿ ਸਮੱਗਰੀ ਨੂੰ ਇੱਕ ਵਿਵਰਣ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਿਉਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ
ਇਛੁੱਕ ਦਰਸ਼ਕ
ਕੋਈ ਵੀ ਰੱਖ-ਰਖਾਅ ਯੋਜਨਾਵਾਂ (ਭਾਵ, ਇਸ ਵ੍ਹਾਈਟ ਪੇਪਰ ਦੇ ਅਗਲੇ ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਮਾਨਿਤ ਸਮਾਂ ਜ਼ਰੂਰੀ ਹੋ ਸਕਦਾ ਹੈ)
ਵਾਈਟ ਪੇਪਰ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਣਾ ਹੈ, ਜੇਕਰ ਕੋਈ ਹੋਵੇ (ਉਦਾਹਰਨ ਲਈ, ਆਰਕਾਈਵਿੰਗ) ਲਈ ਸਿਫ਼ਾਰਿਸ਼ਾਂ

ਚਾਰਟਰ ਅੱਪਡੇਟ ਅਤੇ ਵ੍ਹਾਈਟ ਪੇਪਰ ਪ੍ਰਸਤਾਵ ਪੇਸ਼ਕਾਰੀ BARB ਰੀ ਲਈ ਜਮ੍ਹਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈview. ਮੁੜview ਅਤੇ BARB ਦੁਆਰਾ ਚਾਰਟਰ ਅੱਪਡੇਟ ਦੀ ਮਨਜ਼ੂਰੀ, BSTS ਚਾਰਟਰ ਅੱਪਡੇਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਲਈ BoD ਨੂੰ ਸਹਾਇਕ ਵਾਈਟ ਪੇਪਰ ਪ੍ਰਸਤਾਵ ਪੇਸ਼ਕਾਰੀ ਦੇ ਨਾਲ ਜਮ੍ਹਾ ਕਰੇਗਾ।

ਜੇਕਰ BoD ਚਾਰਟਰ ਅੱਪਡੇਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਗਰੁੱਪ ਜਾਂ ਕਮੇਟੀ ਵਾਈਟ ਪੇਪਰ ਨੂੰ ਵਿਕਸਿਤ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧ ਸਕਦੀ ਹੈ।

ਜਦੋਂ ਸਮੂਹ ਜਾਂ ਕਮੇਟੀ ਨੇ ਵਾਈਟ ਪੇਪਰ ਦਾ ਵਿਕਾਸ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ, ਤਾਂ BSTS ਇੱਕ ਸੰਪਾਦਕੀ ਮੁੜ ਕਰੇਗਾview ਬਲੂਟੁੱਥ ਡਰਾਫਟ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ ਇਕਸਾਰਤਾ ਲਈ।

BSTS ਟਿੱਪਣੀਆਂ ਦੇ ਹੱਲ ਤੋਂ ਬਾਅਦ, ਸਮੂਹ ਨੂੰ ਕਾਨੂੰਨੀ ਮੁੜ-ਵਿਚਾਰ ਲਈ BSTS ਨੂੰ ਵ੍ਹਾਈਟ ਪੇਪਰ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview. ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview, ਸਮੂਹ ਅਤੇ BSTS ਵ੍ਹਾਈਟ ਪੇਪਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ। ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀ ਤੋਂ ਕੋਈ ਅਣਸੁਲਝੀਆਂ ਕਾਨੂੰਨੀ ਟਿੱਪਣੀਆਂ ਹਨview ਵਾਈਟ ਪੇਪਰ 'ਤੇ, ਗਰੁੱਪ ਚੇਅਰ ਰੈਜ਼ੋਲਿਊਸ਼ਨ 'ਤੇ BoD ਇਨਪੁਟ ਲੈਣ ਲਈ BoD ਏਜੰਡੇ 'ਤੇ ਸਮਾਂ ਮੰਗ ਸਕਦੀ ਹੈ।

ਕਾਨੂੰਨੀ ਰੀ ਦੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚview, ਸਮੂਹ ਨੂੰ ਦੁਬਾਰਾ ਲਈ BARB ਨੂੰ ਵਾਈਟ ਪੇਪਰ ਜਮ੍ਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈview. ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਉਨ੍ਹਾਂ ਦੇ ਰੀview, BARB ਇਹ ਸਿਫ਼ਾਰਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਵ੍ਹਾਈਟ ਪੇਪਰ ਦੇ ਕਿਸੇ ਹਿੱਸੇ ਨੂੰ ਸੈਕਸ਼ਨ 3 ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਦੇ ਬਾਅਦ ਵਾਈਟ ਪੇਪਰ ਵਿੱਚੋਂ ਹਟਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇੱਕ ਨਿਰਧਾਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।view. BARB ਦੇ ਪੂਰਾ ਹੋਣ 'ਤੇ ਮੁੜview, ਸਮੂਹ ਅਤੇ BARB ਵ੍ਹਾਈਟ ਪੇਪਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਫੀਡਬੈਕ 'ਤੇ ਸਹਿਮਤ ਹੋਣਗੇ।

ਜੇਕਰ ਕਾਨੂੰਨੀ ਰੀview ਕਿਸੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਵਾਧੂ ਮੁੜview BARB ਦੁਆਰਾ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇਕਰ BARB ਮੁੜview ਕਿਸੇ ਵੀ ਠੋਸ ਤਬਦੀਲੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, BSTS ਇਹ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਕੀ ਕੋਈ ਵਾਧੂ ਕਾਨੂੰਨੀ ਰੀview ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੈ। ਕਾਨੂੰਨੀ ਮੁੜ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇview ਅਤੇ ਬਾਰਬ ਰੀview, BARB ਨੂੰ ਵਾਈਟ ਪੇਪਰ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

BARB ਦੁਆਰਾ ਵਾਈਟ ਪੇਪਰ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਬਾਅਦ, BARB-ਪ੍ਰਵਾਨਿਤ ਵਾਈਟ ਪੇਪਰ ਨੂੰ ਲੇਖਕ ਸਮੂਹ ਜਾਂ ਕਮੇਟੀ ਦੁਆਰਾ ਪ੍ਰਵਾਨਗੀ ਲਈ BoD ਨੂੰ ਪੇਸ਼ ਕੀਤਾ ਜਾਵੇਗਾ।

ਵਾਈਟ ਪੇਪਰ ਪ੍ਰਕਿਰਿਆ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ BoD ਨੇ ਵਾਈਟ ਪੇਪਰ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੱਤੀ ਹੈ ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਪ੍ਰਵਾਨਗੀ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਹਨ:

BSTS ਨੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵਾਈਟ ਪੇਪਰ ਨੂੰ ਬਲੂਟੁੱਥ SIG 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਕਰਵਾਇਆ ਹੈ webਸਾਈਟ.
BSTS ਪ੍ਰਵਾਨਿਤ ਵ੍ਹਾਈਟ ਪੇਪਰ ਦੇ ਸਾਰੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ।
ਜੇਕਰ ਵ੍ਹਾਈਟ ਪੇਪਰ ਮੌਜੂਦਾ ਵਾਈਟ ਪੇਪਰ ਦਾ ਵਾਧਾ ਹੈ, ਤਾਂ BSTS ਇਤਿਹਾਸਕ ਉਦੇਸ਼ਾਂ ਲਈ ਮੈਂਬਰਾਂ ਦੀ ਪਹੁੰਚ ਲਈ ਵਾਈਟ ਪੇਪਰ ਦੇ ਇੱਕ ਸੰਸਕਰਣ ਨੂੰ ਆਰਕਾਈਵ ਕਰੇਗਾ।

ਬਲੂਟੁੱਥ SIG ਵ੍ਹਾਈਟ ਪੇਪਰ ਦੀ ਪ੍ਰਵਾਨਗੀ ਤੋਂ ਬਾਅਦ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ-ਅੰਦਰ ਪ੍ਰਵਾਨਗੀ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ।

10. ਹਵਾਲੇ

ਹਵਾਲੇ ਕੀਤੇ ਬਲੂਟੁੱਥ ਦਸਤਾਵੇਜ਼ ਬਲੂਟੁੱਥ ਤੋਂ ਉਪਲਬਧ ਹਨ webਸਾਈਟ http://www.bluetooth.com.

ਬਲੂਟੁੱਥ ਡਰਾਫਟਿੰਗ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ (ਵਰਕਿੰਗ ਗਰੁੱਪ ਟੈਂਪਲੇਟਸ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ ਹਨ, 'ਤੇ https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
ਬਲੂਟੁੱਥ SIG, Inc. ਦੇ ਨਿਯਮ (ਗਵਰਨਿੰਗ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ, https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
ਬਲੂਟੁੱਥ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਇਰੱਟਾ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ (ਵਰਕਿੰਗ ਗਰੁੱਪ ਟੈਂਪਲੇਟਸ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ ਹੈ,' https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
ਵਰਕਿੰਗ ਗਰੁੱਪ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ (ਵਰਕਿੰਗ ਗਰੁੱਪ ਟੈਂਪਲੇਟਸ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ ਹੈ, 'ਤੇ https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
ਟੈਸਟ ਰਣਨੀਤੀ ਅਤੇ ਸ਼ਬਦਾਵਲੀ ਓਵਰview ਦਸਤਾਵੇਜ਼ (ਯੋਗਤਾ ਟੈਸਟ ਦੀਆਂ ਲੋੜਾਂ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ ਹੈ, 'ਤੇ https://www.bluetooth.com/specifications/qualification-test-requirements)
BTI ਨਿਰਧਾਰਨ ਰੀview ਪ੍ਰਕਿਰਿਆ ਚੈੱਕਲਿਸਟ (ਵਰਕਿੰਗ ਗਰੁੱਪ ਟੈਂਪਲੇਟਸ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ ਹੈ, 'ਤੇ https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
ਬਲੂਟੁੱਥ SIG ਅਸਾਈਨ ਕੀਤੇ ਨੰਬਰ (https://www.bluetooth.com/specifications/assigned-numbers)
ਵਰਕਿੰਗ ਗਰੁੱਪ ਟੈਂਪਲੇਟਸ ਅਤੇ ਦਸਤਾਵੇਜ਼ (ਵਰਕਿੰਗ ਗਰੁੱਪ ਟੈਂਪਲੇਟਸ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
GATT ਨਿਰਧਾਰਨ ਪੂਰਕ (GSS) (GATT ਨਿਰਧਾਰਨ ਪੰਨੇ 'ਤੇ ਉਪਲਬਧ ਹੈ, ਇੱਥੇ https://www.bluetooth.com/specifications/gatt)
ਇੱਕ ਨਵੇਂ ਨਿਰਧਾਰਨ ਲਈ ਇੱਕ ਵਿਚਾਰ ਜਮ੍ਹਾਂ ਕਰੋ https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. ਸੰਖੇਪ ਅਤੇ ਸੰਖੇਪ ਰੂਪ

ਸਾਰਣੀ A: ਸੰਖੇਪ ਅਤੇ ਸੰਖੇਪ ਰੂਪ

ਅੰਤਿਕਾ ਏ - ਇਰੱਟਮ ਗੰਭੀਰਤਾ ਵਰਗੀਕਰਣ

ਇਹ ਅੰਤਿਕਾ ਇੱਕ ਨਿਰਧਾਰਨ ਇਰੱਟਮ ਲਈ ਗੰਭੀਰਤਾ ਵਰਗੀਕਰਨ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਸਾਰ ਦਿੰਦਾ ਹੈ। ਇਸ ਸਾਰਣੀ ਨੂੰ EPD ਦੇ ਭਵਿੱਖੀ ਸੰਸ਼ੋਧਨ ਵਿੱਚ ਜੋੜਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਫਿਰ ਇਸ ਭਾਗ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ।

ਇਸ ਮੈਨੂਅਲ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ ਅਤੇ PDF ਡਾਊਨਲੋਡ ਕਰੋ:

ਨਿਰਧਾਰਨ ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ (SMPD) - ਅਨੁਕੂਲਿਤ PDF
ਨਿਰਧਾਰਨ ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ (SMPD) - ਅਸਲ ਪੀਡੀਐਫ

ਤੁਹਾਡੇ ਮੈਨੂਅਲ ਬਾਰੇ ਸਵਾਲ? ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਪੋਸਟ ਕਰੋ!

ਹਵਾਲੇ

ਯੂਜ਼ਰ ਮੈਨੂਅਲ