ANKARA ÜN ĐVERSĐTESĐ

FEN BĐLĐMLER Đ ENSTĐTÜSÜ

YÜKSEK L ĐSANS TEZĐ

ADAPTĐF VERĐ HIZLARINDA ÇALI ŞAN VoIP UYGULAMALARINDA KULLANILMAK ÜZERE TIKANIKLIK B ĐLDĐRĐMĐ

CEM DENĐZ PELĐT

ELEKTRON ĐK MÜHEND ĐSLĐĞĐ ANABĐLĐM DALI

ANKARA

2005

Her hakkı saklıdır.

Yrd. Doç. Dr. H. Gökhan ĐLK danışmanlığında, Cem Deniz PELĐT tarafından

hazırlanan bu çalışma 03/06/2005 tarihinde aşağıdaki jüri tarafından. Elektronik

Mühendisliği Anabilim Dalı’nda yüksek lisans tezi olarak kabul edilmiştir.

Başkan : Prof. Dr. Mümtaz YILMAZ

Üye : Doç. Dr. Bilal GÜNEŞ

Üye : Yard. Doç. Dr. H. Gökhan ĐLK

Yukarıdaki sonucu onaylarım

Prof. Dr. Ülkü MEHMETOĞLU

Enstitü Müdürü

i

ÖZET

Yüksek Lisans Tezi

ADAPTĐF VERĐ HIZLARINDA ÇALI ŞAN VoIP UYGULAMALARINDA KULLANILMAK ÜZERE TIKANIKLIK B ĐLDĐRĐMĐ

Cem Deniz PELĐT

Ankara Üniversitesi Fen Bilimleri Enstitüsü

Elektronik Mühendisli ği Anabilim Dalı

Danışman: Yrd. Doç. Dr. H. Gökhan ĐLK

Günümüzde internet kullanımı hayatımızın bir parçası haline gelmiştir. Đnternet

kullanımı kapsamında sesin iletimi üzerine yapılmakta olan çalışmalar telefon

görüşmelerinde tasarruf, düşük destek maliyeti, esneklik ve daha yüksek seviyelerde

ölçeklenebilirlik sağlayacaktır. Ayrıca böyle bir yapı içinde sesin kalitesinin arttırılması

daha kolay olacaktır.

Bu çalışmada ilk olarak sesin internet üzerinden iletimi sırasında karşılaşılacak

tıkanıklığın tespit edilmesi alanındaki mevcut yayınlar taranmış ve değerlendirilmiştir.

Daha sonra adaptif hızlarında çalışmakta olan bir ses kodlayıcısına ağda oluşan

tıkanıklık durumunu bildirebilecek bir mekanizma incelenmiştir.

SNMP (Basit Ağ Yönetim Protokolü – Simple Network Management Protocol) ile

Ankara Üniversitesi ağında bulunan Ankara Üniversitesi Geliştirme Vakfı Okullarının

hat kullanım oranları anlık olarak alınmış ve adaptif veri hızlarında çalışmakta olan bir

VoIP uygulamasına tıkanıklık bildirme parametreleri olarak verilmiştir. Araştırma

sonuçları önerilen sistemin uygulama sırasında başarılı sonuçlar verebileceğini

göstermiştir.

2005, 71 Sayfa

ANAHTAR KEL ĐMELER: VoIP, Tıkanıklık bildirimi, SNMP, QoS

ii

ABSTRACT

Master Thesis

CONGESTION NOTIFICATION IN ADAPTIVE BIT RATE VoIP APPLICATIONS

Cem Deniz PELĐT

Ankara University Graduate School of Natural and Applied Sciences

Department of Electronics Engineering

Supervisor: Asst. Prof. Dr. H. Gökhan ĐLK

Internet, which becomes an integral part of our lives, enables a model which provides

low support costs, flexibility and more scalability to voice transmission that human kind

has been working on for centuries. In addition it is easier to enhance the quality of voice

in this model.

In this thesis, articles on detection of the problems that is encountered during the

transmission of voice over the Internet were investigated initially. Then a mechanism

that informs the congestion that occurs in the network to the voice codec, which is

working on adaptive speeds, is developed.

With SNMP (Simple Network Management System), instant usage ratios of Ankara

University Foundation Schools that is present in the Ankara University network are

gathered and considered in the VoIP application, which works on adaptive data speeds,

as congestion notification parameters. The subjective listening test results revealed that

the proposed scheme could be successfully applied in a VoIP environment.

2005, 71 Pages

Key Words: VoIP, Congestion Notification, SNMP, QoS

iii

TEŞEKKÜR

Tez konumun belirlenmesinin ilk gününden bu yana çalışmalarımın her safhasında

yakın ilgi ve önerileri ile beni yönlendiren, iş hayatımdaki yoğunluk sebebiyle

çalışmalarımda oluşan aksamalarda büyük sabır gösteren, tez danışmanım Sayın Yrd.

Doç. Dr. Hakkı Gökhan ĐLK’e teşekkürlerimi sunarım.

Tez çalışmalarım sırasında iş hayatımdaki aksaklıklara göstermiş olduğu sabırdan

dolayı Bilgi Đşlem Daire Başkanımız Sayın Rıza AYHAN’a, aksamalar da benden

destek ve yardımlarını esirgemeyen mesai arkadaşlarım Çağdaş Funda, Erdem Ağaoğlu,

Fatih Erikçi ve Serdar Cihaner’e teşekkür ederim.

Kod yazımı sırasında fikir ve önerileri ile desteklerini her zaman hissettiğim Aldemir

Akpınar ve Adaptif WSOLA kodunu benimle paylaşan Saadettin Güler’e teşekkür

ederim.

Son olarak sevgili eşim Đlke Pelit başta olmak üzere tüm aileme bana sağladıkları moral

ve destek için teşekkür ederim.

Cem Deniz PELĐT

ANKARA, Haziran 2005

iv

ĐÇĐNDEKĐLER

ÖZET................................................................................................................................Đ

ABSTRACT....................................................................................................................ĐĐ

TEŞEKKÜR .................................................................................................................ĐĐĐ

SĐMGELER VE KISALTMALAR D ĐZĐNĐ ...............................................................VĐ

ŞEKĐLLER D ĐZĐNĐ ....................................................................................................... X

ÇĐZELGELER D ĐZĐNĐ ..............................................................................................XĐĐ

1. GĐRĐŞ............................................................................................................................ 1

2. KURAMSAL TEMELLER........................................................................................ 2

2.1 VOIP ........................................................................................................................... 2

2.1.1 VoIP nedir? .............................................................................................................. 2

2.1.2 VoIP’nin kullanım alanları ...................................................................................... 2

2.1.3 Ses sinyallerinin iletimi............................................................................................ 5

2.1.4 RTP .......................................................................................................................... 8

2.1.5 RTCP...................................................................................................................... 12

2.1.6 Paket boyutu........................................................................................................... 14

2.1.7 QoS mekanizmaları................................................................................................ 15

2.1.8 H.323...................................................................................................................... 22

2.1.9 SIP.......................................................................................................................... 26

2.2 Tıkanıklık.................................................................................................................. 29

2.2.1 Tıkanıklık nedir?.................................................................................................... 29

2.2.2 Tıkanıklık giderme................................................................................................. 31

2.2.3 Paket anahtarlamalı ağlarda tıkanıklık................................................................... 31

2.3 QOS........................................................................................................................... 33

2.3.1 QoS kavramları ...................................................................................................... 34

2.3.2 Temel QoS mimarisi .............................................................................................. 35

2.3.3 Servis kalitesinin tipleri ......................................................................................... 37

2.4 SNMP ....................................................................................................................... 41

2.4.1 SNMP ana komutları.............................................................................................. 42

2.4.2 SNMP sürümleri .................................................................................................... 42

v

2.4.3 SNMP uyumluluk yöntemleri ................................................................................ 44

2.4.4 SNMP’nin avantaj ve dezavantajları...................................................................... 45

2.4.5 SNMP standardı ..................................................................................................... 45

2.4.6 MIB ........................................................................................................................ 47

3. MATERYAL VE YÖNTEM....................................................................................52

3.1 Materyal.................................................................................................................... 52

3.2 Yöntem ..................................................................................................................... 54

3.2.1 SNMP ile hat kullanımının gözlenmesi ................................................................. 54

3.2.2 SNMP ile hat kullanımı hesabı .............................................................................. 54

3.2.3 SNMP ile kullanılan hat kapasitesini hesaplayan program.................................... 56

3.2.4 Adaptif WSOLA .................................................................................................... 56

3.2.5 G.729...................................................................................................................... 56

3.2.6 Sesin kalitesini değerlendirme ............................................................................... 58

3.2.7 Anlamlılık testi....................................................................................................... 59

4. ARAŞTIRMA BULGULARI VE TARTI ŞMA...................................................... 61

5. SONUÇ....................................................................................................................... 67

KAYNAKLAR .............................................................................................................. 68

ÖZGEÇM ĐŞ................................................................................................................... 71

vi

SĐMGELER VE KISALTMALAR D ĐZĐNĐ

ASCII Bilgi Değiş Tokuşu için Amerika Standart Kodu (American Standard Code for Information Interchange)

ASN.1 Özet Sözdizimi Gösterimi Bir (Abstract Syntax Notation One)

ATM Eşzamansız Aktarım Durumu (Asyncronous Transfer Mode)

CC CSRC Sayısı (CSRC Count)

CLNS Bağlantısız Ağ Servisi (Connectionless Network Service)

CNAME Takma Ad (Canonical Name)

CoS Servis Sınıfı (Class of Service)

CQ Sabit Kalite (Constant Quality)

CSRC Katılımcı Kaynağı Tanımlayıcısı (Conributing Source Identifier)

DBCES Dinamik Bantgenişliği Devre Emülasyon Hizmeti (Dynamic Bandwidth Circuit Emulation Service)

DDP Datagram Gönderim Protokolü (Datagram Delivery Protocol)

DES Veri Şifreleme Standardı (Data Encryption Standard)

DiffServ Ayrılmış Servisler (DIFFerentiated SERVices)

DSCP Ayrılmış Servisler Kod Noktası (Differentiated Services Code Point)

DSL Sayısal Kullanıcı Hattı (Digital Subscriber Line)

DSP Sayısal Sinyal Đşleme (Digital Signal Processing)

E.164 Kuzey Amerika Numaralandırma Plan Adreslemesi (North American Numbering Plan Addressing)

EGP Ağ Geçidi Dışı Protokolü (Exterior Gateway Protocol)

FIFO Đlk Gelen Đlk Çıkar (First In First Out)

FlowSpec Akış Özellikleri (Flow Specification)

FTP Dosya Transfer Protokolü (File Transfer Protokol)

HTTP Hiper Yazı Taşıma Protokolü (Hyper Text Transport Protocol)

vii

IETF Internet Mühendisliği Görev Kuvvetleri (The Internet Engineering Task Force)

IP Internet Protokolü (Internet Protocol)

IPv4 Internet Protokolü sürüm 4 (Internet Protocol version 4)

IPv6 Internet Protokolü sürüm 6 (Internet Protocol version 6)

IPX Ağlararası Paket Değişimi (Internetwork Packet Exchange)

ITU Uluslar arası Đletişim Birliği (International Telecommunication Union)

Kbps Saniye Başına Kilo bit (Kilo bit per second)

LAN Yerel Alan Ağı (Local Area Network)

MC Çoklu nokta Kontrolcüsü (Multipoint Controller)

MCU Çoklu nokta Kontrol Birimi (Multipoint Control Unit)

MD5 Mesaj Derlemesi 5 (Message Digest 5)

MGCP Çoklu ortam Ağ geçidi Kontrol Protokolü (Multimedia Gateway Control Protocol)

MIB Yönetim Bilgisi Tabanı (Management Information Base)

MOS Ortalama Fikir Skoru ( Mean Opinion Score)

MP Çok noktalı Đşlemci (Multipoint Processor)

NMS Ağ Yönetim Sistemleri (Network Management Systems)

OID Nesne Tanımlayıcı (Object Identifier)

PC Kişisel Bilgisayar (Personel Computer)

PDU Protokol Veri Birimi (Protocol Data Unit)

PHB Her atlamadaki davranış (Per Hop Behaviour)

PQ Öncelik Sıralaması (Priority Queuing)

PSTN Ortam Anahtarlamalı Telefon Ağı (Public Switched Telephony Network)

QoS Servis Kalitesi (Quality of Service)

RFC Yorumlar için Đstek (Request For Comments)

viii

RSVP Kaynak Rezervasyonu Protokolü (Resource Reservation Protocol)

RTCP Gerçek Zamanlı Taşıma Kontrol Protokolü (Real-time Transport Control Protocol)

RTP Gerçek Zamanlı Taşıma Protokolü (Real-time Transport Protocol)

SCMP Akış Protokolü Kontrol Mesajı Protokolü (Stream Protocol Control Message Protocol)

SHA Güvenli Hash Algoritması (Secure Hash Algorithm)

SIP Oturum Başlatma Protokolü (Session Initiation Protocol)

SMTP Basit Posta Taşıma Protokolü (Simple Mail Transfer Protocol)

SNMP Basit Ağ Yönetim Protokolü (Simple Network Management Protokol)

SONET Eşzamanlı Optik Ağ (Synchronous Optical NETwork)

SPSS Sosyal Bilimler için Đstatistikî Paketler (Statistical Package for the Social Sciences)

SSRC Eşzamanlama Kaynak Tanımlayıcı (Synchronisation Source Identifier)

ST2 Akış Protokolü Sürüm 2 (Stream Protocol version 2)

TCP Đletim Kontrol Protokolü (Transmission Control Protocol)

TCP/IP Đletim Kontrol Protokolü / Internet Protokolü (Transmission Control Protocol/ Internet Protocol)

ToS Servis Tipi (Type of Service)

UDP Kullanıcı Datagram Protokolü (User Datagram Protocol)

URL Tek biçimli Kaynak Konumlayıcı (Uniform Resource Locator)

VoIP Internet Protokolü Üzerinden Ses (Voice over Internet Protocol)

VBR Değişken Hızlı (Variable Bit Rate)

WAN Geniş Alan Ağı (Wide Area Network)

WFQ Ağırlıklı Adil Sıralama (Weighted Fair Queuing)

WRED Ağırlıklı Rasgele Erken Algılama (Weighted Random Early Detection)

ix

WSOLA Dalga Şekli Benzerlikli Örtüşmeli Ekleme (Waveform Similarity Overlap Add)

x

ŞEKĐLLER D ĐZĐNĐ

Şekil 2.1 Bilgisayar yerel ağ bağlantısı............................................................................. 3

Şekil 2.2 Telefon-bilgisayar-yerel ağ bağlantısı ............................................................... 3

Şekil 2.3 Telefon-ağ geçidi bağlantısı............................................................................... 4

Şekil 2.4 RTP başlık bilgisi............................................................................................... 9

Şekil 2.5 RTCP alıcı raporu başlık.................................................................................. 13

Şekil 2.6 RTCP gönderici raporu.................................................................................... 14

Şekil 2.7 Rezervasyon örneği.......................................................................................... 19

Şekil 2.8 Örnek H.323 sistemi ........................................................................................ 25

Şekil 2.9 H.323 mimarisi ................................................................................................ 25

Şekil 2.10 Tıkanıklık kontrol düzeyi............................................................................... 30

Şekil 2.11 Tıkanıklık kontrol algoritmaları..................................................................... 33

Şekil 2.12 Basit QoS uygulaması.................................................................................... 35

Şekil 2.13 Sondan sona QoS servisleri ........................................................................... 36

Şekil 2.14 IP başlığı ........................................................................................................ 38

Şekil 2.15 IP başlığındaki ToS alanı ayrıntısı................................................................. 38

Şekil 2.16 DSCP ve ToS alan karşılaştırması ................................................................. 39

Şekil 2.17 SNMP işleyişi ................................................................................................ 41

Şekil 2.18 MIB ağaç yapısı .............................................................................................48

Şekil 3.1 Ankara Üniversitesi Geliştirme Vakfı Okulları hat kullanımı......................... 54

Şekil 3.2 G.729 için kodlayıcı devresi ............................................................................ 57

Şekil 3.3 G.729 sentez devresi ........................................................................................ 58

Şekil 4.1 Anlık ağ trafiği ................................................................................................. 61

Şekil 4.2 Tek yönlü trafik için örnek Adaptif WSOLA uygulaması............................... 61

Şekil 4.3 Kullanılan ses dalga şekli................................................................................. 62

xi

Şekil 4.4 Sistemden elde edilen ses dalga şekli .............................................................. 62

Şekil 4.5 Adaptif WSOLA-G.729 kodek sistemi............................................................63

Şekil 4.6 Adaptif WSOLA-G.729 kodek sisteminin ses dalga şekli............................... 63

xii

ÇĐZELGELER D ĐZĐNĐ

Çizelge 2.1 H.323 tavsiyeleri .......................................................................................... 23

Çizelge 2.2 Servis tipi alan bilgileri ................................................................................ 38

Çizelge 2.3 IP öncelik değerleri ...................................................................................... 39

Çizelge 2.4 Ayrık servis kod noktası değerleri ............................................................... 40

Çizelge 2.5 SNMP sürümleri karşılaştırması .................................................................. 44

Çizelge 2.6 Örnek bazı MIB nesne değerleri .................................................................. 50

Çizelge 4.1 Ortalama MOS puanları............................................................................... 64

Çizelge 4.2 Orijinal ses ile Adaptif WSOLA uygulanmış seslere ait t testi ................... 64

Çizelge 4.3 Orijinal ses ile Adaptif WSOLA+G.729 düzeneğinden elde edilen

seslere ait t testi .......................................................................................... 65

Çizelge 4.4 Adaptif WSOLA uygulanmış ses ile Adaptif WSOLA+G.729

düzeneğinden elde edilen seslere ait t testi................................................. 66

1

1. GĐRĐŞ

Ağ, iletişim kabiliyetlerine sahip bilgisayar, yazıcı, telefon veya santral gibi sistemlerin

birbirleri ile belirli bir protokol altında iletişimde bulunabilmesini sağlayan bir sistemdir

(Çölkesen 2000). Đnternet dünya üzerindeki en büyük veri ağı olmakla birlikte, insanlar

arasındaki iletişimde ses her zaman en önemli konuma sahip olmuştur. Böylesine büyük

bir ağı ses iletişiminde kullanmak fikri ise çok yeni sayılabilir. Đnternette oluşan hızlı

gelişme ve sesin sayısallaştırılmasında atılan ciddi adımlar sesin Đnternet üzerinden

aktarılmasını kolaylaştırmış ve hızlandırmıştır.

Günümüzde yaşanan ses-veri bütünleşmesi eğilimi bundan yaklaşık otuz sene önce

düşünülmeyen bir konu idi. Veri sadece ses iletimi için tasarımlanmış PSTN (Kamu

Anahtarlamalı Telefon Ağı - Public Switched Telephony Network) üzerindeki 300bps

hızında çalışan modemlerle iletiliyordu. Zaman içinde, PSTN’nin veri için verimli

olmadığı anlaşılmış ve değişik teknolojiler geliştirilmi ştir.

Đnternet üzerinde oluşabilecek tıkanıklık gibi en temel sorunlar, gerçek zamanlı olan ses

haberleşmelerinde kabul edilemez boyutlara ulaşabilir. Bu konu üzerinde günümüzde

çok ciddi araştırmalar yapılmaktadır. Düşük hat kapasitesine sahip kurum ya da

kuruluşlarda, VoIP (IP üzerinden Ses Đletimi-Voice over Internet Protocol) sayesinde

ekonomik anlamda çok ciddi katkılar sağlanabilmektedir.

Bu tezde adaptif bir ses kodlayıcısına ağ üzerinde oluşabilecek tıkanıklık durumlarını

bildirmesi için SNMP (Basit Ağ Yönetim Protokolü – Simple Network Management

Protokol) ile çalışan bir kod geliştirilmi ştir. Geliştirilen bu kod sayesinde anlık olarak

yönlendirici ara yüzlerindeki hat kullanım bilgileri alınmış ve değerlendirmesi

yapıldıktan sonra adaptif ses kodlayıcısını uyarlamak için bir parametre olarak

gönderilmiştir.

2

2. KURAMSAL TEMELLER

2.1 VoIP

2.1.1 VoIP nedir?

VoIP (Internet Protokolü Üzerinden Ses – Voice over Internet Protocol) konuşma

sinyallerinin IP ağı üzerinden, gönderenden hedefe, kabul edilebilir bir kalitede

taşınması olarak tanımlanabilir (Black 2000). IP (Internet Protokolü-Internet Protocol)

ağı, bilgiyi iletmek için IP protokolünü kullanan bilgisayar ağıdır.

'Kabul edilebilir’ifadesinin tanımı üzerinde çalışılan duruma bağlıdır. Konuşma

sinyalleri, iki kişi arasında gerçek zamanlı iletişimin bir parçası şeklinde taşınıyorsa,

gerçek zamanlı iletişimin uzun sessizlik boşluklarından kaçınma durumu göz önünde

bulundurulmalıdır. Uzun sessizlik boşluklarından kaçınmak için, gönderme ve alma

arasındaki toplam gecikme süresi kısa olmalıdır. Bir diğer durum ise konuşma

sinyallerinin tek yönlü bir işlemin parçaları şeklinde taşınması olabilir. Bu duruma

örnek olarak canlı radyo yayını verilebilir ve interaktif bir durum söz konusu olmadığı

için gecikme sınırlamaları daha esnek düşünülebilir.

VoIP sistemlerinde kişilerin iletişim kurabildiği ve bir uçtan diğer uca iletim sırasındaki

toplam gecikmenin olabildiğince az olduğu sanal bir yapı bulunmalıdır.

2.1.2 VoIP’nin kullanım alanları

VoIP literatürü incelendiğinde, çalışmaların büyük bir kısmının VoIP’i telefona

alternatif olarak inceledikleri görülmektedir. Yeni yapılan bazı çalışmalar da VoIP’in

sanal ortamdaki kullanımı üzerinde de durulmaktadır.

2.1.2.1 Telefona alternatif

VoIP’in en yaygın kullanım şekli telefona alternatiftir. Bu kullanım birçok şekilde

olabilir.

Öncelikle, Ağa bağlı bir PC (Kişisel Bilgisayar – Personel Computer), o ağa bağlı başka

bir PC kullanıcısını aramak için kullanılabilir. VoIP’in kullanımı için ağa bağlı olmanın

3

dışında, PC’ye ait hoparlörler, bir mikrofon ve aramayı yapabilmek için bir yazılımın

sağlanması gerekir. PC Şekil 2.1’de gösterildiği gibi bir bilgisayar ağına doğrudan bağlı

olabileceği gibi bir modem vasıtası ile de bağlı olabilir.

Şekil 2.1 Bilgisayar yerel ağ bağlantısı

Đkinci durum birinci durumun değişime uğramış halidir. Bu durumda, telefon bir PC’ye

bağlıdır ve normal bir aramada kullanılan biçime benzer bir şekilde kullanılır. PC

aramayı hazırlamak ve konuşma sinyallerini iletmek için gerekli tüm işlemleri yapar. Bu

aynı zamanda aramanın yapılmadan önce PC’nin açık olması gerektiği anlamına da

gelir. Bu şekildeki düzenleme, bilgisayarlarla sık sık çalışmayan kişiler için daha kolay

olabilir. Bir önceki durumdaki gibi, ağa bağlantı Şekil 2.2’deki gibi doğrudan ya da bir

modem ile olabilir.

Şekil 2.2 Telefon-bilgisayar-yerel ağ bağlantısı

Son olarak, VoIP ağ geçidi kullanılarak, hem bir PC’nin kullanımı hem de bir ağın

gerekliliği ihmal edilebilir. VoIP ağ geçidi, telefon ağı ile bilgisayar ağını birbirine

bağlayan ve aramanın yapılabilmesi için gerekli olan işlemleri ve konuşmaları yapan

özel bir cihazdır. Karşı tarafı aramak için önce ağ geçidi aranır ve aramanın hedefi

belirlenir. Sonra arama hazırlanacak ve eğer diğer uç uygun durumdaysa konuşma

4

başlayabilecektir. Bu düzenleme bir PC’si olmayan kişiler için en uygun yöntemdir.

Muhtemelen telefon kullanımına alışkın birçok kişi için ve etrafta bir PC’nin bulunması

gerekmediği için kullanımı en kolay olan yöntem Şekil 2.3’te gösterilmiştir.

Şekil 2.3 Telefon-ağ geçidi bağlantısı

Bu düzenlemelerin muhtemelen birçok varyasyonu yapılabilir ama bu üç ana durum

telefona alternatif VoIP sistemlerin genel kullanım şekilleri olarak tanımlanabilir.

Ayrıca bu yöntemler karma şekilde kullanılabilir. Örneğin bir kişi, başka birine ulaşmak

için VoIP ağ geçidini kullanırken, ulaşmaya çalıştığı kişi, telefondan PC’ye olan

düzenlemeyi kullanabilir.

Telefon kullanımının kendisi gayet kullanışlıyken, VoIP’nin bir alternatif olarak neden

kullanılacağı sorusu akıllara gelebilir. Bu konuda VoIP lehine söylenebilecek birçok

kanıt bulunmaktadır.

Bir kurum ya da kuruluşta internet erişimi için bir bilgisayar ağına ihtiyaç olabilir. Bu

durumda ek bir telefon şebekesi kurulumu yerine, VoIP kullanımının kurum ya da

kuruluşa getireceği bir takım faydaları vardır. Tek gereklilik olan IP protokolünün

kullanılmasıdır. Günümüzde IP kullanılmakta olan en yaygın protokol olduğundan, bu

gereklilik kendiliğinden sağlanmaktadır.

Bilgisayarlar ve telefonlar için iki farklı ağ kurmak yerine, ihtiyaçları ortak

karşılayabilecek tek ağda daha az kablolamaya ve donanıma ihtiyaç duyulacaktır. Tüm

iç aramalar VoIP araçları kullanılarak gerçekleştirilebilir. Đçeriden dışarıya doğru ve

dışarıdan içeriye doğru olan aramalar için ise telefon ağına bir bağlantının yapılması

hala gerekmektedir. Bu durum hem telefon hem de bilgisayar ağına bağlı bir ağ geçidi

kurularak çözülebilir. Bu sayede ağ geçidi, gerekli konuşmaları ve de işaretleşmeleri

yaparak bu tip aramaları mümkün kılacaktır.

5

VoIP kullanımı sayesinde bilgisayar ağının kapasitesi daha verimli kullanılacaktır. Bir

organizasyon içindeki ağın kullanılabilir kapasitesi genellikle büyüktür ve nadiren

tamamı kullanılır. VoIP kullanılarak, ağın kapasitesinin daha fazlası kullanılmış

olacaktır.

Ev kullanıcısı için VoIP lehine başka bir avantaj daha bulunmaktadır. Eğer VoIP uzak

mesafelerde kullanılabilirse, aynı tip görüşmeyi telefon ağı üzerinden yapmaktan daha

ucuza mal olacaktır.

VoIP ile normal telefon özelliklerinin mümkün olması dışında, özellikle bir PC

kullanırken, birçok yeni özellik de eklenebilir. Arayan ve aranan numaraların kayıtları

için bir defter tutulabilir. Konuşmalar kolaylıkla kaydedilebilir ve iletişim güvenliğini

artırmak için şifreleme algoritmaları da kullanılabilir.

VoIP’i yerel ağ (LAN) üzerinden kullanırken genellikle büyük miktarda kullanılabilir

hat kapasitesi vardır ve gönderme alma arasındaki gecikme çok düşüktür. Yerel ağda

VoIP sorunsuzca kullanılabilir. Ama geniş alan ağı (WAN) kullanıldığında -örneğin

Internet- tıkanıklık ve gecikme sorunları oluşabilir. LAN üzerindeki gecikme genellikle

çok düşük olsa da WAN’da olan gecikme çok artarsa konuşma bir şekilde

gerçekleşemeyecek veya anlaşılamaz hale gelecektir. Diğer bir sorun ise konuşma

sinyalinin kalitesidir. Belli hatlarda yoğun kullanım olduğunda paketler kaybolabilir. Bu

kayıp paketler konuşma sinyalinde kesilmelere sebep olur. Bu kesilmeler de, yeterince

büyük oldukları zaman, konuşmayı bozabilirler. Hattın yoğun kullanımına VoIP

uygulaması da neden olabilir. Bu yoğunluğu azaltmak için, birçok VoIP uygulaması

sıkıştırma teknikleri kullanırlar. Ancak sıkıştırma, çoğu zaman sinyalin bozulmasına

neden olur. Bu durum dinleyici de rahatsızlığa neden olabilir ama sıkıştırma oranının az

olması durumunda telefon kalitesine ulaşılabilinir.

2.1.3 Ses sinyallerinin iletimi

IP, QoS (Servis Kalitesi – Quality of Service) garantisi olmayan sadece en iyi çaba

(best-effort) bir hizmet ortaya koyar. Telefon kalitesinde ses iletişimi için gecikmenin

ve paket kayıplarının az olması gerekir. Gecikme ve paket kayıplarının çok olması

iletişimin kalitesini olumsuz etkileyeceğinden garantilere ihtiyaç vardır.

6

Ses sinyallerinin iletimi için genel ihtiyaçlar, kullanılacak protokoller ve gecikmenin

etkileri tespit edilmelidir.

2.1.3.1 Đhtiyaçlar

Ses verisi içeren paketleri iletirken, konuşma sinyali içindeki senkronizasyonu koruyan

bir mekanizma olmalıdır. Birbirini takip eden paketler doğru zamanda doğru sırayla

karşı tarafa iletilmelidir. Bu şekildeki senkronizasyona ortam içi (intra-media)

senkronizasyon denir.

Gerçek zamanlı ses iletişiminde toplam gecikme mümkün olduğunca az tutulmalıdır.

Bir IP ağı sadece en iyi çaba hizmet verdiği için gecikmenin ihtiyaçları sağlayacağının

hiçbir garantisi yoktur. Benzer bir şekilde, kayıp paket miktarı, örneğin tıkanıklık

zamanlarında, yüksek olabilir. Telefon kalitesinde konuşma yapabilmek için, gecikme

ve paket kayıpları hakkında garantiler içeren bir QoS mekanizması olması gerekebilir.

Gönderilmesi gereken konuşma verisi, tipik olarak düzenli küçük zaman aralıklarında

yaratılır. Veriyi alan uç bu veri akışını düzgün biçimde alamayabilir. Gönderici bir

şekilde alıcının, gelen akışı tutup tutamayacağını bilmelidir. Alıcının veri akışını alıp

alamayacağını belirleyen yöntemlere akış kontrolü yöntemi (flow control method) denir.

Aynı zamanda, verinin düzenli bir şekilde gönderildiği gerçeğinden hareketle,

bağlantının aşırı yüklenmesi ve tıkanıklık oluşması muhtemeldir. Tıkanıklık, ses

iletişiminde istenmeyen niteliklerden olan, paket kaybı ve gecikmede artışa sebep olur.

Đletim bileşeni, artan bir tıkanıklığı algılayabilmeli ve tıkanıklık durumunu ortadan

kaldırmaya yönelik işlemleri yapmalıdır. Tıkanıklığı engelleyen ve kontrol eden

mekanizmalara tıkanıklık kontrolü (congestion control) adı verilir.

Akış ve tıkanıklık kontrolü için yapılması gereken, gönderilen veri miktarını

azaltmaktır. Tipik olarak bu işlemi sıkıştırma modülü tarafından gerçekleştirilebilir, veri

oranının azaltılması gerektiği zaman, sıkıştırma modülü sıkıştırma miktarını artırması

için uyarılır. Bu genellikle konuşma kalitesinin azalmasıyla sonuçlanır. Böyle bir kalite

azalması, kayıp paketler ve uzun gecikmelere göre tercih edilebilir (Black 2000).

7

2.1.3.2 Đletim protokolleri

Bir uygulamanın veri iletebilmesi için protokolleri kullanması gereklidir. TCP/IP

mimarisinde, bir uygulamanın kullanabileceği protokoller TCP (Đletim Kontrol

Protokolü-Transmission Control Protocol) veya UDP (Kullanıcı Datagram Protokolü-

User Datagram Protocol)’dir.

Telefon benzeri bir hizmet veren VoIP uygulamaları için TCP, konuşma verisinin

gönderilmesinde iyi bir aday gibi görünebilir. TCP, bağlantının güvenilir veri akışı

içinde olacağı bir hizmet vermektedir. TCP kullanımında ilk önce bağlantı hazırlanır,

veri alış verişi yapılır ve son olarak bağlantı sonlandırılır.

TCP kullanımında senkronizasyonla ilgili herhangi bir problem bulunmamaktadır. Tüm

veri tam olarak gönderildiği sırada alınabilir. Ayrıca TCP kullanımında verinin doğru

bir şekilde iletildiği garantilidir. Protokolün kendi özelliklerinde, ağı aşırı yüklenmeden

koruyacak, akış ve tıkanıklık kontrol mekanizmaları da vardır.

TCP’nin kullanımında karşılaşılabilinecek birkaç dezavantaj vardır. Temel

problemlerden bir tanesi, amacı güvenilir veri akışı sağlamak olan protokol, kaybolan

ya da bozulmuş paketlerin, tekrar iletilmesi esasına dayanmaktadır. Bu özellik veri akışı

sırasının korunduğu güvenilir bir hizmet sunarken, tekrar iletilen paketler için bekleme

süresi, iletişime fazladan gecikme eklemektedir. VoIP uygulamalarında gecikmenin

artması yerine ara sıra olan kayıp ya da bozuk paketler tercih edilen bir durum olabilir.

TCP paketlerin sırasını koruduğu için, bir kayıp ya da bozuk paket olması durumunda

uygulamanın, o paketten sonra gelenleri almasını engelleme durumu olabilir. VoIP

uygulamasında konuşma verisi belirli zaman aralıklarında sürekli gönderilmelidir. Eğer

bir paket yeterli bir zaman miktarı boyunca alıcıya ulaşmaz ise, diğer paketler alınmış

olsalar bile diğer paketlerin çalınmasını engelleyecektir.

TCP’e ait akış ve tıkanıklık kontrol özellikleri çok kullanışlı görünebilir, ama VoIP

uygulaması için bu kontrol yöntemleri kısıtlayıcı bir etken olacaktır. TCP, verinin

gönderildiği oranı uygulamanın isteği dışında kolaylıkla azaltabilir ve bu durum yine

toplam gecikmeyi arttırır.

8

Buradaki anahtar nokta, TCP’nin VoIP için kullanışlı olmayan birçok özelliğe ve

karmaşıklığa sahip olmasıdır.

TCP, konuşma verisinin aynı anda birden çok kişiye gönderilmesi gerektiği zamanlarda

verinin etkili bir şekilde dağıtımını desteklemez. Veri TCP kullanılarak birçok hedefe

gönderilmek istenirse, ayrı ayrı TCP bağlantıları kurulmak zorundadır. Bu durum

bağlantı yapılan noktalar arasında hat kapasitesinin yetmemesine neden olabilir. Hat

kapasitesinin yetmeme durumu tıkanıklık göstergesidir. Verinin etkili bir şekilde

dağıtımı için IP çoğa-gönderim (IP multicasting) kullanılabilinir.

Bu nedenler TCP kullanımından vazgeçilmesi için yeterli sebeplerdir. UDP

kullanılabilecek bir diğer TCP/IP protokolüdür. Bu protokol nerdeyse hiçbir karmaşıklık

içermez. UDP, basit olarak IP’ye sadece en iyi çaba hizmeti ekleyen bir protokoldür.

UDP kullanımında, kayıp paketlerin tekrar gönderilmesi gerekmemektedir. Bu bir

avantaj olarak görülebilir. Aynı zamanda, sadece basit bir IP eklentisi olduğu için IP

çoğa-gönderim (IP multicasting) özelliklerini de kullanabilir. Veri birden çok hedefe

yollanmak istediği zaman hat kapasitesinde tasarruf sağlayabilir. Tüm bunlar her ne

kadar iyi gibi görünse de bazı dezavantajlar da vardır. UDP, senkronizasyon için

nerdeyse hiçbir mekanizma içermez ve akış ya da tıkanıklık kontrolü yapması için hiç

bir mekanizması yoktur.

UDP’de, akış ya da tıkanıklık kontrolü olmamasını ortadan kaldırmak için konuşma

verisine fazladan veri ekleyebiliriz. Bu eklentiler yapılmış protokol, kontrol ve konuşma

bilgisinin dağıtılması için kullanılabilinir. Bu gerçekte Gerçek-zamanlı Taşıma

Protokolünün (Real-time Transport Protocol-RTP) TCP/IP mimarisindeki çalışma

şeklidir.

2.1.4 RTP

RTP (Gerçek-zamanlı Taşıma Protokolü -Real-time Transport Protocol), interaktif ses

ya da görüntü gibi gerçek zamanlı karakteristikleri olan veriler için uçtan uca iletim

hizmetleri sağlayan bir protokoldür (Schulzrinne vd. 1996). Bu durumda VoIP

uygulamaları için kullanılabilecek protokol RTP olabilir.

9

RTP özellikleri gerçekte iki ayrı protokolü tanımlar. Đlki RTP’dir. Đkincisi RTCP

(Gerçek Zamanlı Taşıma Kontrol Protokolü - Real-time Transport Control Protocol)’dir.

RTP’nin fonksiyonu gerçek zamanlı veriyi taşımaktır. RTCP oturum içindeki

katılımcılar hakkında bilgi sağlar. Protokoller sadece TCP/IP değil çok sayıda ağ

mimarisinde kullanılabilecek şekilde tanımlanmışlardır. RTP, TCP/IP de kullanıldığında

tipik olarak UDP üstünde çalışan bir protokoldür.

Bu protokoller, zamanında teslimden emin olacak mekanizmalara sahip değildirler.

Herhangi bir QoS garantisi de vermezler. Bunlar başka bazı mekanizmalar tarafından

sağlanmak durumundadırlar.

Aynı zamanda, sırası bozuk şekilde veri akışının olması hala olasıdır. RTP’de akış ve

tıkanıklık kontrolü direkt olarak desteklenmemektedir. Ama gelen verinin sırasının,

doğru olduğundan emin olmak için gerekli veriyi uygulamalara protokoller teslim

ederler. Aynı zamanda, RTCP alma kalitesi hakkında, uygulamanın yerel düzenlemeler

yapabileceği bilgiyi sağlar. Örneğin tıkanıklık oluşuyorsa, uygulama veri oranını

azaltmaya karar verebilir.

2.1.4.1 RTP başlığı

Bir RTP paketi, bir RTP başlığı (header) ve onu takiben gönderilecek veriden ibarettir.

RTP teknik bilgisinde bu veri faydalı yük (payload) olarak isimlendirilir. Başlık, aynı IP

başlığında olduğu gibi ağ bayt sırasında (network byte order) iletilir. Şekil 2.4 RTP

başlığının biçimini göstermektedir (Schulzrinne vd. 1996).

Şekil 2.4 RTP başlık bilgisi

10

Şekilde gösterilen alanlar ve açıklamalar şöyledir:

V: Sürüm Bilgisi (Version Information), RTP’nin değişik sürümleri arasında ayrım

yapabilmek için kullanılır. (2 bit) protokolün şuanda 2 sürümü bulunmaktadır.

P: Doldurma (Padding), eğer değeri 1 olarak atanmışsa; paketin sonunda bir ya da daha

fazla, yükün parçası olmayan dolgu baytları mevcut demektir. Dolgu bitleri sabit

boyutlu başlıklarda bazı şifreleme algoritmaları için kullanılabilmektedir. (1 bit)

X: Uzantı (Extension), eğer değeri 1 olarak atanmışsa; başlığın sonunda kesinlikle bir

adet başlık uzantısı mevcut demektir. (1 bit)

CC: CSRC (Katılımcı Kaynağı Tanımlayıcısı - Conributing Source Identifier Count)

sayısı, sabit başlığı takip eden CSRC tanımlayıcı sayısını gösterir. (4 bit)

M: Đşaretleyici (Marker), yük profili tarafından tanımlanır. Çerçeve sınırlarının

işaretlenmesi benzeri önemli işlevler için kullanılır. (1 bit)

PT: RTP yükünün yapısını tanımlar ve uygulama tarafından anlamlandırılacağını

belirtir. (7 bit)

Sıra Numarası: Gönderilen her RTP veri paketiyle birlikte, değeri bir artırılır. Alıcı

tarafından paket kayıpları tespiti ve paket sıralamasının yeniden oluşturulması için

kullanılabilir. (16 bit)

Zaman etiketi (timestamp): RTP veri paketindeki ilk bayta ait örnekleme zaman kesitini

içeren, ortama özgü bir zaman etiketidir. Örnekleme kesiti, eş zamanlılığa imkan

tanımak ve gecikme değişkenliği hesaplarını yapabilmek için, zamanda doğrusal ve

tekdüze artan bir saatten türetilmiş olmalıdır. (32 bit)

SSRC : (Eş Zamanlama Kaynağı Tanımlayıcısı - Synchronisation Source Identifier), eş

zamanlayıcı kaynağı tanımlar. Tanımlayıcı, bir oturum içinde iki ayrı kaynağın aynı

tanımlayıcıya sahip olmaması için, rasgele seçilir. Kaynak tanımlamanın amacı, tek bir

zamanlama ve sıra numaralama uzayına sahip olmaktır. Yerel ağ adresini (örn: IP

adresi) kullanmak yeterli değildir, çünkü bu adres tek olmayabilir. RTP ayrıca taşıma

katmanından bağımsız olmak üzere tasarlanmıştır. RTP çeviricileri, değişik adres

11

uzaylarına sahip farklı ağlar arasındaki uyumluluğu sağlamak üzere tasarlanmıştır.

Rasgele seçilmiş bir SSRC kullanmak, iki farklı adres uzayında tahsis dizileri

kullanmaktan hem daha basittir hem de daha düşük adres çakışması ihtimaline sahiptir.

Bir oturumda aynı SSRC tanımlayıcısına sahip iki kaynağın bulunduğu az rastlanır

durumlarda çarpışmaya dair problem çözme mekanizmaları devreye girer. (32 bit)

CSRC, RTP paketindeki yüke katılım yapan kaynakları listeler. CSRC tanımlayıcıları

RTP karıştırıcılarında değişik kaynaklardan gelen RTP paketleri tek bir RTP paketi

içine yerleştirildi ğinde eklenir. Yani değişik kaynaklardan gelen ses paketlerinin SSRC

tanımlayıcıları CSRC içine yerleştirilir ve yeni oluşturulan bu paket için karıştırıcı

SSRC ’si kullanılır. Bu işlem, alıcı tarafındaki konuşma tespitinin doğruluğu için

gereklidir. ( (0–15) * 32 bit )

Son olarak başlık, ilave başlık kullanarak fazladan bilgi içerebilir. RTP teknik bilgisinde

eklenti mekanizmasını sadece tanımlar, muhtemel bir eklentiden bahsetmez. Bu

uygulamaya bırakılmıştır.

Başlığın ilk iki biti sürüm numarasını taşır. Protokolün iki farklı sürümü vardır. Sonraki

bit doldurma bitidir. Bu bit ayarlanmış ise paket, faydalı yükün parçası olmayan, bazı

doldurma baytları içermektedir. Örneğin, doldurma, birden çok bayt sınırında

hizalanması gereken bazı şifreleme algoritmaları için gerekli olabilir. Đlave bit başlığın

bir ilave başlık içerip içermediğini gösterir. Daha sonra, RTP başlığı içinde kaç tane

katılımcı kaynağın belirlendiğini gösteren CSRC sayısı vardır.

Đşaretleyici biti, uygulama tarafından örneğin bir konuşma isteği (talkspurt) haberi

vermek için kullanılabilir. RTP teknik açıklamalarında bunun tam bir yorumu

bulunmamaktadır, uygulamanın kendisine bırakılmıştır. Daha sonra, faydalı yük tipi

(payload type) vardır. Bu paketin içerdiği verinin tipini tanımlar, yani uygulamanın

faydalı yükü yorumlayacağı yolu tanımlar.

Sıra numarası (Sequence number), bir uygulama tarafından gelen paketleri doğru sıraya

dizmek için kullanılabilir. Numaralama güvenlik sebebiyle rasgele bir değerden başlar.

Zaman etiketi, paketlerin akışı için senkronizasyon bilgisini içerir. Bu değer faydalı

yükün ilk baytının ne zaman örneklendiğini belirtir. Örneğin ses için, zaman etiketi tipik

12

olarak paket içindeki örnek miktarıyla arttırılır. Alan uygulama bu bilgiyi temel alarak,

ses verisini tam olarak doğru zamanda çalabilir. Sıralama sayısında olduğu gibi zaman

etiketi işaret başlangıç değeri rasgeledir. Birkaç paket aynı zaman etiketi değerine sahip

olabilir. Örneğin sayısallaştırılmış video verisiyle, bir görüntünün genellikle birkaç

parça içinde gönderilmesi gerekir. Bu parçalar farklı sıralama sayılarına sahiptirler ama

zaman etiketleri aynı olabilir.

SSRC, paketi gönderenin tanımlama numarasıdır. Uygulama aynı anda farklı tip veri

göndermek isterse, örneğin ses ve görüntü, her tip veri için ayrı RTP oturumları

olmalıdır. Bu yolla, bir uygulama gelen veriyi SSRC’ye bakarak gruplayabilir.

Tanımlayıcı rasgele seçilir; haberleşen iki grubun kazara aynı SSRC yi alma olasılığı

çok düşüktür. Bu nadir durumda oluşacak sorunu çözmek için yapılması gerekenler

özellikler de açıklanmıştır.

Sırada, muhtemelen bir CSRC’lerin bir numarası vardır. Örneğin, bir noktada farklı ses

akışlarının karıştırılması gerekiyorsa, esas SSRC tanımlayıcılar buraya konulabilir. Bu

paketin SSRC tanımlayıcısı sonradan karıştırılmış paketi gönderen kaynağın

tanımlayıcısı olur.

Son olarak, başlık, ilave başlık kullanarak fazladan bilgi içerebilir. RTP özellikleri

eklenti mekanizmasını sadece tanımlar, muhtemel bir eklentiden bahsetmez. Bu

uygulamaya bırakılmıştır.

2.1.5 RTCP

RTP’ye bir kontrol protokolü, RTCP (Gerçek Zamanlı Taşıma Kontrol Protokolü -

Real-time Transport Control Protocol) eşlik eder (Schulzrinne vd. 1996). RTP

oturumunun tüm katılımcıları periyodik olarak, tüm katılımcılara RTCP paketleri yollar.

RTCP dört farklı işleve sahiptir:

RTCP2 nin, temel işlevi veri dağıtımının kalitesi hakkında geri besleme yapmaktır. Bu

geri besleme adaptif kodlama kontrolü için kullanılabilir. IP çoklu-yayın deneyleri

sonucunda görülmüştür ki geri besleme, dağıtım hatalarını teşhis etmek için de kritik bir

role sahiptir. Geri besleme işlevi alıcı ve verici raporlarıyla elde edilir. Aşağıdaki

şekillerde (Şekil 2.5 ve Şekil 2.6) alıcı ve verici raporları gösterilmiştir.

13

RTCP bir oturumdaki bütün katılımcıların kaydını tutar. Her bir kaynağa ait, CNAME

(Takma Ad - Canonical Name) denilen taşıma katmanı tanımlayıcılarını ve de eş

zamanlayıcı kaynak tanımlayıcısını taşıyarak bu işlevi yerine getirir. Eş zamanlayıcı

kaynak tanımlayıcısı bir oturum içinde değişebilir. CNAME ayrıca ilintili çoklu

akışların (ses ve görüntü) eş zamanlaması için de gereklidir.Bir katılımcı oturumu terk

ettiğinde, RTCP çıkış mesajı gönderilir.

RTCP paketleri, yukarıda geçen işlevleri yerine getirmesi için sırayla gönderilir,

dolayısıyla bu sıranın da kontrol edilmesi gerekmektedir. Bu kontrol de RTCP

tarafından gerçekleştirilir. Gözlemlenen katılımcı sayısı, paket gönderme oranını

belirleme için kullanılır. Bir oturumdaki katılımcı sayısı ile her bir katılımcının paket

gönderme oranı ters orantılıdır.

Bahsi geçen ve gerçekleştirilmesi zorunlu olan ilk üç işlevin aksine, isteğe bağlı olarak

gerçekleştirilebilen dördüncü işlev ise asgari oturum kontrol bilgisi (örn: katılımcı

tanımlanmasının kullanıcı arabiriminde görüntülenmesi) taşımayı amaçlar.

Şekil 2.5 RTCP alıcı raporu başlık

14

Şekil 2.6 RTCP gönderici raporu

2.1.6 Paket boyutu

Sayısallaştırılmış konuşmayı iletmek için kullanılacak uygun protokolün RTP olduğu

düşünülebilir.

Paketlerin sadece küçük bir miktar ses verisi içermesi iki sebepten dolayı tercih edilir.

Đlk olarak, bir paketin kaybolması durumunda, iletişimdeki bozulma daha az olacaktır.

Đkinci olarak, toplam gecikmenin azaltılması için, örnekleme aralığının mümkün

olduğunca az olması gerekir. Sayısallaştırılmış ses sinyalinin her parçası mümkün olan

15

en kısa süre içinde iletilmelidir. Örnekleme aralığının az olması paket büyüklüklerini

otomatik olarak azaltacaktır.

Konuşma verisi iletildiğinde, hat kapasitesinin bir miktarı başlıklar ve alt katmanlardaki

protokoller tarafından kullanılacaktır. Yani paket içindeki ses verisinin az olmasıyla,

iletim için kullanılacak başlıklar için daha fazla kullanılabilinir bit kalacaktır.

Bir ses sinyali bir milisaniyelik düzenli aralıklarla örneklenip, her örnek aralığından

sonra RTP kullanarak sayısallaştırılmış sinyali iletilebilinir. Bu durumda her

milisaniyede en az bir RTP, UDP ve IP başlığı bu iletimde kullanılacaktır. Bu

başlıkların toplam boyutu en az 40 bayttır. Her milisaniyede 40 bayt göndermek için

320 kbps’lik bir veri hızına ihtiyaç duyulur.

Örnekleme zaman aralığını arttırılırsa, başlık bilgisi tarafından kullanılacak hat

kapasitesinin azalacağı açıktır. Başlıklar tarafından kullanılacak veri hızının azalması

toplam gecikmenin artmasına neden olacaktır. Yani örnekleme aralığının artırılmaması

gereklidir. Örnekleme aralığının arttırılması paket büyüklüklerini de artıracak ve doğal

olarak kayıp paketlerin oluşması ihtimalini de artacaktır.

Dial-up bağlantılar, LAN bağlantılarına oranla daha düşük hat kapasitesine sahiptir.

Dial-up bağlantı kullanımında paket içerisindeki veri için mümkün alan kullanılmalıdır.

Bu tip bağlantılarda başlık bilgisi tarafından işgal edilen veri hızı miktarını fazlasıyla

düşüren yöntemler bulunabilinir.

2.1.7 QoS mekanizmaları

RTP ses iletiminde servis kalitesini garanti edemez. Servis kalitesi için QoS

mekanizmaları kullanılmalıdır.

2.1.7.1 Paketlere öncelik sıraları vermek

IP başlığında paketlere öncelik verilebilir. IPv4 ve IPv6 kullanılmakta olan iki farklı IP

sürümüdür. IPv4’te QoS’un bir seviyesi ToS (Servis Tipi – Type of Service) alanında

belirtilebilir. IPv6 başlığı, trafik sınıfı alanının (traffic class field) kullanımıyla benzer

bir özelliğe sahiptir.

16

Tüm yönlendiricilerde bu tip öncelikler ayarlanılabilinirse, gerçek zamanlı verinin az

gecikmeyle teslim edilebilmesi sağlanabilinir. Bu yaklaşımın ana avantajı ek bir

protokol kullanımına ihtiyaç duyulmamasıdır.

QoS mekanizmaları sadece daha iyi bir hizmet verebilirler, garanti veremezler. Örneğin,

tüm ağ yüksek öncelikli trafikle doluysa servis kalitesi hala düşük olacaktır.

Gerçek zamanlı verinin garantili iletimi isteniliyorsa, Qos mekanizmaları dışında

protokoller kullanılmalıdır. Garantili iletim için iki farklı protokol kullanılabilinir.

ST2 (Akış Protokolü Sürüm 2 - Stream Protocol version 2)

RSVP (Kaynak Rezervasyon Protokolü-Resource Reservation Protocol)

2.1.7.2 ST2

ST2 (Akış Protokolü Sürüm 2 -Stream Protocol version 2), CIP Working Group

tarafından Ekim 1990 yılında ortaya çıkarılmıştır. Protokolle deneyim kazanıldıktan beş

yıl sonra, revize edilmiş ve tekrar tanımlanmıştır (Delgrossi ve Berger, 1995).

Revizyonla protokol basitleştirilmi ş, uygulaması kolaylaştırılmış ve protokol daha

ayrıntılı açıklanmıştır.

TCP/IP mimarisinde, ST2 internet katmanına yerleştirilmi ştir. Amacı garantili bir

şekilde uçtan uca hizmet sağlamaktır. Protokol, IP yerine kullanılacak şekilde değil

daha çok ona bir eklenti olacak şekilde tasarlanmıştır. Bu şekilde genel veri taşımalar

hala IP’yi kullanırken gerçek zamanlı veri ST2 kullanılarak iletilebilmektedir.

Bağlantısız (connectionless) bir protokol olan IP den farklı olarak, ST2 bağlantı

yönelimlidir. Đlk olarak, bir bağlantının kurulması gerekir. Bu bölümde QoS

garantilerini sağlamak için kaynaklar ayrılır. ST2 bağlantısı kurulduğunda artık gerçek

veri taşıması yapılabilir. Tüm veri iletildiğinde bağlantının tekrar sonlandırılması

gerekir.

Bir bağlantı verinin sadece orijinden hedeflere doğru akışına izin verecektir. Eğer diğer

yönde bir iletişim yapılması gerekiyorsa farklı bir ST2 bağlantısının yapılması gerekir.

Bu yolla, bağlantı orijinden hedeflere doğru yönlü bir ağaç şeklinde gösterilebilir. Bu

17

modeli kullanarak, verinin dağıtımı, birbirinin kopyası paketlerin miktarının en aza

indiren bir şekilde yapılacaktır.

Bir bağlantı yaratmak için, uygulama öncelikle bağlanılacak hedeflerin sayısını bilmek

durumundadır. Bu amaç için, uygulamanın kendisi ST2’yi kullanamaz. Bunu yapmak

için muhtemelen IP bazlı bir protokol kullanılacaktır.

Uygulama hedefleri ve gerekli QoS kısıtlamalarını bildiği zaman, bu bilgiyi ST2

modülüne gönderebilir ve bu hedeflere doğru birer bağlantı oluşturmasını isteyebilir.

QoS kısıtlamaları ST2 içinde, FlowSpec de denen, akış özelliklerinin kurallarıyla

dağıtılır.

FlowSpec içindeki bilgiyi baz alarak, orta seviye ST2’yi destekleyen yönlendiriciler

gerekli rezervasyonu gerçekleştirebilirler. Eğer bu rezervasyonlar istenen QoS’a

uymuyorsa, akış özelliklerinin içindeki bilgi elde edilen QoS seviyesini gösterecek

şekilde güncellenir.

Hedef bir bağlantı isteği aldığında, bu FlowSpec uygulama tarafından incelenebilir ve

uygulama, bağlantıyı kabul etmeye veya etmemeye karar verebilir. Bağlantı kabul

edilirse, alınan QoS içindeki FlowSpec, bağlantı isteğinin orijinine geri gönderilir.

Her şey iyi giderse, bağlantıyı deneyen uygulama, her hedefin birer doğrulamasını alır.

Bu doğrulamalar aynı zamanda her bir hedef için elde edilen QoS’u tanımlayan

FlowSpec’i de içerirler. Uygulama daha sonra verilerini göndermeye ya da bağlantıyı

iptal etmeye karar verebilir.

Orijinden hedeflere giden yollardaki farklı bölümlerde rezervasyonlar değişebilir.

Uygulama herhangi bir aşırı rezervasyonu açıkça bırakmalıdır.

Bağlantının yaşam süresi boyunca, hedef eklenmesi ihtimali hala vardır. Prosedür,

yaratma bölümüne benzerdir ve bağlantının orijini tarafından başlatılır. Hedefler aynı

zamanda bağlantıdan çıkarılabilirler. Bu hem orijin hem de hedef tarafından yapılabilir.

Aslında sadece veri paketleri ST2 kullanılarak iletilir. Di ğer fonksiyonlar bir kontrol

protokolünün, SCMP’nin (ST Kontrol Mesaj Protokolü- ST Control Message Protocol)

kullanımıyla yapılır. Bu fonksiyonlar bağlantı yaratma ve hedef eklemeyi de içerir. Tüm

18

kontrol mesajları güvenli bir şekilde, tanımaların ve gerek olursa tekrar iletimlerin

kullanımıyla iletilir.

Ağ elemanlarının hatalarını algılayabilmek için, her ST2 kullanabilen makine, periyodik

olarak kendi komşularına bir 'merhaba (hello)’mesajı gönderir.

ST2’nin kendisi rezervasyonların nasıl yapılacağını ya da QoS’un nasıl sağlanacağını

belirtmez. Sadece istenen QoS özelliklerinin dağıtımının yapılacağı bir yol sunar.

2.1.7.3 RSVP

Kaynakların rezerve edilmesi için başka bir yol da RSVP (Kaynak Rezervasyon

Protokolü-Resource Reservation Protocol)’dir (Braden vd. 1997). Protokol

Bütünleştirilmi ş Servisler (Integrated Services) modelinin bir parçasıdır (Braden vd.

1994). Bütünleştirilmi ş Servisler terimi, hem gerçek zamanlı hem de en iyi çaba gibi,

birkaç tip hizmetin sunulabildiği gerçeğine işaret eder.

ST2 den farklı olarak RSVP’nin kendi veri iletim protokolü yoktur. Bu fonksiyon hala

IP tarafından gerçekleştirilmektedir. RSVP sadece, uygulamalara QoS garantileri

sağlamaya yardım etmek için kullanılabilecek bir kontrol protokolüdür.

Eğer bir istemci belli bir QoS ile ulaşması gereken bir veriyi iletecekse, verinin hedefine

periyodik olarak bir yol mesajı gönderir. Bu adres hem teke gönderim (unicast) hem de

çoğa-gönderim (multicast) adresi olabilir. Yol mesajı, gönderici tarafından yaratılacak

trafiğin karakteristikleri hakkında bilgi içerir. Veri paketlerinin biçimi de tanımlanır.

Diğerleri arasından göndericinin gönderdiği paketleri seçmek, bu bilgiyi kullanarak

mümkün olur.

Hedeflerine doğru giden yolda RSVP kullanabilen yönlendiriciler, yol mesajı içindeki

bilgiyi saklarlar. Bu şekilde bilgi, yol mesajının göndericisinden gelen veriler için

olacak rezervasyonları yaparken kullanılabilir.

Bir uygulama bir yol mesajı aldığı zaman, göndericinin verisini belirli bir QoS ile

almaya karar verebilir. Yol mesajı içindeki bilgilerden gerekli QoS kısıtlamalarını

hesaplayabilir. Bu QoS’u istemek için, yol mesajının tersi yöndeki yol üzerinden

19

periyodik olarak rezervasyon isteği gönderecektir. Tam tersi yol, RSVP kullanabilen

yönlendiricilerin yol mesajına cevap olarak sakladığı bilgi sayesinde bulunabilir.

Rezervasyon isteği, iki elemanı içerir. Đlki, alıcının elde etmek istediği QoS’u içerir.

Đkincisi, Bu QoS ile alınması gereken veri paketlerinin grubunun tanımlamasını içerir.

Her yönlendirici içinde, QoS’u desteklemek için gerekli rezervasyonlar yapılabilir.

RSVP’nin önemli bir özelliği rezervasyonların birleştirilebilir olmasıdır. Birleştirmeden

sonra yönlendirici, bağlantı yukarı akım (upstream) için net bir değişikli ğin varlığını

kontrol eder ve eğer varsa, bir önceki yönlendiriciye uygun bir rezervasyon isteği

gönderilir.

Bu durum küçük bir örnekle özetlenebilir. Şekil 2.7’deki gibi bir senaryo da, A

göndericidir ve online bir konferansın bir parçası olan sayısallaştırılmış konuşmayı

göndermektedir. Bu veri, yol mesajlarının da gönderildiği bir çoğa-gönderim adresine

gönderilerek dağıtılmaktadır. Cevap olarak B istemcisi, A’dan B’ye giden yolda 32

kbps’lik bir rezervasyona sebep olan bir rezervasyon isteği çıkarır.

Şekil 2.7 Rezervasyon örneği

Daha sonra C istemcisi da konferansa katılır ve gönderici A ile 16 kbps’lik garantili bir

bağlantı istemektedir. C istemcisi, bunu belirten bir rezervasyon isteği yaratır ve bunu

yönlendirici 2 ye yollar. Orda, yönlendirici isteği inceler ve C’ye olan bağlantıda 16

kbps aşağı akım (downstream) veri hızını ayırır. Aynı zamanda, A ya doğru 32 kbps’lik

bir rezervasyonun varlığını ve yönlendirici 1’e fazladan rezervasyon isteğinin

20

gönderilmesi gerekmediğini fark eder. Eğer, C istemcisi 64 kbps garantili bir bağlantı

isteseydi, yönlendirici 1’e yeni bir istek gönderilmesi gerekecekti.

RSVP tarafından birçok rezervasyon tipi desteklenmektedir. Örneğin, bir istemci birçok

kaynaktan veri alıyorsa, her bir kaynak için ayrı hat kapasitesini ayıracak bir

rezervasyon isteği çıkarabilir. Ama aynı zamanda, ayrılan hat kapasitesinin tüm

göndericiler arasında paylaşılacağını belirtmek de mümkündür. Bu, bir zamanda

genellikle sadece bir konuşmacının olacağı online bir tartışma durumunda kullanışlıdır.

Bu sayede, kullanılan hat kapasitesini sadece bir ya da az sayıda konuşmacıya vermek

yeterli olacaktır.

Yol mesajları ve rezervasyon istekleri periyodik olarak gönderilir. Bunun sebebi,

yönlendirici içindeki RSVP bilgisi belli bir süre sonra zaman aşımına uğrayacak

olmasıdır. Yol bilgilerini ve rezervasyonlarının yerinde tutulması için düzenli olarak

güncellenmeleri gerekir. Bu mekanizma yumuşak-durum (soft-state) olarak adlandırılır.

Bir rezervasyon ya da yol durumu zaman aşımına uğradığında, ilgili kaynaklar

boşaltılabilir. Kaynaklar aynı zamanda, bir gönderici ya da alıcı çıktığında hemen

boşaltılabilir.

ST2 de olduğu gibi, RSVP’de de, gerçek QoS garantilerinin nasıl uygulanacağını

belirtmez. Protokol sadece QoS ile ilgili verileri dağıtmak için kullanılır.

2.1.7.4 ST2 ve RSVP karşılaştırması

Hem ST2 hem de RSVP, göndericiden alıcıya olan yol üzerinde kaynak rezervasyonu

yapabilmek için bir mekanizma sağlarlar. Bu kaynak rezervasyonları QoS garantilerini

desteklemek için tasarlanmıştır. Đki protokolle de, kaynaklar sadece göndericiden

alıcılara yönde veri dağıtımı için ayrılır. Bu kökün gönderici olduğu, yönlü bir ağaç gibi

modellenebilir.

Ama bu protokollerin yaptığı yaklaşımlar büyük ölçüde farklıdırlar. Ve hangisinin daha

etkili olduğu sorusu açığa çıkar. Mitzel ve diğerleri 1994 yılında bu iki protokol

arasında bir karşılaştırma yapılmışlardır.

21

Protokoller arasındaki önemli bir değişiklik rezervasyon isteklerinin oluşturulduğu

yerdir. ST2 ile dağıtım yolu üzerindeki gerekli rezervasyonları yapan göndericidir.

Diğer yanda, RSVP’de alıcılar rezervasyon isterler. RSVP’nin rezervasyon tipinin alıcı

tarafından başlatıldığı söylenirken, ST2'nin gönderici tarafından başlatılan tipte olduğu

söylenir.

Bazı uygulamalar için, birkaç gönderici olabilir ama genellikle aynı anda

göndericilerden bazıları aktif gönderen olabilirler. RSVP’de çok özel bir rezervasyon

tipinin kullanımıyla bu bilgiden faydalanılabilir. Ama ST2 böyle bir özelliğe sahip

değildir. Burada, her bir muhtemel gönderici için rezervasyonlar yapılacak ve hat

kapasitesinin fazla kullanımına sebep olacaktır.

Veri birden fazla alıcıya gönderilirken, tüm alıcıların aynı QoS isteklerinin olacağı

durum rastlanılmaz. ST2 gönderici tarafından başlatıldığı için, gönderici rezervasyon

isteğini, en çok isteyen alıcının ihtiyaçlarını karşılayacak şekilde yapacaktır. Az isteyen

alıcıların bağlı olduğu kollar bile aynı rezervasyonu yapacaktır.

RSVP ile alıcıların heterojenliği daha etkili bir şekilde değerlendirebilinir. Đstekler

istemcilerden çıkacaktır ve eğer mümkünse, istekler birleştirilecektir. Bu, dağıtım

ağacının az isteyen alıcılara açılan kollarında az rezervasyona sahip olacağı anlamına

gelebilir.

Bir alıcı tüm aktif göndericilerden gelen veri akışlarına cevap veremezse, veri almak

için hangi kaynakları kullanmak istediğini dinamik olarak seçebilir. Bu kanal seçimi

olarak adlandırılır. ST2'de yapılabilecek tek kanal seçimi her gönderici için ayrı

rezervasyon yapmaktır. Asıl kanal seçimi alıcıda yapılmalıdır.

RSVP rezervasyon isteklerinin, ilgili QoS’u hangi paketlere uygulayacağına karar

verebilir. Bir rezervasyon isteği gönderildiğinde, yeni bir kaynaklar grubu seçilebilir ve

filtreleme ağ içerisinde yapılabilir.

ST2'deki ağ hatası algılama, aynı akış içine katılan komşu makinelere periyodik olarak

mesaj yollama yoluyla yapılır. Bir hata algılandığında, bir kurtarma prosedürü başlatılır.

RSVP herhangi bir hataya otomatik olarak adapte olabilmek için tamamıyla yumuşak

durum mekanizmasına güvenir. Đki protokol de periyodik olarak mesajlar yollar. Ama

22

RSVP’de, mümkün olan yerde rezervasyon isteklerinin birleştirilmesiyle bu mesajların

getireceği ek yük azaltılır.

Bir alıcı ST2 oturumuna katıldığında, bu alıcı için rezervasyon isteklerinin gönderici

tarafından yapılması gerekir. Bu şekilde, bir mesajın kaynaktan çıkıp tüm yolu geçerek

yeni alıcıya ulaşması sağlanılır. RSVP’nin alıcı tarafında başlatılan yaklaşımıyla, bir

rezervasyon isteği göndericiye doğru sadece gönderilir ve mümkün olan yerde diğer

rezervasyonlarla birleştirilebilir. Bu birleştirme, protokol ek yükünün azalması

sonucunu verir. RSVP’de alıcının kendi isteğini yollamak için bir yol mesajı alana

kadar beklemesi gerekebilir.

2.1.7.5 Đletimin gecikmesi

Kaynak rezervasyonu yöntemleri yönlendiriciler tarafından desteklendiğinde, iletim

gecikmeleri muhtemelen, toplam gecikme limiti olan 200 ms yi sağlayabilecek kadar az

tutulabilir. Ama mevcut yönlendiricilerin genelde bu şekilde özellikleri yoktur.

Veri iletildiğinde, verinin gittiği bağlantıların kapasitesine bağlı olarak minimal bir

gecikme miktarı her zaman vardır. Ama iletim kaynaklı gecikmelerin önemli bir

miktarı, paketlerin yönlendiriciler içinde sıralanmasından ötürüdür. Bu gecikme

fazlasıyla değişkendir ve hem yol üzerindeki yönlendiricilerin sayısına hem de

yönlendiricilerin yüküne bağlıdır.

IP ağlardaki iletim gecikmesi hakkında genel bir fikir ortaya sürmek mümkün değildir,

yine de tek yönlü iletim gecikmeleri nadiren 100 ms’i geçebilir.

2.1.8 H.323

H.323 hakkındaki ITU-T dokümanı paket bazlı ağlarda QoS desteği olmadan çoklu

ortam konferansları için bir tavsiye halindedir. Farklı tip ağlar üzerinde çoklu ortam

konferansı tanımlayan H.32x tavsiyeler serisinin bir parçasıdır. Bu tavsiyeler DataBeam

Corporation tarafından 1999 yılında konulmuştur. Çizelge 2.1’de bu tavsiyeler

görülmektedir.

23

Çizelge 2.1 H.323 tavsiyeleri

2.1.8.1 Fonksiyonellik

H.323 tavsiyelerine uyan son sistemler birbirleriyle hem sondan sona hem de çok

noktalı konferans şekilde haberleşebilirler. Bu son sistemler farklı yeteneklere sahip

olabilirler ama her birinin en azından G.711 ses kodlamasını desteklemesi gerekir.

Görüntü desteği ve diğer ses kodlayıcıları opsiyonludur. H.323 aynı zamanda genel veri

transferinin nasıl yapılacağını da tanımlar ama bu da opsiyonludur.

Tavsiye, farklı tip ağlardaki H.32x standartlarına uyan son sistemler arasında iletişimi

mümkün kılar. Bu, gerekli dönüşümleri yapabilmek için farklı ağlara bağlanan özel

cihazlar gerektirmektedir.

H.323, hesap (accounting) ve yönetim desteği de sağlanmaktadır. Bu sayede, örneğin

H.323 aramaları ile işgal edilebilecek en fazla hat kapasitesi miktarını belirlemek

mümkündür. Hesap, arayanların faturalandırılması desteğini sağlar.

H.323 tavsiyesi destekleyici hizmetlerin geliştirilmesi için bir çatı (framework)

tanımlar. Bu şekilde arama yönlendirme ve aktarma hizmetleri tanımlanmıştır.

Son olarak, paket bazlı ağlar -IP ağları gibi- genellikle çok güvenli olmadıkları için,

H.323 daha iyi bir güvenlik sağlamak için birkaç mekanizma tanımlamaktadır.

2.1.8.2 Bileşenler

H.323 tavsiyesinde terminaller, ağ geçitleri, ağ kayıt tutucuları (gatekeeper) ve çoklu-

nokta kontrol birimleri (multipoint control unit - MCUs) bileşenler olarak belirtilmiştir.

24

Bir terminal H.323 verisinin ve sinyalleşme akışlarının başladığı ve bittiği bir sistemdir.

Sistem, en azından G.711 ses kodlamasını kullanabilecek yeteneğe sahip olmalıdır.

Ağ geçidi (Gateway), H.323 kullanabilen sistemlerin diğer H.32x kullanan sistemlerle

haberleşmesini mümkün kılan bir cihazdır. Ağ geçitleri farklı ağları birbirlerine

bağlarlar ve gerekli dönüşümleri yaparlar. Sinyalleşme bilgisinin değiştirilmesi ya da

başka bir ses kodlamasının kullanılması gerekli olabilir. Ağ geçidi H.323 kullanılabilen

bir ağda seçimlidir.

Ağ kayıt tutucu, seçimli bir bileşendir ama varlığı çok kullanışlıdır. Bir ağ kayıt tutucu

varsa, tüm terminallerin, ağ geçitlerin ve MCU’ların ona kaydolması gerekir. Bir ağ

kayıt tutucu tarafından iki önemli iş gerçekleştirilir. Uluslararası bir telefon numarasının

bir ağ adresine dönüşümünü yapmak görevlerinden biridir. Bir diğer görevi ise hat

kapasitesi yönetimidir. Bir ağ kayıt tutucu, H.323 aramalarıyla kullanılan hat

kapasitesini sınırlayacak ya da aynı anda yapılan sabit arama sayısına izin verecek

şekilde ayarlanabilir.

Bir ağ kayıt tutucunun seçimli bir özelliği de aramaları yönlendirmesidir. Bir arama, bir

ağ kayıt tutucuya yönlendirildiğinde, arama üzerinde daha fazla kontrol ve arama

hakkında daha fazla bilgi sağlayacaktır. Bu, aramaları faturalandırmak ya da bir aramayı

aranan uçtaki istemci uygun olmadığı zaman, başka bir sisteme tekrar yönlendirmek için

kullanılabilir.

Bir MCU üç ya da daha fazla uç noktası olan konferanslar için kullanılır. Bir MC

(Çoklu-nokta kontrolcüsü) ve muhtemelen birkaç MP (Çoklu-nokta Đşlemcisi) içerir.

Katılımcılar, uç nokta yeteneklerinin değiş tokuş edilebilmesi ve iletişim parametreleri

görüşülebilmesi için, kendi kontrol bilgilerini MC’ye gönderirler. MP gelen veriyi

işlemek, örneğin birkaç akışı karıştırmak, için kullanılır.

Çok noktalı konferans için üç model tanımlanmıştır. Tüm modellerde her katılımcı,

kendi kontrol bilgisini, MC tarafından işlenebileceği, MCU’ya gönderir.

Merkezileştirilmi ş modelde, her katılımcı kendi verisini de MCU’ya gönderir. Merkezi

olmayan modelde ise farklı veriler çoğa-gönderimle dağıtılır. Karma modelde, bazı

25

katılımcılar veriyi dağıtmak için çoğa-gönderim kullanırken, diğerleri direkt olarak

MCU’ya gönderir. Şekil 2.8 de örnek bir H.323 sistemi görülmektedir.

Şekil 2.8 Örnek H.323 sistemi

2.1.8.3 Mimari

H.323 tavsiyesi şemsiye özelliği (umbrella specification) olarak da adlandırılır. Bunun

sebebi fonksiyonelliği sağlamak için birçok diğer ITU-T tavsiyelerini kullanmasıdır.

H.323 mimarisinin yapısı Şekil 2.9’da gösterilmiştir.

Şekil 2.9 H.323 mimarisi

26

Ses kodlayıcıları, ITU-T G. standartlarıdır. Tavsiyelerde tanımlanan görüntü

kodlayıcıları H.261 ve H.263’tür. H.263 kodlayıcı düşük bit oranındaki taşımalar için

tasarlanmıştır ama H.261’den daha karmaşıktır. Hem ses hem görüntü RTP paketlerinde

sarılmıştır ve sonrasında ağ üzerinden iletilir. Bu iletimler hakkında ek bilgi RTCP

tarafından sağlanır.

Đki ya da daha fazla grup birbiriyle haberleşmeden önce, ilk olarak bir arama

hazırlanmalıdır. Bu, H.225.0 ve H.245’de tanımlanan mekanizmaların kullanımıyla

yapılır. H.225.0 tavsiyesi bir aramanın nasıl hazırlanacağını ve sonlanacağını belirtir.

Arama gerçekleştirildi ğinde, yer alan son sistemlerin yetenekleri değiş tokuş edilir ve bu

sayede her son sistem uygun kodlayıcıları seçer. Bu yetenek değiş tokuşu, örneğin ses

ve görüntüyü taşımak için mantıksal kanalların açılıp kapanması gibi diğer

fonksiyonları da tanımlayan H.245 tarafından yapılır.

H.225.0 tavsiyesinin diğer bir kısmı ağ kayıt tutucuyla nasıl bir etkileşim yapılacağını

belirtir. Bu, Registration(Kayıt olma), Admission (Kabul) ve Status (Durum)

kelimelerinin kısaltması şeklinde, RAS denen bir protokol tarafından yapılır. RAS

fonksiyonları, ağ kayıt tutucu keşfi ve son noktanın bir ağ kayıt tutucuya kaydı

işlemlerini içerir. Hat kapasitesi yönetimi ve izin kontrolü de RAS mesajları tarafından

yapılır.

H.323 son sistemleri, birbirleriyle genel veri değiş tokuşu da yapabilirler. Veri değiş

tokuşunun nasıl yapılacağı T.120 tavsiyesinde belirtilmiştir. H.323’te olduğu gibi, bu

da, veri değiş tokuşu için diğer protokollerin nasıl kullanılacağını tanımlayan bir

şemsiye tavsiyedir.

Güvenlik hizmetlerinin nasıl sağlanması gerektiği H.235 tavsiyesinde tanımlanmıştır.

Doğrulama, ağ kayıt tutucu tarafından yapılan, son noktaların izin kontrolleriyle

sağlanır. Veri bütünlüğü ve güvenliği şifreleme teknikleri kullanılarak uygulanır. Son

olarak, inkâr edememe de ağ kayıt tutucu tarafından sağlanmaktadır.

2.1.9 SIP

H.323‘den sonra noktadan noktaya mimarilerde SIP (Oturum Başlatma Protokolü-

Session Initiation Protocol) de yerini almıştır. H.323‘den farklı olarak SIP felsefe ve

27

amacı bakımından internet tipi bir protokoldür. SIP, IETF MMUSIC Çalışma Grubu

tarafından, Eylül 1999 da RFC 2543’de açıklanmıştır. SIP H.323 için alternatif ve

MGCP (Çoklu ortam Ağ geçidi Kontrol Protokolü - Multimedia Gateway Control

Protocol) gibi istemci/sunucu protokolleri için ise tamamlayıcı olarak düşünülmüştür.

SIP’e, sunucu ile çok az iletişim gerektiren veya etkileşim gerektirmeyen akıllı uç

noktalarında ihtiyaç duyulur. SIP bir ya da birden fazla katılımcının yer aldığı

oturumları kurmak, değiştirmek ve sonlandırmak için tasarlanmış bir kontrol

protokolüdür. Her uç nokta kendi işaretleşmesini yönetir. Bu yönetim, istemci ve diğer

uç nokta için de yapılır. En önemli nokta, MGCP aygıt kontrolü sağlarken SIP’in

oturum kontrolü sunmasıdır. Bu özellik SIP’e birçok üstünlük sağlar. Öncelikle, basit

mesaj yapısı, H.323’e göre arama ayarlarının daha az aşamada gerçekleşmesini sağlar.

Bu özellik donanım olarak benzer işletimi kullanan H.323’e göre performansı yükseltir.

SIP, H.323’e göre daha ölçeklenebilir bir yapıdır. Çünkü SIP yapısal olarak

sınıflandırılmış ve durumsuz bir arama modelidir. Asıl farklılık ve avantaj sağlayan

SIP’in Đnternet modeli bir protokol olmasıdır. ASN.1 (Özet Sözdizimi Gösterimi Bir-

Abstract Syntax Notation One) mesajlaşma yerine basit olan, HTTP/1.1 de

yapılandırılmış ASCII kullanır. Böylece, SIP mesajlaşmada şifre çözümünü ve hata

denetimi kolaylaştırmakta ve küçük ayarlamalar ile web tipi uygulamalar SIP servisini

destekleyebilmektedir. SIP, URL(Evrensel Kaynak Konumlandırıcı – Universal

Resource Locator), E.164 ( Kuzey Amerika Numaralandırma Plan Adreslemesi - North

American Numbering Plan Addressing) standartlarını tam desteklemektedir. Böylece,

SIP modelinde istemcinin e-posta adresi ile telefon adresi aynı olabilir ve karmaşık

oturumlarda değişik uç noktalar kendi aralarında iletişim kurabilirler.

SIP, kullanıcı yeri, kullanıcı yetenekleri, kullanıcı uygunluğu, arama kurulumu ve arama

karşılama gibi beş farklı ara yüzlü kurulum ve çoklu ortam iletişimlerini desteklemek

üzere modellenmiştir. SIP oturumunda bu ara yüzlerden her biri çözülebilir ve iki uç

nokta arasında iletilebilir.

Bununla beraber SIP mantığı bakımından uçtan uca bir protokoldür. Mantıksal kullanıcı

ve sunuculardan yapılanmıştır. Örneğin, tipik SIP kullanıcısı IP telefon, PC veya PDA,

SIP’i başlatmak için, kullanıcı aracılarını ve sonlandırmak için sunucu aracılarını

içerirler.

28

SIP mesajları basit istek ve yanıt kelimeleri içerir. Đstekler “metotlar” olarak adlandırılır.

Bu metotlar;

Kayıt - Sunucu ile geçerli yerleri kaydeder.

Çağrı - Arayan tarafından çağrının kabul edilmesi için yollanır.

Tanımlama - Arayan tarafından tanımlama için yollanır.

Hoşçakal - Đki taraf tarafından da aramayı sonlandırmak için yollanır.

Đptal - Arama daha fazla sürdürülmek istenmediğinde yollanır.

Seçenekler - Sorgu yetenekleri için yollanır.

2.1.9.1 SIP ve H.323 karşılaştırması

H.323 ve SIP benzer hizmetler sağladıkları için hangi çözümün kullanılacağı sorusu

düşünülebilinir. Her iki protokolünde birbirlerine karşı üstün oldukları özellikler vardır.

Hangisinin seçileceği uygulamaya göre değişebilir.

Đki protokolün karmaşıklığı karşılaştırıldığında zaman SIP’nin H.323’e göre çok daha az

karmaşık olduğunu görülmektedir (Schulzrinne ve Rosenberg 1998). H.323’ün

özellikleri SIP’e göre çok geniştir ve daha fazla elemanı tanımlamaktadır. Daha da

fazlası H.323 arama sinyallemesi ve kontrolü için ikili kodlama mekanizması

kullanırken, SIP kod çözülmesi (decode) ve hata ayıklaması (debug) daha kolay olan

yazılım temellidir. H.323’ün karmaşıklığının bir parçası, açıkça ayrılmayan birkaç

bileşen arasındaki etkileşimdir. H.323’te bir işi yapmanın birkaç yolu olabilir ve bazı

özellikler protokolün birkaç kısmında birden yer almaktadır.

SIP, SMTP ve HTTP gibi protokollerden gelen deneyimle daha da genişletilebilirdir.

Yeni özellikler protokole kolaylıkla eklenebilir. H.323 de bazı eklentilere izin verebilir

ama bunlar sadece protokol içinde önceden belirlenmiş yerlerde olabilir. SIP

bileşenlerinin kolaylıkla değiştirilebilmesi açısından modülerdir. Diğer tarafta H.323 ise

daha az modülerdir. Genellikle bir işin başarılması için çeşitli protokol bileşenlerinin

beraber çalışması gerektiğinden değiştirmek zor olmaktadır.

29

H.323 esasında tek bir LAN üzerinde kullanılmak için tasarlanmıştır. Yapılan

değişikliklerle bu sınırlama bulunmamaktadır, fakat H.323 döngülü mesajları

algılamada sorun yaşayabilir. SIP hiçbir zorluk çıkarmadan, geniş alan ağlarında, oluşan

döngüleri kolaylıkla fark ederek kullanılabilir. H.323 konferans boyutu büyüdüğünde de

bazı zorluklar yaşar. Bir MC kullanımı bir konferans için dar boğazdır (bottleneck).

Konferans boyutu büyümeyi sürdürdüğünde, neticede başka bir protokolün H.322’nin

kullanılması gerekir. SIP MC’ye benzer bir şeye sahip olmadığı için bu gibi

ölçeklenebilirlik sorunları da yaşamaz.

Protokoller arasında yetenek değiş tokuşlu hizmetler de, H.323 SIP’e göre daha fazla

kullanışlıdır. H.323, SIP’in harici protokollere güvendiği çeşitli konferans kontrol

hizmetlerine sahiptir. SIP tarafından sağlanan kişisel gezerlik hizmetleri, H.323’teki

benzer desteğe kıyasla daha geniştir.

2.2 Tıkanıklık

2.2.1 Tıkanıklık nedir?

Tıkanıklık her ağda olabilecek doğal bir olgudur. Ağdaki her kaynağın belli bir

kapasitesi vardır. Eğer bu kapasite o anda oluşan talebe cevap veremiyorsa tıkanıklık

oluşacaktır. Ağdaki temel kaynaklar tamponlar, gönderim hat kapasitesi ve işlemci

zamanıdır. Hat kapasitesi ağın en önemli bileşenidir ve hat kapasitesinin yetmemesi

durumu tıkanıklığın en temel halidir.

2.2.1.1 Tıkanıklı ğın oluşma sebepleri

Yönlendiriciye gelen paketlerle, yönlendiricinin yönlendirdiği paketlerin oranı yüksek

ve yönlendiricinin tampon kapasitesi bu gelen paketleri tutamayacak durumdaysa

paketler atılacaktır. Bu durum ağ tarafından tıkanıklık olarak adlandırılacaktır.

Yönlendiriciye gelen akışın hızını işleyebilecek büyüklükte bir yönlendirici işlem gücü

yoksa bu durum da tıkanıklığa neden olacaktır.

Tıkanıklık kendini besleyerek daha da kötü olabilir. Eğer yönlendirici hiç boş tampona

sahip değilse, yeni gelecek paketleri ihmal etmesi gerekecektir. TCP, ağ

uygulamalarında paketin ulaşması esasına dayanır ve ulaşmayan paketler için yeniden

30

gönderim yapılır. Paket ihmal edilince kaynak yönlendiricinin süresi dolar ve pek çok

kere yeniden gönderir. Paket geribildirim alana kadar atılamayacağından alıcı

tarafındaki tıkanıklık, göndericiyi normal olarak boşaltılacak bir tamponun serbest

bırakılmasından kaçınmak için zorlar.

Ağda bir yönlendiriciden yönlendirilmesi beklenen trafiğin çok olması durumu, taşınan

trafiğin az olması ile sonuçlanıyorsa bu durum tıkanıklık olduğunu gösterir (Pouzin, L.

1981). Tıkanıklık kontrolü, veri bağlantı, ağ ve taşıma katmanı olmak üzere üç farklı

katmanda yapılabilir. Bu katmanlarda yapılan denetimler ve düzeyleri Şekil 2.10’de

gösterilmiştir (Tanenbaum 1996).

Şekil 2.10 Tıkanıklık kontrol düzeyi

Sekme düzeyi (hop level) denetiminde, bilgisayar ağındaki iki komşu düğüm arasında,

yerel tampon tıkanıklıklarından kaçınılarak düzgün bir trafik akışı sağlanması söz

konusudur. Giriş-çıkış düzeyindeki (entry-to-exit level) denetim, daha çok kaynak ve

hedef düğümü arasındaki protokol olarak karşımıza çıkar ve çıkış düğümündeki tampon

tıkanıklığını önlemek amacındadır. Ağ girişi ya da diğer adıyla ağ erişimi (network

access) düzeyinde yapılan işlemin amacı, ağ içindeki tıkanıklık ölçümlerine dayanan dış

girdilerin kısılmasıdır (Gerla ve Kleinrock 1980).

31

2.2.2 Tıkanıklık giderme

Paket anahtarlamalı ağlarda gözlenen tıkanıklık problemleri, yönlendiriciye gelen

paketlerin erişebileceği tampon alanını artırmakla çözümlenebilir, ancak uzun

kuyrukları kabul etmek iyi bir çözüm değildir. Yönlendirici sonsuz miktarda belleğe

sahipse tıkanıklık daha da kötüleşecektir. Çünkü paketler kuyruğun önüne geldiklerinde

zaten süreleri (Time to live) bitmiş olacaktır ve tekrar gönderilecektir. Tekrar tekrar

gönderim yükü artıracaktır (Tanenbaum 1996). Bu, çok fazla bellek alanı olması

durumunun, çok az bellek alanı olmasından daha zararlı olduğunu göstermektedir (Jain

1990). Uzun kuyruklar zaman kaybıdır ve daha karmaşık denetim gerektirir. Bununla

birlikte, tıkanıklık sırasında oluşan problemler çözümlenmiş değil, sadece ertelenmiş

olur (Filipiak 1991).

Tıkanıklık sorununun giderilmesinde, çok hızlı bağlantılara sahip olmak bir çözüm

değildir. Çünkü hızlı yerel bilgisayar ağları, yavaş bağlantılarla birbirine bağlandığında,

bağlantı noktalarında tıkanıklık problemi oluşacaktır (Jain 1990).

Tıkanıklık problemi, sadece çok hızlı işlemcilerle de çözümlenemez. Ayrıca tüm

bağlantılar ve işlemciler aynı hıza sahip olsa bile tıkanıklık oluşabilir. Sonuçta,

tıkanıklık dinamik bir problemdir ve sadece statik yöntemlerin uygulanmasıyla

çözümlenemez (Jain 1990). Bu alternatifler tek başlarına uygulandığında bir sonuç

vermezler.

Tıkanıklığın gelişen bilgisayar teknolojisinde bir çözümünün olması mümkün değildir.

Artırılan tamponlar, hızlı ağ bağlantıları, yüksek hat kapasiteleri ve yüksek işlemci

gücüne sahip yönlendiriciler tıkanıklığı anlık olarak çözebilir ama zamanla yine benzer

tıkanıklık problemleriyle karşılaşmak mümkün olacaktır.

2.2.3 Paket anahtarlamalı ağlarda tıkanıklık

Paket anahtarlamalı ağlarda tıkanıklık kontrolü, ağ tasarımı ve araştırmasında hat

kapasitesinin artması ve yoğun ağ uygulamaları nedeniyle önemli bir öncelik

kazanmıştır.

32

2.2.3.1 Tıkanıklık tipleri

Değişik tıkanıklık kontrol algoritmalarının karakterize edilmesi ve karşılaştırılması

genellikle güçtür. Bu nedenle tıkanıklık kontrolü, global, yerel ve odaklanmış tıkanıklık

olarak üç tipte ele alınabilir (Filipiak 1991).

Global tıkanıklık, ağ kaynakları sunulan trafiği hizmete koymakta yeterli değildir.

Sürekli global tıkanıklık, genellikle ağ çok yüklü olduğu zamanlarda gözlenir. Aksi

takdirde, global tıkanıklığın periyotları, yerel ya da odaklanmış tıkanıklığın yayılması

ve daha önemli başarısızlıklardan kaynaklanmaktadır.

Yerel tıkanıklık, genelde bir donatı aksaklığından ya da seyrek gözlenen olayların neden

olduğu yerel trafik talebinden kaynaklanır. Tıkanmış bölgedeki trafik, yayılma

eğilimindedir. Sonuçta tüm ağı doldurabilir.

Odaklanmış tıkanıklık, bir bölgeye yönelmiş trafiğin çok fazla olması durumunda

gözlenir.

2.2.3.2 Tıkanıklık kontrol yakla şımları

Bu alandaki mevcut literatür tıkanıklık kontrol yaklaşımlarını iki kategoride

sınıflandırmıştır: tıkanıklık önleyici yaklaşımlar (congestion avoidance) ve tıkanıklık

düzeltici yaklaşımlar (congestion recovery). Böyle basit bir sınıflandırma sadece farklı

gruplara ayrılmış yaklaşımlar arasındaki ortak noktaların genel görünümünü verir.

Tıkanıklıktan kaçınmanın stratejisi, ağ işleyişini maksimum güçte ya da yakınında

tutmaktır. Böylece tıkanıklık oluşmaz. Tıkanıklık iyileştirmenin amacı, ağ işleyişini

tıkanıklık oluştuktan sonra normal durumuna getirmektir. Tıkanıklık iyileştirilmesi

olmazsa, tıkanıklık oluştuğunda ağ çöker. Yani, tıkanıklık önleme stratejisi oluşturulsa

bile tıkanıklık iyileştirme stratejisine de ihtiyaç vardır.

Tıkanıklık kontrol algoritmalarındaki genel kıstas çıkışın gecikmeye oranı olarak

tanımlanan gücü maksimize etmektir (Yang ve Reddy 1995).

33

2.2.3.3 Kontrol teorisine dayanan sınıflandırma

Tıkanıklık algoritmalarının iyi bir şekilde organizasyonu için 1995 yılında Yang ve

Reddy tarafından tıkanıklık kontrol algoritmalarını açık döngü (open loop) ve kapalı

döngü (closed loop) diye ikiye ayıran bir sınıflandırma geliştirildi. Bunların ağaç

yapısındaki alt kategorileri Şekil 2.11’de gösterilmektedir.

Şekil 2.11 Tıkanıklık kontrol algoritmaları

2.3 QoS

QoS (Servis Kalitesi-Quality of Service), Frame Relay, ATM (Asenkron Transfer Modu

- Asyncronous Transfer Mode), Ethernet ve 802.1 ağları, SONET ve bu altyapıların

hepsini ya da birkaçını kullanan IP yönlendirmeli ağları içeren çeşitli teknolojilerdeki

trafik için daha iyi servis yeteneğini işaret eder. QoS un ana hedefi, tahsis edilmiş bant

genişliği, kontrollü gecikmenin değişimi (jitter) ve gecikme (bazı gerçek zamanlı ve

etkileşimli trafik tarafından ihtiyaç duyulur) ve gelişmiş kayıp karakteristiklerini içeren

önceliği sağlamaktır. Bir başka önemli olan konu ise bir akış için sağlanan önceliğin

diğer akışları engellememesidir. QoS teknolojileri yerleşke, WAN ve servis sağlayıcı

ağlarındaki gelecekteki iş uygulamalarında kullanılmak üzere temel yapıtaşlarını

oluştururlar.

34

Kaynaklar arası kontrol – Kullanılan kaynakların (hat kapasitesi, donanım, geniş alan

imkânları ve diğerleri) kontrolü ağ yöneticisine aittir. Örnek olarak, bir omurga

hattındaki FTP (Dosya Transfer Protokolü – File Transfer Protokol) transferleri

tarafından kullanılan hat kapasitesi sınırlanabilir, ya da önemli veritabanı erişimlerine

öncelik tanınabilir.

Ağ kaynaklarının daha etkin kullanımı – Ağ analiz yönetim ve araçları kullanılarak ağın

ne amaçla kullanıldığını ve istenilen trafiğe öncelik verildiği gözlenebilir.

Uygun hale getirilmiş servisler – QoS tarafından sağlanan kontrol ve görünürlük

Internet servis sağlayıcılara, müşterilere dikkatlice uygun hale getirilmiş servis

dereceleri sunmalarını sağlar.

Görev-kritik uygulamaların birlikteliği – QoS teknolojileri WAN için en önemli görev-

kritik uygulamalar tarafından etkin kullanımını sağlar. Bu sayede zamana hassas çoklu

ortam ve ses uygulamalarının gereksinim duyduğu hat kapasitesi ve minimum

gecikmeler sağlanır. Diğer uygulamalara görev-kritik trafiğine bir etki etmeden servis

verilmesi sağlanılır.

Gelecekte tamamen entegre ağ tesisi – Ağda QoS teknolojilerini uygulamak yakın

gelecekteki, tamamen entegre çoklu ortam ağına doğru ilk adımdır.

2.3.1 QoS kavramları

Temel olarak QoS belirli akışlara daha iyi servis verilmesini sağlar. Bu, akışın

önceliğini arttırmak ya da başka bir akışın önceliğini kısıtlamak ile olur. Tıkanıklık-

yönetim araçları kullanırken kuyruklara servisi ya da kuyruk işlemini farklı yöntemlerle

yaparak akışın önceliğinin artırılması denebilir. Tıkanıklığı engellemek için kullanılan

tıkanıklık yönetim aracı yüksek öncelikli akışlardan önce düşük öncelikli akışları

kullanım dışı bırakarak önceliği yükseltir. Düzenleme ve şekil verme, diğer akışların hat

kullanımını sınırlandırarak öncelik sağlar. Hat etkinliği araçları büyük akışları

sınırlandırarak küçük akışlara öncelik tanır. QoS kullanarak bir servise öncelik

tanımlama işlemi birden fazla yöntemle yapılabilir. Bu yöntemlerin hemen hepsi aynı

sonucu elde edebilir. Sonuçlara farklı QoS araçları kullanılarak da ulaşabilineceğini

göstermektedir. Hangi QoS yönteminin kullanılacağı trafiğe bağlıdır. Ağda kullanılan

35

uygulamaların tespit edilmesi ve önceliklendirilmesi gerektiği açıktır. QoS araçları

birçok tıkanıklık problemini bastırmaya yardımcı olabilir. Yine de çoğu zaman sağlanan

hat kapasitesi için çok fazla trafik olabilir. Đster istemez bu durum dar boğazlara neden

olacaktır. Dar boğazı çözmek için QoS kullanılabilir. Yine de bu çözüm paket

kayıplarının son bulması anlamını taşımaz. Aşırı yoğun trafikte QoS kullanılmış olsa

bile hattın taşıyacağı bilgi, hattın fiziksel kapasitesi kadar olacaktır.

2.3.2 Temel QoS mimarisi

Temel mimari, QoS uygulamasını Şekil 2.12’de gösterilen şekilde üç ana parçaya böler.

Sondan sona ağ elemanlarında QoS u koordine etmek için QoS tanımlama ve işaretleme

teknikleri

Tek ağ elemanı dahilinde kuyruk, planlama ve trafik şekillendirme araçları gibi QoS

Ağ boyunca sondan sona trafiği kontrol ve idare etmek için QoS poliçeleri, yönetim ve

muhasebe fonksiyonları

Şekil 2.12 Basit QoS uygulaması

2.3.2.1 Sondan sona QoS seviyeleri

Servis seviyeleri, ağın sondan sona ya da kenardan kenara özel ağ trafiği tarafından

ihtiyaç duyulan servisi karşılama kabiliyeti anlamına gelen, QoS kabiliyetlerini işaret

eder. Bu servisler, servisin özel hat kapasitesi, gecikme, gecikmenin değişimi ve kayıp

karakteristiklerine ne kadar bağlı olduğunu tanımlayan QoS kesinlik seviyelerine göre

36

farklılık gösterebilirler. Şekil 2.13’de görülmekte olan heterojen bir ağda sağlanabilen

üç temel sondan sona QoS seviyeleri şunlardır:

Şekil 2.13 Sondan sona QoS servisleri

En iyi çaba servisi – QoS’un yoksunluğu olarak da bilinen, en iyi çaba servisi garantisi

olmayan temel bağlantıdır. Bu en iyi akışlar arasında fark olmayan FIFO (Đlk gelen ilk

çıkar – First In, First Out) sorguları ile karakterize edilir.

Farklılaştırılmış servis (soft QoS) – Bazı trafikler diğerlerine göre daha önceliklidir

(daha hızlı işleme, daha fazla ortalama hat kapasitesi ve daha az ortalama kayıp oranı).

Bu istatistiksel bir tercihtir, bir garanti değildir. Bu, trafiğin sınıflandırılması ve PQ,

CQ, WFQ ve WRED gibi araçların kullanılması ile sağlanır.

Garantili servis (hard QoS) -Bu, özel trafik için ağ kaynaklarının mutlak tahsisidir. Bu,

RSVP ve CBWFQ araçları ile sağlanır. Hangi servis tipinin ağa uygulanmasının daha

uygun olduğu birçok etmene bağlıdır:

Kullanıcının çözmeye çalıştırdığı uygulama ya da problem: Her üç servis tipi belirli

uygulamalar için uygundur. Bu, kullanıcının farklılaştırılmış ve daha sonra garantili

servise geçmesi anlamına gelmez. Farklılaştırılmış servis – veya en iyi çaba servisi –

kullanıcının uygulama ihtiyaçlarına uygun olabilir.

37

Kullanıcıların altyapılarını yenileme oranı. Garanti edilmiş servisi sağlamak için

gereken farklılaştırılmış servisleri sağlamak için gerekli teknoloji için, farklılaştırılmış

servislerin gereksinimini de kapsayan doğal bir yenileme yolu vardır.

Garantili servisin uygulanıp yerleştirilme masrafı farklılaştırılmış servise göre daha

fazladır.

2.3.3 Servis kalitesinin tipleri

2.3.3.1 CoS

CoS (Servis Sınıfı - Class of Service) benzer trafik tiplerini (ör: e-posta, video akışı, ses,

büyük doküman transferi) gruplandırarak, her grubun kendi servis önceliği seviyesi ile

bir sınıf tanımlayarak ağdaki trafiği yönetme yoludur. QoS trafik yönetiminden farklı

olarak, CoS teknolojileri hat kapasitesi, teslim zamanı gibi servislerin seviyelerini

garanti etmezler, sunduğu sadece “en iyi çaba”dır. Bir taraftan CoS teknolojisi kolay

yönetilebilir ve ölçeklendirilebilirdir. CoS’u “kaba taneli” trafik kontrolü olarak

nitelendirirsek QoS “ince taneli” trafik kontrolü olarak anılmalıdır.

Üç ana CoS teknolojisi vardır:

802.1p Seviye 2 Etiketleme

ToS (Servis Tipi – Type of Service)

Ayrık Servisler (DiffServ)

802.1p Seviye 2 Etiketleme ve ToS ikinci seviye çerçeve başlığındaki 3 biti önceliği

belirtmek için kullanır. Trafiği yönetmek için 3 bit fazla seçenek sunmamasından dolayı

IETF çalışma grubu, Ayrık Servisler (DiffServ) adı verilen yeni bir protokol

geliştirmiştir. Ayrık Servisler öncelik etiketinden daha farklı bir yaklaşım ile paketleri

yönetir. PHB (Her atlamadaki davranış-Per Hop Behaviour) adı verilen ve verilen

paketin nasıl iletileceğini içeren bir işaret kullanır. PHB hat kapasitesi, kuyruk teorisi ve

kullanım dışı bırakma kararları cinsinden kısmi servis seviyelerini tanımlar.

38

2.3.3.2 ToS

ToS (Servis Tipi –Type Of Service) RFC 791 içinde belirtilmiş olup, arzulanan servis

kalite özet parametrelerinin belirtilmesini sağlar. Bu parametreler kısmi bir ağ üzerinden

datagramı iletirken seçilen asıl servis parametrelerine kılavuzluk ederler. Birçok ağ,

yüksek öncelikli trafiğin diğer trafiklerden (genellikle yüksek yük altında sadece belli

öncelikteki trafiği kabul ederek) daha önemli olduğu gibi davranan servis önceliğini

sağlar. Ana seçim düşük-gecikme, yüksek güvenirlik ve yüksek-kullanım arasında olur.

Bu bilgi IP başlığında iletilmektedir (Şekil 2.14). Bu başlık bilgisinin ToS alanının

ayrıntısı Şekil 2.15’de görülebilir.

Şekil 2.14 IP başlığı

0 1 2 3 4 5 6 7 Öncelik (Precedence)

Gecikme (Delay)

Kullanım (Throughput)

Güvenirlik (Reliability)

Rezerve (Reserve)

Rezerve (Reserve)

Şekil 2.15 IP başlığındaki ToS alanı ayrıntısı

IP başlığında iletilen ToS alanındaki bilgiler Çizelge 2.2’de görülmektedir.

Çizelge 2.2 Servis tipi alan bilgileri

Bit 0-2 Öncelik (precedence) (Çizelge 2.3 )

Bit 3 0=Normal Gecikme 1=Dü şük Gecikme

Bit 4 0=Normal Kullanım 1=Yüksek Kullanım

Bit 5 0=Normal Güvenirlik 1=Yüksek Güvenirlik

Bit 6-7 Rezerve

Gecikme, kullanım ve güvenirlik belirteçlerinin kullanımı servisin maliyetini arttırabilir.

Birçok ağda, bu parametrelerden biri için daha iyi performans, bir başkasının üstündeki

39

daha kötü performans ile birleştirilmi ştir. Alışılagelmeyen durumlar haricinde bu

belirteçlerin ikisi ya da üçü ayarlanmalıdır.

ToS, datagramın internet sistemi boyunca iletimi esnasında davranışını belirlemek için

kullanılır.

Ağ kontrol öncelik tayini, sadece ağ içerisinde kullanılacak şekilde tasarlanmıştır. Bu

tayinin asıl kullanım ve kontrolü her ağ içindir. Ağlar arası kontrol tayini ağ geçidi

kontrol yaratıcıları tarafından kullanılması için tasarlanmıştır. Eğer bu öncelik

tayinlerinin esas kullanımı kısmi ağ ile ilgili ise bu öncelik tayinlerinin erişimini kontrol

etmek ve kullanmak da ağın sorumluluğudur.

Çizelge 2.3 IP öncelik değerleri

Öncelik De ğeri Anlamı 000 (0) Sıradan veya en iyi çaba ( Routine or Best

Effort) 001 (1) Öncelik (Priority) 010 (2) Derhal (Immediate) 011 (3) Anlık (Flash) 100 (4) Anlık üstüne bindirme (Flash Override) 101 (5) Kritik (Critical) 110 (6) A ğlar arası Kontrol (Internetwork

Control) 111 (7) A ğ Kontrolü (Network Control)

2.3.3.3 DSCP

DSCP (Ayrık Servisler Kod Noktası – Differentiated Services Code Point), IP Öncelik

alanı 8 ya da 23 tane olası değere sahip olabilir. Yönlendiriciler bu değerlerin ikisini (6

ve 7) yönlendirme protokolü trafiği için kullanırlar. Bu yüzden kullanıcı trafiğinin

önceliklendirilmesi için 6 farklı değer kullanılabilir. ToS bitleri tipik olarak

kullanılmadığı için IP öncelik alanı ToS alanını da kapsayarak 3 bitten 6 bite

çıkarılmıştır. Şekil 2.16’da DSCP ile ToS alanlarının karşılaştırılması görülmektedir.

Şekil 2.16 DSCP ve ToS alan karşılaştırması

40

Bu yeni alana DSCP alanı denir. Bu şekilde trafiğin önceliklendirilmesi için 64 ya da 26

olası değerin kullanılabilmesi anlamına gelir. Olası 64 DSCP değerine rağmen tipik

olarak sadece 14 tanesi kullanılır. Ayrık Servis kod noktası değerleri Çizelge 2.4’de

görülmektedir.

Çizelge 2.4 Ayrık servis kod noktası değerleri

DSCP Değeri

Anlamı Kullanım Dı şı Kalma Olasılı ğı

Eş De ğer IP Öncelik Değeri

101 110 (46)

Yüksek Öncelik Acele Đletme

Yok 101 – Kritik

000 000 (0)

En Đyi Çaba Yok 000 – Sıradan

001 010 (10)

AF11 Dü şük 001 – Öncelik

001 100 (12)

AF12 Orta 001 – Öncelik

001 110 (14)

AF13 Yüksek 001 – Öncelik

010 010 (18)

AF21 Dü şük 001 – Derhal

010 100 (20)

AF22 Orta 001 – Derhal

010 110 (22)

AF23 Yüksek 001 – Derhal

011 010 (26)

AF31 Dü şük 011 – Anlık

011 100 (28)

AF32 Orta 011 – Anlık

011 110 (30)

AF33 Yüksek 011 – Anlık

100 010 (34)

AF41 Dü şük 100 – Anlık üstüne bindirme

100 100 (36)

AF42 Orta 100 – Anlık üstüne bindirme

100 110 (38)

AF43 Yüksek 100 – Anlık üstüne bindirme

DSCP değerinin ilk 3 bitinin IP öncelik bitleri olduğuna dikkat edilmelidir. IP Öncelik

000 DSCP değeri 000 000 olarak belirtir ve her ikisi de “en iyi çaba teslimi” temsil

eder. IP Öncelik 101 (Kritik), DSCP değeri olarak 101 110 u belirtir. Geri kalan 4 IP

öncelik değerleri 3 ayrı DSCP değeri ile ilişkilendirilmiştir. Ek 3 bitlik kısım ise dört

AF (sigortalanmış iletim-Assured Forwarding) sınıflarından biri içindeki atma

olasılığını tanımlamak için kullanılır (Parkhurst W. 2004).

41

2.4 SNMP

SNMP (Basit Ağ Yönetim Protokolü -Simple Network Management Protocol), IETF

(Đnternet Mühendisliği Görev Kuvvetleri-Internet Engineering Task Force) tarafından

geliştirilmi ş ve ağ cihazlarının görüntüleme ve yönetiminde kullanılan bir protokoldür.

Bir SNMP yönetilebilir ağ üç temel ekipmandan oluşur (Şekil 2.17) :

Yönetilen Aygıt: Üzerinde SNMP Aracının çalıştığı ve cihaz bilgilerini NMS’lere (Ağ

Yönetim Sistemi- Network Management System) SNMP aracılığı ile ileten cihazlardır.

Yönlendirici, anahtar, yazıcı bunlara örnektir.

Aracı: Yönetilen aygıt üzerinde bulunan ve cihaz bilgilerini SNMP formatına çevirerek

NMS e ileten bir yazılım modülüdür.

NMS: Yönetilen aygıtları izlemek ve kontrol etmek için kullanılan yazılımdır.

Şekil 2.17 SNMP işleyişi

SNMP sunucu/istemci ilişkisine dayanan bir protokoldür. NMS, sunucu tarafındaki

SNMP aracısıyla UDP kullanarak 161. porttan bağlantı kurup, cihazın işlemlerini

yapmasını sağlar ya da cihazın durumu hakkında bilgi edinir. SNMP ile bilgisayar,

modem, yönlendirici, yazıcı gibi cihazlar kontrol edilebilir. SNMP Aracısı tarafından

kontrol edilen MIB (Yönetim Bilgi Merkezi-Management Information Base) adı verilen

42

bir veritabanı bulunur. Bu veritabanında istatistiksel ve kontrol verileri bulunur. Bu

MIB’nin içinde standart değerler olduğu gibi üretici firmalara özel ayrılmış değerler de

bulunabilir.

Ağ Yöneticisi tarafından sunucuya yollanan ve SNMP OID (değişken tanımlayıcılarını -

Object Identifier) içeren direktifler sayesinde değişkenlerin değerleri okunabilir ya da

bu değişkenlere yeni bir değer atanabilir.

Özel MIB değişkenleri kullanılarak SNMP aracıları köprü, ağ geçidi ve yönlendirici

gibi birçok özel cihaz üzerinde çalışabilir. Bu özel değişken tanımlarının yazımında

ASN.1 kullanılır ve bu sayede istemci üzerinde çalışan programlar bu MIB değişkenleri

hakkında bilgi edinirler.

2.4.1 SNMP ana komutları

Yönetilen aygıtlar aşağıdaki dört SNMP komutu ile izlenir ve kontrol edilir:

”read (okuma)” komutu NMS tarafından cihazları izlemek için kullanılır. NMS, bu

cihazdan gelen cevapları kendi içinde yorumlar.

”write (yazma)” komutu NMS tarafından cihazları kontrol etmek için kullanılır. Bu

sayede cihaz üzerinde bir ayar değiştirilebilir

”trap (yakalama)” komutu yönetilen aygıt tarafından, meydana gelmiş kayda değer

değişiklikleri NMS e bildirmek için kullanılır. Trap mesajları UDP 162. port üzerinden

gönderilir

“traversal (gezici)” işlemler ise NMS tarafından, yönetilen aygıtın hangi değişkenleri

MIB sinde barındırdığını öğrenmek için ya da ardışık bir şekilde tablolardan veri almak

için kullanılır. Örnek olarak yönlendirme tablo bilgileri verilebilir.

2.4.2 SNMP sürümleri

Günümüzde kullanılmakta olan 3 SNMP sürümü bulunmaktadır.

43

2.4.2.1 SNMPv1

1990 yılında Case ve diğerleri RFC 1157’de SNMPv1’i tanımlamışlardır. SNMPv1

UDP, IP, CLNS (Bağlantısız Ağ Servisi - Connectionless Network Service), DDP

(Datagram Gönderim Protokolü (Datagram Delivery Protocol) ve IPX (Ağlararası Paket

Değişimi - Internetwork Packet Exchange) protokolleri üzerinde çalışabilir. SNMP

özetle bir sorgu-cevap protokolüdür ve bu işlem, GetNext, Set ve Trap protokol

işlemleri aracılığı ile olmaktadır. Get, NMS tarafından bir ya da daha fazla nesne

bilgisini almak için kullanılır. Eğer yönetilen aygıt üzerinde çalışan aracı, istenen

verilerin hepsini cevaplayamıyor ise NMS’e bir cevap yollamaz. GetNext işlemi tabloda

ya da aracı listesindeki bir sonraki değeri almak için kullanılan işlemdir. Set işlemi ile

yönetilen aygıtın MIB’i içindeki değerler değiştirilebilir. Trap işlemi ise NMS’e

yönetilen aygıt tarafından, meydana gelmiş kayda değer değişiklikleri bildirmek için

kullanılır.

2.4.2.2 SNMPv2

SNMPv2 için SNMPv1’in evrimleşmiş hali de denebilir. 1993 yılında Case ve diğerleri

tarafından ortaya çıkarılmış bir protokoldür. SNMPv2 ile bazı ek protokol işlemleri

tanımlanmıştır. Get, GetNext ve Set işlemleri SNMPv1 ile aynı olmasına rağmen

SNMPv2 de Trap işlemi SNMPv1’e göre daha farklı bir formattadır.

SNMPv2, SNMPv1’e göre iki yeni protokol işlemi daha içermektedir. GetBulk işlemi

ile NMS’e büyük miktarda veri yollamak mümkündür. Eğer istenen veri bir paket

boyutundan fazla ise aracı tarafından art arda birkaç paket yollanır. Inform işlemi ise bir

NMS’in Trap mesajlarını ağdaki başka bir NMS’e yollayabilmesi için kullanılır.

SNMPv1’den farklı olarak eğer aracı istenen değerlerin hepsini sağlayamıyorsa cevap

vermemek yerine sağlayabildiği cevapları NMS’e yollar.

2.4.2.3 SNMPv3

SMNPv3, SNMPv2c’de iptal edilen güvenlik geliştirmelerini içerir. Sürüm 3 mesajları

güvenli olmayan, doğrulanmış fakat gizli olmayan, ya da doğrulanmış ve gizli

formatlarını kullanabilirler. Doğrulanmış-gizli olmayan tipte doğrulama zaman

44

etiketleriyle ve derleme ile sağlanır. Doğrulanmış-gizli’de ise tüm mesaj şifrelenir

(Harrington vd. 1998).

Çizelge 2.5 SNMP sürümleri karşılaştırması

SNMPv1 SNMPv2 SNMP v3

Ek protokol i şlemleri

Yok Var Var

Güvenlik ve uzaktan yapılandırma

Yok Yok Var

Eri şim kontrolü Yok Yok Var

MD5, DES, and SHA encryption

Yok Yok Var

2.4.3 SNMP uyumluluk yöntemleri

SNMPv1 ile SNMPv2 arasındaki PDU (Protokol Veri Birimi – Protocol Data Unit) ve

işlem farklılıklarının üstesinden gelebilmek için Vekil Aracısı (Proxy Agent) ya da

ikidilli NMS kullanılabilir.

2.4.3.1 Vekil aracısı

Cihazlar üzerinde bulunan SNMP aracıları sürümlerine göre farklı bilgiler elde ederler.

Bu bilgilerin sürümler arasında dönüşümünü yapmak için bütün sürümler ile uyumlu

çalışabilen aracıdır.

Bir SNMPv2 aracı SNMPv2 mesajlarını SNMPv1 haline dönüştürme işini yapar. Bu

işlem şöyle gerçekleşir:

SNMPv2 NMS, SNMPv1 cihaz için bir işlem oluşturur.

NMS bilgiyi SNMPv2 Vekil Aracıya gönderir.

Vekil Aracısı ise Get, GetNext, ve Set işlemlerini, üzerinde değişiklik yapmadan olduğu

gibi SNMPv1 aracıya yollar.

GetBulk işlemleri Vekil Aracısı tarafından GetNext işlemlerine dönüştürülerek

SNMPv1 aracıya yollanır.

45

Yine aynı şekilde SNMPv1 aracıdan alınan Trap işlemleri de Vekil Aracısı tarafından

SNMPv2 Trap işlemlerine dönüştürülerek NMS’e iletilir.

2.4.3.2 Đkidilli NMS

Đkidilli sistemler hem SNMPv1 hem de SNMPv2 yi desteklerler. Bu işlem için ilk önce

Đkidilli NMS in yönetim kısmı aracı ile iletişim kurmalıdır. Daha sonra NMS

veritabanına bakarak aracının SNMPv1 veya SNMPv2 desteklediğine karar verir. Bu

işlemden sonra NMS, aracıya anlayacağı sürümde işlemleri gönderir.

2.4.4 SNMP’nin avantaj ve dezavantajları

Đlginçtir ki ne RFC’lerde ne de başka kaynaklarda SNMP’nin neden “ping”, “rsh”,

“netstat” gibi bazı diğer uygulamalardan daha kullanışlı olduğu açıklanamamıştır. Fakat

günümüzde SNMP yönetim programı üreten firmalar geleneksel otomasyona bağlanmış

işlemler yerine grafik ara yüzlü, tek bir fare hareketiyle konfigüre edilebilen yazılımlara

ağırlık vermişlerdir, bu yüzden de SNMP günümüzde daha kullanışlı bir hale gelmiştir.

SNMP deki güvenlik sorunları yüzünden kötü niyetli kişiler tarafından SNMP ile

yönetilebilen cihazlarda değişiklik yapılabilir. SNMP mesajlarında topluluk adı denilen

kısım düz yazı olarak gönderilir. Herhangi bir dinleyici (sniffer) ile bu topluluk adları

kolaylıkla öğrenilebilir. SNMPv2 de bir kodlama işlemi yapılmaya çalışıldıysa da

1990’ların sonuna doğru bu engel de kolaylıkla aşılabilir hale gelmiştir. SNMPv3 de ise

bu daha güvenli bir hale gelmiştir.

SNMP istekleri ve gelen cevaplar arasında bir gecikme olmaktadır. Yani anlık bir

izleme pek mümkün değildir. Eğer izlenen cihaz yerel ağ üzerinde ise bu gecikmenin

önemsenmeyecek kadar düşük olacağı öngörülebildiği gibi eğer arada birkaç hop var ise

ve büyük miktarlarda veri toplanıyorsa SNMP işlemleri UDP üzerinden yapıldığından

bu konuda biraz sıkıntı yaşanabilir.

2.4.5 SNMP standardı

SNMP ye birçok yönden bakılabilir. Bu bakış açılarından biri de SNMP’yi üç farklı

standardın birleşimidir:

46

Mesaj Formatı: SNMP, UDP mesaj formatını kullanan bir standart iletişim protokoldür.

Yönetilen Nesne Dizileri: SNMP, “SNMP Objects” adı verilen ve bir cihazdan sorgular

sayesinde alınabilen standart değerler bütünüdür. Bu standart özellikle TCP, IP, UDP ve

cihaz ara yüzlerini izlemede kullanılan değişkenleri içerir. Her değişkenin kendine özgü

bir adı ve aynı şekilde nümerik bir gösterimi vardır.

Nesne Ekleme Yöntemi: Standart nesnelere ilave olarak cihaza göre spesifik

değişkenlerin oluşturulabilmesi SNMP’nin popüler olmasının tek nedeni olarak kabul

edilebilecek bir özelliktir.

2.4.5.1 Mesaj formatı

Dört çeşit SNMP mesajı vardır:

Get: Bu tip mesaj formatı ile cihazın performans ve durum bilgilerine ulaşılabilir.

Cihaza giriş yapılmadığı veya bir TCP bağlantısı kurulmadığı için veriler alınırken diğer

yöntemlere göre daha az işlemci gücüne ihtiyaç duyulacağı açıktır.

GetNext: Bu tip mesaj formatı ile cihaz üzerindeki değişkenlerin adları ve değerlerini

öğrenmek için bütün değerler tespit edilir. Bu işlem ise ilk SNMP nesnesinin alınmasını

takiben diğer nesnelerin, ta ki en son nesne bilgisi alınıp da bütün nesnelerin tespit

edildiğini belirten bir hata mesajı alınana kadar “get-next” adı verilen işlemle tekrar

edilmesi ile yapılır.

Set: Bu tip mesaj formatı ile ara yüzleri devre dışı bırakma, kullanıcıların bağlantılarını

koparma, kayıtları sıfırlama gibi işlemler yapılır. Bu da ağ cihazlarını SNMP üzerinden

kontrol etme imkanı sağlar.

Trap: Bu tip mesaj formatı ise cihazda herhangi bir problem olduğunda aracı tarafından

istemciyi haberdar etmek amacıyla asenkron olarak gönderilir. Bunun için cihazların

SNMP trap mesajlarını, SNMP trap bilgilerini alabilen bir ya da daha çok cihaza

yayınlayacak şekilde konfigüre edilmesi ile olabilir.

47

2.4.5.2 Yönetilen nesneler

Standart MIB’nin içinde barındırdığı değerler 1991 yılında McCloghrie ve Rose

tarafından RFC 1213’te tanımlanmıştır. MIB içindeki her değerin kendine özgü bir adı

olmasının yanı sıra bir de sayısal gösterimi vardır. Örneğin “sysUpTime” değişkeninin

sayısal gösterimi 1.3.6.1.2.1.1.3.0 dır.

2.4.5.3 Nesne ekleme yöntemi

Bu yöntem ile yeni bir MIB derlenirken yeni nesneler eklenebilir. Bu nesne tanımları

ASN.1 yazım biçimine uymalıdır. SNMP çalıştırılan bir cihazın MIB’i sabittir, herhangi

bir ekleme ya da modifikasyon yapılamaz. Sadece yönetim yazılımının MIB’i

değiştirilebilir (McCloghrie ve Rose 1990).

2.4.6 MIB

SNMP’nin efektif kullanımı için okunan ve değiştirilebilen nesnelerin bulunduğu

MIB’in ayrıntılıca bilinmesi gerekmektedir.

MIB, tıpkı bir diskteki dizinlerin oluşturduğu yapı gibi ağaç biçiminde bir tasarıma

sahiptir. En üst seviyede ISO “internet” bulunur ve 4 kola ayrılır. “mgmt” kolu bütün ağ

cihazlarında bulunan standart nesneleri, “private” kolu ise üretici firmanın özel

nesnelerinin bulunduğu bölgedir. Bunlardan başka “experimental” ve “directory” adlı

kollar da vardır, fakat anlamlı veri ya da nesnelerden yoksun bölgelerdir (Şekil 2.22).

48

Şekil 2.18 MIB ağaç yapısı

Yukarıda anlatılan ağaç yapısı SNMP için olmazsa olmaz bir parça olmasına karşın,

bununla beraber en önemli kısımlar olarak yapraklar olarak da tabir edilen ve cihazın

yönetimi ile ilgili bilgileri sağlayan kısımlar vardır. Genel olarak bu yapraklar iki

kısımda incelenebilir (McCloghrie ve Rose 1988).

2.4.6.1 Ayrık MIB nesneleri

Birçok MIB nesnesi ayrık biçimdedir. MIB nesnesinin ayrık biçimde olması

kullanıcının sadece nesne adını bilmesini gerektirir. Genellikle bu nesneler ağ cihazının

performansı hakkında kısmi bilgi vermek için oluşturulan özet değerlerdir. Uzantıları

aksi belirtilmedikçe “.0” olarak kabul edilebilir.

2.4.6.2 Tablo üzerinde MIB nesneleri

SNMP tabloları, diziler halinde olan nesneleri tutar. Örnek olarak standart bir nesne

olan ve ara yüzlerin tanım bilgilerinin bulunduğu “ifDescr” nesnesi cihaz üzerindeki her

ara yüz için bir değişken bulundurur.

2.4.6.3 MIB nesne tipleri

MIB nesne tipleri birkaç çeşittir. Bunlardan başlıcalar aşağıda tanımlanmıştır:

49

Text Type: “DisplayString” olarak tanımlanan nesnelerdir. Maksimum 256 karakter

boyutunda olmalıdır. “sysDescr”, “ifDescr” bu tip nesnelere örnektir.

Counter Type: “Counter” olarak tanımlanan ve sadece artan nesnelerdir. Bu nesne tipi

MIB de en çok bulunan nesne tipidir. Bu nesneler maksimum değerlerine kadar artabilir

ve asla sıfırdan düşük olamaz “ipInReceives”, “snmpInPkts” bu tip nesnelere örnektir.

Gauge Type: “Gauge” olarak tanımlanan ve artıp azalabilen numerik nesnelerdir.

Standart MIB içerisinde nadir bulunur. “tcpCurrEstab” bu tip nesnelere örnektir.

Integer Type: “Integer” olarak tanımlanan ve hem pozitif hem de negatif değerler

alabilen nesne tipleridir. Her ne kadar Gauge ve Counter tipleri bu tip nesnelerin

yerlerini almışsa da bazı firmaların “private” MIB lerinin içinde bulunabilirler.

EnumVal Type: “Enumerated Value” olarak tanımlanan ve bir yazıyı bir sayı ile eşleyen

nesne tipidir. Bu nesne tipi de standart MIB de çokça bulunur. Genel anlamda biçimi

yazı(no) şeklindedir. Örnek olarak “ifAdminStatus” nesnesindeki “up(1)”, “down(2)”,

“testing(3)” değerler verilebilir.

Time Type: “TimeTicks” olarak tanımlanan ve geçen süreyi gösteren nesnelerdir.

Hassasiyetleri saniyenin 1/100 ü kadardır. HH:MM:SS:hh biçimindedir. “sysUpTime”

nesnesi buna örnek olarak verilebilir.

Object Type: “Object” olarak tanımlanan ve başka bir SNMP nesnesinin tanımlama

bilgisini içeren nesnelerdir. Eğer obje nesnesi kullanılarak MIB derlenirse eski

değerinin yerinde obje nesnesinin değeri görülecektir. “sysObjectID” bu tür nesnelere

örnektir.

IPAddr Type: “IP address” olarak tanımlanan ve ağ cihazının IP bilgilerini tutan

nesnelerdir. “ipRouteDest”, “ipRouteNextHop”, “ipRouteMask” bu tip nesnelere

örnektir.

PhysAd Type: “Physical Address” olarak tanımlanan ve MAC adreslerinin tutulduğu

nesnelerdir. “hex:” ön eki ile kullanılır. “ifPhysAddress” bu tip nesnelere örnektir.

50

String Type: “String” olarak tanımlanırlar. Eğer sadece ASCII karakterlerden oluşuyor

ise yönetim programları bu nesneleri “text string” olarak gösterirler. Yoksa başına

“hex:” ön eki getirilerek gösterilir. Oek rastlanılan bir nesne tipi olmamasına rağmen

üretici firmalar tarafından MIB nin “private” kolunda tanımlanmış olabilirler.

Table Type: Tablo girdilerini tutarlar. Bu nesnelerde tablo nesnelerinin bulunduğu

“Entry” klasörleri tutulur.

Branch Type: MIB nin diğer dallarının, tablolarının ve ayrık nesnelerinin bilgisi tutulur.

2.4.6.4 MIB nesne erişim seviyeleri

Her SNMP nesnesinde “read-only (salt-okunur)” “read-write (okuma-yazma)” “write-

only (salt-yazılır)” erişim seviyelerinden biri tanımlıdır.

Her nesne için eğer okuma-yazma işlemi yapılmak isteniyor ise “community name

(topluluk adı)” adı verilen değerin bilinmesi şarttır. Bu değer sistem yöneticisi

tarafından atanır ve bir bakıma şifre görevi görür. Ortak görüş bu “community

name”lere anlaşılması güç değerlerin atanması ile SNMP yi diğer kullanıcıların

erişimine kapatmaktır.

2.4.6.5 MIB nesneleri

Örnek bazı MIB nesne değerleri Çizelge 2.6’da verilmiştir.

Çizelge 2.6 Örnek bazı MIB nesne değerleri

MIB De ği şkeni OID ifInOctets 1.3.6.1.2.1.2.2.1.10 ifInUcastPkts 1.3.6.1.2.1.2.2.1.11 ifInNUcastPkts 1.3.6.1.2.1.2.2.1.12 ifOutOctets 1.3.6.1.2.1.2.2.1.16 ifOutUcastPkts 1.3.6.1.2.1.2.2.1.17 ifOutNUcastPkts 1.3.6.1.2.1.2.2.1.18 ifAdminStatus 1.3.6.1.2.1.2.2.1.7 ifOperStatus 1.3.6.1.2.1.2.2.1.8 ifAdminStatus 1.3.6.1.2.1.2.2.1.7 ifOperStatus 1.3.6.1.2.1.2.2.1.8 ifLastChange 1.3.6.1.2.1.2.2.1.9 ifInUcastPkts 1.3.6.1.2.1.2.2.1.11 ifInErrors 1.3.6.1.2.1.2.2.1.14 ifInDiscards 1.3.6.1.2.1.2.2.1.13 ifOutUcastPkts 1.3.6.1.2.1.2.2.1.17

51

Çizelge 2.7 (devam)

ifOutErrors 1.3.6.1.2.1.2.2.1.20 ifOutDiscards 1.3.6.1.2.1.2.2.1.19 sysUpTime 1.3.6.1.2.1.1.3

52

3. MATERYAL VE YÖNTEM

3.1 Materyal

Paket anahtarlamalı ağların geçmişi 30–40 yıl öncesine dayanmakla birlikte bu teknoloji

çok hızlı bir şekilde gelişmiştir. Bu teknolojilerin bazıları günümüz hız ve kapasite

ihtiyaçlarını karşılayamayacak kapasitede olduklarından ses iletimine adapte

edilememişlerdir. Ses iletiminde en çok kullanılan paket anahtarlamalı ağ IP ağıdır.

VoIP’i yerel ağ (LAN) üzerinden kullanırken genellikle büyük miktarda kullanılabilir

hat kapasitesi vardır ve gönderme alma arasındaki gecikme çok düşüktür. Yerel ağda

VoIP sorunsuzca kullanılabilir. Ama geniş alan ağı (WAN) kullanıldığında -örneğin

Internet- tıkanıklık ve gecikme sorunları oluşabilir. LAN üzerindeki gecikme genellikle

çok düşük olsa da WAN’da olan gecikme çok artarsa konuşma bir şekilde

gerçekleşemeyecek veya anlaşılamaz hale gelecektir. Diğer bir sorun ise konuşma

sinyalinin kalitesidir. Belli hatlarda yoğun kullanım olduğunda paketler kaybolabilir. Bu

kayıp paketler konuşma sinyalinde kesilmelere sebep olur. Bu kesilmeler de, yeterince

büyük oldukları zaman, konuşmayı bozabilirler. Hattın yoğun kullanımına VoIP

uygulaması da neden olabilir. Bu yoğunluğu azaltmak için birçok VoIP uygulaması

sıkıştırma teknikleri kullanırlar. Sıkıştırma, çoğu zaman sinyalin kötüleşmesini sağlar.

Bu durum dinleyici de rahatsızlığa neden olabilir ama sıkıştırma oranının az olması

durumunda telefon kalitesine ulaşılabilinir.

Telefon kalitesine ulaşmak için ağ üzerinde bir takım kontroller kullanılması

gerekebilir. QoS bu servislerin genel adıdır. Tüm yönlendiricilerde bu tip öncelikler

ayarlanılabilinirse, gerçek zamanlı verinin az gecikmeyle teslim edilebilmesi

sağlanabilinir. Bu yaklaşımın ana avantajı ek bir protokol kullanımına ihtiyaç

duyulmamasıdır. Yapılması gereken, verinin akış yönündeki bütün yönlendiricilerin,

paketlerin önceliklerini hesaba katacak şekilde ayarlanmasıdır. Đnternet üzerinde

bulunan bütün yönlendiriciler de bu ayarlamaların yapılmasını sağlamak mümkün

olmayabilir. Bir şekilde bu yönlendiriciler de bu ayar yapılmış olsa bile, bu

mekanizmalar sadece daha iyi bir hizmet vermek amacındadır, garanti veremezler.

Örneğin, tüm ağ yüksek öncelikli trafikle doluysa kalite hala düşük olacaktır.

53

Tıkanıklık her ağda olabilecek doğal bir olgudur. Ağdaki her kaynağın belli bir

kapasitesi vardır. Eğer bu kapasite o anda oluşan isteklere cevap veremiyorsa, tıkanıklık

oluşacaktır. Ağdaki temel kaynaklar tamponlar, gönderim hat kapasitesi ve işlemci

zamanıdır. Hat kapasitesi ağın en önemli bileşenidir ve hat kapasitesinin yetmemesi

durumu tıkanıklığın en temel halidir.

Tez araştırması sırasında noktadan noktaya WAN bağlantıları için bir tıkanıklık bildirim

mekanizması üzerinde durulmuştur. Kurum ya da kuruluşların, farklı yerlerdeki kısıtlı

hat kapasitesine sahip birimleri arasında, VoIP uygulaması yapılması gerekebilir. Bu

durum karşısında gerçek zamanlı trafik, tıkanıklık nedeniyle uygulanamaz hale

gelebilir. Hat kullanım grafiklerini oluşturmak için MRTG yazılımı kullanılmıştır.

MRTG yazılımı SNMP kullanarak grafikleri oluşturan bir programdır. MRTG,

http://people.ee.ethz.ch/~oetiker/webtools/mrtg/ adresinden indirilmiştir. SNMP

kullanımı yönlendiricilerde çok fazla işlemci gücüne ihtiyaç duymazlar. Özellikle

“snmpget” cihaza herhangi bir bağlantı yapmayacağı için tez aşamasında bu özellik

üzerinde durulmuştur. Noktadan noktaya bağlantı yapılmış merkezler arasındaki

yönlendiriciler de SNMP ile trafik akışı gözlemlenmeye çalışılmıştır. Kullanılabilir

SNMP kütüphaneleri http://www.net-snmp.org/ adresinden indirilmiştir. Açık kaynak

koduna sahip NETSNMP’de gerekli değişiklikler yapılarak anlık olarak hat kullanımı

tespit edilmeye çalışılmıştır. Linux işletim sisteminde çalışan, ANSI C ile yazılmış bir

uygulama geliştirilmi ştir. Ankara Üniversitesi ağında bulunan, kısıtlı hat kapasitesine

sahip Ankara Üniversitesi Geliştirme Vakfı Okullarının ağ trafik bilgisi anlık olarak

alınmaya çalışılmıştır.

Daha sonra elde edilen bilgiler, adaptif hızlarda çalışmakta olan VoIP uygulamasında

(Güler 2004) ihtiyaç duyulan WSOLA (Dalga Şekli Benzerlikli Örtüşmeli Ekleme-

Waveform Similarity Overlap Add) faktörü olarak sisteme entegre edilmiştir. Örnek

yapı içerisinde yer alan G.729 kodeği www.voiceage.com adresinden form doldurularak

indirilmiştir.

Sistemlerden elde edilen ses dosyasının kalitesini ölçmek için en çok kullanılan ve öznel

bir yöntem olan MOS (Ortalama Fikir Skoru - Mean Opinion Score) kullanılmıştır. Elde

edilen puanların istatistiki anlamlılığı, SPSS (Sosyal Bilimler için Đstatistikî Paketler -

Statistical Package for the Social Sciences) kullanılarak test edilmeye çalışılmıştır.

54

3.2 Yöntem

3.2.1 SNMP ile hat kullanımının gözlenmesi

Ankara Üniversitesi omurgasında yer alan Ankara Üniversitesi Geliştirme Vakfı

Okullarının hat kullanım grafikleri gün, hafta, ay ve yıl olarak MRTG yazılımı ile

alınmıştır. Örnek bir gün grafiği Şekil 3.1’de görülmektedir.

Şekil 3.1 Ankara Üniversitesi Geliştirme Vakfı Okulları hat kullanımı

Grafikten de görüleceği üzere hat kullanımı mesai saatlerinde artmakta ve 128 kbps

kapasiteye sahip bağlantıda 124 kbps’e kadar bir kullanım oranı ortaya çıkmaktadır. Bu

gibi hat kullanımına sahip birimler de gün içinde bir VoIP uygulaması kullanmak,

VoIP’e ait avantajları yok edebilmektedir.

3.2.2 SNMP ile hat kullanımı hesabı

Kullanımın nasıl hesaplanacağı, ölçmek istenilen verinin nasıl sunulduğuna bağlıdır. Ağ

kullanımı için yönlendirici üzerindeki ara yüzlerden geçen veri temel ölçüdür.

Kullanımı tespit edilmek istenilen bağlantının tek yönlü ya da çift yönlü olmasına bağlı

olarak, kullanılacak ölçme metodu değişecektir. Paylaşılmış LAN bağlantıları tek

yönlüdür. WAN bağlantıları ise çift yönlüdür. Bağlantı noktadan noktayadır ve her iki

cihaz da bağlantıyı paylaşan tek bir cihaz daha olduğunu bildiği için aynı zamanda

iletim ve alım yapabilir. MIB II değişkenleri sayaç olarak tutulduğu için iki sorgu

döngüsü alınmalıdır ve bu değerlerin farkları hesaplanmalıdır. Değer farkları nedeniyle

denklemde delta kullanılmıştır.

Formüllerde kullanılan değişkenler şunlardır:

55

∆ifInOctets: Gelen trafiğin sekizlik olarak belirtildiği, SNMP ifInOctets nesnesini

toplayan iki sorgu döngüsü arasındaki farktır.

∆ifOutOctets: Giden trafiğin sekizlik olarak belirtildiği, SNMP ifOutOctets nesnesini

toplayan iki sorgu döngüsü arasındaki farktır.

ifSpeed: SNMP ifSpeed nesnesinde belirtilen, ara yüzün veri hızıdır.

ifSpeed, WAN ara yüzünün hızını tam olarak yansıtmayabilir. Tek yönlü ortamlarda ara

yüz kullanımını hesaplamak için Eşitlik (3.1) kullanılır. ;

(∆ifInOctets + ∆ifOutOctets) x 8 x 100 / ((∆zaman) x ifSpeed) (3.1)

Çift yönlü ortamlar için bu hesap daha karmaşıktır. Karmaşayı azaltmak için düşünülen

sistem tek yönlü olarak tasarlamıştır.

Çift yönlü bağlantılarda kullanım yüzdesini bulmak için, ara yüzün hat kullanımını

hesaplarken giriş ve çıkış değerlerinin yüksek olanının tercih edildiği formül

kullanılmalıdır.

Maks(∆ifInOctets,∆ifOutOctets) x 8 x 100 / ((∆zaman) x ifSpeed) (3.2)

Eşitlik (3.2)’de maks(x,y) x ve y değişkenlerinden nicelik olarak büyük olanın

seçilmesini ifade etmektedir.

Fakat bu metot düşük değere sahip olan yönün kullanımını dikkate almaz ve eksik

sonuç verir. Bu sorunu gidermenin yolu giriş ve çıkış kullanımını ayrı ayrı ölçmektir:

Giriş kullanımı = ∆ifInOctets x 8 x 100 / ((∆zaman) x ifSpeed) (3.3)

Çıkış kullanımı = ∆ifOutOctets x 8 x 100 / ((∆zaman) x ifSpeed) (3.4)

Eşitlik (3.3) ve (3.4), Eşitlik (3.2)’nin basitleştirilmi ş halleri olup, protokolle ilişkili ek

yük göz önünde bulundurulmamıştır.

56

3.2.3 SNMP ile kullanılan hat kapasitesini hesaplayan program

Program yazımında NETSNMP kütüphaneleri ve örnek programları kullanılmıştır.

SNMP ile Hat Kullanımı Hesabı Bölüm 3.2.2’deki gibidir. Yapılan çalışmada bu

yöntem hesaplama metodu olarak kullanılmıştır. ifInOctets bilgisi cihazın çalışmaya

başladığı andan itibaren geliş ve gidiş yönündeki kullanım oranını bayt cinsinden

tutmaktadır. Bu nedenle iki kez ölçüm alınmıştır. Arada geçen süre, yine cihaz üzerinde

sysUpTime ile cihazın ne kadar süredir açık olduğunu gösteren zaman bilgisi alınmıştır.

Bu bilgi timetick halindedir ve cihazın MIB alanında salise olarak tutulmaktadır.

Program cihaz üzerinden o andaki ifInOctets ve sysUpTime bilgilerini alarak hat

kullanımını ifSpeed bilgisi ile karşılaştırıp kullanılabilecek durumdaki hat kapasitesi

değerini ortaya çıkarmaktadır.

Bu değer Adaptif WSOLA için WSOLA faktörünü oluşturmak da için kullanılmıştır.

3.2.4 Adaptif WSOLA

Sesin sayısallaştırılması ve kodlanması ile ilgili yapılan çalışmalarda birçok farklı kodek

tasarlanmış ve standartlaştırılmıştır. Çeşitli gecikme, bant genişliği ve kalite

ihtiyaçlarına göre bu kodeklerden uygun biri seçilmelidir. Günümüzde ses kodlaması ve

sıkıştırması için yapılan akademik çalışmaların çoğu yeni bir kodek algoritması

oluşturmak yerine, bir konuşma iletimi esnasında ortaya çıkan dinamik ihtiyaçlara göre

kodeklerin veya kullanılan özelliklerin değiştirilmesi üzerinedir. Bu nedenle bu

çalışmalar, Adaptif VoIP (Genelleme yapılacak olursa Adaptif Ses Đletimi) veya VBR

(Variable Bit Rate – Değişken Hızlı) kodek olarak adlandırılmaktadır (Güler 2004).

WSOLA ile yapılandırılmış sistemlerin MOS değerleri diğer sıkıştırma yöntemlerine

göre çok daha başarılıdır (Đlk ve Tuğaç 2005).

3.2.5 G.729

G.729 CELP tabanlı bir kodek standardıdır. Standarda göre kodek girdi olarak 8 Khz

’lik her örneklemenin, 16 bit doğrusal PCM ile kodlandığı ses sinyalini almaktadır.

Aşağıdaki Şekil 3.2’de standartta tanımlanan G.729 kodlayıcısının blok diyagramını

göstermektedir.

57

Tüm CELP kodekleri gibi G.729 standardının kodlayıcısında da senteze göre analiz

(analysis by synthesis) yapılmaktadır. Kodek girdisi olan ses, önişleme bloğu tarafından

ilk önce yüksek geçirgen bir filtreden (microfon DC’sini ve AC şebeke gürültüsünü

filtrelemek için) geçirilir. Bu filtrenin çıktısı diğer tüm işlemlerde girdi olarak

kullanılmaktadır. LPC parametreleri her 10 ms ’lik çerçeve için hesaplanır. Daha sonra

bunlar LSF parametrelerine çevrilerek 18 bit ile vektörel nicemlenir. LPC filtresinin

uyarıcı girdi sinyali her 5 ms ‘lik alt çerçevede uygun adaptif kod tablosu (codebook) ve

sabit kod tablosu kullanılarak (sentez) hesaplanır.

Şekil 3.2 G.729 için kodlayıcı devresi

Bu parametreleri bulmak için orijinal ses ile LPC filtresinin farkından kalan kalıntı

sinyali algısal ağırlık filtresinden geçirilir. Daha sonra perde analizi ve sabit kod tablosu

taraması yapılarak uygun perde periyodu, sabit kod ve kazançları hesaplanır. Adaptif

58

kod tablosu perde periyodu ve kazancına göre hesaplanmaktadır. Perde periyodu ilk alt

çerçeve için 8 bit ikinci alt çerçeve için 5 bit ile kodlanmaktadır. Sabit kod tablosu her

iki alt çerçeve için 13 bit, nabız (pulse) işaretleri 4 bit ve kazançları 7 bit ile

kodlanmaktadır. 1 bit de perde periyodu hata paritesi olarak kullanıldığı için her çerçeve

toplam 80 bit ile kodlanır.

G.729 için kod çözücü devresi (sentez) ise oldukça basittir (Şekil 3.3).

Şekil 3.3 G.729 sentez devresi

Yukarıdaki şekilde de görüldüğü gibi LSF parametrelerinden elde edilen LP katsayıları

kısa zaman filtresinde kullanılmaktadır. Perde periyodu ve kazancı adaptif kod

tablosunu oluşturmakta, sabit kod tablosu ve kazancı ile birlikte LP filtresini

uyarmaktadır. En son sentezlenen çıktı son bir yüksek geçirgen filtreden geçirilerek ses

oluşturulmaktadır (Anonim 1996).

3.2.6 Sesin kalitesini değerlendirme

Ses iletişiminde, örneğin Internet telefonunda, MOS (ortalama fikir skoru - Mean

Opinion Score), devrenin hedef ucundaki insan sesinin kalitesinin bir ölçütüdür. Şema,

sistem performansına dair nicel bir gösterge elde etmek için matematiksel olarak

ortalanmış öznel testleri (opinionated sources) kullanır.

Kodekler, ses iletişiminde hat kapasitesini koruma eğilimli oldukları için, genellikle

sıkıştırma/açma (codec - compressor/decompressor) sistemleri ve DSP (Sayısal Sinyal

Đşleme-Digital Signal Processing) kullanırlar. Aynı zamanda sesin gerçekliğini de

bozmaktadırlar. En iyi kodekler sinyali en az seviyede bozarak, hat kapasitesini en iyi

59

koruyanlardır. Hat kullanımı laboratuar cihazları kullanılarak ölçülebilir, ama ses

kalitesi insan tarafından yorumlanmalıdır.

MOS u analiz etmek için bir kaç dinleyici, ses devresi üzerinden erkek ve kadın

seslendiriciler tarafından okunan cümlelere puan verirler. Dinleyici her bir cümleye şu

şekilde not verir: (1) kötü, (2) zayıf, (3) orta, (4) iyi, (5) pekiyi. MOS tüm tekil notların

aritmetik ortalamasıdır.

3.2.7 Anlamlılık testi

3.2.7.1 Hipotez

Bir durum hakkında ileri sürülen varsayımlardır. Anlamlılık testleri bir hipotezi test

etmek için yapılır. Hipotez, istatistiksel olarak H0 farksızlık hipotezi ve H1 alternatif

hipotez olmak üzere gösterilirler.

Öncelikle H0 hipotezi belirlenir. Bu hipotez farksızlığı esas alır. Đki ortalama arasında

fark yoktur. H1, alternatif hipotez ise farklılık üzerine kurulur.

Bir hipotez kabul veya ret edildiğinde her zaman doğru sonuca varıldığı ya da varılan

kararın doğru olduğu söylenemez. Doğru bir hipotezin yanlışlıkla reddedilmesi veya

yanlış bir hipotezin kabul edilmesi her zaman olasıdır.

3.2.7.2 T testi

Birbirinden bağımsız iki örneklemin ortalamaları arasındaki farkın hangi yönde olduğu

ve farkın önemli olup olmadığının test edilmesinde kullanılır. Örneklem büyüklüğü

30’dan büyük ise z testi, küçük ise t testi hesaplanır.

n: Denek Sayısı, x: Denek tarafından verilen puan olmak üzere, n> 30 için z testi

uygulanılır.

z eşitli ği Eşitlik (3.5)’de verilmiştir. Eşitlikte verilen σ∆x= Standart Hata Eşitlik (3.6)’da

verilmiştir.

(3.5)

60

(3.6)

n< 30 için t testi uygulanılır (Eşitlik 3.7). Eşitlikte kullanılan S∆x: Standart Hata Eşitlik

(3.8)’de verilmiştir.

(3.7)

(3.8)

61

4. ARAŞTIRMA BULGULARI VE TARTI ŞMA

MRTG’de hat grafikleri 5 dakikalık aralar ile alınan sonuçlara dayanmaktadır. Ses

iletimi gibi gerçek zamanlı uygulamalar da bu grafiklerin kullanımı mümkün değildir.

Ses trafiği için 5 dakika oldukça uzun bir süredir. Bu süre içerisinde hat tıkanıklığa

uğramış olabilir. Elde edilen grafiklerden, geçen süre içerisinde tıkanıklık olduğunu

anlamak mümkün olmayacaktır. Bu nedenle tez çalışmasında bu süreyi en aza indirerek

olası tıkanıklık, anlık olarak tespit edilmeye çalışılmıştır. Şekil 4.1’de bu grafik

görülmektedir.

Şekil 4.1 Anlık ağ trafi ği

Kullanılan ses sıkıştırma yönetim Adaptif WSOLA ile Şekil 4.2’deki gibi bir düzenek

oluşturulmuştur.

Şekil 4.2 Tek yönlü trafik için örnek Adaptif WSOLA uygulaması

Bu yapı da Şekil 4.3’de verilen, 8 Khz örnekleme frekansında ve 16 bit/örnek bir ses

Ses Çıkışı

62

sinyali kullanılmıştır. SNMP ile alınmış WSOLA faktörü sisteme sıkıştırma parametresi

olarak verilmiştir.

Şekil 4.3 Kullanılan ses dalga şekli

Adaptif WSOLA ile sıkıştırma-açma işleminden sonra oluşan ses dalga şekli Şekil

4.4’deki gibi olmuştur.

Şekil 4.4 Sistemden elde edilen ses dalga şekli

Şekil 4.3 ve 4.4’den görüleceği üzere Adaptif WSOLA ile sıkıştırma-açma işleminden

sonra sinyallerin dalga şeklinde önemli bir fark oluşmamıştır.

63

Daha sonra bu sisteme G.729 kodek eklenmiştir. G.729 kodek günümüzde VoIP için en

yaygın olarak kullanılandır. G.729 eklenmiş yapı Şekil 4.5’de görülmektedir.

Şekil 4.5 Adaptif WSOLA-G.729 kodek sistemi

Şekil 4.3’de gösterilen ses sinyali bu sisteme de uygulanmıştır. Bu yapıdan elde edilen

ses dalga şekli Şekil 4.6’da görülmektedir.

Şekil 4.6 Adaptif WSOLA-G.729 kodek sisteminin ses dalga şekli

Ses sinyallerini dalga şekillerine bakarak analiz etmek mümkün değildir. Bu nedenle ses

kalitesi analiz tekniklerinden olan öznel ses inceleme tekniklerine ihtiyaç vardır. Bu

nedenle; her iki sistemden elde edilen ses dosyaları 21 farklı kişiye dinletilmiş ve elde

edilen ortalama MOS puanları Çizelge 4.1’de gösterilmiştir.

64

Çizelge 4.1 Ortalama MOS puanları

Kullanılan Sistem MOS Puanları Orijinal Ses 4,72 Adaptif WSOLA 4,55 Adaptif WSOLA + G.729 3,87

Elde edilen sonuçların istatistiki anlamlılığı için 3 adet değerlendirme yapılmıştır. Đlk

olarak orijinal ses ve Adaptif WSOLA uygulanmış ses verilerine t testi uygulanmıştır.

Orijinal sese verilen puanlar: x

Adaptif WSOLA uygulanmış sese verilen puanlar: y

Ho: µx-µy=0 (Ho: yokluk hipotezi, µ karşılaştırılmak istenen kitle ortalaması)

H : µx-µy≠0 (H : alternatif hipotez)

Ho hipotezi orijinal seslere verilen puanların ortalaması ile Adaptif WSOLA

uygulanmış sese verilen puanların ortalaması arasında fark yoktur. Adaptif WSOLA

uygulanmış ses, orijinal sesten kalite olarak farklı değildir. Sonuç Çizelge 4.2’de

görülmektedir.

Çizelge 4.2 Orijinal ses ile Adaptif WSOLA uygulanmış seslere ait t testi

Şekilde p=Sig.=0.076 olarak bulunmuştur. Test %95 anlam düzeyinde uygulanmıştır.

α=1-anlam düzeyi=1-0.95=0.05

65

p>α olduğu için Ho hipotezi reddedilemez. Sonuç olarak, Adaptif WSOLA tekniği

kullanılarak elde edilen seslerin kalitesinde bir azalma olduğuna dair yeterli kanıt

bulunamamıştır.

Bir diğer test orijinal ses ile adaptif WSOLA+G.729 düzeneğinden elde edilen ses ile

yapılmıştır.

Orijinal sese verilen puanlar: x

Adaptif WSOLA+G.729 düzeneğinden elde edilen sese verilen puanlar: z

Ho: µx-µz=0, H : µx-µz≠0 hipotezleri kurularak test işlemi yapılmıştır. Ho hipotezinde

orijinal seslere verilen puanların ortalaması ile adaptif WSOLA+G.729 düzeneğinden

elde edilen sese verilen puanların ortalaması arasında fark olmadığını göstermektedir.

Ho hipotezi reddedilmez ise adaptif WSOLA+G.729 düzeneğinden elde edilen ses,

orijinal sesten kalite olarak farklı olmayacaktır. Sonuç Çizelge 4.3’de görülmektedir.

Çizelge 4.3 Orijinal ses ile Adaptif WSOLA+G.729 düzeneğinden elde edilen

seslere ait t testi

p=Sig.=0.000 olduğu için α>p olacaktır. Bu nedenle Ho hipotezi reddedilecektir. Sonuç

olarak adaptif WSOLA+G.729 düzeneğinden elde edilen ses orijinal sesten farklıdır.

66

Orijinal ses ile adaptif WSOLA+G.729 düzeneğinden elde edilen ses arasında fark

vardır. Bu farkı yaratan sistemin tespit edilmesi için adaptif WSOLA ve adaptif

WSOLA+G.729 sistemlerine de t testi uygulanmıştır.

Adaptif WSOLA uygulanmış sese verilen puanlar: y

Adaptif WSOLA+G.729 düzeneğinden elde edilen sese verilen puanlar: z

Ho: µy-µz=0, H1: µy-µz≠0 hipotezleri kurularak test işlemi yapılmıştır. Ho hipotezinde

adaptif WSOLA uygulanmış sese verilen puanların ortalaması ile adaptif

WSOLA+G.729 düzeneğinden elde edilen sese verilen puanların ortalaması arasında

fark olmadığını göstermektedir. Ho hipotezi reddedilmez ise adaptif WSOLA+G.729

düzeneğinden elde edilen ses, adaptif WSOLA uygulanmış sesten kalite olarak farklı

olmayacaktır. Sonuç Çizelge 4.4’de görülmektedir.

Çizelge 4.4 Adaptif WSOLA uygulanmış ses ile Adaptif WSOLA+G.729

düzeneğinden elde edilen seslere ait t testi

p=0.000 ve α=0.05 olduğu için α>p olacaktır. Bu nedenle Ho hipotezi reddedilecektir.

Sonuç olarak adaptif WSOLA+G.729 düzeneğinden elde edilen ses, adaptif WSOLA

uygulanmış sesten farklıdır.

67

5. SONUÇ

WAN uygulamalarında tıkanıklık nedeniyle paket kayıpları oluşabilmekte veya paketler

alıcı tarafına çok geç ulaştığı için sistem tarafından kullanılmadan düşürülebilir. Bu tür

durumlarda ses kodlamasının, veri hızı ihtiyacını tıkanıklığa göre değiştirebilme

yeteneği, büyük esneklik kazandıracaktır. Daha önceden geliştirilen Adaptif WSOLA

yönteminde tıkanıklıklarda konuşma sesi hızlandırılarak hat kullanımı düşürülmüştür.

Burada WSOLA’nın adaptif oluşu WSOLA faktörünün değişimine göre alıcı taraftaki

WSOLA ağırlık penceresinin uzunluğun da değişmesi anlamındadır.

Bu çalışma da noktadan noktaya bir bağlantı ağ olarak alınmıştır. Ağda oluşabilecek

olası tıkanıklık durumlarının Adaptif WSOLA tarafından kullanılması için WSOLA

faktör değerlerini ortaya çıkaran bir SNMP uygulaması geliştirilmi ştir. WSOLA

algoritmasının kullanacağı sıkıştırma oranları bu değere göre değişmekte ve hat

kullanımına göre kendini ayarlayabilmektedir. Sisteme ayrıca VoIP uygulamalarında

sıkça kullanılan G.729 kodek dahil edilerek tam bir VoIP uygulaması elde edilmiştir.

Her iki sistem için elde edilen MOS puanları, sistemlerin uygulanmasında, ses kalitesi

olarak başarılı sayılabileceğini göstermiştir.

Yapılan istatistiki testler sonucunda orijinal ses ile adaptif WSOLA uygulanmış ses

arasında herhangi bir kalite farkı bulunamamıştır. Orijinal ses ile adaptif

WSOLA+G.729 düzeneğinden elde edilen ses arasında t testine göre fark vardır. Bu

durum sesin kalite olarak bozulduğunu göstermektedir. Bu bozulmanın kaynağının

G.729 olduğu adaptif WSOLA uygulanmış ses ile adaptif WSOLA+G.729

düzeneğinden elde edilen ses arasında yapılan test ile görülmüştür. Adaptif WSOLA

uygulanmış ses ile adaptif WSOLA+G.729 düzeneğinden elde edilen ses arasında kalite

farkı tespit edilmiştir.

Gelecek çalışma olarak noktadan noktaya uygulanan bu sistemin, birden fazla atlama

noktası olan sistemlere uygulanması düşünülmüştür.

68

KAYNAKLAR

Anonim. 1996. “Coding of Speech at 8 Kbit/s Using CS-ACELP” ITU-T Rec G.729;

44.

Black, U. 2000. Voice over IP. Prentice Hall, 352, United States of America.

Braden, R. Clark, D. and Shenker, S. 1994. Integrated Services in the Internet

Architecture: an Overview. RFC 1633;33.

Braden, R. Zhang, L. Berson, S. Herzog, S. and Jamin, S. 1997. Resource ReSerVation

Protocol (RSVP). RFC 2205; 112.

Case, J. Fedor, M. Schoffstall, M. and Davin, J. 1990. A Simple Network Management

Protocol (SNMP). RFC 1157; 35.

Case, J. McCloghrie, K. Rose, M. and Waldbusser, S. 1993. Textual Conventions for

version 2 of the Simple Network Management Protocol (SNMPv2). RFC 1443;

31

CIP Working Group. 1990. Experimental Internet Stream Protocol, Version 2 (ST-II),

RFC 1190; 147.

Çölkesen, R. 2000. “Ağ TCP/IP Unix”. Papatya Yayıncılık, 240, Đstanbul.

DataBeam Corporation. 1998. A Primer on the H.323 Standard.

http://www.databeam.com/h323/h323primer.html

Delgrossi, L. and Berger, L. 1995. Internet Stream Protocol Version 2 (ST2) Protocol

Specification – Version ST2. RFC 1819; 108.

Filipiak, J. 1991. Real Time Network Management. 446. Amsterdam, North-Holland.

Gerla, M. and Kleinrock, L. 1980. Flow Control: A Comparative Survey. IEEE

Transactions on Communications, Vol.Com–28 no.4, (21); 553–574.

Güler, S. 2004. Paket Anahtarlamalı Ağlar Üzerinden Konuşma Đletme Parametreleri.

Ankara Üniversitesi Fen Bilimleri Enstitüsü Yüksek Lisans Tezi, Ankara.

69

Harrington, D. Presuhn, R. and Wijnen, B. 1998. An Architecture for Describing SNMP

Management Frameworks. RFC 2261; 56

Đlk, H.G. and Tuğaç, S. 2005. Channel and Source Considerations ofa Bit-Rate

Reduction Technique for a Possible Wireless Communications System’s

Performance Enhancement. IEEE Transactions on Wireless Communications,

Vol 4, NO. 1, (6); 93-99.

Jain, R. 1990. Congestion Control in Computer Networks: Issues and Trends. IEEE

Network Magazine, (6). 24–30

McCloghrie, K. and Rose, M. 1988. Management Information Base for Network

Management of TCP/IP-based internets. RFC 1066; 89.

McCloghrie, K. and Rose, M. 1990. Structure and Identification of Management

Information for TCP/IP-based Internets. RFC 1155; 22.

McCloghrie, K. and Rose, M. 1991. Management Information Base for Network

Management of TCP/IP-based internets: MIB-II. RFC 1213; 70.

Mitzel, D.J. Estrin, D. Shenker, S. and Zhang, L. 1994. An architectural comparison of

ST-II and RSVP. Networking for Global Communications, 13th Proceedings

IEEE, (9); 716 – 725.

Parkhurst, W. 2004. Internet Addressing and Routing First Step. Cisco Press, 474,

United States of America.

Postel, J.(ed.) 1981. Internet Protocol - DARPA Internet Program Protocol

Specification. RFC 791; 45.

Pouzin, L. 1981. Methods, Tools, and Observations on Flow Control in Packet-

Switched Data Networks, IEEE Transactions on Communications, Vol.Com-29

no.4 (13); 413–426.

Schulzrinne, H. Casner, S. Frederick, R. and Jacobson, V. 1996. RTP: A Transport

Protocol for Real-Time Applications, RFC1889,

70

Schulzrinne, H. and Rosenberg J. 1998. “A Comparison of SIP and H.323 for Internet

Telefony”, NOSSDAV'98, England

Tanenbaum, A.S. 1996. Computer Networks. Prentice-Hall, 912, United States of

America.

Yang, C. and Reddy, A.V.S. 1995. A Taxonomy for Congestion Control Algorithms in

Packet Switching Networks. IEEE Network Magazine, Vol.9 (5); 41-46

71

ÖZGEÇM ĐŞ

Kırıkkale’de 1977 yılında doğdu. Đlk, orta, lise öğrenimini Kırıkkale’de tamamladı.

1996 yılında girdiği Ankara Üniversitesi Fen Fakültesi Elektronik Mühendisliği

Bölümü’nden 2000 yılında Elektronik Mühendisi unvanıyla mezun oldu.

2000 yılında başladığı Ankara Üniversitesi Bilgi Đşlem Daire Başkanlığında Sistem ve

Ağ Mühendisi olarak görev yapmaktadır. 2002 yılında Bilgi Đşlem Daire Başkanlığı

Sistem ve Ağ Grup sorumluğu görevine getirilmiştir. Aynı yıl Ankara Üniversitesi

Sürekli Eğitim Merkezi kapsamında yürütülmekte olan Cisco Networking Academy

Programı bünyesinde eğitmen olarak da görev almaktadır.