Generation TV Polaris Building Room: FTG13 June 11, 10:30 - 12:30 Sungho Jeon, Seongman Min, Moonsun Kang, Jae Hun You (KBS), Sunhyung Kwon, Sung-Ik Park (ETRI) The 20th IEEE International Symposium on Broadband Multimedia Systems and Broadcasting will be held in the Faculty of Engineering and Computing, Dublin City University, Ireland, from 11-13 June 2025.
Unit Standardization of ATSC 3.0 Monitoring Integrated Monitoring Dashboard Remote Monitoring Device with GPS Synchronization for Transmitter Stations Remote Monitoring Unit with PTP Synchronization for Broadcast Headend Network-Topology based Dashboard Real-time Measurement Performance Indicators Leading Domestic Standards Development Ahead of North America Monitoring Guideline for Terrestrial UHD Systems Guideline for TxIDand BSID Assignment of Terrestrial UHD Systems As of 11:00 AM, March 5, 2025, 68,000 hours have elapsed ✓ KBS has maintained continuous 24/7 operation since the world's first ATSC 3.0 terrestrial broadcast launch in May 2017. ✓ Leveraging years of stable nationwide SFN operation, KBS leads the development and standardization of advanced monitoring systems. [1] Sungho Jeon, et. al., “Simple Anomaly Detection Technique from Long-term Time-series Data by ATSC 3.0 Single Frequency Broadcast Network Monitoring System,” in The 18th IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB 2023), Beijing, China, June 2023. [2] Sungho Jeon, et. al., “Nationwide Integrated 24/7 Monitoring System for ATSC 3.0 Single Frequency Broadcast Network,” in The 17th IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB 2022), Bilbao, Spain, June 2022.
Wonhyobong Wonhyobong Heukseung 55km Daejeon (b) between Heukseongsan Relay Transmitter and Wonhyobong Relay Transmitter Jeonju Moak Nogodan Moak Nogodan 63km Jeonju Distribution network structure and location (a) between Jeonju Station and Nogodan Relay Transmitter Microwave fading causing signal attenuation at Nogodan and Wonhyobong receiver sides
Sensitivity (a) Power Adjustment (Nov. 2023) ✓ Increased M/W output from 1W to 1.6W and monitored results ✓ Same fading symptoms occurred → Reverted to 1W (b) Modulation Order Change (Dec. 2023) ✓ Changed modulation from 128QAM to 64QAM and monitored results ✓ Same fading symptoms occurred → Reverted to 128QAM Only solution so far: Dedicated ISP leased line installation Public Internet Enterprise VPN Dedicated ISP Leased Network High stability Less stable Cost-effective High cost
VPN Dedicated ISP Leased Network High stability Less stable Cost-effective High cost Option Public Internet Enterprise VPN Dedicated Line Pros • Very low monthly cost • Reasonable monthly cost • Quality/stability guaranteed within pre-agreed bandwidth • 100% guaranteed transmission quality and stability • Full Multicast support Cons • No guarantee of transmission quality or stability • No Multicast support. Unicast Only • No Multicast support • Very high monthly cost Summary Not suitable for broadcast signal distribution Could be the most viable option if Multicast is supported Only current solution for STLTP over broadband STLTP Signal Distribution: Network Options Comparison
VPN Dedicated ISP Leased Network High stability Less stable Cost-effective High cost 60 Mbps STLTP Transmission (KBS1: 30 Mbps + KBS2: 30 Mbps) Category Public Internet Enterprise VPN Dedicated Leased Line Monthly Cost $20 $200 $2,000 Feasibility Not usable Viable if multicast support is added Fully usable Remarks No stability No multicast support Stable within contracted bandwidth No multicast support High stability Full multicast support * Since not all routers along the transmission path in the public Internet support multicast, a single non-supporting router will prevent multicast transmission. As a result, unicast must be used instead.
CTP (Common Tunneling Protocol) redundancy Defined in standard: ATSC 3.0 A/324 Annex D allows STLTP delivery over public networks using Unicast. Key Mechanism: • STLTP packets are transmitted via multiple ISPs using Unicast • At the transmitter, all identical STLTP streams are received • Packet aggregation is used to recover dropped packets and compensate for jitter → Achieves probabilistic reliability despite unstable public networks Unicast-based STLTP Delivery over Public Internet Pros & Cons of Public Internet + Unicast STLTP Delivery Aspect Details Advantage • Low cost due to use of public Internet Disadvantages • BGW & Exciter must support Unicast TX/RX (KBS BGW: not supported) • Public Internet cannot guarantee Multicast compatibility across all routers • Requires bandwidth scaling with number of ISPs × TX sites * Bandwidth Example: KBS1 STLTP = 30 Mbps Using 3 ISPs for 1 TX site → 90 Mbps required for 2 TX sites → 180 Mbps required
Tunneling) Method Feature Method 1 (SRT) Method 2 (GRE Tunneling) Requirements Requires dedicated SRT Caller and Listener devices Requires L3 switches with GRE tunneling capability at both ends Additional Delay Minimum 120 ms (due to ARQ buffer latency) None Transmission Rate Same as ATSC 3.0 BGW output, excluding FEC Same as ATSC 3.0 BGW output Error Correction Performance Fixed error correction performance based on ARQ Variable depending on STL-FEC settings Exciter Input Connection Direct connection to exciter due to multicast RPF issue Indirect connection via L3 Switch Important Notes Rather than increasing the transmission rate by applying SRT FEC, it is generally recommended not to apply FEC in most cases. Since a GRE header is added, the BGW output packet size must be set to within 1,436 bytes. Each multicast stream requires a separate VPN subnet or L3 switch.
Fa0/0 ISP VPN # cd /root/loopback-main # ./loopback –input udp://239.255.9.136: 5000?adapter=100.135.253.162 –output udp ://127.0.0.1:8888?adapter=127.0.0.1 & # srt-live-transmit udp://:8888 srt://20 5.24.1.49:8082 –v & # srt-live-transmit -v -r 5000 -s 5000 " srt://:8082?mode=listener“ "udp://239.25 5.9.136:5000?adapter=100.135.253.169“ & Microwave SRT Caller SRT Listener To Exciter @SRT Caller [Daejeon] @SRT Listener [Wonhyobong] Method 1 (SRT) R1 Configuration and Detailed Settings of SRT Application on Daejeon Station - Wonhyobong Transmitter ✓ On the SRT caller device, the STLTP multicast stream received from the ATSC 3.0 BGW is looped back to the localhost (127.0.0.1) to maintain the IGMP connection, ensuring continuous reception of the signal. This looped multicast stream is then transmitted via the SRT protocol using the srt-live-transmit command, which sends it to the IP address of the SRT listener. The listener device is configured explicitly with ?mode=listener and forwards the received SRT data to the designated STLTP multicast IP via UDP.
input signal configuration Method 1 (SRT) Approximately 20 Mbps out of the original 27 Mbps output from the ATSC 3.0 BGW (excluding the FEC portion) is observed on the ISP’s traffic monitoring system. VPN
the SRT method (b) SFN delay measurement (a) Input#2 status ✓ After implementing the SRT method, the Input#2 signal status of the ATSC 3.0 TX-B transmitter indicates normal operation. The total delay remains within 600 ms, satisfying KBS ATSC 3.0 SFN (Single Frequency Network) requirements and enabling stable operation. ✓ However, as shown in Table II, the delay difference between Input#1 and Input#2 of the transmitter exceeds 100 ms, preventing the use of Seamless Switching feature. Consequently, the transmitter TX-B is configured with Seamless Switching functionality turned off for operation.
UHD IP Signal Transmission Architecture – Jeonju CISCO L3 Switch ✓ Multicast transmission : Enable PIM Sparse-Mode functionality ✓ All nationwide ATSC 3.0 STLTP transmission switches are Cisco devices, with GRE tunnel support varying by installation year. • GRE tunneling is supported between Jeonju Broadcasting Center and Nogodan Station. Method 2 (GRE Tunneling) ✓ ATSC 3.0 STLTP signals are transmitted and distributed to their destinations via Layer 3 transmission switches located at the broadcast center and relay stations. Broadcast Center Relay Station
a tunnel interface, which is a logical interface. Then you must configure the tunnel endpoints for the tunnel interface. To configure the tunnel source and destination, issue the tunnel source {ip-address | interface-type} and tunnel destination {host-name | ip-address} com mands under the interface configuration mode for the tunnel. The below example explain about how to create simple GRE tunnels between endpoints and the necessary steps to create and verify the GRE tunnel between the two networks. R1's and R2's Internal subnets (192.168.1.0/24 and 192.168.2.0/24) are communicating with each other using GRE tunnel over internet. Both Tunnel interfaces are part of the 172.16.1.0/24 network. https://community.cisco.com/t5/networking-knowledge-base/how-to-configure-a-gre-tunnel/ta-p/3131970 R1 R2 Fa0/0 Internet Network 192.168.1.0/24 Tunnel Interface 1 172.16.1.1/24 Fa0/1 Fa0/1 Tunnel Interface 1 172.16.1.2/24 Internet Network 192.168.2.0/24 Fa0/0 ISP RFC 2784
we adjust the maximum transfer unit (MTU) to 1400 bytes and maximum se gment size (MSS) to 1360 bytes. Because most transport MTUs are 1500 bytes and we have an added overhead bec ause of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice an d will ensure unnecessary packet fragmentation is kept to a minimum. https://community.cisco.com/t5/networking-knowledge-base/how-to-configure-a-gre-tunnel/ta-p/3131970 1 R1(config)# interface Tunnel1 2 R1(config-if)# ip address 172.16.1.1 255.255.255.0 3 R1(config-if)# ip mtu 1400 4 R1(config-if)# ip tcp adjust-mss 1360 5 R1(config-if)# tunnel source 1.1.1.1 6 R1(config-if)# tunnel destination 2.2.2.2 1 R2(config)# interface Tunnel1 2 R2(config-if)# ip address 172.16.1.2 255.255.255.0 3 R2(config-if)# ip mtu 1400 4 R2(config-if)# ip tcp adjust-mss 1360 5 R2(config-if)# tunnel source 2.2.2.2 6 R2(config-if)# tunnel destination 1.1.1.1 R1 R2 Fa0/0 Internet Network 192.168.1.0/24 Tunnel Interface 1 172.16.1.1/24 Fa0/1 Fa0/1 Tunnel Interface 1 172.16.1.2/24 Internet Network 192.168.2.0/24 Fa0/0 ISP 1,436 bytes [payload] + 20 bytes [TCP header] + 20 bytes [IP header] + 24 bytes [ 4 GRE header + 20 IP header] = 1,500 bytes 1.1.1.1/30 2.2.2.2/30 RFC 2784 1 R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.1.2 1 R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.1.1
Multicast Routing Issue Identified via Cisco Troubleshooting Findings: •Through joint troubleshooting with Cisco, it was confirmed that: • Multicast routing must be explicitly configured for the subnet where the signal is received (input subnet) • Without this setting, the system fails to maintain a stable multicast path Symptom When Missing: • Intermittent packet loss (~every 3 minutes) • Small number of packets are dropped periodically Resolution: • Ensure multicast routing is enabled toward the signal input subnet • Prevents periodic packet loss and ensures stable STLTP stream reception 100.135.9.0/24 ATSC 3.0 Headend ATSC 3.0 Control Room
Unlike the SRT method (Method 1), the GRE tunnel allows the receiver-side switch to accept the multicast signal directly. In case of tunnel failure, the system automatically switches back to the original transmission path, offering seamless failover capabilities.
GRE tunneling Nogodan ATSC 3.0 transmitter input signal configuration (a) Telecom provider’s VPN traffic management control dashboard. The output is confirmed to be approximately 27 Mbps per channel, which matches the ATSC 3.0 BGW output Input#2 status SFN Delay measurement The STL-FEC configuration set at the ATSC BGW has been verified as applied correctly. Signal reception confirmed without any additional latency. Method 2(GRE Tunneling)
signals over ISP-provided VPN • Proposed SRT and GRE Tunneling techniques • Conducted long-term real-world deployment • Key Results • ATSC 3.0 transmitter, decoder, KBS nationwide SFN monitoring system, and other broadcasting equipment successfully received and processed signals without issues • Supplemented existing microwave (M/W) transmission network, improving stability and reliability of ATSC 3.0 broadcasting • Expected Benefits • Potential to apply SRT and GRE Tunneling to other transmission sections affected by microwave fading and new ATSC 3.0 facilities • Enables low-cost ATSC 3.0 signal transmission via VPN in low-power TV repeater (TVR) areas without M/W networks • Opportunity to replace dedicated IP transmission lines, reducing operational costs for broadcasters
the Daejeon–Wonhyobong Path for the GRE Tunnel? Q2. Why SRT and GRE Tunnel Have Different Input Configurations at the Transmitter (Exciter)? Q3. Multicast Tutorials: Source Tree and Shared Tree RPF (Reverse Path Forwarding) Check
the Daejeon–Wonhyobong Path for the GRE Tunnel? VPN Reliability Concerns at Transmitter Sites Transmitter sites (such as Wonhyobong) share limited telecom infrastructure with nearby government facilities. Due to concerns about VPN stability and reliability, a policy decision was made to avoid VPN-based GRE tunneling between transmitter sites. Result: GRE over VPN between Heukseongsan and Wonhyobong was considered unreliable and therefore not selected as the preferred path.
ATSC 3.0 BGW ATSC 3.0 Exciter ATSC 3.0 Exciter e0/1 e0/1 VPN SRT Caller SRT Listener Microwave Microwave e0/3 Wonhyobong local vlan OSPF PIM-SM vlan 222 OSPF PIM-SM local vlan OSPF PIM-SM vlan 999 OSPF PIM-SM e0/3 e0/0 100.136.9.50 239.255.9.136 100.136.9.51 239.255.9.136 Issue: Different Source IPs for SRT and BGW The Wonhyobong network switch recognizes BGW and SRT as separate multicast streams due to different source IPs, resulting in reception of both signals. [Path 1] Signal received via M/W transmission: Daejeon → Gyeryongsan → Heukseongsan → Wonhyobong [Path 2] SRT signal received directly: Daejeon → Wonhyobong Issue: The Wonhyobong transmitter receives both signals simultaneously, making proper processing impossible. Conclusion: The SRT output source IP must be identical to the BGW source IP. RP
BGW ATSC 3.0 Exciter ATSC 3.0 Exciter e0/1 e0/1 VPN SRT Caller SRT Listener Microwave Microwave e0/3 local vlan OSPF PIM-SM vlan 222 OSPF PIM-SM local vlan OSPF PIM-SM vlan 999 OSPF PIM-SM e0/3 e0/0 100.136.9.50 239.255.9.136 100.136.9.50 239.255.9.136 When SRT and BGW share the same source IP The Wonhyobong switch treats both BGW and SRT as the same multicast stream, receiving only the directly input SRT signal. [Path 1] M/W transmission is active but BGW signal is ignored. [Path 2] SRT signal is received and processed by the transmitter. RP Daejeon Heukseung Wonhyobong
BGW ATSC 3.0 Exciter ATSC 3.0 Exciter e0/1 e0/1 VPN SRT Caller SRT Listener Microwave Microwave e0/3 local vlan OSPF PIM-SM vlan 222 OSPF PIM-SM local vlan OSPF PIM-SM vlan 999 OSPF PIM-SM e0/3 e0/0 100.136.9.50 239.255.9.136 100.136.9.50 239.255.9.136 If the SRT signal to Wonhyobong is lost No changes to PIM settings in [Path 1] switch network. Packet drop occurs only at the transmitter due to signal loss. The transmitter begins receiving multicast stream via [Path 1]. Link Up (Active) RP Packet Drop Status SRT Source Turned OFF Decoder #1 (Broadcast Center) X (No packet loss observed) Decoder #2 (Intermediate Link) X Decoder #3 (Transmission Site) O (Packet drop occurred) Link Down ❷ ❶ Daejeon Heukseung Wonhyobong
BGW ATSC 3.0 Exciter ATSC 3.0 Exciter e0/1 e0/1 VPN SRT Caller SRT Listener Microwave Microwave e0/3 local vlan OSPF PIM-SM vlan 222 OSPF PIM-SM local vlan OSPF PIM-SM vlan 999 OSPF PIM-SM e0/3 e0/0 100.136.9.50 239.255.9.136 100.136.9.50 239.255.9.136 When the SRT signal is reconnected A new source is detected in the [Path 1] switch network. RPF (Reverse Path Forwarding) path is updated, triggering a change in the multicast routing table. Conclusion: All network switches experience a momentary packet drop. RP Packet Drop Status SRT Source Turned ON SRT Source Turned OFF Decoder #1 (Broadcast Center) O (Packet drop occurred) X (No packet loss observed) Decoder #2 (Intermediate Link) O X Decoder #3 (Transmission Site) O O Daejeon Heukseung Wonhyobong
BGW ATSC 3.0 Exciter ATSC 3.0 Exciter e0/1 e0/1 VPN SRT Caller SRT Listener Microwave Microwave e0/3 local vlan OSPF PIM-SM vlan 222 OSPF PIM-SM local vlan OSPF PIM-SM vlan 999 OSPF PIM-SM e0/3 e0/0 100.136.9.50 239.255.9.136 100.136.9.50 239.255.9.136 Attempt to isolate SRT signal from [Path 1] by removing PIM-SM PIM-SM was removed to avoid multicast impact from [Path 1]. However, due to missing multicast configurations, stable multicast reception could not be maintained. Multicast input on the Wonhyobong switch is interrupted every 3 minutes, regardless of source IP. Final Conclusion: SRT signal must be directly input to the transmitter to ensure stable operation. Link Up (Active) RP 3 min Link Down Link Up Daejeon Heukseung Wonhyobong
packets are delivered through two types of trees: Source Tree and Shared Tree. Source Tree ✓ A routing path that connects the multicast source to the receiver using the shortest path. ✓ Also called SPT (Shortest Path Tree). ✓ PIM-DM (Dense Mode) uses the Source Tree for packet delivery. Note: PIM-SSM uses only Source Trees. Bidir-PIM uses only Shared Trees. Multicast Server R2 R4 R3 (RP) Host (1.1.12.1, 239.1.1.1)
packets are delivered through two types of trees: Source Tree and Shared Tree. Shared Tree ✓ A routing path that goes through a central router called the RP (Rendezvous Point). ✓ Also known as RPT (Rendezvous Point Tree). ✓ The RP acts as a registration point for multicast sources. ✓ In PIM-SM (Sparse Mode), the first packet is sent via the Shared Tree, and then subsequent packets are switched to the Source Tree. Multicast Server R2 R4 R3 (RP) Host (1.1.12.1, 239.1.1.1)
up a multicast network, a unicast routing protocol must be in place. This is essential to prevent multicast packet loops. ✓ To avoid loops, multicast routing uses a process called RPF (Reverse Path Forwarding) check. ✓ RPF requires a working unicast routing table. Multicast Server R2 R4 R3 Host (1.1.12.1, 239.1.1.1) F0/0.24 F0/0.34 1.1.12.0/24 F0/0.24 Unlike unicast routing, which forwards packets based on the destination IP, multicast routing first checks the source IP using RPF, then forwards the packet based on the destination group address.
sunghojeon
moriatsushi
tenstorrent_japan
sansan33
pal4de
kameitomohiro
ttnyt8701
takumimukaiyama
techtekt
kakehashi
mnakabayashi
ysknsid25
wooootack
marktimemedia
deanohume
holman
thoeni
bluesmoon
sachag
addyosmani
paigeccino
kastner
chriscoyier
reverentgeek
tammyeverts
