KR101705359B1

KR101705359B1 - 네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티

Info

Publication number: KR101705359B1
Application number: KR1020100022497A
Authority: KR
Inventors: 서덕영; 박광훈; 김규헌
Original assignee: 경희대학교 산학협력단; 삼성전자주식회사
Priority date: 2010-03-12
Filing date: 2010-03-12
Publication date: 2017-02-10
Also published as: WO2011112043A2; CN102792733A; JP5912089B2; WO2011112043A3; EP2545730A4; EP2545730A2; US20110222403A1; EP2545730B1; JP2013523003A; KR20110103259A

Abstract

본 발명은 네트워크에서 서비스 품질(QoS) 제어를 위한 정보를 보고하는 방법과 이를 위한 네트워크 엔터티에 대한 것으로서, 본 발명의 실시 예에 따라 네트워크에서 QoS 제어 관련 정보를 보고하는 방법은, 중간 네트워크 엔터티가 종단간(end-to-end) 경로 내에 있는 제1 네트워크 엔터티로부터 QoS 제어 관련 보고 패킷을 수신한 경우, 상기 종단간 경로 내에 있는 상기 중간 네트워트 엔터티가 채널 상태를 측정하여 상기 중간 네트워크 엔터티와 관련된 QoS 제어 관련 정보를 포함하는 보고 패킷을 생성하는 과정과, 상기 중간 네트워크 엔터티가 상기 종단간 경로 내에 있는 제2 네트워크 엔터티에게 상기 QoS 제어 관련 정보를 포함하는 상기 보고 패킷을 전송하는 과정을 포함하며, 상기 QoS 제어 관련 정보를 포함하는 상기 보고 패킷은 상기 수신된 QoS 제어 관련 보고 패킷을 업데이트하여 생성된다.

Description

네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티{METHOD FOR REPORTING INFORMATION FOR REPORTING ＱｏＳ CONTROL-RELATED INFORMATION IN A NETWORK AND A NETWORK ENTITY THEREFOR}

본 발명은 네트워크에서 서비스 품질(QoS) 관련 정보를 보고하는 것에 대한 것으로서, 네트워크 링크 및 노드의 정보를 이용한 실시간 멀티미디어 서비스 품질 향상 방법 및 이를 이용한 기기에 관한 것이다.

멀티미디어 서비스의 QoS 제어를 위한 파라미터는 트래픽 파라미터와 QoS 파라미터를 포함한다. 상기 트래픽 파라미터(traffic parameter)는 대역폭(bandwidth) 및 버퍼 사이즈(buffer size)를 포함한다. 상기 QoS 파라미터(parameter)는 지연(delay)과 손실율(loss rate)를 포함한다. 상기 트래픽 파라미터는 네트워크에서 특정 흐름 (flow)에게 자원을 할당하는 자원 예약 프로토콜인 RSVP(Resource Reservation Protocol)에 정의되어 있고, QoS 파라미터는 RTP(Real-time Transport Protocol)의 QoS를 유지하기 위한 프로토콜인 RTCP(real-time transport control protocol)에 정의되어있다. 이하에서는 네트워크에서 트래픽 파라미터와 QoS 파라미터의 예를 제공하기 위해 각각 RFC 2205 RSVP와 RFC 3550 RTCP 표준에 대한 내용을 간략하게 기술한다.

1-1. RTCP (RFC3550 RTP Section 6.4.1)

RTCP는 유니캐스트/멀티캐스트(unicast/multicast) 애플리케이션(application)을 위한 대역외 제어 프로토콜(out-of-band control protocol)이다. RTCP는 RTP 엔터티들이 데이터 전송(data delivery)을 모니터링하고, 최소한의 제어 기능(control functionality)를 갖도록 한다.
RTCP와 관련된 파라미터는 송신기들(Senders)와 수신기들(receivers)간에 각각 주고 받을 수 있다. 여러 participants가 참여하는 오디오 회의 세션(audio conference session)를 생각해보라. 또한, 새로운 수신기는 SDES(Source DEScription), CNAME(Canonical NAME) 등을 송신기로부터 받아야 한다.

RTCP의 4가지 목적은 1. Feedback of end-to-end network quality, 2. Carriers of CNAME(canonical name to associate multiple data streams), 3. RTCP packet의 bitrate제어, 4. Minimal session control information이다. RTCP 패킷의 종류에는 SR(Sender Report), RR(Receiver Report), SDES for CNAME, BYE, APP 패킷 등이 있다. RTCP 구간(interval)은 통계적 해법(statistic resolution)을 제공하면서, 세션 대역폭(session bandwidth)이 한정된 범위 이내가 되도록 결정된다.

SR(Sender Report)/RR(Receiver Report) packet에는 0~31개의 reception block이 있다. SSRC(Synchronization SouRCe, participant identifier)마다 하나의 reception block이 존재한다. (CSRC와는 무관하다. CSRC, 즉, CSRC(Contribution SouRCe)는 고유의 SSRC를 가진 mixer의 출력에서 각각의 source를 구분하기 위한 번호이다.) 도 1은 네트워크에서 사용되는 일반적인 SR 패킷의 구조를 보여 주는 도면이다. 그리고 도 2는 네트워크에서 사용되는 일반적인 RR 패킷의 구조를 보여 주는 도면이다. SR 패킷과 RR 패킷에 대한 구체적인 설명은 RFC 3550 RTCP 표준에 기술되어 있으므로 그 상세한 설명은 생략하기로 한다.
1-2. RTCP XR

삭제

기존의 RFC3611 RTCP XR(RTP Control Protocol Extended Reports)에 있는 Loss RLE(Run-Length Encoding) Report Block은 RTCP interval 동안 개별 RTP 패킷 손실에 대한 정보를 전달한다. 이에 따라, FEC[RFC5109] and/or retransmission[RFC4588]을 실행하여 손실을 치유한다. 기존 RFC3611과 달리 현재 표준화중인 Draft-ietf-avt-post-repair-rtcp-xr-07 (2010)에서는 post-loss-repair의 Loss RLE에 대한 정보를 전달하여, RTP sender로 하여금 loss repair의 효과를 알 수 있게 한다.
상기 Draft-ietf-avt-post-repair-rtcp-xr-07 (2010)에서는 새로운 report block type을 제안하여 등록(register)한다. 그 report block type는 RFC3611의 그것과 비슷하다.
도 3은 네트워크에서 일반적인 RTCP XR 패킷의 구조를 보여 주는 도면이다.
도 3에서 "V" 필드는 RTP의 버전, "P" 필드는 패딩(padding)을 나타낸다. "P" 필드가 설정되어 있으면, RTCP XR 패킷은 끝부분에 부가적인 패딩 옥텟(padding octets)을 포함한다. 상기 "P" 필드의 의미(semantics)는 SR 패킷에서 패딩 필드의 의미와 동일하다. "PT" 필드는 패킷 타입을 나타내며, RTCP XR 패킷을 확인하기 위한 타입 정보(상수 207)를 포함한다. "length" 필드는 RTCP XR 패킷의 길이를 나타내고, "SSRC" 필드는 RTCP XR 패킷의 발신자(originator)에 대한 동기화 소스 식별자(synchronization source identifier)를 나타낸다. 그리고 "report block" 필드는 가변 길이의 0 또는 복수의 확장 보고 블록들을 나타낸다.

삭제

1-3. RSVP (Resource reSerVation Protocol)

RFC 2205 RSVP은 라우터(router)에 자원을 예약하기 위한 protocol이다. 이 표준에 의하면 송신기(Sender)에서 먼저 전송되는 PATH 패킷(PATH 메시지라고도 칭한다.)과, 수신기(receiver)에서 응답으로 전송하는 RESV 패킷(RESV 메시지라고도 칭한다.)을 이용하여 사용하는 트래픽 파라미터(traffic parameter)에 대한 정보를 교환한다. 선택적으로 라우터(router)가 ADSPEC 패킷으로 현재 가용한 자원에 대한 정보를 제공할 수 있다. PATH 패킷에는 데이터 흐름(flow)의 특성에 대한 TSPEC이 포함되고, RESV 패킷에는 자원 예약 내용에 대한 FLOWSPEC이 포함된다. Controlled load인 경우에는 TSPEC과 FLOWSPEC 모두 같은 이중 누설 버킷(double leaky bucket) 인자들을 이용한다. FLOWSPEC에서 [Rate R, Slack Term S]가 추가되면 보장된 서비스(guaranteed service)가 된다. 여기서 Slack Term S는 원하는 지연값과 자원 예약을 통해 얻어진 지연값과의 차이를 나타낸다. 이러한 방식은 호 설정(call setup)과 호 제어(call control)에 모두 사용된다. 호 제어(Call control)에 대한 방법으로 대역폭 감소(bandwidth reduction)을 하는 절차가 RFC4495에 나와있다.

RFC2212에 나와있는 Guaranteed service의 FLOESPEC은 도 4에 도시된 것과 같다. 도 4는 RVSP를 위한 RESV 패킷의 FLOWSPEC 구조를 보여 주는 도면이다. 도 4에 도시된 FLOWSPEC 구조를 살펴보면, 예를 들어 Token Bucket Rate r, Peak Data Rate p, Rate R 등 3가지 종류의 bit rate가 있다. 각각의 bit rate는 bucket size, 패킷 size, slack term과 짝을 이루어 각각 개별적인 leaky bucket을 정의할 수 있다. FLOWSPEC 구조에 대한 보다 상세한 설명은 RFC2212를 참조할 수 있다.

삭제

멀티미디어 서비스의 품질을 향상시키기 위하여 네트워크 상황에 따라 그 서비스 품질을 제어하는 것이 중요하다. RTP(Realtime Transport Protocol) 표준에서는 RTCP를 사용하여 단대단 QoS(Quality Of Service)를 측정하였다. 송신기(sender)는 RTCP SR(Sender Report) 패킷을 전송하고, 수신기(receiver)는 SR 패킷을 받자마자 그 동안 계산해온 QoS를 RTCP RR(Receiver Report) 패킷에 포함하여 전송한다. Sender는 RTCP를 이용하여 측정된 QoS에 따라 멀티미디어 서비스의 품질을 제어한다. 지연이 많이 생기면, 송신기는 bit rate를 줄이고, 패킷 손실이 많이 생기면 손실을 패킷 손실을 방지하기 위해 기존 방법을 사용한다.

그런데, 기존의 RTCP를 이용하면 network layer이하 하부 계층을 black box로 생각하여, 종단간(end-to-end) QoS 파라미터를 측정한다. 여기서 RTCP 파라미터의 측정은 delay, loss 등 결과에 대한 측정이므로 feedback이 느리며, 불확정성(uncertainty)이 생긴다. 그러나, QoS 값을 결정하는 원인인 MAC/ PHY 계층의 channel 및 버퍼 parameter를 이용하여 QoS parameters를 추정하면, feedback이 더 빠르며 uncertainty가 줄어든다.

특히 또한 기존의 RTCP를 이용하여 왕복 지연 시간, 즉 round trip time을 측정하고, 이를 반으로 나누어 one way delay로 사용하는 방식은 mobile 망에서는 개선이 요구된다. 왜냐하면, mobile channel의 uplink와 downlink의 프로토콜과 특성은 서로 전혀 다르기 때문이다. 패킷 손실율의 경우에도 패킷 손실이 random하게 나타나므로 그 값이 uncertain하다. Uncertainty를 줄이기 위해서는 측정 시간을 늘여야 하는데 그렇게 되면 feedback이 늦어진다.
본 발명은 네트워크에서 적응적으로 QoS 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티를 제공한다.
또한 본 발명은 중간 네트워크가 QoS 제어 관련 정보를 다른 네트워크 엔터티에게 보고하는 방법과 이를 위한 중간 네트워크를 제공한다.
또한 본 발명은 네트워크 엔터티에서 네트워크 환경에 적응적으로 QoS 제어 관련 정보를 보고하기 위한 보고 패킷의 구조를 제공한다.

본 발명의 실시 예에 따라 네트워크에서 서비스 품질(QoS) 제어 관련 정보를 보고하는 방법은, 중간 네트워크 엔터티가 종단간(end-to-end) 경로 내에 있는 제1 네트워크 엔터티로부터 QoS 제어 관련 보고 패킷을 수신한 경우, 상기 종단간 경로 내에 있는 상기 중간 네트워트 엔터티가 채널 상태를 측정하여 상기 중간 네트워크 엔터티와 관련된 QoS 제어 관련 정보를 포함하는 보고 패킷을 생성하는 과정과, 상기 중간 네트워크 엔터티가 상기 종단간 경로 내에 있는 제2 네트워크 엔터티에게 상기 QoS 제어 관련 정보를 포함하는 상기 보고 패킷을 전송하는 과정을 포함하며, 상기 QoS 제어 관련 정보를 포함하는 상기 보고 패킷은 상기 수신된 QoS 제어 관련 보고 패킷을 업데이트하여 생성된다.
또한 본 발명의 실시 예에 따라 네트워크에서 서비스 품질(Quality of Service : QoS) 제어 관련 정보를 보고하는 네트워크 엔터티는, 상기 네트워크를 통해 데이터를 송수신하는 송수신부와, 종단간(end-to-end) 경로 내에 있는 제1 네트워크 엔터티로부터 QoS 제어 관련 보고 패킷을 수신한 경우, 상기 종단간 경로 내에 있는 상기 네트워트 엔터티가 채널 상태를 측정하여 상기 네트워크 엔터티와 관련된 QoS 제어 관련 정보를 포함하는 보고 패킷을 생성하고, 상기 종단간 경로 내에 있는 제2 네트워크 엔터티에게 상기 QoS 제어 관련 정보를 포함하는 상기 보고 패킷을 전송하는 동작을 제어하는 제어부를 포함하며, 상기 QoS 제어 관련 정보를 포함하는 상기 보고 패킷은 상기 수신된 QoS 제어 관련 보고 패킷을 업데이트하여 생성된다.
MAC/PHY 프로토콜과 채널환경에 따라 결정되는 link의 특성을 sender 또는 receiver에 전달하기 위하여 기존의 RTCP의 방법대로 XMR(Extended intermediate Report) 패킷 또는 report block을 전송한다. XMR은 link(channel)의 특성을 adaptive QoS control에 이용할 수 있게 하기 위하여 end-to-end path 중간에 있는 entity들이 MAC/PHY 계층 및 network layer의 상황을 종합하여 보고할 수 있게 한다. 여기서 end-to-end path 중간에 있는 entity를 본 발명에서는 intermediate entity(이하 IE라고한다)라고 부른다. IE는 RFC3550에서의 mixer와 translator에 해당한다. MPEG/JVT에서는 MANE(Media Aware Network Entity)가 이에 해당하며, mobile network에서는 base station 또는 access point와 같이 ① 'end-to-end QoS에 크게 영향을 미치는 동작'이 이루어지거나, ② 'end-to-end QoS에 크게 영향을 미치는 parameter를 검출'할 수 있는 entity를 말한다.

① 'End-to-end QoS에 크게 영향을 미치는 동작'이란 filtering이나 extraction을 말한다. Filtering은 여러 개의 media stream중 하나이상의 스트림의 forwarding을 차단하는 것을 말한다. 예를 들어, audio stream과 video stream으로 이루어진 AV service에서 네트워크 상황이 나빠져서 available bitrate가 낮아질 때, video stream을 forwarding하지 않고 audio stream만 forwarding하는 경우를 말한다. Multicast인 경우, 한 쪽 가지에 연결된 device에는 video 기능이 없을 때도 filtering이 필요하다. Extraction은 여러 개의 layer로 이루어진 하나의 media에서 하나이상 layer stream의 forwarding을 차단하는 것을 말한다. 예를 들어, 여러 layers의 scalable video streams으로 이루어진 video service에서 네트워크 상황이 나빠져서 available bitrate가 낮아질 때, upper layer 스트림(들)를 forwarding하지 않고 lower layer stream(s)만 forwarding하는 경우를 말한다. 유무선 통합망에서 multicast인 경우, mobile network으로 가는 쪽 가지(branch)에는 lower layer stream(s)만 forwarding하는 경우에도 extraction이 필요하다.

② 'End-to-end QoS에 크게 영향을 미치는 parameter를 검출'할 수 있는 entity로는 mobile network에서의 BS(base station) 또는 AP(access point)를 예를 들 수 있다. 이들 entity들은 end-to-end QoS에 가장 크게 영향을 미치는 모바일 채널, 즉, last hop을 담당하고 있다. 각 RTP stream에 지정된 channel의 현재 상태 변수를 측정한다. Queue(buffer) fullness, CINR (Carrier to Interference plus Noise Ratio), SINR (Signal to Interference plus Noise Ratio), RSSI (Received Signal Strength Indication), MCS (Modulation and Coding Scheme) level, AMC (Adaptive Modulation and Coding) level, Retry (frame retransmission 횟수), hybrid ARQ (Automatic Repeat reQuest) level 등등이 포함된다. 이러한 변수들을 이용하여 end-to-end QoS를 추정하는데 도움을 줄 수 있다. 각각의 channel 방식에 따라 parameters들이 서로 다르므로, 이를 이용하여 통일된 단위의 변수로 계산하여 알려주어야 한다.

통일된 단위의 변수는 traffic parameters와 QoS parameters로 나눌 수 있다. Traffic parameters는 전달하는 stream의 특성을 표현하며, RFC2205 RSVP(Resource reSerVation Protocol)에 정의된 t-spec에서 규정하는 변수가 바람직하다. Token rate, bucket depth, peak rate, maximum packet size 등등이 포함된다. QoS parameters는 channel 또는 network의 특성을 표현하며 delay/jitter의 정도, throughout, loss/error rate 등을 포함한다.

계산된 QoS parameters들은 XMR 패킷 또는 XMR report block에 담아서 sender, receiver, 또는 다른 IE에 전달된다. Multicast인 경우에는 downstream receiver에 전달하는 것이 바람직하다.

Sender에서는 RTCP XMR을 이용하여 adaptive QoS control을 한다. 즉, RTCP XMR report block에 쓰여진 변수들을 종합하여, end-to-end QoS를 추정하며, 이 추정에 따라, media filtering, rate control, FEC level control 등을 수행한다.

MANE에서도 RTCP XMR을 이용하여 adaptive QoS control을 한다. 즉, RTCP XMR report block에 쓰여진 변수들을 종합하여, end-to-end QoS를 추정하며, 이 추정에 따라, media filtering, rate control, FEC level control 등을 수행한다. QoS가 서로 다른 망으로 갈라지는 QoS differentiated multicast인 경우에는 가지(branch)별로 시시각각으로 변하는 각각 망의 특성을 RTCP XMR을 이용하여 측정하고 이에 맞추어 가능한 최고의 품질의 서비스를 할 수 있다.

본 발명의 실시 예는 실시간 멀티미디어 서비스를 포함하여 각종 멀티미디어 서비스에서 서비스 품질(QoS)을 향상시키는데 적용될 수 있다. 여기서 실시간 멀티미디어 서비스란 화상회의나 화상전화처럼 대화형(conversational) 서비스, VOD(Video On Demand)와 같이 스트리밍(streaming) 서비스, 브로드캐스트/멀티캐스트(broadcast/multicast)와 같은 방송(broadcast) 서비스를 포함한다. 전체적인 서비스 품질에 영향을 크게 미치는 채널(channel)의 상태를 네트워크 경로에 있는 송신기(sender)나 수신기(receiver) 또는 네트워크 경로 중간에서 QoS를 제어하는 네트워크 엔터티에 전달함으로써 적응적인 QoS 제어를 가능하게 한다. 여기서 링크란 cellular network과 와이브로망 (IEEE802.16) 에서 기지국(base station)과 단말기간, 무선랜(WLAN, IEEE802.11)에서 AP(Access Point)와 단말기간 채널 등을 예로 들 수 있다.

도 1은 네트워크에서 사용되는 일반적인 SR 패킷의 구조를 보여 주는 도면,
도 2는 네트워크에서 사용되는 일반적인 RR 패킷의 구조를 보여 주는 도면,
도 3은 네트워크에서 일반적인 RTCP XR 패킷의 구조를 보여 주는 도면,
도 4는 RVSP를 위한 RESV 패킷의 FLOWSPEC 구조를 보여 주는 도면,
도 5는 본 발명의 실시 예에 따라 XMR을 전송하는 방법을 나타낸 도면,
도 6은 본 발명에 적용될 수 있는 Report block의 일반적인 구조를 나타낸 도면,
도 7은 본 발명에 적용될 수 있는 스트림 구별을 위한 IPv6의 Flow Label 하위 4비트 값을 나타낸 도면,
도 8은 본 발명에 적용될 수 있는 RTCP XMR 패킷의 구조를 간략히 나타낸 도면,
도 9는 본 발명의 실시 예에 따른 RTCP XMR 블록의 일 구조 예를 나타낸 도면,
도 10은 본 발명의 실시 예에 따라 RTCP XMR 블록을 생성하는 네트워크 엔터티의 구성을 기능적으로 나타낸 도면,
도 11은 본 발명의 실시 예에 따라 RTCP XMR의 정보를 이용하여 QoS 제어를 수행하는 네트워크 엔터티의 구성을 기능적으로 나타낸 도면.

이하, 첨부된 도면들을 참조하여 본 발명의 실시예를 상세하게 설명한다. 본 명세서에서 사용되는 용어들은 실시 예에서의 기능을 고려하여 선택된 용어들로서, 그 용어의 의미는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 후술하는 실시예들에서 사용된 용어의 의미는, 본 명세서에 구체적으로 정의된 경우에는 그 정의에 따르며, 구체적인 정의가 없는 경우는 당업자들이 일반적으로 인식하는 의미로 해석되어야 할 것이다.

본 발명의 실시 예는 QoS 제어를 위해 적응적인 보고를 위한 새로운 RTCP 패킷 또는 RTCP report block을 제안한다. SR 패킷이나, RR 패킷과 같이 독립된 패킷으로 전송되거나, 기존의 RTCP 패킷에 report block을 추가하는 형태로 구현한다. 이를 RTCP XMR(eXtended intermediate Report)라고 부른다.

XMR은 end-to-end QoS를 결정하는 노드와 link(channel)의 특성을 적응적인 QoS 제어(adaptive QoS control)에 이용할 수 있게 하기 위하여 end-to-end path 중간에 있는 네트워크 엔터티들이 MAC/PHY 계층 및 network layer의 상황을 종합하여 보고할 수 있게 한다. 여기서 end-to-end path 중간에 있는 네트워크 엔터티를 본 발명에서는 intermediate entity(이하 IE라고 한다)라고 부른다. IE는 RFC3550에서의 mixer와 translator에 해당한다. MPEG/JVT에서는 MANE(Media Aware Network Entity)가 이에 해당하며, mobile network에서는 base station 또는 access point와 같이 ① 'end-to-end QoS에 크게 영향을 미치는 동작'이 이루어지거나, ② 'end-to-end QoS에 크게 영향을 미치는 parameter를 검출'할 수 있는 entity를 말한다.

① 'End-to-end QoS에 크게 영향을 미치는 동작'이란 filtering이나 extraction을 말한다. Filtering은 여러 개의 media stream중 하나이상의 forwarding을 차단하는 것을 말한다. 예를 들어, audio stream과 video stream으로 이루어진 AV service에서 네트워크 상황이 나빠져서 가용 비트율(available bitrate)이 낮아질 때, video stream을 forwarding하지 않고 audio stream만 forwarding하는 경우를 말한다. Multicast인 경우, 한 쪽 가지에 연결된 device에는 video 기능이 없을 때도 filtering이 필요하다. Extraction은 여러 개의 layer로 이루어진 하나의 media에서 하나이상 layer stream의 forwarding을 차단하는 것을 말한다. 예를 들어, 여러 layers의 scalable video streams으로 이루어진 video service에서 네트워크 상황이 나빠져서 available bitrate가 낮아질 때, upper layer 스트림(들)를 forwarding하지 않고 lower layer stream(s)만 forwarding하는 경우를 말한다. 유무선 통합망에서 multicast인 경우, mobile network으로 가는 쪽 가지(branch)에는 lower layer stream(s)만 forwarding하는 경우에도 extraction이 필요하다.

② 'End-to-end QoS에 크게 영향을 미치는 parameter를 검출'할 수 있는 IE는 상기와 같이 무선 통신 시스템에서 BS(base station) 또는 AP(access point)를 예를 들 수 있다. 이들 IE들은 end-to-end QoS에 가장 크게 영향을 미치는 last hop을 담당하고 있다. IE는 각 RTP stream 또는 각 서비스에 지정된 channel의 현재 상태 변수를 측정하며, 상기 채널의 상태 변수는 Queue(buffer) fullness, CINR (Carrier to Interference plus Noise Ratio), SINR (Signal to Interference plus Noise Ratio), RSSI (Received Signal Strength Indication), MCS (Modulation and Coding Scheme) level, AMC (Adaptive Modulation and Coding) level, Retry (frame retransmission 횟수), hybrid ARQ (Automatic Repeat reQuest) level 등이 포함된다. 이러한 채널의 상태 변수들을 이용하여 end-to-end QoS를 추정하는데 도움을 줄 수 있다. 각각의 channel 방식에 따라 parameters들이 서로 다르므로, 이를 이용하여 통일된 단위의 채널 상태 변수를 계산하여 알려주어야 한다.

상기 통일된 단위의 채널 상태 변수는 트래픽 파라미터와 QoS 파라미터로 나눌 수 있다. 상기 트래픽 파라미터는 전달하는 stream의 특성을 표현하며, RFC2205 RSVP(Resource reSerVation Protocol)에 정의된 TSPEC에서 규정하는 변수를 사용하는 것이 바람직하다. 상기 트래픽 파라미터는 예를 들어 Token rate, bucket depth, peak rate, maximum packet size 등이 포함된다. 상기 QoS 파라미터는 channel 또는 network의 특성을 표현하며 delay/jitter의 정도, throughout, loss/error rate 등을 포함한다. RFC3611에서 VoIP metrics에 포함되는 변수들을 사용하는 것이 바람직하다. 계산된 QoS parameters들은 XMR을 통하여 sender, receiver, 또는 다른 IE에 전달된다. 상기 QoS 파라미터는 Multicast 전송인 경우에는 downstream receiver에 전달하는 것이 바람직하다. 만일 MANE와 같이 종단간 경로의 중간에 QoS를 제어하는 네트워크 엔터티가 있다면 그 네트워크 엔터티에 전달되어 사용될 수 있다.
이하 본 발명의 실시 예에서 XMR(Extended interMediate Report)을 전송하는 세 가지 방식(Option 1, 2, 3)과, XMR 패킷에서 IP 주소와, XMR 보고 주기, XMR 블록의 구조 등 XMR을 구성하고 이용하는 다양한 실시 예들에 대해 구체적으로 설명하기로 한다.

삭제

XMR 정보는 XMR을 통해 QoS 관련 정보는 세 가지 방식으로 전송이 가능하다.
첫 번째 방식(Option 1)은, sender에서 보내온 SR 패킷을 update하는 방식으로 SR 패킷에 report block을 추가하는 방식이다.
두 번째 방식(Option 2)은, receiver에서 보내온 RR 패킷을 update하는 방식으로 RR 패킷에 report block을 추가하는 방식이다.
세 번째 방식(Option 3)은, IE에서 XMR 패킷을 만들어서 전송하는 방식이다.

도 5는 본 발명의 실시 예에 따라 XMR을 전송하는 방법의 세 가지 방식을 나타낸 도면이다.

Option 1(510)에서 IE1은 SR 패킷에 새로운 정보를 추가하여 SR'로 update한다. SR 패킷에 추가되는 정보는 IE1에서 RTP 패킷을 forwarding하는데 영향을 미치는 인자들로서 IE1 내부 사정과 receiver쪽으로 빠져나가는(egress) link의 현재 상태를 반영한다. 예를 들어, IE1이 router라면 congestion 정도에 따라 지연의 정도, 패킷 폐기율(packet discarding ratio), 해당 session에 할당할 수 있는 bitrate(bandwidth)를 적절한 형태로 추가한다. 또 한 예로, IE2가 LTE BS(LTE 기지국)라면 기지국과 receiver간의 link 상황과 기지국에서의 scheduling 상황을 측정하여, 해당 session의 RTP 패킷 패킷들에 대한 지연의 정도, 패킷 손실율(packet loss ratio), 해당 session에 할당할 수 있는 bitrate(bandwidth)를 SR''에 적절한 형태로 추가한다. 만일 receiver가 마지막 link의 상황을 측정하고 RTCP XMR report block을 작성할 수 있고, 그 측정과 작성을 할 수 있는 IE가 없다면 receiver가 들어오는(ingress) channel의 RTCP XMR report block을 작성하여 sender에게 전달한다. 이 경우 Receiver는 전체 경로상의 XMR report block을 종합하여, XMR report block을 작성하여, RR 패킷에 추가하여 MANE나 sender에게 전달한다.

도 5의 Option 2(530)를 이용하는 경우 RR'이나 RR''에 포함되는 QoS 제어 관련 정보는 각각 IE의 내부 사정과 해당 IE에서 receiver쪽으로 나가는 link에 대한 정보를 포함할 수 있다. Option 1(510)과 Option 2(530)를 적용할 때에는 해당 IE에서 SR 또는 RR 패킷이 머무는 시간을 XMR에 포함할 수 있다. 여기서 SR 또는 RR 패킷이 머무는 시간을 XMR에 r기록하는 방법은 RTCP RR에서의 해당 정보의 report block의 그것과 같다.

도 5의 Option 3(550)는 XMR report block을 SR 패킷이나 RR 패킷에 추가하는 형태가 아니라 별도의 XMR 패킷으로 전송하는 방식이다. XMR 패킷을 주기적으로 보고하는 경우에는 sender나 receiver가 최초의 XMR 패킷을 만들어서 전송하며 거치는 IE에서 update 하는 방식으로 end-to-end QoS를 종합할 수 있다. 주기적인 보고가 아니라 특별히 변경상황이 생겼을 때는 변경상황이 생긴 IE에서 XMR 패킷을 생성하여 전송할 수 있다.

Option 1(510)의 경우 최초의 XMR report block은 sender에서 작성하여 SR에 추가할 수 있다. 마찬가지로, Option 2(530)의 경우 최초의 XMR report block은 receiver에서 작성하여 RR에 추가할 수 있다. 이 경우 추가되는 정보는 RFC3611에서의 report block과 같은 형태로 포함될 수 있다.

삭제

도 6은 본 발명에 적용될 수 있는 Report block의 일반적인 구조를 나타낸 도면이다.

도 6을 참조하면, 8비트크기의 BT(Block Type)는 report block의 종류를 구분하는 번호이며, XMR에서 새롭게 지정하는 block에 대해서는 새로운 번호를 받아, IANA (Internet Assigned Numbers Authority)에 등록하여야 한다. BT를 인식하지 못하는 sender나 receiver는 block length만큼 skip하여 다음 report block을 처리하면 된다.

도 5의 Option 1, 2, 3에서는 각각 SR, RR, XMR 패킷을 IE에서 인식(identification)하는 방법이 필요하다. IPv4에서는 extended IP header를 사용하여 인식할 수 있고, IPv6에서는 flow label을 이용하여 인식할 수 있다. 즉, 하나의 실시간 멀티미디어 서비스에서 스트림별로 따로 flow label 번호를 정한다. 일 실시 예로, 하위 4비트를 이용하여 도 7에 도시된 것과 같이 구분할 수 있다. 도 7은 본 발명에 적용될 수 있는 스트림 구별을 위한 IPv6의 Flow Label 하위 4비트 값을 나타낸 것이다.

도 5의 Option 3의 경우에는 XMR 패킷을 구조를 정해야 하며 통상적으로 SR과 RR 패킷의 구조와 같다. SR과 RR과 구별할 수 있는 PT(Packet Type) 번호를 IANA (Internet Assigned Numbers Authority)에 등록하여야 한다.

도 8은 본 발명에 적용될 수 있는 RTCP XMR 패킷의 구조를 간략히 나타낸 도면이다. XMR 패킷의 기본적인 구조는 도 3에서 설명한 RTCP XR 패킷(RFC3611 참조)을 이용할 수 있다.

삭제

도 5에서 설명한 Option 1과 Option 2의 경우에는 기존 RFC 3350 RTP에서 나오는 mixer(translator)에서와 같은 방식으로 source address를 사용하며, 해당 RTP stream에 대한 SSRC를 하나 부여 받을 수 있다. 즉, XMR 패킷에서 source address와 destination address는 통상적으로 SR과 RR과 같이 sender와 receiver의 IP address를 사용하는 것이 바람직하다. 그러나, mixer와 translator와 같이 stream을 새로이 형성하는 경우에는 자체의 IP address를 source address로 하고, destination address는 receiver 또는 sender의 IP address로 한다. 마찬가지로 Option 3의 경우에도 source address를 XMR 패킷을 만들어 보내는 IE의 IP address로 한다.

삭제

RTCP XMR의 보고 주기는 option 1과 2의 경우에는 기존의 RTCP 주기, 즉, SR이나 RR의 주기와 같은 것이 바람직하다. 그러나, option 3의 경우에는 IE의 자체적인 주기에 따라 전송한다. 예를 들어 XMR을 일정한 시간간격으로 전송하는 방법과 QoS 인자의 변화가 심할 때 전송하는 방법으로 나눌 수 있다. 여기서 일정한 시간 간격이란 통상의 실시간 멀티미디어 서비스에서는 1초 정도가 적합하다.

삭제

XMR 블록은 RTCP report block 형태로 구현될 수 있다. XMR 블록은 Option 1, Option2, Option3의 경우에 각각 상기한 SR, RR, XMR 패킷에 추가된다. XMR 블록에는 RFC 2210에서 사용되는 TSPEC이나 FLOWSPEC의 트래픽 파라미터와 RTCP RR에 포함되는 QoS 파라미터가 포함될 수 있다. 이러한 파라미터들의 일 예로 available bitrate, packet loss ratio, delay, available buffer size 등이 포함될 수 있다. 기본적으로 트래픽 파라미터는 TSPEC 형태로 정의할 수 있다. 이러한 변수들은 일 실시 예로 도 9에 도시된 것과 같은 구조로 전달할 수 있다. 도 9는 본 발명의 실시 예에 따른 RTCP XMR 블록의 일 구조 예를 나타낸 도면으로서, 그 구조는 아래와 같이 예시될 수 있다.

Block type (BT) : 8 bits (901)

Report block의 종류를 구분하는 번호이며, XMR에서 새롭게 지정하는 block에 대해서는 새로운 번호를 받아, IANA (Internet Assigned Numbers Authority)에 등록하여야 한다. BT를 인식하지 못하는 sender나 receiver는 block length만큼 skip하여 다음 report block을 처리하면 된다.

IE번호(Intermediate entity number (IE#)) : 8 bits (903)

추가하기 전에 있던 IE#에 1을 더하여 기록한다. 만일 XMR report block이 없었다면 1을 기록한다.

Block length : 16 bits (905)

RFC3611에서 정의된 내용을 그대로 이용한다. Header를 포함한 byte수로 표시한다.

Available bitrate (Ra) : 32 bits (907)

RFC 2210에서 Token Bucket Rate를 기술하는 방식을 사용한다. 만일 Ra를 측정하지 못하는 경우에는 0으로 기록하며, 이 경우에는 기록된 내용을 무시한다.

Delay : 16 bits (909)

해당 IE에 도착해서 성공적으로 전송되는데까지 걸리는 시간을 추정하여 기록한다. Queueing delay와 link에서 재전송에 의한 지연을 포함한다. RFC3611에서 round trip delay를 표현하듯이, 지연은 millisecond 단위로 16비트 integer로 표시하는 것이 바람직하다. 만일 Delay를 측정하지 못하는 경우에는 0으로 기록하며, 이 경우에는 기록된 내용을 무시한다.

Packet Loss Ratio (PLR) : 8 bits (911)

패킷손실율을 표시하는 방법은 RFC3611에서 loss ratio와 discard ratio를 표시하는 방법과 같은 방법을 사용하는 것이 바람직하다. 즉, PLR에 256을 곱하여 8비트 integer로 표시한다. 예를 들어, 손실율이 5%이면 256을 곱하여 12.8이 나오고, 소수점 이하를 버리고 12로 표시한다. 만일 PLR을 측정하지 못하는 경우에는 0으로 기록하며, 이 경우에는 기록된 내용을 무시한다.

Reserved : 8 bits (913)

추후 다른 변수를 추가할 때, 사용한다.

위의 변수의 지정과 변수를 표현하는 방법은 일 실시 예이다. 다른 목적을 위해 새로운 변수가 추가될 수 있으며, 표현방법도 다르게 정할 수 있다. 본 발명은 이것을 제한하지 않는다.

삭제

상기한 설명에서는 각각의 IE에서 XMR 블록에 포함되는 각각의 정보(즉 변수)를 기록하는 방법을 기술하였고, 이하에서는 다수의 IE가 수록한 XMR 블록의 정보들을 합치는 방법을 기술한다. 그 정보들을 합치는 과정을 수행하는 entity를 종합자(merger)라고 부른다. Option 1의 경우에는 통상적으로 sender가 종합자가 된다. 반면, Option 2의 경우에는 receiver를 종합자가 된다. 그러나, Option 1과 2 경우 모두에서 필요하거나 가능하다면 중간에 어떤 IE에서 종합자의 기능을 수행할 수도 있다. Option 3의 경우에는 sender, receiver, IE 모두 merger가 될 수 있다. RTP 세션뿐만 아니라, HTTP streaming에서도 본 방법을 이용할 수 있다. n개의 IE에서 보내온 XMR 블록을 정보별로 다음과 같이 종합한다. 여기서 receiver나 sender가 XMR 블록을 추가하였다면 receiver나 sender도 IE의 개수에 포함된다.

XMR 정보를 전달하는 패킷(SR, RR, or XMR 패킷)내에서 가장 큰 IE번호가 n이 라면, n개의 IE를 거친 것이고, i번째 available bitrate을 Rai로 표현하면, 최종적으로 가용한 비트율은 아래 <수학식 1>과 같이 계산할 수 있다.

같은 조건에서 각각의 PLR(Packet Loss Ratio) PLR(Pi)을 이용하여 최종적으로 패킷 손실율(P)은 <수학식 2>와 같이 계산할 수 있다.

같은 조건에서 각각의 one way delay Di를 이용하여 최종적으로 지연(D)은 <수학식 3>과 같이 계산할 수 있다.

같은 조건에서 각각의 available buffer Bi를 이용하여 최종적으로 가용한 버퍼 크기(B)는 <수학식 4>와 같이 계산할 수 있다.

Option 1에서는 Receiver에서 종합된 XMR 블록을 RR 패킷에 담아, sender 또는 MANE에 전달하여 QoS 적응 동작이 이루어질 수 있도록 한다. Option 2의 경우에는 sender 또는 MANE가 XMR 블록을 종합하여 바로 QoS 적응 동작이 이루어질 수 있도록 한다. Option 3의 경우에는 XMR 패킷의 전송방향이 Receiver 쪽이면 Option 1과 같은 방식으로 receiver에서 종합하고 RR 패킷에 담아 sender 또는 MANE에 전달하여 QoS 적응 동작이 이루어질 수 있도록 한다. 반면 Option 3에서 XMR 패킷의 전송방향이 Sender 쪽이면 Option 2과 같은 방식으로 sender 또는 MANE가 XMR 블록을 종합하여 바로 QoS 적응 동작이 이루어질 수 있도록 한다.

삭제

XMR은 RFC 2327 (Session Description Protocol)과 호환성을 갖추어야 한다. Option 1과 Option 2의 경우에는 기존의 SR 또는 RR 패킷의 attribute과 같이 취급되어도 좋으며, Option 3의 경우에는 새로운 atrribute로 정의된다. RTCP XMR blocks SDP attribute는 RFC 2234 Augmented Backus-Naur Form (ABNF)에 따라 정의되어야 한다. 이에 대한 자세한 방법은 RFC 3611에 기술된 방법을 이용한다.

삭제

Security에 관한 사항은 RFC 3550 RTP Appendix B에 나온 방법을 따른다.

실시간 멀티미디어 서비스의 품질을 향상시키기 위하여 네트워크 상황에 따라 QoS를 제어하는 것이 중요하다. 이를 위하여 기존 RTP(Realtime Transport Protocol) 표준에서는 RTCP를 사용하여 종단간 QoS(Quality Of Service)를 측정하였다. Sender는 RTCP를 이용하여 측정된 QoS에 따라 멀티미디어 스트림의 품질을 제어하였다. 즉, 지연이 많이 생기면, bitrate를 줄이고, 패킷 손실이 많이 생기면 손실을 막기 위한 방법을 사용하였다.

그런데, 기존의 RTCP를 이용하면 network layer이하 하부 계층을 black box로 생각하게 되어, end-to-end QoS parameter만을 측정한다. RTCP parameter의 측정은 delay, loss 결과에 대한 측정이므로 feedback이 느리며, uncertainty가 생긴다. 그러나, QoS 값을 결정하는 원인인 MAC/ PHY 계층의 channel parameter를 이용하여 QoS parameters를 추정하면, feedback이 더 빠르며 uncertainty가 줄어든다.

무선 통신 시스템에서는 특히 기존의 RTCP를 이용하여 round trip time을 측정하고, 이를 반으로 나누어 one way delay로 사용하는 것은 잘못 된 방식이다. 왜냐하면, mobile channel의 uplink와 downlink는 프로토콜과 특성이 전혀 다르기 때문이다. 패킷 손실율의 경우에도 패킷 손실이 random하게 나타나므로 그 값이 uncertain하다. Uncertainty를 줄이기 위해서는 측정시간을 늘여야 하는데 그렇게 되면 feedback이 늦어진다. 따라서, packet loss의 직접적인 원인이 되는 MAC/PHY 특성을 이용하여 QoS 인자를 추정하는 것이 훨씬 효과적이다.

도 10은 본 발명의 실시 예에 따라 RTCP XMR 블록을 생성하는 네트워크 엔터티의 구성을 기능적으로 나타낸 도면으로서, 상기한 IE는 도 10과 같이 구현될 수 있다.

도 10을 참조하면, IE는 각각의 서비스에 대해서 적합하게 XMR 블록을 추가한다. 패킷 구분기(packet identifier)(1010)는 해당 패킷이 어떤 서비스에 대한 것인지를 구분한다. IPv4에서는 확장헤더(extended header)를 통해, IPv6에서는 flow label를 통해 어떤 서비스인지를 인식할 수 있다. 이를 위하여, 우선 RTCP 패킷을 구분할 수 있도록 하는 것이 필요하다. Network layer, MAC/PHY layers에서 측정한 parameters를 이용하여 QoS 측정기(QoS estimator)(1030)에서 블록에 수록되는 parameters를 계산한다. 그 방식은 MAC/PHY 및 network layers의 특성에 따라 다르다. 그러나, XMR 블록에 수록되는 값은 약속된 단위의 정보를 약속된 format으로 수록한다. 그리고 XMR 부가기(XMR adder)(1050)는 각각의 서비스에 대해서 적합하게 XMR 블록을 추가한다.

도 11은 본 발명의 실시 예에 따라 RTCP XMR의 정보를 이용하여 QoS 제어를 수행하는 네트워크 엔터티의 구성을 기능적으로 나타낸 도면이다. 도 11의 네트워크 엔터티는 예컨대, Sender와 MANE에 해당된다.

도 11을 참조하면, 그리고 패킷 identifier(1110)는 해당 패킷이 어떤 서비스에 대한 것인지를 구분한다. IPv4에서는 확장헤더(extended header)를 통해, IPv6에서는 flow label를 통해 어떤 서비스인지를 인식할 수 있다. Sender와 MANE는 종합된 XMR report에 따라 QoS control을 수행한다. 종합자(merger)에서 종합된 XMR report은 QoS 결정 블록(Action Decision block)(1130)에 전달된다. XMR report는 Option 1, Option 2의 경우에 각각 Receiver와 Sender에서 service별로 종합된다. 종합된 XMR report는 available bitrate, 패킷 loss ration, delay 등 정보를 포함한다. QoS 결정 블록(1130)에서는 QoS action을 결정한다. QoS action에는 media filtering, rate control, FEC 패킷 추가 등이 포함된다. 이에 따라, Adaptive QoS 제어기(1150)에서는 어떤 RTP stream을 filtering-out 시키거나, 어떤 RTP stream에 FEC 패킷을 추가한다. Sender에서는 패킷 identifier(1110)와 같이 점선으로 표시된 block은 포함하지 않는다.

기존의 RTCP를 이용하면 network layer이하 하부 계층을 black box로 생각하여, end-to-end QoS parameter를 측정한다. RTCP parameter의 측정은 delay, loss 결과에 대한 측정이므로 feedback이 느리며, uncertainty가 생긴다. 그러나, RTCP XMR을 이용하면 QoS 값을 결정하는 원인인 MAC/ PHY 계층의 channel parameter를 이용하여 QoS parameters를 추정하며, 이로써 feedback이 빠르며 uncertainty가 적어진다.

특히 mobile 망에서는 기존의 RTCP를 이용하여 round trip time을 측정하고, 이를 반으로 나누어 one way delay로 사용하는 것은 잘못 된 결과를 가져온다. 왜냐하면, mobile channel의 uplink와 downlink는 프로토콜과 특성이 전혀 다르기 때문이다. 패킷 손실율의 경우에도 패킷 손실이 random하게 나타나므로 그 값이 uncertain하다. Uncertainty를 줄이기 위해서는 측정시간을 늘여야 하는데 그렇게 되면 feedback이 늦어진다. 따라서, packet loss의 직접적인 원인이 되는 MAC/PHY 특성을 이용하여 QoS 인자를 추정하는 것이 훨씬 효과적이다.

MANE에서도 RTCP XMR을 이용하여 adaptive QoS control을 한다. 즉, RTCP XMR report block에 쓰여진 변수들을 종합하여, end-to-end QoS를 추정하며, 이 추정에 따라, media filtering, rate control, FEC level control 등을 수행한다. QoS가 서로 다른 망으로 갈라지는 QoS differentiated multicast인 경우에는 시시각각으로 변하는 각각 망의 특성을 RTCP XMR을 이용하여 측정하고 이에 맞추어 가용한 전송자원을 이용하여 가능한 최고의 품질의 서비스를 할 수 있다.

이상의 설명은 본 발명의 실시예에 불과할 뿐, 이 실시예에 의하여 본 발명의 기술 사상이 한정되는 것으로 해석되어서는 안된다. 본 발명의 기술 사상은 특허청구범위에 기재된 발명에 의해서만 특정되어야 한다. 따라서 본 발명의 기술 사상을 벗어나지 않는 범위에서 전술한 실시예는 다양한 형태로 변형되어 구현될 수 있다는 것은 당업자에게 자명하다.

삭제

Claims

삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
네트워크에서 서비스 품질(Quality of Service : QoS) 제어 관련 정보를 보고하는 방법에 있어서,
중간 네트워크 엔터티가 종단간(end-to-end) 경로 내에 있는 제1 네트워크 엔터티로부터 QoS 제어 관련 제1 보고 패킷을 수신한 경우, 상기 종단간 경로 내에 있는 상기 중간 네트워트 엔터티가 채널 상태를 측정하여 상기 중간 네트워크 엔터티와 관련된 QoS 제어 관련 정보를 포함하는 제2 보고 패킷을 생성하는 과정; 및
상기 중간 네트워크 엔터티가 상기 종단간 경로 내에 있는 제2 네트워크 엔터티에게 상기 제2 보고 패킷을 전송하는 과정을 포함하며,
상기 제2 보고 패킷은 상기 제1 보고 패킷을 업데이트하여 생성되는 QoS 제어 관련 정보를 보고하는 방법.
제 11 항에 있어서,
상기 QoS 제어 관련 정보는 상기 중간 네트워크 엔터티와 관련된 패킷 손실율, 지연, 가용한 비트율 중 적어도 하나를 포함하는 QoS 제어 관련 정보를 보고하는 방법.
제 11 항에 있어서,
상기 QoS 제어 관련 정보는 RTCP(Real-time Transport Control Protocol) 보고 블록의 형태로 생성되는 QoS 제어 관련 정보를 보고하는 방법.
제 11 항에 있어서,
상기 QoS 제어 관련 정보는 RTCP(Real-time Transport Control Protocol) 보고 블록을 포함하는 IP(Internet Protocol) 패킷의 형태로 생성되는 QoS 제어 관련 정보를 보고하는 방법.
제 11 항에 있어서,
상기 QoS 제어 관련 정보는 RTCP(Real-time Transport Control Protocol) 보고 블록을 포함하는 RTCP 패킷의 형태로 생성되는 QoS 제어 관련 정보를 보고하는 방법.
제 15 항에 있어서,
상기 RTCP 패킷은 송신기 보고 패킷(Sender Report Packet), 수신기 보고 패킷(Receiver Report Packet) 그리고 XMR(eXtended interMediate Report) 패킷 중 하나인 QoS 제어 관련 정보를 보고하는 방법.
제 11 항에 있어서,
상기 중간 네트워트 엔터티는 라우터, MANE(Media Aware Network Entity), 무선 통신 시스템의 기지국 중 적어도 하나인 QoS 제어 관련 정보를 보고하는 방법.
네트워크에서 서비스 품질(Quality of Service : QoS) 제어 관련 정보를 보고하는 네트워크 엔터티에서 있어서,
상기 네트워크를 통해 데이터를 송수신하는 송수신부; 및
종단간(end-to-end) 경로 내에 있는 제1 네트워크 엔터티로부터 QoS 제어 관련 제1 보고 패킷을 수신한 경우, 상기 종단간 경로 내에 있는 상기 네트워트 엔터티가 채널 상태를 측정하여 상기 네트워크 엔터티와 관련된 QoS 제어 관련 정보를 포함하는 제2 보고 패킷을 생성하고, 상기 종단간 경로 내에 있는 제2 네트워크 엔터티에게 상기 제2 보고 패킷을 전송하는 동작을 제어하는 제어부를 포함하며,
상기 제2 보고 패킷은 상기 제1 보고 패킷을 업데이트하여 생성되는 네트워크 엔터티.
제 18 항에 있어서,
상기 QoS 제어 관련 정보는 상기 네트워크 엔터티와 관련된 패킷 손실율, 지연, 가용한 비트율 중 적어도 하나를 포함하는 네트워크 엔터티.
제 18 항에 있어서,
상기 QoS 제어 관련 정보는 RTCP(Real-time Transport Control Protocol) 보고 블록의 형태로 생성되는 네트워크 엔터티.
제 18 항에 있어서,
상기 QoS 제어 관련 정보는 RTCP(Real-time Transport Control Protocol) 보고 블록을 포함하는 IP(Internet Protocol) 패킷의 형태로 생성되는 네트워크 엔터티.
제 18 항에 있어서,
상기 QoS 제어 관련 정보는 RTCP(Real-time Transport Control Protocol) 보고 블록을 포함하는 RTCP 패킷의 형태로 생성되는 네트워크 엔터티.
제 22 항에 있어서,
상기 RTCP 패킷은 송신기 보고 패킷(Sender Report Packet), 수신기 보고 패킷(Receiver Report Packet) 그리고 XMR(eXtended interMediate Report) 패킷 중 하나인 네트워크 엔터티.
제 18 항에 있어서,
상기 네트워트 엔터티는 라우터, MANE(Media Aware Network Entity), 무선 통신 시스템의 기지국 중 적어도 하나인 네트워크 엔터티.
네트워크에서 종단간 통신 경로(end-to-end) 내에 있는 하나 또는 복수의 링크들과 관련하여 서비스 품질(Quality of Service : QoS) 제어 관련 정보를 보고하는 방법에 있어서,
중간 네트워크 엔터티가 상기 종단간 통신 경로 내에 있는 제1 네트워크 엔터티로부터 QoS 제어 관련 보고 패킷을 수신한 경우, 상기 종단간 통신 경로 내에 있는 상기 중간 네트워트 엔터티가 상기 중간 네트워크 엔터티와 상기 종단간 통신 경로 중 일 단(one end) 간의 하나 또는 복수의 링크들의 채널 상태를 측정하는 과정;
상기 중간 네트워크 엔터티가 상기 하나 또는 복수의 링크들과 관련하여 상기 중간 네트워크 엔터티와 관련된 QoS 제어 관련 정보를 포함하는 XMR(eXtended interMediate Report)을 생성하는 과정; 및
상기 중간 네트워크 엔터티가 상기 종단간 경로 내에 있는 제2 네트워크 엔터티에게 상기 QoS 제어 관련 정보를 포함하는 상기 XMR을 전송하는 과정을 포함하며,
상기 QoS 제어 관련 정보를 포함하는 상기 XMR은 상기 수신된 QoS 제어 관련 보고 패킷을 업데이트하여 생성되는 QoS 제어 관련 정보를 보고하는 방법.
제 25 항에 있어서,
상기 종단간 통신 경로 중 상기 일 단은 수신기이고, 상기 중간 네트워크 엔터티는 상기 수신기의 보고 패킷에 상기 XMR를 부가하여 전송하는 QoS 제어 관련 정보를 보고하는 방법.
제 25 항에 있어서,
상기 중간 네트워크 엔터티는 XMR 패킷으로 상기 XMR을 전송하는 QoS 제어 관련 정보를 보고하는 방법.
제 25 항에 있어서,
상기 중간 네트워크 엔터티는 무선 통신 시스템에서 기지국이고, 상기 하나 또는 복수의 링크들은 상기 기지국과 단말 간의 무선 링크인 QoS 제어 관련 정보를 보고하는 방법.