a. Si sintonizzera' sul designato canale di traffico uscente
obbedendo alle seguenti temporizzazioni:
- Se IDENT2(cancelletto)IPFIXI, l'unita' dovra' essere in grado di
ricevere sul canale di traffico entro 35 ms dopo la fine del
messaggio GTC.
- Se IDENT2=IPFIXI l'unita' dovra' essere in grado di ricevere sul
canale di traffico entro 142 ms dopo la fine del messaggio GTC;
(Questo permette all'unita' chiamata in una chiamata interprefisso di
rimanere sul canale di controllo per un'altro "timeslot" dopo aver
ricevuto il messaggio GTC, per estrarre l'indirizzo del chiamante se
il messaggio seguente e' un GTC per l'unita' chiamante).
b. Controllera' PFIX, IDENT1 e IDENT2 del messaggio GTC e anche il
numero di canale del canale di controllo (da usare in osservanza alle
procedure dei paragrafi 9.2.3.1, 9.2.3.3., 9.2.3.5, 9.2.3.6 e
9.2.3.7)
c. Se il bit D nel messaggio GTC e' '0', allora l'unita' abilitera'
l'audio (per comunicazioni per conversazione). Se il bit D=1 l'unita'
disabilitera' l'audio (per comunicazioni dati); si noti che l'unita'
non deve mandare messaggi di manutenzione dentro gli *item* (a meno
che precedentemente accordato nel sistema).
d. Se IDENT1 nel messaggio GTC e' ALLI e PFIX/IDENT2 nel messaggio
GTC non e' il suo indirizzo individuale, allora l'unita' inibira' la
trasmissione dell'utente sul canale di traffico. Altrimenti
abilitera' la trasmissione dell'utente sul canale di traffico.
Essa puo' anche dare una indicazione all'utente.
Se l'unita' non obbedisce a un messaggio di GTC (o, per
IDENT2=IPFIXI, un messaggio GTC nello "slot" seguente), e il canale
di traffico designato e' il canale di controllo su cui il messaggio
e' stato ricevuto, allora l'unita' deve ritornare alle procedure di
acquisizione del canale di controllo. (Vedi 6.2.1.1).
9.2.2.6 Memorizzazione dei parametri di manutenzione della chiamata
Una *unita' radio* memorizzera' i parametri di manutenzione della
chiamata specificati dal piu' recente messaggio di BCAST,
SYSDEF='00010' che si riferiscono al sistema al momento in uso.
Questi parametri indicano:
a. se il sistema richiede che la *unita' radio* su un canale di
traffico allocato invii un messaggio di "Pressel ON" all'inizio di
ogni *item* di conversazione che trasmette;
b. se le *unita' radio* devono inviare messaggi periodici entro
*item* di conversazione, e in tal caso il massimo intervallo (in
secondi) fra l'inizio dell' *item* e il primo messaggio periodico, e
quindi fra successivi messaggi periodici;
c. se una unita' chiamata in un gruppo predisporra' PFIX/IDENT1 nel
messaggio di MAINT che essa invia uguale al suo indirizzo individuale
o all'indirizzo di gruppo relativo al messaggio GTC.
Vedi anche 5.5.4.2, 5.5.4.5C e 9.2.3.1. All'inizio della sessione,
fino a che riceve un messaggio BCAST, SYSDEF='00010', l'unita':
- inviera' messaggi "Pressel ON"
- inviera' messaggi periodici con un intervallo massimo TP
- fissera' PFIX/IDENT1 come indirizzo di gruppo (quando essa e'
l'unita' chiamata nel gruppo)
9.2.3 Procedure per tutte le *unita' radio* su un canale di traffico
allocato.
Queste procedure saranno osservate da tutte le *unita' radio* su un
canale di traffico allocato (eccetto quando esentate da procedure di
chiamate di emergenza d'accordo con il sistema - vedi 10.2.8). Per
altre procedure per tutte le *unita' radio* su un canale di traffico,
vedi paragrafi:
6.2.2 Disciplina del canale di traffico
11.3 Istruzione di inviare l'informazione di indirizzo esteso.
15.2 Procedure di interrogazione dati.
9.2.3.1 Messaggi di manutenzione della chiamata.
Durante una chiamata per conversazione (vedi 9.2.2.5e, 9.2.3.4), una
*unita' radio* inviera' i seguenti messaggi di manutenzione della
chiamata entro *item* di conversazione:
a. Se richiesto dal sistema (vedi 9.2.2.6), la *unita' radio*
inviera' un messaggio di "Pressel ON" (MAINT, OPER=000) all'inizio di
ciascun *item* essa trasmette.
b. Se richiesto dal sistema, la *unita' radio* inviera messaggi
periodici (MAINT, OPER=010) entro ciascun *item* di conversazione
essa trasmette. Vedi 9.2.2.6 per il massimo intervallo fra messaggi
periodici.
c. La *unita' radio* inviera' un messaggio di "Pressel OFF" (MAINT,
OPER='001') alla fine di ciascun *item* di conversazione essa
trasmette, come l'ultimo segnale prima di risintonizzarsi sul canale
di traffico uscente.
PFIX/IDENT1 nei messaggi MAINT inviati da una *unita' radio* e'
l'indirizzo individuale dell'unita' come se fosse indirizzata
individualmente dal messaggio di GTC; altrimenti (esempio per una
unita' chiamata nel gruppo), PFIX/IDENT2 sara' fissato o
all'indirizzo individuale dell'unita' oppure all'indirizzo di gruppo
(PFIX/IDENT1) del messaggio GTC, come richiesto dal sistema - vedi
9.2.2.5 e 9.2.2.6).
(Durante una chiamata dati, la *unita' radio* non necessita di
inviare i messaggi di cui sopra, a meno che richiesti dal sistema da
predisposizioni precedenti).
9.2.3.2 Verifica disponibilita' su un canale di traffico
Se una *unita' radio* su un canale di traffico riceve un messaggio di
AHY con:
PFIX/IDENT1 uguale al suo indirizzo individuale e POINT=0
o PFIX/IDENT2 uguale al suo indirizzo individuale e POINT=1
allora rispondera' con l'appropriato riscontro, (vedi di seguito),
con lo stesso prefisso e identificativi come nel messaggio AHY. Se il
bit AD=0 nel messaggio AHY, l'unita' temporizzera' la sua risposta
dalla fine della parola codice di indirizzo AHY; se il bit AD=1, una
parola di codice dati e' aggiunta e l'unita' temporizzera' la sua
risposta dalla fine della parola codice dati. Per la temporizzazione,
vedi 6.2.2.2.
a. Se POINT=0, l'unita' inviera' ACK (QUAL=0)
ACK(QUAL=0) - L'unita' e' in contatto radio.
b. Se POINT=1, l'unita' inviera' ACK (QUAL=0) o ACKX (QUAL=0):
ACK (QUAL=0) - L'unita' sta aspettando la segnalazione per una
inclusione di chiamata appropriata ad IDENT1 (esempio IDENT1 e'
l'identificativo chiamato o *gateway*) vedi anche paragrafo 11.2.5
ACKX (QUAL=0) - L'unita' non sta aspettando la segnalazione per una
inclusione di chiamata appropriata ad IDENT1.
9.2.3.3 Disabilitazione alla trasmissione dell'utente.
Se una *unita' radio* su un canale di traffico riceve un messaggio di
manutenzione di chiamata MAINT, OPER=111 con il numero di canale
(CHAN) uguale al numero del canale di traffico ed al relativo
indirizzo, allora inibira' la trasmissione dell'utente mentre essa e'
sintonizzata su questo canale di traffico (esempio disabilitera' il
pulsante di trasmissione per una chiamata di conversazione o inibira'
i dati dell'utente per una chiamata dati).
L'indirizzo (PFIX/IDENT1) del messaggio MAINT e' applicabile se:
a. PFIX/IDENT1 e' uguale all'indirizzo individuale dell'unita', o
b. PFIX/IDENT1 e' uguale a PFIX/IDENT1 del messaggio GTC e l'unita'
non e' l'utente chiamante, o
c. IDENT1 e' uguale a ALLI
9.2.3.4 Sostituzione del canale di traffico.
Se una *unita' radio* sul canale di traffico riceve un messaggio di
GTC con:
PFIX/IDENT1 del messaggio GTC uguale al suo indirizzo individuale
o PFIX//IDENT1 uguale ad ognuno dei suoi indirizzi designati per
questo sistema
o IDENT1 fissato all'identificativo ALLI di chiamata generale
allora eseguira' le seguenti azioni:
i) si sintonizzera' sul designato canale di traffico uscente e sara'
in grado di ricevere entro 35 ms dopo la fine del messaggio GTC.
ii) Se il bit D del messaggio GTC e' '0' , allora la *unita' radio*
abilitera' l'audio (per comunicazione di conversazione). Se il bit
D=1, l'unita' disabilitera' l'audio (per comunicazione dati); si noti
che essa non deve inviare messaggi di manutenzione entro gli *item*
(a meno che richiesto dal sistema da predisposizioni precedenti)
iii) Se IDENT1 del messaggio GTC e' ALLI e PFIX/IDENT2 del messaggio
GTC non e' il suo indirizzo individuale, allora l'unita' inibira' la
trasmissione dell'utente. Altrimenti essa abilitera' la trasmissione
dell'utente. (Vedi anche 11.2.7c).
Quando l'unita' e' sintonizzata sul canale di traffico designato,
essa puo' continuare la comunicazione.
(Notare che l'unita' continua ad usare PFIX, IDENT1 e IDENT2 del
messaggio GTC originale (vedi 9.2.2.5) in osservanza alle procedure
dei paragrafi 9.2.3.1, 9.2.3.3, 9.2.3.5, 9.2.3.6 e 9.2.3.7).
9.2.3.5 Riaggangio sul canale di traffico
Se l'utente della *unita' radio* riaggangia o effettua un'azione
equivalente (o se il suo terminale dati indica che la chiamata dati
e' finita) mentre e' sintonizzato sul canale di traffico, e se il suo
indirizzo individuale e' o PFIX/IDENT1 o PFIX/IDENT2 del messaggio di
GTC, allora l'unita' inviera' un numero di messaggi di disconnessione
(MAINT, OPER=011) sul canale di traffico. Essa inviera' ND1 messaggi
di disconnessione se il suo indirizzo individuale e' PFIX/IDENT1 del
messaggio GTC, o ND2 se il suo indirizzo individuale e' PFIX/IDENT2
del messaggio GTC. L'unita' inviera' continuamente i messaggi (vedi
3.3.2 e 6.2.2.2) e disabilitera' l'audio, e deve ritornare quindi
alle procedure di acquisizione del canale di controllo (vedi 6.2.1.1)
Una *unita' radio* il cui indirizzo individuale non e' PFIX/IDENT1
ne' PFIX/IDENT2 del messaggio GTC (esempio l'unita' chiamata in una
chiamata di gruppo) puo' lasciare la chiamata in ogni momento quando
l'utente riaggangia e equivalente; essa disabilitera' l'audio, e deve
ritornare allora alle procedure di acquisizione del canale di
controllo (senza segnalazione). Tuttavia, l'unita' chiamante invia
ND2 messaggi di disconnessione per una chiamata di gruppo (vedi
sopra), e cosi' il chiamante dovrebbe essere avvisato di rimanere con
una chiamata di gruppo sino al suo termine.
9.2.3.6 Tempo limite sul canale di traffico
Una *unita' radio* su un canale di traffico temporizzera' la
lunghezza di un periodo durante il quale essa non rileva alcuna
attivita' (esempio smette di ricevere un adeguato livello di segnale)
e temporizzera' anche la lunghezza di ciascun *item* essa trasmette.
Se l'unita' non rileva attivita' sul canale di traffico uscente per
un tempo TN allora assumera' che la chiamata e' terminata;
disabilitera' l'audio e deve ritornare alle procedure per
l'acquisizione del canale di controllo (senza segnalazione), e puo'
indicare all'utente che la chiamata e' terminata.
Se l'unita' trasmette un *item* che raggiunge la durata massima
permessa TT allora essa disabilitera' l'audio e:
i) inviera' un messaggio di "Pressel OFF" (per un *item* di
conversazione);
ii) inviera' ND1 o ND2 messaggi di disconnessione se il suo indirizzo
individuale e' PFIX/IDENT1 o PFIX/IDENT2 relativi al messaggio GTC
(come in paragrafo 9.2.3.5)
Essa allora deve cessare la trasmissione sul canale di traffico,
ritornare alle procedure di acquisizione del canale di controllo e
puo' indicare all'utente che la chiamata e' finita.
9.2.3.7 Messaggio selettivo di terminazione chiamata: MAINT con
OPER=110.
Se una *unita' radio* sul canale di traffico riceve un messaggio di
manutenzione della chiamata MAINT, OPER=110, con:
il numero di canale (CHAN) uguale al numero del canale di traffico
e PFIX/IDENT1 diverso da PFIX/IDENT1 del messaggio GTC
e PFIX/IDENT1 diverso da PFIX/IDENT2 del messaggio GTC
allora deve disabilitare immediatamente l'audio, ritornare alle pro-
cedure di acquisizione del canale di controllo e puo' indicare
all'utente che la chiamata e' terminata.
9.2.3.8 Messaggio di terminazione
Se una *unita' radio* su un canale di traffico riceve un messaggio di
terminazione CLEAR con:
il numero di canale CHAN uguale al numero del canale di traffico e il
campo REVS uguale '101010101010'
allora essa deve immediatamente disabilitare l'audio e spostarsi sul
canale di controllo uscente indicato dal campo CONT nel messaggio
CLEAR (per essere in grado di ricevere entro 35 ms dopo la fine della
parola di codice indirizzo CLEAR), e puo' indicare all'utente che la
chiamata e' finita.
Nota: Se il campo CONT nel messaggio CLEAR e' uguale a '0000000000' ,
allora la rimozione del canale e' dipendente dal sistema.
10. PROCEDURE DI CHIAMATA DI EMERGENZA.
Questo capitolo definisce le procedure standard per le chiamate di
emergenza (notare che sistemi diversi possono avere procedure di
emergenza alternative impiegando messaggi personalizzati dall'utente,
e che solo le *unita' radio* che hanno predisposizioni adatte al
sistema li possono usare).
Chiamate standard di emergenza da *unita' radio* possono essere
richieste a:
- a una *unita' radio*, *terminale d'utente a connessione diretta* o
a un gruppo
- tutte le unita' nel sistema
- ad un estensione di PABX (con indirizzamento breve o esteso)
Chiamate di emergenza da *unita' radio* sono richieste usando il
messaggio di richiesta chiamata di emergenza RQE (vedi 5.5.3.1.5).
Bit D nel messaggio RQE specifica se l'unita' sta richiedendo una
comunicazione per conversazione o dati. Una richiesta con
indirizzamento esteso e' indicata predisponendo IDENT1 nel messaggio
RQE ad un appropriato identificativo *gateway*.
Una *unita' radio* puo' interrompere un tentativo di una chiamata non
di emergenza per richiedere una chiamata di emergenza; in questo caso
abbandonera' il precedente tentativo. I messaggi ACKE (QUAL=0) e AHY
(E=1) sono le uniche risposte a chiamate RQE; esse indicano che il
TSC ha ricevuto positivamente RQE e che ogni ulteriore segnalazione
inviata all'unita' e' per una chiamata di emergenza. Fino a che
l'unita' non riceve ACKE (QUAL=0) o AHY (E=1) l'unita' ignora altri
riscontri e rifiuta messaggi AHYC con MODE 1.
Normalmente le chiamate di emergenza hanno precedenza su tutte le
altre chiamate. Le chiamate di emergenza possono essere di tipo "a
liberazione forzata", il che significa che un'altra chiamata puo'
essere terminata in anticipo per liberare un canale per la chiamata
di emergenza.
Se il bit EXT e' predisposoto a 0 nel messaggio RQE (esempio se RQE
non e' una chiamata aPABX con indirizzamento breve) allora la FLAG2
puo' essere fissata a '1' per indicare che la unita' chiamante sta
richiedendo una chiamata di emergenza di tipo speciale,
precedentemente concordata con il sistema; il TSC determina l'azione
richiesta in riferimento all'indirizzo della unita' chiamante quinti
il TSC e la *unita' radio* seguono appropriate (non standard) proce-
dure. In questo caso il significato dei campi IDENT1, D e FLAG1 nel
messaggio RQE possono essere ridefiniti. Per esempio EXT=0/FLAG2=1
potrebbe indicare che il campo IDENT1 contiene un messaggio speciale
di 13 bit perche' sia trattato al momento dal controllore; questi
speciali messaggi potrebbero avere ogni significato predefinito (come
il tipo dell'emergenza, il servizio richiesto o la posizione
geografica dell'unita'). Vedi anche le introduzioni ai paragrafi 10.1
e 10.2.
10.1 Procedure standard di chiamata d'emergenza per TSC
Se il TSC offre un servizio di emergenza allora sara' preparato ad
accettare un messaggio di RQE in ogni "slot" ad accesso casuale.
Le procedure del TSC dettagliate nei seguenti paragrafi sono per
chiamate di emergenza standard. Se, a seguito di una incorretta
operazione di una *unita' radio*, il TSC riceve un messaggio RQE
richiedente un modo speciale di servizio (EXT=0/FLAG2=1) da una
*unita' radio* che non e' stata precedentemente prevista allora esso
puo' rifiutare la richiesta rispondendo con ACKE (QUAL=0) e quindi
inviando ACKX (QUAL=0), dove entrambi ACKE e ACKX contengono lo
stesso PFIX, IDENT1 e IDENT2 come il messaggio RQE.
10.1.1 Risposte a richiesta di emergenza standard con indirizzamento
breve
Una *unita' radio* richiede una chiamata di emergenza generando un
messaggio RQE conformemente al protocollo ad accesso casuale (almeno
che essa abbia altre predisposizioni con il sistema). Alla ricezione
di un messaggio RQE con indirizzamento breve, il TSC inviera' una
risposta il piu' presto possibile; per il massimo ritardo permesso,
vedi 7.2.4. Risposte valide sono:
a. ACKE (QUAL=0): vedi 5.5.2.1 e 10.2.2
b. Una verifica di disponibilita' per la chiamata (AHY con il bit
E=1) vedi 9.1.1.5, 9.1.1.7 e 10.2.2.
c. Per una chiamata con PABX (esempio EXT=0 nel messaggio RQE):
- un messaggio Go To Channel (GTC): vedi 9.1.1.12 e 10.2.2 (Questa e'
la risposta raccomandata se il TSC non fa alcuna verifica di
disponibilita' per la chiamata - vedi 10.1.6)
ACKE (QUAL=0) e' inviato solo come una risposta ad un messaggio RQE;
esso e' un riscontro intermedio; indicando che ulteriore segnalazione
seguira'. Il TSC puo' mandare allora altri riscontri (es. ACKI, ACKX)
alla unita' chiamante in attesa, nei tempi appropriati per indicare
l'andamento della fase di costruzione delle chiamate; vedi paragrafo
10.1.5.
10.1.2 Rispostaa richieste d'emergenzastandardconindirizzamento
esteso
Una *unita' radio* richiede una chiamata di emergenza generando un
messaggio RQE, conformemente al protocollo ad accesso casuale (a meno
che essa non abbia altre predisposizioni con il sistema). Alla
ricezione di un messaggio RQE con indirizzamento esteso il TSC
inviera' una risposta ACKE (QUAL=0) con lo stesso prefisso ed
identificativi come nel messaggio RQE. Per il massimo ritardo
permesso, vedi 7.2.4.
10.1.3 Segnalazione per una chiamata precedente.
Dopo aver ricevuto un messaggio RQE, il TSC non inviera' alcuna altra
segnalazione all'unita' chiamante per ogni precedente richiesta di
chiamata da quella unita' (sebbene, per una chiamata sul canale di
traffico, esso puo' mandare un AHYX per informare l'unita' chiamata
che la chiamata non avra' luogo).
10.1.4 Conseguimento delle informazioni di indirizzo esteso
Dopo aver ricevuto un messaggio RQE con indirizzo esteso e
rispondendo con ACKE (QUAL=0), il TSC puo' chiedere l'indirizzo
completo del chiamato dall'unita' chiamante inviando un messaggio di
AHYC (come in paragrafo 9.1.1.3).
10.1.5 Riscontri inviati per indicare l'avanzamento di una chiamata
di emergenza.
Dopo aver inviato ACKE (QUAL=0) o un riscontro di disponibilita' AHY
con E=1 come risposta ad una richiesta di chiamata di emergenza, il
TSC puo' mandare riscontri ACKI, ACKQ, ACKX, ACKV, ACKB (QUAL=0) o
ACKT (QUAL=0) all'unita' chiamante per indicare l'avanzamento della
chiamata come in paragrafo 9.1.1.4.
10.1.6 Verifiche disponibilita' prima di allocare un canale di
traffico.
Per chiamate di emergenza, la verifica obbligatoria di disponibilita'
dettagliata in sezione 9.1.1.5 puo' essere esentata (per chiamate di
emergenza, la verifica di disponibilita' sulle *unita' radio* e'
fatta usando il messaggio AHY con il bit E=1).
10.1.7 Tempi limite del TSC.
Il TSC puo' ordinare all'unita' chiamante di far ripartire il suo
contatore di attesa TW, inviando il messaggio AHY con il bit POINT=1
(e il bit E=1); vedi 9.1.1.7 e 9.2.2.3. Se trascorre un tempo TW,
meno la tolleranza del contatore della *unita' radio*, da quando
l'ultimo messaggio e' ricevuto per una chiamata di emergenza
(dall'unita' chiamante), il TSC non deve inviare alcuna altra
segnalazione per la chiamata, eccettuato l'invio di AHYX per
informare una unita' chiamata che la chiamata non avra' luogo. Vedi
anche 10.2.7.
10.1.8 Altre procedure.
a. Una unita' chiamante puo' mandare un messaggio RQX per cancellare
la sua chiamata di emergenza. Le procedure del TSC sono definite in
9.1.1.8 per chiamate semplici.
b. E' raccomandato che il TSC non mescoli una chiamata di emergenza
con altre chiamate in coda.
c. Se tutti i canali di traffico sono occupati allora il TSC puo'
terminare prematuramente un'altra chiamata (con o senza avviso ai
corrispondenti che lo stanno usando) in modo di liberare un canale
per una chiamata di emergenza.
d. Le procedure per l'allocazione di un canale di traffico,
manutenzione delle chiamate e terminazione sono dettagliate in
9.1.1.12 e 9.1.2.
10.2 Procedure di chiamate di emergenza standard per *unita' radio*
Una *unita' radio* fara' solo un tentativo di chiamata di emergenza
alla volta. Mentre sta tentando l'accesso o aspettando ulteriore
segnalazione per una richiesta di emergenza, l'unita' non richiedera'
un'altra chiamata di ogni tipo (a meno che l'utente prima cancelli la
chiamata originale). Essa puo' fare una chiamata di emergenza in un
altro tempo. Per esempio, essa puo' interrompere un tentativo di
chiamata non di emergenza per richiedere una chiamata di emergenza;
in questo caso abbandonera' il precedente tentativo di chiamata
(senza inviare RQX).
Le procedure delle *unita' radio* dettagliate nei paragrafi seguenti
sono per chiamate di emergenza standard. Se una *unita' radio* invia
un messaggio di RQE con EXT=0/FLAG2=1 allora sta richiedendo un modo
speciale del servizio di emergenza precedentemente previsto nel
sistema e generalmente segue procedure non standard; comunque, se
essa riceve ACKE (QUAL=0) e seguentemente riceve ACKX (QUAL=0),
entrambi con lo stesso PFIX, IDENT1 e IDENT2 come il corrispondente
RQE, allora deve ritornare nello stato di riposo (e puo' indicare
all'utente che il tentativo di chiamata e' fallito).
10.2.1 Richiesta di una chiamata di emergenza standard.
Una *unita' radio* richiede una chiamata standard di emergenza
inviando un messaggio RQE sul canale di controllo; i campi nel
messaggio RQE saranno fissati propriamente (vedi 5.5.3.1.5). Alcuni
TSC possono permettere piu' di un tentativo di accesso casuale in una
trama; comunque, a meno che la *unita' radio* conosca il numero di
tentativi successivi permessi dal TSC, si deve attenere al normale
protocollo di accesso casuale - vedi 7.3 (Notare che la *unita' ra-
dio* richiedente una chiamata di emergenza ignora tutti i valori del
qualificatore di indirizzo eccetto M=20 - vedi 7.3.1)
L'unita' tentera' l'accesso fino a che riceve una valida risposta
(vedi 10.2.2/3), o fino a che il suo utente cancelli la chiamata
(vedi 10.2.8), o fino a che il tentativo di accesso fallisce (esempio
l'unita' ha inviato il numero massimo di trasmissioni NE e non ha
ricevuto nessuna risposta, o il suo tempo di accesso TC e' scaduto
(vedi 7.3.8). Nel caso di accesso fallito, se l'unita' non ha inviato
una richiesta, deve ritornare allo stato di riposo (e puo' indicare
l'insuccesso all'utente); altrimenti, deve aspettare una ulteriore
segnalazione per la chiamata - vedi da 10.2.4 a 10.2.7.
10.2.2 Risposte ad un RQE con indirizzamento breve.
Per una chiamata con indirizzamento breve, l'unita' chiamante
accettera' i seguenti messaggi (con PFIX/IDENT2) come il suo
indirizzo individuale e IDENT1 come identificativo del chiamato o
PABXI per una chiamata a PABX) come una risposta valida al suo RQE o
non inviera' piu' nessuna richiesta:
a. Un riscontro ACKE (QUAL=0)
b. Un messaggio AHY con il bit E=1
c. Per una chiamata non PABX (esempio EXT=0 nel messaggio RQE)
- Un messaggio GO TO CHANNEL (GTC) con il bit D uguale al bit D del
messaggio RQE.
Nei casi a. e b. l'unita' allora deve aspettare una ulteriore
segnalazione per la chiamata. Vedi anche paragrafi 10.2.6, 9.2.2.3 e
9.2.2.5.
10.2.3 Risposte a un messaggio RQE con indirizzamento esteso
Per una chiamata con indirizzo esteso, l'unita' chiamante accettera'
un messaggio di riscontro ACKE (QUAL=0) o AHY (E=1) (con lo stesso
prefisso ed identificativi del messaggio RQE) come una risposta al
suo RQE e non inviera' piu' nessuna altra richiesta; essa allora deve
aspettare una ulteriore segnalazione relativa alla chiamata. Vedi
anche 9.2.2.3.
10.2.4 Invio dell'informazione di indirizzo esteso.
Per una chiamata di emergenza con indirizzo esteso, dopo aver
ricevuto un messaggio ACKE (QUAL=0) o AHY (E=1) per la sua chiamata,
l'unita' chiamante inviera' l'intera informazione dell'indirizzo del
chiamato alla ricezione dell'appropriato AHYC; vedi paragrafo
9.2.2.1. Sino a che essa riceve ACKE (QUAL=0) o AHY (E=1), l'unita'
rispondera' al MODE 1 dei messaggi AHYC con ACKX (QUAL=0).
10.2.5 Riscontri indicanti l'avanzamento della chiamata di emergenza.
Dopo aver ricevuto un messaggio ACKE (QUAL=0) o AHY (E=1) per la sua
chiamata di emergenza, l'unita' chiamante in attesa prendera'
l'appropriata azione alla ricezione di ulteriori riscontri quali -
ACKI, ACKQ, ACKX, ACKV, ACKB, (QUAL=0) o ACKT (QUAL=0) - come
dettagliato nei paragrafi 9.2.1.4. Se riceve ACKE (QUAL=0) per la
chiamata allora l'unita' deve aspettare una ulteriore segnalazione.
10.2.6 Verifica disponibilita' e allocazioni del canale per la
propria chiamata.
Una unita' chiamante tentando l'accesso o aspettando ulteriore
segnalazione per una chiamata di emergenza obbedira' alle procedure
di verifica disponibilita'. (Vedi da 9.2.2.2 a 9.2.2.4). Notare
particolarmente che:
a. Se l'unita' non ha ricevuto ACKE (QUAL=0) o AHY (E=1) per la sua
chiamata di emergenza obbedira' ad un messaggio GTC se la sua
chiamata e' di tipo ad indirizzamento breve non PABX e il messaggio
GTC e' per la chiamata richiesta (vedi di seguito).
b. Dopo aver ricevuto ACKE (QUAL=0) o AHY (E=1) per la sua chiamata
di emergenza, l'unita' obbedira' ad un messaggio GTC solo se essa e'
individualmente indirizzata dal GTC (esempio se il suo indirizzo
individuale e' PFIX/IDENT1 o PFIX/IDENT2).
Vedi paragrafo 9.2.2.5 , regola 1.
Per una chiamata con indirizzamento breve non PABX o dopo aver
ricevuto ACKE (QUAL=0) o AHY (E=1) per una chiamata con
indirizzamento breve PABX o dopo aver inviato il completo indirizzo
per una chiamata con indirizzo esteso, l'unita' assumera' che il
messaggio GTC che essa riceve e' per la sua richiesta di chiamata se
PFIX/IDENT2 e' il suo indirizzo individuale, IDENT1 e' l'indirizzo
del chiamato o (*gateway*) e il bit D e' lo stesso del messaggio RQE.
Se e' cosi', essa puo' dare una indicazione all'utente, e deve
ritornare allo stato di riposo alla fine della chiamata.
10.2.7 Tempo scaduto in attesa di segnalazione
Una unita' chiamante in attesa di ulteriore segnalazione per una
chiamata di emergenza deve ritornare allo stato di riposo se il tempo
TW e' scaduto da quando l'ultimo messaggio e' stato inviato per la
chiamata, esempio:
RQE, richiesta chiamata di emergenza (vedi 10.2.1)
o SAMIS, fornendo le informazioni di indirizzo esteso per la chiamata
(vedi 9.2.2.1)
o ACK (QUAL=0) inviato in risposta ad un messaggio AHY con POINT=1,
E=1 e IDENT1 come identificativo del chiamato o *gateway* (vedi
9.2.2.3)
Essa puo' anche indicare l'insuccesso all'utente.
10.2.8 Altre procedure.
a. Una unita' chiamante in attesa di una chiamata di emergenza puo'
tentare di cancellare la chiamata inviando una richiesta di
cancellazione RQX.
Le procedure sono come definite in 9.2.1.7 per la cancellazione di
chiamate semplici.
b. Le procedure su un canale di traffico allocato sono definite in
9.2.3 (a meno che altre predisposizioni siano state fatte nel
sistema).
11. PROCEDURE PER CHIAMATA DI INCLUSIONE
Durante una chiamata RQS o RQE, una *unita' radio* allocata sul suo
canale di traffico puo' inviare una richiesta di messaggio RQS al
TSC, per chiedere che un'altro *utente* si possa unire alla chiamata
in corso. Questa funzione puo' essere usata per:
a) una chiamata di conferenza - un utente sul canale puo' chiedere
che la chiamata venga allargata per includere un altro *utente*,
b) trasferimento di chiamata - un utente puo' includere un altro
*utente* nella chiamata e dopo abbandonare la chiamata che puo'
continuare senza esso
c) ripetizione di chiamata - un utente puo' chiedere l'assegnazione
del canale segnalando che la chiamata deve essere ritrasmessa.
L' *utente* incluso puo' essere una *unita' radio*, un *terminale
d'utente a connessione diretta*, un gruppo di unita', un estensione
PABX (con indirizzamento breve o esteso).
Una *unita' radio* richiede una chiamata di inclusione trasmettendo
un messaggio di richiesta RQS sul canale di traffico assegnato. (Una
richiesta di indirizzamento esteso e' indicata fissando IDENT1 nel
messaggio RQS all'appropriato identificativo *gateway*).
Il TSC risponde e, per una richiesta di indirizzamento esteso, da'
ordine all'unita', che ha richiesto l'inclusione, di trasmettere
tutti i particolari dell' *utente* chiamato. Dopo verifica la
disponibilita' dello *utente* chiamato (se necessario) e indirizza lo
*utente* chiamato sul canale di traffico. Per tutta la durata della
transazione, il TSC puo' inviare riscontri all'unita' che ha chiesto
l'inclusione per indicare la progressione e il successo/perdita della
transazione.
Quando un utente inizia una chiamata di inclusione, la sua richiesta
di trasmissione e' disabilitata fino a quando la *unita' radio*
riceve un riscontro diverso da ACKI (QUAL=1) o fino a quando scade il
tempo.
Dopo che l' *utente* e' stato incluso in una chiamata, il TSC puo'
permettere alle unita' di abbandonare la chiamata, senza concludere
la chiamata, a condizione che il numero degli *utenti* che
indicheranno la condizione di riaggancio non e' ridotto sotto il
numero normale per il tipo di chiamata.
Le limitazioni della temporizzazione per i messaggi trasmessi su un
canale di traffico sono specificati nelle sezioni 6.1.2.2 e 6.2.2.2.
11.1 Procedure del TSC per chiamate di inclusione.
Questo paragrafo definisce le procedure per i TSC che offrono la
possibilita' della chiamata di inclusione.
11.1.1 Risposta ad una chiamata di inclusione con indirizzamento
breve.
Una *unita' radio* richiede una chiamata di inclusione con
indirizzamento breve trasmettendo un messaggio RQS (con EXT=1, o con
EXT=0 e IDENT1 fissato a un identificativo di un *utente* chiamato
valido) sul canale di traffico. Alla ricezione di un messaggio RQS di
inclusione con indirizzamento breve, il TSC dovra' inviare una
risposta:
ACKI, ACKQ (QUAL=0), ACKX, ACKV, ACKT (QUAL=0) o ACK (QUAL=0).
Per gli identificativi, vedi sezione 5.5.2.1; per ritardo
accettabile, vedi 6.1.2.2.
Questi messaggi di riscontro possono anche essere inviati all'unita'
per indicare la progressione della propria chiamata di inclusione -
vedi 11.1.4.
11.1.2 Risposta a una richiesta di inclusione con indirizzamento
esteso.
Una *unita' radio* richiede una chiamata di inclusione con
indirizzamento esteso trasmettendo un messaggio RQS (con EXT=0 e
IDENT1=IPFIXI, PABX) su canale di traffico. Alla ricezione di un
messaggio RQS di richiesta di inclusione con indirizzamento esteso,
il TSC inviera' una delle seguenti risposte con lo stesso prefisso e
identificativi come nella RQS di inclusione:
a) un riscontro ACKI (QUAL=1), ACKX o ACKV (QUAL=0).
b) AHYC (per esempio un'istruzione di inviare le informazioni com-
plete del chiamato).
Per il ritardo accettabile vedi 6.1.2.2. Vedi anche 11.1.3 e 11.1.4.
11.1.3 Modalita' per inviare le informazioni di indirizzamento
esteso.
Dopo la ricezione di un messaggio RQS di inclusione con
indirizzamento esteso, il TSC puo' richiedere l'indirizzamento
completo del chiamato inviando un messaggio AHYC, con:
- lo stesso prefisso e identificativi come nel messaggio RQS di
inclusione
- il campo DESC fissato per indicare l'appropriato *gateway* (vedi
5.5.3.2.8).
- il campo SLOTS fissato al corrispondente della RQS di inclusione.
Il messaggio AHYC da' istruzione alla *unita' radio*, che ha
richiesto l'inclusione di inviare le informazioni dell'indirizzo
dell'utente chiamato (vedi 11.3.1). Se il TSC non decodifica con
successo le informazioni di indirizzo, la *unita' radio* ripete il
messaggio AHYC o trasmette ACKV (QUAL=0) per indicare il fallimento
della chiamata di inclusione.
Dopo aver decodificato con successo tutte le informazioni di
indirizzo, il TSC puo' inviare i riscontri appropriati all'unita' che
ha richiesto l'inclusione (vedi 11.1.4).
11.1.4 Riscontri inviati per indicare la progressione di una chiamata
di inclusione
Il TSC puo' inviare messaggi di riscontro per indicare ad una *unita'
radio* la progressione della sua chiamata di inclusione - per
identificativi, vedi 5.5.2.1. (Per chiamate di inclusione con
indirizzamento esteso, solo ACKI (QUAL=1), ACKX e ACKV (QUAL=0) sono
appropriate fino a quando non sono state ottenute tutte le
informazioni dell'indirizzo.)
ACKI (QUAL=0) - L' *utente* chiamato e' stato avvisato ma non e'
ancora pronto.
ACKI (QUAL=1) - Riscontro intermedio; ulteriore segnalazione a
seguire.
ACKQ (QUAL=0) - Tutti i canali di traffico sono in uso sul sito
chiamato; ulteriore segnalazione a seguire.
ACKX (QUAL=0) - Chiamata non valida, richiesta respinta.
ACKX (QUAL=1) - Sovraccarico del sistema ad esempio tutti i canali
sono in uso sul sito chiamato e la chiamata non puo' essere accodata.
ACKV (QUAL=0) - L'unita' chiamata non e' in contatto radio o
abbandono della chiamata di inclusione.
ACKV (QUAL=1) - Conflitto della chiamata in progressione (esempio
chiamata occupata) o l'utente chiamato non vuole ricevere la
chiamata.
ACKT (QUAL=0) - l' *utente* chiamato e' stato deviato.
ACK (QUAL=0) - Richiesta di inclusione accettata; la verifica di
disponibilita' ha avuto successo (se eseguita); l' *utente* chiamato
sara' indirizzato sul canale di traffico.
Per il massimo ritardo accettabile delle ripetizioni dei riscontri
ACKX, ACKV, ACKT e ACK vedi il tempo limite TB nel paragrafo 11.2.4.
11.1.5 Verifica della disponibilita' della *unita' radio* chiamata
Se una richiesta di inclusione specifica che una *unita' radio*
individuale deve essere inclusa, il TSC puo' verificare la
disponibilita' dell'unita' chiamata prima di darle istruzioni di
unirsi alla chiamata in progressione.
Il TSC verifica la disponibilita' della *unita' radio* chiamata
inviando il messaggio AHY sul canale di controllo (vedi 5.5.3.2.1 e
9.2.2.2a).
Per una verifica di disponibilita' di una chiamata di inclusione,
IDENT 2 nel messaggio AHY e' fissato a INCI (per inibire all'utente
chiamato la risposta con ACKB (QUAL=0)) e una parola di codice dati
puo' essere aggiunta contenente l'indirizzo dell'unita' che ha
richiesto l'inclusione.
Il TSC puo' indicare il risultato della verifica di disponibilita' ad
una *unita' radio* che ha richiesto l'inclusione, inviando il
riscontro (i) appropriato (vedi 11.1.4) sul canale di traffico.
11.1.6 Cancellazione di chiamata
Una *unita' radio* puo' cancellare la sua richiesta di chiamata di
inclusione trasmettendo un messaggio RQX (vedi 5.5.3.1.3) sul canale
di traffico. Alla ricezione di un messaggio RQX cancellante la
chiamata di inclusione, il TSC rispondera' con ACK (QUAL=0) o ACK
(QUAL=1), con lo stesso prefisso e identificativi come nel RQX; vedi
anche 11.1.4 e 11.2.6.
Se una chiamata di inclusione e' stata cancellata, il TSC puo'
informare la *unita' radio* chiamata inviando il messaggio AHYX (con
IDENT2 fissato a INCI) sul canale di controllo. Il messaggio AHYX
puo' essere ripetuto se non ha ancora ricevuto un riscontro con il
messaggio ACK (QUAL=1) dall'unita' chiamata (vedi 9.2.2.4).
11.1.7 Tempo limite del TSC.
Il TSC puo' dare istruzione ad una *unita' radio* che ha richiesto
l'inclusione di far ripartire il suo temporizzatore di attesa TI,
inviando un messaggio AHY con:
- Il bit POINT fissato al valore '1'
- PFIX/IDENT2 fissato al valore dell'indirizzo individuale
dell'unita'
- IDENT1 fissato al valore dell'identificativo del chiamato e del
*gateway*.
Vedi 9.1.2.2 e 9.2.3.2. Se il tempo TI, meno le tolleranze del
temporizzatore delle *unita' radio* , scade senza che l'ultimo
messaggio venga ricevuto per una chiamata di inclusione (dall'unita'
che ha richiesto la chiamata d'inclusione), il TSC non inviera'
alcuna ulteriore segnalazione per la transazione, eccetto quando puo'
inviare il messaggio AHYX sul canale di controllo per informare la
*unita' radio* chiamata. Vedi anche 11.2.5.
11.1.8 Assegnazione del canale di traffico.
Il TSC indirizzera' una *unita' radio* chiamata o un gruppo di
*unita' radio* al corretto canale di traffico usando i messaggi Go To
Channel GTC (con IDENT2 fissato a INCI); vedi paragrafo 5.4.
11.1.9 Termine di una chiamata.
Dopo una chiamata di inclusione, il TSC puo' permettere agli *utenti*
di abbandonare la chiamata in progressione, senza terminare la
chiamata stessa, nel modo seguente:
i) Per una chiamata di gruppo o una chiamata in cui un gruppo e'
stato incluso, il TSC puo' permettere alle *unita' radio* di inviare
la segnalazione di gancio (o ai *terminali d'utente a connessione
diretta* , oppure utenti PABX di abbandonare la chiamata), senza
terminare la chiamata stessa, a condizione che almeno un *utente*,
che indichera' la fine dell'uso del canale, rimanga in conversazione.
ii) Per una chiamata comprendente solo utenti con indirizzamento
individuale, il TSC puo' permettere alle *unita' radio* di inviare la
segnalazione di gancio (o ai *terminali d'utente a connessione
diretta*, oppure utenti PABX di abbandonare la chiamata) senza
terminare la chiamata stessa verificando che almeno due *utenti*
rimangano in conversazione.
In questo modo, almeno il numero normale di utenti in grado di
indicare la fine dell'uso del canale, rimane in conversazione
(escludendo la corruzione di messaggi di segnalazione). Vedi anche
paragrafo 9.1.2.6.
11.2 Procedure per *unita' radio* che richiedono l'inclusione.
Una *unita' radio* sul canale di traffico chiedera' soltanto una
transazione alla volta; mentre sta richiedendo una chiamata di
inclusione oppure e' in attesa di ulteriori segnalazioni, la *unita'
radio* non richiedera' un'altra transazione di qualsiasi tipo (a meno
che l'utente cancelli prima la richiesta di chiamata di inclusione).
11.2.1 Richiesta di inclusione.
Quando un utente inizia una chiamata di inclusione (indicando che
desidera che un altro si unisca alla chiamata in corso), la *unita'
radio* inibira' la trasmissione dell'utente per esempio:
- disabilitando il tasto per la trasmissione per una chiamata per
conversazione, o
- inibendo il terminale dati dell'utente per una chiamata dati.
La *unita' radio* richiede una chiamata di inclusione trasmettendo un
messaggio RQS sul canale di traffico assegnato. I campi del messaggio
RQS saranno fissati appropriamente (vedi 5.5.3.1.1); tuttavia notare
particolarmente che:
a. Se la chiamata in progressione e' una chiamata per conversazione
(vedi 9.2.2.5 e 9.2.3.4), il bit DT sara' fissato a '0', per una
chiamata dati DT sara' fissato a '1'.
b. Il bit LEVEL sara' fissato a '1'.
(Questo obbligo e' imposto per prevenire che il messaggio RQS possa
essere interpretato come AHY dall' *utente* chiamato).
c. Una richiesta di messaggio con indirizzamento esteso e' indicato
fissando IDENT1 e il messaggio RQS all'appropriato valore di *gate-
way* (ad esempio IPFIXI, PABXI).
Dopo aver trasmesso un messaggio di richiesta di inclusione sul
canale di traffico, l'unita' aspettera' di ricevere una risposta dal
TSC. Se non viene ricevuta nessuna risposta entro il tempo definito
nel paragrafo 6.2.2.2, la *unita' radio* riterra' che il messaggio
non ha avuto successo e puo' ritrasmetterlo. Potra' ripetere la
richiesta di inclusione, aspettando ogni volta una risposta dal TSC,
fino a che:
i) riceve una risposta valida (vedi 11.2.2/3), oppure
ii) il proprio utente cancella la chiamata di inclusione (vedi
11.2.6), o
iii) ha inviato il massimo numero di trasmissioni NI.
In questo caso, deve aspettare una ulteriore segnalazione per la
chiamata di inclusione (vedi 11.2.4 e 11.2.5).
11.2.2 Risposta ad una richiesta di inclusione con indirizzamento
breve.
Per un messaggio RQS di richiesta di inclusione con indirizzamento
breve, la *unita' radio* accettera' i seguenti messaggi come risposta
valida alla propria RQS e non inviera' ulteriori richieste:
a. ACKI, ACKQ (QUAL=0) ACKX, ACKV o ACK (QUAL=0), con PFIX/IDENT2
come proprio indirizzo individuale e IDENT1 come l'identificativo del
chiamato. (o PABXI per chiamate a PABX).
b. ACKT (QUAL=0) con PFIX/IDENT2 come proprio indirizzo individuale.
Per altre azioni alla ricezione di questi messaggi vedi paragrafo
11.2.4.
11.2.3 Risposta ad una richiesta di inclusione con indirizzamento
esteso.
Per una RQS di inclusione con indirizzamento esteso, la *unita' ra-
dio* accettera' i seguenti messaggi (con gli stessi prefissi ed
identificativi come nel messaggio RQS) come una risposta valida al
proprio RQS e non iniziera' ulteriori richieste:
a) Un riscontro ACKI (QUAL=1), ACKX oppure ACKV (QUAL=0)
b) AHYC (cioe' un istruzione di inviare le informazioni complete
dell'utente chiamato).
Per ulteriori azioni alla ricezione di questi messaggi vedi 11.2.4 e
11.3.1.
11.2.4 Riscontri ricevuti.
Se una *unita' radio* , in attesa di una risposta per una richiesta
RQS di inclusione, o di ulteriori segnalazioni per una chiamata di
inclusione, riceve un appropriato riscontro dopo dovra' comportarsi
come sotto indicato.
Per una chiamata di inclusione con indirizzamento esteso, soltanto
ACKI (QUAL=1) ACKX e ACKV (QUAL=0) sono corrette fino a quando
l'informazione completa dell'indirizzo non e' stata inviata. Per
identificativi, vedi 5.5.2.1.
ACKI (QUAL=0) - L'utente chiamato e' stato avvisato ma non e' ancora
pronto.
ACKI (QUAL=1) - Riscontro intermedio, seguira' ulteriore
segnalazione.
ACKQ (QUAL=0) - Tutti i canali di transito sono in uso sul sito
chiamato, seguira' ulteriore segnalazione.
ACKX (QUAL=0) - Chiamata non valida; richiesta respinta.
ACKX (QUAL=1) - Sovraccarico del sistema; richiesta respinta.
ACKV (QUAL=0) - L'unita' chiamata non e' in contatto radio o la
chiamata di inclusione e' stata abbandonata.
ACKV (QUAL=1) - Chiamata in progressione in conflitto (ad esempio
l'utente chiamato e' occupato) o l'utente chiamato non desidera
ricevere questa chiamata.
ACKT (QUAL=0) - L'utente chiamato e' stato deviato.
ACK (QUAL=0) - Richiesta di inclusione accettata; l'utente chiamato
sara' indirizzato sul canale di traffico.
Se viene ricevuto ACKI oppure ACKQ (QUAL=0), la *unita' radio* deve
aspettare una ulteriore segnalazione. Tuttavia, per una chiamata per
conversazione, puo' riabilitare il tasto per la trasmissione alla
ricezione dei messaggi ACKI (QUAL=0) oppure ACKQ (QUAL=0).
Se viene ricevuto ACKX oppure ACKV la *unita' radio* deve riabilitare
la trasmissione dell'utente e puo' indicare all'utente che la
chiamata di inclusione non e' andata a buon fine.
Se un completo messaggio ACKT (QUAL=0) viene ricevuto la *unita' ra-
dio* potra' sia:
a. Riabilitare la trasmissione dell'utente (e puo' indicare
all'utente che l'altra parte chiamata e' stata deviata), oppure
b. Tentare una nuova chiamata di inclusione all'indirizzo di
deviazione.
Se un messaggio ACKT (QUAL=0) viene ricevuto incompleto, allora:
i) se l'unita' non richiede l'indirizzo di deviazione, riabilitera'
la trasmissione dell'utente (e potra' dare un'indicazione
all'utente).
ii) Se l'unita' non richiede l'indirizzo di deviazione allora:
- se non ha ricevuto precedenti risposte alla sua richiesta RQS di
inclusione, e non ha inviato il numero massimo di trasmissioni del
messaggio RQS (vedi 11.2.1), ignorera' il messaggio ACKT;
- negli altri casi deve aspettare un ACKT ripetuto, riabilitando la
trasmissione dell'utente se il tempo TB scade (in questo caso, potra'
indicare all'utente la non andata a buon fine).
Se ACK (QUAL=0) viene ricevuto, l'unita' deve riabilitare la
trasmissione dell'utente e puo' indicare all'utente stesso che
l'altro utente chiamato e' stato indirizzato sul canale di traffico.
Dopo aver ricevuto ACKX, ACKV oppure ACK per la propria chiamata di
inclusione, l'unita' non richiedera' sul canale di traffico un'altra
transazione di qualsiasi tipo allo stesso identificativo (o *gate-
way*) per almeno il tempo TB. Dopo aver ricevuto ACKT per la propria
chiamata di inclusione, l'unita' non richiedera' sul canale di
traffico altre transazioni di qualsiasi tipo per almeno il tempo TB.
11.2.5 Tempo limite dopo l'attesa per una chiamata di inclusione.
Una *unita' radio*, in attesa di ulteriore segnalazione per una
chiamata di inclusione, riabilitera' la trasmissione dell'utente se
il tempo TI e' trascorso dall'ultimo messaggio che ha inviato per la
transazione, cioe':
RQS richiedente la chiamata di inclusione (vedi 11.2.1)
oppure SAMIS, che ha fornito le informazioni di indirizzamento esteso
per la chiamata (vedi 11.3.1.)
oppure ACK (QUAL=0), inviato in risposta ad un messaggio di AHY con
il bit POINT=1 e IDENT1 come identificativo del chiamato o *gateway*
(vedi 9.2.3.2).
Puo' anche indicare all'utente che il risultato della transazione e'
sconosciuto.
11.2.6 Cancellazione della chiamata di inclusione.
Una *unita' radio* puo' cancellare una richiesta di inclusione (dopo
l'invio di un messaggio RQS e mentre sta aspettando di ricevere ACKX,
ACKV, ACKT oppure ACK) trasmettendo una richiesta di cancellazione
RQX (vedi 5.5.3.1.3) sul canale di traffico. L' unita' allora deve
aspettare una risposta dal TSC; per la temporizzazione, vedi 6.2.2.2.
L'unita' ripetera' la propria richiesta di cancellazione, ogni volta
aspettando un messaggio dal TSC, fino a che si verifichi uno dei
seguenti eventi:
a. Riceve ACK (QUAL=1), con lo stesso prefisso e identificativi come
nel messaggio RQX, confermando la cancellazione della chiamata di
inclusione.
b. Riceve ACKX, ACKV, ACKT (QUAL=0) oppure ACK (QUAL=0) per la
chiamata di inclusione che sta tentando di cancellare. Vedi anche
11.2.4.
c. Ha inviato il massimo numero di trasmissioni NI. In questo caso,
si mettera' in attesa di segnalazione per la chiamata di inclusione
(vedi 11.2.4 e 11.2.5).
Nei casi a. e b., l'unita' riabilitera' la trasmissione all'utente.
11.2.7 Altre procedure.
a. Una *unita' radio* non tentera' una chiamata di inclusione se la
trasmissione dell'utente e' stata inibita (con un messaggio GTC o con
un messaggio MAINT (OPER=''111''); vedi 9.2.2.5, 9.2.3.3 e 9.2.3.4).
b. Se mentre una *unita' radio* sta richiedendo o sta cercando di
cancellare la chiamata di inclusione, o mentre e' in attesa di
ulteriore segnalazione, riceve un messaggio MAINT (OPER=''111'') che
inibisce la trasmissione dell'utente (vedi 9.2.3.3), allora
continuera' con la chiamata di inclusione ma non riabilitera' la
trasmissione dell'utente alla fine della transazione.
c. Se mentre una *unita' radio* sta richiedendo o sta tentando di
cancellare una chiamata di inclusione o mentre e' in attesa di
ulteriore segnalazione, riceve un messaggio GTC che assegna un
cambiamento di un canale di traffico, eseguira' le azioni i) e ii)
come specificato nel paragrafo 9.2.3.4 e dopo continuera' con la
chiamata di inclusione. Alla fine della transazione, l'unita'
riabilitera' la trasmissione dell'utente solo se e' stata abilitata
dalla azione iii) di 9.2.3.4.
d. Se un utente di una *unita' radio* riaggancia (o azione
equivalente) mentre sta richiedendo o sta tentando di cancellare una
chiamata di inclusione, o mentre e' in attesa di ulteriore
segnalazione, allora l'unita' abbandonera' la chiamata di inclusione
e seguira' le procedure specificate nel paragrafo 9.2.3.5.
(Se l'utente riaggancia (o azione equivalente) dopo una chiamata di
inclusione, allora l'unita' ubbidira' alle procedure specificate nel
paragrafo 9.2.3.5, negli altri casi vedi anche paragrafo 11.1.9).
e. Se mentre una *unita' radio* sta richiedendo o sta tentando di
cancellare una chiamata di inclusione, o mentre e' in attesa di
ulteriore segnalazione, riceve un messaggio MAINT (OPER=''110'')
oppure un messaggio CLEAR concludente la chiamata in corso, deve
abbandonare la chiamata di inclusione e attenersi alle procedure
specificate nei paragrafi 9.2.3.7 e 9.2.3.8 rispettivamente.
11.3 Procedure per tutte le *unita' radio* su un canale di traffico
allocato.
11.3.1 Istruzioni per inviare le informazioni di un indirizzo esteso.
Questa procedura sara' seguita da tutte le *unita' radio* che sono
equipaggiate per richiedere una chiamata di inclusione con
indirizzamento esteso.
Se una *unita' radio* sul canale di traffico riceve un messaggio AHYC
con PFIX/IDENT2 uguali al proprio indirizzo individuale allora
inviera' le informazioni di indirizzo o trasmettera' il messaggio
ACKX (QUAL=0), come sotto indicato. Per la temporizzazione vedi
6.2.2.2.
Se
l'unita' ha inviato un messaggio RQS di inclusione con indirizzamento
esteso
e IDENT1 corrisponde ad IDENT1 dalla chiamata RQS d'inclusione
e DESC e' appropriato ad IDENT1 (vedi 5.5.3.2.8)
e SLOTS corrisponde ad un RQS di inclusione (cioe' SLOTS='01')
allora
trasmettera' le informazioni complete dell'indirizzo chiamato,
secondo il formato della parola di codice definita nel paragrafo
5.6.1.2.2 (SAMIS, MODO 1).
Altrimenti
l'unita' trasmettera' ACKX (QUAL=0), con lo stesso prefisso e
identificativi come AHYC.
12. PROCEDURE DELLA DEVIAZIONE DI CHIAMATA.
Questa sezione definisce le procedure per la richiesta e per la
cancellazione della deviazione di chiamata. Richieste possono essere
applicabili a chiamate per conversazione, chiamate dati o entrambi.
Due tipi di deviazioni di chiamata sono predisposti:
i) Deviazione di chiamata autogenerata. Una *unita' radio* puo'
richiedere che le future chiamate indirizzate ad essa siano
reindirizzate ad una specificata destinazione alternativa.
ii) Deviazione richiesta da terzo *utente*. Una *unita' radio* puo'
richiedere che le future chiamate indirizzate ad un altro utente (o
gruppo) vengano reindirizzate ad una specificata destinazione
alternativa. Per esempio, una unita' di dispaccio puo' richiedere la
deviazione per mezzo di una *unita' radio* della propria flotta.
In generale, *unita' radio A (l'unita' richiedente) puo' deviare una
chiamata per l'indirizzo B (l'indirizzo bloccato) alla destinazione
alternativa C (indirizzo deviato): per una deviazione auto-generata,
B=A.
Le procedure permettono che l'indirizzo bloccato B possa essere una
*unita' radio*, un *terminale d'utente a connessione diretta*, un
indirizzo di gruppo.
L'indirizzo di destinazione C puo' essere un'*unita' radio*, un
*terminale d'utente a connessione diretta*, un indirizzo di gruppo,
una estensione PABX (in forma breve o generale).
Tre tipi di cancellazione delle deviazioni di chiamata sono
disponibili:
i) Cancellazione auto generata.
Una *unita' radio* puo' richiedere che le proprie chiamate non siano
piu' deviate.
ii) Cancellazione da terzo *utente* .
Una * unita' radio* puo' richiedere che le chiamate all'unita' di un
altro utente (o gruppo) non siano piu' deviate.
iii) Cancellazione generale dal destinatario.
Una *unita' radio* puo' richiedere che qualsiasi deviazione esistente
venga cancellata. (Questa e' una cancellazione generale dal
destinatario di deviazione, la specifica cancellazione di deviazione
dal destinatario e' coperta da cancellazione da terzi).
E' raccomandato che richieste per la deviazione da terzo *utente* o
cancellazione da terzo *utente* siano accettate solo se provenienti
da unita' autorizzate.
La deviazione di chiamata e' richiesta o cancellata usando il
messaggio Richiesta Deviazione Chiamata RQT (vedi 5.5.3.1.4). In
questo messaggio:
- PFIX/IDENT2 e' l'indirizzo della *unita' radio* richiedente.
- Per richieste di deviazione, IDENT1 e' l'identificativo di
deviazione C (o IPFIXI, PABXI per un indirizzo interprefisso,
qualsiasi estensione PABX rispettivamente).
- Per cancellazione autonoma o da terzo *utente* di una deviazione di
chiamata, IDENT1 specifica l'unita' o il gruppo a cui le chiamate
devono essere indirizzate (oppure IPFIXI per un indirizzo
interprefisso).
- Per cancellazione generale dal destinatario IDENT1 e' fissato al
valore DIVERTI.
- Il bit DIV indica la richiesta di una deviazione o la
cancellazione.
- Per una deviazione di chiamata, FLAG 2 indica se e' una deviazione
autonoma o per terzo *utente*.
- Il campo SD specifica il tipo di chiamata (per esempio fonia, dati
o entrambi) a cui la deviazione o cancellazione si riferisce.
Allo scopo di definire il tipo di deviazione chiamate per
conversazione sono definite come richieste e usano RQS (DT=0), RQE
(D=0), RQQ (STATUS='00000') oppure RQQ (STATUS='11111'). Le chiamate
dati sono definite come richieste di chiamate in cui viene usato RQS
(DT=1), RQE (D=1), RQQ ('00001' a '11110'), RQC o RQD.
Per richieste di deviazione autogenerate o per ogni cancellazione due
indirizzi (piu' altri parametri) specificano il requisito. Tuttavia,
per richiesta di deviazione da terzo *utente* l'indirizzo B
(indirizzo bloccato) deve essere fornito.
Il TSC usa il messaggio AHYC per richiedere:
a. Informazioni indirizzamento esteso per IDENT1
b. Indirizzo bloccato B
come appropriato. Se entrambi a. e b. sono necessari il TSC ottiene
informazione completa in due passi, in ogni passo viene usato AHYC. I
messaggi AHYC sono distinti dal valore con cui e' fissato IDENT1 (a
IPFIXI, PABXI per a. , o a DIVERTI per b.), e cosi' l'ordine in cui
essi sono inviati non e' prescritto.
Nelle procedure, una richiesta per deviazione o cancellazione di
chiamata e' definita come una richiesta ad indirizzamento esteso se
IDENT1 e' fissato a IPFIXI, PABXI. Una richiesta e' definita come
"complessa" se richiede l'indirizzamento esteso o se tre indirizzi
devono essere inviati, in caso contrario e' "semplice".
Notare che procedure con indirizzamento esteso sono usate per
richiedere la deviazione ad ogni estensione PABX ( sia per
un'estensione con numero "breve" o "esteso"). La *unita' radio* fissa
IDENT1 nel messaggio RQT e PABXI e dopo invia le informazioni di
indirizzo del PABX in risposta a un messaggio AHYC con IDENT1 fissato
a PABXI e DESC fissato a '010'. L'unita' fissa il bit SP nel
messaggio SAMIS per indicare se sta inviando cifre BCD o un numero di
estensione a 13 bit (piu' 2 bit del numero del centralino).
Vedi 5.5.3.2.8 e 5.6.1.2.2.
Se il TSC accetta una richiesta di deviazione e dopo una chiamata
viene richiesto da una *unita' radio* l'indirizzo bloccato, il TSC
indica l'indirizzo di deviazione alla *unita' radio* chiamante usando
il riscontro ACKT (QUAL=0). L'unita' allora puo' ritentare con
l'indirizzo di deviazione o ritornare nello stato di riposo. Per
esempio, vedi paragrafi 9.1.1.4 e 9.2.1.4.
12.1 Procedure del TSC per richieste di deviazione di chiamata.
12.1.1 Risposte alla richiesta di deviazione semplice.
Una *unita' radio* richiede una deviazione semplice di chiamata
generando un messaggio RQT (con FLAG2=0 e IDENT1 fissato a un
identificativo dell'utente chiamato valido oppure a DIVERTI),
conformemente al protocollo ad accesso casuale. Alla ricezione di un
messaggio RQT semplice, il TSC inviera' una delle seguenti risposte
con lo stesso prefisso ed identificativi come nel messaggio RQT:
ACKI (QUAL=1), ACKX, ACKV (QUAL=0) oppure ACK (QUAL=0)
Per il ritardo accettabile vedi 7.2.4. Vedi anche 12.1.5.
12.1.2 Risposta a una richiesta di deviazione complessa
Una *unita' radio* richiede una deviazione complessa di chiamata
generando un messaggio RQT (con FLAG2=1 e/o IDENT1=IPFIXI, PABXI)
conforme al protocollo ad accesso casuale. Alla ricezione di un
messaggio RQT, il TSC inviera' una delle seguenti risposte:
a. Un riscontro ACKI (QUAL=1), ACKX o ACKV (QUAL=0), con gli stessi
prefissi e identificativi come del RQT.
b. Per un messaggio RQT ad indirizzamento esteso: Un messaggio AHYC
che da' istruzione all'unita' di inviare le informazioni
dell'indirizzo completo per IDENT1.
c. Per una richiesta di deviazioni per terzi (cioe' RQT con FALG2=1):
un messaggio AHYC che da' istruzione all'unita' di inviare
l'indirizzo bloccato.
Per il ritardo accettabile, vedi 7.2.4. Vedi anche da 12.1.3 a
12.1.5.
12.1.3 Istruzione per inviare informazioni con indirizzamento esteso.
Dopo aver ricevuto un messaggio RQT con un indirizzamento esteso, il
TSC puo' richiedere l'informazione dell'indirizzo completo per IDENT1
inviando il messaggio a AHYC, con:
- gli stessi prefissi e identificativi come nel messaggio RQT, ad
esempio IDENT1 fissato a IPFIXI, PABXI e PFIX/IDENT2 fissato
all'indirizzo dell'unita' richiedente).
- DESC fissato per indicare appropriato *gateway* (vedi 5.5.3.2.8).
- SLOTS fissato al valore corrispondente del RQT. (cioe' SLOTS='01').
Il messaggio AHYC da' istruzione alla *unita' radio* richiedente di
inviare le informazioni complete dell'indirizzo per IDENT1
nelsuccessivo(i)SLOT (vedi 9.2.2.1). Se il TSC non decodifica con
successo le informazioni dell'indirizzo, puo' ripetere il messaggio
AHYC o trasmettere ACKV (QUAL=0) per indicare l'insuccesso della
transazione.
12.1.4 Istruzioni per inviare l'indirizzo bloccato.
Dopo aver ricevuto una richiesta di deviazione per terzi (per esempio
FLAG2=1), il TSC puo' richiedere l'indirizzo bloccato inviando il
messaggio AHYC con:
- IDENT1 fissato a DIVERTI
- PFIX/IDENT2 fissato all'indirizzo dell'unita' richiedente
- DESC fissato a '000'
- SLOTS fissato a '01'.
Il messaggio AHYC da' istruzione alla *unita' radio* richiedente di
inviare l'indirizzo bloccato nello slot successivo (vedi 9.2.2.1). Se
il TSC non decodifica con successo le informazioni dell'indirizzo,
puo' ripetere il messaggio AHYC o trasmettere ACKV (QUAL=0) per
indicare il fallimento della transazione.
12.1.5 Riscontri inviati per modificare la progressione di una
transazione RQT.
Il TSC puo' inviare i seguenti messaggi di riscontro, con lo stesso
prefisso e identificativi come nel RQT, per indicare alla *unita' ra-
dio* la progressione della propria transazione di deviazione. (Per
una richiesta di deviazione complessa, ACK (QUAL=0) non e'
appropriato fino a quando tutte le informazioni di deviazione non
sono state ottenute).
ACKI (QUAL=1) - Riscontro intermedio; ulteriore segnalazione
seguira'.
ACKX (QUAL=0) - Chiamata non valida ad esempio richiesta di
deviazione non autorizzata, o TSC non provvede la deviazione di
chiamata.
ACKX (QUAL=1) - Sovraccarico del sistema, richiesta respinta.
ACKV (QUAL=0) - Transazione abbandonata.
ACK (QUAL=0) - La deviazione o cancellazione di chiamata e' stata
accettata.
Per il massimo ritardo accettabile di ripetizione dei riscontri ACKX,
ACKV e ACK, vedi il tempo limite TB in 12.2.4.
12.1.6 Cancellazione dell'operazione.
Una *unita' radio* puo' cancellare le operazioni per la propria
deviazione generando un messaggio RQX (vedi 5.5.3.1.3), conforme al
protocollo ad accesso casuale. Alla ricezione di un messaggio RQX che
cancella la transazione di deviazione, il TSC inviera' una risposta:
ACK (QUAL=1) con gli stessi prefissi e identificativi come nel RQX.
12.1.7 Tempo limite del TSC.
Il TSC puo' dare istruzione ad una *unita' radio* di far ripartire il
suo temporizzatore di attesa TJ, inviando un messaggio AHY con il bit
POINT fissato a '1' (e lo stesso prefisso ed identificativi come nel
RQT); vedi 9.1.1.7 e 9.2.2.3. Se il tempo TJ, meno le tolleranze del
temporizzatore della *unita' radio*, passa senza che l'ultimo
messaggio sia stato ricevuto per la transazione di deviazione, il TSC
non inviera' alcuna ulteriore segnalazione per la transazione. Vedi
anche 12.2.5.
12.2 Procedura per una *unita' radio* che richiede una deviazione di
chiamata.
Una *unita' radio* fara' un solo tentativo di chiamata alla volta
(escluso quando e' in emergenza); mentre sta tentando l'accesso o e'
in attesa di un riscontro conclusivo (cioe' la fine dell'operazione)
alla sua richiesta di deviazione, l'unita' non richiedera' un'altra
chiamata, con esclusione di quella di emergenza, di qualsiasi tipo (
a meno che l'utente prima cancelli la transazione originale).
12.2.1 Richiesta di deviazione.
Una *unita' radio* richiede o cancella la deviazione di chiamata
trasmettendo un messaggio RQT sul canale di controllo, conforme con
l'accesso al protocollo casuale (vedi 7.3). I campi nel messaggio RQT
saranno fissati appropriatamente (vedi 5.5.3.1.4); tuttavia notare in
particolare che:
a. Il bit DIV specifica se l'unita' sta richiedendo una deviazione di
chiamata o una cancellazione di deviazione di chiamata.
b. Il bit FLAG2 specifica se devono essere inviati tre indirizzi.
c. Una richiesta di deviazione con indirizzamento esteso e' indicata
fissando IDENT1 nel messaggio RQT al valore identificativo
dell'appropriato *gateway* , ad esempio IPFIXI, PABXI.
(Nota che procedure di indirizzamento esteso sono usate per
richiedere deviazione ad un'estensione PABX sia per un'estensione con
numero "breve" che "esteso").
L'unita' tentera' di accedere fino a quando una risposta valida (vedi
12.2.2/3), o fino a quando l'utente cancella la transazione (vedi
12.2.6), o fino a quando il tentativo di accesso fallisce (ad esempio
l'unita' ha inviato il numero massimo di transazioni NR e non ha
ricevuto risposta, o il tempo di accesso TC e' scaduto (vedi 7.3.8).
Nel caso di fallimento nell'accesso, se l'unita' non ha inviato una
richiesta, deve ritornare allo stato di riposo (e puo' indicare il
fallimento all'utente); altrimenti deve aspettare ulteriori
segnalazioni per l'operazione - vedi 12.2.4 e 12.2.5.
12.2.2 Risposta a una richiesta di deviazione semplice.
Per una richiesta di deviazione semplice, la *unita' radio*
accettera' i seguenti messaggi (con gli stessi prefissi e
identificativi come nel RQT) come una risposta valida al proprio RQT
e non inviera' ulteriori richieste:
ACKI (QUAL=1), ACKX, ACKV (QUAL=0) oppure ACK (QUAL=0)
Per altre azioni alla ricezione di questi messaggi vedi paragrafo
12.2.4.
12.2.3 Risposta a una richiesta di deviazione complessa.
Per una richiesta di deviazione complessa, la *unita' radio*
accettera' i seguenti messaggi come risposta valida al proprio RQT e
non inviera' ulteriori richieste:
a. ACKI (QUAL=1), ACKX o ACKV (QUAL=0), con lo stesso prefisso e
identificativi come nel RQT.
b. Per una RQT con indirizzamento esteso: AHYC, con gli stessi
prefissi e identificativi come nella RQT.
c. Per una richiesta di deviazione per terzi (cioe' RQT con FLAG2=1):
AHYC, con PFIX/IDENT2 come il proprio indirizzo individuale e IDENT1
come DIVERTI.
Per altre azioni alla ricezione di questi messaggi vedi 12.2.4 e
9.2.2.1.
12.2.4 Riscontri ricevuti.
Se mentre una *unita' radio* sta tentando l'accesso o sta aspettando
ulteriore segnalazione per una transazione di deviazione, riceve un
riscontro appropriato (con gli stessi prefissi e identificativi come
nel RQT) allora prendera' dei provvedimenti come indicato. Per una
richiesta di deviazione complessa ACK (QUAL=0) non e' appropriato
fino a quando tutte le informazioni di deviazione sono state inviate.
ACKI (QUAL=0) - Riscontro intermedio; seguira' altra segnalazione
ACKX (QUAL=0) - Chiamata non valida; richiesta respinta
ACKV (QUAL=0) - Transazione abbandonata
ACK (QUAL=0) - La deviazione o la cancellazione di deviazione della
chiamata e' stata accettata.
Se ACKI (QUAL=1) viene ricevuto l'unita' deve aspettare una ulteriore
segnalazione per la transazione.
Se ACKX o ACKV (QUAL=0) viene ricevuto l'unita' deve ritornare allo
stato di riposo e puo' indicare all'utente che la transazione non ha
avuto successo.
Se ACK (QUAL=0) viene ricevuto, l'unita' deve ritornare allo stato di
riposo e puo' indicare all'utente che la richiesta per la deviazione
di chiamata o la cancellazione e' stata accettata.
Dopo aver ricevuto ACKX, ACKV o ACK per la richiesta di deviazione,
l'unita' non richiedera' altre chiamate di qualsiasi tipo allo stesso
identificativo di utente chiamato (*gateway*) per almeno un tempo
uguale a TB, con esclusione delle chiamate d'emergenza.
12.2.5 Tempo limite di attesa.
Una *unita' radio* in attesa di ulteriore segnalazione per
transazione di deviazione deve ritornare allo stato di riposo se il
tempo di TJ e' passato da quando ha inviato l'ultimo messaggio per la
transazione cioe':
RQT, richiedente la transazione (vedi 12.2.1)
o SAMIS, fornente le informazioni di indirizzo per la chiamata (vedi
9.2.2.1)
o ACK (QUAL=0), inviato in risposta a un messaggio AHY con il bit
POINT=1 e gli stessi prefissi e identificativi come nel RQT (vedi
9.2.2.3).
Puo' anche indicare all'utente che il risultato della transazione e'
sconosciuto.
12.2.6 Cancellazione della transazione.
Una *unita' radio* puo' cancellare una transazione di deviazione
(dopo aver inviato un RQT e mentre sta aspettando di ricevere ACKX,
ACKV oppure ACK) trasmettendo una richiesta di cancellazione della
transazione RQX (vedi 5.5.3.1.3), conforme al protocollo ad accesso
casuale. Tentera' di accedere fino a che uno dei seguenti eventi
accade:
a. Riceve ACK (QUAL=1) con gli stessi prefissi ed identificativi come
nel RQX. In questo caso, puo' indicare all'utente che il risultato
della transazione e' sconosciuto.
b. Riceve ACK (QUAL=0), ACKX o ACKV (QUAL=0) per la transazione che
sta tentando di cancellare. Vedi anche 12.2.4.
c. Ha inviato il massimo numero di trasmissioni NR e non ha ricevuto
risposta o il tempo limite di accesso TC e' passato (vedi 7.3.8). In
questo caso dovra' tornare ad attendere la segnalazione per la
transazione di deviazione (vedi 12.2.4 e 12.2.5).
Nei casi a. e b. l'unita' tornera' allo stato di riposo.
13. PROCEDURE PER I MESSAGGI DI STATO
Questo capitolo definisce le procedure per i messaggi di stato. I
messaggi di stato possono essere inviati al TSC o a *unita' radio* o
a *terminali d'utente a connessione diretta*.
Una *unita' radio* invia le informazioni di stato usando il messaggio
RQQ - vedi 5.5.3.1.7. Il campo statu nel messaggio RQQ consiste di 5
bit, permettendo 32 valori differenti di stato. Due di questi valori
sono gia' predefiniti.
a) Per stati inviati al TSC:
'0000' indica che l'unita' e' disponibile a ricevere una chiamata (ad
esempio indica lo sgancio o equivalente)
'00001' a '11110' sono valori di stato definiti a livello sistema.
'11111' indica che l'unita' non e' piu' disponibile a ricevere una
chiamata (ad esempio indica il riaggancio o equivalente).
RQQ ('00000') e RQQ ('11111') sono usati per il meccanismo di
"Risposta dell'utente chiamato" vedi paragrafo 9.2.2.2. Se una
*unita' radio* riceve AHY (CHECK=1) che l'avvisa di una chiamata
entrante e risponde con ACKI (QUAL=0), puo' tentare un accesso
casuale RQQ ('00000') quando il proprio utente o apparecchiatura dati
e' disponibile a ricevere la chiamata. Negli altri casi, se l'utente
non desidera piu' ricevere la chiamata, l'unita' puo' informare il
TSC usando RQQ ('11111').
Il valore degli altri 30 stati possono essere usati per inviare
informazione di stato come precedentemente concordato con il sistema.
b) Per stati inviati alle *unita' radio* o *terminali d'utente a
connessione diretta*.
'00000' richiede che l'unita' indirizzata richiami con una chiamata
per conversazione.
'00001' a '11110' sono valori di stato definiti dall'utente.
'11111' cancella una richiesta di chiamata per conversazione inviata
precedentemente.
Per esempio RQQ ('00000') puo' essere usato per richiedere "una
chiamata accodata a un dispacciatore". In questo tipo di chiamata,
una *unita' radio* invia RQQ ('00000') per richiedere che il
dispacciatore indirizzato sia informato che l'unita' desidera che il
dispacciatore lo chiami per una chiamata per conversazione. Il TSC
dirige le informazioni all'unita' di dispaccio che tiene una lista
delle chiamate richieste. Il dispacciatore puo' allora richiedere
ogni chiamata nella maniera piu' comoda e nel modo casuale; per
esempio se la sua unita' e' una *unita' radio* invia una richiesta di
chiamata semplice RQS (vedi 5.5.3.1.1 e 9.2.1).
RQQ ('11111') e' usato per cancellare una precedente richiesta di
chiamata dalla coda delle chiamate dell'unita' indirizzata. Questo
puo' essere usato per cancellare la richiesta di chiamata sia:
i) dopo che l'unita' chiamata ha accettato un messaggio RQQ
('00000'), oppure
ii) dopo che l'unita' chiamata in una RQS o RQE ha accettato una
chiamata con avviso di richiamare (inviando ACKB (QUAL=0)) inrisposta
ad una verifica di disponibilita'); vedi 9.2.1.4 e 9.2.2.2.
Gli altri 30 valori di stato possono essere usati per inviare
informazioni di stato, come precedentemente concordato tra l'utente
richiedente e l'utente chiamato.
Il TSC informa una *unita' radio* chiamata di una informazione di
stato usando il messaggio AHYQ - vedi 5.5.3.2.7. Il messaggio di
stato puo' essere stato generato all'interno del TSC, da un'altra
*unita' radio* (usando RQQ ecc. ecc.) o da un *terminale d'utente a
connessione diretta*
Le procedure per messaggi di stato indirizzate a TSC sono simili ad
un sottosistema delle procedure per i messaggi di stato indirizzati
ad una *unita' radio* o a postazione radio base di dispaccio.
Tuttavia, per chiarezza sono state specificate separatamente:
- il paragrafo 13.1 specifica le procedure per messaggi di stato
indirizzati al TSC.
- il paragrafo 13.2 specifica le procedure per messaggi di stato
indirizzati a *unita' radio* o *terminale d'utente a connessione
diretta*
Una sequenza tipica di messaggio per una *unita' radio* che invia un
messaggio di stato ad un'altra *unita' radio* (con lo stesso
prefisso) e' illustrata nell'esempio sotto.
1 slot
| 1 | | 3 | | 5 | |
da TSC | ALH | ALH | AHYQ | ALH | ACK | ACK |
alle RUs | (1) | (1) | | (1) | (1) | (1) |
| | | | | | |
| | 2| | 4| | | |
dalle RU | | RQQ | | ACK | | | |
al TSC s | | | | | | | |
| | | | | | | |
| | | | | | | | | |
trama trama trama trama trama
Esempio Una sequenza di messaggi sul canale di controllo per una
*unita' radio* che invia un messaggio di stato ad una unita' radio
con lo stesso prefisso.
1. ALH: Invito generale di ALOHA (trama a slot singolo).
2. RQQ: Richiesta con accesso casuale di informazioni di stato che
devono essere trasmesse all'unita' chiamata.
3. AHYQ: messaggio di stato Ahoy:
- riscontro del messaggio RQQ
- invio delle informazioni alla *unita' radio* chiamata e richiesta
di una risposta.
4. ACK: riscontro ACK (QUAL=0) dalla *unita' radio* chiamata -
informazione accettata.
5. ACK: riscontro ACK (QUAL=0) inviato alla unita' chiamante per
indicare che l'unita' chiamata ha accettato la informazione.
In questo esempio il TSC ripete immediatamente il messaggio ACK, per
migliorare l'affidabilita'.
13.1 Procedure per messaggi di stato indirizzati a TSC.
13.1.1 Procedure del TSC per messaggi indirizzati a se stesso.
13.1.1.1 Risposta a un messaggio RQQ indirizzato a TSC.
Una *unita' radio* invia informazioni di stato al TSC generando un
RQQ message (con IDENT1=TSC), conforme al protocollo ad accesso
casuale.
Alla ricezione di un messaggio RQQ indirizzato ad esso, il TSC
inviera' una delle seguenti risposte:
a. ACK (QUAL=0), ACKI (QUAL=1) oppure ACKX, con lo stesso prefisso ed
identificativi come nel RQQ.
b. Per STATUS = '00000' oppure STATUS = '11111':
- un messaggio AHYX con lo stesso prefisso e identificativi come nel
messaggio di avviso AHX.
- un messaggio GTC per la chiamata originale (cioe' GTC con gli
stessi prefisso, identificativi e bit D come nel messaggio di avviso
AHY).
Per il ritardo accettabile vedi 7.2.4. Vedi anche 13.1.1.2, 9.1.1.8 e
9.1.1.12.
13.1.1.2 Riscontri inviati per indicare la progressione di una
transazione di RQQ.
Il TSC puo' inviare i seguenti messaggi di riscontro (con lo stesso
prefisso ed identificativi come nel RQQ) per indicare ad una *unita'
radio* l'avanzamento della sua transazione di stato:
ACKI (QUAL=1) - Riscontro intermedio; ulteriore segnalazione
seguira'.
ACKX (QUAL=0) - Chiamata non valida; messaggio respinto.
ACKX (QUAL=1) - Sovraccarico del sistema; messaggio respinto.
ACK (QUAL=0) - L'operazione e' stata completata con successo cioe' il
TSC ha accettato l'informazione di stato.
Per il ritardo massimo accettabile di ripetizione dei riscontri ACKX
e ACK, vedi tempo limite TB in 13.1.2.4.
13.1.1.3 Cancellazione dell'operazione.
Una *unita' radio* puo' cancellare la sua transazione di stato
generando un messaggio RQX (vedi 5.5.3.1.3), conforme al protocollo
ad accesso casuale. Alla ricezione di un messaggio di cancellazione
RQX di una transazione di stato, il TSC inviera' una risposta: ACK
(QUAL=1) con lo stesso prefisso e identificativi come nel RQX.
13.1.1.4 Tempo limite del TSC.
Il TSC puo' dare istruzione ad una *unita' radio* di far ripartire il
suo temporizzatore di attesa TJ, inviando il messaggio AHY con il bit
POINT fissato a '1' PFIX/IDENT2 fissato all'indirizzo individuale
dell'unita' e IDENT1 fissato a TSCI; vedi 9.1.1.7 e 9.2.2.3.
Se il tempo TJ (meno le tolleranze del temporizzatore dell'unita' ra-
dio) passa senza che un ultimo messaggio venga ricevuto per la
transazione di stato, il TSC non inviera' alcuna ulteriore
segnalazione per la transazione.
Vedi anche 13.1.2.5.
Vedi anche paragrafo 9.1.1.5, 13.1.2.7 e 13.1.2.8.
13.1.2 Procedure per *unita' radio* che inviano messaggi di stato al
TSC.
Una *unita' radio* fara' un solo tentativo di chiamata per volta
(eccetto in emergenza); mentre sta tentando l'accesso o aspettando un
riscontro conclusivo (cioe' fine transazione) ad un messaggio di
stato indirizzato al TSC, l'unita' non richiedera' un'altra chiamata
di non emergenza di qualsiasi tipo (a meno che l'utente prima
cancelli la transazione originale).
13.1.2.1 Criteri per l'invio dei messaggi di riaggancio e sgancio.
Se una *unita' radio* sul canale di controllo e' stata avvisata di
una chiamata in arrivo sul canale di traffico (vedi 9.2.2.2A), puo'
iniziare il meccanismo di risposta dell'utente chiamato, cioe'
tentando l'accesso casuale con RQQ (STATUS='00000') indirizzato al
TSC, se:
- la propria risposta all'ultimo messaggio di avviso AHY era ACKI
(QUAL=0), e
- l'utente o l'attrezzatura per l'invio dati e' ora pronta per
ricevere la chiamata, e
- e' ancora in attesa di una chiamata entrante, cioe' la chiamata,
non ha avuto luogo o e' stata cancellata (con AHYX o con un AHY per
una diversa chiamata) e non e' trascorso piu' del tempo TA dalla
ricezione dell'ultimo AHY per la chiamata; vedi 9.2.2.2A e 9.2.2.4.
Se una *unita' radio* e' stata avvisata di una chiamata in arrivo sul
canale di traffico e il proprio utente indica che non desidera piu'
ricevere la chiamata (ad esempio desidera iniziare una propria
chiamata) l'unita' puo' tentare di respingere la chiamata nei modi
seguenti:
a. Se sta tentando l'accesso o e' in attesa di inviare la
segnalazione per un RQQ di "sgancio", tentera' di inviare RQX (vedi
13.1.2.6).
b. In altri casi, se l'unita' sta aspettando una chiamata entrante,
tentera' un accesso casuale con RQQ (STATUS='11111') indirizzato al
TSC.
(Attraverso queste procedure l'unita' risponde ai messaggi AHY e
ubbidisce ai messaggi GTC come specificato nel paragrafo 9.2.2. Vedi
anche paragrafi 13.1.2.7 e 13.1.2.8).
13.1.2.2 Richiesta di invio del messaggio di stato al TSC.
Una *unita' radio* richiede la transazione di stato inviando un
messaggio RQQ sul canale di controllo, conformemente al protocollo ad
accesso casuale (vedi 7.3). I campi nel messaggio RQQ saranno fissati
nel modo appropriato (vedi 5.5.3.1.7).
L'unita' tentera' l'accesso fino a quando riceve una risposta valida
(vedi 13.1.2.3), o fino a quando l'utente cancella la transazione
(vedi 13.1.2.6), o fino a quando fallisce il tentativo d'accesso (ad
esempio l'unita' ha inviato il massimo numero NR di trasmissioni e
non riceve risposta, o il tempo massimo d'accesso TV e' terminato
(vedi 7.3.8)). Nel caso di fallimento nell'accesso, se l'unita' non
ha inviato la richiesta, deve ritornare allo stato di riposo (e puo'
indicare l'insuccesso all'utente); in altri casi, deve aspettare una
ulteriore segnalazione per la transazione - vedi 13.1.2.4, 13.1.2.5 e
13.1.2.7.
13.1.2.3 Risposte valide ad una RQQ indirizzata al TSC:
Una *unita' radio* accettera' i seguenti messaggi come una risposta
alla propria RQQ al TSC, e non inviera' ulteriori richieste:
a. Un riscontro ACK (QUAL=0), ACKI (QUAL=1) o ACKX con gli stessi
prefissi ed identificativi come nel RQQ.
b. Per STATUS = '00000' o STATUS = '11111':
- un messaggio AHYX con gli stessi prefisso ed identificativi come
nel "messaggio di allerta" AHY, o
- un messaggio GTC con gli stessi prefisso, identificativi e il bit D
come il "messaggio di allerta" AHY.
Per altre azioni alla ricezione di questi messaggi, vedi paragrafi
13.1.2.4 e 13.1.2.7. Vedi anche paragrafo 13.1.2.8.
13.1.2.4 Riscontri ricevuti.
Se una *unita' radio* che sta tentando l'accesso o e' in attesa di
ulteriore segnalazione per la transazione di stato al TSC riceve uno
dei seguenti riscontri (con gli stessi prefissi ed identificativi
come nel RQQ), allora si comportera' come indicato piu' avanti.
ACKI (QUAL=1) - Riscontro intermedio; seguira' ulteriore
segnalazione.
ACKX (QUAL=0) - Chiamata non valida; messaggio respinto.
ACKX (QUAL=1) - Sovraccarico del sistema; messaggio respinto.
ACK (QUAL=0) - La transazione e' stata completata con successo cioe'
il TSC ha accettato l'informazione di stato.
Se viene ricevuto ACKI (QUAL=1) , l'unita' attendera' ulteriori
segnalazioni per la transazione.
Se viene ricevuto ACKX. l'unita' deve ritornare allo stato di riposo
e puo' indicare all'utente che la trasmissione e' fallita.
Se viene ricevuto ACK (QUAL=0), l'unita' deve considerare la
transazione completata con successo e puo' indicarlo all'utente.
Dopo aver ricevuto ACKX o ACK per la transazione l'unita' non
richiedera' un'altra chiamata di qualsiasi tipo, escluso quelle di
emergenza, al TSC per almeno il tempo TB.
13.1.2.5 Tempo limite di attesa.
Una *unita' radio* in attesa di ulteriore segnalazione per la
transazione di stato al TSC ritornera' allo stato di riposo se il
tempo TJ e' passato da quando e' stato inviato l'ultimo messaggio per
la transazione, ad esempio:
RQQ, richiedente la transazione (vedi 13.1.2.2)
o ACK (QUAL=0), inviato in risposta a un messaggio AHY con il POINT=1
e IDENT1 fissato a TSCI (vedi 9.2.2.3).
Puo' anche indicare all'utente che il risultato della transazione e'
sconosciuto.
13.1.2.6 Cancellazione della transazione.
Se un utente desidera cancellare la transazione dopo che l'unita' ha
inviato un RQQ e mentre sta aspettando un riscontro conclusivo,
l'unita' tentera' di inviare una richiesta di cancellazione della
transazione RQX (vedi 5.5.3.1.3), conforme al protocollo ad accesso
casuale. Tentera' di accedere fino a quando uno dei seguenti eventi
accade:
a. Riceve ACK (QUAL=1) con gli stessi prefisso ed identificativi come
nella RQX.
b. Riceve ACK (QUAL=0) o ACKX per la transazione che sta tentando di
cancellare. Vedi anche 13.1.2.4.
c. Ha inviato il numero massimo di trasmissioni NR e non riceve
risposta, o il tempo limite di accesso TC e' scaduto (vedi 7.3.8).
In questo caso, ritornera' ad attendere la segnalazione per la
transazione di stato (vedi 13.1.2.4, 13.1.2.5 e 13.1.2.7).
D. Si verificano le condizioni specificate in 13.1.2.7 o 13.1.2.8
(applicabili soltanto per STATUS = '00000' e '11111').
Nei casi a. e b. l'unita' deve ritornare allo stato di riposo.
13.1.2.7 Ricezione di un AHYX o GTC per una chiamata in arrivo.
Se una *unita' radio*:
a. mentre sta tentando di accedere al protocollo o e' in attesa di un
riscontro conclusivo ad un messaggio di riaggancio o sgancio RQQ (o
STATUS = '00000' o '11111' ), o
b. sta tentando di cancellare una transazione di "sgancio o
riaggancio" RQQ
riceve AHYX con gli stessi prefisso ed identificativi come nel
messaggio di avviso AHY, rispondera' con ACK (QUAL=1), fermera' il
segnale di avviso (se necessario) e ritornera' allo stato di riposo;
vedi anche 9.2.2.4. Se riceve un messaggio GTC con lo stesso
prefisso, identificativi e bit D come nel messaggio di avviso AHY,
deve seguire le procedure riportate in 9.2.2.5 e ritornare allo stato
di riposo al termine della chiamata.
13.1.2.8 Ricezione di un AHY per una differente chiamata in arrivo.
Se mentre una *unita' radio*:
cms a. sta tentando l'accesso al protocollo o e' in attesa di un
riscontro conclusivo ad un messaggio di "riaggancio" o "sgancio" RQQ
(STATUS = "00000" o "11111" ), o
b. sta tentando di cancellare la transazione di "sgancio o
riaggancio" RQQ
riceve un messaggio AHY che verifica la sua disponibilita' per una
differente chiamata in arrivo su un canale di traffico (cioe' bit D
e/o bit e/o l'indirizzo del chiamante sono differenti dal messaggio
di avviso AHY), allora l'unita' riterra' che la chiamata precedente
non ha avuto luogo e abbandonera' la transazione RQQ (senza inviare
RQX). Seguira' anche le procedure in 9.2.2.2A per la nuova chiamata.
13.2 Procedure per messaggi di stato indirizzati a *unita' radio* o a
*terminali d'utente a connessione diretta*
13.2.1 Procedure del TSC per messaggi di stato a *unita' radio* o a
*terminali d'utente a connessione diretta*
13.2.1.1 Risposta a un messaggio RQQ con indirizzamento breve.
Una *unita' radio* richiede che un'informazione di stato venga
inviata ad una unita' con lo stesso prefisso generando un messaggio
RQQ, conforme al protocollo ad accesso casuale. Alla ricezione di un
messaggio RQQ con prefisso comune, il TSC inviera' una delle seguenti
risposte:
a. ACK (QUAL=0), ACKI (QUAL=1), ACKQ, ACKX o ACKV, con lo stesso
prefisso e identificativi come nel RQQ.
b. ACKT (QUAL=0), con PFIX/IDENT2 come l'indirizzoindividuale
dell'unita' chiamante.
c. Un messaggio AHYQ per questa transazione.
Per il ritardo accettabile vedi 7.2.4. Vedi anche 13.2.1.4. e
13.2.1.5.
13.2.1.2 Risposta a un messaggio RQQ con indirizzamento esteso.
Una *unita' radio* richiede che le informazioni di stato siano
inviate ad una unita' con prefisso diverso generando un messaggio RQQ
(con IDENT1=IPFIXI), conformemente al protocollo ad accesso casuale.
Alla ricezione di un messaggio RQQ interprefisso, il TSC inviera' una
delle seguenti risposte, con lo stesso prefisso e identificativi come
nel RQQ:
a. Un riscontro ACKI (QUAL=1), ACKX o ACKV (QUAL=0)
b. AHIC (cioe' un'istruzione per inviare l'indirizzo dell'unita'
chiamata).
Per il ritardo accettabile vedi 7.2.4, vedi anche 13.2.1.3. e
13.2.1.4.
13.2.1.3 Istruzione per inviare le informazioni di un indirizzo
esteso.
Dopo aver ricevuto un messaggio RQQ interprefisso il TSC potra'
richiedere l'indirizzo dell'unita' chiamata dalla *unita' radio*
chiamante inviando il messaggio AHYC (con lo stesso prefisso e
identificativi come nel RQQ, il campo DESC fissato a '000' e il campo
SLOTS fissato a'01').
Il messaggio AHYC da' istruzione all'unita' chiamante di inviare
l'indirizzo del chiamato nello slot successivo (vedi 9.2.2.1). Se il
TSC non decodifica con successo le informazioni di indirizzo, puo'
ripetere il messaggio AHYC o trasmettere ACKV (QUAL=0) per indicare
il fallimento della transazione.
13.2.1.4 Riscontri inviati per indicare la progressione di una
transazione RQQ.
Il TSC puo' inviare messaggi di riscontro per indicare alla *unita'
radio* chiamante l'avanzamento del proprio messaggio di stato - per
identificativi vedi 5.5.2.1. (Per RQQ interprefisso, ACKI (QUAL=1),
ACKX e ACKV (QUAL=0) sono appropriati fino a quando l'informazione di
indirizzo completa non e' stata ottenuta).
ACKI (QUAL=0) - Riscontro intermedio; seguira' ulteriore
segnalazione.
ACKQ (QUAL=0) - Il sistema e' occupato. Attendere la ulteriore
segnalazione
ACKQ (QUAL=1) - L'unita' chiamata e' occupata. Attendere la ulteriore
segnalazione.
ACKX (QUAL=0) - Chiamata non valida, ad esempio il sistema non tratta
messaggi di stato, o l'unita' chiamata e' un indirizzo di gruppo, o
l'unita' chiamata non e' equipaggiata per accettare l'informazione.
ACKX (QUAL=1) - Il sistema o l'unita' chiamata sono in sovraccarico;
messaggio respinto.
ACKV (QUAL=0) - L'unita' chiamata non e' in contatto radio o la
transazione e' stata abbandonata.
ACKV (QUAL=1) - L'unita' chiamata e' occupata (e il TSC non memorizza
la richiesta) o l'unita' chiamata non desidera accettare
l'informazione.
ACKT (QUAL=0) - Le chiamate all'unita' chiamata sono state deviate.
ACK (QUAL=0) - La transazione e' stata completata con successo cioe'
l'unita' chiamata ha accettato l'informazione di stato.
Per il ritardo massimo accettabile delle ripetizioni dei riscontri
ACKX, ACKV, ACKT e ACK vedi tempo limite TB in 13.2.2.4.
13.2.1.5 Informazioni alla *unita' radio* chiamata.
Il TSC informa una *unita' radio chiamata della informazione di stato
inviando il messaggio AHYQ (vedi 5.5.3.2.7). Il messaggio di stato
puo' essere originato dallo stesso TSC, o da una *unita' radio*
(usando RQQ ecc. ecc.) o da un *terminale d'utente a connessione
diretta* .
Per un messaggio di stato interprefisso IDENT2 nella parola di codice
indirizzo AHYQ e' fissato a IPFIXI e una parola di codici dati viene
inviata successivamente contenente l'indirizzo dell'unita' chiamata.
Il messaggio AHYQ richiede una risposta dalla unita' chiamata (vedi
13.2.3). Se la risposta e' ACK (QUAL=0), ACKX o ACKV (QUAL=1), il TSC
puo' inviare un riscontro (i) appropriato alla *unita' radio*
chiamante (vedi 13.2.1.4). Se il TSC non decodifica con successo la
risposta o la risposta e' ACKB (QUAL=1), puo' ripetere il messaggio
AHYQ. Se l'unita' chiamata non puo' essere messa in contatto, il TSC
puo' indicare l'insuccesso all'unita' chiamante inviando ACKV
(QUAL=0).
13.2.1.6 Cancellazione dell'invio del messaggio.
Una *unita' radio* chiamante puo' cancellare la sua transazione di
stato generando un messaggio RQX (vedi 5.5.3.1.3), conformemente al
protocollo ad accesso casuale. Alla ricezione di un messaggio di
cancellazione RQX di un operazione di invio del messaggio di stato,
il TSC inviera' una risposta:
ACK (QUAL=1) con gli stessi prefissi e identificativi come nel RQX.
Se RQX cancella una richiesta per una chiamata per conversazione
(cioe' RQQ (STATUS='00000')) e il TSC ha gia' informato l'unita'
chiamata richiesta di una chiamata, puo' informare l'unita' chiamata
della cancellazione inviando AHYQ con STATUS='11111'.
13.2.1.7 Tempo limite del TSC.
Il TSC puo' introdurre un limite sul tempo massimo con cui memorizza
la richiesta del messaggio di stato (per esempio, aspettando che
l'unita' chiamata diventi libera).
Il TSC puo' dare istruzione a una *unita' radio* chiamante di far
ripartire il suo temporizzatore di attesa TW, inviando un messaggio
AHY con il bit POINT fissato a '1'; vedi 9.1.1.7 e 9.2.2.3. Se un
tempo TW, meno la tolleranza del temporizzatore della *unita' radio*
, scade senza che venga ricevuto l'ultimo messaggio per la
transazione di stato (dall'unita' chiamante), il TSC non inviera'
altra segnalazione per la transazione. Vedi anche 13.2.2.5.
13.2.2 Procedure per una *unita' radio* inviante messaggi di stato a
un'altra *unita' radio* o a un *terminale d'utente a connessione
diretta* .
Una *unita' radio* effettuera' soltanto un tentativo di chiamata alla
volta (eccetto emergenza) mentre sta tentando l'accesso o aspettando
un riscontro conclusivo (cioe' un fine transazione)ad una richiesta
di un messaggio di stato, l'unita' non richiedera' un'altra chiamata
di non emergenza di qualsiasi tipo (a meno che l'utente prima
cancelli la transazione originale).
13.2.2.1 Richiesta di invio di un messaggio di stato a una *unita'
radio* o a un *terminale d'utente a connessione diretta* .
Una *unita' radio* richiede una transazione di stato inviando un
messaggio RQQ sul canale di controllo, conformemente al protocollo ad
accesso casuale (vedi 7.3). I campi nel messaggio RQQ saranno fissati
appropriamente (vedi 5.5.3.1.7); tuttavia notare che in particolare
una richiesta interprefisso e' indicata fissando IDENT1 a IPFIXI.
(Notare anche che messaggi di stato non possono essere inviati a un
gruppo).
L'unita' tentera' l'accesso fino a quando riceve una risposta valida
(vedi 13.2.2.2/3), o fino a quando il proprio utente cancella la
transazione (vedi 13.2.2.6), o fino a quando il tentativo d'accesso
fallisce (ad esempio la unita' ha inviato il massimo numero di
trasmissioni NR e non riceve risposta, o il proprio tempo limite TC
e' scaduto (vedi 7.3.8)). Nel caso di fallimento nell'accesso, se
l'unita' non ha inviato la richiesta, deve ritornare allo stato di
riposo (e puo' indicare il fallimento all'utente); negli altri casi
deve aspettare una ulteriore segnalazione per la transazione - vedi
13.2.2.4 e 13.2.2.5.
13.2.2.2 Risposte valide a RQQ con indirizzamento breve.
Per un RQQ con prefisso comune, l'unita' chiamante accettera' i
seguenti messaggi come risposta al proprio RQQ e non inviera'
ulteriori richieste:
a. un riscontro ACK (QUAL=0), ACKI (QUAL=1), ACKQ, ACKX o ACKV, con
gli stessi prefissi ed identificativi come nel messaggio RQQ:
b. un riscontro ACKT (QUAL=0) con PFIX/IDENT2 come proprio indirizzo
individuale. Vedi anche 13.2.2.4.
c. un messaggio AHYQ con gli stessi prefissi ed identificativi e
campo STATUS come nel messaggio RQQ.
Per altre azioni alla ricezione di questi messaggi, vedi paragrafo
13.2.2.4
13.2.2.3 Risposte valide ad una RQQ con indirizzamento esteso.
Per un RQQ interprefisso, l'unita' chiamante accettera' i seguenti
messaggi (con gli stessi prefissi ed identificativi come nel RQQ)
come una risposta al proprio RQQ e non inviera' ulteriori richieste:
a. Un riscontro ACKI (QUAL=1), ACKX o ACKV (QUAL=0)
b. AHYC (cioe' un istruzione per inviare l'indirizzo dell'unita'
chiamata).
Per altre azioni alla ricezione di questi messaggi vedi 13.2.2.4 e
9.2.2.1.
13.2.2.4 Riscontri ricevuti
Se una *unita' radio* mentre sta tentando l'accesso o e' in attesa di
ulteriori segnalazioni per la transazione di stato, riceve un
appropriato riscontro allora si comportera' come sotto indicato.
Per RQQ interprefisso, soltanto ACKI (QUAL=1) ACKX e ACKV (QUAL=0)
sono appropriati fino a quando l'informazione completa d'indirizzo
non viene inviata. Per gli identificativi vedi 5.5.2.1.
ACKI (QUAL=1) - Riscontro intermedio, seguira' ulteriore
segnalazione.
ACKQ (QUAL=0) - Il sistema e' occupato; attendere la ulteriore
segnalazione.
ACKQ (QUAL=1) - L'unita' chiamata e' occupata. Attendere la ulteriore
segnalazione.
ACKX (QUAL=0) - Chiamata non valida, messaggio respinto.
ACKX (QUAL=1) - Il sistema o l'unita' chiamata sono in sovraccarico.
ACKV (QUAL=0) - L'unita' chiamata non e' in contatto radio o la
transazione e' stata abbandonata.
ACKV (QUAL=1) - L'unita' chiamata e' occupata (e il TSC non memorizza
la richiesta) o l'unita' chiamata non desidera accettare
l'informazione.
ACKT (QUAL=0) - Le chiamate per l'unita' chiamata sono state deviate.
ACK (QUAL=0) - La transazione e' stata completata con successo cioe'
l'unita' chiamata ha dato conferma della ricezione dell'informazione
di stato.
Se viene ricevuto ACKI (QUAL=1) o ACKQ, l'unita' deve aspettare una
ulteriore segnalazione e puo' indicare all'utente la progressione
della transazione.
Se viene ricevuto ACKX o ACKV, l'unita' deve ritornare allo stato di
riposo e puo' indicare all'utente la ragione dell'insuccesso della
transazione; si raccomanda che la ricezione di ACKX (QUAL=0) venga
indicata in maniera differente.
Se viene ricevuto un messaggio completo ACKT (QUAL=0), l'unita'
potra' sia:
a. ritornare allo stato di riposo (e puo' indicare all'utente che le
chiamate all'unita' chiamate sono state deviate), sia
b. tentare una nuova transazione di stato all'indirizzo deviato
fornito nel messaggio ACKT.
Notare che, se IDENT1=IPFIXI nella parola di indirizzo AKT e il bit
GF=1 nella parola di codice dati successiva, l'indirizzo deviato e'
un indirizzo di gruppo; in questo caso; una transazione di stato
all'indirizzo deviato potrebbe generare una chiamata non valida.
Se viene ricevuto il messaggio ACKT (QUAL=0) incompleto allora:
i) Se l'unita' non richiede l'indirizzo di deviazione, deve ritornare
allo stato di riposo (e puo' dare indicazioni all'utente).
ii) Se l'unita' richiede l'indirizzo deviato allora:
- se sta ancora tentando di accedere per transazione, ignorera' il
messaggio ricevuto e continuera' il tentativo d'accesso.
- negli altri casi deve aspettare una la ripetizione di ACKT,
ritornando allo stato di riposo se scade un tempo TB (in questo caso
puo' indicare l'insuccesso dell'utente).
Se viene ricevuto ACK (QUAL=0), l'unita' deve ritornare allo stato di
riposo e puo' indicare all'utente che la transazione e' stata
completata con successo cioe' l'unita' chiamata ha accettato
l'informazione. (Notare che questo non implica un'accettazione del
messaggio dell'utente).
Dopo la ricezione di un ACKX, ACKV o ACK per la transazione, l'unita'
non richiedera' un'altra chiamata di qualsiasi tipo allo stesso
identificativo chiamato (o *gateway*) per almeno il tempo TB, con
esclusione delle chiamate d'emergenza. Dopo la ricezione di ACKT per
la transazione, l'unita' non richiedera' un'altra chiamata, escluso
quelle d'emergenza, di qualsiasi tipo per almeno un tempo TB.
13.2.2.5 Tempo limite di attesa.
Una *unita' radio* chiamante in attesa di ulteriore segnalazione per
una transazione di stato ad una *unita' radio* o ad un *terminale
d'utente a connessione diretta* ritornera' allo stato di riposo se
passa un tempo TW da quando ha inviato l'ultimo messaggio per
l'operazione, cioe':
RQQ richiedente la transazione (vedi 13.2.2.1)
o SAMIS, che fornisce l'informazione d'indirizzo esteso per la
chiamata (vedi 9.2.2.1)
o ACK (QUAL=0), inviato in risposta ad un messaggio AHY con il bit
POINT=1 e IDENT/1 come identificativo del chiamato o *gateway* (vedi
9.2.2.3).
Puo' indicare anche all'utente che il risultato della transazione e'
sconosciuto.
13.2.2.6 Cancellazione della transazione.
Se l'utente desidera cancellare la transazione dopo che l'unita' ha
inviato un RQQ e mentre e' ancora in attesa di un riscontro
conclusivo, l'unita' tentera' di inviare una richiesta di
cancellazione della transazione RQX (vedi 5.5.3.1.3), conformemente
al protocollo ad accesso casuale. Tentera' l'accesso fino a quando
uno dei seguenti eventi accade:
a. Riceve ACK (QUAL=1) con lo stesso prefisso e identificativi come
nel RQX. In questo caso puo' indicare all'utente che il risultato
della transazione e' sconosciuto.
b. Riceve ACK (QUAL=0) ACKX, ACKV o ACKT (QUAL=0) per la transazione
che sta tentando di cancellare. (Vedi anche 13.2.2.4).
c. Ha inviato il massimo numero di trasmissioni NR e non riceve
risposta, o il tempo limite d'accesso TC e' scaduto (vedi 7.3.8). In
questo caso, ritornera' ad attendere la segnalazione per la
transazione di stato (vedi 13.2.2.4 e 13.2.2.5).
Nei casi a. e b. , l'unita' deve ritornare allo stato di riposo.
13.2.3 Procedure per tutte le *unita' radio* sul canale di controllo.
Le procedure in questo paragrafo devono essere osservate da tutte le
*unita' radio* che sono equipaggiate per riconoscere una parola
d'indirizzo AHYQ (Il requisito di riconoscimento AHYQ potra' essere
dipendente dal sistema).
13.2.3.1 Ricezione di un messaggio di stato AHYQ.
Se una *unita' radio* sul canale di controllo riceve un messaggio
AHYQ con PFIX/IDENT2 corrispondenti al proprio indirizzo individuale
allora rispondera' con gli appropriati riscontri (vedi sotto), con
gli stessi prefissi ed identificativi come nel AHYQ. Se IDENT2
(cancelletto) IPFIXI nel messaggio AHYQ, l'unita' rispondera' nello
"slot" seguente AHYQ, se IDENT2=IPFIXI, e' aggiunta una parola di
codice dati (contenente l'indirizzo del chiamante) e l'unita'
rispondera' nello "slot" seguente la parola di codice dati. Per la
temporizzazione vedi 6.2.1.3.
a. Se l'unita' non e' equipaggiata per accettare l'informazione
allora inviera' ACKX (QUAL=0)
b. Negli altri casi, l'unita' inviera' uno dei seguenti riscontri:
ACKB (QUAL=1) se IDENT2=IPFIXI nel messaggio AHYQ, ma la parola di
codice dati aggiunta non era decodificabile e l'unita' richiede che
il messaggio venga ritrasmesso.
o ACKX (QUAL=1) se non puo' accettare l'informazione in quel momento
ad esempio STATUS='00000' nel messaggio AHYQ la coda dell'unita'
chiamata e' piena.
o ACKV (QUAL=1) se non desidera accettare l'informazione di stato
dallo *utente* chiamante.
o ACK (QUAL=0) se ha accettato l'informazione del messaggio AHYQ.
14. PROCEDURE PER I MESSAGGI DATI BREVI
Questa sezione definisce le procedure per messaggi dati brevi fino a
184 bit in formato libero, trasmessi sul canale di controllo. I dati
sono contenuti in un massimo di 4 parole di codice dati, aggiunte ad
una parola di codice indirizzo (HEAD).
Una *unita' radio* richiede di inviare il messaggio dati brevi usando
il messaggio RQC (vedi 5.5.3.1.8). Il TSC allora:
- da' istruzione all'unita' di inviare il messaggio dati breve (e le
informazioni dell'indirizzo esteso se necessario)
- invia il messaggio all'utente chiamato
- indica il risultato della transazione all'unita' chiamante.
Una *unita' radio* puo' inviare un messaggio dati breve al TSC o a
una *unita' radio* , o ad *terminale d'utente a connessione diretta*,
o ad un gruppo di unita', o a tutte le unita' del sistema, o ad una
estensione PABX (con indirizzamento breve o esteso)
Il TSC puo' anche trasmettere messaggi dati breve (indirizzati ad una
*unita' radio* , o ad un gruppo o a tutte le unita' nel sistema),
originati all'interno del TSC o da un *terminale d'utente a
connessione diretta*, o da una estensione PABX.
Per chiamate da *unita' radio* , il TSC usa il messaggio AHYC per
richiedere:
a. l'informazione dell'indirizzo chiamato, per chiamate a:
- indirizzi interprefissi
(se necessario vedi sotto)
- estensione PABX con numero "lungo"
b. il messaggio dati breve.
Se entrambi a. e b. sono necessari, il TSC ottiene l'informazione
completa in due passi, ogni passo usando il messaggio AHYC. I
messaggi AHYC sono distinti secondo come e' fissato IDENT1 (IPFIXI, o
PABXI, per a. o a SDMI per b.), e cosi' l'ordine in cui vengono
trasmessi non e' prescritto.
Notare che, quando una *unita' radio* invia il proprio messaggio dati
breve, fornisce l'indirizzo (prefisso/identificativo) della parte
chiamata nel messaggio di testa dei dati. Tuttavia per una chiamata
interprefisso, il TSC non ha bisogno di richiedere l'indirizzo del
chiamato separatamente a meno che lo richieda per semplicita'
dell'operazione.
Il formato dei dati all'interno del messaggio dati breve non
e'specificato. Inoltre possono essere richieste ulteriori specifiche
(dipendenti dal sistema) per definire:
- la temporizzazione per la ripetizione di messaggi, e/o
- la numerazione di messaggi dati
6. ACK: riscontro ACK (QUAL=0) dalla *unita' radio* chiamata -
messaggio dati accettato.
7. ACK: riscontro ACK (QUAL=0) inviato all'unita' chiamante per
indicare che l'unita' chiamata ha accettato il messaggio dati. In
questo esempio il TSC ripete il messaggio ACK, per migliorare
l'affidabilita'.
14.1 Procedure del TSC per messaggi dati brevi.
14.1.1 Risposte ad un messaggio RQC con indirizzamento breve.
Una *unita' radio* richiede di inviare un messaggio dati breve
generando un messaggio RQC conformemente al protocollo ad accesso
casuale. Alla ricezione di un messaggio RQC con indirizzamento breve
(con EXT=1 o con EXT=0 e IDENT1 fissato a un valore di identificativo
di un *utente* chiamato valido), il TSC inviera' una delle seguenti
risposte:
a. ACKI (QUAL=1), ACKQ (QUAL=1), ACKX o ACKV, con PFIX(IDENT2 come
indirizzo individuale dell'unita' chiamante e IDENT1 come
identificativo del chiamato (o PABXI per una chiamata ad una
estensione PABX).
b. ACKT (QUAL=0) con PFIX/IDENT2 come indirizzo individuale
dell'unita' chiamante.
c. Un messaggio AHYC richiedente all'unita' chiamante il proprio
messaggio dati.
Per il ritardo accettabile vedi 7.2.4. Vedi anche 14.1.4 a 14.1.5.
14.1.2 Risposta ad un messaggio RQC con indirizzamento esteso.
Una *unita' radio* richiede di inviare il messaggio dati breve
generando un messaggio RQC, conformemente al protocollo ad accesso
casuale. Alla ricezione di un messaggio RQC con indirizzamento esteso
(con EXT=0 e IDENT1=IPFIXI, o PABXI), il TSC inviera' uno dei
seguenti messaggi:
a. ACKI (QUAL=1) ACKX o ACKV (QUAL=0), con lo stesso prefisso ed
identificativi come nel RQC.
b. Un messaggio AHYC che da' istruzione all'unita' chiamante di
inviare le informazioni complete dell'indirizzo del chiamato.
c. Un messaggio AHYC che da' istruzione all'unita' chiamante di
inviare il proprio messaggio dati.
Per il ritardo accettabile vedi 7.2.4. Vedi anche da 14.1.3 a 14.1.5.
per prevenire la duplicazione dei messaggi (quando un destinatario
accetta la ripetizione del messaggio come un nuovo messaggio).
Una sequenza tipica del messaggio per una *unita' radio* che invia un
messaggio dati breve ad un'altra *unita' radio* , e' illustrata
nell'esempio successivo.
1 slot
| 1| | 3| | | 5| | 5| | 7|
dal TSC |ALH | ALH | AHYC | ALH | ALH |HEAD |dati | ALH | ACK |ACK |
alle RUs |(3) | (0) | | (0) | (4) | | | | (0) | (1) | 1 |
| | | | | | | | | | | |
2 4 4 6 dalle RUs RQC HEAD dati
ACK al TSC
trama trama trama
Esempio Una sequenza di messaggi sul canale di controllo per l'invio
di un messaggio dati breve fra una *unita' radio* ad un'altra *unita'
radio* sullo stesso sito. In questo esempio, il messaggio dati
comprende una parola di codice d'indirizzo e due parole di codice
dati aggiunte:
1. ALH: invito generale ALOHA (lunghezza della trama pari a tre
"slot")
2. RQC: richiesta di accesso casuale per trasmettere un messaggio
dati breve. (La richiesta indica il numero di slot necessari per il
messaggio di dati: in questo caso due "slot").
3. AHYC: invito per un messaggio dati breve
- riscontro al messaggio RQC
- da' istruzione all'unita' chiamante di inviare il messaggio dati
nei prossimi due "slot"
- inibizione all'accesso casuale nello "slot" successivo.
4. HEAD+dati: l'unita' chiamante invia il proprio messaggio dati
breve al TSC. In questo esempio il messaggio comprende una parola di
codice indirizzo (HEAD) e due parole di codice dati aggiunte.
5. HEAD+dati: il TSC invia il messaggio dati breve alla *unita' ra-
dio* chiamata.
La seconda parola di codice dati contiene una flag (RSA) che e'
fissata a '0' per inibire l'accesso casuale nello "slot" successivo
riservando cosi' lo "slot" per una risposta dall'unita' chiamata.
14.1.3 Istruzioni per inviare un'informazione con indirizzo esteso.
Dopo aver ricevuto un messaggio RQC con indirizzamento esteso, il TSC
puo' richiedere l'indirizzo completo del chiamato (se necessario)
inviando il messaggio AHYC con:
- lo stesso prefisso ed identificativi come nel RQC (per esempio
IDENT1 fissato a IPFIXI, o PABXI come appropriato e PFIX/IDENT2
fissato all'indirizzo dell'unita' chiamante)
- DESC fissato per indicare il *gateway* appropriato (vedi
5.5.3.2.8).
- SLOTS fissato al valore corrispondente RQC. (cioe' SLOTS='01').
Il messaggio AHYC da' istruzione all'unita' chiamante di inviare le
informazioni di indirizzo dell'utente chiamato nel successivo "slot"
indicato da SLOTS (vedi 9.2.2.1). Se il TSC non decodifica con
successo le informazioni dell'indirizzo, puo' ripetere il messaggio
AHYC o trasmettere ACKV (QUAL=0) per indicare l'insuccesso della
transazione.
Notare che, quando la *unita' radio* invia il proprio messaggio dati
breve fornisce l'indirizzo dell'utente chiamato
(prefisso/identificativo) all'inizio del messaggio dati. Tuttavia per
una chiamata interprefisso il TSC non ha bisogno di richiedere
l'indirizzo del chiamato separatamente a meno che venga richiesto per
comodita' nelle operazioni.
14.1.4 Istruzioni per inviare il messaggio di dati breve.
Dopo aver ricevuto un messaggio RQC, il TSC puo' richiedere il
messaggio dati breve della *unita' radio* chiamante inviando un
messaggio AHYC, con:
- IDENT1 fissato a SDMI
- PFIX/IDENT2 fissato all'indirizzo dell'unita' chiamante
- DESC fissato a '000'
- SLOTS uguale a SLOTS ricevuti nel messaggio RQC.
Il messaggio AHYC da' istruzione all'unita' chiamante di inviare il
messaggio di dati breve nel successivo "slot" indicato da SLOTS (vedi
9.2.2.1). Se il TSC non decodifica con successo il messaggio breve di
dati, puo' ripetere il messaggio AHYC o trasmettere ACKV (QUAL=0) per
indicare il fallimento della transazione.
Notare che il messaggio AHYC disabilita l'accesso casuale soltanto
nel primo slot successivo entrante quando viene richiesto un
messaggio breve di dati il TSC prendera' le azioni opportune per
riservare i susseguenti slot entranti se sono all'interno di una
trama (cioe' inviando il messaggio AHY con entrambi gli
identificativi fissati a DUMMY1).
14.1.5 Riscontri inviati per indicare l'avanzamento di una
transazione RQC.
Il TSC puo' inviare messaggi di riscontro per indicare alla *unita'
radio* chiamante l'avanzamento della propria transazione dati breve -
per identificativi vedi 5.5.2.1. (Per una chiamata con indirizzamento
esteso i riscontri ACKQ, ACKV (QUAL=1), ACKT (QUAL=0) e ACK (QUAL=0)
non sono appropriati fino a quando non e' stato ottenuto l'indirizzo
chiamato. Riscontri ACKQ (QUAL=0) e ACK (QUAL=0) non sono corretti
fino a quando non e' stato ottenuto il messaggio dati breve).
ACKI (QUAL=1) - Riscontro intermedio; seguira' ulteriore
segnalazione.
ACKQ (QUAL=0) - Il sistema e' occupato. Attendere la ulteriore
segnalazione
ACKQ (QUAL=1) - La parte chiamata e' occupata. Attendere la ulteriore
segnalazione.
ACKX (QUAL=0) - La chiamata non e' valida ad esempio il TSC non
tratta messaggi dati brevi, o la parte chiamata non e' equipaggiata
per accettare il messaggio.
ACKX (QUAL=1) - Il sistema o l'unita' chiamata sono in sovraccarico;
messaggio respinto.
ACKV (QUAL=0) - L'unita' chiamata non e' in contatto radio oppure la
transazione e' stata abbandonata.
ACKV (QUAL=1) - l' *utente* chiamato e' occupato (e il TSC non
memorizza la chiamata) o l'unita' chiamata non desidera accettare il
messaggio.
ACKT (QUAL=0) - La chiamata dati all' *utente* chiamato e' stata
deviata.
ACK (QUAL=0) - La transazione del messaggio e' stata conclusa con
successo.
Per il ritardo massimo accettabile delle ripetizioni dei riscontri
ACKX, ACKV, ACKT e ACK vedi tempo limite TB in 14.2.4.
14.1.6 Verifica della disponibilita' di una *unita' radio* chiamata.
Prima di trasmettere un messaggio dati breve ad una *unita' radio*,
il TSC puo' verificare che l'unita' e' in contatto radio (e
opportunamente equipaggiate). Il TSC usa il messaggio AHY, con:
- bit POINT fissato a '0'
- bit CHECK fissato a '0'
- bit D fissato a '1'
- bit E fissato a '0'
- bit AD fissato a '0'
- PFIX/IDENT1 come indirizzo dell'unita' chiamata
- IDENT2 fissato a SDMI.
Il messaggio AHY richiede una risposta nello slot successivo
dall'unita' chiamata (vedi 9.2.2.2B).
Il TSC puo' indicare il risultato della verifica della disponibilita'
alla *unita' radio* chiamante inviando riscontro (i) appropiato (vedi
14.1.5).
14.1.7 Informazioni all' *utente* chiamato
Il TSC trasmette il messaggio dati breve a una *unita' radio* , a un
gruppo o a tutte le unita' del sistema inviando il messaggio HEAD sul
canale di controllo (vedi 5.6.2). Il messaggio di dati puo' essere
originato dallo stesso TSC o da una *unita' radio* (usando RQC ecc.),
o da un *terminale d'utente a connessione diretta* , o da
un'estensione PABX.
La parola di codice indirizzo HEAD indica il numero delle parole di
codice dati aggiunte (fino a quattro), e contiene due indirizzi di
venti bit: l'indirizzo del chiamato e l'indirizzo del chiamante (o
*gateway).
I dati dell'utente sono contenuti nella parola di codice dati. Per un
messaggio dati breve indirizzato individualmente all'interno di una
trama il TSC fissera' la flag RSA nell'ultima parola di codice dati
(o nella parola di codice dati riempitiva) a "0" , per inibire
l'accesso nello "slot" successivo.
Per un messaggio dati breve indirizzato individualmente, il messaggio
HEAD richiede una risposta dall'unita' chiamata (vedi 14.3.1.1). Se
la risposta e' ACK (QUAL=0) ACKX o ACKV (QUAL=1), il TSC puo' inviare
il riscontro appropriato alla *unita' radio* chiamante. (Vedi
14.1.5). Se il TSC non decodifica con successo una risposta, o se la
risposta e' ACKB (QUAL=1) puo' ripetere il messaggio HEAD. Se
l'unita' chiamata non puo' essere avvisata, il TSC puo' indicare il
fallimento inviando all'unita' chiamante ACKV (QUAL=0).
Per messaggi dati brevi indirizzati ad un gruppo (o all'intero
sistema), l'unita' chiamata non risponde; il TSC puo' ripetere il
messaggio dati breve per incrementare la probabilita' di ricezione
con successo. Dopo aver trasmesso il messaggio dati breve il TSC puo'
inviare ACK (QUAL=0) alla *unita' radio* chiamante.
14.1.8 Cancellazione della transazione.
Una *unita' radio* chiamante puo' cancellare la propria transazione
dati breve generando un messaggio RQX (vedi 5.5.3.1.3), conformemente
al protocollo ad accesso casuale. Alla ricezione di un messaggio RQX
che cancella una transazione dati breve, il TSC dovra' inviare una
risposta: ACK (QUAL=1) con lo stesso prefisso ed identificativi come
nel RQX.
14.1.9 Tempo limite del TSC.
Il TSC puo' introdurre un limite sul massimo tempo con cui memorizza
il messaggio dati breve (per esempio aspettando che l'utente chiamato
diventi libero).
Il TSC puo' dare istruzione a una *unita' radio* chiamante di far
ripartire il suo temporizzatore di attesa TJ o TW, inviando il
messaggio AHY con il bit POINT fissato a '1', vedi 9.1.1.7 e 9.2.2.3.
Se il tempo TJ o TW, meno la tolleranza sul temporizzatore della
*unita' radio*, scade senza che venga ricevuto l'ultimo messaggio per
una transazione dati breve (dall'unita' chiamante), il TSC non
inviera' alcuna ulteriore segnalazione per la transazione. Vedi anche
14.2.6.
14.2 Procedure per *unita' radio* che inviano il messaggio dati
breve.
Una *unita' radio* effettuera' soltanto un tentativo di chiamata alla
volta (escluso in emergenza); mentre sta tentando l'accesso o
aspettando un riscontro conclusivo (cioe' un fine transazione) ad una
richiesta di un messaggio dati breve, l'unita' non richiedera'
un'altra chiamata di non-emergenza di qualsiasi tipo (a meno che
l'utente prima non cancelli la transazione originale).
14.2.1 Richiesta per una transazione dati breve.
Una *unita' radio* richiede di trasmettere un messaggio dati breve
inviando un messaggio RQC sul canale di controllo conformemente al
protocollo ad accesso casuale (vedi 7.3). I campi nel messaggio RQC
saranno fissati correttamente (vedi 5.5.3.1.8); tuttavia Notare
particolarmente che:
a. Il campo SLOTS specifica il numero di "timeslot" richiestiper il
messaggio di dati (minimo due "slot" , massimo tre "slot" ).
b. Una richiesta con indirizzamento esteso e' indicata fissando
IDENT1 nel messaggio RQC all'appropriato *gateway* (ad esempio
IPFIXI, oPABXI).
L'unita' potra' tentare l'accesso fino a quando riceve una risposta
valida (vedi 14.2.2/3) o fino a quando l'utente cancella la
transazione (vedi 14.2.7), o fino a quando il tentativo d'accesso
fallisce (ad esempio l'unita' ha inviato il numero limite di
trasmissioni NR e non riceve risposta o il tempo massimo d'accesso TC
e' scaduto (vedi 7.3.8)). Nel caso di fallimento dell'accesso, se
l'unita' non ha inviato la richiesta, deve ritornare allo stato di
riposo (e puo' indicare all'utente l'insuccesso); negli altri casi,
deve aspettare una ulteriore segnalazione per la transazione - vedi
da 14.2.4 a 14.2.6.
14.2.2 Risposte valide ad un messaggio RQC con indirizzamento breve.
Per un messaggio RQC con indirizzamento breve l'unita' chiamante
accettera' i seguenti messaggi come risposta al proprio RQC e non
inviera' ulteriori richieste:
a. ACKI (QUAL=1), ACKQ (QUAL=1), ACKX o ACKV, con PFIX/IDENT2 come
proprio indirizzo individuale e IDENT1 come identificativo del
chiamato (o PABXI per una chiamata a PABX)
b. ACKT (QUAL=0) con PFIX/IDENT2 come proprio indirizzo individuale.
c. AHYC con PFIX/IDENT2 come proprio indirizzo individuale e IDENT1
come SDMI.
Per altre azioni alla ricezione di questi messaggi vedi 14.2.4 e
9.2.2.1.
14.2.3 Risposte valide a un messaggio RQC con indirizzamento esteso.
Per un messaggio RQC con indirizzamento esteso, l'unita' chiamante
accettera' i seguenti messaggi come una risposta al proprio RQC e non
inviera' ulteriori richieste:
a. ACKI (QUAL=1), ACKX o ACKV (QUAL=0), con lo stesso prefisso e
identificativi come nel RQC.
b. AHYC, con lo stesso prefisso e identificativi come nel RQC.
c. AHYC, con PFIX/IDENT2 come proprio indirizzo individuale e IDENT1
come SDMI.
Per altre azioni alla ricezione di questi messaggi vedi 14.2.4 e
9.2.2.1.
14.2.4 Riscontri ricevuti.
Se mentre una *unita' radio* sta tentando l'accesso o attendendo una
ulteriore segnalazione per una transazione dati breve, riceve un
appropriato riscontro allora si comportera' come sotto indicato
(ACKQ, ACKV (QUAL=1), ACKT (QUAL=0) e ACK (QUAL=0) non sono corretti
fino a quando l'informazione dell'utente chiamato non e' stata
inviata, nel messaggio RQC, come informazione d'indirizzo esteso, o
nel messaggio dati breve. ACKQ (QUAL=0) e ACK (QUAL=0) non sono
corretti fino a quando il messaggio dati breve e' stato inviato). Per
identificativi vedi 5.5.2.1.
ACKI (QUAL=1) - Riscontro intermedio; seguira' ulteriore
segnalazione.
ACKQ (QUAL=0) - Il sistema e' occupato. Attendere la ulteriore
segnalazione
ACKQ (QUAL=1) - L' *utente* chiamato e' occupato. Attendere la
ulteriore segnalazione.
ACKX (QUAL=0) - Chiamata non valida; messaggio respinto.
ACKX (QUAL=1) - Il sistema o l'unita' chiamata e' in sovraccarico;
messaggio respinto.
ACKV (QUAL=0) - L'unita' chiamata non e' in contatto radio o la
transazione e' stata abbandonata.
ACKV (QUAL=1) - L' *utente* chiamato e' occupato (e il TSC non
memorizza la richiesta) o l'utente chiamato non desidera accettare il
messaggio.
ACKT (QUAL=0) - Le chiamate dati all' *utente* chiamato sono state
deviate.
ACK (QUAL=0) - La transazione si e' conclusa con successo.
Se viene ricevuto ACKI (QUAL=1) o ACKQ, l'unita' deve aspettare una
ulteriore segnalazione e puo' indicare all'utente l'avanzamento della
transazione.
Se viene ricevuto ACKX o ACKV, l'unita' deve ritornare allo stato di
riposo e puo' indicare all'utente il motivo dell'insuccesso della
transazione; viene raccomandato che la ricezione di un riscontro ACKX
(QUAL=0) venga indicata con modalita' differente.
Se viene ricevuto un messaggio ACKT (QUAL=0) completo, l'unita'
potra' sia:
a. ritornare allo stato di riposo (puo' indicare all'utente che le
chiamate dati per l' *utente* chiamato sono state deviate) o,
b. tentare una nuova transazione dati breve all'indirizzo deviato
fornito nel messaggio ACKT.
Se viene ricevuto il messaggio ACKT (QUAL=0) incompleto allora:
i) se l'unita' non richiede l'indirizzo di deviazione, deve ritornare
allo stato di riposo (e puo' avvisare l'utente)
ii) se l'unita' richiede l'indirizzo di deviazione allora:
- se sta gia' tentando l'accesso per la transazione, ignorera' il
messaggio e continuera' il tentativo d'accesso;
- negli altri casi deve aspettare la ripetizione del messaggio ACKT,
ritornando allo stato di riposo se viene superato il tempo TB (in
questo caso puo' indicare il fallimento all'utente).
Se viene ricevuto ACK (QUAL=0) l'unita' deve ritornare nello stato di
riposo e puo' indicare all'utente che la transazione e' stata
completata con successo cioe' che:
- per una chiamata individuale, l'unita' chiamata ha accettato il
messaggio dati breve; (Notare che questo non implica l'accettazione
da parte dell'utente);
- per una chiamata di gruppo (o generale), il messaggio dati breve e'
stato inviato al gruppo.
Dopo aver ricevuto ACKX, ACKV o ACK per la transazione, l'unita' non
richiedera' un'altra chiamata, escluso quelle di emergenza, di
qualsiasi tipo allo stesso identificativo chiamato (*gateway*) per
almeno un tempo TB. Dopo aver ricevuto ACKT per la transazione,
l'unita' non richiedera' un'altra chiamata, escluso quella di
emergenza, di qualsiasi tipo per almeno un tempo TB.
14.2.5 Invio di un messaggio dati breve.
L'unita' chiamante trasmettera' il proprio messaggio dati breve (una
parola di codice indirizzo HEAD e parola (e) di codice dati aggiunta
- vedi 5.6.2) alla ricezione di un messaggio appropriato AHYC dal
TSC; vedi sezione 9.2.2.1.
14.2.6 Tempo limite di attesa
Una *unita' radio* chiamante in attesa di ulteriore segnalazione per
una transazione dati breve ritornera' nello stato di riposo se il
tempo TJ (per un messaggio dati indirizzato al TSC) o TW (per altre
destinazioni) e' scaduto da quando l'ultimo messaggio di segnalazione
e' stato inviato per la transazione, cioe':
RQC, richiedente transazione (vedi 14.2.1)
o SAMIS, che fornisce la informazione di indirizzo esteso per la
chiamata (vedi 9.2.2.1)
o HEAD, contenente il messaggio dati breve (vedi 14.2.5 e 9.2.2.1)
o ACK (QUAL=0), inviato in risposta ad un messaggio AHY con il bit
POINT=1 e IDENT1 come identificativo del chiamato o *gateway* (vedi
9.2.2.3).
Puo' anche indicare all'utente che il risultato della transazione e'
sconosciuto.
14.2.7 Cancellazione dell'operazione.
Una *unita' radio* puo' cancellare la transazione dati breve (dopo
aver inviato un RQC e mentre sta ancora aspettando di ricevere ACKX,
ACKV, ACKT o ACK) trasmettendo una richiesta di cancellazione della
transazione RQX (vedi 5.5.3.1.3), conformemente al protocollo ad
accesso casuale. Tentera' l'accesso fino a quando uno dei seguenti
eventi accade:
a. riceve ACK (QUAL=1) con gli stessi prefissi e identificativi come
nel RQX. In questo caso, puo' indicare all'utente che il risultato
della transazione e' sconosciuto.
b. Riceve ACK (QUAL=0), ACKX, ACKV o ACKT (QUAL=0) per la transazione
che sta tentando di cancellare. Vedi anche 14.2.4.
c. Ha inviato il numero massimo di trasmissioni NR e non riceve
risposta, il tempo massimo d'accesso TC e' scaduto (vedi 7.3.8). In
questo caso, deve ritornare in attesa di segnalazioni per la
transazione dati brevi (vedi da 14.2.4 a 14.2.6).
Nei casi a. e b. l'unita' deve ritornare allo stato di riposo.
14.3 Procedure per tutte le *unita' radio* sul canale di controllo.
Le procedure in questo paragrafo saranno osservate da tutte le
*unita' radio* che sono equipaggiate per riconoscere una parola di
codice indirizzo HEAD ricevuta. (Il requisito di ricezione HEAD sara'
dipendente dal sistema).
14.3.1 Ricezione di un messaggio dati breve (HEAD).
14.3.1.1 Messaggi HEAD con indirizzo individuale.
Se una *unita' radio* sul canale di controllo riceve un messaggio
HEAD con PFIX/IDENT1 corrispondenti al proprio indirizzo individuale,
rispondera' con l'appropriato riscontro (vedi sotto), con PFIX/IDENT1
come proprio indirizzo individuale e IDENT2 fissato a IDENT2 dal
HEAD. La parola di codice indirizzo HEAD contiene un campo (LEN) che
indica il numero di parole di codice dati aggiunte; l'unita'
rispondera' nello "slot" successivo all'ultimo parola di codice dati.
Per la temporizzazione, vedi 6.2.1.3.
a. Se l'unita' non e' equipaggiata per accettare il messaggio dati
allora inviera' ACKX (QUAL=0).
b. Negli altri casi, l'unita' inviera' uno dei seguenti riscontri:
ACKB (QUAL=1) se non tutte le parole di codice dati sono state
decodificate e l'unita' richiede che il messaggio venga ritrasmesso
o ACKX (QUAL=1) se non puo' accettare il messaggio in quel momento
(ad esempio la sua memoria di dati e' satura)
o ACKV (QUAL=1) se non desidera accettare il messaggio dati da questo
*utente* chiamante
o ACK (QUAL=0) se ha accettato il messaggio dati.
14.3.1.2 Messaggi HEAD indirizzato a un gruppo.
Se una *unita' radio* sul canale di controllo riceve un messaggio
HEAD con PFIX/IDENT2 non corrispondente al proprio indirizzo
individuale, e
PFIX/IDENT1 corrispondente ad uno dei propri indirizzi di gruppo per
quel sistema
o IDENT1 fissato all'identificativo ALLI per una chiamata generale
allora puo' accettare l'informazione contenuta nella parola di codice
indirizzo HEAD e le parole di codice dati aggiunte, ma non inviera'
la risposta.
15. PROCEDURE DI INTERROGAZIONE DATI.
Questo capitolo definisce le procedure per la interrogazione dati,
che permettono al TSC di richiedere che una *unita' radio*
indirizzata trasmetta un messaggio dati del tipo prescritto. Questa
richiesta e' una interrogazione da parte del TSC, non una parte della
segnalazione per una richiesta di chiamata da una *unita' radio*.
Puo' essere inviata sia sul canale di controllo che su un canale di
traffico assegnato.
Il TSC interroga la *unita' radio* inviando un messaggio AHYC modo 2
(vedi 5.5.3.2.8). In questo messaggio, IPFIX/IDENT1 e' fissato
all'indirizzo individuale della *unita' radio* e IDENT2 e'
l'identificativo di chi richiede l'interrogazione (un identificativo
non appartenente ad una *unita' radio* ). Il tipo di dato che deve
essere trasmesso da una *unita' radio* e' indicato dal campo
descrittore DESC e dall'identificativo non appartenente ad una
*unita' radio*
Il TSC non invia riscontri dei messaggi di dati ricevuti dalla
*unita' radio* (tuttavia puo' prendere appropriate azioni come
risultato dei dati ricevuti).
Attualmente, per interrogazione dati, soltanto un valore del campo
descrittore del messaggio di dati DESC e' stato assegnato. Questo
valore e' usato per effettuare la verifica del numero di serie: il
TSC puo' in ogni momento sia sul canale di traffico che sul canale di
controllo dare istruzione ad una *unita' radio* di inviare il proprio
numero di serie di 38 bit. La comparazione del numero di serie
ricevuto con il valore atteso (memorizzato nel TSC) aiutera' nella
rivelazione di utenti fraudolenti.
15.1 Procedure di interrogazione dati per il TSC.
15.1.1 Interrogazione dati sul canale di controllo.
Il TSC puo' richiedere che una *unita' radio* sul canale di controllo
trasmetta un messaggio dati del tipo prescritto, inviando il
messaggio AHYC con:
- PFIX/IDENT1 fissato all'indirizzo individuale della *unita' radio*
- IDENT2 fissato all'identificativo dell'interrogatore (per esempio,
per la verifica del numero di serie IDENT2=TSCI)
- DESC fissato per indicare il tipo di messaggio di dati richiesto;
vedi 5.5.3.2.8.
(per esempio, per la verifica del numero di serie DESC='000').
- SLOTS fissato nel modo corretto, vedi 5.5.3.2.8 (per esempio per la
verifica del numero di serie, SLOTS='01').
Il messaggio AHYC da' istruzioni alla *unita' radio* indirizzata di
trasmettere un messaggio di dati nello "slot" successivo indicato da
SLOTS (vedi 15.2.1). Se il TSC non decodifica con successo una
risposta, puo' ripetere il messaggio AHYC quando e' piu' comodo. (Il
TSC non invia riscontri dei messaggi dati ricevuti).
Notare che AHYC disabilita l'accesso casuale soltanto nel primo
"slot" entrante successivo. Quando viene richiesto un messaggio dati
con piu' parole di codice, il TSC prendera' gli opportuni
provvedimenti per riservare gli "slot" entranti susseguenti se sono
all'interno di una trama (cioe' inviando messaggi AHY con entrambi
gli identificativi fissati a DUMMI).
15.1.2 Interrogazione dati sul canale di traffico.
Il TSC puo' richiedere che una *unita' radio* sul canale di traffico
assegnato trasmetta un messaggio dati del tipo prescritto, inviando
il messaggio AHYC con:
- PFIX/IDENT1 fissato all'indirizzo individuale della *unita' radio*
- IDENT2 fissato all'identificativo dell'interrogatore
- DESC fissato per indicare il tipo di messaggio dati richiesto; vedi
5.5.3.2.8
- SLOTS fissato appropriatamente; vedi 5.5.3.2.8
Il messaggio AHYC da istruzione alla *unita' radio* indirizzata di
trasmettere un messaggio dati (vedi 15.2.2). Se il TSC non decodifica
con successo una risposta, puo' ripetere il messaggio AHYC.
15.2 Procedure per tutte le *unita' radio*.
Le procedure in questo paragrafo saranno osservate da tutte le
*unita' radio* che sono equipaggiate per riconoscere un messaggio
AHYC Modo 2 ricevuto. (Il requisito di riconoscere il messaggio AHYC,
Modo 2, potra' essere dipendente dal sistema).
15.2.1 Messaggio di interrogazione dati (AHYC, Modo 2) sul canale di
controllo.
Se una *unita' radio* sul canale di controllo riceve un messaggio
AHYC con PFIX/IDENT1 corrispondente al proprio individuale allora
dovra' o inviare un messaggio dati nel successivo "slot" o
trasmettere ACKX (QUAL=0), come sotto indicato. Per temporizzazione,
vedi sezione 6.2.1.3.
Se
IDENT2 e' fissato a TSCI
e DESC e' fissato a '000'
e SLOTS e' fissato a '01'
e l'unita' e' equipaggiata per trasmettere il proprio numero di
serie su interrogazione
allora trasmettera' il proprio "numero di serie" conformemente con il
formato di parola di codice definito nel paragrafo 5.6.1.2.2 (SAMIS,
Modo 2, DESC='000'). (Il formato del numero di serie e' dipendente
dal sistema).
Negli altri casi
l'unita' trasmettera' ACKX (QUAL=0) con lo stesso prefisso e
identificativi come nel AHYC.
15.2.2 Messaggio di interrogazione dati (AHYC Modo 2) su un canale di
traffico assegnato.
Se una *unita' radio* sul canale di traffico riceve un messaggio AHYC
con PFIX/IDENT1 corrispondenti al proprio indirizzo individuale
allora dovra' o inviare un messaggio dati, o trasmettere ACKX
(QUAL=0), come sotto indicati. Per temporizzazione vedi sezione
6.2.2.2.
Se
IDENT2 e' fissato a TSCI
e DESC e' fissato a '000'
e SLOTS e' fissato a '01'
e l'unita' e' equipaggiata per trasmettere il proprio numero di serie
su interrogazione
allora inviera' il proprio numero di serie, conformemente con il
formato di parola di codice definito nel paragrafo 5.6.1.2.2 (SAMIS,
Modo 2, DESC='000').
Negli altri casi
l'unita' trasmettera' ACKX (QUAL=0) con lo stesso prefisso e
identificativi come AHYC.
APPENDICE 1
VALORI CONSIGLIATI PER I PARAMETRI
Parametri come tempi limiti e numero di tentativi delle *unita' ra-
dio* sono rappresentati da simboli in questo standard; per esempio la
massima durata dell' *ITEM* e' riferito come TT. Questa appendice
contiene valori consigliati per questi parametri. Tuttavia, notare
che una *unita' radio* deve usare i valori richiesti dal sistema in
cui e' normalmente operativo.
Una breve descrizione dell'utilita' di ciascun parametro viene
fornita, ma il lettore dovrebbe riferirsi alle procedure dei
paragrafi per una definizione precisa dell'uso. La tabella elenca i
paragrafi a cui si riferisce ciascun parametro.
La tolleranza massima per i tempi realizzati dalle *unita' radio* e'
piu' o meno 10%.
Significato Simbolo Valore Riferimento Consigliato
Numero di messaggi di scon- ND1 2 9.2.3.5
nessione inviati da una 9.2.3.6
*unita' radio* chiamata
individualmente.
Numero di messagi di scon- ND2 4 9.2.3.5
nessione inviati da una 9.2.3.6
*unita' radio* chiamante
Numero massimo di tra- NE 16 7.3.8
smissioni con accesso ca- 10.2.1
suale di RQE
Numero massimo di tra- NI 4 11.2.1
smissioni sul canale di 11.2.6
di traffico di RQS o RQX
Numero massimo di trasmis- NR 8 7.3.8
sioni con accesso casuale 8.2.2.2
di RQS, RQD, RQX, RQT, 9.2.1.1
RQR, RQQ o RQC 9.2.1.7
12.2.1
12.2.6
13.1.2.2
13.1.2.6
13.2.2.1
13.2.2.6
14.2.1
14.2.7
Significato Simbolo Valore Riferimento Consigliato
Ritardo massimo di una risposta NT 103 6.1.2.2
dal TSC ad un messaggio 6.2.2.2.2
spontaneo da una *unita' radio*
sul canale di traffico (la
risposta SYNT comincia non piu'
tardi della partenza del bit NT,
misurato dalla fine del
messaggio della *unita' radio*).
Valore di Wait assunto NW 4 7.3.7
all'inizio di una sezione.
(Wait e' un numero di "slot")
Tempo limite per una *unita' TA 60 sec. 9.2.2.2
radio* chiamata dopo la rice- 9.2.2.4
zione di AHY 13.1.2.1
Tempo di disabilitazione di TB 2 sec. 9.1.1.4
chiamata allo stesso identifica- 9.2.1.4
tivo dopo aver ricevuto 11.1.4
ACK (QUAL=0), ACKX, ACKV o 11.2.4
ACKB (QUAL=0), o a qualsiasi 12.1.5
identificativo dopo aver 12.2.4
ricevuto ACKT (QUAL=0) 13.1.1.2
13.1.2.4
13.2.1.4
13.2.2.4
14.1.5
14.2.4
Tempo limite per una *unita' TC 60 sec. 7.3.8
radio* che richiede l'acces- 8.2.2.2
so casuale 9.2.1.1
9.2.1.7
10.2.1
12.2.1
12.2.6
13.1.2.2
13.1.2.6
13.2.2.1
13.2.2.6
14.2.1
14.2.7
Tempo limite per una *unita' TI 2 sec. 9.1.2.2
radio* in attesa di ulteriore 11.1.7
segnalazione per una chiamata 11.2.5
di inclusione
Tempo limite per una *unita' TJ 20 sec. 7.3.8
radio* in attesa di ulte- 8.2.1.3
riore segnalazione per una 8.2.2.4
transazione sul canale di 9.1.1.7
controllo con il TSC (ad 9.2
esempio registrazione, ri- 12.1.7
chiesta di deviazione, mes- 12.2.5
saggi di stato o messaggi 13.1.1.4
dati breve al TSC) 13.1.2.5
14.1.9
14.2.6
Tempo limite di inattivi- TN 7 sec. 9.2.3.6
ta' di una *unita' radio*
sul canale di traffico
Intervallo massimo tra mes- TP 5 sec. 9.2.2.6
saggi periodici (all'inter-
no di un *ITEM* per con-
versazione) all'inizio di
una sessione
Tempo in cui una *unita' TS 5 sec. 6.2.1.2
radio* ritorna alle pro-
cedure di acquisizione
del canale di controllo
se non viene decodificato
il codice di identita' del
sistema.
Massima durata di un TT 60 sec. 9.2.3.6
*item*
Tempo limite per una *unita' TW 60 sec. 7.3.8
radio* chiamante in attesadi 9.1.1.7
ulteriore segnalazione per 9.1.1.10
una chiamata o un'operazione 9.2
che puo' richiedere 9.2.1.6
l'accodamento (per un canale 10.1.7
di trafficoo per un *utente* 10.2.7
chiamato) 13.2.1.7
13.2.2.5
14.1.9
14.2.6
APPENDICE 2
LE PROPRIETA' DEL CONTROLLO DI ERRORE DELLE PAROLE DI CODICE
Le proprieta' di controllo di errore delle parole di codice sono
almeno le seguenti.
Con decodifica a "hard decision"
a. Rilevare tutti i numeri dispari di errore, ogni 5 errori casuali,
e ogni pacchetto d'errore fino ad una lunghezza di 16, o
b. correggere ogni errore singolo e rilevare fino a 4 errori e
qualsiasi pacchetto d'errore fino ad una lunghezza di 11, o
c. correggere fino a ciascun doppio errore e rivelare qualsiasi
triplo errore ed ogni pacchetto d'errore fino ad una lunghezza 4, o
d. correggere ogni singolo pacchetto d'errore fino ad una lunghezza
di 5.
Con decodifica a "soft decision":
Correggere qualsiasi presenza di 5 bit dubbi ed ogni singolo
pacchetto di bit dubbi fino a una lunghezza di sedici, secondo il
risultato dell'esame della sequenza dei bit dubbi.
Nota. Maggiore e' il grado di correzione d'errore applicato, piu'
probabile e' la falsa decodifica. L'applicazione della misura della
qualita' del segnale sulla base di "bit - per - bit " puo' aiutare a
ripararsi contro elaborazioni false se viene usata una decodifica
"hard decision", ed e' essenziale se viene usata una decodifica "soft
decision" .
APPENDICE 3
UN ALGORITMO PER DETERMINARE IL COMPLETAMENTO DELLA SEQUENZA DI UNA
PAROLA DI CODICE DEL CANALE DI CONTROLLO DEL SISTEMA.
1. Creare una parola di codice che inizia con un preambolo di 16 bit
seguito dalla sequenza di bit '1100010011010100' e il codice di
identificazione del sistema di 15 bit, cosi' riempiendo i bit da 1 a
47.
2. Assumere che il bit 48 sia = '0'. Calcolare il bit di verifica
(vedi paragrafo 3.2.3).
3. Se il bit di parita' e' ='0' , allora l'assunzione in 2 era er-
rata. In questo caso porre bit 48='1' e ricalcolare i bit di verifica
(vedi anche nota 1).
4. La desiderata sequenza di completamento della parola di codice e'
costituita dai bits da 48 a 63 incluso con il bit 63 invertito.
Nota 1. Un modo veloce di invertire il bit assunto e ricalcolare i
bit di verifica e' di sommare modulo -2 il polinomio generatore
'1110100000010101' ai bit da 47 a 63, e dopo calcolare il bit di
parita'.
Nota 2. L'algoritmo funziona perche' i bit da 1 a 63 sono
completamente ciclici, eccetto per il bit 63 e ci sono un numero
dispari di 1 nel polinomio generatore. Il bit di parita' rimane
inalterato da qualsiasi processo ciclico.
APPENDICE 4
UN ALGORITMO PER GENERARE I CAMPI A E B DELLA PAROLA DI CODICE MARK.
1. I bit 1, da 22 a 30 e da 49 a 64 nella parola di codice di
indirizzo MARK sono fissi (vedi paragrafo 5.5.4.1). I bit da 2 a 5
(CHAN 4) e da bits 7 a 21 (SYS) sono dipendenti dal sistema. I bit 6
(campo A) e bit da 31 a 48 (campo B) sono scelti per massimizzare il
numero delle transizioni fra i bit 33 e 49 nella parola di codice.
2. Per calcolare una parola di codice MARK candidata iniziale, si as-
sume che i bit 6,31 e 32 della parola di codice MARK siano a '0'.
3. Ottenere una sequenza di 16 bit da inserire nei bit da 33 a 48
secondo una metodologia similare a quella in appendice 3, cioe':
a. Creare una parola di codice intermedio che inizi con la sequenza
'1100010011010101' seguita da CHAN4, '0' (bit 6 di MARK), SYS,
'10001100' e '00' (bit 31 e 32 di MARK).
b. Assumere che il bit 48 della parola di codice intermedia sia='0'.
Calcolare i bit di verifica, (vedi sezione 3.2.3).
c. Se il bit di parita' e' '0', allora l'assunzione in b. era errata.
In questo caso fissare il bit 48=1 e ricalcolare i bit di verifica,
(vedi anche nota 1 di Appendice 3).
d. La sequenza dei 16 bit da inserire nei bit da 33 a 48 di una
parola di codice candidata MARK e' il bit tra 48 a 63 di una parola
di codice intermedia, con il bit 63 invertito.
4. Derivare altre 7 parole di codice candidate MARK aventi le
combinazioni alternative dei bit 6, 31 e 32. Questo puo' essere
ottenuto sommando modulo 2 la sequenza seguente ai bit da 33 a 48
nella parola di codice iniziale candidata MARK:
se il bit 6 = '1' aggiungere '0100000000101110'
se il bit 31 = '1' aggiungere '0111000001111110'
se il bit 32 = '1' aggiungere '0011100000111111'
5. Per ogni parola di codice MARK candidata contare il numero di
transizioni dei bit che appaiono tra i bit 33 e i bit 49.
6. La parola di codice richiesta MARK e' una candidata che fornisce
il piu' alto numero di transizioni contate.
APPENDICE 5
CODIFICA BCD
Dove la codifica BCD viene specificata in questo standart le seguenti
rappresentazioni verranno usate.
Valore binario Carattere Rappresentato
'0000' 0
'0001' 1
'0010' 2
'0011' 3
'0100' 4
'0101' 5
'0110' 6
'0111' 7
'1000' 8
'1001' 9
'1010' riservato
'1011' *
'1100' (cancelletto)
'1101' riservato
'1110' riservato
'1111' nullo
Nota: Questi gruppi BCD saranno sistemati in un parola di codice
cosicche' il bit piu' significativo del valore binario e' trasmesso
per primo (cioe' il bit a sinistra nella tabella di sopra sara'
trasmesso per primo).
TOMO TERZO
PARTE I
SEZIONE 3a
PROCEDURE DI PROVA
1. CONDIZIONI GENERALI DI PROVA
Gli apparati sottoposti alle prove di conformita' saranno
assoggettati a due tipi di prova:
- prove in laboratorio secondo le modalita' riportate piu' avanti;
- prove di accesso in rete e di funzionalita' secondo i parametri e
la procedure che verranno rese note dall'Ente certificante.
1.1 Condizioni di default per la prova
Questa sezione definisce certe condizioni di test che sono prese come
condizioni di default se non altrimenti specificato.
1.1.1 Livello di potenza del segnale ricevuto
Se non diversamente indicato, il livello di potenza di segnale
all'ingresso del ricevitore dell'unita' radio dovra' essere al valore
nominale di -85 dBm.
1.1.2 Stato di riposo
L'unita' radio e' nello stato di riposo se ha acquisito un canale di
controllo ed ha effettuato l'operazione di registrazione. Nello stato
di riposo non sono in corso scambi di segnalazioni.
1.1.3 Valori del SYS e CCS
Se non diversamente indicato, il valore standard del SYS e del CCS
trasmessi dal canale di controllo generato dal Test Set di prova,
dovranno essere i seguenti:
SYS CCS
'101010110000001' '1100100111001110'
1.2 Parametri di Rete
Tutte le unita' radio operanti nel servizio radiomobile pubblico di
dispaccio per gruppo chiuso di utenti dovranno essere pre-
programmabili con le informazioni sulla rete in cui dovranno operare.
In aggiunta ai valori assegnati alle variabili di sistema riportate
in appendice B della PARTE 1a sezione 1, i seguenti parametri
dovranno avere il valore assegnato.
1.2.1 ESEMPIO: Dati di autorizzazione all'acquisizione
1 '001' Zona
2 '0100010' Area
3 '0100100' Area
4 '0100110' Area
5 '0101000' Area
6 '0101010' Area
7 '010110000' Full Code
8 '011001010' Full Code
1.2.2 Lunghezza del sotto-campo di Zona
LZ = 3 bits
1.2.3 Lunghezza del sotto-campo di Area
LA = 7 bits
1.2.4 Codice di Rete
NET = '01'
1.2.5 Numero di canale inferiore nella Rete
35
1.2.6 Numero di canale superiore nella Rete
97
1.2.7 Dimensione della scansione normale
10 canali
1.2.8 Numero di canale della scansione normale
A = Valore CHAN/CONT
35 '0000100011'
38 '0000100110'
40 '0000101000'
45 '0000101101'
48 '0000110000'
53 '0000110101'
59 '0000111011'
62 '0000111110'
70 '0001000110'
97 '0001100001'
1.2.9 Soppressione della scansione generale
No
1.2.10 Valore di INFO nel RQR
0
1.2.11 Valore di NC1
5
1.2.12 Valore di NC2
5
1.2.13 Valore di NV
1
1.2.14 Valore di NX1
3
1.2.15 Valore di NX2
3
1.2.16 Valore di NZ1
1 campione
1.2.17 Valore di NZ2
2 campioni
1.2.18 Valore di TC
60 sec.
1.2.19 Valore di TD
5 min.
1.2.20 Valore di TJ
20 sec.
1.2.21 Valore di TN
7 sec.
1.2.22 Valore di TS
5 sec.
1.2.23 Valore di TT
60 sec.
1.3 Personalizzazione dell'unita' radio
1.3.1 Proprio PFIX
39
1.3.2 Identificativo proprio individuale
2001
1.3.3 Numero di digits delle chiamate individuali
3 digits
1.3.4 Indicativo di base individuale
2000
1.3.5 Chiamate di gruppo a due o tre digits
2 digits
1.3.6 Indicativo individuale piu' alto della propria flotta
2039
1.3.7 Indirizzi di gruppo
L'unita' radio sara' un membro del seguente gruppo 7001.
1.3.8 Sbarramento di chiamata interflotta di gruppo
Sbarrato
1.3.9 Identificativo base di gruppo
7000
1.3.10 Identificativo piu' alto del proprio gruppo
7003
1.3.11 Categoria di controllo
CCAT A
1.4 Ulteriore preparazione dell'unita' radio
Per i tests relativi alla deviazione di frequenza per i dati standard
e la tolleranza di frequenza viene richiesto che la unita' radio sia
posizionata in funzionamento in modo manuale (cioe' l'unita' non
dovra' operare in modo automatico multiaccesso).
1.5 Documentazione
Il costruttore dovra' fornire una copia del manuale dell'operatore
per l'unita' radio e le seguenti informazioni (che dovranno essere
conformi alla PARTE 1a Sezione 1, dove applicabile):
- Prestazioni opzionali normalizzate fornite;
- Istruzioni per la connessione alle apparecchiature di prova
- Istruzioni per lo smontaggio dell'unita' radio al fine della
identificazione della scritta indicante il numero di protezione;
- Istruzioni per il cambio dei parametri di rete;
- Istruzioni per il cambio dei parametri di personalizzazione
dell'unita' radio.
Il costruttore dovra' inoltre fornire i campi contenenti
l'informazione del numero di sicurezza nella risposta SAMIS al
messaggio di richiesta di validazione del numero di sicurezza (AHYC)
che sono corretti per l'unita' radio fornita per le prove.
2. PROVE PARAMETRICHE
2.1 Designazione del canale e tolleranza di frequenza
2.1.1 Scopo della prova
Assicurare che l'unita' radio riceva le informazioni ed esegua gli
ordini relativi al campo CHAN negli appropriati messaggi GTC.
Assicurare che l'unita' radio non risponda a valori indefiniti del
campo CHAN.
Assicurare che la frequenza della portante emessa sia entro la
tolleranza richiesta con riferimento alla frequenza nominale di
trasmissione.
2.1.2 Inizializzazione
L'unita' radio dovra' essere connessa al Test Set di prova che
generera' le segnalazioni del canale di controllo su una frequenza di
canale al centro della banda di funzionamento dell'unita' radio (ad
es.: canale n. 53).
L'unita' radio dovra' essere in stato di riposo sul canale suddetto.
2.1.3 Metodo di prova
Tramite il Test Set di prova dovra' essere generata una Parola di
Codice tipo GTC utilizzando i valori di personalizzazione dell'unita'
radio definiti nel paragrafo 1.3. Dovranno essere effettuate prove
con il campo CHAN assumendone i seguenti valori:
A: valore '0000000000' che determina un canale indefinito.
B, C, D: valori corrispondenti a canali della rete entro i limiti
definiti nel paragrafo 1.2.
E: valore corrispondente ad un canale che supera i limiti
definiti nel paragrafo 1.2
Dopo ogni invio della parola di codice suddetta, verra' premuto il
tasto di trasmissione dell'unita' radio e verra' misurata la
frequenza della corrispondente emissione.
Per le parole di codice B, C, e D dovra' risultare una trasmissione
effettiva con frequenza entro i limiti di tolleranza rispetto al
valore nominale previsto.
Per le parole di codice A ed E non si dovra' verificare emissione da
parte del trasmettitore.
2.2 Deviazione di frequenza della segnalazione
2.2.1 Scopo della prova
Assicurare che il codificatore dei dati dell'unita' radio utilizzato
per la trasmissione delle segnalazioni sia in accordo con i requisiti
riguardanti la frequenza generata e le relative deviazioni di
frequenza, in tutto il campo di temperatura e di variazione della
tensione di alimentazione.
2.2.2 Inizializzazione
L'unita' radio sara' posizionata nel modo manuale e configurata per
permettere sia la trasmissione di un treno continuo di '0' binari,
sia un treno continuo di '1' binari in conformita' alla PARTE 1a
Sezione 2, Sezione 6.1.
2.2.3 Metodo di prova
L'unita' radio dovra' essere connessa tramite il connettore d'antenna
ad un demodulatore di frequenza a sua volta connesso ad un contatore
ad audio frequenza.
Dovra' essere misurata la frequenza modulante e la deviazione di
frequenza per i due casi di:
a) trasmissione continua di un treno di "1" binari;
b) trasmissione continua di un treno di "0" binari;
La frequenza modulante e la deviazione di picco della portante a ra-
dio frequenza dovranno essere entro i limiti specificati in 1.6.4.
Inoltre le differenze di deviazione riscontrate fra i due casi a) e
b) dovranno essere entro i limiti specificati in 1.6.4.
Dovranno inoltre essere ripetute le prove in condizioni estreme di
temperatura e di tensione di alimentazione per le quattro
combinazioni seguenti:
1. massima temperatura piu' minima tensione
2. massima temperatura piu' massima tensione
3. minima temperatura piu' massima tensione
4. minima temperatura piu' minima tensione
Per ciascuna prova la frequenza modulante a la deviazione di
frequenza di picco della portante dovranno essere entro i limiti
specificati in 1.6.4 relativi alle condizioni estreme, per tutte le 4
combinazioni di temperatura e di tensione di alimentazione.
Dovranno inoltre essere verificate per ciascuna prova le differenze
di deviazione di frequenza che dovranno rimanere entro i limiti
specificati in 1.6.4.
2.2.4 Limiti
Condizioni normali:
frequenza modulante ('1'): 1200 +- 0,12 Hz
frequenza modulante ('0'): 1800 +- 0,18 Hz
Deviazione di frequenza di picco: - Canalizzazione 12.5 KHz:
1,5 KHz +- 250 Hz
- Canalizzazione 25 KHz:
3 KHz +- 500 Hz
Condizioni estreme:
frequenza modulante ('1'): 1200 +- 0,12 Hz
frequenza modulante ('0'): 1800 +- 0,18 Hz
Deviazione di frequenza di picco: - Canalizzazione 12.5 KHZ:
1,5 KHz +- 500 Hz
- Canalizzazione 25 KHz:
3 KHz +- 1000Hz
Differenza di deviazione fra '1' e '0': minore di 300 Hz
2.3 Prestazioni in termini di tasso d'errore
2.3.1 Scopo della prova
Assicurare che l'unita' radio sia capace di soddisfare le prestazioni
in termini di tasso di errore del demodulatore di ricezione FFSK.
2.3.2 Modalita' della prova (*)
La prova verra' effettuata utilizzando i seguenti livelli di segnale
in ricezione del canale di controllo uscente:
Livello A: +8 dB rispetto a 1 (micron)V FEM equivalente a -105 dBm.
Livello B: +1 dB rispetto a 1 (micron)V FEM equivalente a -112 dBm.
Livello C: +14 dB rispetto a 1 (micron)V FEM equivalente a -99 dBm.
(*) Prima di effettuare le prove descritte in questo paragrafo e'
necessario far acquisire alla radio il canale di controllo
utilizzando un livello di segnale compatibile (per esempio -60 dBm).
Il tasso di errore e' misurato in termini di numero di rispetto ad un
numero di parole di codice AHY inviate.
La prova e' effettuata con l'ausilio di un insieme di apparati di
test connessi come indicato nell'Appendice A della PARTE 1a Sezione
1.
2.3.3 Prove con segnale al Livello A
L'unita' radio dovra' essere connessa al Test Set di prova che
generarera' la segnalazione del canale di controllo sulla frequenza
del canale 53.
L'unita' radio dovra' essere in stato di riposo sul canale suddetto.
Il livello del segnale RF del canale di controllo dovra' essere
portato al Livello A (-105 dBm).
Tramite il Test Set si dovranno inviare 100 sequenze di parole di
codice del tipo relativo alla figura A-2 dell'allegato A alla PARTE
1a SEZIONE 1 con i seguenti campi variati come segue:
SYS = '101010110000001'
PFIX = 39
IDENT = 2001
Canale di controllo = 53
CHAN4 = 0101
Preambolo = '1010101010101010'
SYNC = '1100010011010111'
CCSC = '01010101100000011100100111001110-
10101010101010101100010011010111'
MARK = '10101010101011000000110001100010-
01001101011010101100010011010111'
AHY= '10100111001111101000110001000000-
11111100100000000110101010010111'
DUMMY = '10000000000000000000010001000000-
00000000000000000110001100101001'
e dovra' essere verificato che il numero delle risposte (ACK)
dell'unita' radio non sia inferiore a 99.
2.3.4 Prove con segnale a livello B
L'unita' radio dovra' essere connessa al Test Set di prova con le
stesse modalita' della prova precedente ma con il livello di segnale
RF del canale di controllo portato al valore B (-112 dBm).
Tramite il Test Set si dovranno inviare 100 sequenze di parole di
codice del tipo menzionato nella prova precedente e dovra' essere
verificato che il numero delle risposte dell'unita' radio non sia
inferiore a 89.
2.3.5 Prove con interferenza co-canale da una sorgente audio
L'unita' radio dovra' essere connessa al Test Set di prova con le
stesse modalita' della prova precedente ma con il livello di segnale
RF del canale di controllo portato al Livello C (-99 dBm).
Dovra' inoltre essere attivato il generatore del canale interferente
sintonizzato sulla frequenza nominale del canale di controllo, con un
livello di segnale RF di 10 dB inferiore a quello del canale di
controllo e modulato con un tono a 400 Hz e con deviazione di
frequenza pari al 60% della massima deviazione di frequenza di picco
ammessa. Inviando tramite il Test Set di prova 100 sequenze di parole
di codice del tipo menzionato nella prova precedente si dovranno
contare il numero delle risposte dell'unita' radio per le seguenti
condizioni:
A. generatore interferenze alla stessa frequenza del generatore del
canale di controllo.
B. generatore interferenze ad una frequenza di 1200 Hz maggiore di
quella del generatore del canale di controllo.
C. generatore interferenze ad una frequenza di 1200 Hz inferiore a
quella del generatore del canale di controllo.
In tutte le prove dovra' essere verificato che il numero di risposte
dell'unita' radio non sia inferiore a 89.
2.3.6 Prove con interferenza co-canale da una sorgente dati
L'unita' radio dovra' essere connessa al Test Set di prova che
generera' la segnalazione del canale di controllo sulla frequenza del
canale 53.
L'unita' radio dovra' essere in stato di riposo sul canale suddetto.
Il livello del segnale RF del canale di controllo dovra' essere
portato al valore del Livello C (-99 dBm).
Il Test Set di prova dovra' inviare 100 sequenze di codice del tipo
menzionato nella prova precedente.
Dovra' essere attivato inoltre il generatore sul canale interferente
con un livello di segnale di 10 dB inferiore rispetto a quello del
canale utile ed un segnale modulante costituito da una sequenza
ripetuta di 511 bit in accordo con la raccomandazione V52 del CCITT
trasmessa a 1200 bits/secondo. Tale segnale dovra' modulare la
portante formando un segnale FFSK in accordo con il paragrafo 4.2.3
della PARTE 1a Sezione 1.
Inviando tramite il Test Set di prova 100 sequenze di parole di
codice del tipo menzionato nella prova precedente, si dovra'
verificare che il numero di risposte dell'unita' radio non sia
inferiore a 89.
2.3.7 Prova di controllo delle false attivazioni con parole di codice
non corrette
L'unita' radio dovra' essere connessa al Test Set di prova che
generera' la segnalazione del canale di controllo sulla frequenza del
canale 53, con un livello del segnale RF portato al valore di -105
dBm (Livello A).
Il Test Set di prova dovra' inviare 100 sequenza di parole di codice
del tipo menzionato nella prova precedente con la sezione
prefisso/identificativo della parola di codice AHOY selezionata in
modo che differisca di 1 bit dal prefisso/identificativo dell'unita'
radio. La posizione del bit non corretto e' diversa nelle parole di
codice AHOY successive. La parita' e' stata di volta in volta
ricalcolata al fine di ottenere una parola di codice valida. Ciascuno
dei 20 messaggi deve essere inviato 5 volte (per avere un totale di
100 messaggi). L'elenco della parole di codice AHOY modificate e' il
seguente:
1110011100111110100011000100000011111100100000000001111010011100
1000011100111110100011000100000011111100100000001011100010000111
1011011100111110100011000100000011111100100000000000001110011111
1010111100111110100011000100000011111100100000000101111000010011
1010001100111110100011000100000011111100100000000111000011010101
1010010100111110100011000100000011111100100000001000111110100010
1010011000111110100011000100000011111100100000000001100000001100
1010011110111110100011000100000011111100100000001011101111001111
1010011101111110100011000100000011111100100000000000001000111011
1010011100101110100011000100000011111100100000001001100010101000
1010011100011110100011000100000011111100100000000101111011000001
1010011100110110100011000100000011111100100000001111101110011101
1010011100111010100011000100000011111100100000001100101000000110
1010011100111100100011000100000011111100100000000011101011011110
1010011100111111100011000100000011111100100000000100001010110010
1010011100111110000011000100000011111100100000000111111010000100
1010011100111110110011000100000011111100100000001000100010001011
1010011100111110101011000100000011111100100000000001101110011001
1010011100111110100111000100000011111100100000001011101000000100
1010011100111110100010000100000011111100100000001110101011001011
Non si dovranno verificare risposte da parte dell'unita' radio.
2.4 Verifica del tempo di commutazione Rx/Tx e delle tempistiche di
protocollo
L'unita' radio dovra' essere connessa al Test Set di prova che
generera' la segnalazione del canale di controllo sulla frequenza del
canale 53.
L'unita' radio dovra' essere in stato di riposo sul canale suddetto.
Tramite il Test Set di prova si dovra' inviare il messaggio AHY
diretto all'unita' radio (contenente quindi i parametri
identificativi dell'unita' radio e l'identificativo del chiamante
scelto all'interno della flotta definita al punto 1.3.6).
Dovra' essere verificato tramite il Test Set di prova che:
1. L'unita' radio risponda con il messaggio ACK nello slot
immediatamente successivo a quello d'invio del messaggio AHY.
2. L'unita' radio risponda con tempistiche, misurate dal Test Set di
prova, in accordo alla figura 6.1 della PARTE 1a Sezion 2 ed entro i
limiti da essa specificati.
2.5 Verifica del tempo di commutazione Tx/Rx
L'unita' radio dovra' essere connessa al Test Set di prova che
generera' la segnalazione di controllo sulla frequenza del canale 53.
Il Test Set di prova sara' programmato per trasmettere un unico
messaggio di tipo AHY nello slot immediatamente successivo alla
ricezione di un messaggio di tipo RQS inviato dall'unita' radio.
Successivamente il Test Set di prova dovra' continuare con l'invio
dei messaggi ALH tipici del canale di controllo.
L'unita' radio dovra' essere in stato di riposo sul canale di
controllo.
Tramite l'unita' radio verra' effettuata la chiamata (RQS) verso un
utente della stessa flotta (vedi punto 1.3.6) ; e si dovra'
verificare che l'unita' radio stessa acquisisca la risposta del Test
Set di prova contenente il messaggio AHY rivolto all'utente chiamato.
L'unita' radio dovra' rimanere in attesa di ulteriori segnalazioni da
Test Set di prova senza effettuare altri tentativi di chiamata.
3. PROVE SULLE SEGNALAZIONI OPERATIVE
3.1 Acquisizione del canale di controllo utilizzando la procedura NHS
e CHS
L'unita' radio dovra' essere inizializzata disabilitando la scansione
generale.
L'unita' radio dovra' essere connessa al Test Set di prova generante
il canale di controllo ad una frequenza di canale compresa
nell'elenco del punto 1.2.8, con i corretti parametri dei campi SYS e
CCS del punto 1.1.3.
Inizialmente l'unita' radio dovra' essere in posizione di spento.
All'accensione dell'unita' radio dovra' essere verificato che essa
faccia partire la procedura di registrazione analizzando la
segnalazione inviata sul canale di controllo entrante (o comunque
acquisisca il canale di controllo se e' gia' registrata con quel
valore di SYS).
Successivamente l'unita' radio verra' spenta e verra' cambiata la
frequenza del canale di controllo generato dal Test Set di prova con
un valore non compreso nell'elenco del punto 1.2.8, ma all'interno
della gamma di frequenza ammessa dalla rete.
All'accensione dell'unita' radio si dovra' verificare che la radio
non riesca ad acquisire il canale (rimane in stato di "non
disponibilita' ") .
Successivamente nell'unita' radio verra' eliminata la disabilitazione
alla scansione generale.
Verra' quindi ripetuta l'operazione di accensione dell'unita' radio e
si dovra' verificare che questa acquisisca il canale di controllo.
3.2 Prove sul dispositivo di protezione
3.2.1 Rimozione del dispositivo
Dovra' essere verificato che la rimozione del dispositivo contenente
il numero di sicurezza porti una notevole probabilita' di danneggiare
l'unita' radio.
Al fine di evitare la distruzione dell'unita' radio la rispondenza al
requisito verra' determinata da una ispezione visiva oppure tramite
dichiarazione esplicita del costruttore.
3.2.2 Indicazione del numero di sicurezza
Lo scopo della prova e' quello di verificare che l'indicazione del
numero di sicurezza sia sufficientemente permanente.
L'indicazione del numero di sicurezza sara' soggetta ad un leggero
sfregamento con uno straccio imbevuto di acqua per 15 secondi e la
prova verra' ripetuta per lo stesso tempo con uno straccio imbevuto
di alcol.
Dovra' essere verificato che la indicazione sia ancora leggibile dopo
la prova e che eventuali adesivi non tendano a staccarsi oppure ad
incurvare i margini.
3.2.3 Valore del numero di sicurezza
La prova ha lo scopo di assicurare che il numero indicato all'interno
dell'unita' radio e le informazioni fornite dal costruttore
corrispondano al numero di sicurezza usato nel messaggio di risposta
alla richiesta del numero di sicurezza.
Dovra' inizialmente essere notato il numero di sicurezza letto dalla
indicazione interna alla unita' radio.
L'unita' radio sara' quindi connessa al Test Set di prova che
generera' sul canale di controllo un messaggio di richiesta di
trasmissione del numero di sicurezza (AHYC).
L'unita' radio dovra' rispondere (nello slot immediatamente
successivo) con il codice relativo alla risposta alla richiesta di
validazione del numero di sicurezza, contenente il campo SAMIS. Tale
campo dovra' quindi contenere le seguenti parti informative:
Bits 2-9 : dovranno riportare in binario il codice del costruttore
come indicato nell'unita' radio e riportato nelle informazioni
fornite dal costruttore secondo le richieste del punto 1.5.
Bits 10-13 : dovranno riportare in binario il codice del modello come
indicato sull'unita' radio e riportato nelle informazioni fornite dal
costruttore secondo le richieste del punto 1.5.
Bits 14-21 : dovranno riportare i bits di check come indicato nelle
informazioni fornite dal costruttore secondo le richieste del punto
1.5.
Bits 31-48 : dovranno riportare il numero di serie dell'unita' radio
come indicato sull'unita' radio e riportato nelle informazioni
fornite dal costruttore secondo le richieste del punto 1.5.
3.3 Prove di protocollo
3.3.1 Generalita'
L'unita' radio ed il Test Set di prova dovranno essere inizializzati
utilizzando i valori dei parametri indicati nelle condizioni generali
di prova (punto 1).
I messaggi necessari per l'effettuazione delle prove sia generati
dall'unita' radio per chiamate verso utente che generati dal Test Set
di prova per chiamate o risposte verso l'unita' radio, dovranno
essere impostati secondo il corretto formato riportato nella PARTE 1a
Sezione 2, utilizzando altresi' i parametri utilizzati per
l'inizializzazione della radio.
3.3.2 Prova di registrazione su richiesta dell'unita' radio
- Verifica del messaggio RQR da unita' radio Tale invio viene
provocato effettuando una variazione nel valore del solo campo AREA
del SYS scegliendolo fra i valori elencati nel punto 1.2.1.
- Verifica della corretta ricezione da parte dell'unita' radio del
messaggio ACK generato dal Test Set di prova, constatando l'avvenuta
registrazione.
- Verifica della corretta ricezione da parte dell'unita' radio del
messaggio ACKX, constatando la non avvenuta registrazione.
3.3.3 Prova di registrazione su richiesta da TSC
L'unita' radio dovra' essere registrata correttamente (ad es. tramite
la prova precedente e la ricezione del messaggio ACK generato da Test
Set di prova).
- Invio del messaggio ALHR da parte del Test Set di prova.
- Verifica della risposta RQR della radio sul canale di controllo
entrante.
- Verifica della corretta ricezione da parte dell'unita' radio del
messaggio ACK generato dal Test Set di prova, constatando la conferma
di registrazione.
- Verifica della corretta ricezione da parte dell'unita' radio del
messaggio ACKX, constatando il passaggio in stato di non
registrazione.
3.3.4 Prova di chiamata semplice e numero massimo di richieste
d'accesso da unita' radio
L'unita' radio dovra' essere registrata correttamente (ad es. tramite
la prova precedente e la ricezione del messaggio ACK generato dal
Test Set di prova).
- Invio del messaggio RQS da unita' radio tramite selezione
dell'utente desiderato secondo le modalita' proprie dell'unita' radio
stessa.
- Verifica della corretta ricezione del messaggio AHY generato da
Test Set di prova.
- Verifica della corretta ricezione da parte dell'unita' radio del
messaggio GTC generato dal Test Set di prova constatando il passaggio
dell'unita' radio nello stato di conversazione sul canale indicato
nel messaggio GTC.
Al fine della verifica del numero massimo di richieste di accesso da
unita' radio dovra' essere verificato che a seguito di una mancanza
di risposta del Test Set (mancato invio del messaggio AHY e
successivo GTC), l'unita' radio ripeta la chiamata per un numero
massimo di volte pari ad 8 (vedi Appendice B della PARTE 1a sezione
1, Tabella B1).