Patent Publication Number: US-2022234211-A1

Title: Technique for Selecting a Transmission Mode for Wirelessly Transmitting a Message Comprising Control Information for Robotic Device Control

Description:
TECHNICAL FIELD 
     The present disclosure generally relates to industrial automation. In particular, an apparatus for selecting a transmission mode for wirelessly transmitting a message comprising control information for robotic device control is provided. Also provided are a system comprising the apparatus, a method for selecting a transmission mode for wirelessly transmitting a message comprising control information for robotic device control, a cloud computing system configured to perform the method, a computer program, a computer-readable medium and a data carrier signal. 
     BACKGROUND 
     Existing industrial applications (including, e.g., robot arm controllers or robot cell controllers) typically run on programmable logic controllers, PLCs, and use a fieldbus protocol like ProfiNet to transmit messages to robotic devices and receive messages from the devices. The ProfiNet protocol is an Ethernet based protocol which supports real-time communication between industrial applications. According to the ProfiNet protocol, messages are sent with a predefined update time. The ProfiNet protocol defines a threshold for a count of consecutively not correctly received packages. In other words, the protocol defines a count of tolerated message losses specified by a retry parameter. 
     When the count of consecutively not correctly received messages reaches or exceeds the threshold, the industrial application running on the PLC is notified, and emergency actions are executed. According to such emergency actions, typically the whole robotic cell is stopped. The ProfiNet protocol uses a memory map-like operation. In more detail, the application reads/writes a memory area in the PLC and the ProfiNet protocol keeps a mirrored version in the device up-to-date, and vice-versa. 
     Existing solutions are designed for traditional robotic cells in which all devices are connected through reliable wired connections. In such implementations, any problem in communication means that most probably the robotic device or its controller is physically damaged, and the robotic device must stop. 
     In future industrial applications, some devices will be connected through wireless connection, but still also use the fieldbus technology. However, wireless connections are often not as reliable connection as wired connections, even if several radio mechanisms are introduced to eliminate or reduce a radio uncertainty from the connection, such as modulation, Hybrid Automatic Repeat Request (H-ARQ), Radio Link Control (RLC) or multi-connectivity. 
     Existing wireless transmission protocols do not consider aspects relating to fieldbus-based connections and industrial applications. Instead, they focus on improving the characteristics of the wireless connection independently from the involved industrial automation protocols or mechanisms mentioned above. On the other hand, industrial automation protocols and wired gateways do not consider message transmission as a limited resource, which is the case in wireless communication over scarce spectrum resources. 
     SUMMARY 
     There is a need for a technique of enabling reliable transmission of messages comprising control information for robotic device control over a wireless connection. 
     According to a first aspect, an apparatus for selecting a transmission mode for wirelessly transmitting a message comprising control information for robotic device control is provided. The apparatus is configured to compare a current message, which is to be transmitted after a previous message, with the previous message to identify a change in the control information from the previous message to the current message. The apparatus is further configured to select one of a normal transmission mode and a robust transmission mode which is more robust than the normal transmission mode for wireless transmission of the current message. The apparatus is configured to select the robust transmission mode if a change in the control information is identified and to trigger wireless transmission of the current message with the selected transmission mode. 
     The wireless transmission may be based on message acknowledgements, such as HARQ mechanisms. As such, correct receipt of the previous message may have been acknowledged. The acknowledgement may have happened prior to the comparison step. 
     The apparatus may be configured to compare the current message with the previous message by obtaining at least one part of the control information comprised in the current message, obtaining at least one part of the control information comprised in the previous message and comparing the at least one part of the control information comprised in the current message with the at least one part of the control information comprised in the previous message. In one variant, the apparatus is configured to obtain the at least one part of the control information comprised in the current message by masking at least one part of the current message to define at least one masked part and at least one unmasked part of the current message and extracting the at least one unmasked part of the current message as the at least one part of the control information comprised in the current message. 
     The apparatus is in one example configured to obtain the at least one part of the control information comprised in the previous message by masking at least one part of the previous message to define at least one masked part and at least one unmasked part of the previous message and by extracting the at least one unmasked part of the previous message as the at least one part of the control information comprised in the previous message. The apparatus may in particular be configured to mask at least one of a protocol field comprised in the message and a message part which has no effect on a reaction time of a robotic device to be controlled. On the other hand, specific control information such as commands relating to movement of the robotic device or feedback information from the robotic device for generation of the next command may have an effect on reaction time and, thus, may not be masked. 
     For example, the apparatus is configured to apply a plurality of different masks to define at least one masked part and at least one unmasked part for each of the different masks, wherein each one of the plurality of masks has an associated priority level. The apparatus may further be configured to extract the at least one unmasked part as the at least one part of the control information separately for each one of the plurality of masks. 
     The apparatus is for example configured to compare the at least one unmasked part of the control information comprised in the current message with the at least one unmasked part of the control information comprised in the previous message, for each one of the plurality of masks, to identify a change in the control information from the previous message to the current message. The apparatus may further be configured to determine one of the plurality of masks associated with the change in the control information and select the robust transmission mode based on the priority level associated with the determined mask. The apparatus may specifically be configured to determine one of the plurality of masks based on which a change in the control information from the previous message to the current message is identified. 
     According to one variant, the apparatus is configured to compare the current message with the previous message by obtaining a first hash of the at least one part of the control information comprised in the current message, obtaining a second hash of the at least one part of the control information comprised in the previous message, and comparing the first hash with the second hash. For example, the apparatus is configured to identify a change in the control information from the previous message to the current message based on a result of comparing the first hash with the second hash. The apparatus may in particular be configured to identify a change in the control information from the previous message to the current message in case the first hash is not equal to the second hash. 
     For example, the robust transmission mode comprises transmitting the current message more often than with the normal transmission mode. Alternatively, or in addition, the robust transmission mode comprises transmitting the current message using a modulation scheme which is more robust than a modulation scheme of the normal transmission mode. 
     According to a second aspect, an apparatus for selecting a transmission mode for wirelessly transmitting a message comprising control information for robotic device control is provided. A robot communication protocol based on which a robotic device can receive or send messages defines a threshold for a count of consecutively not correctly received messages. The robotic device is configured to perform an emergency action in case the count exceeds the threshold. The apparatus is configured to obtain a count of consecutively not correctly received messages and to select one of a normal transmission mode and a robust transmission mode which is more robust than the normal transmission mode based on the obtained count. The apparatus is further configured to select the robust transmission mode if the count equals or approaches the threshold and to trigger wireless transmission of the message with the selected transmission mode. 
     The message of the second apparatus aspect may correspond to the current message of the first apparatus aspect. The first apparatus aspect and the second apparatus aspect may be combined in a single apparatus or as two co-located apparatuses in a single system. 
     The apparatus of the second aspect is for example configured to obtain the count of consecutively not correctly received messages by obtaining a positive feedback message (also referred to as ACK) or a negative feedback message (also referred to as NACK), the positive feedback message indicating that a transmitted message has been correctly received, and the negative feedback message indicating that a transmitted message has not been correctly received. The apparatus may further be configured to obtain the count of consecutively not correctly received messages based on the obtained feedback message. 
     In one example, the apparatus of the second aspect is configured to increase the obtained count of consecutively not correctly received messages if, after transmitting the message, a negative feedback message is obtained, or if, after transmitting the message, no positive feedback message is obtained. For example, the count may be incremented with each consecutively received NACK, including the first NACK received. The count may also be incremented in case neither an ACK nor a NACK is received for a particular message transmission (e.g., within a predefined period of time following the particular message transmission). The count may be zeroed in response to each received ACK. 
     The robust transmission mode may comprise at least one of transmitting the message more often than with the normal transmission mode, and transmitting the message using a modulation scheme which is more robust than a modulation scheme of the normal transmission mode. 
     The apparatus of the first aspect of the second aspect may be configured to be connected to the robotic device (or to a local robot controller of the robotic device) via a fieldbus connection. 
     According to a third aspect, a system is provided which comprises the apparatus of the first aspect and/or the apparatus of the second aspect and the robotic device. At least a portion of a communication link between the apparatus and the robotic device may be a fieldbus connection. 
     The robotic device for example comprises the robot controller configured to control the robotic device based on control information comprised in a message received by the apparatus. 
     The robotic device may comprise a robot controller configured to generate the current message comprising the control information based on a current state of the robotic device. The robot controller may be configured to generate the message comprising the control information based on a current state of the robotic device. 
     The apparatus of the first aspect or of the second aspect may be configured to be connected to a controller via a fieldbus connection. The controller may be located in a computing cloud. 
     Also, according to a fourth aspect, a system is provided which comprises the apparatus of the first aspect or the second aspect and a controller, wherein at least a portion of a communication link between the apparatus and controller is a fieldbus connection. The controller is for example configured to determine desired control information based on control information comprised in a message received by the apparatus. 
     The controller is in one variant configured to generate the message comprising the control information. The controller may be configured to generate the current message comprising the control information. 
     According to a fifth aspect, a system is provided. The system comprises the apparatus of the first aspect or the apparatus of the second aspect. The system further comprises at least one of the apparatus of the first aspect, the apparatus of the second aspect and the apparatus comprised in the system of the third aspect. 
     Alternatively, the system comprises the apparatus of the first aspect or the apparatus of the second aspect, and the system of the fourth aspect. 
     The system in one variant comprises at least one of the apparatus of the first aspect, the apparatus of the second aspect and the apparatus comprised in the system of the third aspect. The system in this case further comprises the system of the third aspect. 
     The system for example comprises the system of the third aspect and the system of the fourth aspect. 
     According to a sixth aspect, a method for selecting a transmission mode for transmitting a message comprising control information of a robotic device is provided. The method comprises comparing a current message, which is to be transmitted after a previous message, with the previous message to identify a change in the control information from the previous message to the current message. The method further comprises selecting one of a normal transmission mode and a robust transmission mode which is more robust than the normal transmission mode, wherein the robust transmission mode is selected if a change in the control information is identified. In addition, the method comprises triggering wireless transmission of the current message with the selected transmission mode. 
     According to a seventh aspect, a method for selecting a transmission mode for transmitting a message comprising control information for robotic device control is provided. A robot communication protocol based on which a robotic device can receive or send messages defines a threshold for a count of consecutively not correctly received messages. The robotic device performs an emergency action in case the count exceeds the threshold. The method comprises obtaining a count of consecutively not correctly received messages and selecting one of a normal transmission mode and a robust transmission mode which is more robust than the normal transmission mode, wherein the robust transmission mode is selected if the count equals or approaches the threshold. In addition, the method comprises triggering wireless transmission of the message with the selected transmission mode. 
     At least one of the method of the sixth aspect and the method of the seventh aspect may be performed by the apparatus of the first aspect, the apparatus of the second aspect or the apparatus comprised in the system of the third aspect. 
     According to an eighth aspect, a cloud computing system is provided which is configured to perform at least one of the method of the sixth aspect and the method of the seventh aspect. The cloud computing system may comprise distributed cloud computing resources that jointly perform at least one of the method of the first aspect and the method of the second aspect under control of one or more computer program products. For example, at least one of the apparatus of the first aspect, the apparatus of the second aspect and the apparatus comprised in the system of the third aspect may be a part of the cloud computing system. 
     According to a ninth aspect, a computer program is provide computer program comprises instructions which, when the program is executed by a processor, cause the processor to carry out at least one of the method of the first aspect and the method of the second aspect. The computer program may also be provided for download via a network connection. 
     According to a tenth aspect, a computer-readable medium comprising the computer program of the ninth aspect is provided. 
     According to an eleventh aspect, a data carrier signal carrying information which represents the computer program of the ninth aspect is provided. 
     Furthermore, a computer-readable medium comprising the computer program is provided, and a data carrier signal carrying information which represents the computer program. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Further aspects, details and advantages of the present disclosure will become apparent from the detailed description of exemplary embodiments below and from the drawings, wherein: 
         FIGS. 1A  &amp; B illustrate network system embodiments of the present disclosure; 
         FIGS. 2A  &amp; B illustrate apparatus embodiments of the present disclosure; 
         FIGS. 3A  &amp; B illustrate further apparatus embodiments of the present disclosure; 
         FIG. 4  illustrates a method embodiment of the present disclosure; 
         FIG. 5  illustrates a further method embodiment of the present disclosure; 
         FIG. 6  illustrates a still further method embodiment of the present disclosure; 
         FIG. 7  illustrates masking of a message according to the present disclosure; and 
         FIG. 8  illustrates a time sequence of message transmission according to the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be practiced in other embodiments that depart from these specific details. 
     While, for example, the following description focuses on specific radio access network types such as 5 th  Generation (5G) networks, the present disclosure can also be implemented in connection with other radio access network types or using fully wired (e.g., fieldbus) connections. Moreover, while certain aspects in the following description will exemplarily be described in connection with cellular networks, particularly as standardized by 3GPP, the present disclosure is not restricted to any specific wireless access type. 
     Those skilled in the art will further appreciate that the steps, services and functions explained herein may be implemented using individual hardware circuitry, using software functioning in conjunction with a programmed microprocessor or general purpose computer, using one or more Application Specific Integrated Circuits (ASICs) and/or using one or more Digital Signal Processors (DSPs). It will also be appreciated that when the present disclosure is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors. 
     In the following description of exemplary embodiments, the same reference numerals denote the same or similar components. 
       FIG. 1A  illustrates an embodiment of a network system  100  for computing cloud-based robot cell control. As shown in  FIG. 1A , the network system  100  comprises a robot cell domain  100 A, a wireless access domain  100 B as well as a cloud computing domain  100 C. 
     The robot cell domain  100 A comprises at least one robot cell  101  with multiple robotic devices  102  each having a dedicated local robot controller  102 A in association therewith. Each of the robotic devices  102  can comprise various actuators that jointly define a robot arm movable within multiple degrees of freedom. Two or more of robotic devices  102  within the robot cell  101  may collaboratively work on the same task (e.g., on the same work product). 
     The robot cell domain  100 A further comprises multiple sensors  104  such as cameras, position sensors, orientation sensors, movement sensors, and so on. The sensors  104  generate sensor data indicative of a state of at least one robotic device  102  comprised in the robot cell  101  (i.e., cell state data). The sensors  104  can be freely distributed in the robot cell  101 . One or more of the sensors  104  can also be integrated into one or more of the robotic devices  102 . 
     In some implementations the sensor data provided by the sensors  104  constitute feedback data, in particular for a closed-loop control of at least one of the robotic devices  102 . At least one of the sensors  104  may be a camera. In robotics, visual servoing, also known as vision-based control, is a technique which uses a visual feedback to control the motion(s) of one or more of the robotic devices  102 . There are two fundamental configurations: eye-in-hand, where the camera  104  is attached to a robotic arm of the robotic device  102  and configured to observe a relative position of a target, and eye-to-hand, where the camera  104  is fixed relative to the robotic arm and configured to observe a target and a motion of the robotic arm  102 . 
     The wireless access domain  100 B may comprise a cellular or non-cellular network, such as a cellular network specified by 3GPP. In some implementations, the wireless access domain  100 B may be compliant with the 3GPP standards according to Release R 15 , such as TS 23.503 V15.1.0 (2018-3) or later. 
     As illustrated in  FIG. 1A  by dashed arrows, the robotic devices  102  with their associated robot controllers  102 A are configured to receive via the wireless access domain  100 B control information for robotic device control generated in the cloud computing domain  100 C. Moreover, as indicated by regular arrows, the sensors  104  are configured to provide the feedback data as control information for robotic device control via the wireless access domain  100 B to the cloud computing domain  100 C. 
     The wireless access domain  100 B generally comprises equipment that enables a wireless communication between the robot cell domain  100 A on the one hand and the cloud computing domain  100 C on the other hand via the wireless access domain  100 B. The equipment may comprise a base station of a radio access network (RAN) or a wireless access point interfacing the cloud computing domain  100 C and a wireless terminal device interfacing the robot cell domain  100 A). In the specific example shown in  FIG. 1A , the wireless access domain  100 B comprises a user equipment (UE)  106  interfacing the robot cell domain  100 A and an RAN  108  interfacing the could computing domain  100 C. The communication link between the UE  106  and the robot cell domain  100 A may comprise or consist of a wired connection (e.g., using a fieldbus such as ProfiNet). In a similar manner, the communication link between the RAN  108  and the cloud computing domain  100 C may comprise or consist of a wired connection (e.g., using a fieldbus such as ProfiNet). 
     UE  106  comprises a radio bearer control unit  110 A and a priority identification unit  112 A. The priority identification unit  112 A is configured to analyze a message comprising control information for robotic device control (e.g., as determined by one of the sensors  104 ) and to select a transmission mode for wireless transmission of the message to wireless access domain  100 B. The radio bearer control unit  110 A is configured to set up a radio bearer  114 A for message transmission accordingly. RAN  108  has a closely similar configuration to UE  106 . RAN  108  comprises a radio bearer control unit  110 B and a priority identification unit  112 B. The priority identification unit  112 B is configured to analyze a message comprising control information for robotic device control and to select a transmission mode for wireless transmission of the message to UE  106 . The radio bearer control unit  110 B is configured to set up radio bearer  114 B for message transmission accordingly. 
     As further illustrated in  FIG. 1A , the cloud computing domain  100 C comprises a controller  110  which is configured to determine control information for robotic device control based on feedback data received from the sensors  104  via wireless access domain  100 B. The controller  110  is composed of cloud computing resources. The control information generated by the controller  110  may include movement instructions for a movement trajectory of at least one of the robotic devices  102 . The movement instruction for a particular robotic device may be generated by the controller  110  based on control information (i.e., feedback data) obtained for that robotic device from an associated sensor  104 . 
     The robot controller  102 A in the robot cell domain  100 A and the controller  110  in the cloud computing domain  100 C communicate with each other using a dedicated industrial automation communication protocol such as a fieldbus protocol (e.g., based on ProfiNet). The fieldbus protocol works symmetrically in both uplink, UL, and downlink, DL, directions. Based on the fieldbus protocol, the robotic device  102  can receive messages from the controller  110  or send messages to the controller  110 . The fieldbus protocol may also be used to transmit messages from robot controller  102 A to the controller  110  and to transmit messages from the controller  110  to robot controller  102 A. 
     As can be seen in  FIG. 1A , the same functionality is implemented in both UL and DL directions. In other words, UE  106  and RAN  108  are configured in a closely similar manner: In UE  106  and also in RAN  108 , a message is first analyzed by the priority identification units  112 A,  112 B. The priority identification unit  112 A,  112 B may perform their analyses based on shallow packet inspection or deep packet inspection techniques. The radio bearer control units  110 A,  110 B then sets up the radio bearer  114 A,  114 B based on a result of the analysis. 
     The fieldbus protocol in some variants defines a threshold for a count of consecutively not correctly received messages, for example a threshold of 3, 6 or 9. The robotic devices  102  may be configured to perform an emergency action under control of the associated robot controller  10 A in case the local count exceeds the threshold, for example an emergency stop. The protocol further defines a time interval at which messages are to be transmitted, for example a time interval of 1 ms up to 512 ms for real-time communication. 
     The feedback data as acquired by the sensors  104  are communicated to the cloud computing domain  100 C to inform same about the state of the robot cell  101 . Processing of the feedback data (e.g., in the context of inverse kinematics) at least partially takes place in the cloud computing domain  100 C. The processed feedback data may then form the basis for movement instruction generation by the controller  110  in the computing cloud domain  100 C, wherein the control information comprises the movement instruction. Additionally, or in the alternative, movement instruction generation in the cloud computing domain  100 C is based on actions defined in an action plan for one or more of the robotic devices  102 . The control information as received by the controller  110  from the robot cell  101  may include the feedback data. Also in this case, the control information is usable for robotic device control since it forms the basis for the determination of the movement instructions. 
     In more detail, the sensors  104  are configured to transmit a message comprising feedback data as control information to UE  106  via a fieldbus connection. UE  106  is configured to trigger wireless transmission of the message comprising the feedback data over radio bearer  114 A to RAN  108 . The RAN  108  is configured to receive the message that will then be forwarded via a fieldbus connection to the controller  110  in the cloud computing domain  100 C. 
     Controller  110  is configured to generate a message comprising a movement instruction as control information for one of the robotic devices  102 . The message is generated based on the feedback data as received for the particular robotic device and/or based on an action plan as defined for the particular robotic device  102 . The message is forwarded via a fieldbus connection to RAN  108 . The RAN  108  is configured to trigger wireless transmission of the generated message over radio bearer  114 B to UE  106 . The UE  106  is configured to forward the message via a fieldbus connection. Each of the robot controllers  102 A is configured to receive the message via the fieldbus connection and to control one or more individual actuators of the respective robotic device  102  based thereon. 
     In some variants, the robotic device  102  is or comprises a robotic arm. The robotic arm comprises multiple independently actuatable joints that define multiple degrees of freedom for robot arm movement. As understood herein, a movement instruction may pertain to the robot arm as a whole (and may thus comprise multiple sub-commands for the individual joint actuators), or it may pertain to an individual joint actuator of a multi-joint robot arm. A movement instruction pertaining to a robot arm movement may thus result in an action corresponding to a particular robot arm movement. 
       FIG. 1B  illustrates an embodiment of a further network system  100  similar to the one shown in  FIG. 1A . In the network system  100  of  FIG. 1B , only robot cell domain  100 A and UE  106  comprised in the wireless access domain  100 B are shown. Note that also RAN  108  comprised in wireless access domain  100 B and cloud computing domain  100 C illustrated in  FIG. 1A  are part of the network system  100  as shown in  FIG. 1B . The local robot controllers  102 A of  FIG. 1A  are replaced by a central gateway controller  102 B. This gateway controller  102 B is configured to receive the messages from the wireless access domain  100 B, in particular from UE  106 , and to control one or more individual actuators of each of the robotic devices  102  in the robot cell  101  based thereon. The connections between the gateway controller  102 B and the robotic devices  102  may be wire-based (e.g., based on fieldbuses). The connection between the gateway controller  102 B and wireless access domain  100 C, in particular UE  106 , may be wire-based (e.g., based on a fieldbus). Using a central gateway controller  102 B, a synchronous control of interworking robotic devices  102  becomes easier. The gateway controller  102 B also collects the feedback data from the sensors  104  for wireless transmission of same as control information to the computing cloud domain  100 C. The connections between the gateway controller  102 B and the sensors  104  may be wire-based (e.g., based on a fieldbus). 
     The network embodiments illustrated in  FIGS. 1A and 1B  can be combined in various ways. For example, each robotic device  102  may comprise an associated robot controller  102 A as illustrated in  FIG. 1A , and the robot controllers  102 A may be attached to the gateway controller  102 B of  FIG. 1B  using wire-based connections (e.g., field buses). 
       FIGS. 2A and 2B  illustrate two embodiments of the UE  106  of  FIGS. 1A and 1B . In the embodiment illustrated in  FIG. 2A , the UE  106  comprises a processor  202  and a memory  204  coupled to the processor  202 . Optionally, the UE  106  further comprises one or more interfaces for communication with other components of the network system  100  of  FIGS. 1A and 1B , in particular with the robot cell domain  100 A and the RAN  108 . The processor  202  may be configured to implement the functions of the radio bearer control unit  110 A and the priority identification unit  112 A. 
       FIG. 2B  shows an embodiment in which the UE  106  is implemented in a modular configuration. As shown in  FIG. 2B , the UE  106  comprises a comparing/obtaining module  206 , a selecting module  208  and a triggering module  210 . These modules may be implemented by processor  202  or by circuitry, or by a combination thereof. 
     RAN  108  may be configured in a similar manner as UE  106  described above.  FIGS. 3A and 3B  illustrate two embodiments of the RAN  108  of  FIGS. 1A and 1B . In the embodiment illustrated in  FIG. 3A , the RAN  108  comprises a processor  302  and a memory  304  coupled to the processor  302 . Optionally, the RAN  108  further comprises one or more interfaces for communication with other components of the network system  100  of  FIGS. 1A and 1B , in particular with the cloud computing domain  100 C and the UE  106 . The processor  302  may be configured to implement the functions of the radio bearer control unit  110 B and the priority identification unit  112 B. 
       FIG. 3B  shows an embodiment in which the RAN  108  is implemented in a modular configuration. As shown in  FIG. 3B , the RAN  108  comprises a comparing/obtaining module  306 , a selecting module  308  and a triggering module  310 . These modules may be implemented by processor  302 , by circuitry, or by a combination thereof. 
       FIG. 4  shows a method embodiment of the present disclosure. The method is executed by at least one of the UE  106  and the RAN  108  described above with reference to  FIGS. 1A, 1B, 2A, 2B, 3A and 3B . In particular, at least one of the processor  202  and the processor  302  is configured to perform the method. 
     In the following, in case reference is made to processor  202  and modules  206 - 210 , it is to be understood that processor  302  and modules  306 - 310  may be configured in a similar manner to perform the steps mentioned below with reference to processor  202  and modules  206 - 210 . 
     In step S 402 , a current message, which is to be transmitted after a previous message, is compared by comparing module  208  with the previous message to identify a change in the control information from the previous message to the current message. The control information is comprised in the previous message and the current message and is configured for robotic device control of the robotic device  102 . Shallow packet inspection or deep packet inspection techniques may be applied in step S 402  to identify the control information change from one message to the next. 
     In step S 404 , selecting module  208  selects one of a normal transmission mode and a robust transmission mode which is more robust than the normal transmission mode for wireless transmission of the current message. The selecting module  208  is configured to select the robust transmission mode if a change in the control information is identified. In step S 406 , triggering module  210  triggers wireless transmission of the current message with the selected transmission mode. The processor  202  may be configured to perform steps S 402  to S 406 . 
       FIG. 5  shows another method embodiment of the present disclosure. The method may be executed by at least one of the UE  106  and the RAN  108  described above with reference to  FIGS. 1A, 1B, 2A, 2B, 3A and 3B . In particular, at least one of the processor  202  and the processor  302  may be configured to perform the method. The method shown in  FIG. 5  can be combined with the method described above with reference to  FIG. 4 . That is, at least one of the UE  106  and the RAN  108  can be configured to perform both the method of  FIG. 4  and the method of  FIG. 5 . 
     The method shown in  FIG. 5  relates to determining a transmission mode for transmitting a message comprising control information for robotic device control. In step S 502 , obtaining module  206  obtains a count of consecutively not correctly received messages. In step S 504 , selecting module  208  selects one of a normal transmission mode and a robust transmission mode which is more robust than the normal transmission mode based on the obtained count. Selecting module  210  selects the robust transmission mode if the count equals or approaches the threshold. For example, the robust transmission mode is selected in case the count reaches a number (e.g., 2) which is lower than the predetermined threshold (e.g., 3) by a predetermined amount (e.g., 1). The robust transmission mode may be selected in case the count falls into a predetermined range (e.g., 2-3) or assumes a predefined value (e.g., 2) before the predetermined threshold (e.g., 3). In step S 506 , triggering module  210  triggers wireless transmission of the message with the selected transmission mode. The processor  202  may be configured to perform steps S 502  to S 506 . 
       FIG. 6  shows a method embodiment of the present disclosure, which the apparatus described herein such as UE  106 , RAN  108  or a separate component in communication with UE  106  and/RAN  108  is configured to perform. The method of  FIG. 6  is an exemplary combination of the methods described above with reference to  FIGS. 4 and 5 . 
     In step S 602 , the count of consecutively not correctly received messages is obtained by processor  202 , in particular by obtaining module  206 . For each transmitted message a receiver (i.e., RAN  108 ) which received the transmitted message sends feedback. A positive acknowledgement, ACK, is sent for a correctly received message and if a corrupted message has been received, a negative acknowledgement, NACK, is sent. If a transmitter (i.e., UE  106 ) which transmitted the message did not receive any ACK within a predetermined time limit after sending the message, then a loss of the message is assumed. The predetermined time limit may correspond to or be lower than the time interval defined by the fieldbus protocol. 
     The number of consecutive packets for which no or no positive acknowledgement is received by the transmitter is counted. In case no ACK is received within the predetermined time limit for a transmitted message (S 604 ) or in case a NACK is received for the transmitted message, the count is increased by 1. In case an ACK is received for the transmitted message (S 608 ), the count is reset to 0. The count for consecutively not correctly received messages is determined on a transmission side. 
     In case UE  106  wirelessly transmits a message to RAN  108 , the count is determined by processor  202  of UE  106 . In this case, the count may be obtained by obtaining module  206 . Also in this case, the ACK or NACK may be received by UE  106  from RAN  108  after controller  110  has correctly received the transmitted message. On the other hand, in case RAN  108  wirelessly transmits a message to UE  106 , the count is determined by processor  302  of RAN  108 . The count may in this case be obtained by obtaining module  306 . Also in this case, the ACK or NACK may be received by RAN  108  from UE  106  after robot cell domain  100 A has correctly received the transmitted message. 
     In step S 610 , the current message is received by the apparatus. The current message is received by UE  106  from robot cell domain  100 A or the current message is received by RAN  108  from cloud computing domain  100 C. In step S 612 , it is checked whether the previous message transmitted by the corresponding apparatus was correctly received. In particular, it is checked by UE  106  whether the previous message transmitted from UE  106  to RAN  108  was correctly received by RAN  108  or it is checked by RAN  108  whether the previous message transmitted from RAN  108  to UE  106  was correctly received by UE  106 . 
     In case no ACK was received for the previous message, the count of consecutively not correctly received messages is increased by 1 and the method proceeds to step S 624  described below. In case an ACK was received for the previous message, the count of consecutively not correctly received messages is reset to 0 and the method proceeds to step S 616 . In other words, before triggering transmission of a message, the count of consecutively not correctly received messages is checked. If it is 0, then the method proceeds to step S 616 . If the count is larger than 0, a robust transmission is required (e.g. a robust modulation scheme or multiple message transmission). 
     In step S 616 , the current message is masked and a hash of an unmasked part of the current message is determined. A hash of an unmasked part of the previous message may be obtained (for example from UE  106  or RAN  108 ) or determined by the apparatus. The determined hash of the unmasked part is compared with the hash of the unmasked part of the previous message in step S 618 . It is determined whether both hashes are similar, i.e., equal, to one another in step S 620 . If this is the case, the method proceeds to step S 622  and the normal transmission mode is selected, for example by selecting module  208  or  308 . If the two hashes are not similar to one another, the method proceeds to step S 624 . In step S 624 , the robust transmission mode is selected, for example by selecting module  208  or  308 . The higher the count of consecutively not correctly received messages, the more robust is the selected transmission mode (e.g., double transmission of the message in case of the count equals 1 and triple transmission of the message in case the count equals 2). 
     The robust transmission mode is more robust than the normal transmission mode. For example, a higher transmission power may be selected compared to the normal transmission mode. Alternatively, or in addition, a modulation scheme can be applied for the robust transmission mode which is more reliable and results in lower probability of a loss of a message, i.e., ensures a higher chance of successful message transmission. For example, using 4-QAM instead of 64-QAM at the same transmission power or higher transmission power increases the chances for a successful transmission of a message. In general, radio mechanisms or transmission mechanisms which increase the probability of successful message transmission can be used for the robust transmission mode. To increase the probability, modulation and transmission power may be chosen appropriately. 
     The purpose of steps S 616  to S 620  is to identify a change in control information between the current message and the previous message. In general, most of the time the payloads of the consecutive messages are the same (e.g., because one and the same movement instruction is sent repeatedly in consecutive messages from the controller  110  or since the feedback data as determined by one of the sensors  104  does not change over messages consecutively received at the controller  110 ). However, when, for example, the controller  110  (e.g., in a PLC-based implementation) changes the value of a field in a memory area, then the payload of the forthcoming fieldbus message delivers this change to the corresponding robotic device  102 . This mechanism is also the same in the opposite direction (e.g., in case the feedback data change due to a movement of the robotic device  102 ). These messages are important messages from a reaction time point of view since they carry updated information. Thus, a reliable transmission of such messages should be ensured by selecting the robust transmission mode instead of the normal transmission mode for wirelessly transmitting these messages. Details on the identification of a change in control information will now be discussed with reference to  FIG. 7 . 
       FIG. 7  shows a general overview of a structure of a message according to an exemplary fieldbus protocol and how the masking is performed according to the techniques disclosed herein, in particular the methods described above with reference to  FIGS. 4 and 6  (see for example step S 402  and steps S 616  et seq.). 
     A part of the current message is masked and a hash code of the remaining unmasked part is calculated. The mask has two components. First, fieldbus protocol fields (fieldbus protocol header  702 A and fieldbus protocol footer  702 B) may be masked. Second, parts  704  and  706  of the message having no effect on reaction time even if they should change are masked. The second mask specification is based on application logic. It depends on the type of action to be performed by the robotic device  102 . The mask selects the relevant fields, for example from a PLC memory area, from a reaction time point of view. For example, if the memory area contains several register values, and only one has impact on reaction time (e.g., its change triggers start/stop of a robotic device  102 ), then only that part  708  of the message is considered in hash code calculation. In the shown example, that part  708  represents the control information for robotic device control which has an effect on the reaction time. In general, parts of the message have an effect on reaction time which include a command relating to a movement of the robotic device  102 , or which include feedback data from the robotic device  102  to be used in calculating a next control command for the robotic device  102 . In the upper part of  FIG. 7 , four masked message parts  702 A,  702 B,  704  and  706  are illustrated. 
     By the masking operation, masked parts  710 A and  710 B as well as an unmasked part  712  of the message are determined (see lower half of  FIG. 7 ). In the shown example, unmasked part  712  equals the part  708  of the message that represents the control information of interest. The hash is determined for unmasked part  712  only, and not for masked parts  710 A and  710 B. 
     The industrial application (e.g., the controller  110 ) can define more masks and assign a priority value for each mask. For example, the mask which masks header  702 A and footer  702 B can be assigned a low priority, whilst the mask which masks header  702 A and footer  702 B as well as parts  704  and  706  can be assigned a high priority. In case a change in an unmasked part between the previous message and the current message is identified based on a mask, the priority level of this mask is considered to select the robust transmission mode. 
     In the given example, a change may be identified in part  708  based on the mask with the associated high priority. A change may at the same time also be identified in parts  704 ,  706  and  708  based on the mask with the associated low priority. Then, the mask with the higher priority is chosen in order to select the robust transmission mode, wherein the robust transmission mode is selected based on the priority level of the chosen mask. For example, a change in a highest priority field (e.g., part  708 ) of the message requires as robust transmission as possible. For example, an identified change based on the mask with the associated low priority may originate from part  704 . This change may not be that critical and thus, a transmission mode having a lower robustness may be selected. The masks and priority levels may be determined by the industrial application (i.e., controller  110 ) and obtained by the apparatus (i.e., UE  106  or RAN  108 ). 
       FIG. 8  shows a time sequence of subsequently transmitted messages. The messages are transmitted after triggering transmission with a selected transmission mode, wherein the selection is performed according to the method of  FIG. 4, 5 or 6 . In other words, the UE  106  or the RAN  108  may be configured to transmit the message (also referred to as the current message) according to the shown time sequence of  FIG. 8 . 
     At a first point in time t 1 , a first message  802  is transmitted once. At a second point in time t 2 , a second message  804  is transmitted three times. This is because a robust transmission mode has been selected for transmitting the second message because a change in the control information has been identified between the first message  802  and the second message  804 . Thus, the robust transmission mode has been selected for transmitting the second message. 
     At a third point in time t 3 , a third message  806  is transmitted once. The third message  804  is transmitted with a robust transmission mode which uses a more robust modulation scheme instead of multiple message transmission. Also this case, the robust transmission mode is selected due to a change in the control information between the second message  804  and the third message  806 . 
     At a fourth point in time t 4 , a fourth message  808  is transmitted. The fourth message  804  is transmitted with the normal transmission mode since no change in control information between the third and the fourth message  808  has been identified based on the individual hash codes and since the third message  806  was correctly received and the count of subsequently not correctly received messages has been reset to 0 before transmitting the fourth message  808 . 
     The technique presented herein may be implemented using a variety of robot programming tools and languages. For example, the robot programming language may be based on C++. 
     In summary, a fieldbus-aware wireless message transmission scheme is disclosed. Situations when robust transmission is required are identified pro-actively to avoid fieldbus connection failures that are reported to the controller  110  and possibly culminate in a stop of the robotic cell  101 . Also, loss of messages is prevented, which loss increases the reaction time of the controller  110  and the robotic device  102 . 
     The number of consecutively not correctly received (e.g., missing) messages is counted on the transmitter side. If the loss of a next message would result in a fieldbus connection failure, then that message is proactively transmitted in a more robust way using a robust transmission mode (e.g., using message duplication). In addition to this, or as an alternative, the robust transmission mode may be used when a change in the control information comprised in the current message compared to the previous one is identified. 
     The content of the current message, the content of the previous message and the transmission status of previous messages are thus determined in some variants. Based on this information, the transmission mode is selected to avoid a connectivity problem due to use of a wireless connection and to avoid an increase of reaction time. 
     The present technique makes a fieldbus-based connection more robust when it stretches over a wireless link. It also avoids an increase in reaction time due to inherent issues of wireless transmission mechanisms. In addition, radio resource usage can be minimized by avoiding unnecessary retransmissions. 
     Especially transmitting ProfiNet traffic over a wireless connection requires an ultra-reliable and low latency communication over the wireless connection. By taking into account the mechanisms of industrial applications and fieldbus technologies in wireless transmission as described herein, the efficiency of the ultra-reliable and low latency communication can be enhanced. 
     While the present disclosure has been described with reference to exemplary embodiments, it will be appreciated that the present disclosure can be modified in various ways without departing from the scoop of the present disclosure as defined in the appended claims.