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:

Figure 5.3.3.2-1: Typical robotic system setup for teleoperations

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

Table 5.3.3.5-1: Applicable existing communication service functional requirements

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

Table 5.3.3.6-1: Potential new Communication Service Performances Requirements

Use case
5.3.3 - Communication QoS requirement for robotic telesurgery

Characteristic parameter
Communication service availability: target value in %

Communication service reliability: Mean Time Between Failure

End-to-end latency: maximum

Bit rate

Direction

Influence quantity
Message Size [byte]

Survival time

UE speed

# of active UEs

Service Area [km] (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

---

---

 

Table 5.3.3.6-2: Clock Synchronization service performance requirements

Number of devices for clock synchronisation

Clock synchronicity requirement

Service area (note 1)

---

Up to 10 UEs (note 2)

< 50 μs

400 km

---

---