powerpoint presentationnetwk.hannam.ac.kr/data/com_network_20… · ppt file · web view ·...

HANNAM UNIVERSITYHttp://netwk.hnu.kr 8.1

Chapter 8

멀티미디어와

QoS

HANNAM UNIVERSITYHttp://netwk.hnu.kr

Chapter 8: Outline

8.1 압축

8.2 멀티미디어 데이터

8.3 인터넷에서의 멀티미디어

8.4 실시간 대화형 프로토콜

8.5 서비스 품질

8.2


Chapter 8: Objective 압축 (compression) 배후에 있는 일반적인 아이디어 (idea) 에 대해

논의할 것이다 . 비록 압축이 멀티미디어라는 주제와 직접적인 관 계 는 없 지 만 , 데 이 터 압 축 없 이 는 멀 티 미 디 어 전 송 은 불가능하다 .

텍스트 , 이미지 , 비디오 및 오디오 등의 멀티미디어의 요소들에 대해 논의할 것이다 . 첫 번째 절에서 논의한 기술들을 이용하여 이러한 요소들을 어떻게 표현 , 압축 및 인코딩하는지 보여 줄 것이다 .

인터넷에서의 멀티미디어를 세 가지 항목으로 나눌 것이다 : 저 장 되 어 있 는 오 디 오 / 비 디 오 스 트 리 밍 (streaming stored audio/vide), 실 시 간 오 디 오 / 비 디 오 스 트 리 밍 (streaming live audio/video), 실시간 상호작용 오디오 / 비디오 (real-time interactive audio/video). 간략하게 각각의 기능과 특성을 설명하고 몇 가지의 예를 들 것이다 .

8.3


Chapter 8: Objective (continued) 실 시 간 상 호 작 용 (real-time interactive) 항 목 에 집 중 할

것이다 . 이 항목에서 시그널링 (signaling) 을 위한 프로토콜 두 가지를 소개할 것이다 : SIP 및 H.232. 이 프로토콜들은 voice over IP (Internet telephony) 에 서 사 용 되 며 향 후 어플리케이션의 시그널링 프로토콜로 사용이 가능하다 . 또한 멀티미디어 어플리케이션에 사용되는 전송 계층(transport layer) 프로토콜에 대해서 논의할 것이다 .

서비스 품질 (QoS, quality of service) 에 대해서 논의할 것이다 . QoS 는 텍스트만을 이용하는 통신보다 멀티미디어 통신에 더 필요로 하고 있다 .

8.4


8-1 압축 (COMPRESSION)

• 이 번 절 에 서 는 대 량 의 데 이 터 가 교 환 되 는 멀티미디어 통신에서 중요한 역할을 갖는 압축(compression) 에 대해서 논의

• 압축은 다음과 같은 항목들로 나눌수 있다 : 무손실(lossless) 및 손실 (lossy) 압축

• 각 항목에서 사용되는 일반적인 방법에 대해서 간단하게 논의할 것이다

8.5


8.1.1 무손실 압축

무손실 압축에서는 압축과 압축 해제의 알고리즘이

서로 정확히 반대이기 때문에 데이터의 무결성이 보존 됨

이 과정에서는 데이터의 어떠한 부분도 손실되지 않음

무손실 압축 방식은 보통 데이터를 잃어서는 안될 때 사용

예를 들면 , 텍스트 파일이나 응용프로그램을 압축할 때

데이터가 손실되어서는 안 됨

무손실 압축은 데이터의 크기를 줄이기 위해 간혹 비가역

(lossy compression) 과정의 마지막 관계로 적용될 때가 있다

8.6


8.1.1 무손실 압축 ( 계속 ) 실행 –길이 부호화

사전 부호화 인코딩 (Encoding) 디코딩 (Decoding)

허프만 코딩 (Huffman Coding) 허프만 트리 부호화 테이블 인코딩과 디코딩

8.7


8.1.1 무손실 압축 ( 계속 )

산술 부호화

인코딩

디코딩

정적 대 동적 산술 부호화

8.8


실행 길이 부호화 (Run-length coding) 중복을 제거하는 가장 간단한 방식

어떠한 기호 (symbol) 의 조합으로 만들어진 데이터를 압축할 때 사용

반복되는 순서로 두 개의 개체 (entities) 를 갖는 기호를 실행 (run) 한다

9

AAABBBBCDDDDDDEEE

3A4B1C6D3E


Figure 8.1 : 이진 패턴을 압축하기 위한 실행 - 길이 코딩

8.10


사전 부호화 (Dictionary Coding) Lempel-Ziv-Welch(LWZ)

문자들을 각각 따로 인코딩하는 대신 공통된 순서의 문자들을 인코딩 하는 것

메시지가 스캔이 되면서 사전이 생성되고 만약 문자의 순서가 메시지 안에서 발견된 사전의 엔트리 순서 대신에 엔트리의 코드가 전송 됨

인코딩하는 과정1. 메시지 안에 존재할 가능성 있는 문자를 위해 사전은

하나의 시작점을 가지고 초기화 그와 동시에 메시지의 첫 번째 문자로 버퍼 혹은 문자열을 초기화

시킴 문자열이 가장 큰 엔코딩될 순서를 담음 초기화 단계에서는 오직 메시지의 다음 문자를 가지고 옴

11


사전 부호화 (Dictionary Coding) ( 계속 ) 인코딩하는 과정 ( 계속 )

2. 프로세스 (process) 가 메시지를 스캔하고 메시지의 다음 문자를 가지고 옴a. 해당 문자의 연계된 문자와 검색된 문자가 사전에 있으면 , 그 문자열은

가장 큰 encodable sequence 가 아님 프로세스는 문자를 가장 마지막 연계 문자로 등록해서 문자열을

갱신하여 다음 반복이 수행 될 때가지 대기 함 문자열의 연계와 검색된 문자가 사전에 없으면 , 마지막 인쇄에 문자가

등록된 문자열이 아닌 그 문자열이 가장 큰 encodable sequence 가 됨 여기서 세가지 일을 수행① 프로세스는 마지막 연계에 문자가 등록된 문자열을 사전에 새로운

엔트리로 등록② 프로세스는 문자열을 인코딩③ 다음 반복을 위해 검색된 문자와 함께 문자열을 다시 초기화

3. 메시지 안에 문자들이 남아 있으면 프로세스는 2 번 과정을 계속 반복

12


Table 8.1: LZW 인코딩

8.13


다음과 같이 테스트 메시지 안에 두 문자 A, B 를 가지고 LZW 인코딩을 사용하는 예를 보자 ( 그림 8.1).그 림 에 서 는 문 자 “ BAABABBBAABBBBAA” 가 1002163670 으로 인코딩되는 과정을 보여주고 있다 . 버퍼 PreS 가 갱신되기 전에 이전 반복의 문자열을 가지고 있다는 점을 참고하자 .

Example 8.1

8.14


사전 부호화 (Dictionary Coding) ( 계속 ) 디코딩

사전이 초기화 , 첫 번째 코드워드는 사전에 이용하여 검색이 되고 , 메시지의 첫 번째 문자가 출력

프로세스는 문자열을 생성하여 이전에 검색된 코드워드에 세팅해 놓음 , 그리고 새로운 코드워드를 검색

a. 코드워드가 사전에 존재하면 , 프로세스는 사전에 엔트리를 등록

b. 코드워드가 사전에 존재하지 않으면 프로세스는 문자열을 문자열의 첫 번째 문자와 연결하며 사전에 저장 , 또한 연쇄의 결과를 출력

코드 안에 코드워드가 남아 있다면 프로세스는 2 번 과정을 반복

15


Figure 8.2 : Example 8.1

8.16


Table 8.2: LZW 디코딩

8.17


예제 8.1 의 코드가 어떻게 디코딩되고 원본 메시지로 복원되는지 알아보도록 한다 . PreC 라는 박스는 이전 반 복 에 서의 코 드 워 드 (codeword) 를 담 고 잇 다 . 의사코드 (pseudocode) 로 나타낼 필요는 없지만 여기서는 처리과정을 보이기 위해서 쓰도록 한다 . 이번 예제에서는 코드워드가 사전에 존재하지 않는 특별한 경우라는 걸 참고하도록 한다 . 사전의 새로운 엔 트 리 는 문 자 열 및 문 자 열 안 에 있 는 첫 번 째 문자로부터 생성되어야 한다 . 출력값은 새로운 엔트리와 비슷하다 .

Example 8.2

8.18



8.19


허프만 코딩 (Huffman Coding) 이진 패턴으로 인코딩할 때 각 기호마다 고정된

숫자의 비트를 사용데이터를 압축할 시 기호의 빈도수 (frequency) 와

메시지 안에서 발생 가능성을 고려할 수 있음짧은 코드를 자주 발생하는 기호에 할당하고 긴 코드는 덜

발생되는 기호에 할당

허프만 트리 (Huffman Tree)입사귀 (leaves) 가 기호가 되는 트리 (tree) 를 말함

빈도수가 가장 높은 기호를 트리의 루프 (root) 에 배치 가장 낮은 빈도수를 갖는 기호를 루트로부터 가장 먼 곳에 배치

20


Figure 8.4 : 허프만 트리

8.21


허프만 코딩 (Huffman Coding) ( 계속 ) 부호화 테이블 (Coding Table)

각 문자들이 어떻게 인코딩 / 디코딩 되는지 확인할 수

있는 테이블을 생성

각 문자의 코드는 루트 (root) 에서 시작 , 그 문자로 뻗어

나가는 가지 (branches) 에 존재

코드 자신이 경로에 있는 가지의 비트 값 (bit value) 이며

순차적으로 진행

22


Table 8.3: 부호화 테이블

8.23


Figure 8.5 : 허프만 코드를 이용한 인코딩 /디코딩

8.24


산술 부호화 (arithmetic coding) 메시지 전체를 작은 구간 내부로 [0, 1)매핑 그 다음 그 작은 구간은 이진 패턴으로 인코딩이 된다

산술 부호화는 무한의 작은 구간들을 반개구간 [0,1) 안에

담을 수 있는 사실을 바탕으로 되어 있음

각각의 작은 구간들은 유한한 세트의 기호들을 이용하여

생성 가능한 메시지를 표현할 수 있음

25


Figure 8.6 : 산술 부호화

8.26


산술 부호화 (arithmetic coding) ( 계속 ) 인코딩

산술 부호화로 메시지를 인코딩하려면 , 첫째로 각

기호마다 발생 확률을 할당해야 함

만약 알파벳 내부에 M 기호가 존재하면 , 발생확률은 P1, P2, …., PM 이며 P1 + P2 + … + PM = 1.0

27


Table 8.4: 산술 부호화

28


간편성을 위해서 현재 가지고 있는 기호가 S = {A, B, ∗} 라 가정 했을 때 , 여기서 ‘ *’ 는 종료 기호 , 각 기호에 발생 확률을 다음과 같이 할당할 수 있다 .

Example 8.3

그림 8.7 은 구간과 "BBAB*" 라는 짧은 메시지와 관련된 코드를 어떻게 찾는지 확인할 수 있다 .

8.29



8.30


산술 부호화 (arithmetic coding) ( 계속 ) 디코딩

디코딩은 인코딩과 비슷하지만 , 종료 기호가 출력 값을

경우 루프에서 벗어남

원본 메시지에 종료 기호가 있어야 하는 이유는 이 때문

31


Table 8.5: 산술 디코딩

32


그림 8.8 에서는 예제 8.3 의 메시지를 디코딩하기

위한 과정을 살펴볼 수 있다 . 여기서 핸드 (hand) 는

해당되는 구간의 숫자의 위치를 나타낸다 .

Example 8.4

8.33



8.34


8.1.2 손실 압축 무손실 압축은 압축할 수 있는 양의 한계가 있음

그러나 어떤 상황에서는 정확성을 희생시켜 압축률을 증가시킬 수 있다

비록 텍스트를 압축할 때 정보가 손실되는걸 감안할 수 없지만 , 이미지 , 비디오 및 오디오를 압축할 시 감안할 수 있음 예를 들면 , 비가역압축 (lossy compression) 으로 인한

이미지의 왜곡된 부분은 사람의 시각으로 감지 못할 경우가 있다

이번 절에서는 비가역압축에 대한 몇 가지 아이디어에 대해서 알아보도록 할 것이다

8.35


8.1.2 손실 압축 ( 계산 ) 예측 부호화 (Predictive Coding)

델타 변조 (Delta Modulation) 적응 델타변조 (ADM, Adaptive DM) 차분 펄스 부호 변조 (DPCM, Differential

PCM) 적응 차분 펄스 부호 변조 (ADPCM, Adaptive

DPCM) 선형 예측 부호화 (Linear Predictive Coding)변환 부호화 (Transform Coding) 이산 코사인 변환 (DCT, Discrete Cosine

Transform)

8.36


예측 부호화 (predictive coding) 아날로그 신호를 디지털 신호로 변경할 때 사용

PCM 에서는 샘플들이 따로 양자화 됨

그러나 이웃되는 양자화 샘플들은 깊은 연관성이 있고

비슷한 값을 가짐

예측 부호화에서는 이러한 유사한 부분들을 사용

각 샘플들을 양자화하는 대신 차이만 양자화 함

차이는 실제 샘플보다 작고 적은 비트 수를 요구 함

37


예측 부호화 (predictive coding) ( 계속 )델타변조

예측 부호화에서 가장 간단한 기법

xn 을 샘플링 구간 n 의 본래 기능의 값이고 , yn 은 xn 의

복원된 값이라고 하자

PCM 에서는 송신자가 샘플 (xn) 을 양자화 하고

수신자에게 전송 함

델타변조에서는 송신자가 en, 각 샘플 (xn) 의 차이

그리고 복원 이전의 값 (yn-1) 을 양자화 함

38


Figure 8.9 : 델타변조의 인코딩 / 디코딩

8.39


Figure 8.10 : xn − xn−1 v 과 xn − yn−1 의 양자화 복원

델타변조 ( 계속 )그 후 송신자는 Cn 을 전송

수신자는 Cn 으로부터 전달받은 샘플을 yn 으로 복원

8.40


예측 부호화 (predictive coding) ( 계속 ) 적응 델타변조 (ADM, Adaptive DM)

그림 8.11 은 델타변조에서 양자화 △의 역할을 보여줌

기울기 과부화 왜곡 (slope overload distortion)△가 원래 함수의 기울기랑 비교 했을 때 차이가 상대적으로 작은

영역에서는 복원된 계단 신호는 원래 함수를 따라잡을 수 없음

입상 잡음 (granular noise)△가 원래 함수의 기울기랑 비교했을 때 차이가 상대적으로 큰

영역에서는 복원된 계단 신호는 지속적으로 함수 주위에서 크게 진동

41


Figure 8.11 : 기울기 과부화와 입상 잡음

8.42


예측 부호화 (predictive coding) ( 계속 ) 적응 델타변조 ( 계속 )

대부분의 함수들이 기울기가 크고 작은 영역이

존재하므로 , △ 를 위해 큰 값 또는 작은 값을

선택하더라도 하나의 오류는 감소하고 그 반대의 경우

오류가 증가하게 됨

이러한 문제해결을 위해 적응 DM(Adaptive DM) 을

사용 ADM 에서는 △값이 현재 단계에서 다음으로 넘어갈 때 변함

43

△n = Mn△n-1


예측 부호화 (predictive coding) ( 계속 )차분 펄스 부호 변조 (DPCM, Differential PCM)

일반적인 델타변조이전의 복원된 샘플 yn-1 은 예측자라고 함DPCM 에서 예측하기 위해 하나 이상의 이전에 복원된 샘플을 사용

44


예측 부호화 (predictive coding) ( 계속 )차분 펄스 부호 변조 ( 계속 )

수신자는 다음과 같이 현재의 값을 복원

예측계수는 실제값과 예측값 사이의 누적된 오류를 최소화하면서 발견

최적화로는 제곱법 오류 (method of square error) 를 사용 45


예측 부호화 (predictive coding) ( 계속 ) 적응 차분 펄스 부호 변조 (Adaptive DPCM)

샘플의 또 다른 영역에 다른 계수를 사용하거나 양자화 (△) 를 단계별로 조정 또는 두 가지 방식을 다 이용하여 보다 나은 압축을 할 수 있음

선형 예측 부호화 (LPC, linear predictive coding)차이의 양자화 신호를 전송하는 대신 소스가 신호를 분석하고 특성을

결정함 특성에는 주파수의 민감한 범위 안에 있는 주기 , 주파수의 세기

그리고 각 신호의 지속시간 등을 포함 그 후 소스는 이러한 정보를 양자화하고 수신자에게 전송 수신자는 이러한 정보를 신호 합성기로 공급하여 원본 신호와 비슷한

신호로 시뮬레이션 함높은 수준의 압축이 가능 주로 군사용 , 음성압축에 사용

46


변환 부호화 출력신호를 위해 입력신호에는 수학적 변환을 적용하였음

원본 신호가 복구되기 위해서는 변환은 역으로 되어야 함

변환은 신호 표현을 하나의 도메인에서 다른 도메인으로 변환함

이산 코사인 변환 (DCT, discrete cosine transform) 멀티미디어에서 가장 흔하게 쓰이는 변화 기술

1차원 DCT(One-Dimensional DCT) 1차원 DCT 에서 변환은 열벡터 p 와 정방행렬 t 의 행렬 곱

결과값은 열백터 M DCT 계수를 표현하는 정방행렬은 직교행렬이기 때문에 역변환은

DCT 계수의 변환 데이터 행렬과 전치행렬의 곱으로 구할 수 있음

47


Figure 8.12 : 1차원 DCT

8.48


Figure 8.13 : 1 차원 DCT 의 변환 및 역변환 공식

8.49


그림 8.14 는 N=4 를 위한 변환 행렬을 보여주고

있다 . 그림과 같이 첫 번째 열은 동일한 값을 가지고

있으며 , 다른 열에서는 양과 음의 값이 번갈아 있다 . 각 열이 소스 데이터 행렬과 곱하면 , 양과 음의 값들이

0 에 가까워 질 것 이 라 예 상 할 수 있 다 . 여 기 서

기대하는 변환은 다음과 같다 . 소스 데이터의 값 중에

중요한 것도 있지만 대부분의 값들은 불필요하다 .

Example 8.5

8.50



8.51


변환 부호화 ( 계속 ) 2차원 DCT(Two-Dimensional DCT)

이미지 , 오디오 및 비디오 압축을 위해 필요

소스 데이터와 변환 데이터가 2차원 정방행렬이라는

점을 제외하고는 원칙은 1차원과 같음

1차원 DCT 에선 언급한 속성대로 변환을 하고 싶으면 , 행렬 T 를 두 번 사용해야 함 (T 와 TT)

역변환 또는 행렬 T 를 두 번 사용하지만 역순 임

52


Figure 8.15 : 2차원 DCT

8.53


Figure 8.16 : 2차원 DCT 의 변환 및 역변환 공식

8.54


8-2 멀티미디어 데이터

• 오늘날 멀티미디어 데이터는 텍스트 , 이미지 .

비디오 및 오디오로 이루어짐• 그러나 미래형 미디어의 등장으로 점차 정의가

바뀌고 있다

8.55


8.2.1 텍스트

인터넷에서는 사용 및 다운로드가 가능한

텍스트들이 많이 있음

하나는 선형인 일반 텍스트 또는 비선형인

하이퍼텍스트의 텍스트 데이터가 있다

인터넷에 있는 텍스트는 유니코드와 문자형을 기본

언어로 사용

8.56


8.2.2 이미지 (Image) 멀티미디어 용어로 이미지 ( 또는 정지 이미지라고도

불리는 ) 는 주로 사진 , 팩스 또는 영상의 한 프레임을 말함

디지털 이미지 이미지 압축 : JPEG

변환 양자화 인코딩

이미지 압축 : GIF

8.57


디지털 이미지

58


다음은 1,280 × 720 픽셀 이미지를 100kbps 로 전송 시 요구되는 시간을 보여주고 있다 .

Example 8.6

a. 비트심도 1 의 흑백 이미지

b. 비트심도 8 의 회색 이미지

c. 비트심도 24 의 색깔 이미지

전송시간 = (1,280 × 720 × 1)/10,000 = 9 초

전송시간 = (1,280 × 720 × 8)/10,000 = 74 초

전송시간 = (1,280 × 720 × 24)/10,000 = 215 초

8.59


이미지 압축 : JPEG

60


Figure 8.17 : JPEG 의 각 채널의 압축

8.61


이미지 압축 : JPEG

62


이미지 압축 : JPEG양자화

JPEG 은 Q1 에서부터 Q100까지의 행렬을 정의

Q1 은 가장 낮은 화질을 가지며 가장 높은 단계의 압축률을 가짐

Q100 은 가장 좋은 화질을 보여주지만 가장 낮은 단계의 압축률을 가짐

63


Figure 8.18 : 세 가지의 다른 양자화 행렬

과정 중에 완벽하게 역이 되지 않는 단계는 양자화 단계복원이 불가능한 부분에서는 정보를 잃음

8.64


이미지 압축 : JPEG 인코딩

양자화 이후 값들은 테이블로부터 읽혀지고 중복된 0들은 제거 됨

0 들을 모두 밀집시키기 위해서 테이블은 행과 행 , 열과

열보다는 지그재그 방식으로 비스듬하게 읽음 만약 사진이 좋게 변환되지 않았다면 , T 테이블의 우측 하단

부분이 모두 0 이 되기 때문

65


Figure 8.19 : 테이블 읽기

8.66


JPEG 압축에 대해 더 알아보기 위해 다음과 같이 비트심도가 20 인 회색의 이미지의 블록을 이용하였다 . 변환 , 양자화 , 지그재그 방식으로 재정렬을 자바 프로그램으로 만들었고 다음과 같은 인코딩 과정을 보여준다 ( 그림 8.20).

Example 8.7

8.67


Figure 8.20 : 예제 8.7 단일 그레이스케일

8.68


두 번째 예로는 점진적으로 변하는 블록이 있다 . 값과 이웃된 픽셀 사이의 갑작스러운 변화는 없다 . 그러나 그림 8.21 과 같이 0 값은 많이 나온다 .

Example 8.8

8.69


이미지 압축 : GIF Graphic Interchange Format(GIF)

보다 작은 팔레트를 사용 , 보통 28 = 256 색

팔레트 색으로 트루 색 (true color) 을 매핑 함

팔레트에 이미지를 생성하면 , 각 픽셀은 256 개의 부호

중 하나로 표현될 수 있음

이미지의 높은 압축을 위해서는 사전 코딩이나 산술

코딩과 같은 손실 없는 압축 기법 중 하나를 사용할 수

있다

70


Figure 8.21 : 예제 8.8 흑백 변화도

8.71


8.2.3 Video 비디오는 여러 프레임으로 구성 ( 한 프레임 = 한 장의

사진 ) 따라서 비디오 파일은 높은 전송률을 요구한다 비디오 디지털화

동영상 압축 : MPEG 공간 압축 일시적인 압축

8.72


비디오 계수화 ( 디지털화 ) 비디오는 프레임의 연속으로 구성

초당 표준 프레임의 수는 정해져 있지 않으나 , 북미의 경우

초당 25 프레임이 일반적임

깜빡임이라고 알려진 현상을 피하기 위해서는 프레임이

재생되어야 함 TV 업계에서는 각 프레임을 두 번 내보내게 되고 초당 전송하는

프레임 수가 50 이 됨

송신자 측에 메모리가 있다면 25 프레임이 메모리에서 각각 다시

내보내지게 됨

73


몇 개의 비디오 표준화 기술의 전송률을 살펴보자

Example 8.9

a. 컬러 TV 는 한 프레임에 720 × 480 픽셀 , 1 초에 30프레임 그리고 한 컬러에 24 비트를 제공한다 . 전송률은 아래와 같다 .

b. HD(high definition) 컬러 TV 는 한 프레임에 1,920 × 1,080 픽셀 , 1 초에 30 프레임 그리고 한 컬러에 24 비트를 제공한다 . 압축 없는 전송률은 아래와 같다 .

720 × 480 × 30 × 24 = 248,832,000 bps = 249Mbps

1920 × 1080 × 30 × 24 = 1,492,992,000 bps = 1.5 Gbps

8.74


동영상 압축 : MPEG MPEG(Moving Picture Experts Group)

동영상 압축에 사용프레임은 픽셀 공간의 조합이고 , 동영상은 프레임의

일시적인 조합동영상 압축은 각 프레임을 공간적으로 압축하는 것과

프레임들의 집합을 일시적으로 압축하는 것을 의미 공간압축 (spatial compression)

중복 프레임은 제거 됨TV 를 시청 할 때는 초당 50 프레임을 수신일시적으로 데이터를 압축하기 위해 MPEG 방법은 먼저

I- 프레임 , P- 프레임 , B- 프레임의 세 가지의 프레임 집합으로 나뉨

75


Figure 8.22 : MPEG 프레임

8.76


동영상 압축 : MPEG 공간압축 ( 계속 )

I- 프레임 (intracoded frame) 다른 프레임과 관계되지 않은 독립적인 프레임 , 규칙적인 간격으로 되어

있음 앞과 뒤의 프레임에서 보여줄 수 없는 갑작스러운 변화를 다루기 위해

주기적으로 나타나야만 함 또한 화상으로 방송 할 때 뷰어는 언제라도 각자의 수신기에서 파장을 맞춤

P- 프레임 (predicted frame) 이전의 I- 프레임 혹은 P- 프레임과 연관 P- 프레임은 다른 프레임 형태보다 매우 작은 정보를 전달하고 , 압축 후

더 작은 비트를 전달 함 B- 프레임 (bidirectional frame)

앞 , 뒤의 I- 프레임 혹은 P- 프레임과 연관 B- 프레임은 결코 다른 B- 프레임과 연관되지 않음에 유의

77


8.2.4 오디오 오디오 ( 소리 ) 신호는 전송 매체 ( 공기 ) 를 이용하는 아날로그

신호 따라서 오디오 신호는 진공상태에서 전송할 수 없다

또한 대기에서 소리의 속도는 약 330 m/s (740 mph) 이며 , 정상적인 사람의 가청 주파수는 약 20Hz 에서 20kHz, 최대 가청 주파수는 3,300 Hz 임 음성 디지털화

음성 압축 전조 부호화 (Predictive coding) 지각 부호화 (Perceptual Coding) MP3

8.78


음성 디지털화하기 (Digitizing Audio) 음성 압축을 위해선 음성의 아날로그 신호를

아날로그 - 디지털 (analog-to-digital)변환기를 이용하여 디지털화 해야 함

아날로그 - 디지털 변환샘플링 및 양자화

디지털화 과정 중 펄스 부호변조 : 아날로그 신호를 샘플링하고 샘플을 양자화하여 양자화된 값을 비트의 스트림으로 코딩

음성 신호는 샘플당 8 비트로 초당 8,000 번 샘플링 : 8,000x8=64kbps

음악은 샘플당 16 비트로 초당 44,100 번 샘플링 : 모노 : 44,100 x 16 = 705.6kbps 스테레오 : 1.411Mbps

79


음성 압축 비가역압축 및 무손실 압축 알고리즘 두 가지 방법을 모두 사용무손실 음성 압축 : 음악 파일의 원본을 정확히 보존

약 2 정도의 매우 낮은 압축율을 가지고 있으며 기록과 수정을 목적으로 많이 사용

비가역 압축보다 높은 압축율을 제공하며 오디오 장치에서 많이 사용

비가역압축 : 품질을 조금 떨어트리지만 , 저장 공간 및 대역폭 요구를 상당히 줄여줌

음성 및 음악에 사용되는 압축기술은 서로 다른 요구사항을 가짐

80


음성 압축 ( 계속 ) 전조 부호화

모든 샘플링 된 값을 부호화하는 대신 샘플들 사이의 차이 값을 부호화 함

일반적으로 음성 (speech) 을 위해 사용 DM, ADM, DPCM, ADPCM, LPC

지각 부호화 CD 품질의 음성을 생성하기 위해 일반적으로 가장 많이 사용되는

압축 기술 : 음향심리학 기반 처음에 데이터를 시간 영역에서 부호화 영역으로 변환

데이터에서 수행되는 작업은 주파수 영역에서 작동 이러한 이유로 이 기술은 주파수 영역 방식이라고도 함 음성 심리학은 인간의 주관적인 소리에 대한 인식에 대한 연구

81


Figure 8.23 : 가청도의 임계치

8.82


음성 압축 ( 계속 ) 지각 부호화 ( 계속 )

주파수 매스킹 및 시간 매스킹의 개념을 사용하면 더 많은 수의 비트를 절약 할 수 있음

주파수 매스킹 : 큰 소리 및 작은 소리의 주파수가 서로 비슷하고 큰 소리가 작은 소리를 부분적 또는 완전히 마스킹 할 경우 발생

시간 매스킹 : 큰 소리는 소리가 멈추더라도 한 동안 사람의 청각 기능을 마비시킬 수 있음

기본적인 접근 방식은 입력 음성 PCM 을 코더에게 두 단위로 동시에 나누어서 공급 첫번째 단위 : 디지털 바이패스 필터인 분석 필터 뱅크라는 배열을 의미

이산푸리에변환 사용 , 필터들은 입력 시간 영역을 동일한 주파수 차분으로 나눔 두번째 단위 : 입력시간영역을 주파수 영역으로 변환하고 각 차분의 매스킹 주파수를 확정

고속푸리에변환을 이용 여분의 비트들은 완전히 매스킹 된 차분에게 할당 작은 수의 비트들은 부분적으로 매스킹 된 차분으로 할당 많은 수의 비트들은 매스킹이 안된 차분으로 할당

지각부호를 이용하는 표준화 중에 하나는 MP3 임

83


8-3 인터넷에서의 멀티미디어

• 음성 및 영상 서비스는 크게 세가지 항목으로 나눌 수 있음 저 장 된 스 트 리 밍 음 성 / 영 상 (streaming stored

audio/video) 생 방 송 스 트 리 밍 음 성 / 영 상 (streaming live

audio/video) 상호작용 음성 / 영상 ( interactive audio/video)

• 스트리밍이란 , 파일의 다운로드가 시작되자마자 사용자는 시청할 수 있는 방식을 의미

8.84


8.3.1 스트리밍 저장형 오디오 / 비디오

첫 번째 항목인 저장된 스트리밍 음성 /영상은

압축된 파일들이 서버에 저장되어 있음

사용자는 인터넷을 통해 파일들을 다운로드 함

그래서 간혹 실시간 주문형 음성 /영상 (on-demand au-dio/video) 라고 불리곤 한다

여기서 스트리밍 음성 /영상은 압축된 음성 /영상

파일들의 온디멘드 (on-demand) 요구사항이라 할

수 있음

8.85


8.3.1 스트리밍 저장형 오디오 / 비디오첫 번째 접근방법 : 웹 서버 사용

두 번째 접근방법 : 웹 서버 메타파일 사용

세 번째 접근방법 : 미디어 서버 사용

네 번째 접근방법 : 매체 서버와 RTSP 사용

사례 : 주문형 비디오 (VOD, Video on Demand)

8.86


첫 번째 접근방법 : 웹 서버 사용 압축된 AV 파일은 텍스트 파일과 같이 다운로드할

수 있음클라이언트 (브라우저 ) 는 HTTP 서비스를 사용할 수

있고 , 파일을 다운로드 하기 위해 GET 메시지를 보낼 수 있음

웹 서버는 클라이언트 (브라우저 ) 에 압축된 파일을 보낼 수 있음

그 후 , 클라이언트 (브라우저 ) 는 파일을 재생하기 위해 일반적으로 매체 재생기 (media player) 라는 어플리케이션을 사용할 수 있음

이러한 접근은 스트리밍을 사용하지 않고 매우 단순하지만 약점이 있음 압축 한 후에도 파일이 큼 파일이 실행되기까지는 다운로드가 완료되어야 함

87


Figure 8.24 : 웹 서버 (Web server) 이용

8.88


두 번째 접근방법 : 웹 서버 메타파일 사용 AV 파일을 다운로드 하기 위해 매체 재생기는 웹

서버와 직접적으로 연결웹 서버는 실제 AV 파일과 AV 파일에 대한 정보를

갖는 메타파일을 저장 접근 방법의 단계

1. HTTP 클라이언트는 GET 메시지를 사용하여 웹 서버에 접근

2. 메타파일에 대한 정보가 응답으로 되돌아옴3. 메타파일은 매체 재생기로 보내짐4. 미디어 플레이어는 AV 파일에 접근하기 위하여

메타파일에 있는 URL 을 사용5. 웹 서버는 응답한다

89


Figure 8.25 : 웹 서버 메타파일 사용

8.90


세 번째 접근방법 : 미디어 서버 사용 두 번째 접근 방법의 문제

클라이언트와 매체 재생기는 모두 HTTP 서비스를 사용한다는 것 HTTP 는 TCP 위에서 동작되며 , AV 파일을 검색하기엔 적절치 못함

매체 서버와 같은 다른 서버를 요구1. HTTP 클라이언트는 GET 메시지를 사용하여 웹 서버에 접근2. 메타파일 정보가 응답으로 되돌아 옴3. 메타파일은 매체 재생기로 보내짐4. 매체 재생기는 파일을 다운로드하기 위해 메타파일에 있는 URL 을

사용하여 미디어 서버에 접근한다 , 다운로드는 UDP 를 사용하는 어떤 프로토콜에 의해 될 수 있다

5. 매체서버는 응답한다

91


Figure 8.26 : 미디어 서버 사용

8.92


네 번째 접근방법 : 매체 서버와 RTSP 사용 RTSP 는 스트리밍 처리를 위해 더 많은 기능을 추가하도록 설계되었고 ,

RTSP 를 사용하여 AV 의 실행을 제어할 수 있음

RTSP 는 FTP 의 두 번째 연결과 유사한 대역외 (out-of-band) 제어 프로토콜

그림 8.27 은 매체 서버와 RTSP 를 보여줌1. HTTP 클라이언트는 GET 메시지를 사용하여 웹 서버에 접근2. 메타파일에 대한 정보가 응답으로 되돌아옴3. 메타파일은 매체 재생기로 보내짐4. 매체 재생기는 매체 서버와 연결을 생성하기 위해 SETUP 메시지를 보낸다5. 매체 서버가 응답6. 매체 재생기는 플레이 ( 다운로딩 ) 를 시작하기 위해 PLAY 메시지를 보냄7. AV 파일은 UDP 위에서 실행되는 또 다른 프로토콜을 사용하여 다운로드8. 연결은 TEARDOWN 메시지를 사용하여 종료된다9. 매체 서버가 응답한다

93


Figure 8.27 : 매체 서버와 RTSP 사용

8.94


사례 : 주문형 비디오 주문형 비디오 (VOD, Video On Demand)

시청자가 시청가능한 VOD 를 선택하여 시청

양방향 통신을 제공

실시간으로 비디오 시청

시청자의 컴퓨터 , 미디어플레이어 , 또는 DVR 와 같은 장치를 사용

케이블 TV, 위성 TV 그리고 IPTV 제공업체는 pay-per-view 와 무료 VOD 콘텐츠 스트리밍을 제공

인터넷 TV 또한 점차적으로 VOD 방식을 이용하고 있다

95


8.3.2 스트리밍 생방송 Audio/Video(AV) 두 번째 절에서는 , 스트리밍 생방송 Audio/Video 에 대해

알아본다 사용자는 인터넷을 통해 방송되는 오디오와 비디오를 받을

수 있다 이와 같은 애플리케이션의 좋은 예는 인터넷 라디오와

인터넷 TV 이다

사례 : 인터넷 라디오

사례 : 인터넷 TV(ITV, Internet Television)

사례 : IPTV

8.96


사례 : 인터넷 라디오 웹캐스트 서비스

인터넷을 통해 뉴스 , 스포츠 , 이야기 , 그리고 음악을 제공 세계 어디서나 청취 가능 오디오는 일반적으로 MP3 또는 비슷한 소프트웨어로

압축되고 그 비트들은 TCP 또는 UDP 패킷으로 전송 됨

97

사례 : 인터넷 텔레비전 (ITV) 시청자가 방송 프로그램 라이브러리에서 시청하고 싶은 방송

프로그램을 선택하여 시청 가능 인터넷 TV 의 최초 모델은 스트리밍 인터넷 TV 또는

인터넷을 통해 제공하는 선택형 비디오 서비스


사례 : IPTV 실시간 전달 및 대화형 TV 를 위한 차세대 기술 기존의 TV 신호 전송 대신 인터넷으로 전송 IPTV 는 ITV 와 다름

인터넷 TV 는 생성 및 관리는 서비스 제공자에 의해 제공되지만 인터넷 환경에 따른 서비스 품질은 제어할 수 없다

IPTV 는 높은 서비스 품질을 제공 장점

일반 케이블 방송이나 위성 네트워크에서 제공하는 모든 콘텐츠를 사용자에게 제공

서비스 이용자는 셋톱 (set-top) 박스를 이용하여 콘텐츠를 선택할 수 있음

적은 대역폭을 사용하여 많은 콘텐츠와 여러 기능을 제공

98


8.3.3 실시간 대화형 오디오 / 비디오

세번째 절에서는 , 실시간 대화형 AV(audio/video) 에서 사람들은 실시간으로 다른 사람과

통신을 한다

인터넷 폰이나 IP 상의 음성 (voice) 은 이러한

어플리케이션의 예

화상회의는 사람들이 시각적으로 그리고 구두로

통신하는 것을 허락하는 또 다른 예

8.99


8.3.3 실시간 대화형 오디오 / 비디오 ( 계속 ) 특징

시간적인 관계 타임스탬프 재생 버퍼 정렬 멀티캐스팅 변환 혼합

8.100


8.3.3 실시간 대화형 오디오 / 비디오 ( 계속 )순방향 오류 정정

해밍거리를 이용한 오류 정정 XOR 를 이용한 오류 정정 청크 키워넣기 해밍 거리와 끼워넣기 결합 복합 해상도 패킷 (Compounding High- and Low-

Resolution Packets)

실시간 어플리케이션의 사례 : Skype

8.101


특징 시간적인 관계

패킷 교환망에서 실시간 데이터는 하나의 세션 동안 패킷들 간의 시각적인 관계 유지를 필요로 한다

102

Figure 8.28 : 시간 관계


Figure 8.29 : 지터 (jitter)

8.103


특징 ( 계속 ) 타임스탬프

지터를 해결하는 하나의 방법

104

지터를 방지하기 위해서 패킷에 타임스탬프 정보를 더하면 도착 시간과 재생시간을 구분하여 처리할 수 있다


Figure 8.30 : 타임스탬프

8.105


특징 ( 계속 ) 재생 버퍼

도착 시간과 재생 시간을 분리하기 위해서는 재생될

때까지 수신한 데이터를 저장할 버퍼를 말함

세션이 시작되면 수신자는 임계치가 될 때까지 데이터의

재생을 지연하게 됨

데이터가 버퍼에 저장되는 것은 가변율로 저장되나

버퍼에서 꺼내 재생하는 것은 고정된 단위로 이루어짐

106


Figure 8.31 : 재생 버퍼

8.107


Figure 8.32 : 패킷들의 시간선

8.108


특징 ( 계속 ) 정렬

실시간 트래픽에 대한 시간 관계 정보와 타임스탬프 이외에 하나의 특징이 필요 , 이는 각 패킷에 대한 순서번호

타임스탬프만으로는 수신자가 패킷이 유실된 경우 이를 알 수 없다

멀티캐스팅트래픽이 많아질 수 있으므로 데이터가 분산되어야 함

변환때때로 실시간 트래픽은 다른형식으로 변환되어야 함중계기는 대역폭이 큰 화상신호를 대역폭이 적은 낮은

품질의 신호로 바꿀 수 있는 컴퓨터

109


특징 ( 계속 )혼합

동시에 데이터를 전송할 수 있는 송신자가 하나 이상인

경우 트래픽은 다중 스트림으로 구성

이때 트래픽을 하나의 스트림으로 줄이려면 서로 다른

송신자의 데이터를 하나의 스트림으로 혼합 시켜야 함

혼합기는 서로 다른 송신자의 신호들을 수학적으로 더해

하나의 신호로 생성하는 일을 함

110


순방향 오류정정 (FEC, forward error correction) 오류 정정 또는 패킷 교환은 즉각적으로 이뤄져야 함

해밍 거리를 이용한 오류 정정만약 s 개의 오류를 찾았다면 , 최소 해밍거리는 dmin = s

+1만약 t 개의 오류를 탐지했다면 , dmin = 2t + 1 이 됨이 말은 많은 중복 데이터를 전송해야 한다는 것

111


순방향 오류정정 ( 계속 ) XOR 를 이용한 오류 정정

청크 끼워넣기멀티미디어 FEC 기법들은 수신자 측에서 몇 개의 청크가 유실되는 것을 허용

한 개의 청크가 유실되면 수정 가능하지만 패킷의 모든 청크가 유실이 되면 복구를 할 수 없다

112


Figure 8.33 : 끼워넣기

8.113


순방향 오류정정 ( 계속 ) 해밍 거리와 끼워넣기 결합

N 비트의 원본 패킷에 수정해야 할 t 비트의 오류가 존재할 때 n 비트는 m 개의 행과 일정 비트단위로 열을 구성하며 열의 방향으로 전송

이러한 방법은 자동적으로 m x t 개 이상의 오류를 수정할 수 있음

복합 해상도 패킷 (Compounding High- and Low-Resolution Packets)각 패킷에 대한 대한 저해상도의 여분 패킷을 복제그리고 다음 패킷에 여분 패킷을 포함 시킴

114


Figure 8.34 : 복합 해상도 패킷

8.115


실시간 어플리케이션의 사례

Skype (Sky peer-to-peer)Jaan Talinn, Priit Kasesalu, Ahti Heinla 가 최초로

개발한 peer-to-peer VoIP 응용 프로그램

인터넷을 통해 프로그램에 등록된 사람과 PC 간의

음성통화를 제공

PC 와 PC 사이의 통화는 무료지만 , PSTN 또는

휴대전화에 서비스를 이용할 때는 유료로 제공

116


8-4 실시간 전송 프로토콜 (RTP, REAL-TIME INTERACTIVE PROTOCOLS)

• 가 장 흥 미 롭 고 복 잡 한 실 시 간 대 화 형 멀티미디어에 대해 알아보자

• 이 어플 리케이션은 인 터넷 분야의 많은 관심을 불러일으켰으며 여러 어플리케이션 계 층 프 로 토 콜 들 은 이 어 플 리 케 이 션 을 조작하기 위해 설계되었음

8.117


Figure 8.35 : 실시간 멀티미디어 시스템 개략도

8.118


8.4.1 새로운 프로토콜의 필요성 TCP/IP 프로토콜 구조의 하위 3 계층 (물리 ,

데이터링크 , 네트워크 계층 ) 은 데이터 전달을 위해 설계되었기 때문에 바꿀 필요가 없다

그렇기 때문에 어플리케이션과 전송계층에 대해서만 생각하면 됨

어플리케이션 계층 전송 계층

전송계층의 요구사항 UDP 또는 TCP 의 요구사항

8.119


어플리케이션 계층

대화형 실시간 멀티미디어를 위한 어플리케이션

프로토콜의 개발이 필요

음성회의와 화상회의의 성질이 다르기 때문

몇몇의 어플리케이션은 오디오와 비디오 전송을

정의한 표준화를 사용하지만 모든 어플리케이션이

그렇지는 않음

연동 가능한 어플리케이션 프로토콜이 필요

120


전송 계층

단일 표준의 부재와 멀티미디어 어플리케이션의

일반적인 특징은 모든 멀티미디어 어플리케이션을

위해 전송 계층 프로토콜 사용에 대해 의문이 든다

대화형 실시간 멀티미디어 어플리케이션의

요구사항에 대해 생각해볼 필요가 있음

그리고 UDP 또는 TCP 가 이러한 요구사항을

만족하는지 확인해야 함

121


전송 계층 ( 계속 ) 상호 작용 실시간 멀티미디어를 위한 전송 계층 요구사항

송신자와 수신자 간의 협의

패킷 스트림 생성

소스 동기화

오류 제어

혼잡 제어

지터 제거

송신자 식별

122


전송 계층 ( 계속 ) 실시간 멀티미디어 처리를 위한 UDP, TCP 요구사항

UDP 와 TCP 모두 모든 요구사항을 만족시키진 못함클라이언트 - 서버 소켓을 사용하기 위해 전송 계층

프로토콜이 필요어플리케이션 계층이 전송 계층의 일을 할 수 없기 때문

따라서 다음과 같은 3 가지 상황을 선택할 수 있음UDP 와 TCP 의 특징을 합한 새로운 전송 계층 프로토콜을

사용TCP 가 충족시키지 못한 요구 사항은 다른 전송기법을

TCP 와 결합하여 사용UDP 가 충족시키지 못한 요구사항은 다른 전송기법을

UDP 와 결합하여 사용

123


Table 8.6: 실시간 멀티미디어 처리를 위한 UDP, TCP 요구사항

8.124


8.4.2 RTP 실시간 전송 프로토콜 (RTP, Real-time Transport Proto-

col) 은 인터넷 상에 실시간 트래픽을 관리하기 위해서 설계된 규약

RTP 는 전달 메커니즘 ( 멀티캐스팅 , 포트번호 , 기타 등등 ) 이 없음 그러므로 반드시 UDP 와 함께 이용

RDP 는 UDP 와 멀티미디어 응용 사이에 존재 문서와 표준화 기술에서는 RTP 를 전송 프로토콜 ( 전송 계층 프로토콜이

아닌 ) 로 취급하며 응용 계층에 위치해 있다고 주장한다 ( 그림 8.36 참조 )

RTP 패킷 형식

UDP 포트

8.125


Figure 8.36 : TCP/IP 프로토콜에서의 RTP 위치

8.126


RTP 패킷 형식

127

Figure 8.37 : RTP 패킷 헤더 형식


각 필드의 설명

Ver. : 버전번호를 정의

P. : 이 값이 설정되면 패킷 마지막에 패딩이 있음을 나타냄

X. : 일반 헤더와 데이터 사이에 추가적인 확장 헤더가

있음을 나타냄

기여자 카운트 : 기여자 소스의 개수를 나타냄

M. : 어플리케이션에서 표시자 역할

8.128

RTP 패킷 형식 ( 계속 )


Table 8.7: 페이로드 유형 각 필드의 설명 ( 계속 )

패이로드 유형

순서번호 : RTP 패킷에 번호매기기 위해 사용 타임스탬프 : 패킷 간의 시간 관계를 나타냄 동기 발신지 식별자

만약 하나의 발신지만 있으면 발신지를 나타냄 그러나 여러 개의 발신지가 있다면 믹서가 동기 발신지가 되고 다른

발신지들은 기여자가 됨 발신 식별자의 값은 발신지가 선택한 임의의 값이 됨

기여자 식별자 : 필드 각각은 발신지를 나타내며 최대 15 개까지 정의

8.129

Table 8.7: 페이로드 유형


UDP 포트

RTP 자체로 전송계층 규약이지만 RTP 패킷은

직접 IP 패킷에 캡슐화 되어 전송될 수 없음

RTP 는 응용프로그램처럼 다루어져서 UDP 데이터그램에 캡슐화되어야 함

130

RTP 는 임시의 짝수 UDP 포트를 사용한다


8.4.3 RTCP RTP 는 송신자로부터 목적지까지 데이터를

전달하는 하나의 메시지 유형만 허용많은 경우 세션 동안 이것과는 다른 메시지들이

필요하게 된다이런 메시지들은 플로우와 데이터의 품질을 제어하며

수신자로 하여금 송신자 혹은 송신자들에게 피드백을 보내도록 함

실시간 전송 제어 규약인 RTCP(Real-time Trans-port Control Protocol) 는 이런 목적을 위해 설계된 규약 RTCP 는 RTP 패킷에서 수행되는 페이로드가 아닌 RTP

의 자매 프로토콜

8.131


8.4.3 RTCP ( 계속 ) RTCP 패킷

송신자 보고 패킷 수신자 보고 패킷 발신지 기술 패키지 Bye 메시지 응용 지정 메시지

UDP 포트

대역폭 이용

요구 사항 이행8.132


8.4.3 RTCP ( 계속 ) RTCP 는 다음과 같은 함수를 제공

1. RTCP 는 송신자의 멀티미디어 스트림에 대한 네트워크 혼잡과 관련된 성능을 알림

2. RTCP 패킷의 정보는 동일한 소스와 관련된 다른 스트림을 동기화 하는데 사용할 수 있음a. 송신자는 각각의 ID 를 필요로 함

각 원천 데이터가 다른 SSRC 가 있을 수 있지만 , RTCP 는 고유한 ID 를 제공 (CNAME)

CNAME 는 수신자가 서로 다른 두 개의 데이터를 하나의 원천 데이터로 결합할 수 있도록 사용할 수 있음

b. 정식 이름은 그것 자체로 동기화를 제공할 수 없음 원천 데이터의 동기화를 위해서 RTP 패킷의 타임스탬프 필드에서

제공하는 상대 타이밍 이외에 스트림의 절대 타이밍을 알아야 함3. RTCP 패킷은 수신자측에 유용한 송신자 정보를 나름

133

user@host


RTCP 패킷

134

Figure 8. 38 : RTCP 패킷 유형


송신자 보고 패킷

활성화된 서버에서 주기적으로 간격 사이에 전달되는

RTP 패킷의 전송 및 수신의 통계를 보냄

전달된 보고 패킷은 다음과 같은 정보들을 담고 있음 : RTP 스트림의 SSRC 1970년 1월 1 일 자정 이후로부터 지나간 초 단위의 벽걸이

시계 및 인접 타임스탬프의 혼합인 절대 타임 스탬프

세션 시작부터 보내진 바이트와 패킷의 수

8.135

RTCP 패킷 ( 계속 )


수신자 보고 패킷

RTP 패킷을 전달하지 않은 수동적인 참가자들에 의해 배포

수신자 보고 패킷은 수신자와 송신자에 서비스 품질에

대해서 알려줌

수신자 보고는 다음과 같은 정보들을 담고 있음 : 수신 보고가 갱신한 RTP 스트림의 SSRC 패킷 손실의 분수

마지막 순서 번호

간격의 지터

8.136

RTCP 패킷 ( 계속 )


RTCP 패킷 ( 계속 ) 발신지 기술 메시지

SSRC발신자의 CNAME실명 , 이메일 주소 , 전화번호와 같은 추가적인 정보

추가적인 데이터를 포함할 수 있음 ( 예 : 비디오 자막 ) Bye 메시지

스트림을 종료하기 위해 전송

응용 지정 메시지새로운 응용을 사용하기 원하는 응용에 대한 패킷

137


UDP 포트

RTCP 는 RTP 와 마찬가지로 UDP 포트를

사용하지 않음

임시 포트를 사용해야 함

138

RTCP 는 RTP 를 위해 선택된 포트번호 다음에 오는 홀수 번 UDP 포트를 사용해야 한다


대역폭 이용 RTCP 패킷들은 능동적 송신자에게서만 보내지는 게 아니라

능동적인 송신자들보다 훨씬 많은 수동적 송신자들로부터 보내

짐 만약 RTCP 트래픽이 제어되지 않으면 손을 벗어날 수 있다는 것을 의미

이 상황을 제어하기 위해 RTCP 는 세션에서 사용되는 트래픽을 작은

수준으로 유지하기 위해 제어장치를 이용

이 작은 부분의 큰 부분인 (x) 는 수동적 송신자들에 의해서

만들어진다고 표시된 RTCP 패킷이고 , 작은 부분인 (1-x) 는

능동적인 송신자들에 의해서 만들어진다고 표시된 RTCP 패킷이다

RTCP 프로토콜은 능동적 송신자들에 대한 수동적

송신자들의 x 의 값을 정의하기 위한 장치를 사용한다 139


세션에 대한 대역폭이 1Mbps 로 할당되었다고 가정해

보자 . RTCO 트래픽은 대역폭의 5% 인 50 Kbps 를

가진다 . 만약 여기에 오직 2 명의 능동적 송신자와 8명의 수동적 송신자만 있다면 각각의 송신자 혹은

수신자들은 오직 5Kbps 만 가진다 . 만약 RTCP 의

평균적 크 기 가 5Kbits 라 면 각 각 의 송 신 자 혹 은

수신자들은 1 초에 오직 하나의 RTCP 패킷을 보낼 수

있다 .

Example 8.10

8.140


요구사항 이행 RTP 와 RTCP 의 조합이 어떻게 실시간 멀티미디어

응용프로그램의 요구사항에 응답하는지 볼 것이다 디지털 음악이나 영상 , 비트의 연속은 몇 개의 청크로 되어 있음 각각의 청크들은 이전의 청크 혹은 다음의 청크와 구분하기 위한 미리

정의된 경계를 가지고 있다 하나의 청크는 특별한 인코딩 , 시퀀스 넘버 , 타임스탬프 , 동기화

소스 식별자와 그리고 하나 혹은 그 이상의 기여 소스 식별자를 정의하는 RTP 패킷 속에 캡슐화 되어 있다

1. 첫 번째 요구사항 : 송신자 - 수신자 협상은 RTP/RTCP 프로토콜만으로는 만족될 수 없음

2. 두 번째 요구사항 : 청크의 스트림 생성은 각각의 청크를 RTP 패킷에 캡슐화 하는 것과 시퀀스 번호를 부여하는 것으로 제공

141


요구사항 이행 ( 계속 )3. 세 번째 요구사항 : 소스의 동기화는 32 비트 식별자로 각 소스를

식별하고 RTP 패킷과 RTCP 패킷의 절대 타임스탬프에 상대 타임스탬프를 사용하여 만족 시킴

4. 네 번째 요구사항 : 오류제어는 연속 번호를 RTP 패킷에 사용하는 것과 FEC 메서드를 이용하여 응용프로그램이 분실된 패킷을 재생산하는 것으로 만족 시킴

5. 다섯 번째 요구사항 : 혼잡제어는 송신자의 손실 패킷의 번호를 공지하는 RTCP 를 사용하는 수신자로부터 피드백 받음으로서 만족 됨

6. 여섯 번째 요구사항 : 지터 제거는 타임스탬프와 데이터의 버퍼 재생에 사용되는 각 RTP 패킷에서 제공하는 순서에 의해 이루어짐

7. 일곱 번째 요구사항 : 소스 ID 는 송신자가 보낸 소스 설명 패킷 (RTCP)에 포함된 CNAME 을 통하여 제공 됨

142


8.4.4 세션 초기화 프로토콜 (SIP) 우리는 오디오 - 비디오 회의를 위한 인터넷을

사용하는 방법에 대해 논의했음

RTP 와 RTCP 는 이러한 서비스를 제공하는 데

사용할 수 있지만 , 한 구성요소가 빠져 있음

바로 참가자를 호출하는 데 필요한 신호 시스템이다

8.143


8.4.4 세션 초기화 프로토콜 ( 계속 ) SIP 는 IETF 에 의해 만들어졌음

이는 멀티미디어 세션을 설정하고 , 관리하며 , 종료하기 위해 사용되는 응용 계층 규약

이는 두 개체 간 , 여러 개체간 혹은 멀티캐스트 세션을 생성하기 위해 사용되어질 수 있음

SIP 는 하부 전송 계층과 무관하게 만들어졌기 때문에 , UDP, TCP 및 SCTP 상에서 동작할 수 있다

인터넷에 연결되어 있는 사용자들 간의 요청을 수립 사용자들이 IP 주소가 바뀔 수 있기 때문에 인터넷 상에서 사용자들의

IP 주소를 찾는다 사용자들이 conference call 에 참여 할 수 있거나 원하면 찾아낸다 사용될 미디어와 부호화 형태 측면에서 사용자의 역량을 알아냄 포트번호와 같은 파라미터들을 정의해 세션 설정을 수립 콜 홀딩 , 콜 포워딩 , 새 참가자 수락 , 세션 파라미터 변경 등과 같은

세션 관리 함수들을 제공

144


8.4.4 세션 초기화 프로토콜 ( 계속 )통화 상태주소메시지

요청 메시지 응답 메시지

첫번째 시나리오 : 간단한 세션 세션의 설정 통신 세션의 종료

8.145


8.4.4 세션 초기화 프로토콜 ( 계속 ) 두 번째 시나리오 : 수신자 추적 SIP 메시지 형식 및 SDP 프로토콜

시작 라인

상태 라인

헤더

본문 (Body)

파트들의 통합

8.146


통화 상태

상호적인 실시간 멀티미디어 어플리케이션들과 다른

어플리케이션의 한 가지 차이는 통신하는 당사자이다

음성 또는 화상회의에서 사용자들 사이에 하는

것이지 장치들 사이에 하는 것이 아님

SIP 프로토콜은 수신자의 위치를 찾는 동시에

참가자가 사용하는 장치의 능력을 협상할 필요가

있음

147


주소

일반적인 전화통신에서 전화번호는 송신자와

수신자로 구분

SIP 는 매우 유연하여 SIP 에서는 전자우편 주소 , IP 주소 , 전화번호 및 다른 종류의 주소들이 송신자와

수신자로 구분하기 위해 사용되어질 수 있음

그러나 주소는 SIP 형태일 필요가 있다

148


Figure 8.39 : SIP 형식

8.149


메시지 SIP 는 HTTP 와 같은 텍스트 기반의 규약

HTTP 처럼 메시지를 사용SIP 에서 메시지들은 요청과 응답 두 가지 넓은 범주로 나뉨

150

Start lineHeader // one or more linesBlank lineBody // one or more lines

Status lineHeader // one or more linesBlank lineBody // one or more lines


메시지 ( 계속 ) 요청메시지

INVITE: 초기 세션을 초기화하기 위해 발신자에 의해

사용

ACK: 세션초기화가 완료되었는지 확인하기 위해

발신자가 보냄

OPTIONS: 장치의 능력에 대해 질의

CANCEL: 이미 시작된 초기화 과정을 취소 함

REGISTER: 수신자가 불가능할 때에 연결을 만든다

BYE: 세션을 종료할 때 사용151


메시지 ( 계속 ) 응답메시지

Information Responses: SIP 1xx 형태

Successful Responses: SIP 2xx 형태

Redirection Responses: SIP 3xx 형태

Client Failure Responses: SIP 4xx 형태

Server Failure Responses: SIP 5xx 형태

Global Failure Responses: SIP 6xx 형태

152


간단한 세션 첫번째 시나리오

앨리스가 밥에게 연락을 하는 상황앨리스는 IP 주소를 그리고 밥은 SIP 주소를 통신으로

사용하고 있다통신은 설정하기 , 통신하기 , 종료하기 세 무듈로 분류

세션의 설정SIP 의 세션을 설정하기 위해서는 3 단계 핸드쉐이크를

필요로 함

153


Figure 8.40 : 간단한 SIP

8.154


간단한 세션 ( 계속 ) 통신

세션의 설정이 끝나면 앨리스와 밥은 설정 세션에서

정의된 임시포트에서 통신을 할 수 있다

짝수의 숫자를 갖는 포트는 RTP 를 위해 사용

RTCP 다음에 오는 홀수의 숫자를 갖는 포트를 사용할 수 있다

세션의 종료

세션은 어느 한 쪽에서 보낸 BYE 메시지로 종료할 수 있다

155


수신자 추적

SIP 는 몇몇의 서버를 레지스트리로 정의

어느 순간에도 사용자가 최소한 하나의 등록 서버에

등록이 되어 있다면 , 이 서버는 수신자의 IP 주소를 알 수 있음

156


Figure 8.41 : 수신자 추적

8.157


SIP 메시지 형식 및 SDP 프로토콜 SIP 요청과 응답 메시지는 네 가지 세션으로 나뉨

시작 혹은 상태라인 , 헤더 , 블랭크라인 , 바디 시작 라인

받는 사람의 주소와 SIP 버전의 뒤에 따라오는 request name 과 함께 시작하는 하나의 라인

상태 라인Three-digit 응답 코드와 함께 시작하는 하나의 라인

158

INVITE sip:[email protected]

200 OK


SIP 메시지 형식 및 SDP 프로토콜 (계속 )헤더

요청 혹은 응답 메시지에서 여러 개의 라인을 쓸 수 있음각각의 라인은 콜론과 스페이스 그리고 벨류의 뒤에 오는

line name 과 같이 시작 됨

159

Via: SIP/2.0/UDP 145.23.76.80 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] Content-Type: application/spd Content-Length: 600


SIP 메시지 형식 및 SDP 프로토콜 (계속 ) 본문 (body)

SIP 는 본문을 정의하기 위해 Session Description Protocol (SDP) 라 불리는 다른 프로토콜을 사용

본문에 있는 각각의 라인은 equal sign 과 value 뒤에 따라오는 SDP코드로 만들어져 있음

코드는 코드의 목적을 정의하는 하나의 글자 우리는 본문을 몇 개의 세션으로 나눌 수 있음

160

v=0 0=forouzan 64.23.45.8 s=computer classes i=what to offer next semester u=http://www.uni.edu [email protected] c=IN IP4 64.23.45.8 t=2923721854 2923725454

HANNAM UNIVERSITYHttp://netwk.hnu.kr 161

SIP 메시지 형식 및 SDP 프로토콜 (계속 ) 통합

아래에 나오는 내용에 따라 네 가지 메시지 요청들의 부분들을 합쳐 보자

INVITE sip:[email protected] Via: SIP/2.0/UDP 145.23.76.80 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] Content-Type: application/spd Content-Length: 600 // Blank line v=0 0=forouzan 64.23.45.8 s=computer classes i=what to offer next semester u=http://www.uni.edu [email protected] c=IN IP4 64.23.45.8 t=2923721854 2923725454

// Blank line


8.4.5 H.323 H.323 은 공중전화망 상에 있는 전화를 사용하여

인터넷에 연결되어 있는 컴퓨터 (H.323 에서는 터미널이라고 함 ) 와 통신할 수 있도록 ITU 에 의해 만들어진 표준

그림 8.42 는 오디오를 위한 H.323 의 일반적인 모습을 보여 줌 그러나 이는 비디오를 위해서도 사용할 수 있다

프로토콜 동작

8.162


Figure 8.42 : H.323 구조

8.163


프로토콜

음성 ( 비디오 ) 통신을 설정하고 유지하기 위해

여러 프로토콜을 사용

H.323 은 압축을 위해 G.711 혹은 G.723.1 을 사용

양측이 압축 방법을 협상하기 위해 H.245 라는

프로토콜을 사용

프로토콜 Q.931 은 연결을 설정하고 종료하는 데 사용

RAS 혹은 H.225 라고 불리는 또 다른 프로토콜은

게이트키퍼에 등록하는 데 사용 됨

164


Figure 8.43 : H.323 프토토콜

8.165


동작 H.323 을 이용해 통신하는 전화의 동작절차

1. 터미널은 게이트키퍼에 방송메시지를 전송 , 게이트키퍼는 IP 주소로 응답

2. 터미널과 게이트키퍼는 대역폭을 협상하기 위해 H.225를 사용하여 서로 통신

3. 터미널 , 게이트키퍼 , 게이트웨이 및 전화는 연결을 설정하기 위해 Q.931 을 사용하여 통신

4. 터미널 , 게이트키퍼 , 게이트웨이 및 전화는 압축 방법을 협상하기 위해 H.245 를 사용하여 통신

5. 터미널 , 게이트웨이 및 전화는 RTCP 의 관리 하에 RTP를 사용하여 오디오를 교환

6. 터미널 , 게이트키퍼 및 전화는 연결을 종료하기 위해 Q.931 을 사용하여 통신


Figure 8.44 : H.323 예

8.167


8.4.6 SCTP 스트림 제어 전송 프로토콜 (SCTP, Stream Con-

trol Transmission Protocol) 멀티미디어 통신을 위한 보다 나은 프로토콜을

생성하기 위해

UDP 와 TCP 의 특징을 조합하여 설계한 새로운

전송 계층 프로토콜이다

8.168


8.4.6 SCTP ( 계속 ) SCTP 서비스

프로세스간 통신 멀티 스트림 멀티호밍 전이중통신 연결 지향 서비스 신뢰성 있는 서비스

SCTP 특징 전송 순서 번호 (TSN, Transmission Sequence Number) 흐름 식별자 (SI, Stream Identifier) 흐름 순서 번호 (SSN, Stream Sequence Number) 패킷 확인응답 번호

8.169


8.4.6 SCTP ( 계속 ) 패킷 형식

일반 헤더 청크 (Chunks)

SCTP 결합 결합 설정 데이터 전송 연계 종료

흐름 제어 수신기 사이트 (Receiver Site) 송신기 사이트 (Sender Site)

8.170


8.4.6 SCTP ( 계속 ) 오류 제어 (Error Control)

수신기 사이트 (Receiver Site) 송신기 사이트 (Sender Site) 데이터 청크 송신 (Sending Data Chunks) SACK 청크 생성 (Generating SACK Chunks)

혼잡 제어 (Congestion Control)

8.171


SCTP 서비스

프로세스 간 통신

SCTP 는 UDP 또는 TCP 와 같이 프로세스간 통신을

제공

멀티스트림

SCTP 는 SCTP 용어로 결합이라고 하는 멀티스트림

서비스를 각 연결에 허용

172


Figure 8.45 : 멀티 스트림의 개념

8.173


SCTP 서비스 ( 계속 ) 멀티호밍

송신 호스트와 수신 호스트는 결합을 위해 각 종단에 다수의 IP 주소로 정의할 수 있음

174

Figure 8.46 : 멀티호밍 개념


SCTP 서비스 ( 계속 ) 전이중 통신

송신과 수신 버퍼를 갖고 패킷들은 양쪽 모두의 방향으로 송신

연결 지향 서비스

신뢰성 있는 서비스

175


SCTP 특징 전송 순서 번호

SCTP 는 데이터의 단위는 데이터 청크 전송 순서 번호 (TNS) 를 이용하여 데이터 청크에 번호를 부여

흐름 식별자 각 스트림은 흐름 식별자 (SI) 를 사용하여 식별

흐름 순서 번호 SI 외에 SCTP 는 각 스트림의 데이터링크를 스트림 순서 번호 (SSN) 로

정의

패킷 (Packets) 데이터는 데이터 청크 , 제어정보는 제어 청크로 운반 여러 개의 제어 청크와 데이터 청크는 하나의 패킷에 함께 묶일 수 있음 SCTP 의 패킷은 TCP 의 세그먼트처럼 동일 한 역할을 수행

176


Figure 8.47 : TCP 단편과 SCTCP 패킷 간의 비교

8.177


Figure 8.48 : 패킷 , 데이터 청크 그리고 스트림

8.178


SCTP 특징 ( 계속 ) 확인응답 번호

TCP 는 바이트 지향이고 순서번호를 참조하나 , SCTP 는

정크 지향적

제어정보만을 운반하는 세그먼트에 대하여 확인응답을

위해 TCP 는 순서번호와 확인응답 번호를 사용

SCTP 제어정보는 제어 청크에 의해 운반되며 TSN 을

필요로 하지 않음청크제어는 또 다른 적절한 형태의 제어 청크에 의해 확인응답 됨

179


패킷 형식규칙에 따른 일반적인 헤더와 청크라 불리는 블록

집합으로 구성

8.180

Figure 8.49 : SCTP 패킷 형식


패킷 형식 ( 계속 ) 일반 헤더

패킷이 보장하고 속하는 각 결합의 끝 지점을 정의특정한 결합에 속하는 패킷을 보장하고 헤더 자체를 포함하는 패킷 내용에 대한 무결성을 보존

8.181

Figure 8.50 : 일반 헤더


패킷 형식 ( 계속 ) 청크 (Chunks)

제어정보나 사용자 데이터는 청크에 의해 전달 첫 번째 세 개 필드는 모든 청크에서 가짐 정보필드는 청크의 유형을 가짐유형필드는 청크의 256 가지의 유형 중 하나로 정의 지금까지 단 몇몇의 유형만이 정의되었고 나머지는 차후에 사용되기

위해 예약 됨

8.182

Figure 8.51 : 청크의 일반 레이아웃


Table 8.8: 청크

8.183


SCTP 결합

결합 설정결합설정은 네 방향 핸드쉐이크를 요구이 절차에서 일반적으로는 클라이언트인 프로세스는 전송

계층 프로토콜로써 SCTP 를 사용하여 일반적으로 서버인 또 다른 프로세스와 함께 결합을 설정하기 원함

서버는 어떠한 결합도 받아들일 준비가 필요 ( 수동개방 )결합 설정은 클라이언트에 의해 시작 ( 능동개방 )

184

SCTP 내에서 연결을 결합이라 부른다


Figure 8.52 : 네 방향 핸드쉐이크

8.185


SCTP 결합 데이터 전송

결합의 목적은 두 개의 종단 간에 데이터를 전송하는 것TCP 와 다르게 SCTP 에서는 경계선을 인식하고 유지프로세스로부터 수신한 메시지는 데이터 청크 헤더를

메시지에 붙임으로써 하나의 데이터 청크가 되며 , 단편화가 된다면 여러 개의 데이터 청크가 됨

멀티호밍 데이터 전송 멀티호밍은 통신을 위하여 양종단 간 여러 개의 IP 주소를

정의하는 것을 허용

186


SCTP 결합 ( 계속 ) 데이터 전송 ( 계속 )

멀티스트림 전달 발신지와 목적지 사이의 데이터 청크의 이동인 데이터 전송을

다루기 위하여 TSN 번호를 사용 데이터 청크의 전달은 SI 와 SSN 으로 제어 SCTP 는 여러 개의 스트림을 지원할 수 있으며 이것은 송신기

프로세스는 서로 다른 스트림들을 정의할 수 있고 하나의 메시지는 이러한 스트림의 하나에 속할 수 있다는 것을 의미

각 스트림에는 스트림을 유일하게 정의하는 스트림 식별자 (SI) 가 할당

그러나 SCTP 는 각 스트림에 대하여 규칙과 불규칙의 두가지 데이터 전달 방식을 지원

187


SCTP 결합 ( 계속 ) 데이터 전송 ( 계속 )

단편화 SCTP 에서 이루어지는 단편화는 다음과 같이 이루어짐1. 메시지가 크기 요구 사항을 충족하기 위해 작은 조각으로 나눔2. 데이터 청크 헤더는 다른 TSN 운반 각 조각에 추가 , TSN 은

순서대로 추가되어야 한다3. 모든 헤더 청크는 동일한 스트림 식별자 (SI) 와 같은 스트림

시퀀스 번호 (SSN), 동일한 페이로드 프로토콜 식별자와 같은 U 플래그 값을 가짐

4. B 와 E 의 조합은 다음과 같이 지정a. 첫 번째 조합 : 10.b. 중간 조각 : 00.c. 마지막 조각 : 01.

188


SCTP 결합 ( 계속 ) 연계 종료

SCTP 에서는 TCP 처럼 데이터를 교환하고 있는데 참여한

두 개의 어느 쪽도 연결을 종료할 수 있다

그러나 TCP 와는 다르게 SCTP 는 절반 -종료 상황을 허용하지

않음

만약 한쪽 종단이 결합을 종료하면 다른 종단은 새로운 데이터

송신을 멈추어야 함

189


Figure 8.53 : 연계 종료

8.190


흐름 제어 TCP 와 유사 두 개의 데이터 단위인 바이트와 청크를 다룸

rwnd 와 cwnd 의 값은 바이트로 표현TSN 과 확인응답 값은 청크로 표현

수신기 사이트수신기는 한 개의 버퍼 (큐 ) 와 세 개의 변수를 가짐큐는 프로세스에 의해 미처 읽혀지지 않은 수신된 데이터 청크를 유지

첫 번째 변수는 수신된 마지막 TSN, cumTSN 을 유지두 번째 변수는 이용 가능한 버퍼 크기 winsize 를 유지세 번째 변수는 마지막 누적된 확인응답 lastACK 를 유지

191


Figure 8.54 : 흐름 제어 ( 수신 측 )

1. 사이트가 데이터 청크를 수신할 때 버퍼 (큐 ) 의 끝에 저장하고 winSize로부터 청크 크기를 뺀다 청크의 TSN 번호는 cumTSN변수에 저장

2. 프로세스가 청크를 읽을 때 큐로부터 제거하고 제거된 청크의 크기를 win-Size 에 더한다

3. 수신기가 SACK 송신을 결정할 때 lastAck 값을 검사 만약 cumTSN 보다 작다면 cumTSN 과 동일한 누적된 TSN 번호를 가진 SACK 를 보냄 또한 공개된 윈도우 크기로써 winSize 값을 포함 lastACK 의 값은 cumTSN 값을 유지시키기 위해 업데이트 한다

8.192


흐름 제어 ( 계속 ) 송신기 사이트

한 개의 버퍼와 세 개의 변수를 갖음 curTSN : 송신이 되는 다음 청크를 나타냄

rwnd : 수신기에 의하여 공개된 마지막 값을 보유

inTransi : 바이트가 전송되었고 , 미처 확인응답이 되지 않은

이동상태에 있는 바이트 수를 유지

193


Figure 8.55 : 흐름 제어 ( 송신 측 )

1. curTSN 에 의해 지적된 청크는 데이터의 크기가 rwnd – inTransit 양보다 작거나 동일하면 전송할 수 있음 청크를 전송 후 curTSN 의 값은 1 만큼 증가하고 송신되어질 다음번 청크를

가르킴 inTransit 의 값은 전송된 청크에 있는 데이터 크기만큼 증가 함

2. SACK 가 수신될 때 SACK 에 누적된 TSN 보다 작거나 또는 같은 TSN 을 가진 청크는 큐에서 제거되고 폐기된다 송신기는 더 이상 그것들에 대해서 신경 쓸 필요가 없다 inTransit 값은 폐기된 청크의 전체 크기만큼 감소 rwnd 의 값은 SACK 에 있는 공지된 윈도우 값으로 갱신

8.194


오류 제어 SCTP 는 신뢰성 있는 전송계층 프로토콜

송신기에 수신기 버퍼의 상태를 보고하기 위하여 SACK 청크를 사용

각 구현 방법에서는 수신기와 송신기 사이트를 위하여 서로 다른 형태의 개체와 타이머를 사용

수신기 사이트 수신기는 순서가 어긋난 청크들을 포함하여 큐에 도착한 모든 청크들을 저장

그러나 , 손실된 청크를 위한 공간은 남겨둠

중복 메시지를 버리지만 송신기에 보고하기 위하여 추적을 함

195


Figure 8.56 : 오류 제어 ( 수신 측 )

8.196


오류 제어 ( 계속 ) 송신기 사이트

송신 큐와 재전송 큐의 두 가지 버퍼를 요구 송신기의 상태가 어떻게 변하는지 확인하기 위한 과정

1. 모든 TSN 이나 SACK 의 cumTSN 을 가지고 있는 청크들은 더 이상 재전송을 위한 마크가 될 수 없으므로 재전송 큐나 전송 큐에서 제거 됨 청크 21 과 22 번은 재전송 큐에서 제거되며 23 번 청크는 전송 큐에서 제거

2. 현 설계 또한 전송 큐의 캡 블록들에 선언된 모든 청크들을 제거 26 번부터 28 번까지의 청크와 31 번부터 34 번까지의 청크가 전송 큐에서

제거

3. 중복 청크들 목록은 더 이상 영향을 끼치지 않음

4. SACK 청크의 광고로 인해 rwnd 의 값이 1,000 으로 바뀜

5. 청크 24, 25 전송 패킷에 대한 전송 타이머가 만료되었다고 가정하면 , 재전송 대기열의 새로운 재전송 타이머 설정은 TCP 에 대한 논의 지수 백오프 규칙에 따라 설정

6. 4 개의 청크만이 전송하기 때문에 inTransit 의 값은 400 이 됨 재전송 큐에 있는 청크들은 곧 사라지기 때문에 카운트를 새지 않음

197


Figure 8.57 : 오류 제어 ( 송신 측 )

8.198


Figure 8.58 : SACK 청크 수신 후의 새로운 상태 ( 송신 측 )

8.199


오류 제어 ( 계속 ) 데이터 청크 송신

하나의 종단은 curTSN 보다 크거나 같은 TSN 을 가진 전송 큐에 데이터 청크가 있거나 또는 재전송 큐에 데이터 청크가 있을 때마다 패킷을 송신

재전송 큐는 우선 순위를 갖음그러나 패킷에 포함되어 있는 데이터 청크 또는 청크의 총

크기는 rwnd-inTransit 을 초과해서는 안됨프레임의 총 크기는 MTU 크기를 초과해서는 안됨재전송

손실되거나 또는 폐기된 청크를 제어하기 위해서는 재전송 타이머를 사용하는 것과 동일한 손실된 청크를 가진 세 개의 SACK 를 수신하는 두가지 전략을 채택

200


오류 제어 ( 계속 ) 데이터 청크 송신 ( 계속 )

재전송 ( 계속 ) 재전송 : 세그먼트의 ACK 를 위한 대기시간을 처리하는 재전송

타이머를 사용

RTO 를 계산하기 위해 RTTM, RTTS, RTTD 를 사용하여 계산

4 번 누락 보고 : 수신부에서 특정 데이터 청크의 누락을 나타내는

4 번의 SACK 정보를 받는 경우 , 해당 청크를 누락시킬지 재전송

큐에 이동시킬지 고려해야 함

201


오류 제어 ( 계속 ) SACK청크 생성

1. 한 종단에서 다른 쪽 종단에 데이터 청크를 보낼 때에는 반드시 un-acknowledge 데이터 청크의 영수증을 알리는 SACK 청크를 포함해야 함

2. 한 종단에서 데이터가 포함된 패킷을 받지만 보낼 데이터가 없을 때 지정된 시간 안에 확인응답 청크가 필요

3. 한 종단은 다른 모든 수신 패킷에 대해 적어도 하나의 SACK 청크를 보내야 함 ( 이 규칙은 두 번째 규칙을 무시 )

4. 만약 순서가 벗어난 데이터 청크 패킷이 도착하면 , 수신기는 즉시 송신기에 SACK 청크를 보냄

5. 만약 한 종단에서 새로운 데이터 청크로 패킷을 받지 않고 중복 데이터 청크를 받으면 , 즉시 SACK 청크로 알림

혼잡제어 SCTP 는 TCP 처럼 네트워크의 혼잡에 종속되는 패킷을 가진 전송 계층

프로토콜 , SCTP 설계자들은 TCP 의 혼잡 제어와 동일한 전략을 사용

202


8-5 서비스 품질 (QoS, QUALITY OF SERVICE)

• 인터넷은 기본적으로 예측 가능한 서비스들의 성능을 보장하기 위해 설계 되었음• 서 비 스 의 품 질 은 정 의 되 는 것 보 다 는 논 의 가 계속되어 온 인터네트워킹 (internetworking) 의 문제• 여기서는 서비스 품질을 한 흐름이 달성하고자 하는 그 어떤 것이라고 비공식적인 정의를 한다

8.203


8.5.1 흐름 특성

전통적으로 신뢰성 (reliability), 지연 (delay), 지터 (jitter) 와 대역폭 (bandwidth) 등 네 종류의

특성이 한 흐름에 주어져 왔음

각 응용프로그램 유형의 요구사항을 위한 특성을

정의하자

정의 어플리케이션의 민감도

8.204


정의

신뢰성 : 신뢰성 부족은 재전송을 일으키는

패킷이나 확인응답이 유실되는 것을 의미

지연 : 응용에 따라 견딜 수 있는 지연의 정도가

다름

지터 : 같은 흐름에 속하는 패킷들에 대한 지연의 변이

대역폭 : 서로 다른 응용은 필요로 하는 대역폭이 다름205


응용의 민감도

206

Table 8.9: 흐름 특성에 따른 응용의 민감도


8.5.2 흐름 등급

흐름의 특성에 기반하여 흐름을 각 특성의 수준을

갖는 그룹으로 분류할 수 있음

인터넷 커뮤니티는 아직 공식적으로 분류가 정의되지 않음

그러나 예를 들어 FTP 와 같은 프로토콜은 높은

수준의 신뢰성과 중간 수준의 대역폭을 필요로 하나

지연이나 지터의 수준은 이 프로토콜에서 중요하지

않다

8.207


비록 인터넷에서 일반적인 흐름 등급이 정해져 있진 않지만 , ATM 과 같은 프로 토콜에서 5 등급으로 서비스를 정의하고 있다 .

Example 8.11

a. 고정 비트율 (CBR, Constant Bit Rate).

b. 가변 비트율 - 비실시간 (VBR-NRT, Variable Bit

Rate-Non Real Time).

c. 가 변 비 트 율 - 실 시 간 (VBR-RT, Variable Bit

Rate-Real Time).

d. 가용 비트율 (ABR, Available Bit Rate).

e. 비규정 비트율 (UBR, Unspecified Bit Rate).8.208


8.5.3 QoS 향상을 위한 흐름 제어

인터넷에서 흐름의 공식적인 등급은 정의되어 있지 않음

IP 데이터그램은 데이터그램의 집합을 어떤 응용이

전송했는지에 대해 비공식적으로 서비스의 유형이 정의된

ToS 필드를 가짐

응용이 요구하는 서비스의 단일 수준의 특정 유형을

지정하는 경우 , 이러한 서비스 수준을 위해 규정을

정의할 수 있다

이것들은 몇 가지 메커니즘을 이용하여 가능

8.209


8.5.3 QoS 향상을 위한 흐름 제어 ( 계속 )스케쥴링

FIFO 큐잉 (FIFO Queuing) 우선순위 큐잉 (Priority Queuing) 가정 공정 큐잉 (Weighted Fair Queuing)

트래픽 쉐이핑 및 폴리싱 (Traffic Shaping or Policing) 리키 버켓 (Leaky Bucket) 토큰 버켓 (Token Bucket)

자원 예약 수락 제어

8.210


스케줄링

FIFO 큐잉패킷들이 노드가 처리할 준비가 되었을 때까지 버퍼에서

기다림

만약 평균도착률이 평균처리율보다 높으면 큐는 꽉차게

될 것이며 새로운 패킷들은 폐기될 것이다

다음 그림은 FIFO 큐의 개념적인 단면을 보여줌

211


Figure 8.59 : FIFO 큐

8.212


스케줄링 ( 계속 ) 우선순위 큐잉

패킷들에게 먼저 우선순위 등급이 주어짐

각 우선순위 등급은 우선순위만의 큐를 가짐 우선순위가 가장 높은 큐에 있는 패킷이 가장 먼저 처리

우선순위가 가장 낲은 큐에 있는 패킷은 가장 마지막에 처리

시스템은 큐가 비워질 때까지 일을 멈추지 않음

패킷의 우선순위 IPv4 헤더의 ToS 필드 , IPv6 의 우선순위 필드 , 목적지 주소에

할당된 우선순위 번호 또는 응용에 할당된 우선순위 번호 ( 목적지 포트번호 ) 등 패킷 헤더의 특정 필드로부터 결정 됨


Figure 8.60 : 우선순위 큐

8.214


스케줄링 ( 계속 ) 가중 공정 큐잉

이 기술에서는 패킷들에게 여전히 서로 다른 등급이

주어지고 서로 다른 큐에 들어감

큐들은 큐의 우선 순위에 따라서 가중치가 주어짐

높은 우선순위가 높은 가중치를 의미

시스템은 각 큐에 있는 패킷들을 라운드 로빈 방식으로

차례대로 처리하는데 해당 가중치에 따라서 각 큐에서

선택되는 패킷 수가 결정됨

215


Figure 8.61 : 가중 공정 큐

8.216


트래픽 쉐이핑 및 폴리싱

트래픽양이나 트래픽율을 제어하기 위한 것을

트래픽 성형 또는 트래픽 치안이라고 부름

첫 번째 조건은 트래픽이 네트워크를 출발할 때 사용

두 번째 조건은 데이터가 네트워크로 들어갈 때 사용

리키버켓

버스트 트래픽을 평탄하게 만들 수 있음

버트한 입력 부분은 물통에 저장되고 평균 비율로 출력 됨

217


Figure 8.62 : 리키 버켓 (Leaky bucket)

8.218


Figure 8.63 : 리키 버켓 구현 (Leaky bucket implementation)

8.219


트래픽 쉐이핑 및 폴리싱 ( 계속 ) 리키 버켓 ( 계속 )

다음은 가변길이 패킷에 대한 알고리즘클럭의 틱에서 카운터를 n 으로 초기화

만약 n 이 패킷 크기보다 크면 패킷을 송신하고 카운터를 패킷

크기만큼 감소 , 이 단계를 n 이 패킷 크기보다 작은 한 반복한다

카운터를 리셋하고 1 단계로 간다

220

리키 버켓 알고리즘은 데이터율을 평균으로 만들어 버스트 트래픽을 고정 데이터율 트래픽으로 조정한다 .

만약 버켓이 가득 차면 패킷을 폐기할 수 있다 .


트래픽 쉐이핑 및 폴리싱 ( 계속 ) 토큰 버켓

쉬고 있는 호스트가 토큰의 형태로 미래를 위해 신용을 축적하도록 만듬 버켓의 용량은 c 개의 토큰이고 초당 r 개의 토큰이 버켓으로

들어간다고 가정 이 시스템은 모든 셀의 데이터 전송에 대해 하나의 토큰을 제거

토큰 버켓과 리키 버켓의 결합221

패킷의 최대 개수 = rt + c

최대 평균 비율 = (rt + c)/t packets per second

토큰 버켓은 규정된 최고 데이터율 (regulated maximum rate) 에 버스트 트래픽을 허용한다 .


Figure 8.64 : 토큰 버켓 (Token bucket)

8.222


버켓 용량이 토큰 10,000 개이고 초당 1,000 개의

토큰이 추가된다고 가정하자 . 만약 시스템이 10 초

이상 유휴상태라면 , 버켓은 10,000 개의 토큰을

수집하여 가득 찬 상태가 된다 . 앞으로 더 이상

추가되는 토큰은 폐기될 것이다 . 최대 평균 비율은

다음과 같다 .

Example 8.12

최대 평균 비율 = (1,000t + 10,000)/t

8.223


자원 예약

데이터 흐름은 버퍼 , 대역폭 , CPU 시간 등과 같은

자원을 필요로 함

서비스 품질은 만약 자원들이 미리 예약된다면 향상 됨

통합 서비스 모델은 서비스 품질을 향상 시키기 위해

자원예약을 많이 사용


수락 제어 라우터 또는 교환기가 흐름사양으로 부르는 사전에 정의된

파라미터에 근거하여 한 흐름의 수락 또는 거부를 결정하는

방식을 의미

라우터가 처리를 위해 한 흐름을 수락하기 전에 라우터는

흐름 사양을 조사하여 자체의 용량과 다른 흐름들에게

이전에 허용한 용량이 새로운 흐름의 처리에 가능한가를

알아봄

ATM 네트워크에서 수락제어는 연결 수락 제어라고 알려져

있으며 , 이는 혼잡을 제어하기 위한 전략의 주요 부분


8.5.4 통합 서비스 (IntServ, Integrated Ser-vices) 기존의 인터넷은 필요한 대역과 상관없이 모든 사용자에게 최선 노력 전송 (best-effort delivery) 서비스만을 제공

그러나 일부 어플리케이션들은 작동하기 위해서 최소한의 대역폭만이 필요

다른 어플리케이션들에 서로 다른 QoS 를 제공하기 위해 , IETF 는 통합 서비스 모델 (IntServ) 을 개발하였음

이 모델은 데이터 흐름을 위해 대역폭과 같은 자원을 명시적으로 예약하는 흐름기반의 구조를 가진다

8.226

통합 서비스는 IP 를 위해 만들어진 흐름기반 QoS모델이다 . 이 모델의 패킷은 흐름 특성에 따라 라우터에

의해 표시된다 .


8.5.4 통합 서비스 ( 계속 )흐름 사양 수락 (Admission)

보장서비스 등급 부하 제어 서비스 등급

서비스 등급

RSVP (Resource Reservation Protocol)

멀티캐스트 트리 (Multicast Trees) 수신기 기반 예약 (Receiver-Based Reservation) RSVP 메시지

8.227


8.5.4 통합 서비스 ( 계속 ) 통합 서비스의 문제

확장성 (Scalability) 서비스 종류 제한 (Service-Type Limitation)

8.228


흐름 사양 발신지는 흐름 사양을 정의해야 하며 , 두 부분으로 구성

1. Rspec(resource specification): 흐름에서 버퍼 , 대역폭 등과

같은 자원으로 정의

2. Tspec(traffic specification): 흐름의 트래픽 특성으로 정의

라우터는 흐름 사양을 응용으로부터 받은 다음에 서비스를 수락

또는 거부할 것인가를 결정 이 결정은 라우터의 이전 허용 용량과 자원의 현재 가용도에 근거

229

수락


서비스 등급 보장 서비스 등급

보장된 최소 종단 - 대 -종단 지연을 요구하는 실시간 트래픽을 위해 정의된 것종단 - 대 -종단 지연은 라우터들에서의 지연의 합 , 매체의

전파지연과 설정 구조에서의 지연의 합이다 라우터들에서의 지연의 합인 첫 번째 항목만이 라우터에 의해 보장될 수 있음 패킷이 어떤 전달 시간 내에 도착할 것인가와 만약 흐름 트래픽이

Tspec 의 경계 내에 머무르면 폐기되지 않다는 것을 보장양적인 서비스로서 종단 - 대 -종단 지연의 양과 데이터율은 반드시

응용에서 정의되어야 함 부하 제어 서비스 등급

약간의 지연을 수용할 수 있으나 네트워크가 과부하가 되어 패킷 손실의 위험이 있는 것에 민감한 응용을 위해 만들어짐

응용이 저손실 또는 무손실 패킷 전송의 가능성을 요청하는 질적인 서비스 종류 임

230


RSVP (Resource Reservation Proto-col) 멀티캐스트 트리

멀티캐스팅을 위해 만들어진 신호방식 시스템이라는 점에서 지금까지 보아왔던 일부 다른 신호방식 시스템과 다름

RSVP 는 유니캐스팅에도 사용될 수 있는데 그 이유는 유니캐스팅은 멀티캐스트 그룹에 단 하나의 소속원을 가진 멀티캐스팅의 특별한 경우이기 때문

이렇게 설계한 이유는 자주 멀티캐스팅을 사용하는 멀티미디어를 포함하는 모든 종류의 트래픽을 위해 RSVP 가 자원 예약을 제공할 수 있도록 하기 때문이다

수신기 기반 예약 RSVP 에서는 송신기가 아닌 수신기가 예약은 한다 이 전략은 다른 멀티캐스팅 프로토콜들과 맞아떨어진다

231


RSVP ( 계속 ) RSVP 메시지

Path 메시지는 송신기로부터 출발하여 멀티캐스트 경로의 모든 수신기에게 도달 가는 도중에 Path 메시지는 수신기를 위해 필요한 정보를 저장 Path 메시지 하나가 하나의 멀티캐스트 환경에서 송신되며

경로가 갈라지면 새로운 메시지가 만들어진다

232

Figure 8.65 : Path 메시지


RSVP ( 계속 ) Resv 메시지

수신기는 Path 메시지를 받은 다음 Resv 메시지를 하나 보낸다 Resv 메시지는 송신기 방향으로 ( 상류 방향 ) 이동하며 RSVP 를

지원하는 라우터에게서 자원을 예약 함 만약 경로상의 라우터가 RSVP 를 지원하지 않으면 전에 설명한 최선노력 전달 방법 기반으로 패킷을 전달 함

233

Figure 8.66 : Resv 메시지


RSVP ( 계속 ) 예약 합병

RSVP 에서는 자원이 흐름의 각 수신기를 위해 예약되지 않고 예약이 모두 합쳐짐

234

Figure 8.67 : 예약 합병


RSVP ( 계속 ) 예약 유형

와일드 카드 필터 유형고정필터 유형공유 명시적 유형

소프트 상태한 흐름을 위해 모든 노드에 저장된 예약 정보는

주기적으로 새롭게 바꿔야 함 이것을 소프트 상태라고 한다

자동선택 간격은 현재 30 초 이다

235


8.5.5 차별 서비스 (DiffServ) 차별서비스 (DiffServ, Differentiated Services)모델에서

패킷들은 우선순위에 따라 등급에 위치한 응용에 의해 표시

다양한 큐잉 전략을 사용하는 라우터나 스위치는 패킷의

경로를 지정

이 모델은 통합 서비스의 단덤을 보완하기 위해 IETF 에 의해

도입되었음

DS 필드홉 단위 동작 (Per-Hop Behavior) 트래픽 조정기 (Traffic Conditioner)

8.236


8.5.5 차별 서비스 ( 계속 ) 주요처리가 네트워크의 핵심 부분에서 가장자리로 이동

확장성 문제를 해결 라우터는 흐름에 대한 정보를 저장할 필요가 없음 응용 또는 호스트가 패킷을 전송할 때마다 필요로 하는 서비스 종류를

정의 흐름단위 서비스는 클래스 단위 서비스로 변화 되었음

라우터는 흐름이 아니고 패킷에 정의된 서비스 등급에 근거하여 패킷을 이동시킴 서비스 종류 제한 문제를 해결 다른 종류의 서비스를 응용의 필요에 따라 정의할 수 있음

237

차별서비스는 IP 를 위해 만들어진 등급기반 QoS 모델이다 . 이 모델에서 패킷들은 우선순위에 따라

응용에 의해 표시된다 .


DS 필드

Diffserv 에서는 각 패킷에 DS 필드를 포함하고 있음

이 필드의 값은 네트워크의 경계에서 호스트나

경계라우터로 지정된 첫 라우터에 의해 정해 짐

238

Figure 8.68 : DS field


홉단위 동작

DE PHB: ToS 와 호환성이 있어서 최선노력 전달과 같음

EF PHB: a. 저손실

b. 저대기시간

c. 보장된 대역폭

AF PHB: 등급 트래픽이 노드의 트래픽 프로파일을

초과하지 않는 한 높은 보장률로 패킷을 전달

239


트래픽 조정기 (Traffic conditioner)

240

Figure 8.69 : 트래픽 조정기


트래픽 조정기 ( 계속 ) 계량기

입력되는 흐름이 협상된 트래픽 프로파일과 맞는가를 조사함 이 결과를 다른 구성요소들에게 송신

표시기최선노력 전달을 사용하는 패킷을 다시 표시할 수 있으며 ,

계량기에서 받은 정보를 근거하여 다운마크를 할 수 있음흐름의 등급을 낮추는 다운마크는 만약 흐름이 프로파일과 일치하지

않게 되면 발생 조정기

트래픽이 협상된 프로파일과 맞지 않을 경우 재조정하기 위해 계량기에서 받은 정보를 사용

폐기기 버퍼가 없는 조정기로 사용되는 폐기기는 만약 흐름이 협상된

프로파일을 심하게 위반하면 패킷들을 폐기 함

241


Chapter 8: Summary

두 가지 넓은 범위 , 무손실과 손실압축으로 압축의 형태를 나눌 수 있다 . 무손실 압축에서의 압축 및 압축해제 알고리즘은 서로 정확히 교환되기 때문에 데이터 무결성이 보존된다 . 데이터의 어떠한 부분도 그 과정에서 손실되지 않는다 . 손실압축은 데이터의 정확성을 보존하지 못하지만 우리는 압축된 데이터의 크기 절감 효과를 얻을 수 있다 .

AV(Audio/video) 파일은 인터넷 ( 스트리밍 생방송 AV) 으로 클라이언트에 방송하거나 나중에 사용 ( 스트리밍 저장형 AV) 하기 위해 저장될 수 있다 . 인터넷은 대화형 실시간 AV로 사용될 수 있다 . AV 는 인터넷을 통해 전송되기 전에 디지털화되어야 한다 . 스트리밍 AV 파일 다운을 위해 웹 서 버 혹 은 메 타 파 일 혹 은 매체 서 버 , 또 는 RTSP 를 사용한다 .

8.242


Chapter 8: Summary (continued)

패킷 교환 네트워크에서 실시간 데이터는 세션의 패킷들 간에 시간 관계의 보장을 요구한다 . 수신자 측에서 연속적인 패킷 간의 틈새는 지터를 생기게 한다 .

IP 상 의 음 성 (Voice over IP) 는 실 시 간 대 화 형 AV 어플리케이션이다 . 세션 초기 프로토콜 (SIP) 은 멀티미디어 세션의 설정 , 관리 , 종료하는 응용 계층 프로토콜이다 . H.323 은 인터넷에 연결된 컴퓨터와 통신하기 위해 공중망에 연결된 전화를 수용하는 ITU 표준이다 .

8.243

HANNAM UNIVERSITYHttp://netwk.hnu.kr 8.244

실 시 간 멀 티 미 디 어 트래픽은 UDP 와 실 시 간 전 송 프로토콜 (RTP) 이 모두 필요하다 . RTP 는 타임스태핑 , 순서화와 혼합을 다룬다 . 실시간 전송 제어 프로토콜(RTCP) 는 흐름 제어 , 데이터 제어의 특성 , 피드백을 제공한다 .

스케쥴링 , 트래픽 조정 , 자원 예약과 수락 제어는 서비스 품질 (QoS) 를 향상시키기 위한 기술이다 . FIFO 큐잉 , 우선 순위 큐잉과 가중공정 큐잉은 스케줄링 기술이다 . 리키 버켓과 토큰 베켓은 트래픽 조정 기술이다 . 통합 서비스는 IP 를 위해 만들어진 흐름기반 QoS 모델이다 . 자원 예약 프로토콜 (RSVP) 은 IP 가 흐름을 만들고 자원 예약을 하는 데 도움을 주는 신호방식 프로토콜이다 . 차별서비스는 IP를 위해 만들어진 클래스 기반 QoS 모델이다 .

Chapter 8: Summary (continued)

powerpoint presentationnetwk.hannam.ac.kr/data/com_network_20… · ppt file · web view ·...

Documents