KR20110103259A - 네트워크 링크 및 노드의 정보를 이용한 실시간 멀티미디어 서비스 품질 향상 방법 및 이를 이용한 기기 - Google Patents

네트워크 링크 및 노드의 정보를 이용한 실시간 멀티미디어 서비스 품질 향상 방법 및 이를 이용한 기기 Download PDF

Info

Publication number
KR20110103259A
KR20110103259A KR1020100022497A KR20100022497A KR20110103259A KR 20110103259 A KR20110103259 A KR 20110103259A KR 1020100022497 A KR1020100022497 A KR 1020100022497A KR 20100022497 A KR20100022497 A KR 20100022497A KR 20110103259 A KR20110103259 A KR 20110103259A
Authority
KR
South Korea
Prior art keywords
packet
rtcp
report
entity
xmr
Prior art date
Application number
KR1020100022497A
Other languages
English (en)
Other versions
KR101705359B1 (ko
Inventor
서덕영
박광훈
김규헌
Original Assignee
삼성전자주식회사
경희대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사, 경희대학교 산학협력단 filed Critical 삼성전자주식회사
Priority to KR1020100022497A priority Critical patent/KR101705359B1/ko
Priority to PCT/KR2011/001726 priority patent/WO2011112043A2/en
Priority to JP2012558073A priority patent/JP5912089B2/ja
Priority to CN2011800136805A priority patent/CN102792733A/zh
Priority to EP11753648.2A priority patent/EP2545730B1/en
Priority to US13/047,339 priority patent/US20110222403A1/en
Publication of KR20110103259A publication Critical patent/KR20110103259A/ko
Application granted granted Critical
Publication of KR101705359B1 publication Critical patent/KR101705359B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명은 실시간 멀티미디어 서비스의 품질을 증진시키기 위하여, 전체 경로상에 포함된 네트워크 구성자(entity, router, base station, 등)로부터 해당 링크와 노드의 상황을 보고받는 방법에 관한 것이다. 예를 들면, 기지국의 큐잉 상황과 기지국과 단말기간 링크에서의 손실율, 가용 비트율 등을 서버나 클라이언트에 보고하는 수단이다. 기본적으로 단대단(end-to-end) 사이에 QoS 인자를 주고받는 프로토콜인 RTCP(Realtime Transport Control Protocol)을 확장한 것이다.

Description

네트워크 링크 및 노드의 정보를 이용한 실시간 멀티미디어 서비스 품질 향상 방법 및 이를 이용한 기기{Network link and node information based quality improvement method and its using apparatus for realtime multimedia service}
네트워크 링크 및 노드의 정보를 이용한 실시간 멀티미디어 서비스 품질 향상 방법 및 이를 이용한 기기에 관한 것이다.
실시간 멀티미디어 서비스의 서비스 품질 제어를 위해 전달해야 하는 변수는 traffic parameter인 bandwidth 및 buffer size와 QoS parameter인 delay와 loss rate를 모두 포함한다. Traffic parameter는 RSVP에 정의되어 있고, QoS parameter는 RTCP에 정의되어있다. 본 장에서는 RFC 2205 RSVP와 RFC 3550 RTCP 표준에 대한 내용을 간략하게 정리한다.
1-1. RTCP (RFC3550 RTP Section 6.4.1)
RTCP는 the unicast/multicast application을 위한 out-of-band control protocol이다. RTCP는 RTP entities가 data delivery를 monitoring하고, 최소한의 control functionality를 갖도록 한다. Senders와 receivers간에 각각 주고 받을 수 있다. 여러 participants가 참여하는 audio conference session를 생각해보라. 또한, 새로운 receiver는 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 packet 종류에는 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 packet의 구조를 보여 주는 도면이다. 그리고 도 2는 RR 패킷의 구조를 보여 주는 도면이다.
1-2. RTCP XR
기존의 RFC3611 RTCP XR [3]에 있는 Loss RLE(Run-Length Encoding) Report Block은 RTCP interval 동안 개별 RTP packet 손실에 대한 정보를 전달한다. 이에 따라, FEC[RFC5109] and/or retransmission[RFC4588]을 실행하여 loss repair한다. 기존 RFC3611과 달리 2010년 현재 표준화중인 [1]에서는 post-loss-repair의 Loss RLE에 대한 정보를 전달하여, the RTP sender로 하여금 loss repair의 효과를 알 수 있게 한다. [1]은 새로운 report block type을 제안하여 등록(register)한다. 형태는 RFC3611의 그것과 비슷하다. 도 3은 기존적인 RTCP XR 패킷 구조를 보여 주는 도면이다.
version (V): 2 bits
Identifies the version of RTP. This specification applies to RTP version two.
padding (P): 1 bit
If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification.
reserved: 5 bits
This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
packet type (PT): 8 bits
Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 6.1.
length: 16 bits
As described for the RTCP Sender Report (SR) packet (see Section 6.4.1 of the RTP specification [2]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding.
SSRC: 32 bits
The synchronization source identifier for the originator of this XR packet.
report blocks: variable length.
Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words.
SDP[4]에서 사용되기 위해서는 XMR report block에 대한 새로운 parameter가 정의되고, attribute 이름이 정해져야 한다. 표현형태는 ABNF[5]의 형식을 따른다. 또한 security를 위해 SRTP[8]을 고려해야 하며 새로운 block type은 IANA(Internet Assigned Numbers Authority) 등록을 해야 한다.
1-3. RSVP (Resource reSerVation Protocol)
RFC 2205 RSVP은 router에 자원을 예약하기 위한 protocol이다. 이 표준에 의하면 Sender에서 먼저 전송되는 PATH 패킷과, receiver에서 이에 답으로 전송하는 RESV 패킷을 이용하여 사용하는 traffic parameter에 대한 정보를 교환한다. 선택적으로 router가 ADSPEC 패킷으로 현재 가용한 자원에 대한 정보를 제공할 수 있다. PATH 패킷에는 TSPEC이 쓰여있고, RESV packet에는 FLOWSPEC이 적혀있다. Controlled load인 경우에는 TSPEC과 FLOWSPEC 모두 같은 double leaky bucket인자들을 이용한다. FLOWSPEC에서 [Rate R, Slack Term S]가 추가되면 guaranteed service가 된다. 이러한 방식은 call setup과 call control에 모두 사용된다. Call control에 대한 방법으로 bandwidth reduction을 하는 절차가 RFC4495에 나와있다.
RFC2212에 나와있는 Guaranteed service의 FLOESPEC은 도 4에 도시된 것과 같다. 도 4는 RVSP를 위한 RESV 패킷의 FLOWSPEC 구조를 보여 주는 도면이다.
Token Bucket Rate r, Peak Data Rate p, Rate R 등 3가지 종류의 bitrate가 있다. 각각의 bitrate는 bucket size, packet size, slack term과 짝을 이루어 각각 개별적인 leaky bucket을 정의할 수 있다.
1-4. 참고한 자료
RTCP Normative References
[1] Draft-ietf-avt-post-repair-rtcp-xr-07 (2010) : Post-repair Loss RLE(run length encoding) Report
[2] RFC3550 RTP(2003) : basic operation of RTCP
[3] RFC3611 RTCP XR(2003) : RTP Control Protocol Extended Reports
[4] RFC4566 SDP(2006) : Session Description Protocol
[5] RFC5234 ABNF(2008) : Augmented BNF for Syntax Specifications
Informative References
[6] RFC5109 (2007) : RTP Payload Format for Generic FEC
[7] RFC4588 (2006) : RTP Retransmission Payload Format
[8] RFC3711 SRTP (2004) : The Secure Real-time Transport Protocol
RSVP Normative References
[1] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource reSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[2] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[3] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[8] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
RSVP. Informative References
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[11] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate RSVP Reservations", Work in Progress, October 2005.
[12] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[13] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
실시간 멀티미디어 서비스의 품질을 향상시키기 위하여 네트워크 상황에 따라 제어하는 것이 중요하다. 이를 위하여 RTP(Realtime Transport Protocol) 표준에서는 RTCP를 사용하여 단대단 QoS(Quality Of Service)를 측정하였다. Serder는 RTCP SR(Sender Report) 패킷을 전송하고, receiver는 받자마자 그동안 계산해온 QoS를 RTCP RR(Receiver Report) 패킷에 담아 전송한다. 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 망에서는 잘못 된 방식이다. 왜냐하면, mobile channel의 uplink와 downlink의 프로토콜과 특성은 서로 전혀 다르기 때문이다. 패킷 손실율의 경우에도 패킷 손실이 random하게 나타나므로 그 값이 uncertain하다. Uncertainty를 줄이기 위해서는 측정시간을 늘여야 하는데 그렇게 되면 feedback이 늦어진다. 따라서, packet loss의 직접적인 원인이 되는 MAC/PHY 특성을 이용하여 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을 이용하여 측정하고 이에 맞추어 가능한 최고의 품질의 서비스를 할 수 있다.
본 발명은 실시간 멀티미디어 서비스의 서비스 품질을 향상시키는데 사용된다. 실시간 멀티미디어 서비스란 화상회의나 화상전화처럼 대화형(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(Sender Report) 패킷의 구조이다.
도2는 RR(Receiver Report) 패킷의 구조이다.
도3은 기본적인 RTCP 패킷의 구조이다.
도4는 RSVP를 위한 RESV 패킷의 FLOWSPEC구조이다.
도5는 XMR report block 전송을 위한 3가지 방법이다.
도6은 Report block의 기본적인 구조이다.
도7은 스트림 구별을 위한 IPv6의 Flow Label 하위 4비트 값이다.
도8은 RTCP XR(RFC3611)의 기본적 구조이다.
도9는 RTCP XMR report block의 구조 (일 실시 예)이다.
도10은 RTCP XMR report block을 추가하는 모듈의 상세 구조이다.
도11은 RTCP XMR 정보를 활용한 QoS 제어 모듈의 상세 구조이다.
이하, 첨부된 도면들을 참조하여 본 발명의 실시예를 상세하게 설명한다. 본 명세서에서 사용되는 용어들은 실시예에서의 기능을 고려하여 선택된 용어들로서, 그 용어의 의미는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 후술하는 실시예들에서 사용된 용어의 의미는, 본 명세서에 구체적으로 정의된 경우에는 그 정의에 따르며, 구체적인 정의가 없는 경우는 당업자들이 일반적으로 인식하는 의미로 해석되어야 할 것이다.
본 발명은 새로운 RTCP 패킷 또는 RTCP report block을 제안한다. SR 패킷이나, RR 패킷과 같이 독립된 패킷으로 전송되거나, 기존의 RTCP 패킷에 report block을 추가하는 형태로 구현한다. 이를 RTCP XMR(eXtended intermediate Report)라고 부른다.
XMR은 end-to-end QoS를 결정하는 노드와 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)에 정의된 TSPEC에서 규정하는 변수를 사용하는 것이 바람직하다. Token rate, bucket depth, peak rate, maximum packet size 등등이 포함된다. QoS parameters는 channel 또는 network의 특성을 표현하며 delay/jitter의 정도, throughout, loss/error rate 등을 포함한다. RFC3611에서 VoIP metrics에 포함되는 변수들을 사용하는 것이 바람직하다. 계산된 QoS parameters들은 XMR을 통하여 sender, receiver, 또는 다른 IE에 전달된다. Multicast인 경우에는 downstream receiver에 전달하는 것이 바람직하다. 만일 MANE와 같이 단대단 경로의 중간에 QoS를 제어하는 개체가 있다면 그 개체에 전달되어 사용될 수 있다.
1. XSR, XRR → XMR (Extended interMediate Report)
XMR 정보는 세 가지 형태로 전달이 가능하다. 첫째, sender에서 보내온 SR 패킷을 update하는 방식으로 SR 패킷에 report block을 추가하는 형태이다. 둘째, receiver에서 보내온 RR 패킷을 update하는 방식으로 RR 패킷에 report block을 추가하는 형태이다. 셋째, IE에서 XMR 패킷을 만들어서 전송하는 형태이다. Multicast인 경우에는 Option 1 방식이 적합하며, unicast인 경우에는 Option 2 방식이 적합하다. 여기서 SR과 RR은 RFC 3550에 정의된 Sender Report Packet과 Receiver Report Packet을 말한다.
도 5는 XMR report block 전송을 위한 3가지 방법을 보여 준다.
Option 1에서 IE1은 SR 패킷에 새로운 정보를 추가하여 SR'로 update한다. 추가되는 정보는 IE1에서 RTP packets을 forwarding하는데 영향을 미치는 인자들로서 IE1 내부 사정과 receiver쪽으로 빠져나가는(egress) link의 현재 상태를 반영한다. 예를 들어, IE1이 router라면 congestion 정도에 따라 지연의 정도, packet discarding ratio, 해당 session에 할당할 수 있는 bitrate(bandwidth)를 적절한 형태로 추가한다. 또 한 예로, IE2가 LTE BS(LTE 기지국)라면 기지국과 receiver간의 link 상황과 기지국에서의 scheduling 상황을 측정하여, 해당 session의 RTP packet 패킷들에 대한 지연의 정도, packet loss ratio, 해당 session에 할당할 수 있는 bitrate(bandwidth)를 SR''에 적절한 형태로 추가한다. 만일 receiver가 마지막 link의 상황을 측정하고 RTCP XMR report block을 작성할 수 있는데, 그것을 할 수 있는 IE가 없다면 receiver에서 들어오는(ingress) channel의 RTCP XMR report block을 작성하여 전달한다. Receiver에서는 전체 경로상의 XMR report block을 종합하여, XMR report block을 작성하여, RR packet에 추가하여 MANE나 sender에게 전달한다.
Option 2를 이용하는 경우 RR'이나 RR''에 쓰이는 정보도 각각 IE의 내부 사정과 해당 IE에서 receiver쪽으로 나가는 link에 대한 정보를 수록한다. Option 1과 Option 2를 사용할 때에는 IE에서 SR 또는 RR 패킷이 머무는 시간을 수록해주어야 한다. 머무는 시간을 수록하는 방법은 RTCP RR에서의 해당 정보의 report block의 그것과 같다.
Option 3는 XMR report block을 SR 패킷이나 RR 패킷에 추가하는 형태가 아니라 별도의 XMR packet으로 전송하는 방식을 말한다. 주기적으로 보고하는 경우에는 sender나 receiver가 최초의 XMR 패킷을 만들어서 전송하며 거치는 IE에서 update 하는 방식으로 end-to-end QoS를 종합할 수 있다. 주기적인 보고가 아니라 특별히 변경상황이 생겼을 때는 변경상황이 생긴 IE에서 따로 만들어서 이용할 수 있다.
Option 1의 경우 최초의 XMR report block은 sender에서 작성하여 SR에 추가할 수 있다. 마찬가지로, Option 2의 경우 최초의 XMR report block은 receiver에서 작성하여 RR에 추가할 수 있다.
추가되는 정보는 RFC3611에서의 report block과 같은 형태로 하는 것이 바람직하다.
도 6은 Report block의 기본적인 구조를 보여 주는 도면이다.
8비트크기의 BT(Block Type)는 report block의 종류를 구분하는 번호이며, XMR에서 새롭게 지정하는 block에 대해서는 새로운 번호를 받아, IANA (Internet Assigned Numbers Authority)에 등록하여야 한다. BT를 인식하지 못하는 sender나 receiver는 block length만큼 skip하여 다음 report block을 처리하면 된다.
Option 1, 2, 3에서는 각각 SR, RR, XMR packets을 IE에서 인식(identification)하는 방법이 필요하다. IPv4에서는 extended IP header를 사용하여 인식할 수 있고, IPv6에서는 flow label을 이용하여 인식할 수 있다. 즉, 하나의 실시간 멀티미디어 서비스에서 스트림별로 따로 flow label 번호를 정한다. 일 실시 예로, 하위 4비트를 이용하여 도 7에 도시된 것과 같이 구분할 수 있다. 도 7은 스트림 구별을 위한 IPv6의 Flow Label 하위 4비트 값을 보여 준다.
Option 3의 경우에는 XMR 패킷을 구조를 정해야 하며 통상적으로 SR과 RR 패킷의 구조와 같다. SR과 RR과 구별할 수 있는 PT(Packet Type) 번호를 IANA (Internet Assigned Numbers Authority)에 등록하여야 한다.
도 8은 RTCP XR(RFC3611)의 기본적인 구조를 보여 주는 도면이다.
2. XMR 패킷의 IP address (source address and destination address)
Option 1과 Option 2의 경우에는 기존 RFC 3350 RTP에서 나오는 mixer(translator)에서와 같은 방식으로 source address를 사용하며, 해당 RTP stream에 대한 SSRC를 하나 부여 받을 수 있다. 즉, 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로 한다.
3. RTCP XMR interval
RTCP XMR의 주기는 option 1과 2의 경우에는 기존의 RTCP 주기, 즉, SR이나 RR의 주기와 같은 것이 바람직하다. 그러나, option 3의 경우에는 IE의 자체적인 주기에 따라 전송한다. 일정한 시간간격으로 전송하는 방법과 QoS 인자의 변화가 심할 때 전송하는 방법으로 나눌 수 있다. 여기서 일정한 시간 간격이란 통상의 실시간 멀티미디어 서비스에서는 1초 정도가 적합하다.
4. XMR (eXtended intermediate Report) report blocks
XMR report block은 RTCP report block 형태로 수록되는 것이 바람직하다. XMR report block은Option 1, Option2, Option3의 경우에 각각 SR, RR, XMR 패킷에 추가된다. RFC 2210에서 사용되는 TSPEC이나 FLOWSPEC의 traffic parameters와 RTCP RR에 포함되는 QoS parameters가 포함될 수 있다. 일 실시 예로 available bitrate, packet loss ratio, delay, available buffer size 등이 포함될 수 있다. 기본적으로 traffic parameters는 TSPEC 형태로 정의하는 것이 바람직하다. 그러나, 설명을 간략하게 하기 위하여, 아래에서는 일 실시 예로, available bitrate로 표시한다. 이러한 변수들은 일 실시 예로 도 9에 도시된 것과 같은 구조로 전달할 수 있다. 도 9는 일 실시예에 따른 RTCP XMR report block의 구조의 일례를 보여 주는 도면이다.
Block type (BT) : 8 bits
Report block의 종류를 구분하는 번호이며, XMR에서 새롭게 지정하는 block에 대해서는 새로운 번호를 받아, IANA (Internet Assigned Numbers Authority)에 등록하여야 한다. BT를 인식하지 못하는 sender나 receiver는 block length만큼 skip하여 다음 report block을 처리하면 된다.
IE번호(Intermediate entity number (IE#)) : 8 bits
추가하기 전에 있던 IE#에 1을 더하여 기록한다. 만일 XMR report block이 없었다면 1을 기록한다.
Block length : 16 bits
RFC3611에서 정의된 내용을 그대로 이용한다. Header를 포함한 byte수로 표시한다.
Available bitrate (Ra) : 32 bits
RFC 2210에서 Token Bucket Rate를 기술하는 방식을 사용한다. 만일 측정하지 못하는 경우에는 0으로 쓰며, 이 경우에는 기록된 내용을 무시한다.
Delay : 16 bits
해당 IE에 도착해서 성공적으로 전송되는데까지 걸리는 시간을 추정하여 기록한다. Queueing delay와 link에서 재전송에 의한 지연을 포함한다. RFC3611에서 round trip delay를 표현하듯이, 지연은 millisecond 단위로 16비트 integer로 표시하는 것이 바람직하다. 만일 측정하지 못하는 경우에는 0으로 쓰며, 이 경우에는 기록된 내용을 무시한다.
Packet Loss Ratio (PLR) : 8 bits
패킷손실율을 표시하는 방법은 RFC3611에서 loss ratio와 discard ratio를 표시하는 방법과 같은 방법을 사용하는 것이 바람직하다. 즉, PLR에 256을 곱하여 8비트 integer로 표시한다. 예를 들어, 손실율이 5%이면 256을 곱하여 12.8이 나오고, 소수점 이하를 버리고 12로 표시한다. 만일 측정하지 못하는 경우에는 0으로 쓰며, 이 경우에는 기록된 내용을 무시한다.
Reserved : 8 bits
추후 다른 변수를 추가할 때, 사용한다.
위의 변수의 지정과 변수를 표현하는 방법은 일 실시 예이다. 다른 목적을 위해 새로운 변수가 추가될 수 있으며, 표현방법도 다르게 정할 수 있다. 본 발명은 이것을 제한하지 않는다.
5. 합치기(Merger)
앞의 절에서는 각각의 IE에서 각각의 변수를 report block에 수록하는 방법을 기술하였고, 본 절에서는 다수의 IE가 수록한 report block의 변수들을 합치는 방법을 기술한다. 변수들을 합치는 과정을 수행하는 entity를 종합자(merger)라고 부른다. Option 1의 경우에는 통상적으로 sender가 종합자 가 된다. 반면, Option 2의 경우에는 receiver를 종합자로 한다. 그러나, Option 1과 2 경우 모두에서 필요하거나 가능하다면 중간에 어떤 IE에서 종합자 의 기능을 수행할 수도 있다. Option 3의 경우에는 sender, receiver, IE 모두 merger가 될 수 있다. RTP 세션뿐만 아니라, HTTP streaming에서도 본 방법을 이용할 수 있다. n개의 IE에서 보내온 XMR report block을 변수별로 다음과 같이 종합한다. 여기서 receiver나 sender가 XMR report block을 추가하였다면 receiver나 sender도 IE의 개수에 포함된다.
XMR 정보를 전달하는 패킷내에서 가장 큰 IE번호가 n이 라면, n개의 IE를 거친 것이고, i번째 available bitrate을 Rai로 표현하면, 최종적으로 가용한 비트율은 수학식 1과 같이 계산할 수 있다.
Figure pat00001
같은 조건에서 각각의 PLR(Packet Loss Ratio) PLRi을 이용하여 최종적으로 패킷 손실율은 수학식 2와 같이 계산할 수 있다.
Figure pat00002
같은 조건에서 각각의 one way delay Di를 이용하여 최종적으로 지연은 수학식 3과 같이 계산할 수 있다.
Figure pat00003
같은 조건에서 각각의 available buffer Bi를 이용하여 최종적으로 가용한 버퍼 크기는 수학식 4와 같이 계산할 수 있다.
Figure pat00004
Option 1에서는 Receiver에서 종합된 XMR report block을 RR 패킷에 담아, sender 또는 MANE에 전달하여 QoS 적응 동작이 이루어질 수 있도록 한다. Option 2의 경우에는 sender 또는 MANE가 XMR report block을 종합하여 바로 QoS 적응 동작이 이루어질 수 있도록 한다. Option 3의 경우에는 XMR 패킷의 전송방향이 Receiver 쪽이면 Option 1과 같은 방식으로 receiver에서 종합하고 RR 패킷에 담아 sender 또는 MANE에 전달하여 QoS 적응 동작이 이루어질 수 있도록 한다. 반면 Option 3에서 XMR 패킷의 전송방향이 Sender 쪽이면 Option 2과 같은 방식으로 sender 또는 MANE가 XMR report block을 종합하여 바로 QoS 적응 동작이 이루어질 수 있도록 한다.
6. SDP parameter and attribute name
RFC 2327 (Session Description Protocol)과 호환성을 갖추어야 한다. Option 1과 Option 2의 경우에는 기존의 SR 또는 RR packets의 attribute과 같이 취급되어도 좋으며, Option 3의 경우에는 새로운 atrribute로 정의된다. RTCP XMR blocks SDP attribute는 RFC 2234 Augmented Backus-Naur Form (ABNF)에 따라 정의되어야 한다. 이에 대한 자세한 방법은 RFC 3611에 기술된 방법을 이용한다.
7. Security and SRTP
Security에 관한 사항은 RFC 3550 RTP Appendix B에 나온 방법을 따른다.
실시간 멀티미디어 서비스의 품질을 향상시키기 위하여 네트워크 상황에 따라 제어하는 것이 중요하다. 이를 위하여 기존 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가 줄어든다.
mobile 망에서는 특히 기존의 RTCP를 이용하여 round trip time을 측정하고, 이를 반으로 나누어 one way delay로 사용하는 것은 잘못 된 방식이다. 왜냐하면, mobile channel의 uplink와 downlink는 프로토콜과 특성이 전혀 다르기 때문이다. 패킷 손실율의 경우에도 패킷 손실이 random하게 나타나므로 그 값이 uncertain하다. Uncertainty를 줄이기 위해서는 측정시간을 늘여야 하는데 그렇게 되면 feedback이 늦어진다. 따라서, packet loss의 직접적인 원인이 되는 MAC/PHY 특성을 이용하여 QoS 인자를 추정하는 것이 훨씬 효과적이다.
도 10은 RTCP XMR report block을 추가하는 모듈의 상세 구조를 보여 주는 도면이다.
IE는 각각의 서비스에 대해서 적합하게 XMR report block을 추가한다. Packet identifier는 어떤 서비스인지를 구분하는 역할을 한다. IPv4에서는 확장헤더(extended header)를, IPv6에서는 flow label로 인식하는 것이 바람직하다. 이를 위하여, 우선 RTCP 패킷를 구분할 수 있도록 하는 것이 바람직하다. Network layer, MAC/PHY layers에서 측정한 parameters를 이용하여 QoS estimator에서 report block에 수록되는 parameters를 계산한다. 그 방식은 MAC/PHY 및 network layers의 특성에 따라 다르다. 그러나, XMR report block에 수록되는 값은 약속된 단위의 변수를 약속된 format으로 수록한다.
도 11은 RTCP XMR 정보를 활용한 QoS 제어 모듈의 상세 구조를 보여 주는 도면이다.
Sender와 MANE는 종합된 XMR report에 따라 QoS control을 수행한다. 종합자(merger)에서 종합된 XMR report은 QoS Action Decision block에 전달된다. XMR report는 Option 1, Option 2의 경우에 각각 Receiver와 Sender에서 service별로 종합된다. 종합된 XMR report는 available bitrate, packet loss ration, delay 등 정보가 포함된다. QoS Action Decision block에서는 QoS action을 결정한다. QoS action에는 media filtering, rate control, FEC packet 추가 등이 포함된다. 이에 따라, Adaptive QoS controller에서는 어떤 RTP stream을 filtering-out 시키거나, 어떤 RTP stream에 FEC packets를 추가한다. Sender에서는 점선으로 표시된 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 인자를 추정하는 것이 훨씬 효과적이다.
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인 경우에는 시시각각으로 변하는 각각 망의 특성을 RTCP XMR을 이용하여 측정하고 이에 맞추어 가용한 전송자원을 이용하여 가능한 최고의 품질의 서비스를 할 수 있다.
이상의 설명은 본 발명의 실시예에 불과할 뿐, 이 실시예에 의하여 본 발명의 기술 사상이 한정되는 것으로 해석되어서는 안된다. 본 발명의 기술 사상은 특허청구범위에 기재된 발명에 의해서만 특정되어야 한다. 따라서 본 발명의 기술 사상을 벗어나지 않는 범위에서 전술한 실시예는 다양한 형태로 변형되어 구현될 수 있다는 것은 당업자에게 자명하다.
BT : Block Type

Claims (10)

  1. 서비스를 위한 네트워크 경로 중간에 있는 개체가 서비스 품질과 관련되는 인자를 서비스 품질을 제어하는 개체에게 전송한다.
  2. 제1항에 있어서, 청구항 1의 중간에 있는 개체는 셀룰라망의 기지국, 라우터, 미디어인지네트워크개체 MANE, Media Aware Network Entity 등을 포함한다.
  3. 제1항에 있어서, 청구항 1의 서비스 품질과 관련되는 인자는 청구항 1에서 중간에 있는 개체와 직접 관련된 패킷 손실율, 지연, 가용한 비트율을 포함한다.
  4. 제1항에 있어서, 상기 청구항 1의 인자의 전송을 위해 인터넷 패킷을 이용한다.
  5. 제4항에 있어서, 상기 청구항 4의 인터넷 패킷은 RTCP 패킷과 같은 구조를 가진다.
  6. 제5항에 있어서, 청구항 5의 RTCP 패킷은 청구항 1의 서비스 품질과 관련되는 인자를 RTCP 보고 블록(report block) 구조로 수록한다.
  7. 제5항에 있어서, 청구항 5의 RTCP 패킷으로 전송자 보고 패킷(SR, Sender Report Packet)이며 청구항 1의 서비스 품질과 관련되는 인자를 청구항 1의 중간에 있는 개체에서 RTCP 보고 블록(report block) 구조로 추가된다.
  8. 제5항에 있어서, 청구항 5의 RTCP 패킷으로 수신자 보고 패킷(RR, Receiver Report Packet)이며 청구항 1의 서비스 품질과 관련되는 인자를 청구항 1의 중간에 있는 개체에서 RTCP 보고 블록(report block) 구조로 추가된다.
  9. 제5항에 있어서, 청구항 5의 RTCP 패킷으로 중간자 보고 패킷(MR, interMediate entity Report Packet)이며 청구항 1의 서비스 품질과 관련되는 인자를 청구항 1의 중간에 있는 개체에서 RTCP 보고 블록(report block) 구조로 추가된다.
  10. 제5항에 있어서, 청구항 5의 RTCP 패킷으로 중간자 보고 패킷(MR, interMediate entity Report Packet)이며 청구항 1의 서비스 품질과 관련되는 인자를 청구항 1의 중간에 있는 개체에서 RTCP 보고 블록(report block) 구조로 추가된다.
KR1020100022497A 2010-03-12 2010-03-12 네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티 KR101705359B1 (ko)

Priority Applications (6)

Application Number Priority Date Filing Date Title
KR1020100022497A KR101705359B1 (ko) 2010-03-12 2010-03-12 네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티
PCT/KR2011/001726 WO2011112043A2 (en) 2010-03-12 2011-03-11 Method for reporting qos control-related information in network and network entity therefor
JP2012558073A JP5912089B2 (ja) 2010-03-12 2011-03-11 ネットワークにおいてサービス品質制御関連情報を報告する方法とこのためのネットワークエンティティ
CN2011800136805A CN102792733A (zh) 2010-03-12 2011-03-11 用于在网络中报告与QoS控制有关的信息的方法及其网络实体
EP11753648.2A EP2545730B1 (en) 2010-03-12 2011-03-11 Method for reporting qos control-related information in network and network entity therefor
US13/047,339 US20110222403A1 (en) 2010-03-12 2011-03-14 Method for reporting qos control-related information in network and network entity therefor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020100022497A KR101705359B1 (ko) 2010-03-12 2010-03-12 네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티

Publications (2)

Publication Number Publication Date
KR20110103259A true KR20110103259A (ko) 2011-09-20
KR101705359B1 KR101705359B1 (ko) 2017-02-10

Family

ID=44559876

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020100022497A KR101705359B1 (ko) 2010-03-12 2010-03-12 네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티

Country Status (6)

Country Link
US (1) US20110222403A1 (ko)
EP (1) EP2545730B1 (ko)
JP (1) JP5912089B2 (ko)
KR (1) KR101705359B1 (ko)
CN (1) CN102792733A (ko)
WO (1) WO2011112043A2 (ko)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9072005B2 (en) 2011-04-20 2015-06-30 Qualcomm Incorporated Quality of service control in a multicast transmission
US8767576B2 (en) * 2011-08-17 2014-07-01 Verizon Patent And Licensing Inc. Accessing an application based on a level of service quality
US9178778B2 (en) 2012-03-23 2015-11-03 Avaya Inc. System and method for end-to-end RTCP
GB2500740B (en) * 2012-03-23 2014-07-09 Avaya Inc System and method for end-to-end RTCP
US9860296B2 (en) 2012-03-23 2018-01-02 Avaya Inc. System and method for end-to-end call quality indication
US9356917B2 (en) 2012-03-23 2016-05-31 Avaya Inc. System and method for end-to-end encryption and security indication at an endpoint
US10182487B2 (en) * 2012-11-30 2019-01-15 Enlighted, Inc. Distributed fixture beacon management
KR102349450B1 (ko) 2014-12-08 2022-01-10 삼성전자주식회사 무결성 검사 데이터 제공 방법 및 장치
US9743231B2 (en) * 2015-08-25 2017-08-22 Verint Systems Ltd. System and method for using multiple networks to estimate a location of a mobile communication terminal
US11206297B2 (en) * 2018-03-19 2021-12-21 Livescale Technologies Inc. Video streaming
US10721174B2 (en) * 2018-10-09 2020-07-21 Cisco Technology, Inc. Network-based coordination of loss/delay mode for congestion control of latency-sensitive flows
CN112584418A (zh) * 2019-09-27 2021-03-30 中兴通讯股份有限公司 媒体流传输质量通知方法和会话边界控制实体
KR20210097285A (ko) * 2020-01-30 2021-08-09 삼성전자주식회사 이동통신 네트워크의 미디어 처리 및 전송에 대한 지연을 할당하기 위한 장치와 방법
CN113765732A (zh) * 2020-06-02 2021-12-07 华为技术有限公司 网络性能的测量方法、装置、设备、系统及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070051044A (ko) * 2005-11-14 2007-05-17 주식회사 케이티 패킷 전송 품질 측정 시스템 및 그 방법
WO2007060521A2 (en) * 2005-11-23 2007-05-31 Nokia Corporation System and method for providing quality feedback metrics for data transmission in rich media services
KR20070120257A (ko) * 2006-06-19 2007-12-24 주식회사 케이티 차세대 통신망에서 실시간성 서비스에 대한 품질 분석시스템 및 그 분석 방법

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3769468B2 (ja) * 2001-03-21 2006-04-26 株式会社エヌ・ティ・ティ・ドコモ 通信品質制御方法、通信品質制御システム、パケット解析装置及びデータ送信端末装置
US7894354B2 (en) 2002-10-04 2011-02-22 Jds Uniphase Corporation System and method to monitor RTP streams using RTCP SR/RR packet information
JP3994946B2 (ja) * 2003-08-28 2007-10-24 Ｋｄｄｉ株式会社 品質レポートサーバ及びシステム
JP2006352420A (ja) * 2005-06-15 2006-12-28 Kddi Corp 通信品質情報を含む品質パケットを送受信する端末、品質レポートサーバ及びプログラム
US7796532B2 (en) 2006-05-31 2010-09-14 Cisco Technology, Inc. Media segment monitoring
US8064391B2 (en) * 2006-08-22 2011-11-22 Embarq Holdings Company, Llc System and method for monitoring and optimizing network performance to a wireless device
US20080137552A1 (en) * 2006-12-06 2008-06-12 Hyun Woo Lee APPARATUS AND METHOD OF MEASURING AND MANAGING REAL-TIME SPEECH QUALITY IN VoIP NETWORK
EP2181532B1 (en) * 2007-08-21 2016-04-06 Optis Cellular Technology, LLC Scheduling in wireless networks
JP2009055327A (ja) * 2007-08-27 2009-03-12 Hitachi Ltd ネットワークシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070051044A (ko) * 2005-11-14 2007-05-17 주식회사 케이티 패킷 전송 품질 측정 시스템 및 그 방법
WO2007060521A2 (en) * 2005-11-23 2007-05-31 Nokia Corporation System and method for providing quality feedback metrics for data transmission in rich media services
KR20070120257A (ko) * 2006-06-19 2007-12-24 주식회사 케이티 차세대 통신망에서 실시간성 서비스에 대한 품질 분석시스템 및 그 분석 방법

Also Published As

Publication number Publication date
KR101705359B1 (ko) 2017-02-10
JP5912089B2 (ja) 2016-05-11
JP2013523003A (ja) 2013-06-13
EP2545730A2 (en) 2013-01-16
US20110222403A1 (en) 2011-09-15
EP2545730A4 (en) 2014-03-26
WO2011112043A2 (en) 2011-09-15
EP2545730B1 (en) 2016-09-07
WO2011112043A3 (en) 2012-01-12
CN102792733A (zh) 2012-11-21

Similar Documents

Publication Publication Date Title
KR101705359B1 (ko) 네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티
US10015716B2 (en) Systems and methods for preserving application identification information on handover in a communication network
KR102013729B1 (ko) 통신 네트워크에서 애플리케이션-인식 수락 제어를 위한 방법 및 시스템
Hwang et al. Cross‐Layer End‐to‐End QoS for Scalable Video over Mobile WiMAX
EP2165481B1 (en) Adaptive rate control in a communications system
JP4927333B2 (ja) 帯域幅適応
US7944880B2 (en) Method and arrangement for establishing a communication session for multimedia
EP2022201B1 (en) Media segment monitoring
JP5147858B2 (ja) 複合および非複合ｒｔｃｐパケット間のｒｔｃｐ帯域幅の分割
Siomina et al. The impact of QoS support on the end user satisfaction in LTE networks with mixed traffic
Zhu et al. Improving QoE for Skype video call in mobile broadband network
Musabe et al. Evaluation of a new scheduling scheme for VoIP with mobility in 3G LTE
NYAMBO et al. Quality of service in mobile ad hoc networks, carrying multimedia traffic
Musabe et al. A new scheduling scheme for voice awareness in 3G LTE
Lin et al. Provisioning an end to end QoS for VoIP over WiMAX network
Singh Protocols and Algorithms for Adaptive Multimedia Systems
Hultin Congestion notification and rate-adaptation for real-time services in all-IP radio networks
Singh Rate-control for RTP-based multimedia applications
Baraković et al. The impact of control information prioritization on QoS performance metrics
JP4634501B2 (ja) ネットワークシステム、ポリシーサーバ及びポリシー設定方法
KAZEMITABAR VOIP WITH ADAPTIVE RATE IN MULTI-TRANSMISSION RATE WIRELESS LANS
Prior Scalable Network Architectures Supporting Quality of Service
Bilbao et al. PQoS-driven VoIP service adaptation in UMTS networks
Muntean Dynamic adaptation algorithm for multimedia delivery in wireless networks
Heiskanen Quality of Person-to-Person Services in the Third Generation Partnership Project Architecture

Legal Events

Date Code Title Description
N231 Notification of change of applicant
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant