본문 바로가기

Polycom/영상 관련

LPR Lost Packet Recovery

LPR Lost Packet Recovery

 

본 내용은 wainhouse research 내용을 옮긴 내용입니다.

모든 폴리콤 단말은 Call 에 대한 Packet loss를 모니터링 합니다. Packet Loss 가 감지되면, 세가지 Tool을 이용하여 사용자 편의를 보존하고 있습니다.

LPR(Lost Packet Recovery),

DBA(Dynamic Bandwidth Allocation),

PVEC(Polycom Video Error Concealment)

PVEC는 영상시스템이 LPR을 지원하지 않을 시 동작합니다.

 

LPR

대부분의error concealment / avoidance algorithms(폴리콤의 PVEC를 포함) 과 다르게(대부분의 알고리즘은 '받는 시스템'에서만 동작한다.), LPR 은 Call 을 할 때 양쪽 Video system 모두 가지고 있어야 한다.

Flowchart 에 보는 바와 같이, LPR은 Call Bandwidth 이 일부분에 일시적으로 배치되어 동작한다. 이 데이터 채널은 통해 FEC data를 '받는 시스템'에 보낸다. 이 과정을 되풀이 하면서, '받는 시스템'이 모든 Packet loss를 복구하기 위한 최소 Bandwidth 를 찾을때 까지,FEC 데이터 채널의 사이즈를 늘렸다 줄였다 한다.

 

FEC가 사용 중일때(이 의미는 FEC 데이터 채널의 사이즈가 Okbps보다 크다는 것을 의미한다.),

 

시스템은 FEC 데이터 채널의 사이즈를 줄일수 있는지 반복적으로 테스트한다. 그로 인해 audio video content data 를 위해 더 많은 사용 가능한 call bandwidth 를 확보한다. 그러므로, LPR은 packet loss가 감지되었을 때문 bandwidth를 사용한다. 이로 인해 LPR은 Packet loss의 random 혹은 burst (인터넷과 같은 환경) 에서도 이상적인 환경을 제공한다.

 

Polycom Dynamic Bandwidth Allocation (DBA)

지속적으로 Packet Loss 가 있는 환경에서 LPR과 함께 쓰인다.

DBA는Packet loss를 제거하거나 피하기 위해 자동적으로 Video Bit rate 를 Video call 도중에 조절하는알고리즘이다.

예를 들어, 384kbps video call (320 kbps video, 64 kbps audio)에서 10% packet loss가 감지되었다면, DBA는 대략적으로 10% 정도 video bit rate을 감소(320 kbps -> 288kbps)시킵니다. 기르고 packet loss가 남아 있다면 이 과정을 반복합니다.

Video bit rate 을 낮춘 후, DBA가 packet loss가 일시적이었다고 판단한다면, DBA는 점진적으로 video bit rate 을 증가가 시킵니다.

 

Polycom Video Error Concealment (PVEC)

양쪽 참가시스템이 LPR을 지원하지 않을 경우, PVEC가 쓰인다.PVEC 는 Packet 정보(neighboring macroblocks, prior frames, and future frames to

estimate the content of the current video frame)를 통해 IP video quality를 복구하는 알고리즘이다.

LPR 과 DBA 와 같지 않게 PVEC는 packet loss 의 충격을 감추기 위해 동작한다.

 

LPR 은 어떻게 다른가?

  1. Packet Recovery vs Packet Loss Masking

    대부분은 솔류션은 packet loss를 감추거나 video bit rate 을 낮춰 packet loss를 피한다. LPR은 한단계 더 나아가 실제로 이렇어버린 data packet을 복구 시킨다.

  2. Self-Healing 기능

    대부분의 경쟁 솔루션은 packet loss를 피하기 위해 bit rate 를 줄인 후 다시 올리지 않는다. 반면에, LPR은 packet loss가 사라지면 원래 값으로 돌아온다.

  3. Full Coverage

    대부분의 경쟁 솔루션은 error 보정에 대해 Video 에만 적용하는데 반해, LPR은 voice video content 를 커버한다.

 

LPR을 사용함으로 인해 가져갈 수 있는 불리한 점.

  1. Bandwidth 절충

    FEC channel을 통해 LPR이 Bandwidth를 사용한다는 것은 video call이 가용한 bandwidth를 줄인다는 것을 의미한다. 낮은 대역폭의 연결(384kbps 또는 그 이하) 에서, 이것은 일시적인 frame rate 또는 video resolution 감소를 초래할 수 있다.

  2. Latency 증가

    LPR을 사용할 때,보내는 시스탬은 FEC channel을 위한 계산이 끝날때까지 audio video content 의 전송에 delay 가 생긴다. 동일하게, 받는 시스템도 들어오는 FEC channel을 계산하고, 필요한 packet recovery 과정을 거쳐야 한다. 이와 같은 situation 은 video call에 약간의 latency를 추가하게 만든다.

  3. 추가적인 Processing Burden

    LPR을 위해 요구되는 Processing 은 각각의 참가자에게 추가적인 Processing Burden 을 준다. 시스템이 충분한 Processing 능력을 가지고 있다고 가정할때 이것은 문제가 되지 않는다.

Results of the Lost Packet Recovery (LPR) Testing

LPR / PVEC enabled and DBA disabled

> With 1% and 2% packet loss injected, LPR completely eliminated the effect of the injected packet loss and yielded a "no-packet-loss" call experience.

> At 5% packet loss, the impact of the packet loss was minor (slight audio hiccups and a bit of video smearing during the 4Mbps test call).

> Even at 10% packet loss, LPR provided a user experience that WR believes the typical user would consider acceptable.

 

LPR / PVEC and DBA enabled

사진에서 보이듯이 왼쪽사진에서는 얼룩이 보이는 것을 확인할 수 있다.





Lost Packet Recovery

The Lost Packet Recovery (LPR) algorithm uses Forward Error Correction (FEC) to create additional

packets that contain recovery information. These additional packets are used to reconstruct packets that are

lost, for whatever reason, during transmission. Dynamic Bandwidth Allocation (DBA) is used to allocate the

bandwidth needed to transmit the additional packets.

Lost Packet Recovery Guidelines

● If packet loss is detected in the packet transmissions of either the video or Content streams:

 LPR is applied to both the video and Content streams.

 DBA allocates bandwidth from the video stream for the insertion of additional packets containing

recovery information.

● LPR is supported in H.323 and SIP networking environments only.

● In LPR-enabled Continuous Presence conferences:

 Both LPR-enabled and non-LPR-enabled endpoints are supported.

 The LPR process is not applied to packet transmissions from non-LPR-enabled IP (H.323 and

SIP) and ISDN (Collaboration Server 1500/2000/4000) endpoints.

 Non-LPR-enabled endpoints can be moved to LPR-enabled conferences.

 LPR-enabled endpoints cannot be moved to non-LPR-enabled conferences.

● In LPR-enabled Video Switched conferences (Collaboration Server 1500/2000/4000):

 H.323 and SIP endpoints are supported.

 When cascading between conferences running on Collaboration Server and MGC (Polycom

legacy MCU), LPR is not supported over the link between the two conferences.

 Non-H.323 participants cannot be created, added or moved to LPR-enabled Video Switched

conferences.

● When connecting via an Entry Queue:

 A participant using an LPR-enabled endpoint can be moved to a non-LPR-enabled conference.

The participant is connected with LPR enabled.

 SIP and ISDN/PSTN (Collaboration Server 1500/2000/4000) participants cannot be moved to

LPR-enabled Video Switched conferences.

Enabling Lost Packet Recovery

LPR is enabled or disabled in the Conference Profile dialog box.

● CP Conferences – LPR is enabled by default in the New Profile – Advanced dialog box.

● VSW Conferences – If Video Switching is selected, the LPR check box is automatically cleared and

LPR is disabled. LPR can be enabled for VSW conferences but H.320 and SIP participants will not

be able to connect.

For more information, see Defining New Profiles