Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TR 22.826  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3…   5.3…   5.3.3   5.3.4…   5.4…   6…

 

5.3.3  Communication QoS requirement for robotic telesurgeryWord‑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.
Up

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:
Reproduction of 3GPP TS 22.826, Figure 5.3.3.2-1: Typical robotic system setup for teleoperations
Up

5.3.3.3  Service FlowsWord‑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.
Up

5.3.3.4  Post-conditionsWord‑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
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.

Up

5.3.3.6  Potential New Requirements needed to support the use caseWord‑p. 36
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


 
Number of devices for clock synchronisation
Clock synchronicity requirement
Service area (note 1)

Up to 10 UEs (note 2)
< 50 μs
400 km


Up


Up   Top   ToC