<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>operating room networks &#8211; Science</title>
	<atom:link href="https://scienmag.com/tag/operating-room-networks/feed/" rel="self" type="application/rss+xml" />
	<link>https://scienmag.com</link>
	<description></description>
	<lastBuildDate>Wed, 30 Sep 2026 16:57:40 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.2</generator>

<image>
	<url>https://scienmag.com/wp-content/uploads/2024/07/cropped-scienmag_ico-32x32.jpg</url>
	<title>operating room networks &#8211; Science</title>
	<link>https://scienmag.com</link>
	<width>32</width>
	<height>32</height>
</image> 
<site xmlns="com-wordpress:feed-additions:1">73899611</site>	<item>
		<title>Automated Time-Sensitive Networking Brings Deterministic Delays to Connected Operating Rooms</title>
		<link>https://scienmag.com/automated-time-sensitive-networking-brings-deterministic-delays-to-connected-operating-rooms/</link>
		
		<dc:creator><![CDATA[Ophelia Keating]]></dc:creator>
		<pubDate>Wed, 30 Sep 2026 16:57:40 +0000</pubDate>
				<category><![CDATA[Medicine]]></category>
		<category><![CDATA[automated network configuration]]></category>
		<category><![CDATA[bounded-latency communication]]></category>
		<category><![CDATA[Gate Control List]]></category>
		<category><![CDATA[ISO IEEE 11073 SDC]]></category>
		<category><![CDATA[medical device interoperability]]></category>
		<category><![CDATA[operating room networks]]></category>
		<category><![CDATA[patient safety]]></category>
		<category><![CDATA[QUIC]]></category>
		<category><![CDATA[RWTH Aachen University]]></category>
		<category><![CDATA[Surgical robotics]]></category>
		<category><![CDATA[Time-Aware Shaper]]></category>
		<category><![CDATA[Time-Sensitive Networking]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=217298</guid>

					<description><![CDATA[Researchers at RWTH Aachen University have demonstrated an automated workflow that configures Time-Sensitive Networking for ISO IEEE 11073 SDC-based medical device networks, achieving stable bounded-latency communication under heavy load when schedules are generously dimensioned.]]></description>
										<content:encoded><![CDATA[<p>In the modern operating room, a surgeon&#8217;s foot switch can trigger a high-frequency surgical device, a robot can respond to force feedback, and dozens of monitors, pumps and cameras all compete for the same network cables. For years, the industry has promised a future in which medical devices from different manufacturers talk to each other seamlessly over standard Ethernet, without proprietary black boxes or tangled extra wiring. A new study from RWTH Aachen University brings that future measurably closer, while also delivering a sober warning about how easily it can go wrong. The research, published in the International Journal of Computer Assisted Radiology and Surgery, demonstrates for the first time a fully automated workflow that configures Time-Sensitive Networking (TSN) for medical device networks built on the ISO IEEE 11073 Service-oriented Device Connectivity (SDC) standard, and then stress-tests the result under realistic traffic loads.</p>
<p>SDC, standardized since 2019, is the backbone of the vendor-independent operating room. It defines how a medical device describes itself, its measurements, its settings and its remote operations, so that any compliant consumer can subscribe to a ventilator&#8217;s data or invoke a function on a surgical device without knowing who built it. At the heart of every SDC provider sits the Medical Device Information Base, or MDIB, a structured, XML-based model that captures both the static anatomy of a device, organized as a containment tree of systems, subsystems, channels and metrics, and its dynamic state, from live measurement values to alert conditions. What SDC does not define, however, is any guarantee about when those messages arrive. Previous studies have shown that while average latencies in SDC networks are low, they can spike unpredictably when the network gets busy, which is precisely the wrong behavior for applications where a delayed foot-switch signal or a lagging robot command could compromise patient safety.</p>
<p>Today, teams that need deterministic timing often fall back on proprietary solutions or dedicated real-time fieldbuses running alongside the standard network. One example cited in the literature is the Surgical Real-Time Bus, which achieves deterministic communication but demands additional cabling, driving up installation and maintenance costs in an environment where cable clutter is already a documented safety hazard. Time-Sensitive Networking offers an elegant alternative: a suite of IEEE 802.1 extensions that turns ordinary switched Ethernet into a time-controlled transmission system. Its centerpiece, the Time-Aware Shaper specified in IEEE 802.1Qbv, divides time into repeating cycles of slots, and a Gate Control List (GCL) dictates, for every slot and every traffic queue on every device, whether the gate is open or closed. Critical traffic gets reserved windows; everything else waits its turn. The catch is that computing these schedules is hard, and the effort grows with every device and stream added to the network.</p>
<p>The Aachen team, led by Maja Dohms with Noah Wickel, Klaus Radermacher and Armin Janß, attacked exactly that bottleneck. Their automated workflow starts by mining the MDIB of each SDC device: every metric and every service operation is identified as a communication stream, payload sizes are estimated from the SDC message structure and the technical ranges declared in the device description, and transmission periods are derived from the determination and invocation periods stored in the model. Safety classifications are mapped to priority levels, and custom MDIB extensions supply the jitter constraints and string-length bounds that the standard does not natively define. Network parameters are not left to guesswork either: processing delays are measured directly by exchanging UDP packets between devices and comparing hardware and application time stamps, while propagation delays are calculated and link speeds read from the device configuration. The result is a complete stream set and topology description, fed automatically into an open-source scheduling framework.</p>
<p>For schedule computation, the researchers used the TSNKit framework with a joint routing-and-scheduling algorithm, extended to model temporal dependencies between streams and to assign traffic queues. The computed Gate Control Lists are then translated into device-specific configuration files and deployed across the network through the fully centralized configuration model defined in IEEE 802.1Qcc, in which a Centralized Network Controller distributes schedules to every TSN-capable participant. On the Linux end systems, the team used the TAPRIO queuing discipline, which implements the Time-Aware Shaper, with configuration scripts generated automatically and pushed over SSH. Underpinning the entire scheme is the Precision Time Protocol, which synchronizes every clock in the network to a grandmaster so that all gate openings happen in a shared timeframe. The workflow even schedules the PTP synchronization messages themselves at the highest priority, since the whole edifice collapses without accurate time.</p>
<p>The experimental testbed consisted of two virtual end devices, one acting as SDC provider and network controller, the other as consumer, connected through a TSN-enabled switch. The provider, running on a Dell PC with an Intel I225-LM network interface, transmitted two numeric metric updates every 500 milliseconds and processed one activate operation per second, with latency bounds of 500 and 100 milliseconds respectively. Background load was generated with iperf, hammering the network with parallel UDP streams at up to 3 gigabits per second, in two scenarios: traffic between the two endpoints themselves, and external traffic from a third node. Three window-dimensioning strategies were compared: a minimal fixed window of 75 microseconds, which proved to be the lower bound for a stable SDC connection, and two strategies scaling windows proportionally to message size by factors of ten and one hundred.</p>
<p>The results reveal a delicate balancing act. Without any TSN configuration, SDC latencies stayed below 23 milliseconds on an idle network, but under load, sporadic peaks exceeded ten times the median value. With the tightest 75-microsecond schedule, communication became unstable: state update messages accumulated in queues that never had time to drain, latency climbed steadily, and the consumer eventually terminated its subscription. The factor-10 schedule improved matters but remained fragile, particularly under external load, where state updates were lost almost immediately. Only the generously dimensioned factor-100 schedule kept communication stable under both internal and external traffic, with maximum SDC latency remaining in the same range as under unloaded conditions. Yet even this best configuration could not consistently meet its timing constraints, and a sawtooth-like latency pattern betrayed a phase misalignment between the message transmission period and the schedule cycle. Improperly dimensioned windows, the authors found, can produce latency peaks of up to four times the planned transmission time, connection loss and outright instability.</p>
<p>The team also experimented with a modified SDC library that replaces the conventional HTTP/2 over TCP transport with HTTP/3 over QUIC, a UDP-based protocol designed for faster connection establishment. The QUIC-based variant showed slightly lower median latencies in baseline measurements and required fewer scheduled time slots, since fewer protocol messages needed reserving. Under the factor-100 schedule with background load, latencies stabilized after brief transient outliers, suggesting that when the message cycle aligns with the schedule cycle, stable timing can be maintained even under heavy interference. Intriguingly, the measurements also showed that unscheduled SDC communication tolerated load and timing deviations better than overly restrictive schedules, a counterintuitive finding that underscores how a poorly fitted deterministic regime can be worse than none at all.</p>
<p>What makes this work significant is less any single latency number than the demonstration that the configuration burden, historically the great obstacle to TSN adoption, can be lifted almost entirely off the shoulders of clinical engineers. Because the communication requirements are extracted automatically from the very device descriptions that SDC already mandates, a network of interoperable medical devices could in principle configure itself for bounded-latency operation after initial setup, with little manual intervention. That is a prerequisite for any realistic deployment in hospitals, where networks change as devices are wheeled in and out and staff cannot be expected to hand-tune gate control lists. The authors are careful to note, however, that their reported window sizes and scaling factors are empirical observations specific to their testbed, not transferable design rules, and that topology information still must be supplied manually.</p>
<p>The road ahead involves automated device discovery, dynamic acquisition of processing and queue parameters through a centralized device manager, and runtime validation and adaptation of schedules, along with extension to larger networks and coordinated device groups operating as real-time communication ensembles. Reliable worst-case latency bounds, the gold standard for safety-critical certification, remain to be established. But the direction of travel is clear. A connected operating room in which a robot, an electrosurgical unit and a navigation system share one cable, one standard and one predictable clock is no longer a white-paper fantasy. It is an engineering problem with a demonstrated, automated solution, and the remaining work is a matter of tightening schedules, not reimagining them.</p>
<p><strong>Subject of Research:</strong> Automated TSN configuration for bounded-latency communication in ISO IEEE 11073 SDC-based medical device networks</p>
<p><strong>Article Title:</strong> Evaluation of an automated workflow for TSN-based bounded-latency communication in ISO IEEE 11073 SDC-based medical networks</p>
<p><strong>Article References:</strong> Evaluation of an automated workflow for TSN-based bounded-latency communication in ISO IEEE 11073 SDC-based medical networks. (n.d.). <a href="https://doi.org/10.1007/s11548-026-03801-1" rel="noopener noreferrer">https://doi.org/10.1007/s11548-026-03801-1</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s11548-026-03801-1" rel="noopener noreferrer">10.1007/s11548-026-03801-1</a></p>
<p><strong>Keywords:</strong> Time-Sensitive Networking, ISO IEEE 11073 SDC, medical device interoperability, operating room networks, bounded-latency communication, automated network configuration, Time-Aware Shaper, Gate Control List, QUIC, surgical robotics, patient safety, RWTH Aachen University</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">217298</post-id>	</item>
	</channel>
</rss>
