HTS Analysis: Examining Traffic, Device, Time, Location, and Relationship Data from a Digital Forensics Perspective

HTS/CDR data is not, by itself, a record that gives a definitive answer to the question “who did what, where?” It is a digital-forensics data set whose source, method of generation, temporal and spatial uncertainty, device-line distinction, communication graph, and legal context must be evaluated together.

1. Introduction

HTS analysis is not merely filtering hundreds or millions of rows of telephone traffic records in Excel. The real problem is determining which event records produced at different layers of an electronic-communications system represent, which events they do not represent, how they can be related to one another, and how far conclusions can reasonably be drawn from those relationships.

From a digital-forensics perspective, the fundamental distinctions are:

text
Source record ≠ interpretation
Cell-site record ≠ exact location
Subscription ≠ actual user
IMEI ≠ person
Number of communications ≠ nature of the relationship
Correlation ≠ causation
Algorithmic candidate ≠ forensic conclusion

NIST treats digital forensics as the identification, collection, examination, and analysis of digital data while preserving its integrity, together with chain of custody, validation, reproducibility, and reporting. ISO/IEC 27037 focuses on the identification, collection, acquisition, and preservation of potential digital evidence; ISO/IEC 27042 focuses on validity, reproducibility, and repeatability in analysis and interpretation.[1][2][3]

In my approach to digital forensics, HTS examination is divided into four layers:

text
ORIGINAL SOURCE
     ↓
DETERMINISTIC / TRACEABLE TRANSFORMATION
     ↓
ALGORITHMIC INFERENCE / CANDIDATE GENERATION
     ↓
EXPERT ASSESSMENT

A telephone number as it appears in the source file belongs to the first layer. Converting +90 5xx... and 05xx... representations into the same canonical number belongs to the second. Computing the Jaccard similarity of the contact sets of two lines belongs to the third. Assessing what that similarity means in the context of an investigation belongs to the fourth.

Keeping these layers separate is a core principle of HTS analysis: do not say more than the data says, and do not lose what the data does say.

2. HTS, CDR, and traffic data

In Turkish practice, the term HTS generally refers to Historical Traffic Query records. In international technical literature, the broader concepts are Call Detail Records (CDR) and traffic/charging records.

3GPP TS 32.298 defines Charging Data Record parameters within telecommunications management and charging architectures; TS 32.297 addresses CDR file format and transfer.[4][5] An operator export delivered to a judicial authority does not have to contain every field defined by the standard. SWGDE notes that operator record formats can differ, while fields such as date-time, originating/destination number, duration, and cell/sector are common, and that the operator's record-description key is important for interpretation.[6]

The European ePrivacy Directive defines traffic data as data processed for the purpose of conveying a communication or billing for it. Routing, duration, time, volume, protocol, terminal location, and the beginning or end of a connection may form part of traffic data. Location data is network data indicating the geographic position of terminal equipment.[7]

HTS is primarily metadata. In most cases it provides data about:

• which number,
• communicated with which number,
• when,
• in which direction,
• for how long,
• with which device identifier,
• in which cell/base-station context,
• through which communication type.

Deriving the content of a call or message from an HTS record is a different claim and must not be confused with standard traffic records.

3. Core entities: person, line, SIM, and device are not the same thing

3.1 MSISDN

A telephone number is the most visible node in an analysis graph, but it is not directly a person. A line may be used by another person, may be corporate, may be shared within a family, or the subscriber and the actual user may be different.

Therefore:

text
subscriber(number) = X

and

text
user(number, t) = X

are not the same proposition.

3.2 IMSI

The IMSI identifies a mobile subscription/SIM at network level. It is not the same concept as a telephone number. The relationship between number, subscription, and device can change over time.

3.3 IMEI

According to GSMA, an IMEI contains 15 digits; the first 8 digits form the TAC and are used to identify the manufacturer/model family of the device.[8]

A forensic model contains three distinct entities:

text
PERSON → LINE/SIM → DEVICE

The same IMEI appearing with multiple numbers may have several explanations, including device sharing, SIM replacement, or a data-quality issue. The same number appearing with multiple IMEIs may likewise indicate a device change.

For this reason, the MSISDN ↔ IMEI relationship should be stored as a time-bounded relationship.

4. Base station: a network observation, not a location fix

Cell/base-station data is one of the most frequently misinterpreted parts of HTS analysis.

The SWGDE Historical Cell Site Analysis guidance explicitly emphasizes that a CDR may show the cell/sector used by a device at a particular date and time, but does not by itself establish the device's exact physical location, a particular address, or an intersection.[6]

text
“Cell X was used.”

and

text
“The device was at the coordinates of Cell X.”

are not equivalent statements.

Factors that may affect cell selection include:

• RF propagation,
• antenna azimuth and sector,
• frequency,
• terrain and built environment,
• network load,
• optimization,
• handover,
• device/radio conditions.

An RF field survey also does not reproduce the historical event moment exactly; it samples the RF environment at the time of measurement.[6]

5. Legal framework

Although HTS is technical data, the first question is not algorithmic:

Under what legal authority and process was the data obtained?

In Türkiye, Article 135 of the Code of Criminal Procedure is one of the principal provisions concerning the identification of telecommunications communications and the evaluation of signal information. Identification of communications, interception/recording, and evaluation of signal information are not the same measure; the scope of the concrete measure must be assessed separately.[9][10]

In decisions involving the acquisition and technical analysis of HTS records, the Constitutional Court of Türkiye has considered factors such as the method by which data was obtained, its reliability, its technical interpretation, and the defense's opportunity to challenge it. The approach of the Court of Cassation cited by the Constitutional Court also emphasizes the importance of individualized and detailed HTS reports.[11]

Electronic-communications data falls within the context of personal data and confidentiality of communications. BTK guidance emphasizes purpose limitation, relevance, proportionality, and security under Article 51 of Law No. 5809 and the relevant regulation.[12][13]

The technical chain is:

text
Scope of authority
   ↓
Scope of acquired data
   ↓
Technical integrity
   ↓
Analysis
   ↓
Interpretation
   ↓
Report

6. Evidence life cycle and provenance

When a source file is received, the first operation should not be to filter the table.

Minimum metadata to record includes:

text
file name
file size
time received
sender / receiver
file format
official request / reference
provider hash, if available
calculated hash
working-copy identifier

SWGDE recommends preserving the original electronic copy, using a working copy, and maintaining hash and chain-of-custody records.[6][14]

6.1 Hash

text
SHA-256(source.xlsx) = ...
SHA-256(working-copy.xlsx) = ...

A hash supports byte-level integrity. It does not prove that the substantive contents of the file have been interpreted correctly.

6.2 Source and derivative

text
source.xlsx
   ↓
normalized dataset
   ↓
deduplicated dataset
   ↓
analysis tables
   ↓
graph / timeline / map
   ↓
report

Every derivative should be traceable back to the source.

7. ETL: data engineering before analysis

The most critical yet least visible part of HTS analysis is the Extract--Transform--Load process.

text
File
 ↓
container / format validation
 ↓
sheet and header detection
 ↓
operator/data type
 ↓
column mapping
 ↓
row parsing
 ↓
canonical data

Because field names and report formats can differ among operators, the source format's description key is important.[6]

7.1 Canonical schema

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

Core rule:

A source column must not be lost; a canonical value must remain traceable to its source.

8. Normalization

8.1 Telephone number

text
05321234567
5321234567
905321234567
+905321234567

may represent the same number.

text
normalize_msisdn(x):
    trim
    remove formatting
    apply documented country rule
    validate
    return canonical

No country-specific assumption should be made when the country context is unknown.

8.2 IMEI

An IMEI is an identifier, not a mathematical number; it should be preserved as a string. Excel introduces a risk of scientific-notation corruption.

Checks may include:

text
digits only?
length?
Luhn?
is TAC plausible?
scientific-notation corruption?

A failed validation should be used to produce a quality flag, not to delete the record.

8.3 Date-time

text
09.09.2026 14:05:01
2026-09-09 14:05:01
Excel serial date
09/09/26 14:05

should be converted into a single timestamp model.

The following should be documented:

• timezone,
• second-level precision,
• whether the timestamp indicates the beginning or end of the event,
• source-system semantics.

8.4 Event type

text
VOICE_OUT
VOICE_IN
SMS_OUT
SMS_IN
MISSED
GPRS_SESSION
WAP
OTHER

Meaning should not be assigned until the operator code has been verified.

9. Duplicates and deduplication

A naive SELECT DISTINCT * is not always correct.

The same event may appear in target and counterpart queries or in repeated exports. One copy may contain additional cell-site fields.

Candidate key:

text
target
peer
event_type
timestamp
duration
cell
imei

Flow:

text
raw data
 ↓
duplicate-candidate grouping
 ↓
field-level comparison
 ↓
preserve provenance
 ↓
deduplicated view

Both raw and deduplicated results may be reported.

10. Data-quality analysis

Before analysis, the following should be measured:

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

text
q_{time}=1-frac{N_{invalid_time}}{N_{total}}

text
q_{cell}=frac{N_{resolved_cell}}{N_{cell_records}}

Without knowing the missing-data rate, a conclusion of “no match” cannot be interpreted strongly.

11. General communication profile

For a target, derive:

text
total events
outgoing / incoming calls
SMS sent / received
missed calls
total call duration
unique counterpart numbers
unique IMEIs
unique cells
active days
first record
last record

At this stage, the goal is less to generate findings than to understand the scale and character of the data set.

12. Contact analysis

For each counterpart number, compute:

text
count_total
count_out
count_in
count_sms
duration_total
first_seen
last_seen
distinct_days
distinct_cells

text
C(u,v)=|{e:e=(u,v)}|

text
D(u,v)=sum_{e=(u,v)} duration(e)

Communication count or duration alone does not determine the nature of a relationship.

13. Top-N, one-time, and long calls

Most frequently contacted

text
GROUP BY peer
ORDER BY COUNT(*) DESC

Contacted once

text
GROUP BY peer
HAVING COUNT(*) = 1

Longest individual call

text
FILTER voice
FILTER duration > 0
ORDER BY duration DESC

maximum individual duration and total relationship duration are different metrics.

14. Communication direction and asymmetry

text
O=outgoing,quad I=incoming

text
A=(|O-I|)/(O+I)

A → 0 indicates more balanced traffic, while A → 1 indicates a more one-sided traffic pattern.

This measures only communication direction; it does not determine the social or legal meaning of the relationship.

15. Temporal analysis

Hourly activity:

text
H(h)=sum_i1(hour(t_i)=h)

Daily activity:

text
D(d)=sum_i1(date(t_i)=d)

Weekday/weekend, day, and hour profiles can be derived. Rather than assuming a fixed rule such as “night = anomalous,” the subject's own baseline should be preferred.

16. Activity gaps

For ordered timestamps:

text
t_1<t_2<...<t_n

text
gap_i=t_{i+1}-t_i

If gap_i ≥ T, it is a candidate inactivity interval.

text
sort by time
for adjacent events:
    gap = next - current
    if gap >= threshold:
        emit gap

The threshold should be interpreted together with the line's normal usage frequency.

17. Before and after an event

For event time t0:

text
W_before = [t0 - Δb, t0)

text
W_after = (t0, t0 + Δa]

Compare changes in:

• communication,
• cell,
• IMEI,
• city,
• counterpart

within these windows.

Temporal proximity to an event is not causation.

18. Communication graph

text
G=(V,E)

V: numbers E: communications

Edge properties may include:

text
count
duration
first_seen
last_seen
direction
distinct_days

Weighted graphs, social-network similarity, and centrality measures are widely used in telecommunications research on CDR data.[15]

High degree or centrality does not automatically determine a person's social or legal role. Call centers, for example, naturally produce high degree.

19. Common contacts

text
P_A=contacts(A),quad P_B=contacts(B)

text
C=P_Acap P_B

For multiple targets:

text
C=bigcap_i P_i

A more flexible model is:

text
peer → how many different targets did this peer communicate with?

A common contact is a structural connection; the nature of the relationship must be assessed separately.

20. Jaccard similarity

text
J(A,B)=(|Acap B|)/(|Acup B|)

The same method can be used for:

text
contact_jaccard
cell_jaccard
district_jaccard

Jaccard is a similarity measure, not an identity decision.

21. Social proximity

Feature vector:

text
f1 = communication count
f2 = total duration
f3 = distinct days
f4 = nighttime communications
f5 = reciprocity
f6 = recency

text
S(u,v)=sum_iw_i,norm(f_i)

Weights must be justified. A score is safer when used to prioritize review rather than to classify the relationship itself.

22. Communication between targets

For a target set T, select edges satisfying:

text
u ∈ T AND v ∈ T

A canonical pair:

text
(min(u,v), max(u,v))

can group both directions under one relationship while preserving direction separately.

23. IMEI analysis

23.1 Number → IMEI

text
IMEI
first_seen
last_seen
event_count

23.2 IMEI → number

text
IMEI → {MSISDN1, MSISDN2, ...}

23.3 Shared IMEI

text
|Users(imei)|ge2

indicates a candidate shared device.

But temporal separation is critical:

text
simultaneous use
sequential use

do not carry the same meaning.

23.4 IMEI timeline

text
t1 A → IMEI-X
t2 A → IMEI-Y
t3 B → IMEI-X

may be more informative than an aggregate table.

24. Possible same user / Multi-SIM

Telecommunications research uses social-network and behavioral-similarity measures to estimate whether multiple SIMs may belong to the same user.[15]

Features may include:

text
shared_imei
contact_jaccard
cell_jaccard
district_jaccard
temporal_complementarity
same-time contradiction

An explainable model is:

text
S=w_1I_{imei}+w_2J_{contact}+w_3J_{cell}+w_4J_{district}-w_5C_{contradiction}

The output should be:

a candidate pair of lines to review under the same-user hypothesis

not a conclusion that “they are the same person.”

25. Ownership uncertainty and the colloquial “anonymous line” concept

The Turkish expression “patates hat” is neither a technical nor a legal standard term. In practice, it may be used colloquially for lines where a reliable link between the subscriber and the actual user cannot be established, or where identity and usage patterns make ownership questionable.

Possible signals include:

text
missing/inconsistent identity fields
name present but no reliable identity
very frequent device/SIM changes
shared IMEI across many lines
very short life cycle
activation/deactivation around an event
very narrow contact set
one-sided/low-volume use

None is sufficient by itself.

text
R=w_1IdentityRisk+w_2DeviceSharing+w_3EphemeralUse+w_4NetworkPattern

This may be a ranking score; it is not an evidence score.

26. Cell-site analysis

For each cell/base station, calculate:

text
count
first_seen
last_seen
distinct_days
province
district
coordinate

Where possible, use a technical key such as:

text
operator + LAC/TAC + Cell ID/ECGI + sector

Address text alone is fragile.

27. Haversine distance

For two coordinates:

text
a=sin^2(Deltavarphi/2)+cosvarphi_1cosvarphi_2sin^2(Deltalambda/2)

text
d=2Rarcsin(sqrt a)

This is the geometric distance between two cell-site coordinates; it is not the actual distance between devices or an RF coverage radius.

28. Common cell-site analysis

For two targets:

text
A={(t,cell)}
B={(t,cell)}

Temporal condition:

text
|t_A-t_B|leDelta t

Spatial condition may be:

text
same_cell

or:

text
distance(cell_A,cell_B)le R

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

Multiple targets

text
PARTITION BY cell
ORDER BY time
SLIDING WINDOW Δt
EMIT distinct user pairs
AGGREGATE

This approach scales better than naively comparing every pair of users.

29. Levels of “same cell/base station”

text
1. same Cell ID / sector
2. same physical site, different sector
3. nearby physical sites

are not the same thing.

A report should state explicitly what “same base station” means technically.

30. Cell at the time of a call

Assume a call A → B, t0.

The target cell may be recorded directly. If the counterpart requires a separate record, search for:

text
candidate=argmin|t_B-t_0|

subject to:

text
|t_B-t_0|leDelta t

“The nearest record” and “a record at the same time” are not equivalent.

31. City transitions

A time-ordered sequence:

text
Ankara
Ankara
Bolu
Bolu
Istanbul

can be compressed to:

text
Ankara → Bolu → Istanbul

Each transition can be stored with:

text
from
to
last_seen_from
first_seen_to
Δt
distance

32. Route and movement

HTS does not yield a GPS route. What it yields is a time-ordered trace of cell usage:

text
(t1,cell1)
(t2,cell2)
...

Apparent speed:

text
v=frac{distance(cell_i,cell_{i+1})}{t_{i+1}-t_i}

If it is implausibly high, possible explanations such as data error, cell oscillation, clock differences, or network behavior should be investigated.

Research on CDR-based mobility has shown that failure to account for location uncertainty and cell oscillation can make mobility regularity appear stronger than it actually is.[16]

33. Routine analysis

Possible features include:

text
hour_of_day
weekday/weekend
cell
distinct_days
event_count

Example:

text
night → Cell A → 24 distinct days
working hours → Cell B → 19 distinct weekdays

Appropriate interpretation:

Cell A is the recurring dominant cell during nighttime hours.

Overstated interpretation:

Cell A is the person's home.

34. Proximity to an event location or critical point

For event location P0:

text
d_i=distance(P_i,P_0)

If d_i ≤ R, the cell site is a geographic candidate.

This is cell-site proximity, not a measurement proving that the device was at the event location.

POI analysis may likewise be performed textually or geographically using classes such as:

text
airport
bus terminal
hotel
hospital
border crossing
special point of interest

35. The technical meaning of “where was the person at that time?”

An appropriate algorithm is:

text
candidates =
    records where |event_time - t0| <= tolerance

nearest =
    argmin |event_time - t0|

Output:

text
t0
nearest record time
Δt
cell/sector
coordinate

Appropriate wording:

The HTS record nearest to time t0 is associated with Cell X.

SWGDE's warning about precise location is particularly important here.[6]

36. Conference-call candidates

If no explicit session ID exists, calls can be modeled as intervals:

text
I(c) = [start, start + duration]

Sweep-line approach:

text
create call start/end events
sort by time
maintain active call set
if concurrent relevant-call count exceeds threshold, emit candidate

This indicates temporal overlap only; without validated operator semantics it is not a definitive conference-call conclusion.

37. Anomaly detection

An anomaly means “unexpected relative to the normal model”; it does not mean “criminal.”

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 Example anomaly features

text
unexpected hour
sudden daily activity spike
new cell
new IMEI
long silence
unusual city transition

Time-series, clustering, and forecasting methods are used in the academic literature for CDR traffic anomaly analysis.[17]

text
anomaly ≠ malicious
anomaly ≠ criminal
anomaly ≠ intentional

38. GPRS, IP, and CGNAT

In mobile-internet analysis, a public IP address alone is often insufficient.

In a CGNAT context, evaluate together:

text
public_ip
source_port
timestamp
subscriber/private context

There are Constitutional Court and ECHR case materials in which CGNAT, HTS, IMEI, and other technical data are considered together.[18]

IP geolocation is not:

text
IP → exact physical address

ASN/ISP information, allocation data, and geographic estimates are different information layers.

39. Subscriber versus actual user

Subscription data may show:

text
subscriber(number)=X

Establishing:

text
user(number,t)=X

requires additional correlation.

Possible signals include:

• device relationships,
• long-term usage,
• routines,
• relationships with other verified lines,
• device forensic examination,
• other digital artifacts,
• witness statements/testimony.

SWGDE notes that CDR data does not conclusively establish the identity of the person using a device.[6]

40. Separating source, derivative, and interpretation

Layer Example ---------------------- ----------------------------------------- Source Cell X record at 14:05 Deterministic derivative Distance from Cell X to event location: 1.8 km Algorithmic inference event-location proximity candidate Expert interpretation assessment together with other findings

An algorithm should not replace interpretation.

41. False positives and false negatives

text
False Positive:
algorithm flagged it, but it is not meaningful in context

False Negative:
a meaningful pattern exists, but the algorithm did not flag it

In common-cell analysis, dense urban environments may increase false positives, while sparse records may increase false negatives.

A results screen should display data coverage together with matches.

42. Confidence score

One explainable example is:

text
Confidence=TemporalQualitytimes SpatialQualitytimes DataCompleteness

Temporal component:

text
T=e^{-|Delta t|/tau}

Spatial classes:

text
same sector
same site
nearby site

Such values are ranking parameters only within a defined methodology; they are not universal evidentiary weights.

43. Big data and performance

For millions of records, data architecture is as important as the algorithm.

Indexes:

text
(target,event_time)
(peer,event_time)
(imei,event_time)
(cell,event_time)
(event_time)

Precomputed structures:

text
contact_stats
imei_usage
cell_usage
daily_activity
hour_profile

Columnar storage, vectorized execution, predicate pushdown, and projection reduce unnecessary data movement in large CDR data sets.

Core principle:

Perform computation where the data resides; do not move data unnecessarily.

44. Graph centrality and community detection

Degree, weighted degree, betweenness, or PageRank-like measures may quantify structural importance in a graph.

text
high centrality ≠ legal/social leadership

Community-detection algorithms such as Louvain or Leiden can produce densely connected clusters. The output is only a graph community; it may correspond to a family, workplace, service, or another context.

Forensic use:

text
candidate cluster → contextual/manual review

45. Machine learning

Suitable application areas include:

• anomaly ranking,
• entity resolution,
• graph embedding,
• behavioral clustering,
• quality classification.

However:

text
model prediction ≠ source observation

In forensic systems, an explainable-first approach is often advantageous:

text
SQL
set intersection
Jaccard
Haversine
sliding window
simple statistics

The reproducibility and independent-review principles of ISO/IEC 27042 support this approach.[2]

46. Validation and technical review

SWGDE recommends that historical cell-site-analysis results be verifiable on sample data through manual mapping or a tool using a different methodology, and that technical review be performed.[6]

A general HTS validation flow is:

text
1. produce algorithmic result
2. select sample
3. return to source row
4. recompute manually
5. compare with an alternative method
6. investigate discrepancies

47. Reproducibility package

text
source_hashes.json
analysis_config.json
normalization_rules.md
software_version.txt
queries/
derived/
report/

Example parameters:

json
{
  "time_tolerance_seconds": 120,
  "distance_radius_meters": 1000,
  "analysis_mode": "deduplicated",
  "timezone": "Europe/Istanbul"
}

If a parameter can affect the result, it should be visible in the report.

48. Reporting language

Poor wording:

The person was at the event location.

More appropriate wording:

Records for the target line show use of Cell X within a time interval close to the event. Because a cell-site record does not by itself establish the device's precise physical location, this finding should be evaluated together with other location and investigative data.

Poor wording:

The two persons moved together.

More appropriate wording:

Records for the two lines contain same-cell/sector matches within the stated temporal tolerance. This technical correlation does not by itself establish the identities of the device users or their physical co-presence.

49. Minimum report contents

text
1. Examination task
2. Submitted material
3. Hash / integrity
4. Data source and scope
5. Tool and version
6. Normalization
7. Raw/deduplicated mode
8. Parameters/thresholds
9. Findings
10. Source-row references
11. Map/graph explanations
12. Limitations
13. Conclusion

50. Map and RF presentation

A map should show:

• scale,
• north,
• coordinate system,
• cell/sector,
• time,
• tolerance,
• meaning of symbols.

Drawing a cell as a circle with a fixed radius does not mean that the real RF coverage is that circle.

HTS is a historical network record; an RF survey is a field measurement made at a specific time. They are not the same thing.[6]

51. Multi-source correlation

HTS may be evaluated together with sources such as:

text
mobile-device forensic image
SIM artifacts
application records
CGNAT
camera footage
vehicle data
access-control logs
witness statement/testimony

NIST SP 800-101 treats mobile-device forensics as the forensically sound acquisition and examination of digital evidence on a device.[19]

text
Device forensics → endpoint artifact
HTS/CDR          → network/operator artifact

If sources conflict, one should not automatically be discarded.

52. Hypothesis and counter-hypothesis

Example:

H1: Lines A and B may have been used alternately by the same user.

Test:

text
shared IMEI?
contact Jaccard?
cell routine?
same-time distant-location contradiction?
subscription?
device artifact?

Counter-hypothesis:

H0: The lines belong to different users; the similarity results from a shared social or work environment.

Good analysis looks not only for supporting findings, but also for contradictions.

53. Data minimization and security

HTS records may also contain data relating to people who are irrelevant to the investigation.

The system should enforce:

• role-based access,
• audit,
• project isolation,
• export control,
• purpose-limited processing,
• retention controls.

The principles of purpose limitation, relevance, necessity, and proportionality under the BTK/KVKK framework are important here.[12][13]

54. End-to-end HTS algorithm

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. Synthetic example case

text
Line A: 05xx...101
Line B: 05xx...102
Line C: 05xx...103
Event: 28.08.2026 21:30
Location: P0

Records:

text
A → Cell X, 21:17
B → Cell X, 21:19
C → Cell Y, 21:21

A and B used the same IMEI-X on different days.
A and B contact Jaccard = 0.68
A and B cell Jaccard = 0.54

Incorrect conclusion:

A and B were at the event location and are the same person.

Technical assessment:

1. A and B using the same cell at nearby times is a temporal-spatial correlation.
2. The distance from Cell X to the event location should be measured separately.
3. Cell usage is not an exact device location.
4. A shared IMEI is a device relationship.
5. Jaccard is a behavioral-similarity measure.
6. The same-user hypothesis should be tested against simultaneous use in geographically distant locations.
7. The result should be evaluated together with other evidence.

Less assertive wording is not weaker; it is stronger because it is more auditable.

56. Common mistakes

1. Treating a cell-site record as GPS.
2. Automatically treating the subscriber as the actual user.
3. Treating a shared IMEI as proof of the same person.
4. Treating a high communication count as the nature of a relationship.
5. Treating a common contact as direct proof of an organizational link.
6. Treating an algorithmic score as an evidence score.
7. Losing provenance during deduplication.
8. Presenting a map as more precise than the underlying measurement.
9. Reporting only findings that support the hypothesis.
10. Hiding parameters such as Δt, R, and thresholds.
11. Ignoring the missing-data rate.
12. Collapsing source observation and model/expert interpretation into the same sentence.

57. Expert checklist

Source

• [ ] Was the original file preserved?
• [ ] Was a hash calculated?
• [ ] Is chain of custody recorded?
• [ ] Are the provider and format known?

Normalization

• [ ] Are MSISDN rules documented?
• [ ] Is IMEI preserved as an identifier?
• [ ] Are timestamp semantics known?
• [ ] Was event mapping verified?
• [ ] Is the cell key technically correct?

Analysis

• [ ] Is the raw/deduplicated distinction clear?
• [ ] Is the temporal tolerance reported?
• [ ] Is the distance threshold reported?
• [ ] Is the missing-data rate known?
• [ ] Was the counter-hypothesis tested?

Report

• [ ] Are source observations separated from interpretation?
• [ ] Are map limitations stated?
• [ ] Is the algorithm explainable?
• [ ] Can the result be traced back to source rows?
• [ ] Can a technical review be performed?

58. A concise, evidence-based approach

The aim in HTS analysis is not to perform less analysis. It is to reduce unnecessary claims while strengthening the evidentiary chain.

text
Few assumptions.
Explicit data.
Explicit transformation.
Explicit parameters.
Explicit error bounds.
Reproducible results.

A good system can produce hundreds of charts. A good digital-forensics specialist knows which chart answers the technical question actually being asked.

Among a million rows, the important point is not to display every row, but to be able to show the chain that produced the result.

59. Conclusion

An HTS record is not a story by itself. It is a recorded portion of the technical traces generated by a network during particular events, organized along the axes of time, device, line, and cell.

The task of the digital-forensics specialist is not to force those traces into a pre-established narrative, but to preserve the following chain:

text
Source
 ↓
Integrity
 ↓
Normalization
 ↓
Verification
 ↓
Correlation
 ↓
Algorithmic candidate
 ↓
Counter-hypothesis
 ↓
Expert interpretation
 ↓
Limitations

A record may show that a cell was used; it may not establish an exact address. An IMEI may link two lines; it may not establish that two people are the same person. A graph may show a common contact; it cannot determine the legal nature of the relationship. An anomaly may show unusual behavior; it does not show criminal intent.

Good HTS analysis is therefore not analysis that produces more definitive judgments. It is analysis that can return to the source, explain its algorithm, expose its parameters, test alternative explanations, and state the limits of its conclusions clearly.

Technical competence in digital forensics is not only the ability to derive conclusions from data; it is also knowing which conclusions cannot be derived from the data.

References

1. NIST, Digital Forensics -- Glossary.

https://csrc.nist.gov/glossary/term/digital_forensics

1. ISO/IEC 27042:2015, *Guidelines for the analysis and interpretation

of digital evidence*. https://www.iso.org/standard/44406.html

1. ISO/IEC 27037:2012, *Guidelines for identification, collection,

acquisition and preservation of digital evidence*. https://www.iso.org/standard/44381.html

1. 3GPP TS 32.298, Charging Data Record parameter description.

https://portal.3gpp.org/

1. 3GPP TS 32.297, Charging Data Record file format and transfer.

https://portal.3gpp.org/

1. 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/

1. European Parliament and Council, Directive 2002/58/EC.

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058

1. GSMA Open Gateway, Device Identifier / IMEI and TAC.

https://open-gateway.gsma.com/docs/device-identifier/api-reference

1. Turkish Code of Criminal Procedure No. 5271, Article 135.
2. Republic of Türkiye Ministry of Justice, Criminal Procedure Law training material.

https://edb.adalet.gov.tr/

1. Constitutional Court of Türkiye, decision concerning whether the method of obtaining records relating to the identification of telecommunications communications violated the right to a fair trial.

https://anayasa.gov.tr/

1. Information and Communication Technologies Authority (BTK), Protection of Personal Data.

https://tuketici.btk.gov.tr/kisisel-verilerin-korunmasi

1. BTK, Regulation on the Processing of Personal Data and Protection of Privacy in the Electronic Communications Sector.

https://btk.gov.tr/yonetmelikler

1. SWGDE, Best Practices for Digital Evidence Collection.

https://www.swgde.org/documents/published-complete-listing/18-f-002-2-0/

1. Springer, Social network analysis in Telecom data, Journal of Big

Data. https://link.springer.com/article/10.1186/s40537-019-0264-6

1. *On data processing required to derive mobility patterns from

passively-generated mobile phone data*. https://pmc.ncbi.nlm.nih.gov/articles/PMC5789780/

1. Mokhtari et al., *Aggregated Traffic Anomaly Detection Using Time

Series Forecasting on Call Detail Records*. https://onlinelibrary.wiley.com/doi/10.1155/2022/1182315

1. European Court of Human Rights / HUDOC, telecommunications metadata,

CGNAT, IMEI and HTS case materials. https://hudoc.echr.coe.int/

1. NIST SP 800-101 Rev.1, Guidelines on Mobile Device Forensics.

https://csrc.nist.gov/pubs/sp/800/101/r1/final

1. NIST/OSAC, SWGDE Recommendations for Cell Site Analysis.

https://www.nist.gov/osac/standards-library/swgde-17-f-001-20

1. NIST, Evidence Management.

https://www.nist.gov/forensic-science/interdisciplinary-topics/evidence-management

1. 3GPP TS 23.003, Numbering, addressing and identification.

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729

1. Personal Data Protection Authority of Türkiye (KVKK), public announcement concerning the processing of location data.

https://www.kvkk.gov.tr/Icerik/6726/

1. RFC 5737, IPv4 Address Blocks Reserved for Documentation.

https://www.rfc-editor.org/rfc/rfc5737.html

1. ScienceDirect, *Development of multiple mobile networks call

detailed records and its forensic analysis*. https://www.sciencedirect.com/science/article/pii/S235286481830124X

1. 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

The legal characterization of HTS/CDR data should be assessed separately in light of the concrete case, current legislation, and applicable judicial decisions.