a MESA Lab researcher's (name redacted) repo packages the NIST SP800-22 statistical randomness test suite (frequency, block-frequency, cusum, discrete Fourier transform, linear complexity, longest-run-of-ones, (non)overlapping template matchings, poker, random excursions, rank, runs, serial, universal, approximate entropy) as "MESA_sts", exposed with a documented "randomlooking check" with per-test-function enable switches (branch feature-add_switch_for_randomlooking), and tested against captured WeChat voice-call (MMTLS) and Telegram MTProto (IPv4/IPv6, multiple key-negotiation variants) traffic — i.e. a production statistical-randomness classifier for identifying fully-encrypted/obfuscated protocol traffic.

A MESA team ("第二研究室 Mesa团队", lead name redacted) technical overview describes the traffic-classification engine underlying TSG/sapp as performing deep field-level parsing across 29 protocols (HTTP with 32 standard + 400+ extended fields; SMTP/POP3/IMAP/DNS/FTP/RTSP/RTMP/HLS/DASH/ SSL/SSH/OpenVPN/BT etc.), and identifies VPN traffic specifically via a two-stage approach -- coarse protocol-signature classification followed by fine-grained statistical/behavioral-feature classification for traffic that can't be matched by signature alone.

A MESA graduate-project spec ("网络流量随机性检测技术研究与系统实现") calls for a prototype implementing 10+ classical statistical randomness tests (frequency, approximate-entropy, runs, matrix-rank, overlapping-subsequence, autocorrelation, etc., in C, 3000+ LOC) against TCP/UDP payloads to classify traffic as "encrypted data flow" (high entropy) vs. not, trained/validated on a 50GB+ labeled corpus of actively-generated encrypted and compressed traffic.

relationship-gtpc-user derives a single per-subscriber correlation key as Hashkey = md5(IMEI + IMSI + phone_number + vsys_id) from mobile-core GTP-C signaling, and a separate per-tunnel key gtp_uuid = md5(uplink_teid + "|" + downlink_teid). On every update it writes not just the primary user<->TEID row (tsg_galaxy:relation_user_teid) but up to four additional secondary-index rows into tsg_galaxy:gtpc_knowledge_base, one per identifier (IMEI, IMSI, phone number, APN) with a type-digit prefix ("0"/"1"/"2"/"3") and — for phone number and APN — the value's characters reversed before use as the row key, a range-scan-friendly key design that lets any of the four identifiers be used to look up the associated tunnel/session independently.

log-subscriber-hbase-datacenter is a Storm topology that, on a 300-second tick, scans a "national center" HBase cluster (national.hbase.zookeeper.servers) for subscriber_id/account rows changed in that window and replicates them into a separate "branch/regional datacenter" HBase cluster (center.hbase.zookeeper.servers, table sub:subscriber_info) — confirming a two-tier, hub-and-spoke data-federation architecture where subscriber-account correlation data is centrally maintained at a national level and periodically pushed down to per-datacenter local copies for regional/site-level querying.

radius-relationship-hbase and relationship-gtpc-user both ship byte-identical plaintext, hardcoded Kafka SASL credentials (a fixed admin username, product-branded password) in their default_config.properties — the same static credential shared verbatim across at least two independent TSG-OLAP pipeline components rather than injected per-deployment.

radius-account-knowledge decrypts its Kafka SASL credentials at runtime using a jasypt StandardPBEStringEncryptor whose password is the hardcoded literal string "galaxy", compiled directly into RadiusKnowledgeConfig.java — the same string used as the internal product/platform name throughout this corpus (Galaxy / tsg_galaxy HBase namespace), reused here as a shared symmetric secret rather than a deployment-specific one.