Özet. Bu makalede Netas VoIP (Voice over IP) santralinin IMS (IP Multimedya Subsystem)'e erişim verimliliğini artırmaya ve abone kayıt işlemleri sırasında olumsuz etkilenen sistem performansını iyileştirmeye yönelik çalışmalarla ilgili bilgi birikimi ve tecrübe paylaşılmıştır. Bu kapsamda geliştirdiğimiz aramaprogramlama teknikleri ve önerdiğimiz bit haritası yöntemi yardımı ile optimum sayıda abonenin taranması sağlanarak sistem performansı en az %15 oranında artırılmıştır. Proje öncesi ve sonrası yapılan ölçüm sonuçları ve projenin sistem performansına etkisi rakamsal verilerle sunulmuştur.
Telekom operatörleri, mevcut müşterilerinin büyük kısmı eski nesil teknolojileri kullandığından dolayı eski nesil teknolojilerle sunmak istedikleri yeni teknolojileri ve servisleri entegre eden çözümler talep etmektedir [1]. Bu müşteri ihtiyaçları ve teknolojik gereksinimleri karşılamak için Netaş 2012 yılında AGCF (Access Gateway Control Function) çözümü tasarlamıştır. Bu çözüm ile TDM (Time Division Multiplexing) aboneleri VoIP sistemine entegre olup IMS’e bağlı uygulama sunucularından hizmet alabilmektedir. Bunun sonucunda 50K TDM abonesinin zengin IMS IP servislerini kullanabilmesinin önü açılmıştır. Daha sonra yapılan geliştirmelerle desteklenen abone sayısı 500K aboneye çıkarılmıştır.
Bu kapasite artışı ve devamındaki geliştirmeler sonucunda sistem kurtarma durumunda gerçekleşen toplu kayıt işlemleri ile sistem boştayken gelişen sınırlı sayıdaki abone kayıt işlemleri sırasında mevcut CPU (Central Processing Unit) kaynakları çok fazla kullanılmaktadır. Bu durumda sistem performansının olumsuz etkilendiği görülmüştür. Bu çalışmada AGCF çözümünün gerçek zamanlı performansının artırılması, CPU kullanımının azaltılarak, arka planda çalışan diğer işlemlerin performanslarını düşürmesinin engellenmesine ilişkin deneyim paylaşılmıştır.
Bu çalışma beş bölümden oluşmaktadır. Bölüm 2’de Netaş’ın müşterilerine sunduğu VoIP tümleşik çözüm mimarisi, bölüm 3’ te AGCF çözümü genel hatlarıyla anlatılmıştır. Bolum 4’de AGCF çözümünün performans iyileştirme faaliyetlerine ve son bölümde ise genel değerlendirmelere ve sonuçlara değinilmiştir. 2
Netaş’ın müşterilerine sunduğu tümleşik çözüm mimarisi Şekil 1’de verilmiştir. Bu mimarinin ana bileşeni olan yeni nesil VoIP santrali değişik görevleri yerine getiren çok fazla alt bileşenden oluşmakta ve 1300 civarında servisi müşterilerine sunabilmektedir. Bu santral birçok protokol kullanabilmekte ayrıca dünyadaki nerdeyse tüm haberleşme standartlarını desteklemektedir.
Bu santrali oluşturan bileşenlerden bazıları şunlardır. Çekirdek (Core) aramanın kurulması, yönlendirilmesi ve sonlandırılması esnasındaki sinyalleşme gibi arama ve servislerle ilgili tüm kontrolleri üstlenir. Ağ Geçidi (Gateway, GW) transfer katmanında sinyalleşme sistem No:7 (SS7) ile IP tabanlı sinyalleşme protokolleri arasında dönüşüm yapmaktadır. Ağ Geçidi Denetleyicisi (Gateway Controller, GWC) Çekirdek ile GW arasındaki bağlantıyı sağlamaktadır. Oturum Trank Sunucusu (Session Server Trunk, SST) santrali IP altyapıya bağlayan, diğer santraller ile bağlantıyı sağlayan birimdir. SST, IMS ve diğer santraller arasındaki mesajlaşmalarda SIP protokolü kullanılmaktadır[2].
Şekil 1. VoIP Santrali ve Bileşenleri 3
AGCF çözümü TDM abonelerinin VoIP sistemine entegre olmasını ve IMS’e bağlı uygulama sunucularından hizmet alabilmelerini sağlamaktadır. IMS IP tabanlıdır ve diğer sistemlerle SIP (Session Initiation Protocol) ile konuşmaktadır[3]. AGCF çözüm mimarisi Şekil 2 de verilmiştir. AGCF çözümünde tüm AGCF abonelerinin IMS’e kaydolması gereklidir [3]. Bunun için tüm abone bilgilerinin saklandığı Çekirdek üzerinde bu aboneler için AGCF özelliği tanımlanmıştır. AGCF özelliğinin tanımlandığı aboneler için Çekirdek, SST’ye kayıt isteğini gönderir. Bu kayıt mesajı içerisinde abonenin numarası, IMS’den hizmet alırken kullanacağı bağlantı ve yapacağı kaydolma, kayıt silme gibi görevleri taşıyan parametreler tanımlanmıştır. Bu paketler TCAP mesajı formatındadır. SST kendisine gelen mesajlarını çözümleyerek SIP mesajlarını IMS’e gönderir. IMS, SIP mesajını çözümleyerek kendi üzerinde tanımlanmış böyle bir abonesinin olup olmadığını kontrol eder. Eğer kayıt varsa SIP 200 OK mesajı ile santrale olumlu cevap döner. Ardından SST, Çekirdeğe kayıt işleminin gerçekleştirildiği bilgisini iletir[4].
Şekil 2. AGCF Çözüm Mimarisi
Abonelerin tek tek ya da toplu olarak kayıt durumlarının güncellenmesi, ilk defa kayıt edilmesi, ya da kaydını silinmesi gerektiren durumlar mevcuttur. Bu tarz bir durum gerçek zamanda her an gerçekleşebileceği için çekirdek 50ms aralıklarla AGCF abonelerinin kayıt durum değişikliklerini kontrol etmek için aboneleri taramak zorundadır. Eğer bir TDM abonesi çağrı yapabilecek duruma geldiyse otomatik olarak kayıt mesajı atılır. Eğer servis dışı kaldıysa kayıt işlemi yine otomatik olarak silinir.
Çok sayıda abonenin aynı anda kayıt isteğinde bulunması yoğun bir mesajlaşma trafiği yaratmaktadır. Bu yoğun mesajlaşmanın çağrı trafiğini olumsuz etkilememesi için Çekirdekte AGCF kayıt işlemi zamanlama mekanizması (AGCF Throttling) geliştirilmistir. Eğer kayıt için gönderilen istekler için SST den beklenen cevap sayısı 50’yi geçtiyse 10 ms, 100’ü geçtiyse 20 ms, 200’ü geçtiyse 30 ms, 400’ü geçtiyse 40 ms gecikmelerle mesaj gönderilir. 500’den sonra mesajlaşma durdurulur. 4
Bir önceki bölümde bahsedildiği gibi abonelerin tek tek ya da toplu olarak kayıt durumlarının güncellenmesi, ilk defa kayıt edilmesi, ya da kaydının silinmesini gerektiren durumlar vardır. Bunlardan bazıları aşağıdaki gibidir. Aboneye ilk kez AGCF özelliği verildiğinde, ya da AGCF özelliği kaldırıldığında, bu abone için kayıt etme ya da kayıt silme mesajı gönderilir. Abonelerin bakım ya da herhangi bir problem nedeniyle servis durumunun değişmesi durumunda kayıt durumlarının güncellenmesi gerekmektedir. Bir GW veya GWC’nin bakım durumlarında, bu GW veya GWC’ye bağlı tüm
AGCF abonelerine kayıt durum değişikliğini bildiren mesaj gönderilir. SST’nin bakım durumlarında tüm AGCF abonelerinin kayıtları yenilenir. Manuel denetim abonelerin servis durumlarını kontrol ederek tüm AGCF abonelerinin kayıtlarını yeniler. Otomatik denetim veri uyuşmazlıklarını kontrol eder ve servis durumu ile kayıt durumu uyuşmayan aboneler için servis durumuna göre tekrar mesaj gönderir Çekirdek yeniden başlatıldığı zaman aboneler servise girdikçe SST’ye kayıt mesajı gönderilir.
Çekirdek belirli aralıklarla abonelerin kayıt durumlarındaki değişiklikleri IMS’e bildirebilmek için aboneleri taramaktadır. Abonelerin kayıt durumu değişim bilgisinin çok geciktirilmemesi için bu zaman aralığının çok uzun olmaması gerekmektedir. Aynı zamanda abonelerin sürekli taranması da sistemi yoracağından optimum bir çözüme ihtiyaç duyulmaktadır.
CPU performansını asıl etkileyen faktör 50ms de bir bütün abonelerin taranmasıdır. CPU kullanımını düşürmek için her seferinde 500 bin aboneyi taramak yerine optimum sayıda abonenin taranması sağlanmıştır. Şekil 3 ’teki gibi AGCF abonelerinin tutulduğu veri yapısının eşleniği iki kademeli bir bit haritası geliştirilmiştir. 16 bitlik ilk kademe abonelerin havuz endeksini temsil etmektedir. İlk kademedeki her bir bite bağlı oluşturulan ikinci kademedeki 16 blok ise abonelerin ilgili havuzun içindeki adreslerini temsil etmektedir. Yukarıda bahsi geçen, abonelerin kayıt durumlarını değiştiren her bir olay da 6 bitlik ayrı bir bit haritasında tutulmuştur. Yeni yapıda 5 saniyede bir olay haritası kontrol edilir. Bir olay oluştuğunda ilgili işlemler olayı olay bit haritasında, kayıt değişikliği gerektiren aboneleri ise abone bit haritasında işaretler. Herhangi bir olay geldiğinde 5 saniyenin bitmesi beklenmeden tarama işlemi hemen başlatılır. Şekil 3’ te örneklendirildiği gibi tarama işleminde önce ilk kademe bit haritası kontrol edilir. Eğer ilk kademedeki bit haritasında kontrol edilen bit değeri 1 ise o bite bağlı oluşturulan ikinci kademedeki blok taranmaya başlanır. Eğer bit değeri 0 ise o blok taranmaz ve ilk kademedeki bir sonraki bit kontrol edilir. Çekirdek işlemcisi 32 bit algoritmik operasyon desteklediğinden ikinci kademedeki bloklarda her bir satır uzun tamsayı olarak okunur. Eğer satır değeri 0 ise o bloktaki bir sonraki satıra geçilir. Eğer 1 ise satırdaki kayıt mesajı gönderilecek aboneler belirlenerek kayıt güncelleme mesajı atılır. Bu çözüm her 50ms’de bir 500k abone taramak yerine, eğer olay yoksa 5 saniyede bir 6 bitlik olay bit haritasının, eğer olay varsa optimum sayıda abonenin taranmasına olanak sağlamıştır.
Performansı iyileştirmek için yapılan bir diğer çalışma ise IMS networküne kayıt olmak için atılan TCAP mesajlaşmasının da santraldaki hali hazırda akan trafiğe en az etkisi olacak şekilde geliştirilmesidir. Ofis ilk başlatıldığında çalıştırılan bakım işlemleri içinde aboneler sırayla çalışır hale geldikçe ilgili aboneler için gerekli TCAP mesajlaşmaları başlatılmış, bu sayede ofiste arama trafiği varken bu işlemlerin sisteme olan etkisi azaltılmıştır. Mesaj trafiğini azaltmak adına abonelerin IMS’e kayıt isteklerinin balya halinde gönderilmesi sağlanmıştır. Mesajlaşmalar süresince güncellenen AGCF verilerine daha hızlı erişim için AGCF veri tabanı ile direk bağlantı kurulmuştur. Bunun yanında TCAP mesajlaşması sırasında SST ile Çekirdek arasında oluşabilecek iletişim problemlerininin tespiti, bunlarla ilgili gerekli önlemlerin alınması ve sistemin olası hatalar karşısında kendi kendine devreye girip oluşmuş veri uyuşmazlıklarını gidermesi için denetim prosesi geliştirilmiştir.
Senaryolar Sistem boşta Manuel Denetim SST Bakım Çekirdek yeniden başlatma Çekirdek yeniden başlatma + SST Bakım Çekirdek yeniden başlatma + GWC bakım
Eski Ölçümler CPU %
Yeni Ölçümler CPU %
Gelişme Aver %36 %2.69 %2.35 %2.54 %2.26 %2.27
Max %39 %5.27 %8.88 %3.87 %3.83 %3.66
Aver %0 %1.41 %1.62 %1.87 %1.79 %1.92
Max %0 %1.56 %2.18 %2.77 %2.82 %2.72
Aver 100% 48% 31% 26% 21% 15%
Max 100% 70% 75% 28% 26% 26%
Tablo 1. Analiz sonuçları
Proje sonucunda elde edilen performans sonuçları Tablo 1 de gösterilmiştir. Tablonun ilk kolonunda 4. bölümün başında bahsedilen test senaryolarının bazıları, 2. ve 3. kolonlarda proje öncesi, 4. ve 5. kolonlarda proje sonrası AGCF işleminin harcadığı en yüksek ve ortalama CPU yüzdeleri, son iki kolonda ise performans iyileştirme oranı verilmiştir. Tabloda verilen senaryolar düşünüldüğünde santral büyük çoğunlukla sistem boşta durumundadır. Bakım ya da Çekirdek yeniden başlatma gibi diğer durumlara santralde ciddi problemler olduğunda başvurulur. Özellikle sistem kurtarma durumunda gerçekleşen toplu abone kayıt işlemlerinin santrale etkisinin gözlemlenmesi için seçilmiştir.
Sistem boşta testi saate 660K arama trafiği altında, mesajlaşmayı başlatacak herhangi bir olayın manuel olarak tetiklenmediği koşullarda mesajlaşma çok azken ya da yokken yapılmış ve analiz sonuçları yaklaşık 30 dakika boyunca 5 saniye aralıklara AGCF işleminin harcadığı CPU değerleri okunarak elde edilmiştir. Diğer testler yine ayni oranda arama trafiği altında ilgili olay tetiklenerek gerçekleştirilmiş, mesajlaşma süresi boyunca yine 5 saniye aralıklarla CPU değerleri toplanarak analiz edilmiştir.
Tabloda sistem boşta durumunda mesajlaşma çok azken ya da yokken 50ms de bir bütün abonelerin taranmasının sisteme etkisi görülmektedir. Daha efektif tarama sistemi ve yapılan diğer geliştirmeler sayesinde sistem boşta durumunda %100 oranda iyileştirme gözlemlenmiştir.
Tablodaki verilerden anlaşılacağı üzere yoğun mesajlaşmanın olduğu durumlardaki CPU değerleri mesajlaşma çok azken ya da yokken alınan CPU değerlerine göre daha azdır. Bunun nedeni daha önce bahsedilen AGCF kayıt işlemi zamanlama mekanizmasıdır. Çok yoğun mesajlaşma sırasında SST yeteri kadar hızlı cevap veremediği için mesajlar arasına konulan gecikmeler CPU kullanımını azaltmaktadır. Bu senaryolarda olduğu gibi toplu kayıt işlemlerinde tüm aboneler tarandığından dolayı tarama mekanizmasından çok yukarıda bahsedilen diğer geliştirmelerin etkisi olmuş ve %15 ila %50 oranlarında iyileştirme gözlemlenmiştir. 5
AGCF üzerinde yapılan geliştirmeler sonucunda abone sayısının 500 bine çıkarılması hem daha fazla mesajlaşma, hem de daha fazla abonenin taranmasını gerektirmektedir. Bu nedenle çekirdekteki kayıt işlemlerini yöneten mekanizmanın tekrar yapılandırılması ihtiyacı doğmuştur. Mevcut AGCF çözümünde CPU kaynaklarının kullanımının bazen %30’lara çıktığı yapılan analizler ile görülmüştür. Bu bağlamda AGCF çözümünün gerçek zamanlı performansının ve ürünün işlem kapasitesinin artırılmasına yönelik çalışmalar yapılmıştır. Uygulanan arama ve programlama teknikleri sayesinde bu çalışmada sunulan geliştirmelerin genel olarak sistem performansını senaryoya bağlı olarak %15 ila %100’e kadar oranlarda artırdığı fakat en büyük katkısının sistem boştayken özellikle kararsız hat durumlarının sisteme getirdiği yükü ortadan kaldırmak olduğu görülmüştür. Yaklaşım AGCF mimarisi ile ilintili olmayıp herhangi bir sistemde tarama gerektiren herhangi bir sürece uygulanabilecek niteliktedir.