# HTS Analizi: Adli Bilişim Perspektifinden Trafik, Cihaz, Zaman, Konum ve İlişki Verilerinin İncelenmesi > HTS/CDR verisini trafik, cihaz, zaman, baz, konum ve ilişki boyutlarında; veri bütünlüğü, belirsizlik, korelasyon, grafik analizi ve adli yorum sınırlarıyla birlikte ele alan teknik ders notu. - Author: Muhammet Ali Köker - Language: tr - Canonical: https://alikoker.com.tr/hts-analizi - Translation: https://alikoker.com.tr/en/hts-analysis - Published: 2026-05-16T00:00:00+03:00 - Modified: 2026-09-09T00:00:00+03:00 - Verified: 2026-09-09T00:00:00+03:00 - Type: article > HTS/CDR verisi tek başına "kim, nerede, ne yaptı?" sorusuna kesin cevap veren bir kayıt değildir. Kaynağı, üretim biçimi, zaman ve konum belirsizliği, cihaz-hat ayrımı, iletişim grafiği ve hukuki bağlamı birlikte değerlendirilmesi gereken bir adli bilişim veri kümesidir. ### 1. Giriş HTS analizi, yüzlerce veya milyonlarca satırlık telefon trafik kaydını Excel üzerinde filtrelemekten ibaret değildir. Asıl problem, elektronik haberleşme sisteminin farklı katmanlarında üretilmiş kayıtların **hangi olayı temsil ettiğini, hangi olayı temsil etmediğini, birbirleriyle nasıl ilişkilendirilebileceğini ve bu ilişkiden ne ölçüde sonuç çıkarılabileceğini** belirlemektir. Adli bilişim uzmanı açısından temel ayrımlar şunlardır: ```text Kaynak kayıt ≠ yorum Baz kaydı ≠ kesin konum Abonelik ≠ fiilî kullanıcı IMEI ≠ kişi İletişim sayısı ≠ ilişkinin niteliği Korelasyon ≠ nedensellik Algoritmik aday ≠ adli sonuç ``` NIST dijital adli bilişimi; dijital verinin bütünlüğü korunarak tanımlanması, toplanması, incelenmesi ve analiz edilmesi, chain of custody, doğrulama, tekrarlanabilirlik ve raporlama ile birlikte ele alır. ISO/IEC 27037 potansiyel dijital delilin tanımlanması, toplanması, edinilmesi ve korunmasına; ISO/IEC 27042 ise analiz ve yorumun geçerlilik, yeniden üretilebilirlik ve tekrarlanabilirlik boyutlarına odaklanır.[1][2][3] Benim adli bilişim yaklaşımımda HTS incelemesi dört katmana ayrılır: ```text ÖZGÜN KAYNAK ↓ DETERMİNİSTİK / İZLENEBİLİR DÖNÜŞÜM ↓ ALGORİTMİK ÇIKARIM / ADAY ÜRETİMİ ↓ UZMAN DEĞERLENDİRMESİ ``` Bir numaranın kaynak dosyadaki değeri birinci katmandadır. `+90 5xx...` ile `05xx...` gösterimlerini aynı canonical numaraya dönüştürmek ikinci katmandadır. İki hattın iletişim kümelerinin Jaccard benzerliğini hesaplamak üçüncü katmandadır. Bunun soruşturma bağlamındaki anlamını değerlendirmek dördüncü katmandadır. Bu katmanların birbirine karıştırılmaması HTS analizinin temel ilkesidir: **verinin söylediğinden fazlasını söylememek; söylediği şeyi de kaybetmemek.** --- ## 2. HTS, CDR ve trafik verisi Türkiye'de uygulamada HTS ifadesi çoğunlukla **Geçmiş Trafik Sorgulama** kayıtlarını anlatır. Uluslararası teknik literatürde daha genel kavram Call Detail Record (CDR) ve trafik/charging kayıtlarıdır. 3GPP TS 32.298, Charging Data Record parametrelerini telekomünikasyon yönetimi ve ücretlendirme mimarisi içinde tanımlar; TS 32.297 CDR dosya biçimi ve aktarımıyla ilgilidir.[4][5] Adli makama gelen operatör çıktısı standardın bütün alanlarını içermek zorunda değildir. SWGDE, operatör kayıtlarının biçimlerinin farklılaşabildiğini; tarih-saat, kaynak/hedef numara, süre ve hücre/sektör gibi temel alanların ise yaygın olduğunu ve operatörün kayıt açıklama anahtarının yorum bakımından önemli olduğunu belirtir.[6] Avrupa ePrivacy Direktifi trafik verisini iletişimin iletilmesi veya ücretlendirilmesi amacıyla işlenen veri olarak tanımlar. Yönlendirme, süre, zaman, hacim, protokol, terminal konumu ve bağlantının başlangıç/bitişi trafik verisinin parçaları olabilir. Konum verisi terminal cihazının coğrafi konumunu belirten şebeke verisidir.[7] HTS esas olarak **metadata**dır. Çoğu durumda: - hangi numara, - hangi numarayla, - ne zaman, - hangi yönde, - ne kadar süre, - hangi cihaz kimliğiyle, - hangi hücre/baz bağlamında, - hangi iletişim türüyle etkileşim kurmuştur sorularına veri sağlar. Konuşmanın veya mesajın içeriğini HTS kaydından çıkarmak ise başka bir iddiadır ve standart trafik kaydıyla karıştırılmamalıdır. --- ## 3. Temel varlıklar: kişi, hat, SIM ve cihaz aynı şey değildir ### 3.1 MSISDN Telefon numarası analiz grafiğinin en görünür düğümüdür; fakat doğrudan kişi değildir. Hat başka biri tarafından kullanılabilir, kurumsal olabilir, aile içinde paylaşılabilir veya abonelik sahibi ile fiilî kullanıcı farklı olabilir. Bu nedenle: ```text subscriber(number) = X ```ile ```text user(number, t) = X ``` aynı önerme değildir. ### 3.2 IMSI IMSI mobil aboneliği/SIM'i şebeke düzeyinde tanımlar. Telefon numarasıyla aynı kavram değildir. Numara, abonelik ve cihaz ilişkisi zaman içinde değişebilir. ### 3.3 IMEI GSMA'ya göre IMEI 15 hanedir; ilk 8 hane TAC'tır ve cihazın üretici/model ailesini tanımlamak için kullanılır.[8] Adli model: ```text KİŞİ → HAT/SIM → CİHAZ ``` üç ayrı varlık içerir. Aynı IMEI'nin birden fazla numarayla görülmesi cihaz paylaşımı, SIM değişimi veya veri kalitesi problemi gibi farklı açıklamalara sahip olabilir. Aynı numaranın birden fazla IMEI ile görülmesi de cihaz değişimini gösterebilir. Bu nedenle `MSISDN ↔ IMEI` ilişkisi zaman aralığı olan bir ilişki olarak tutulmalıdır. --- ## 4. Baz istasyonu: konum değil, şebeke gözlemidir Baz/hücre verisi HTS analizinin en sık yanlış yorumlanan bölümüdür. SWGDE Historical Cell Site Analysis rehberi, CDR'nin belirli tarih ve saatte cihaz tarafından kullanılan hücre/sektörü gösterebildiğini; fakat cihazın kesin fiziksel konumunu, belirli bir adresi veya kavşağı tek başına belirlemediğini açıkça vurgular.[6] ```text “Cell X kullanılmıştır.” ```ile ```text “Cihaz Cell X'in koordinatındadır.” ``` aynı ifade değildir. Hücre seçimini etkileyebilecek faktörler: - RF yayılımı, - anten azimutu ve sektör, - frekans, - arazi ve yapılaşma, - şebeke yükü, - optimizasyon, - handover, - cihaz/radyo koşulları. RF saha ölçümü de geçmiş olay anını birebir yeniden üretmez; ölçüm anındaki RF ortamını örnekler.[6] --- ## 5. Hukuki çerçeve HTS teknik veri olsa da ilk soru algoritmik değildir: > **Veri hangi hukuki yetki ve süreçle elde edilmiştir?** Türkiye'de telekomünikasyon yoluyla iletişimin tespiti ve sinyal bilgilerinin değerlendirilmesinde CMK m.135 temel düzenlemelerden biridir. İletişimin tespiti, dinleme/kayda alma ve sinyal bilgisinin değerlendirilmesi aynı işlem değildir; somut tedbirin kapsamı ayrıca değerlendirilmelidir.[9][10] Anayasa Mahkemesi HTS kayıtlarının temini ve teknik analizine ilişkin kararlarında verinin elde edilme yöntemi, güvenilirliği, teknik anlamlandırılması ve savunmanın itiraz imkânı gibi unsurları birlikte ele almıştır. AYM'nin aktardığı Yargıtay yaklaşımında kişiselleştirilmiş ve ayrıntılı HTS raporlarının önemi de vurgulanmaktadır.[11] Elektronik haberleşme verileri kişisel veri ve haberleşmenin gizliliği bağlamındadır. BTK'nın açıklamalarında 5809 sayılı Kanun m.51 ve ilgili yönetmelik kapsamında amaçla bağlantılılık, sınırlılık, ölçülülük ve güvenlik ilkeleri vurgulanır.[12][13] Teknik zincir: ```text Yetki kapsamı ↓ Edinilen veri kapsamı ↓ Teknik bütünlük ↓ Analiz ↓ Yorum ↓ Rapor ``` --- ## 6. Delil yaşam döngüsü ve provenance Kaynak dosya geldiğinde ilk işlem tabloyu filtrelemek olmamalıdır. Kaydedilecek asgari metadata: ```text dosya adı dosya boyutu teslim zamanı teslim eden / alan dosya biçimi resmî yazı / talep referansı varsa sağlayıcı hash'i hesaplanan hash çalışma kopyası kimliği ``` SWGDE özgün elektronik kopyanın saklanmasını, çalışma kopyası kullanılmasını, hash ve chain-of-custody kayıtlarının korunmasını önerir.[6][14] ### 6.1 Hash ```text SHA-256(source.xlsx) = ... SHA-256(working-copy.xlsx) = ... ``` Hash byte bütünlüğünü destekler. Dosyanın maddi içeriğinin doğru yorumlandığını kanıtlamaz. ### 6.2 Kaynak ve türev ```text source.xlsx ↓ normalized dataset ↓ deduplicated dataset ↓ analysis tables ↓ graph / timeline / map ↓ report ``` Her türev kaynağa geri izlenebilmelidir. --- ## 7. ETL: analizden önce veri mühendisliği HTS analizinin en kritik fakat en görünmez kısmı Extract--Transform--Load sürecidir. ```text Dosya ↓ container / biçim doğrulama ↓ sheet ve başlık tanıma ↓ operatör/veri türü ↓ kolon eşleme ↓ satır ayrıştırma ↓ canonical veri ``` Farklı operatörlerin alan adları ve rapor biçimleri değişebildiğinden kaynak formatının açıklama anahtarı önemlidir.[6] ### 7.1 Canonical şema ```text record_id source_file source_row target_msisdn peer_msisdn event_type direction event_time duration_seconds target_imei peer_imei cell_id sector lac_tac cell_raw latitude longitude province district ip_address source_port destination_port subscriber_id subscriber_name operator ``` Temel kural: > Kaynak kolon kaybolmamalı; canonical değer kaynağa geri > izlenebilmelidir. --- ## 8. Normalizasyon ### 8.1 Telefon numarası ```text 05321234567 5321234567 905321234567 +905321234567 ``` aynı numarayı temsil edebilir. ```text normalize_msisdn(x): trim remove formatting apply documented country rule validate return canonical ``` Ülke bağlamı bilinmeden varsayım yapılmamalıdır. ### 8.2 IMEI IMEI matematiksel sayı değil kimliktir; string olarak korunmalıdır. Excel scientific notation riski vardır. Kontroller: ```text yalnız rakam? uzunluk? Luhn? TAC makul mü? scientific notation bozulması var mı? ``` Başarısız kontrol kaydı silmek için değil, kalite bayrağı üretmek için kullanılmalıdır. ### 8.3 Tarih-saat ```text 09.09.2026 14:05:01 2026-09-09 14:05:01 Excel serial date 09/09/26 14:05 ``` tek timestamp modeline çevrilir. Belgelenmesi gerekenler: - timezone, - saniye hassasiyeti, - timestamp'in başlangıç mı bitiş mi olduğu, - kaynak sistem semantiği. ### 8.4 Olay tipi ```text VOICE_OUT VOICE_IN SMS_OUT SMS_IN MISSED GPRS_SESSION WAP OTHER ``` Operatör kodu doğrulanmadan anlam atanmamalıdır. --- ## 9. Duplicate ve tekilleştirme Naif `SELECT DISTINCT *` her zaman doğru değildir. Aynı olay hedef ve karşı sorgularında veya tekrar dışa aktarımlarda görünebilir. Bir kopyada ek baz alanı bulunabilir. Aday anahtar: ```text target peer event_type timestamp duration cell imei ``` Akış: ```text ham veri ↓ duplicate candidate grouping ↓ alan bazlı karşılaştırma ↓ provenance koruma ↓ dedup görünüm ``` Ham ve dedup sonuçların ikisi de raporlanabilir. --- ## 10. Veri kalitesi analizi Analize başlamadan: ```text N_total N_invalid_time N_empty_target N_empty_peer N_invalid_msisdn N_invalid_imei N_missing_cell N_unresolved_cell N_duplicate_candidate N_unknown_event_type ``` ölçülmelidir. ```text q_{time}=1-frac{N_{invalid_time}}{N_{total}} ``` ```text q_{cell}=frac{N_{resolved_cell}}{N_{cell_records}} ``` Eksik veri oranı bilinmeden "eşleşme yok" sonucu güçlü yorumlanamaz. --- ## 11. Genel iletişim profili Bir hedef için: ```text toplam olay arama / aranma SMS gönderme / alma cevapsız toplam konuşma süresi benzersiz karşı numara benzersiz IMEI benzersiz baz aktif gün ilk kayıt son kayıt ``` çıkarılır. Bu aşama bulgu üretmekten çok veri setinin ölçek ve karakterini anlamaktır. --- ## 12. İrtibat analizi Her karşı numara için: ```text count_total count_out count_in count_sms duration_total first_seen last_seen distinct_days distinct_cells ``` hesaplanır. ```text C(u,v)=|{e:e=(u,v)}| ``` ```text D(u,v)=sum_{e=(u,v)} duration(e) ``` İletişim sayısı veya süre ilişkinin niteliğini tek başına belirlemez. --- ## 13. Top-N, tek görüşme ve uzun görüşme #### En çok görüşülen ```text GROUP BY peer ORDER BY COUNT(*) DESC ``` #### Bir kez görüşülen ```text GROUP BY peer HAVING COUNT(*) = 1 ``` #### En uzun tekil görüşme ```text FILTER voice FILTER duration > 0 ORDER BY duration DESC ``` `maksimum tekil süre` ile `toplam ilişki süresi` farklı metriklerdir. --- ## 14. İletişim yönü ve asimetri ```text O=giden,quad I=gelen ``` ```text A=(|O-I|)/(O+I) ``` `A → 0` dengeli, `A → 1` daha tek yönlü trafik örüntüsüdür. Bu yalnız iletişim yönü ölçüsüdür; ilişkinin sosyal/hukuki anlamı değildir. --- ## 15. Zaman analizi Saatlik yoğunluk: ```text H(h)=sum_i1(hour(t_i)=h) ``` Günlük yoğunluk: ```text D(d)=sum_i1(date(t_i)=d) ``` Hafta içi/hafta sonu, gün ve saat profilleri çıkarılabilir. Sabit "gece = anormal" kabulü yerine kişinin kendi baseline'ı tercih edilmelidir. --- ## 16. Aktivite kesintisi Sıralı zamanlar: ```text t_1= threshold: emit gap ``` Eşik, hattın normal kullanım sıklığıyla birlikte değerlendirilmelidir. --- ## 17. Olay öncesi ve sonrası Olay zamanı `t0`: ```text W_before = [t0 - Δb, t0) ``` ```text W_after = (t0, t0 + Δa] ``` Pencerelerde: - iletişim, - baz, - IMEI, - şehir, - karşı taraf değişimleri karşılaştırılır. Olay zamanına yakınlık nedensellik değildir. --- ## 18. İletişim grafiği ```text G=(V,E) ``` `V`: numaralar `E`: iletişim Edge özellikleri: ```text count duration first_seen last_seen direction distinct_days ``` Telekom literatüründe CDR üzerinden weighted graph, social-network similarity ve centrality ölçümleri yaygın biçimde kullanılmaktadır.[15] Yüksek degree veya centrality, kişinin sosyal/hukuki rolünü otomatik belirlemez. Çağrı merkezleri doğal olarak yüksek degree üretebilir. --- ## 19. Ortak irtibat ```text P_A=contacts(A),quad P_B=contacts(B) ``` ```text C=P_Acap P_B ``` Birden çok hedef: ```text C=bigcap_i P_i ``` Daha esnek model: ```text peer → kaç farklı hedefle iletişim kurdu? ``` Ortak irtibat yapısal bağlantıdır; ilişkinin niteliği ayrıca değerlendirilir. --- ## 20. Jaccard benzerliği ```text J(A,B)=(|Acap B|)/(|Acup B|) ``` Aynı yöntem: ```text contact_jaccard cell_jaccard district_jaccard ``` için kullanılabilir. Jaccard bir **benzerlik ölçüsü**, kimlik kararı değildir. --- ## 21. Sosyal yakınlık Özellik vektörü: ```text f1 = iletişim sayısı f2 = toplam süre f3 = farklı gün f4 = gece iletişimi f5 = karşılıklılık f6 = güncellik ``` ```text S(u,v)=sum_iw_i,norm(f_i) ``` Ağırlıklar gerekçelendirilmelidir. Skor, ilişkiyi sınıflandırmak yerine inceleme önceliği vermek için daha güvenli kullanılır. --- ## 22. Hedefler arası iletişim Hedef kümesi `T` için: ```text u ∈ T AND v ∈ T ``` olan edge'ler seçilir. Canonical pair: ```text (min(u,v), max(u,v)) ``` ile iki yön tek ilişki altında gruplanabilir; yön ayrıca korunur. --- ## 23. IMEI analizi ### 23.1 Numara → IMEI ```text IMEI first_seen last_seen event_count ``` ### 23.2 IMEI → numara ```text IMEI → {MSISDN1, MSISDN2, ...} ``` ### 23.3 Ortak IMEI ```text |Users(imei)|ge2 ``` ise ortak cihaz adayı vardır. Fakat zaman ayrımı kritiktir: ```text eşzamanlı kullanım ardışık kullanım ``` aynı anlamı taşımaz. ### 23.4 IMEI timeline ```text t1 A → IMEI-X t2 A → IMEI-Y t3 B → IMEI-X ``` aggregate tablodan daha açıklayıcı olabilir. --- ## 24. Olası aynı kullanıcı / Multi-SIM Telekom araştırmalarında aynı kullanıcının birden fazla SIM'ini tahmin etmek için sosyal ağ ve davranış benzerliği ölçümleri kullanılmaktadır.[15] Özellikler: ```text shared_imei contact_jaccard cell_jaccard district_jaccard temporal_complementarity same-time contradiction ``` Açıklanabilir model: ```text S=w_1I_{imei}+w_2J_{contact}+w_3J_{cell}+w_4J_{district}-w_5C_{contradiction} ``` Çıktı: > aynı kullanıcı hipotezi bakımından incelenecek aday hat çifti olmalıdır; "aynı kişidir" hükmü değil. --- ## 25. Sahiplik belirsizliği ve "patates hat" kavramı "Patates hat" teknik veya hukuki standart terim değildir. Uygulamada abonelik sahibi ile fiilî kullanıcı arasında güvenilir bağ kurulamadığı veya kimlik/kullanım örüntüsünün sahipliği sorgulattığı hatlar için argo biçimde kullanılabilir. Olası sinyaller: ```text kimlik alanı eksik/tutarsız isim var, güvenilir kimlik yok çok sık cihaz/SIM değişimi çok sayıda hatla ortak IMEI çok kısa yaşam döngüsü olay çevresinde açılma/kapanma çok dar irtibat kümesi tek yönlü/düşük hacimli kullanım ``` Hiçbiri tek başına yeterli değildir. ```text R=w_1IdentityRisk+w_2DeviceSharing+w_3EphemeralUse+w_4NetworkPattern ``` Bu bir **ranking score** olabilir; delil puanı değildir. --- ## 26. Baz analizi Her baz için: ```text count first_seen last_seen distinct_days province district coordinate ``` hesaplanır. Mümkünse teknik anahtar: ```text operator + LAC/TAC + Cell ID/ECGI + sector ``` kullanılır. Sadece adres metni kırılgandır. --- ## 27. Haversine mesafesi İki koordinat için: ```text a=sin^2(Deltavarphi/2)+cosvarphi_1cosvarphi_2sin^2(Deltalambda/2) ``` ```text d=2Rarcsin(sqrt a) ``` Bu iki baz koordinatı arasındaki geometrik mesafedir; cihazların gerçek uzaklığı veya RF kapsama mesafesi değildir. --- ## 28. Ortak baz analizi İki hedef: ```text A={(t,cell)} B={(t,cell)} ``` Temporal koşul: ```text |t_A-t_B|leDelta t ``` Spatial koşul: ```text same_cell ``` veya: ```text distance(cell_A,cell_B)le R ``` olabilir. ### Two-pointer ```text i = j = 0 while i < len(A) and j < len(B): dt = A[i].time - B[j].time if abs(dt) <= tolerance: evaluate spatial match elif dt < 0: i += 1 else: j += 1 ``` ### Çoklu hedef ```text PARTITION BY cell ORDER BY time SLIDING WINDOW Δt EMIT distinct user pairs AGGREGATE ``` Bu yaklaşım tüm kullanıcı çiftlerini naif biçimde karşılaştırmaktan daha ölçeklenebilirdir. --- ## 29. "Aynı baz"ın seviyeleri ```text 1. aynı Cell ID / sektör 2. aynı fiziksel site, farklı sektör 3. yakın fiziksel siteler ``` aynı şey değildir. Raporda "aynı baz"ın teknik tanımı açıkça yazılmalıdır. --- ## 30. Görüşme anı baz Çağrı `A → B, t0`. Hedef baz doğrudan kayıtlı olabilir. Karşı taraf için ayrı kayıt gerekiyorsa: ```text candidate=argmin|t_B-t_0| ``` ve: ```text |t_B-t_0|leDelta t ``` aranmalıdır. "En yakın kayıt" ile "aynı anda kayıt" aynı değildir. --- ## 31. Şehir değişimi Zaman dizisi: ```text Ankara Ankara Bolu Bolu İstanbul ``` sıkıştırılır: ```text Ankara → Bolu → İstanbul ``` Her transition: ```text from to last_seen_from first_seen_to Δt distance ``` ile tutulabilir. --- ## 32. Rota ve hareket HTS'den GPS rotası çıkarılmaz. Üretilen şey zaman sıralı hücre kullanım izidir: ```text (t1,cell1) (t2,cell2) ... ``` Görünür hız: ```text v=frac{distance(cell_i,cell_{i+1})}{t_{i+1}-t_i} ``` çok yüksekse veri hatası, hücre oscillation, saat farkı veya şebeke davranışı araştırılmalıdır. CDR tabanlı hareket araştırmaları konum belirsizliği ve hücre oscillation'ının işlenmemesinin hareket düzenliliğini olduğundan yüksek gösterebildiğini ortaya koymaktadır.[16] --- ## 33. Yaşam rutini Özellikler: ```text hour_of_day weekday/weekend cell distinct_days event_count ``` Örnek: ```text gece → Cell A → 24 farklı gün mesai → Cell B → 19 farklı hafta içi gün ``` Doğru yorum: > Cell A gece zaman diliminde tekrarlanan dominant hücredir. Yanlış kesinlik: > Cell A kişinin evidir. --- ## 34. Olay yeri ve kritik nokta yakınlığı Olay yeri `P0`: ```text d_i=distance(P_i,P_0) ``` `d_i ≤ R` ise hücre sitesi coğrafi adaydır. Bu **hücre sitesi yakınlığıdır**, cihazın olay yerinde olduğunun ölçümü değildir. POI analizi de: ```text havalimanı otogar otel hastane sınır kapısı özel nokta ``` gibi kümelerle metinsel veya coğrafi yapılabilir. --- ## 35. "Şahıs o an nerede?" sorusunun teknik karşılığı Doğru algoritma: ```text candidates = records where |event_time - t0| <= tolerance nearest = argmin |event_time - t0| ``` Çıktı: ```text t0 en yakın kayıt zamanı Δt cell/sector coordinate ``` Doğru cümle: > t0 zamanına en yakın HTS kaydı X hücresidir. SWGDE'nin kesin konum uyarısı burada özellikle geçerlidir.[6] --- ## 36. Konferans görüşmesi adayları Açık session ID yoksa çağrılar interval olarak modellenebilir: ```text I(c) = [start, start + duration] ``` Sweep-line: ```text call start/end events oluştur time'a göre sırala active call set tut eşzamanlı ilgili call sayısı eşiği aşarsa candidate üret ``` Bu yalnız zaman çakışmasıdır; operatör semantiği doğrulanmadan kesin konferans sonucu değildir. --- ## 37. Anomali tespiti Anomali "normal modele göre beklenmeyen" demektir; "suç" demek değildir. ### 37.1 Z-score ```text z=(x-mu)/(sigma) ``` ### 37.2 Robust MAD ```text MAD=median(|x_i-median(x)|) ``` ```text z_r=0.6745(x-median(x))/(MAD) ``` ### 37.3 Örnek anomaly feature'ları ```text beklenmeyen saat ani günlük yoğunluk yeni baz yeni IMEI uzun sessizlik olağandışı şehir geçişi ``` CDR trafik anomalilerinde zaman serisi, clustering ve tahmin yöntemleri akademik literatürde kullanılmaktadır.[17] ```text anomaly ≠ malicious anomaly ≠ criminal anomaly ≠ intentional ``` --- ## 38. GPRS, IP ve CGNAT Mobil internet analizinde yalnız public IP çoğu zaman yeterli değildir. CGNAT bağlamında: ```text public_ip source_port timestamp subscriber/private context ``` birlikte değerlendirilir. AYM/AİHM dosyalarında CGNAT, HTS, IMEI ve diğer teknik verilerin birlikte değerlendirildiği örnekler bulunmaktadır.[18] IP geolocation: ```text IP → kesin fiziksel adres ``` değildir. ASN/ISP, tahsis ve coğrafi tahmin farklı bilgi katmanlarıdır. --- ## 39. Abonelik sahibi ile fiilî kullanıcı Abonelik: ```text subscriber(number)=X ``` gösterebilir. Fiilî kullanıcı: ```text user(number,t)=X ``` için ek korelasyon gerekir. Sinyaller: - cihaz ilişkisi, - uzun dönem kullanım, - rutin, - doğrulanmış diğer hatlarla ilişki, - cihaz adli incelemesi, - başka dijital artefact, - tanık/ifade. SWGDE CDR'nin cihazı kullanan kişiyi kesin olarak göstermediğini belirtir.[6] --- ## 40. Kaynak--türev--yorum ayrımı Katman Örnek --------------------- ----------------------------------------- Kaynak 14:05'te Cell X kaydı Deterministik türev Cell X--olay yeri mesafesi 1,8 km Algoritmik çıkarım olay yeri yakınlık adayı Uzman yorumu diğer bulgularla birlikte değerlendirme Algoritma yorum yerine geçmemelidir. --- ## 41. False positive ve false negative ```text False Positive: algoritma işaretledi, bağlamda anlamlı değil False Negative: anlamlı örüntü var, algoritma işaretlemedi ``` Ortak bazda şehir merkezi yoğunluğu false-positive, seyrek kayıt false-negative riskini artırabilir. Sonuç ekranı eşleşmeyle birlikte veri kapsamını göstermelidir. --- ## 42. Güven skoru Açıklanabilir örnek: ```text Confidence=TemporalQualitytimes SpatialQualitytimes DataCompleteness ``` Zaman: ```text T=e^{-|Delta t|/tau} ``` Spatial sınıf: ```text aynı sektör aynı site yakın site ``` Bu değerler ancak tanımlanmış metodolojinin ranking parametreleridir; evrensel delil ağırlığı değildir. --- ## 43. Büyük veri ve performans Milyonlarca kayıt için veri mimarisi algoritma kadar önemlidir. İndeksler: ```text (target,event_time) (peer,event_time) (imei,event_time) (cell,event_time) (event_time) ``` Ön hesap: ```text contact_stats imei_usage cell_usage daily_activity hour_profile ``` Columnar storage, vectorized execution, predicate pushdown ve projection büyük CDR kümelerinde gereksiz veri taşınmasını azaltır. Temel ilke: > Hesaplamayı verinin bulunduğu yerde yap; gereksiz veriyi taşıma. --- ## 44. Graph centrality ve community detection Degree, weighted degree, betweenness veya PageRank benzeri ölçüler graph yapısındaki önemi ölçebilir. ```text yüksek centrality ≠ hukuki/sosyal liderlik ``` Louvain/Leiden gibi community detection algoritmaları yoğun bağlantı kümeleri üretebilir. Çıktı yalnız graph topluluğudur; aile, işyeri, servis veya başka bir bağlam olabilir. Adli kullanım: ```text candidate cluster → contextual/manual review ``` --- ## 45. Makine öğrenmesi Uygun alanlar: - anomaly ranking, - entity resolution, - graph embedding, - davranış kümeleme, - kalite sınıflandırması. Ancak: ```text model prediction ≠ source observation ``` Adli sistemde explainable-first yaklaşım çoğu durumda avantajlıdır: ```text SQL set intersection Jaccard Haversine sliding window simple statistics ``` ISO/IEC 27042'nin yeniden üretilebilirlik ve bağımsız inceleme ilkeleri bu yaklaşımı destekler.[2] --- ## 46. Doğrulama ve teknik review SWGDE historical cell-site analizinde sonuçların örnek veri üzerinde manuel haritalama veya farklı metodoloji kullanan araçla doğrulanabilmesini ve teknik review yapılmasını önerir.[6] Genel HTS doğrulama akışı: ```text 1. algoritmik sonuç üret 2. örneklem seç 3. kaynak satıra dön 4. elle yeniden hesapla 5. alternatif yöntemle karşılaştır 6. tutarsızlığı incele ``` --- ## 47. Reproducibility paketi ```text source_hashes.json analysis_config.json normalization_rules.md software_version.txt queries/ derived/ report/ ``` Örnek parametre: ```json { "time_tolerance_seconds": 120, "distance_radius_meters": 1000, "analysis_mode": "deduplicated", "timezone": "Europe/Istanbul" } ``` Parametre sonucu etkiliyorsa raporda görünmelidir. --- ## 48. Raporlama dili Kötü: > Şahıs olay yerindedir. Daha doğru: > Olay zamanına yakın zaman diliminde hedef hat için X hücresinin > kullanıldığı görülmüştür. Hücre kaydı cihazın kesin fiziksel konumunu > tek başına göstermediğinden bulgu diğer konum ve soruşturma > verileriyle birlikte değerlendirilmelidir. Kötü: > İki şahıs birlikte hareket etmiştir. Daha doğru: > İki hatta ait kayıtlarda belirtilen zaman toleransı içinde aynı > hücre/sektör eşleşmeleri tespit edilmiştir. Bu teknik korelasyon cihaz > kullanıcılarının kimliğini ve fiziksel birlikteliğini tek başına > belirlemez. --- ## 49. Raporun minimum içeriği ```text 1. İnceleme görevi 2. Teslim edilen materyal 3. Hash / bütünlük 4. Veri kaynağı ve kapsam 5. Araç ve sürüm 6. Normalizasyon 7. Ham/dedup modu 8. Parametre/eşikler 9. Bulgular 10. Kaynak satır referansları 11. Harita/grafik açıklamaları 12. Sınırlılıklar 13. Sonuç ``` --- ## 50. Harita ve RF sunumu Haritada: - ölçek, - kuzey, - koordinat sistemi, - baz/sektör, - zaman, - tolerans, - sembol anlamı görünmelidir. Bir hücreyi sabit yarıçaplı daireyle çizmek gerçek RF kapsamasının o daire olduğu anlamına gelmez. HTS geçmiş şebeke kaydıdır; RF survey belirli zamanda yapılan saha ölçümüdür. Aynı şey değildir.[6] --- ## 51. Çoklu veri korelasyonu HTS şu kaynaklarla birlikte değerlendirilebilir: ```text mobil cihaz adli imajı SIM artefact uygulama kayıtları CGNAT kamera araç verisi erişim kontrol logları tanık/ifade ``` NIST SP 800-101 mobil cihaz adli bilişimini cihaz üzerindeki dijital delilin forensically sound edinimi ve incelenmesi olarak ele alır.[19] ```text Cihaz forensics → endpoint artefact HTS/CDR → network/operator artefact ``` Çelişki varsa biri otomatik olarak yok sayılmamalıdır. --- ## 52. Hipotez ve karşı hipotez Örnek: > H1: Hat A ve B aynı kullanıcı tarafından dönüşümlü kullanılmış > olabilir. Test: ```text ortak IMEI? contact Jaccard? baz rutini? aynı anda uzak konum çelişkisi? abonelik? cihaz artefact'ı? ``` Karşı hipotez: > H0: Hatlar farklı kullanıcılarındır; benzerlik ortak sosyal/iş > çevresinden kaynaklanmaktadır. İyi analiz yalnız destekleyen bulguyu değil çelişkiyi de arar. --- ## 53. Veri minimizasyonu ve güvenlik HTS kayıtları ilgisiz kişilere ait veriler de içerebilir. Sistem: - role-based access, - audit, - proje izolasyonu, - export kontrolü, - amaçla sınırlı işleme, - retention uygulamalıdır. BTK/KVKK çerçevesindeki amaçla bağlantılı, sınırlı ve ölçülü işleme ilkeleri bu noktada önemlidir.[12][13] --- ## 54. Uçtan uca HTS algoritması ```text INPUT: source files legal scope event context 1. PRESERVE hash originals create working copies record provenance 2. DETECT identify provider/file type validate workbook structure 3. PARSE map source columns preserve source row identity 4. NORMALIZE MSISDN IMEI timestamp event type cell 5. VALIDATE missing/invalid/outlier fields duplicate candidates 6. ENRICH subscriber TAC cell coordinates province/district 7. BASELINE counts active days quality metrics 8. SINGLE-TARGET contacts time device cell route/routine 9. MULTI-TARGET common contacts common IMEI common cells internal graph 10. EVENT-CENTRIC before/after location proximity temporal windows 11. CANDIDATE GENERATION anomaly possible same user ownership uncertainty social proximity 12. VERIFY source sampling alternate method technical review 13. REPORT observation deterministic derivation algorithmic candidate expert interpretation limitations ``` --- ## 55. Sentetik örnek vaka ```text Hat A: 05xx...101 Hat B: 05xx...102 Hat C: 05xx...103 Olay: 28.08.2026 21:30 Yer: P0 ``` Kayıtlar: ```text A → Cell X, 21:17 B → Cell X, 21:19 C → Cell Y, 21:21 A ve B ortak IMEI-X'i farklı günlerde kullanmış. A ve B contact Jaccard = 0.68 A ve B cell Jaccard = 0.54 ``` Yanlış: > A ve B olay yerindeydi ve aynı kişidir. Teknik değerlendirme: 1. A ve B'nin aynı hücreyi yakın zamanlarda kullanması temporal-spatial korelasyondur. 2. Cell X'in olay yerine mesafesi ayrıca ölçülmelidir. 3. Hücre kullanımı kesin cihaz konumu değildir. 4. Ortak IMEI cihaz ilişkisidir. 5. Jaccard davranış benzerliğidir. 6. Aynı kullanıcı hipotezine karşı aynı anda farklı yerlerde kullanım aranmalıdır. 7. Sonuç diğer delillerle değerlendirilmelidir. Daha az iddialı ifade daha zayıf değildir; **daha denetlenebilir olduğu için daha güçlüdür.** --- ## 56. Sık yapılan hatalar 1. Baz kaydını GPS sanmak. 2. Abonelik sahibini otomatik fiilî kullanıcı kabul etmek. 3. Ortak IMEI'yi aynı kişi kararı saymak. 4. Çok görüşmeyi ilişkinin niteliği saymak. 5. Ortak irtibatı doğrudan örgütsel bağ saymak. 6. Algoritmik skoru delil puanı sanmak. 7. Dedup sırasında provenance kaybetmek. 8. Haritayı ölçümden daha kesin göstermek. 9. Yalnız hipotezi destekleyen bulguyu raporlamak. 10. `Δt`, `R` ve threshold gibi parametreleri gizlemek. 11. Eksik veri oranını hesaba katmamak. 12. Kaynak gözlem ile model/uzman yorumunu aynı cümlede eritmek. --- ## 57. Uzman kontrol listesi #### Kaynak - [ ] Özgün dosya korundu mu? - [ ] Hash alındı mı? - [ ] Chain of custody kayıtlı mı? - [ ] Sağlayıcı ve format belli mi? #### Normalizasyon - [ ] MSISDN kuralları belgeli mi? - [ ] IMEI identifier olarak korunuyor mu? - [ ] Timestamp semantiği belli mi? - [ ] Event mapping doğrulandı mı? - [ ] Baz anahtarı teknik olarak doğru mu? #### Analiz - [ ] Ham/dedup ayrımı belli mi? - [ ] Zaman toleransı raporlu mu? - [ ] Mesafe eşiği raporlu mu? - [ ] Eksik veri oranı biliniyor mu? - [ ] Karşı hipotez test edildi mi? #### Rapor - [ ] Kaynak gözlem ile yorum ayrıldı mı? - [ ] Harita sınırlılığı yazıldı mı? - [ ] Algoritma açıklanabilir mi? - [ ] Sonuç kaynak satıra geri izlenebilir mi? - [ ] Teknik review yapılabilir mi? --- ## 58. Sade ve kanıta dayalı yaklaşım HTS analizinde amaç daha az analiz yapmak değildir. Gereksiz iddiayı azaltıp kanıt zincirini güçlendirmektir. ```text Az varsayım. Açık veri. Açık dönüşüm. Açık parametre. Açık hata sınırı. Tekrarlanabilir sonuç. ``` İyi bir sistem yüzlerce grafik üretebilir. İyi bir adli bilişim uzmanı hangi grafiğin sorulan teknik soruya cevap verdiğini bilir. Bir milyon satır içinde önemli olan her satırı göstermek değil, sonucu üreten zinciri gösterebilmektir. --- ## 59. Sonuç HTS kaydı tek başına bir hikâye değildir. Şebekenin belirli olaylar sırasında ürettiği teknik izlerin zaman, cihaz, hat ve hücre ekseninde tutulmuş bir bölümüdür. Adli bilişim uzmanının görevi bu izleri önceden kurulmuş bir anlatıya zorlamak değil, şu zinciri korumaktır: ```text Kaynak ↓ Bütünlük ↓ Normalizasyon ↓ Doğrulama ↓ Korelasyon ↓ Algoritmik aday ↓ Karşı hipotez ↓ Uzman yorumu ↓ Sınırlılık ``` Bir kayıt bir hücrenin kullanıldığını söyleyebilir; kesin adresi söylemeyebilir. Bir IMEI iki hattı bağlayabilir; iki kişinin aynı kişi olduğunu söylemeyebilir. Graph ortak irtibatı gösterebilir; ilişkinin hukuki niteliğini belirleyemez. Anomali alışılmadık davranışı gösterebilir; suç kastını göstermez. Bu nedenle iyi HTS analizi daha çok kesin hüküm üreten analiz değildir. **Kaynağa geri dönebilen, algoritması açıklanabilen, parametreleri görülebilen, alternatif açıklamaları sınayan ve sonucunun sınırlarını açıkça söyleyen analizdir.** Adli bilişimde teknik yeterlilik yalnız veriden sonuç çıkarmak değildir; **hangi sonucun veriden çıkarılamayacağını da bilmektir.** --- ## Kaynakça 1. NIST, *Digital Forensics -- Glossary*. https://csrc.nist.gov/glossary/term/digital_forensics 2. ISO/IEC 27042:2015, *Guidelines for the analysis and interpretation of digital evidence*. https://www.iso.org/standard/44406.html 3. ISO/IEC 27037:2012, *Guidelines for identification, collection, acquisition and preservation of digital evidence*. https://www.iso.org/standard/44381.html 4. 3GPP TS 32.298, *Charging Data Record parameter description*. https://portal.3gpp.org/ 5. 3GPP TS 32.297, *Charging Data Record file format and transfer*. https://portal.3gpp.org/ 6. SWGDE, *Recommendations / Best Practices for Historical Cell Site Analysis*. https://www.swgde.org/documents/published-complete-listing/17-f-001-recommendations-for-historical-cell-site-analysis/ 7. European Parliament and Council, Directive 2002/58/EC. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058 8. GSMA Open Gateway, *Device Identifier / IMEI and TAC*. https://open-gateway.gsma.com/docs/device-identifier/api-reference 9. 5271 sayılı Ceza Muhakemesi Kanunu, m.135. 10. T.C. Adalet Bakanlığı, *Ceza Muhakemesi Hukuku* eğitim materyali. https://edb.adalet.gov.tr/ 11. T.C. Anayasa Mahkemesi, *Telekomünikasyon Yoluyla Yapılan İletişimin Tespitine İlişkin Kayıtların Elde Edilme Yöntemi İtibarıyla Adil Yargılanma Hakkının İhlal Edilmediği*. https://anayasa.gov.tr/ 12. Bilgi Teknolojileri ve İletişim Kurumu, *Kişisel Verilerin Korunması*. https://tuketici.btk.gov.tr/kisisel-verilerin-korunmasi 13. BTK, *Elektronik Haberleşme Sektöründe Kişisel Verilerin İşlenmesi ve Gizliliğin Korunmasına İlişkin Yönetmelik*. https://btk.gov.tr/yonetmelikler 14. SWGDE, *Best Practices for Digital Evidence Collection*. https://www.swgde.org/documents/published-complete-listing/18-f-002-2-0/ 15. Springer, *Social network analysis in Telecom data*, Journal of Big Data. https://link.springer.com/article/10.1186/s40537-019-0264-6 16. *On data processing required to derive mobility patterns from passively-generated mobile phone data*. https://pmc.ncbi.nlm.nih.gov/articles/PMC5789780/ 17. Mokhtari et al., *Aggregated Traffic Anomaly Detection Using Time Series Forecasting on Call Detail Records*. https://onlinelibrary.wiley.com/doi/10.1155/2022/1182315 18. European Court of Human Rights / HUDOC, telecommunications metadata, CGNAT, IMEI and HTS case materials. https://hudoc.echr.coe.int/ 19. NIST SP 800-101 Rev.1, *Guidelines on Mobile Device Forensics*. https://csrc.nist.gov/pubs/sp/800/101/r1/final 20. NIST/OSAC, *SWGDE Recommendations for Cell Site Analysis*. https://www.nist.gov/osac/standards-library/swgde-17-f-001-20 21. NIST, *Evidence Management*. https://www.nist.gov/forensic-science/interdisciplinary-topics/evidence-management 22. 3GPP TS 23.003, *Numbering, addressing and identification*. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729 23. KVKK, konum verisinin işlenmesine ilişkin kamuoyu duyurusu. https://www.kvkk.gov.tr/Icerik/6726/ 24. RFC 5737, *IPv4 Address Blocks Reserved for Documentation*. https://www.rfc-editor.org/rfc/rfc5737.html 25. ScienceDirect, *Development of multiple mobile networks call detailed records and its forensic analysis*. https://www.sciencedirect.com/science/article/pii/S235286481830124X 26. PLOS One, *Temporal social network modeling of mobile connectivity data with graph neural networks*. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0335267 --- HTS/CDR verisinin hukuki nitelendirmesi somut olay, güncel mevzuat ve yargı kararları çerçevesinde ayrıca değerlendirilmelidir. ## Bu Çalışmaya Atıf Köker, M. A. (2026). HTS Analizi: Adli Bilişim Perspektifinden Trafik, Cihaz, Zaman, Konum ve İlişki Verilerinin İncelenmesi. alikoker.com.tr. https://alikoker.com.tr/hts-analizi - BibTeX: https://alikoker.com.tr/hts-analizi.bib - RIS: https://alikoker.com.tr/hts-analizi.ris - CSL-JSON: https://alikoker.com.tr/hts-analizi.csl.json