ATSC 3.0을 위한 햅틱: ATSC A/380 권고안 소개 및 도전과제

1. 햅틱의 정의

햅틱 기술은 스마트폰과 태블릿 같은 모바일 기기에서 터치 기반 피드백을 제공할 뿐만 아니라, 별도의 장비를 통해서도 햅틱 피드백을 느낄 수 있다^[4]. 예를 들어, 스마트폰이나 인터페이스를 조작할 때 사용자에게 진동과 같은 피드백을 제공할 수 있다. 이러한 햅틱 기술은 다양한 상황에서 경험할 수 있다. 라이브로 진행하는 스포츠 경기에서 선수들의 동작과 관련한 햅틱을 별도의 장비를 통해 제공받을 수 있다. 야구 경기에서는 선수가 안타를 치거나 공을 잡았을 때 햅틱 피드백을 제공함으로써 경기에 대한 전반적인 몰입감을 높일 수 있다. 액션 영화에서는 추격전이나 폭발 장면에서 햅틱 피드백을 의자 같은 환경에 적용하여 관객에게 생동감 있는 경험을 제공하며 광고에서도 햅틱을 활용해 소비자의 이목을 끌고 구매율을 상승시키는 데 효과적이다.

2. 장치 특성에 따른 햅틱 시나리오

햅틱을 재생하는 물리적 장치인 Actuator는 모바일 기기뿐만 아니라 게임 컨트롤러, 대형 스크린 등 다양한 기기에 내장되어 각각의 방식으로 햅틱을 재생한다. Actuator가 내장된 기기와 아닌 기기로 분류할 수 있으며, 최근에는 여러 Actuator가 내장된 기기가 점차 늘어나고 있다. ATSC A/380 권고안에 따르면 기기는 방송 스트림을 방송사가 직접 수신할 수 있는지 여부에 따라 PD(Primary Device) 또는 CD(Companion Device)로 분류된다. PD는 ATSC 3.0 수신기능을 내장하여 방송 스트림을 직접 받을 수 있는 기기이며, CD는 이러한 기능이 없는 보조 기기이다. 이에 따라 발생하는 두 가지 시나리오를 고려한다.

그림 1과 같이 Actuator가 내장된 모바일 기기를 PD로 사용하는 경우 ATSC 3.0 Broadcast를 통해 제공되는 A/V 콘텐츠와 별도의 클라우드에 저장된 햅틱 파일을 동기화 과정을 거쳐 모바일 기기(PD)에서 A/V 콘텐츠와 햅틱을 경험할 수 있다.

Fig. 1.

Scenario for using mobile devices as PD

Actuator가 내장되지 않은 TV를 PD로 사용하는 경우 TV는 ATSC 3.0 Broadcast에서 제공하는 A/V만 송출할 수 있다. 그래서 그림 2와 같이 햅틱 기능이 지원되는 모바일 기기(CD)를 별도로 사용한다. 그 후 그림 3과 같이 PD에 존재하는 웹 소켓 서버를 통해 CD로 무선 연결되어 A/V 콘텐츠가 전달되고 별도의 클라우드에 저장된 햅틱 파일과 동기화 과정을 통해 모바일 기기(CD)로 재생할 수 있다^[5].

Fig. 2.

Scenario for using mobile devices as CD

Fig. 3.

Web socket connection between PD and CD

PD에서 제공하는 A/V 콘텐츠와 CD에서 제공하는 A/V 콘텐츠는 서로 같을 수도 있고 다를 수도 있다. 예를 들어 그림 4와 같이 콘텐츠가 동일한 경우, 거실에서 TV(PD)를 통해 축구 경기를 시청하고 있다고 가정한다면 이 TV는 Actuator가 내장되어 있지 않기 때문에 시청자는 A/V 콘텐츠만 제공받게 된다. 그러나 다른 방에서는 CD 애플리케이션을 통해 모바일 기기(CD)에서도 동일한 축구 경기를 시청할 수 있으며, 이 모바일 기기에는 Actuator가 내장되어 있어 시청자가 축구 경기와 관련된 촉각 피드백을 경험할 수 있다. 이러한 경우, 같은 콘텐츠가 두 기기에서 재생되지만, 햅틱 경험은 CD를 통해서만 가능하다.

Fig. 4.

Scenario where PD A/V Content and CD A/V Content are the same

반면, 그림 5와 같이 콘텐츠가 서로 다른 경우도 존재한다. 예를 들어, TV(PD)를 통해 밴드 공연을 시청할 때, TV에는 Actuator가 없어 A/V 콘텐츠만 제공된다. 그러나 모바일 기기(CD)에서는 CD Application을 통해 밴드 공연의 특정 사람에 집중한 개인화된 콘텐츠를 시청하며, 동시에 이 모바일 기기의 Actuator를 통해 공연 중의 진동이나 리듬과 같은 햅틱 피드백을 경험할 수 있다. 이처럼 동일한 공연을 다르게 소비할 수 있는 옵션이 제공되며, PD와 CD의 역할에 따라 사용자 경험이 차별화될 수 있다. 본 논문에서는 TV를 PD로, 모바일 기기를 CD로 사용하는 시나리오에 중점을 두며, 이러한 설정을 통해 ATSC 3.0 방송에서의 햅틱 경험 통합을 구체적으로 다룬다.

Fig. 5.

Scenario where PD A/V Content and CD A/V Content are different

3. 햅틱 파일 크기에 따른 흐름도

햅틱 파일 크기는 콘텐츠에 따라 다르게 존재한다. 주변의 소음이나 사소한 잡음 등 간헐적인 액션만 있는 콘텐츠의 햅틱 파일 크기는 작고, 격렬한 액션이 있는 콘텐츠의 햅틱 파일 크기는 더 크게 존재한다. ATSC 3.0에서는 그러한 햅틱 파일 크기에 따라 전송 방식에 차이를 두고 있다. 햅틱 파일 크기가 작은 경우, 그림 6과 같이 Broadcaster 측에서는 해당 콘텐츠에 대한 content ID를 사용하여 별도의 클라우드에 저장된 햅틱 JSON 파일을 ATSC 3.0 Event Stream에 담아 ATSC 3.0 Broadcast로 전송이 이루어진다. 그때 사용되는 GET 메서드는 아래와 같이 사용하여 요청할 수 있다.

Fig. 6.

Flowchart for small haptic file size

GEThttps://<user>:<password>@<server>:<contentport>/query?contentID=<content_id>

여기서 <user>는 저장소에 알려진 broadcaster ID, <password>는 broadcaster 암호, <server>는 햅틱 클라우드 저장소 URL, <contentport>는 햅틱 콘텐츠를 제공하는 REST 서버의 포트 번호, <contentID>는 햅틱 콘텐츠 ID를 의미한다.

Receiver 측은 PD에서 AMP(Application Media Player)와 RMP(Receiver Media Player)를 통해 PD A/V Content가 A/V Media Device로 재생된다. 그리고 웹 소켓 연결을 통해 CD Application을 거쳐 CD A/V Content가 A/V Media Device로 재생된다. 햅틱 재생을 위해서는 CD Application에서 Android와 iOS 또는 별도의 수신 장치 환경에 맞춰 개발자가 애플리케이션에 맞춤형 햅틱 피드백을 통합할 수 있다. 수신 장치가 Android인 경우 전용 자바스크립트 플레이어 코드인 JSPlayer Haptice Code를 사용하며, iOS의 경우 CoreHaptice API를 사용해 기기별 API를 통해 Device Haptics API에서 렌더링을 거쳐 햅틱을 재생한다^[6].

햅틱 파일 크기가 클 경우, 클라우드에서 JSON 햅틱 파일을 직접적으로 불러오기 어려울 수 있다. 따라서 그림 7과 같이 Broadcaster 측에서는 햅틱 파일의 URL과 인증 토큰을 이용해 ATSC 3.0 Event Stream에 포함시켜 ATSC 3.0 Broadcast로 전송한다. 이때 GET 메서드는 <contentport> 대신에 <URLport>를 사용하여 URL을 받는다.

Fig. 7.

Flowchart for large haptic file size

GEThttps://<user>:<password>@<server>:<URLport>/query?contentID=<content_id>

여기서 <URLport>는 햅틱 콘텐츠 URL을 제공하는 REST 서버 포트 번호를 의미한다.

Receiver 측 PD의 경우 햅틱 파일 크기가 작은 경우와 같다. CD Application에서는 햅틱 파일의 URL과 인증 토큰을 가지고 아래와 같이 클라우드에 있는 햅틱 파일을 불러오는 역할을 수행한다.

GEThttps://<server>:<contentport>/query?fileID=<fileURL>&auth=<authtoken>

여기서 <fileURL>는 햅틱 파일 URL, <authtoken>는 인증 토큰을 의미한다.

사용자는 햅틱에 대한 맞춤화를 진행할 수 있다. GET 메서드에 <userpref>와 <actuator_type>을 추가해 사용자가 경험할 햅틱의 선호도 값과 Actuator의 유형 등을 설정할 수 있으며, 이를 통해 같은 햅틱을 제공받더라도 사용자가 원하는 정도로 조정할 수 있다.

GEThttps://<server>:<contentport>/query?fileID=<fileURL>&auth=<authtoken>&userpref=<userpref>&acttype=<actuator_type>

여기서 <userpref>는 사용자 선호도 값, <actuator_type>는 Actuator 유형을 의미하며, 모두 선택사항이다. 사용자 맞춤화 과정은 그림 7과 같이 파일 크기가 큰 경우에 이루어진다. 맞춤화 정보들을 CD Application에서 URL과 인증 토큰을 바탕으로 햅틱 파일에 접근해야 하는데 파일 크기가 작은 경우에는 CD Application에서 URL 또는 인증 토큰을 주고받지 않기 때문에 이러한 맞춤화 과정이 불가능하다.

CD Application은 햅틱 파일이나 URL을 불러오는 역할뿐만 아니라 그림 8과 같이 A/V와 햅틱의 동기화 작업도 수행한다. 이 동기화 작업은 햅틱 재생 시간을 나타내는 Presentation_time 필드와 햅틱 재생 시간과 영상 재생 간의 오프셋을 나타내는 Presentation_time_delta 필드를 기반으로 이루어진다^[3].

Fig. 8.

Synchronization between A/V and Haptic

4. 사용자 맞춤화

앞서 설명한 것처럼, 사용자마다 햅틱 경험에 대한 선호도가 다를 수 있다. 어떤 사용자는 햅틱을 충분히 즐기고 싶을 수 있고 반면 최소한의 햅틱만을 원할 수도 있다. 이러한 다양한 요구를 반영하기 위해 CD Application에서는 값을 조절할 수 있다. <userpref>는 minimum, typical, maximum으로 선택 가능하며, 이 중에서 minimum과 maximum은 라이브 스포츠 시청 시 선택할 수 있다. minimum은 경기에서 주요 이벤트만 경험하고 싶을 때나 라이브 스포츠 중 광고에서 햅틱을 지원받고 싶지 않을 때 설정할 수 있다. 반면 maximum은 경기 중 발생하는 모든 이벤트를 경험하고 싶을 때 설정한다. typical은 일반적인 비디오 콘텐츠에 사용되며, 스포츠 콘텐츠에는 적용되지 않는다.

또한 사용자마다 보유한 Actuator의 종류가 다를 수 있기 때문에 <actuator_type>은 SD, HD로 구분되며 Actuator의 성능에 따라 구분된다. SD에는 대표적으로 ERM과 Narrowband LRA가 있으며, HD에는 Wideband LRA, VCM, Piezoelectric이 포함된다. 각각의 Actuator는 서로 다른 방식으로 햅틱을 생성하며 <actuator_type>의 기본값은 SD로 설정한다.

5. MPD(Media Presentation Description) 시그널링

햅틱 콘텐츠의 전달 및 동기화를 위해 MPD(Media Presentation Description) 시그널링이 필요하다. MPD는 MPEG-DASH의 핵심 요소로, 미디어 콘텐츠의 구조와 속성을 기술하며 콘텐츠의 URL, 기간, 대역폭 등 다양한 정보를 제공하여 재생의 정확한 타이밍을 제어한다. 본 논문에서는 MPD를 통해 햅틱 파일의 타이밍 정보를 제공함으로써 A/V 콘텐츠와 햅틱 피드백이 동기화된 재생이 가능하도록 한다. 보다 구체적으로는 MPD에 존재하는 Event-Stream 또는 InbandEventStream을 통해 전달된다. Event-Stream은 MPD 내의 Period에 위치하며, 주로 이벤트의 타이밍이 이미 알려진 정적 이벤트를 전달하는 데 사용된다^[2]. 그러나 대부분의 햅틱은 라이브 스포츠와 같이 동적인 특성을 가지므로 정적 이벤트를 전달하는 EventStream은 햅틱 파일을 전송하기에 적합하지 않다. 반면 MPD 내부의 Representaion 또는 Adaptaion Set에 위치한 InbandEvent-Stream은 동적 이벤트를 전달하는 데 사용되므로 햅틱 파일을 전송할 때는 MPD 내의 EventStream보다 Inband-EventStream을 사용하는 것이 적합하다. 전송 방식의 일관성을 유지하기 위해 햅틱 파일은 InbandEventStream을 사용한다. 따라서 정적 이벤트와 동적 이벤트 모두 Inband-EventStream을 통해 전달되며, 식별자를 통해 이벤트를 구분해야 한다. 정적 이벤트의 경우 emsg box의 상위식별자인 @schemeIdUri 값은 “tag:atsc.org,2016:event”이며 하위 식별자 값은 “hpe”이다. 동적 이벤트의 emsg box 상위 식별자는 정적 이벤트와 동일하며 하위 식별자 값은 “hpf”로 구분된다.

1. 다중 Actuator 시그널링

앞선 ATSC A/380 내용은 Actuator가 하나인 경우의 시그널링 방법을 고려한다. 하지만 햅틱을 제공하는 장비 중에는 단일 Actuator가 아닌 여러 Actuator가 내장된 장비도 존재한다. 따라서 다중 Actuator를 사용할 때의 햅틱 전송 방안과 시그널링 방법이 필요하다. 다중 Actuator가 존재한다면 어느 위치의 Actuator를 작동시킬지에 대한 정확한 위치 정보가 필요하다. 사용자 맞춤화 과정에서 사용된 GET 메소드를 활용하여 다중 Actuator에 대한 추가 정보를 서버에 전송하는 방법을 사용한다. 그림 9는 ATSC 3.0에서 다중 Actuator가 있는 경우에 정보를 어떻게 전송할 것인지 시각화한 그림이다. ROUTE/DASH 기반에서 햅틱 데이터는 각 DASH 세그먼트에 포함된 emsg box에 햅틱 데이터를 받을 수 있는 클라우드 URL과 토큰 형태로 저장된다. 이후 사용자는 emsg box가 포함된 데이터를 수신하고 emsg box에 있는 URL과 토큰을 획득한 뒤 Actuator에 대한 정보가 담긴 <body_prat>을 포함하여 클라우드에 요청한다. 신호를 받은 클라우드는 API를 통해 해당 JSON 파일에서 사용자의 <body_part>에 따른 정보를 반환한다. 마지막으로 사용자는 수신한 데이터를 바탕으로 다중 Actuator가 내장된 장비에서 햅틱과 비디오를 재생한다.

Fig. 9.

Transmission Scenarios for Multiple Actuators

GEThttps://<server>:<contentport>/query?fileID=<fileURL>&auth=<authtoken>&userpref=<userpref>&acttype=<actuator_type>&bodytype=6&bodytype=7

여기서 <server>는 햅틱 클라우드 저장소 URL, <content-port>는 햅틱 콘텐츠를 제공하는 REST 서버의 포트 번호, <fileURL>은 햅틱 파일 URL, <authtoken>는 인증 토큰, <userpref>는 사용자 선호도 값(선택사항), <actuator_ type>는 Actuator 유형(선택사항), <body_part>는 Actuator 값(선택사항)을 의미한다.

<body_part>는 신체 부위별 번호를 지정하여 어떤 Actuator를 작동시킬지 사용자가 제공하는 정보이다. 표 1은 각 신체 부위의 위치에 대한 정보를 보여준다.

Table 1.

Information about the location of each body part

그림 10은 <body_part>를 시각화한 것으로 표와 함께 다양한 신체 부위를 쉽게 표현할 수 있다. 또한 값을 추가하여 더 세부적인 신체 부위를 표현하는 것도 가능하다.

Fig. 10.

Visualization of <body_part>