Radio over IP 게이트웨이는 온라인 상태이고, 연결 가능하며, 오디오를 전송하고 있음에도 전체 통신 경로의 성능은 여전히 저조할 수 있습니다. 현장 배포에서 더 어려운 문제는 일반적으로 게이트웨이가 연결될 수 있는지 여부가 아니라, 지연이 어디에서 발생하는지, PTT 응답이 사이트 간에 왜 다른지, 또는 WAN이 사용 중일 때만 오디오가 불안정해지는 이유입니다.

RoIP 시스템을 종단 간 블랙박스가 아닌 일련의 측정 가능한 섹션으로 취급하면 이러한 오류를 더 쉽게 해결할 수 있습니다. 무선 키잉, 게이트웨이 처리, 패킷 전송, VPN 처리, 지터 버퍼 및 원격 RF 경로는 각각 고유한 지연 또는 장애 지점에 기여할 수 있습니다.

배포 작업에서 유용한 질문은 단순히 게이트웨이가 올바르게 구성되었는지 여부가 아닙니다. 통신 체인의 각 섹션이 측정, 검증 및 문서화되었는지 여부입니다.

1. 매개변수 변경 전 RoIP 경로 매핑

코덱 설정, PTT 지연 또는 QoS 정책을 변경하기 전에 프로젝트에서 사용하는 실제 통신 경로를 그리십시오. 두 끝점 사이의 무선 장비 및 네트워크 장치를 포함하십시오.

일반적인 다중 사이트 경로는 다음과 같을 수 있습니다.

무선기 → RoIP 게이트웨이 → LAN 스위치 → 라우터 → VPN/WAN → 라우터 → 디스패치 플랫폼 또는 원격 게이트웨이 → 무선기

정확한 토폴로지는 더 복잡할 수 있습니다. 원격 사이트는 광섬유를 기본 연결로 사용하고 4G/5G를 백업으로 사용할 수 있습니다. 제어 센터는 RoIP 플랫폼을 방화벽 뒤에 배치할 수 있습니다. 일부 프로젝트는 무선 트래픽을 전용 VLAN으로 분리하거나 회사 VPN을 통해 라우팅하기도 합니다.

시운전 중 중요한 것은 한 섹션이 끝나고 다음 섹션이 시작되는 위치를 아는 것입니다.

유용한 테스트 지점에는 일반적으로 다음이 포함됩니다.

• 게이트웨이로 들어오는 무선 수신 오디오;

• 무선기로 들어가는 게이트웨이 송신 오디오;

• 게이트웨이의 PTT 출력;

• 무선 송신 활성화;

• 로컬 게이트웨이에서 나가는 IP 미디어;

• 원격 끝점에 도착하는 IP 미디어;

• 원격 게이트웨이 오디오 출력;

• 및 수신 무선기가 듣는 최종 RF 송신.

이 맵은 모든 후속 테스트의 기초가 됩니다. 운영자가 지연되거나 끊긴 오디오를 보고하면 엔지니어는 관련 없는 여러 매개변수를 동시에 변경하는 대신 각 섹션을 개별적으로 확인할 수 있습니다.

관련 RoIP 솔루션: Radio Over IP 게이트웨이 시스템

2. 전체 무선 경로에 대한 지연 예산 수립

단일 ping 결과는 RoIP 응답 시간을 설명하지 않습니다. Ping은 주로 네트워크 연결성 및 IP 왕복 지연을 보여줍니다. 무선 운영자는 PTT가 요청될 때 시작하여 유용한 음성이 원격 무선기에 도달할 때 끝나는 더 긴 체인을 경험합니다.

문제 해결을 위해 총 지연을 개별 구성 요소로 분할하십시오.

총 RoIP 응답 = PTT 처리 + 로컬 게이트웨이 처리 + 패킷화 + IP 전송 + 지터 버퍼 + 원격 처리 + 무선 키잉 + RF 시스템 지연

각 구성 요소의 정확한 기여도는 장비와 네트워크에 따라 다릅니다. 지연 예산의 목적은 모든 프로젝트를 하나의 고정된 숫자로 강제하는 것이 아닙니다. 지연이 실제로 어디에서 추가되고 있는지 식별하는 것입니다.

네트워크 지연과 무선 지연 분리

WAN 경로는 안정적이지만 사용자가 여전히 PTT 응답이 느리다고 보고한다고 가정해 보겠습니다. 대부분의 지연이 무선 키잉 시간이나 큰 지터 버퍼에서 발생하는 경우 네트워크 지연을 줄여도 문제가 해결되지 않을 수 있습니다.

그 반대도 발생할 수 있습니다. 두 사이트 모두에서 무선 키잉이 빠를 수 있지만, 부하가 많이 걸린 WAN 또는 VPN 경로가 게이트웨이 간에 가변 지연을 도입합니다.

이 두 가지 오류는 서로 다른 시정 조치가 필요하므로 총 지연을 측정 가능한 섹션으로 분할해야 합니다.

다양한 조건에서 동일한 경로 측정

네트워크가 유휴 상태일 때 지연 시간을 기록한 다음, 정상적인 업무 트래픽 중에 동일한 테스트를 반복하십시오. 가능하다면 WAN에 의도적으로 제어된 부하를 가한 상태에서 다시 테스트하십시오.

유용한 비교는 다음과 같습니다.

• 유휴 네트워크 지연;

• 정상 운영 지연;

• 최대 부하 지연;

• 및 보조 WAN이 사용되는 경우 백업 링크 지연.

유휴 상태에서는 허용되지만 운영 트래픽 중에는 일관성이 없어지는 링크는 일반적으로 무선 인터페이스 문제보다는 네트워크 용량, 큐잉 또는 경로 품질 문제를 가리킵니다.

3. PTT-오디오 타이밍을 추측하지 말고 측정

PTT 타이밍은 종종 시행 착오를 통해 조정됩니다. 더 안정적인 방법은 여러 이벤트를 순서대로 측정하고 유용한 오디오가 정확히 어디에서 시작되는지 식별하는 것입니다.

예를 들어:

• T0: 원격 PTT 명령이 발행됨;

• T1: 게이트웨이 PTT 출력이 상태 변경;

• T2: 연결된 무선기가 송신 모드로 전환;

• T3: RF 캐리어를 사용할 수 있음;

• T4: RF 채널에서 유용한 음성이 시작됨.

이러한 지점 간의 차이는 시스템을 단순히 "PTT 지연이 높다"고 설명하는 것보다 훨씬 더 유용한 정보를 제공합니다.

T0과 T1 사이의 지연이 과도한 경우 제어 신호 또는 게이트웨이 처리를 조사하십시오. T1이 빠르게 발생하지만 T2 또는 T3가 느린 경우 무선 장비 또는 무선 인터페이스를 확인해야 합니다. RF 캐리어가 이미 설정되었지만 음성이 늦게 도착하는 경우 오디오 경로 및 미디어 버퍼링을 조사하십시오.

리드 타임 설정 시 실제 무선기 사용

PTT 리드 타임은 연결된 무선기 또는 리피터에 맞춰야 합니다. 다른 장비는 PTT 활성화와 유용한 오디오 사이에 다른 간격이 필요할 수 있습니다.

다른 프로젝트에서 복사한 값은 작동하는 것처럼 보일 수 있지만 여전히 음성이 잘리거나 불필요한 지연이 발생할 수 있습니다.

동일한 원칙이 릴리스 타이밍에도 적용됩니다. 최종 오디오가 무선기를 떠나기 전에 PTT가 해제되면 마지막 음절이 잘릴 수 있습니다. 너무 오래 유지하면 음성이 끝난 후에도 채널이 계속 점유됩니다.

목표는 가능한 가장 짧은 지연이 아닙니다. 목표는 실제 무선 장비로 완전하고 반복 가능한 전송을 여전히 생성하는 가장 짧은 타이밍입니다.

4. 구성 화면이 아닌 혼잡 상태에서 QoS 검증

QoS는 구성 페이지에서 추정하는 것이 아니라 트래픽 동작을 통해 입증되어야 합니다.

게이트웨이는 실시간 트래픽을 올바르게 표시할 수 있지만, 중간 스위치, 방화벽, VPN 장치 또는 WAN 서비스가 해당 표시를 변경하거나 무시할 수 있습니다. 따라서 양쪽 끝의 구성은 올바르게 보일 수 있지만 혼잡 시 RoIP 트래픽이 여전히 대량 데이터와 경쟁할 수 있습니다.

실용적인 테스트는 제어된 부하에서 RoIP 경로를 관찰하는 것입니다.

테스트는 단계적으로 수행할 수 있습니다.

1. 정상적인 무선 통화를 설정하고 지연, 지터 및 패킷 손실을 기록합니다.

2. 동일한 WAN 경로에 백그라운드 트래픽을 도입합니다.

3. PTT 및 오디오 테스트를 반복합니다.

4. 패킷 표시가 경로를 따라 변경되지 않았는지 확인합니다.

5. 혼잡이 발생하는 라우터 또는 방화벽 큐를 검사합니다.

6. 결과를 유휴 네트워크 기준선과 비교합니다.

백그라운드 트래픽이 증가하는 동안 RoIP 경로가 안정적으로 유지되면 네트워크 정책이 제 역할을 하고 있는 것입니다. 음성이 끊기기 시작하거나 지연이 급격하게 변동하는 경우 게이트웨이 오디오 또는 무선 설정을 변경하기 전에 사용 가능한 대역폭 및 큐 동작을 조사하십시오.

QoS는 충분한 대역폭을 대체할 수 없습니다

우선 처리는 경합 중에 실시간 트래픽을 돕지만 존재하지 않는 용량을 생성하지는 않습니다. 영구적으로 포화된 WAN 링크에는 여전히 대역폭 또는 트래픽 엔지니어링 솔루션이 필요합니다.

이는 RoIP가 CCTV, 파일 동기화, 사무실 애플리케이션 또는 기타 대용량 서비스와 동일한 연결을 공유하는 네트워크에서 특히 중요합니다.

백업 링크를 별도로 확인

프로젝트가 4G/5G 또는 다른 보조 연결을 사용하는 경우 기본 WAN의 QoS 동작이 백업 경로에도 적용된다고 가정하지 마십시오.

백업 경로는 다른 지연, 지터, 패킷 손실 특성 또는 트래픽 정책을 가질 수 있습니다. 따라서 별도의 통신 경로로 측정해야 합니다.

5. 세그먼트별로 장애 위치 파악

여러 게이트웨이 매개변수를 동시에 변경하면 원래 오류가 구성 변경 사항 사이에 사라져 문제 해결이 더 어려워집니다. 더 나은 방법은 경로를 격리하고 문제가 처음 나타나는 세그먼트를 확인하는 것입니다.

알려진 양호한 세그먼트를 사용하여 검색 범위 좁히기

로컬 무선-게이트웨이 오디오가 이미 검증된 경우 WAN 문제를 조사하는 동안 해당 인터페이스를 반복적으로 조정하지 마십시오. 검증된 각 세그먼트를 변경하지 않고 다음 테스트 지점으로 이동하십시오.

동일한 방법이 반대 방향에서도 작동합니다. RTP 또는 기타 IP 미디어가 패킷 손실 없이 원격 게이트웨이에 도달하지만 RF 출력이 좋지 않은 경우 네트워크 조정으로 문제를 해결할 가능성이 낮습니다.

세그먼트 기반 테스트는 다중 사이트 시스템에서 특히 유용합니다. 동일한 게이트웨이 모델이 여러 위치에서 올바르게 작동할 수 있지만 한 사이트는 다르게 동작하기 때문입니다. 양호한 사이트와 불량 사이트 간의 측정 지점을 비교하면 차이가 무선 인터페이스, WAN 경로 또는 로컬 네트워크 중 어디에 있는지 신속하게 식별할 수 있습니다.

6. 인계 전 배포 기준선 기록

RoIP 시스템은 최종 작동 값이 인계 전에 기록될 때 유지 관리가 더 쉽습니다. 기준선이 없으면 이후 라우터 교체, 무선 변경 또는 소프트웨어 업그레이드 시 기술자가 현재 매개변수가 원본인지 이미 수정된 것인지 확신하지 못할 수 있습니다.

배포 기록에는 비교에 유용한 값이 포함되어야 하며 장비 구성의 모든 페이지가 포함되어서는 안 됩니다.

측정값은 실험실 구성에서 복사하는 대신 실제 운영 경로에서 기록해야 합니다. 가능한 경우 정상 작동 값과 혼잡 네트워크 또는 장애 조치 테스트 중에 기록된 결과를 모두 보관하십시오.

이 기준선은 구성 요소가 변경될 때마다 유용해집니다. 새 라우터가 지연을 증가시키거나, 교체 무선기가 다른 PTT 리드 타임을 요구하거나, 새 WAN 서비스가 더 높은 지터를 도입하는 경우 유지 보수 팀은 비교할 이전 작동 상태를 갖게 됩니다.

따라서 Radio over IP 게이트웨이 배포는 장치가 온라인 상태를 표시할 때 완료되는 것이 아닙니다. 통신 경로가 섹션별로 측정되고, PTT 타이밍이 실제 무선 장비로 검증되고, 네트워크 동작이 부하 상태에서 테스트되고, 최종 작동 값이 향후 문제 해결을 위해 기록될 때 완료됩니다.