Convalida del throughput wireless 802.11ax e test di convalida

Introduzione

In questo documento viene descritto come testare il throughput wireless di un access point basato su 802.11ax e quale throughput attendersi.

Prerequisiti

Requisiti

In questo documento si presume che l'installazione sia già funzionante con punti di accesso 802.11ax / Wi-Fi 6 (AP) che offrono già la connettività ai client

Componenti usati

Le informazioni di questo documento si basano sulla tecnologia e sulle velocità 802.11ax/Wi-Fi 6.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Comprendere

Wi-Fi 6 può funzionare su diverse bande: 2,4 Ghz, 5 Ghz e anche la banda 6 Ghz, come previsto dalla certificazione Wi-Fi 6E.

802.11ac è arrivato in due ondate. La seconda ondata portò il supporto del canale da 160 Mhz, insieme a MU-MIMO e un massimo teorico di 8 flussi spaziali.

Questi numeri sono solo i numeri teorici dello standard; le differenze si applicano a seconda del foglio dati AP specifico.

802.11ax non è direttamente definito in velocità di dati, ma è piuttosto una combinazione di schema di codifica a modulazione 12 (MCS 0 a MCS 11), una larghezza di canale che va da 20mhz (1 canale) a 160Mhz (8 canali), una serie di flussi spaziali (tipicamente 1 a 2, ci sono stati alcuni 3 prodotti di flussi spaziali, ma sono sempre meno visti).

Anche l'intervallo di guardia breve, medio o lungo (GI) aggiunge circa il 10% di modifiche a questo.

Di seguito è riportata una tabella per valutare una velocità di trasferimento dati in Mbps se si conoscono tutti questi fattori:

Una tabella più completa è disponibile all'indirizzo: https://mcsindex.com/

Nota: la velocità dati NON è uguale alla velocità effettiva raggiungibile prevista. Ciò è dovuto alla natura dello standard 802.11, che ha un notevole sovraccarico amministrativo (frame di gestione, contesa, collisione, riconoscimenti,...) e può dipendere dal collegamento SNR, RSSI e altri fattori significativi.

È una regola pratica:

Throughput previsto = Data Rate x 0,65

Prendiamo un esempio di vita reale. Un Cisco 9120 AP con un moderno smartphone Wi-Fi 6 capace di 2 flussi spaziali. In un ambiente ad alta densità in cui vengono utilizzati canali a 20 Mhz, la velocità massima dei dati utilizzata è compresa tra 240 e 280 Mbps, a seconda dell'intervallo di guardia. Ciò significa che, in un ambiente pulito e in condizioni di test, potremmo avere un client che trasferisce i dati tra 160 e 200 Mbps possibilmente (dal 65 al 70% di efficienza del protocollo). Questa opzione è valida solo quando si esegue un test di trasferimento o di velocità elevato effettivo in cui il protocollo è ottimizzato per il massimo throughput dei dati. Quando si usano altre applicazioni, la velocità di trasmissione diminuisce perché la latenza svolge un ruolo importante nei protocolli che eseguono il ping dei pacchetti e che attendono le conferme prima di procedere.

Tenere presente che la connettività wireless è un ambiente condiviso, il che significa che la quantità di client connessi all'access point condivide il throughput effettivo tra di loro. Se un client che esegue un test di velocità può raggiungere i 160-200 MB/s, ciò significa che due client che eseguono un test di velocità contemporaneamente vedono ogni 80-100 Mbps. Se quattro client eseguono un test di velocità contemporaneamente, la velocità può variare da 40 a 50 Mbps ciascuno e così via...

Inoltre, sempre più clienti implicano più conflitti e inevitabilmente ancora più collisioni. L'efficienza della cellula di copertura diminuisce drasticamente con l'aumento del numero di clienti. Non è quindi realistico impostare alcun tipo di SLA per il throughput in luoghi in cui non si controlla la quantità di client connessi o ciò che stanno facendo sulla rete in termini di attività.

Misura

In generale, quando si esegue un test del throughput possono verificarsi due scenari:

• Gli access point sono in modalità di switching locale Flexconnect

• I punti di accesso sono in modalità locale o in modalità di commutazione centrale Flexconnect

Considera questi scenari uno per uno:

(Grafico 1)

Nel caso del diagramma 1, si suppone che gli access point siano in modalità locale e che la commutazione centrale Flexconnect sia in modalità locale.

Ciò significa che tutto il traffico del client viene incapsulato nel tunnel CAPWAP e terminato sul WLC.

(Grafico 2)

La linea rossa nel diagramma 2 mostra il flusso del traffico proveniente dal client wireless.

Il server iPerf deve essere il più vicino possibile al punto di terminazione del traffico, preferibilmente collegato allo stesso switch del WLC e usare la stessa VLAN.

Nel caso della commutazione locale Flexconnect, il traffico del client viene terminato sull'access point stesso. Considerando che il server iPerf deve essere impostato in modo che si avvicini al punto di terminazione del traffico dei client wireless, collegare il server iPerf allo stesso switch e alla stessa VLAN a cui è collegato l'access point.

Nel nostro caso si tratta di uno switch di accesso (diagramma 3).

(Grafico 3)

I test iPerf possono essere suddivisi in due categorie: a monte e a valle.

Tenendo presente che il server iPerf è in ascolto e che il client iPerf sta generando il traffico, quando il server iPerf si trova sul lato cablato, questo test viene considerato a monte.

Il client wireless sta utilizzando l'applicazione iPerf per inviare il traffico alla rete.

Il test in downstream è viceversa, ovvero il server iPerf è impostato sul client wireless stesso e il client iPerf è sul lato cablato che spinge il traffico verso il client wireless. In questo scenario, questo viene considerato downstream.

Il test deve essere eseguito utilizzando TCP e UDP. Per eseguire i test, è possibile utilizzare i seguenti comandi:

iperf3 -s  <- this command starts iPerf server

iperf3 -c SERVER_ADDRESS -u -b700M <- this command initiates UDP iPerf test with bandwidth of 700 Mbps

iperf3 -c SERVER_ADDRESS <- this command initiates a simple TCP iPerf test

iperf3 -c SERVER_ADDRESS  -w WINDOW_SIZE  -P NUM_OF_PARALLEL_TCP_STREAMS <- this commands initiates a more complex  TCP iPerf test where you can adjust the window size as well the number of parallel TCP streams. 
Please not that in this case you should consider the sum of all the streams as the result

 

Esempio di output iPerf3:

TCP iPerf3:

 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec   188 MBytes   157 Mbits/sec                  receiver
 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.05  sec   304 MBytes   254 Mbits/sec                  receiver

   With 10 parallel TCP streams:
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec  88.6 MBytes  73.9 Mbits/sec                  receiver
[  7]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  7]   0.00-10.06  sec  79.2 MBytes  66.0 Mbits/sec                  receiver
[  9]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  9]   0.00-10.06  sec  33.6 MBytes  28.0 Mbits/sec                  receiver
[ 11]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 11]   0.00-10.06  sec  48.7 MBytes  40.6 Mbits/sec                  receiver
[ 13]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 13]   0.00-10.06  sec  77.0 MBytes  64.2 Mbits/sec                  receiver
[ 15]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 15]   0.00-10.06  sec  61.8 MBytes  51.5 Mbits/sec                  receiver
[ 17]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 17]   0.00-10.06  sec  46.1 MBytes  38.4 Mbits/sec                  receiver
[ 19]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 19]   0.00-10.06  sec  43.9 MBytes  36.6 Mbits/sec                  receiver
[ 21]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 21]   0.00-10.06  sec  33.3 MBytes  27.8 Mbits/sec                  receiver
[ 23]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 23]   0.00-10.06  sec  88.8 MBytes  74.0 Mbits/sec                  receiver
[SUM]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[SUM]   0.00-10.06  sec   601 MBytes   501 Mbits/sec                  receiver
 

UDP iPerf3:

Quando si utilizza il protocollo UDP, è importante assicurarsi che non vi siano perdite di pacchetti troppo ridotte. È possibile vedere numeri con un throughput molto elevato, ma se si ha una perdita di pacchetti del 50%, in realtà non si è trasferita quella quantità di dati.

A volte iPerf non si comporta correttamente e non fornisce la larghezza di banda media al termine del test UDP.

È ancora possibile sommare la larghezza di banda per ogni secondo e quindi dividerla per numero di secondi:

Accepted connection from 192.168.240.38, port 49264
[  5] local 192.168.240.43 port 5201 connected to 192.168.240.38 port 51711
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  53.3 MBytes   447 Mbits/sec  0.113 ms  32/6840 (0.47%)  
[  5]   1.00-2.00   sec  63.5 MBytes   533 Mbits/sec  0.129 ms  29/8161 (0.36%)  
[  5]   2.00-3.00   sec  69.8 MBytes   586 Mbits/sec  0.067 ms  30/8968 (0.33%)  
[  5]   3.00-4.00   sec  68.7 MBytes   577 Mbits/sec  0.071 ms  29/8827 (0.33%)  
[  5]   4.00-5.00   sec  68.0 MBytes   571 Mbits/sec  0.086 ms  55/8736 (0.63%)  
[  5]   5.00-6.00   sec  68.6 MBytes   576 Mbits/sec  0.076 ms  70/8854 (0.79%)  
[  5]   6.00-7.00   sec  66.8 MBytes   561 Mbits/sec  0.073 ms  34/8587 (0.4%)  
[  5]   7.00-8.00   sec  67.1 MBytes   563 Mbits/sec  0.105 ms  44/8634 (0.51%)  
[  5]   8.00-9.00   sec  66.7 MBytes   559 Mbits/sec  0.183 ms  144/8603 (1.7%)  
[  5]   9.00-10.00  sec  64.1 MBytes   536 Mbits/sec  0.472 ms  314/8415 (3.7%)  
[  5]  10.00-10.05  sec   488 KBytes  76.0 Mbits/sec  0.655 ms  2/63 (3.2%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec  0.655 ms  783/84688 (0.92%)  
[SUM]  0.0-10.1 sec  224 datagrams received out-of-order

Nota: si prevede che i risultati di iPerf siano leggermente migliori sullo switch locale Flexconnect rispetto allo scenario di switching centrale.
Questo è causato dal fatto che il traffico dei client è incapsulato in CAPWAP, che aggiunge un maggiore sovraccarico al traffico e in generale il WLC agisce come un collo di bottiglia poiché è il punto di aggregazione per tutto il traffico dei client wireless.
Inoltre, si prevede che il test UDP iPerf darà risultati migliori in un ambiente pulito, in quanto è il metodo di trasferimento più efficiente quando la connessione è affidabile. TCP, tuttavia, può vincere in caso di frammentazione grave (quando si utilizza TCP Adjust MSS) o di connessione inaffidabile

.

Verifica e convalida

Per verificare a quale velocità dati è connesso il client, usare questi comandi dalla CLI del WLC:

WLC#show wireless client mac e88d.a6b0.3bca det

Client MAC Address : e88d.a6b0.3bca
Client MAC Type : Universally Administered Address
Client DUID: NA
Client IPv4 Address : 192.168.1.44
Client IPv6 Addresses : fe80::7798:a5a:a957:ec89
Client Username: N/A
AP MAC Address : 18f9.354d.9d60
AP Name: 9164-etage
AP slot : 1
Client State : Associated
Policy Profile : Darchispp
Flex Profile : default-flex-profile
Wireless LAN Id: 2
WLAN Profile Name: Darchis6
Wireless LAN Network Name (SSID): Darchis6
BSSID : 18f9.354d.9d6f
Connected For : 103 seconds
Protocol : 802.11ax - 5 GHz
Channel : 52
Client IIF-ID : 0xa0000003
Association Id : 2
Authentication Algorithm : Open System
Idle state timeout : N/A
Session Timeout : 80000 sec (Remaining time: 79899 sec)
Session Warning Time : Timer not running
Input Policy Name  : None
Input Policy State : None
Input Policy Source : None
Output Policy Name  : None
Output Policy State : None
Output Policy Source : None
WMM Support : Enabled
U-APSD Support : Disabled
Fastlane Support : Disabled
Client Active State : Active
Power Save : ON
Current Rate : m10 ss2
Supported Rates : 54.0
AAA QoS Rate Limit Parameters:
  QoS Average Data Rate Upstream             :  (kbps)
  QoS Realtime Average Data Rate Upstream    :  (kbps)
  QoS Burst Data Rate Upstream               :  (kbps)
  QoS Realtime Burst Data Rate Upstream      :  (kbps)
  QoS Average Data Rate Downstream           :  (kbps)
  QoS Realtime Average Data Rate Downstream  :  (kbps)
  QoS Burst Data Rate Downstream             :  (kbps)
  QoS Realtime Burst Data Rate Downstream    :  (kbps)
Mobility:
  Move Count                  : 0
  Mobility Role               : Local
  Mobility Roam Type          : None
  Mobility Complete Timestamp : 02/26/2024 14:35:10 Central
Client Join Time:
  Join Time Of Client : 02/26/2024 14:35:10 Central
Client State Servers : None
Client ACLs : None
Policy Manager State: Run
Last Policy Manager State : IP Learn Complete
Client Entry Create Time : 103 seconds
Policy Type : WPA3
Encryption Cipher : CCMP (AES)
Authentication Key Management : FT-SAE
AAA override passphrase : No
SAE PWE Method : Hash to Element(H2E)
Transition Disable Bitmap : None
User Defined (Private) Network : Disabled
User Defined (Private) Network Drop Unicast : Disabled
Encrypted Traffic Analytics : No
Protected Management Frame - 802.11w : Yes
EAP Type : Not Applicable
VLAN Override after Webauth : No
VLAN : default
Multicast VLAN : 0
VRF Name : N/A
WiFi Direct Capabilities:
  WiFi Direct Capable           : No
Central NAT : DISABLED
Session Manager:
  Point of Attachment : capwap_90000002
  IIF ID             : 0x90000002
  Authorized         : TRUE
  Session timeout    : 80000
  Common Session ID: 00000000000041B8E5D75432
  Acct Session ID  : 0x00000000
  Auth Method Status List
  	Method : FT-SAE
  Local Policies:
  	Service Template : wlan_svc_Darchispp (priority 254)
  		VLAN             : 1
  		Absolute-Timer   : 80000
  Server Policies:
  Resultant Policies:
  		VLAN Name        : default
  		VLAN             : 1
  		Absolute-Timer   : 80000
DNS Snooped IPv4 Addresses : None
DNS Snooped IPv6 Addresses : None
Client Capabilities
  CF Pollable : Not implemented
  CF Poll Request : Not implemented
  Short Preamble : Not implemented
  PBCC : Not implemented
  Channel Agility : Not implemented
  Listen Interval : 0
Fast BSS Transition Details :
  Reassociation Timeout : 20
11v BSS Transition : Implemented
11v DMS Capable : No
QoS Map Capable : No
FlexConnect Data Switching : Local
FlexConnect Dhcp Status : Local
FlexConnect Authentication : Local
Client Statistics:
  Number of Bytes Received from Client : 64189
  Number of Bytes Sent to Client : 85831
  Number of Packets Received from Client : 808
  Number of Packets Sent to Client : 244
  Number of Data Retries : 66
  Number of RTS Retries : 0
  Number of Tx Total Dropped Packets : 0
  Number of Duplicate Received Packets : 0
  Number of Decrypt Failed Packets : 0
  Number of Mic Failured Packets : 0
  Number of Mic Missing Packets : 0
  Number of Policy Errors : 0
  Radio Signal Strength Indicator : -41 dBm
  Signal to Noise Ratio : 52 dB
Fabric status : Disabled
Radio Measurement Enabled Capabilities
  Capabilities: None
Client Scan Report Time : Timer not running
Client Scan Reports
Assisted Roaming Neighbor List
Nearby AP Statistics:
EoGRE : Pending Classification
Device Classification Information:
  Device Type      : Un-Classified Device
  Device Name      : Unknown Device
  Protocol Map     : 0x000001  (OUI)
Max Client Protocol Capability:
WiFi to Cellular Steering : Not implemented
Cellular Capability : N/A
Advanced Scheduling Requests Details:
  Apple Specific Requests(ASR) Capabilities/Statistics:
    Regular ASR support: DISABLED

È possibile visualizzare la velocità di connessione di questo particolare client:

Tasso corrente..................................... m10 ss2

Ciò significa che il client sta utilizzando l'indice MCS 10 (m10) su due flussi spaziali (ss2)

Dal comando "show wireless client mac <MAC> det", non è possibile verificare se il client è connesso tramite il collegamento dei canali a 20/40/80 MHz.

Questa operazione può essere eseguita direttamente sul punto di accesso:

9164 esempio:

#show controllers dot11Radio 2 client E8:8D:A6:B0:3B:CA
              mac radio vap aid state       encr  Maxrate Assoc   Cap is_wgb_wired      wgb_mac_addr
E8:8D:A6:B0:3B:CA     2   0  33   FWD AES_CCM128 MCS112SS HE-6E HE-6E        false 00:00:00:00:00:00
Configured rates for client E8:8D:A6:B0:3B:CA
Legacy Rates(Mbps): 6 9 12 18 24 36 48 54
HE Rates: 1SS:M0-11 2SS:M0-11
HT:yes     VHT:no     HE:yes     40MHz:no     80MHz:yes     80+80MHz:no     160MHz:yes
11w:yes     MFP:no     11h:no     session_timeout: 79950     encrypt_policy: 4
_wmm_enabled:yes     qos_capable:yes     WME(11e):no     WMM_MIXED_MODE:no
short_preamble:no     short_slot_time:no     short_hdr:no     SM_dyn:no
short_GI_20M:no     short_GI_40M:no     short_GI_80M:no     LDPC:no     AMSDU:yes     AMSDU_long:no
su_mimo_capable:no     mu_mimo_capable:no     is_wgb_wired:no     is_wgb:no
HE_DL-MIMO:yes     HE_UL-MIMO:yes     HE_DL-OFDMA:yes     HE_UL-OFDMA:yes     HE_TWT_CAPABLE:no

Additional info for client E8:8D:A6:B0:3B:CA
RSSI: -52
SNR: 41
PS  : Legacy (Sleeping)
Tx Rate: 1297100 Kbps
Rx Rate: 1921600 Kbps
VHT_TXMAP: 0
CCX Ver: 0
Rx Key-Index Errs: 0

Statistics for client E8:8D:A6:B0:3B:CA
              mac   intf TxData TxMgmt TxUC TxBytes TxFail TxDcrd TxCumRetries RxData RxMgmt RxBytes RxErr                      TxRt(Mbps) RxRt(Mbps) idle_counter stats_ago expirat
ion
E8:8D:A6:B0:3B:CA apr2v0    391      4  391  129127      0      0           97    559      4   74055     0 HE-160,2SS,MCS6,GI0.8 ,BF(1297)         12          295  8.674000      79
950

Per TID packet statistics for client E8:8D:A6:B0:3B:CA
Priority Rx Pkts Tx Pkts Rx(last 5 s) Tx (last 5 s)
       0     539     383           84            28
       1       0       0            0             0
       2       0       2            0             0
       3       0       0            0             0
       4       0       0            0             0
       5       0       0            0             0
       6      20       3            5             1
       7       0       3            0             0

 Rate Statistics:
Rate-Index    Rx-Pkts    Tx-Pkts Tx-Retries
         0        176          3          0
         5          0         62          0
         6          4        178         21
         7        250        152         52
         8        100          2         22
         9         51          0          0
        10          1          0          0
        11          0          0          2
webauth done: true
Pre-WebAuth ACLs:
Post-Auth ACLs:
Acl name Quota Bytes left In bytes Out bytes In pkts Out pkts Drops-in Drops-out
iPSK TAG: \<0000000000000000>
              MAC Allow HIT iPSK tag
E8:8D:A6:B0:3B:CA  true   0      \<>

L'ultima opzione per controllare la velocità connessa è catturazioni OTA. Nelle informazioni radio del pacchetto di dati, è possibile trovare le informazioni necessarie:

 Questa acquisizione OTA è stata eseguita con un client macbook 11ac.

Risoluzione dei problemi

Se non si ottengono i risultati previsti durante il test, sono disponibili diversi modi per risolvere il problema e raccogliere le informazioni necessarie prima di aprire una richiesta TAC.

I problemi relativi al throughput possono essere causati da quanto segue:

- Cliente

- AP

- Percorso cablato (problemi correlati alla commutazione)

-WLC

Risoluzione dei problemi del client

• Il primo passaggio consiste nell'aggiornare i driver dei dispositivi client wireless all'ultima versione
• Il secondo passaggio consiste nell'eseguire il test iPerf con i client che dispongono di una scheda wireless diversa per verificare se si ottengono gli stessi risultati

Risoluzione dei problemi dei punti di accesso

In alcuni casi, il punto di accesso sta diminuendo il traffico, oppure determinati frame o si comporta in modo errato.

Per ottenere maggiori informazioni, sono necessarie acquisizioni over the air (OTA) e sessioni span sull'access point switchport (lo span deve essere eseguito sullo switch a cui è collegato l'access point)

L'OTA acquisisce e l'SPAN devono essere eseguiti durante il test, usando un SSID aperto per poter vedere il traffico trasmesso all'access point e il traffic access point sta passando verso il client e viceversa.

Sono noti diversi bug per questo comportamento:

CSCvg07438 : AP3800: Basso throughput a causa della perdita di pacchetti nei punti di accesso sia in pacchetti frammentati che in pacchetti non frammentati

CSCva58429 : Cisco 1532i AP: throughput basso (FlexConnect Local switching + EoGRE)

Risoluzione dei problemi relativi ai percorsi cablati

Potrebbero essersi verificati alcuni problemi sullo switch stesso. È necessario verificare la quantità di perdite sulle interfacce e controllare se tali perdite aumentano durante i test.

Provare a utilizzare un'altra porta sullo switch per collegare il punto di accesso o il WLC.

In alternativa è possibile collegare un client allo stesso switch (a cui è collegato il punto di terminazione del client [AP/WLC]) e collegarlo alla stessa VLAN, quindi eseguire i test da cablato a cablato sulla stessa VLAN per verificare se sono presenti problemi nel percorso cablato.

risoluzione dei problemi WLC

È possibile che il WLC stia scaricando il traffico (quando i punti di accesso sono in modalità locale) dal client.

È possibile mettere l'access point in modalità Flexconnect e la WLAN in modalità di commutazione locale, quindi eseguire i test.

Se si riscontrano differenze significative nella velocità di trasmissione in modalità locale (commutazione centrale) rispetto alla commutazione locale di Flexconnect e non vi sono problemi sullo switch collegato al WLC, è molto probabile che il WLC stia riducendo il traffico.

Per risolvere il problema, applicare il piano d'azione:

- Le acquisizioni SPAN sulla porta dello switch WLC (devono essere effettuate sullo switch)

- Acquisizioni SPAN sulla porta AP

- Acquisizioni OTA del client

Eseguendo questa procedura di risoluzione dei problemi e fornendo i risultati a TAC, il processo di risoluzione dei problemi risulta più rapido.