Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TR 22.826  Word version:  17.2.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<150ms3-30ms<10-3<10Mbps
Real-Time Multimedia Stream3D Camera Flow<150ms3-30ms<10-3137 Mbps - 1.6Gbps [for good imaging this could be up to 4Gbps]
Audio Flow<150ms<30ms<10-222-200Kbps
Temp<250ms <10-3<10kbps
Blood Pressure<250ms <10-3<10kbps
Physical Vital SignHeart Rate<250ms<10kps
Respiration Rate<250ms<10kps
ECG<250ms72kbps
EEG<250ms86.4kps
EMG<250ms1.536Mbs
Haptic FeedbackForce (considering human reaction)3-10ms
(20ms)
<2ms<10-4128-400kps
Vibration<5.5ms<2ms<10-4128-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.1Clock synchronization service level requirements related to global clock domain managementTSee TS 22.104
8.9The 5G system shall support data integrity protection and confidentiality methods that serve URLLC and energy constrained devices.TRequirement 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 Characteristic parameter Influence quantity
5.3.3 - Communication QoS requirement for robotic telesurgery Communi­cation service availa­bility: target value in % Communi­cation service reliabi­lity: 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 ms6 Gbit/sUE to Network; Network to UE~1500 - ~9000 (note 1)~16 msstationary< 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 ms2 Gbit/sNetwork to UEs~1500 - ~9000 (note 1)~16 msstationary< 5 per 100m2 (note 3)<400
Haptic Feedback99.9999>1 year<20 ms2 Mbits/sNetwork to UE250~1 msstationary< 2 per 1000 km2<400
Haptic Feedback99.9999>1 year<20 ms16 Mbits/sUE to Network~2000~1 msstationary< 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 μs400 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
Up

Up   Top   ToC