Content for TR 22.826 Word version: 17.1.0
5.3.3 Communication QoS requirement for robotic telesurgery Word‑p. 33
5.3.3.1 Description
Remote surgery (also known as telesurgery) is the ability for a doctor to perform surgery on a patient even though they are not physically in the same location. It is a form of telepresence. A robot surgical system generally consists of one or more arms (controlled by the surgeon), a master controller (console), and a sensory system giving feedback to the user.
Remote surgery combines elements of robotics, cutting edge communication technology such as high-speed data connections and elements of management information systems. While the field of robotic surgery is fairly well established, most of these robots are controlled by surgeons at the location of the surgery. Remote surgery is essentially advanced telecommuting for surgeons, where the physical distance between the surgeon and the patient is immaterial. It promises to allow the expertise of specialized surgeons to be available to patients worldwide, without the need for patients to travel beyond their local hospital. In 2001, the first transatlantic operation was conducted by surgeons in New York on a patient in France [21]. The type of operations conducted include colon operations and hernia repairs. According to the BBC report "the surgeon who operated 400km away" [21], the technology behind long-distance surgery is now mature enough to be used more widely, allowing people to access world-leading expertise and better healthcare without having to travel.
The proposed Use Case describes the QoS requirements that may be needed for operation in a static remote telesurgery scenario.
5.3.3.2 Pre-conditions
Ali was badly injured in a car accident and needs very delicate surgery to clear a heart vessel. The level of expertise needed is not available at his local hospital but the hospital has managed to find a specialist in another hospital within the same country about 400km away but they cannot physically be present for the operation. Ali's local hospital is however set up for telesurgery, hence they can perform the operation. Also, there is a medical school nearby that want to benefit from the surgery taking place and they are allowed to dial in and view the procedure for medical advancement. The set up for the telesurgery is shown in the diagram below:
5.3.3.3 Service Flows Word‑p. 34
Ali lies on the operating table connected to the Robotic machine which is connected to the 5G network. This system has a video monitor, audio stream, robotic arm. The system is operated by a teleoperator.
The training school with the training monitor is also connected to the same cloud network using the 5G network to view the procedure.
The Master Console system is located at the remote location of the surgeon who is able to control the robotic arm that does the surgery and issues audio commands for the doctors and nurses assisting them in the operation at Ali's hospital. The forward link transports real time commands to control motion and rotate the robotic arm of the teleoperator along with voice stream of the surgeon.
The feedback from the teleoperator at Ali's local hospital to the surgeon at a remote location is transporting real time multi modal sensing which includes: 3D stream, force feedback e.g. pressure, tactile feedback e.g. tissue mechanical properties and patient's physiological data such as blood pressure, heart rate along with voice stream from assistant nurses, anaesthetists and other collaborating surgeons by the patient's side.
The performance of the telesurgery largely depends on communication latency, jitter and packet loss, these communication QoS requirements of multi-modal sensory data in telesurgery are important to be considered in a 5G network and typical figures taken based on research [22] are suggested here.
The following are potential requirement taken from [22] to support this use case. The 5G system shall support the following QoS values:
Data Types
Latency
Jitter
Packet Loss Rate
Data Ref
2D Camera Flow <150ms 3-30ms <10-3 <10Mbps Real-Time Multimedia Stream 3D Camera Flow <150ms 3-30ms <10-3 137 Mbps - 1.6Gbps [for good imaging this could be up to 4Gbps] Audio Flow <150ms <30ms <10-2 22-200Kbps Temp <250ms <10-3 <10kbps Blood Pressure <250ms <10-3 <10kbps Physical Vital Sign Heart Rate <250ms <10kps Respiration Rate <250ms <10kps ECG <250ms 72kbps EEG <250ms 86.4kps EMG <250ms 1.536Mbs Haptic Feedback Force (considering human reaction) 3-10ms
(20ms) <2ms <10-4 128-400kps Vibration <5.5ms <2ms <10-4 128-400kps
Privacy and confidentiality
With the use of electronic systems, confidentiality might be at risk and special measures must be taken in order to prevent improper communication of medical data. In situations like transmission of scan results, especially in cases of ultrasound scans supplementary measures must be taken. The doctors providing the medical services from the distance must make sure that the patient consented for this information to be transmitted via electronic systems [23].
Each equipment involved in image generation and processing, display, motion control and haptic feedback is synchronized thanks to a common clock either external or provided by the 5G system. The synchronization is often achieved through dedicated protocols such as e.g. PTP version 2 and allows to e.g. guarantee the consistency of the haptic feedback and displayed images at the master console, or enable the recording and offline replay of the whole procedure.
5.3.3.4 Post-conditions Word‑p. 35
Operation is completed successfully and all connections are terminated.
5.3.3.5 Existing features partly or fully covering the use case functionality
Reference number
Requirement text
Application / Transport
Comment
5.6.1 Clock synchronization service level requirements related to global clock domain management T See TS 22.104
8.9 The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices. T Requirement taken from TS 22.261, however need to add "high data rates" to the requirement text.
The medical equipment being used in this use case may require solutions that serve URLLC communication as well as very high data rates. The equipment is typically not energy constrained.
5.3.3.6 Potential New Requirements needed to support the use case Word‑p. 36
Use case
Characteristic parameter
Influence quantity
5.3.3 - Communication QoS requirement for robotic telesurgery
Communication service availability: target value in %
Communication service reliability: Mean Time Between Failure
End-to-end latency: maximum
Bit rate
Direction
Message Size [byte]
Survival time
UE speed
# of active UEs
Service Area [m2] (note 2)
Stereoscopic 4K 60 fps HDR 10bits frame packed real time video (loss less compressed) 99.9999 >1 year < 250 ms 6 Gbit/s UE to Network; Network to UE ~1500 - ~9000 (note 1) ~16 ms stationary < 2 per 1000 km2 <400 4K 60 fps 12 bits per pixel color coded (e.g. YUV 4:1:1) real time video (loss less compressed) 99.999 >>1 month (<1 year) < 250 ms 2 Gbit/s Network to UEs ~1500 - ~9000 (note 1) ~16 ms stationary < 5 per 100m2 (note 3) <400 Haptic Feedback 99.9999 >1 year <20 ms 2 Mbits/s Network to UE 250 ~1 ms stationary < 2 per 1000 km2 <400 Haptic Feedback 99.9999 >1 year <20 ms 16 Mbits/s UE to Network ~2000 ~1 ms stationary < 2 per 1000 km2 <400
NOTE 1:
MTU size of 1500 bytes is not generally suitable to gigabits connections as it induces many interruptions and loads on CPUs. On the other hand, Ethernet jumbo frames of up to 9000 bytes require all equipment on the forwarding path to support that size in order to avoid fragmentation.
NOTE 2:
Straight line distance between surgeon's console at the hospital and the remote robotic telesurgery system.
NOTE 3:
This comprises a maximum of 5 displays gathered in the same room considering a room density <2 per 1000 km2
Number of devices for clock synchronisation
Clock synchronicity requirement
Service area (note 1)
Up to 10 UEs (note 2) < 50 μs 400 km
NOTE 1:
Straight line distance between surgeon's console at the hospital and the remote telesurgery system
NOTE 1:
This comprises displays, robotic actuators, haptic feedback sensors, located at either end of the robotic system (robot or console) and training monitors at an intermediary location
5.3.3.1 Description
Remote surgery (also known as telesurgery) is the ability for a doctor to perform surgery on a patient even though they are not physically in the same location. It is a form of telepresence. A robot surgical system generally consists of one or more arms (controlled by the surgeon), a master controller (console), and a sensory system giving feedback to the user.
Remote surgery combines elements of robotics, cutting edge communication technology such as high-speed data connections and elements of management information systems. While the field of robotic surgery is fairly well established, most of these robots are controlled by surgeons at the location of the surgery. Remote surgery is essentially advanced telecommuting for surgeons, where the physical distance between the surgeon and the patient is immaterial. It promises to allow the expertise of specialized surgeons to be available to patients worldwide, without the need for patients to travel beyond their local hospital. In 2001, the first transatlantic operation was conducted by surgeons in New York on a patient in France [21]. The type of operations conducted include colon operations and hernia repairs. According to the BBC report "the surgeon who operated 400km away" [21], the technology behind long-distance surgery is now mature enough to be used more widely, allowing people to access world-leading expertise and better healthcare without having to travel.
The proposed Use Case describes the QoS requirements that may be needed for operation in a static remote telesurgery scenario.
5.3.3.2 Pre-conditions
Ali was badly injured in a car accident and needs very delicate surgery to clear a heart vessel. The level of expertise needed is not available at his local hospital but the hospital has managed to find a specialist in another hospital within the same country about 400km away but they cannot physically be present for the operation. Ali's local hospital is however set up for telesurgery, hence they can perform the operation. Also, there is a medical school nearby that want to benefit from the surgery taking place and they are allowed to dial in and view the procedure for medical advancement. The set up for the telesurgery is shown in the diagram below:
5.3.3.3 Service Flows Word‑p. 34
Ali lies on the operating table connected to the Robotic machine which is connected to the 5G network. This system has a video monitor, audio stream, robotic arm. The system is operated by a teleoperator.
The training school with the training monitor is also connected to the same cloud network using the 5G network to view the procedure.
The Master Console system is located at the remote location of the surgeon who is able to control the robotic arm that does the surgery and issues audio commands for the doctors and nurses assisting them in the operation at Ali's hospital. The forward link transports real time commands to control motion and rotate the robotic arm of the teleoperator along with voice stream of the surgeon.
The feedback from the teleoperator at Ali's local hospital to the surgeon at a remote location is transporting real time multi modal sensing which includes: 3D stream, force feedback e.g. pressure, tactile feedback e.g. tissue mechanical properties and patient's physiological data such as blood pressure, heart rate along with voice stream from assistant nurses, anaesthetists and other collaborating surgeons by the patient's side.
The performance of the telesurgery largely depends on communication latency, jitter and packet loss, these communication QoS requirements of multi-modal sensory data in telesurgery are important to be considered in a 5G network and typical figures taken based on research [22] are suggested here.
The following are potential requirement taken from [22] to support this use case. The 5G system shall support the following QoS values:
| Data Types | Latency | Jitter | Packet Loss Rate | Data Ref | |
|---|---|---|---|---|---|
| 2D Camera Flow | <150ms | 3-30ms | <10-3 | <10Mbps | |
| Real-Time Multimedia Stream | 3D Camera Flow | <150ms | 3-30ms | <10-3 | 137 Mbps - 1.6Gbps [for good imaging this could be up to 4Gbps] |
| Audio Flow | <150ms | <30ms | <10-2 | 22-200Kbps | |
| Temp | <250ms | <10-3 | <10kbps | ||
| Blood Pressure | <250ms | <10-3 | <10kbps | ||
| Physical Vital Sign | Heart Rate | <250ms | <10kps | ||
| Respiration Rate | <250ms | <10kps | |||
| ECG | <250ms | 72kbps | |||
| EEG | <250ms | 86.4kps | |||
| EMG | <250ms | 1.536Mbs | |||
| Haptic Feedback | Force (considering human reaction) | 3-10ms (20ms) | <2ms | <10-4 | 128-400kps |
| Vibration | <5.5ms | <2ms | <10-4 | 128-400kps |
Privacy and confidentiality
With the use of electronic systems, confidentiality might be at risk and special measures must be taken in order to prevent improper communication of medical data. In situations like transmission of scan results, especially in cases of ultrasound scans supplementary measures must be taken. The doctors providing the medical services from the distance must make sure that the patient consented for this information to be transmitted via electronic systems [23].
Each equipment involved in image generation and processing, display, motion control and haptic feedback is synchronized thanks to a common clock either external or provided by the 5G system. The synchronization is often achieved through dedicated protocols such as e.g. PTP version 2 and allows to e.g. guarantee the consistency of the haptic feedback and displayed images at the master console, or enable the recording and offline replay of the whole procedure.
5.3.3.4 Post-conditions Word‑p. 35
Operation is completed successfully and all connections are terminated.
5.3.3.5 Existing features partly or fully covering the use case functionality
| Reference number | Requirement text | Application / Transport | Comment |
|---|---|---|---|
| 5.6.1 | Clock synchronization service level requirements related to global clock domain management | T | See TS 22.104 |
| 8.9 | The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices. | T | Requirement taken from TS 22.261, however need to add "high data rates" to the requirement text. The medical equipment being used in this use case may require solutions that serve URLLC communication as well as very high data rates. The equipment is typically not energy constrained. |
5.3.3.6 Potential New Requirements needed to support the use case Word‑p. 36
| Use case | Characteristic parameter | Influence quantity | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 5.3.3 - Communication QoS requirement for robotic telesurgery | Communication service availability: target value in % | Communication service reliability: Mean Time Between Failure | End-to-end latency: maximum | Bit rate | Direction | Message Size [byte] | Survival time | UE speed | # of active UEs | Service Area [m2] (note 2) |
| Stereoscopic 4K 60 fps HDR 10bits frame packed real time video (loss less compressed) | 99.9999 | >1 year | < 250 ms | 6 Gbit/s | UE to Network; Network to UE | ~1500 - ~9000 (note 1) | ~16 ms | stationary | < 2 per 1000 km2 | <400 |
| 4K 60 fps 12 bits per pixel color coded (e.g. YUV 4:1:1) real time video (loss less compressed) | 99.999 | >>1 month (<1 year) | < 250 ms | 2 Gbit/s | Network to UEs | ~1500 - ~9000 (note 1) | ~16 ms | stationary | < 5 per 100m2 (note 3) | <400 |
| Haptic Feedback | 99.9999 | >1 year | <20 ms | 2 Mbits/s | Network to UE | 250 | ~1 ms | stationary | < 2 per 1000 km2 | <400 |
| Haptic Feedback | 99.9999 | >1 year | <20 ms | 16 Mbits/s | UE to Network | ~2000 | ~1 ms | stationary | < 2 per 1000 km2 | <400 |
|
NOTE 1:
MTU size of 1500 bytes is not generally suitable to gigabits connections as it induces many interruptions and loads on CPUs. On the other hand, Ethernet jumbo frames of up to 9000 bytes require all equipment on the forwarding path to support that size in order to avoid fragmentation.
NOTE 2:
Straight line distance between surgeon's console at the hospital and the remote robotic telesurgery system.
NOTE 3:
This comprises a maximum of 5 displays gathered in the same room considering a room density <2 per 1000 km2
|
||||||||||
| Number of devices for clock synchronisation | Clock synchronicity requirement | Service area (note 1) |
|---|---|---|
| Up to 10 UEs (note 2) | < 50 μs | 400 km |
|
NOTE 1:
Straight line distance between surgeon's console at the hospital and the remote telesurgery system
NOTE 1:
This comprises displays, robotic actuators, haptic feedback sensors, located at either end of the robotic system (robot or console) and training monitors at an intermediary location
|
||
