The IEEE 1918.1 “Tactile Internet” Standards Working Group and its Standards

The IEEE “Tactile Internet” (TI) Standards working group (WG), designated the numbering IEEE 1918.1, undertakes pioneering work on the development of standards for the TI. This paper describes the WG, its intentions, and its developing baseline standard and the associated reasoning behind that and touches on a further standard already initiated under its scope: IEEE 1918.1.1 on “Haptic Codecs for the TI.” IEEE 1918.1 and its baseline standard aim to set the framework and act as the foundations for the TI, thereby also serving as a basis for further standards developed on TI within the WG. This paper discusses the aspects of the framework such as its created TI architecture, including the elements, functions, interfaces, and other considerations therein, as well as the novel aspects and differentiating factors compared with, e.g., 5G Ultra-Reliable Low-Latency Communication, where it is noted that the TI will likely operate as an overlay on other networks or combinations of networks. Key foundations of the WG and its baseline standard are also highlighted, including the intended use cases and associated requirements that the standard must serve, and the TI’s fundamental definition and assumptions as understood by the WG, among other aspects.


I. INTRODUCTION
The Tactile Internet (TI) is revolutionizing the understanding of what is possible through wireless communication systems, pushing boundaries of Internet-based applications to remote physical interaction, networked control of highly dynamic processes, and the communication of touch experiences (see [1] and [2]).Whereas senses such as hearing (audio) and sight (visual) or a combination thereof (audiovisual) are relatively less challenging to convey, touch (haptics) and particularly the kinesthetic (muscular movement) component therein have much stricter communication requirements.One reason for this is that stable and ultralow latency interaction needs to be guaranteed if the intention is to achieve sensorimotor control over the communication channel.A good example is the remote balancing of an object as achieved through the TI, as depicted in Fig. 1.Here, the skill involved in balancing the basketball on the tip of the finger needs to be conveyed over a communication channel without losing the temporally fine-grained feedback on the current balance of the ball and with extremely tight timeliness, such that the human can realize the situation and react, and the reaction be conveyed in time to the other end of the link-all before the basketball passes a point of no return and falls.
Aside from such human-client use of the TI, the situation might be even more challenging in cases where machines rather than humans are clients to the haptic interaction.This is because of the increased reactivity, impulsive force, and other enhanced physical capabilities of machines compared with humans.In the case of such machines using the TI, latency might be reduced from the requirement of around 5-ms round-trip for the most challenging human-client cases to as low as 1-ms round-trip for machine-client cases.Moreover, central to the TI is the more general realization of new realms of communication application not only requiring the ultralow latency touch interaction, but also ultrahigh reliability, security, and availability, such as industrial control (pertaining to "Industry 4.0" scenarios [3]).Ultrahigh reliability might also be required in many other TI scenarios, even human-client ones.One indicative scenario is the human-client case of remote (medical) surgery, where there can be no scope for the end-to-end (E2E) communication between the surgeon and the remote robotic machinery operating on the patient to be erroneous during, for example, a brain surgery.
It is noted that the sensors and actuators, and robotic, networking, computational and other components that comprise a TI system, as well as the dedicated haptic human-interaction hardware (e.g., haptic wearables) in some cases involved and comprising a combination of many of the above-mentioned elements, typically use different and often proprietary communication/interaction formats and means.Moreover, there are a range of differing and often conflicting decisions linked to the scenarios and structures that E2E TI deployments might assume.It is, therefore, necessary to standardize the aspects of the TI to harmonize such essentials.This will allow TI components to freely interact with each other directly out-of-the-box, without requiring custom/proprietary communication design that is dependent on the scenario and specific set of equipment used.Such standardization will also facilitate other aspects of the network supporting the TI to be deployed in a consistent way, such as network side processing.
The TI is one key example of the benefits of some of the pioneering capabilities argued for 5G and beyond communication systems, specifically the Ultra-Reliable Low-Latency Communication (URLLC) 5G mode of operation.However, the TI cannot redefine the standards that are being developed to realize 5G or other networks, or combinations of networks, on which it might run.In most realistic scenarios, the TI must simply operate on top of them.With this in mind, the IEEE 1918.1 TI standards are intended to complement and identify what is missing in 5G and other appropriate networks that might serve the TI, such as haptic communication protocols/codecs, and, e.g., network side support for the TI, emulating remote physical environments.As a side note on such emulation, simple propagation delay implies that the end points of the TI service can be a maximum of only 150 km apart (or only 100 km apart for propagation through fiber) to achieve the 1-ms E2E roundtrip latency needed in some TI scenarios.Emulation might significantly increase that distance while still conveying a convincing/realistic experience to the TI client.
The working group (WG) and its standards, particularly the IEEE 1918.1 baseline standard, also intend to define which functionalities and functional entities have to be present in which locations, the relationships between them, how they are interfaced, and how the overall network is invoked among other considerations.This paper addresses all such aspects.This paper is organized as follows.To set the scene, Section II provides a brief definition of the TI and outlines the important assumptions about the TI to which the WG operates.This section also covers some key related standards efforts and technologies, commenting on differentiating factors of the TI and the IEEE 1918.1 TI standards work with respect to those, in order to further assist understanding.Section III introduces IEEE 1918.1, providing essential grounding on the structure, reasoning and objectives of the WG and its baseline standard.Section IV continues the essential groundwork with a discussion on the use cases that the WG and its baseline standard aim to serve, each of which will ultimately be associated with a specific flavor of invoked TI service/session.This section also vitally covers the technical requirements that the standard must adhere to in order to realize those use cases.Section V delves into the real technical implementation of the TI through the standard, including its architecture comprising the key entities and functions, interfaces among those entities and functions, invocation of TI service/session instances ("bootstrapping" of the network), and the state machine, among other aspects.Section VI provides a brief introduction to the 1918.1.1 "Haptic Codecs for the TI" standard, including its objectives, reasoning, and structure of the flavors/modes of operation being developed therein.Finally, Section VII concludes this paper, thereby also providing some observations on what remains to be done.

A. Definition
Key in the development of a standard is to precisely understand the terminology involved such that it can be implemented consistently.It is therefore necessary to define the TI itself, particularly given that the TI has undergone different interpretations from different adopters, each having different objectives for the use of the technology.To this end, the definition of the TI has been agreed within the IEEE 1918.1 WG as: "A network (or network of networks) for remotely accessing, perceiving, manipulating, or controlling real or virtual objects or processes in perceived real time by humans or machines." It is also pivotal to define the context of the TI's operation and interactions.Building on the above-mentioned definition, we therefore detail seven core aspects of the TI as basic assumptions of the WG.
1) The TI provides a medium for remote physical interaction, which often requires the exchange of haptic information.2) This interaction may be among humans or machines or humans and machines.3) In the context of TI operation, the term "object" refers to any form of physical entity, including humans.Machines may include robots, networked functions, software, or any other connected entity.4) Scenarios encompassing human-in-the-loop physical interaction with haptic feedback are often referred to as bilateral haptic teleoperation.The goal of TI in such scenarios is that humans should not be able to distinguish between locally executing a manipulative task compared to remotely performing the same task across the TI.

5)
The results of machine-in-the-loop physical interactions will ideally be the same as if the machines were interacting with objects directly at-or close to-the locations of those objects.6) There are two broad categories of haptic information, namely, tactile or kinesthetic.There may also a combination of both.Tactile information refers to the perception of information by the various mechanoreceptors of the human skin, such as surface texture, friction, and temperature.Kinesthetic information refers to the information perceived by the skeleton, muscles, and tendons of the human body, such as force, torque, position, and velocity.7) The definition of perceived real time may differ for humans and machines and is therefore use case specific.
While the purpose of this section is to clearly define the TI and identify the scope of its interactions, it is ongoing work to ensure a common understanding of the metrics/key performance indicators (KPIs) used, contrasting, for example, with the definitions of latency that are being adopted under the 3GPP [4], [5].Further work is also continuing around the definitions of functions for the TI, as well as the selection or creation of definitions of basic as well as composite concepts that are repeatedly used in the standard.The exhaustive list of such definitions will be included in the baseline standard.

B. Differentiating Factors of the Tactile Internet Compared With Other Standards and Technologies
Also assisting the positioning of our IEEE TI WG and its standards, background on some completed or ongoing standardization activities either directly covering, or related to, the TI and its associated capabilities is provided here.A commentary is provided differentiating the TI from those.
At the top of the hierarchy in an international regulatory standards sense, the International Telecommunication Union Standardization Sector (ITU-T) has defined the TI as a ("Technology Watch") area and prepared an associated report covering aspects such as the TI's applications both in mission-critical and noncritical scopes, its benefits for society, implications for equipment, and other areas [6].It is noted that many of the aspects covered in this report are toward understanding (and indeed affirming) the worthiness of this new technology from an international perspective, as well as the definition of what it is and what it should involve.These are all vital steps in assessing the need and potential for standardization.At a similar international level, the International Standards Organization has prepared a standard covering the aspects of human-system interaction and specifically in this case haptic/tactile interaction [7].It is essential to understand such aspects to have an appropriate awareness of the information requirement and its formatting, for haptic/tactile exchanges in the TI.
The Society of Motion Picture and Television Engineers (SMPTE) has defined a standard aiming to capture the essence of haptic/tactile information, as well as what needs to be communicated and how it is represented, for the purpose of broadcast haptic/tactile information together with audiovisual information [8].This provides an interesting new viewpoint, given the unidirectional nature of broadcast and associated implications for reliability and latency (and the flexibility in both thereof), and its "open-loop" nature.Finally, the European Telecommunications Standards Institute (ETSI) is actively pursuing TI standardization through a work item on IPv6-based TI [9].Such higher layers work is essential to realize TI performance requirements in an E2E sense, given the involvement of the Internet for much of the communication path in many TI scenarios.
Of fundamental importance in the scope of related standards efforts are those developing and refining communication networks making them suitable for carrying TI/haptic traffic, among other traffic types.Again at the international regulatory level, the ITU-T has defined requirements for 5G communication systems [10] of which the URLLC mode of operation could serve TI use cases.In terms of mobile communication systems development, the 3rd-Generation Partnership Project (3GPP) is standardizing the systems realizing these requirements [11].To address URLLC services, 3GPP has specified several features for the 5G New Radio (NR) radio interface, which can be grouped into latency-reducing features and reliability-enhancing features [12].NR is based on an orthogonal frequency-division multiple access (OFDM) waveform, similar to the 3GPP long-term evolution (LTE) r a d i oi n t e r f a c e .I nc o n t r a s tt oL T E ,N Rp r o v i d e safl e x i b l e numerology, such that different subcarrier spacings can be used for the signal generation, leading to different lengths of the OFDM symbol.As a result, by increasing the OFDM subcarrier spacing from 15 kHz (as used in LTE) to 120 kHz, a 14-symbol transmission slot can be reduced from 1-ms to 125-µs duration.Furthermore, minislots have been introduced, which allows URLLC traffic to use even shorter time slots; URLLC can even preempt ongoing other transmissions to reduce queuing time at the transmitter.
For the uplink, a grant-free resource allocation scheme has been specified for URLLC traffic.It allows preconfiguring uplink transmission resources for URLLC services such that uplink data can be transmitted at the next allocated transmission opportunity.This shortens the uplink transmission compared with a normal resource allocation procedure whereby a device first requests transmission resources and is then allocated uplink resources from the base station.3GPP has also specified reliability-enhancing features for NR, with the purpose of being able to guarantee that data transmissions over the radio interface within a defined latency bound.These include the definition of highly robust transmission modes, including robust coding and modulation schemes and robust multiantenna transmission modes.Other features are multiconnectivity, where the data are duplicated at the transmitter and simultaneously transmitted to the receiver via different radio links.In real network deployments, practical limitations can put constraints on which and how features of the NR URLLC toolbox can be used.For example, the allocation of uplink and downlink resources varies between frequencydivision duplex and time-division duplex spectrum usage and impacts the latency, but also larger radio cell sizes can limit the subcarrier spacing to avoid intersymbol interference due to the time dispersion of the radio channel.In [2], it has been shown that the lowest achievable one-way transmission latencies that can be guaranteed with high reliability over the NR radio access network range from sub-millisecond level to a few milliseconds, depending on the used configuration.Different NR radio configurations also lead to different spectral efficiencies and coverage levels of the 5G radio access network.Those have been investigated in [13].
For enabling TI applications, it is insufficient to barely consider the 5G radio access network; the E2E connectivity needs to be considered including the 5G core network.The 5G communication system embraces several new communication paradigms that are beneficial for TI [14].First is the transformation of the network from a hardware-based to a software-based network design.Instead of performing specific network functions in dedicated hardware nodes, the communication infrastructure is built of a distributed computing platform, and network functions are realized as software that is executed on a suitable network node and allowing to configure an optimized network topology.In addition, as the network infrastructure constitutes a distributed computing platform, it is not only network functionality that can be realized within the network, but also application functions can be placed and executed on this distributed cloud platform.This allows putting applications at locations that provide the best performance, such as edge computing at the base station to minimize latency.A major challenge remains when TI services are applied over longer distances.
This challenge alludes to a first differentiating aspect of the TI and our standards effort compared with 5G URLLC for example, namely, that the TI must be developed in a way that can realize its requirements over longer distances than the 150 km (or 100 km in fiber) separation for a round-trip due to propagation in 1 ms.Such capability can be achieved through network side support functions built into the TI architecture, as envisioned through the standards work in IEEE 1918.1 [15].These functions could, for example, model the remote environment using artificial intelligence (AI) approaches and could in some cases also partly or totally be present at the TI end device (the client of the TI/haptic information).Furthermore, differentiating factors are also framed by the TI as an application, with unique characteristics implied by that application and with the expectation that the application can be deployed as an overlay network on top of almost any network or combination of networks-not intended to apply only in the context of 5G URLLC as the underlying communication means.Noting the greatly increased network flexibility in 5G and beyond contexts through sofwarization of network functions, the TI standards effort aims to be able to invoke the E2E TI service on top of such capabilities, conveying the constraints to configure network entities, interfaces and other factors based on t h es p e c i fi cu s ec a s ei nt h ec o n t e x to fs u c hf u l l yfl e x i b l e networks.This is acknowledging, however, that the TI and IEEE 1918.1 standard will also deal with the mapping of entities, interfaces, etc. to the hardware deployed in cases or portions of the utilized networks where there is less flexibility or no flexibility.Indeed, the developed architecture aims to act as a bootstrapping of such an overlay network, providing the means to rendezvous and negotiate/configure requirements/capabilities over each link toward the realization of the required architectural components/entities and overall communication path(s) to invoke the E2E use case and associated E2E requirements-using whichever appropriate communication means, of combination of means, available.Depending on the deployment scenario, such a bootstrapping might be combined with the utilized Haptic Codec (HC) negotiation or mode of operation information exchange, being covered under the scope of IEEE 1918.1.1 standards effort referred to later in Section VI.
It is noted here that the TI implies an extremely wide range of use cases and associated requirements, ranging from extremely easy to achieve in a communication sense, to the toughest latency and reliability constraints of any 5G application.Moreover, as well as bidirectional cases, the service might also aim to serve partially or fully unidirectional contexts-such as multicasting/broadcasting of TI information in haptic broadcasts or streaming.More information on the use cases considered in the TI WG is provided in Section IV.

III. IEEE TACTILE INTERNET STANDARDS WORKING GROUP (IEEE 1918.1)
The IEEE 1918.1 TI Standards WG [15] was formulated initially out of the IEEE ComSoc Standards Development Board (COM/SDB) 5G Rapid Reaction Standardization Initiative (RRSI), as a collaborative effort of King's College London and Technical University of Dresden (the latter having originated the concept of the TI) to bring a proposal for TI standardization to an RRSI meeting in Santa Clara, CA, USA, in November 2015.Approval from that meeting led to the development of a project authorization request (PAR), itself also thereafter being approved by the C O M / S D Bt ob es u b m i t t e dt ot h eI E E ES t a n d a r d sA s s o c iation (IEEE-SA) New Standards Committee (NesCom) for their consideration.This process, including all the stages in between, led to the approval of the PAR by NesCom and the wider IEEE-SA in March 2016, with the project to develop the baseline standard being authorized to operate until the end of 2020.However, it is noted that the intention is to complete the standard and submit it for IEEE-SA "Sponsor Ballot" earlier than that, likely in early 2019.
Paraphrasing the words of the PAR of IEEE 1918.1 [16], the scope of the baseline standard is to define a framework for the TI, including descriptions of its application scenarios, definitions and terminology, necessary functions involved, and technical assumptions.This will also fundamentally include the definition of a reference model and architecture for the TI, comprising the detailing of common architectural entities, interfaces between those entities, and the definition and mapping of functions to those entities.Moreover, in performing this paper, it is noted that the TI encompasses mission-critical applications (e.g., manufacturing, transportation, healthcare, and mobility), as well as noncritical applications (e.g., edutainment and events).The developed standard must therefore take into account and provision for the high reliability, security, and availability that apply in some of its deployment scenarios, as well as low latency, but must also be compatible with a considerable relaxation of such aspects even toward relatively high latency, low-reliability TI scenarios.
Expanding on the PAR, the WG and its baseline standard aim to serve as a foundation for the TI in general: a toolbox of items needed to invoke TI services from a network architecture and functionalities point of view.This includes the definition of entities that have to be involved in the E2E communication interaction, the mapping of functions to those entities, the interfacing of those entities/functions, and the core additional likely higher layer new functionalities that support the TI, such as Network Processing Support [likely termed a "support engine (SE)," in our context], providing functionalities such as emulating the remote environment.Such work encompasses also the invocation of the network, including the "bootstrapping" creation of the elements and other aspects of the network in general for the E2E service/session.
The standard also includes core baseline work on terminology for the TI, such that the standard's instructions can be consistently followed for the TI to be compatibly realized and understood among the manufacturers, operators, end users, and others that might take advantage of or implement the service, or that might in some other way be stakeholders.Furthermore, the standard precisely defines various use cases for the TI, the ultimate objective being that the selection among those use cases will be made at the invocation of the TI service, and the network will be configured accordingly.Use cases in IEEE 1918.1 are therefore defined in a codified way.
In addition to the above, the WG and its baseline standard aim to serve as a foundation for further standards adding extra capabilities, functionalities, or other complementary aspects related to the TI.An example of this is illustrated in Fig. 2. Here, you see that there can be additional standards within the WG which serve as standards in their own rights, i.e., they might operate alone, likely in conjunction with the baseline standard and its associated assumptions but not as a requirement.These standards are numbered IEEE 1918.1.X, "X" being a numerical designation in the same temporal order that the PARs for the standards are approved.Examples of such standards related to the TI are illustrated in the bottom row in Fig. 2. One reason for encompassing this form of standard is to maximize flexibility and impact.The IEEE 1918.1.1 "Haptic Codecs for the TI" standard is a good example of this, where the codecs being developed therein will be operable on the IEEE 1918.1 baseline standard scenarios and architecture, but will also be usable in far removed contexts outside of 1918.1, e.g., over a range of other networks.It is noted here that IEEE 1918.1.1 has already been initiated and is at a very mature stage of its standard development work.
The other forms of standards are amendment standards, which might add specific functionalities to the TI baseline standard building its capabilities.These are numbered IEEE 1918.1a,IEEE 1918.1b,etc., "a" and "b" being the first and second standards in terms of order of PAR approval.They are illustrated on the right side of the top row in Fig. 2, whereby in the TI context some examples of such amendment standards might be the addition of new use cases and perhaps entire protocols (as optional modes of operation) to support the use cases, and perhaps new architectural entities supporting the TI, among others.

IV. USE CASES AND REQUIREMENTS
Key to designing any system is the understanding of what is required of it.This derives out of defining the use cases that must be served, and the basic requirements for each of those use cases in terms of key characteristics and performance measures.To these ends, the current viewpoint on the list of use cases for the IEEE 1918.1 baseline standard is as follows.Figs.3-5 depict the realization of three of these use cases graphically, and Table 1 summarizes the assessments of the use cases' performance requirements and other traffic characteristics: 1) teleoperation; 2) automotive; 3) immersive virtual reality (IVR); 4) Internet of drones; 5) interpersonal communication; 6) live haptic-enabled broadcast; 7) cooperative automated driving.
The use cases are described in more detail as follows.
Teleoperation: Teleoperation allows human users to immerse into a distant or inaccessible environment to perform complex tasks.A typical teleoperation system, as illustrated in Fig. 3 Tab l e 1 KPI Requirements and Traffic Characteristics for the TI Use Cases between the user and the teleoperator.For example, the communication delay between the operator and the remote side jeopardizes the stability of teleoperation and negatively affects the quality of the user.With the advances of the TI, teleoperation systems can enjoy the offered ultralow delay communication services.
Thequalityofservice(QoS)requirementsandthecapabilities of teleoperation systems vary considerably with the dynamics of the remote environment where the teleoperator is placed.When the environment is highly dynamic (e.g., tele-soccer, where the user remotely operates his robotic avatar in a soccer game), the exchange of haptic signals is extremely time critical, with a latency requirement of 1-10 ms, in order to interact with fast moving objects.For teleoperation in a medium-dynamic environment (e.g., telesurgery and telerehabilitation), the teleoperator can react and move with reduced speed or copes with deformable objects.As a result, the latency requirement of haptic data exchange in this scenario is extended to 10-100 ms.For teleoperation in a static or quasi-static environment (e.g., telemaintenance), the latency requirement can be further extended to 100 ms-1 s.
Automotive: Future cars require a permanent connectivity with other cars and infrastructures to handle life-critical situations to reduce the mortality rate globally.Vehicular sensing data used by the driver to make the improved decision during driving events need to be transmitted in real time with almost zero delay.
In-vehicular networks are currently standardized within the IEEE 802.1 (IEEE 802.1BA,IEEE 802.1AS,IEEE 802.1Qat, and IEEE 802.1Qav) and consider trends in automotive high-speed networks and ultralow latency requirements.These requirements are driven by adding new applications into vehicles such as high-resolution cameras (4K and 8K) and sensors with high data rate volume [17].Such high data volume is used within the vehicle to support the driver in life-critical driving situations.To reduce the latency between the electronic control units, the IEEE 802.1 suggested new Ethernet standards particular in vehicular networks.Automotive audio-video bridging and time-sensitive networks are soon to be standardized and will allow new enhanced applications for remote control of driving functions that may be based on sensor fusion of in-vehicular sensing data with outside sensing data.The upper boundary of in-vehicular network delay is targeted below 1 ms [18].
To support the upper latency boundaries, the edge unit may be relevant to support local decision making among cars or within vehicular fleets (5G networks).New haptic applications may target the remote driving support of shuttles, trucks, and road machines in areas which are hard to serve or difficult to maintain.Remote driving requires spontaneous feedback, including haptic events, to make reliable decisions in life-critical situations.
Immersive Virtual Reality: IVR describes the case of a human interacting with virtual entities in a remote environment such that the perception of interaction with a real physical world is achieved.Users are supposed to perceive all five senses (vision, sound, touch, smell, and gustation) for full immersion in the virtual environment.Linked to the emergence of helmet-mounted VR devices such as Oculus VR, HTC Vive, PSVR, and Microsoft Hololens, among others, there is a burst of VR applications and interest in the entertainment industry, especially in the fields of VR video and VR Gaming.The IVR systems have already been applied or have enormous potential to be utilized in the numerous areas including education, health care, and skill transfer such as training drivers, pilot, and surgeon.
The degree of immersion achieved in IVR indicates how real the created virtual environment is.Even a tiny error in the preparation of the remote environment might be noticed, as humans are quite sensitive when using VR systems.Therefore, a high-field virtual environment (high-resolution images and 3-D stereo audio) is essential to achieve an ultimately immersive experience.Moreover, a key point of interest to the TI as a platform for IVR is latency.In order to avoid simulator sickness, motionto-photon delay (the time difference between the user's motion and corresponding change of the video image on display) should be less than 20 ms [19].Currently, the best VR kits cause less than 5-ms latency [20].Consequently, the communication latency for audio-visual media over the TI must be less than 15 ms.As for haptic feedback, Kaber et al. [21], [22] show that latency should be less than 25 ms for accurately completing haptic operations.As rendering and hardware introduce some delay, the communication delay for haptic modality should be reasonably less than 10 ms.As a result, the TI with ultralow latency is a quite appropriate platform for IVR systems.
Internet of Drones: With the unprecedented development of unmanned aerial vehicles (commonly known as drones), the utilization of drones to deliver parcels or vital items (e.g., emergency medicine or medical equipment for patients and critical urgent components for given tasks) will become possible and will be extensively applied.Already, many innovative firms, such as Amazon, Google, and DHL, have already tested the feasibility of drone delivery systems; however, only a very low number of drones have been involved in testing.In a long-term perspective, traffic management for delivery drones (similar to the air traffic control system applied to civil aviation) will be necessary as the scale of usage of drone delivery systems increases.Although drones follow prescribed thoroughly designed routes, collisions and other conflicts between drones will be inevitable considering that the number of deployed drones is expected to be enormous, with different sets of drones even operated by different companies.
As a result, it will be necessary to transmit real-time GPS data, audio data, video data, etc. obtained from various sensors in the drones to a control center for dynamic route allocation.Moreover, due to the high speed of drones and complexity of the drone delivery system, a low-latency communication network will be required to avoid damage to drones and delivered packages as well as property and human beneath the routes through drone collisions.Built on the TI, it will be possible to guarantee the ultralow latency, efficiency, reliability, and overall safety of the drone delivery system.In the foreseeable future, drones will be multifunctional and will be capable of completing sophisticated tasks, such as search and rescue for valuable objects or even humans in dangerous places, maintenance, and repair of devices located in hard-to-reach places/areas.In this context, humans rather than machines might act as controllers on the master side, with drones acting as slaves.Consequently, not only GPS, audio, and video data will be involved, but also haptic (kinaesthetic and tactile) information will be transmitted through the communication network.As for latency, Yang et al. [23] show that the network latency for audio image transmission and real-time control should be less than 40 and 20 ms, respectively.
Interpersonal Communication: The human touch of various forms including handshake, pat, or hug is fundamental to physical, social, and emotional development of humans.For instance, in close relationships such as family and friends, touch plays a prominent role for effective communication.Haptic interpersonal communication (HIC) aims to facilitate mediated touch (kinesthetic and/or tactile cues) over a computer network to feel the presence of a remote user and to perform social interactions.The application spectrum for HIC systems extends from social networking, gaming and entertainment to education, training, and health care [42], [43].
As shown in Fig. 4, a typical HIC system comprises a local user, a remote participant, a remote participant model at the local environment, and a local user model at the remote environment.Maintaining a human model for remote use involves the exchange of haptic data (position, velocity, interaction forces, etc.) and nonhaptic data (gestures, head movements and posture, eye contact, facial expressions, etc.).The system supports two types of interactions: dialogue interaction involves affecting the remote participant presence whereas observing interaction includes perceiving the remote participant presence.Note that the human models (remote participant or local user) can be either a physical entity (such as a social robot) or a virtual representation (such as a virtual reality avatar).With the advances of the TI, interpersonal communication systems can enjoy the high level of co-presence via the offered real-time ultrareliable communication services.
The QoS requirements and the capabilities of HIC systems vary considerably with the dynamics of the interaction with the remote participant [26], [27], [44].In the dialoging mode, where the interaction is highly dynamic (e.g., therapist-patient interaction, where the therapist remotely operates a local robotic avatar to assist the local patient to perform rehabilitation exercises), delays and reliability of haptic data communication are paramount for safe communication (a latency requirement of 0-50 ms).For the observing mode, where interaction is static or quasi-static (e.g., teletraining system, where a trainee will be observing the performance of a remote trainer), the latency requirement can be further extended to 0-200 ms.
Live Haptic-Enabled Broadcast: Continuing advances in picture quality, now up to "4K" with "8K" not far behind, streaming of post-produced and live content, including sports, new audio formats, growing interest in and increasing adoption of virtual reality, combined with viewers at home and on the go using their smartphones and tablets as their primary or "second screen" for watching TV, are creating challenges and opportunities for new technologies to come online to give consumers the type of personalized and immersive experience they are looking for.However, even with all these advancements in video and audio essence, there is still one important aspect missing, the ability to let the viewer actually "feel," "sense" or "perceive" the on-screen action creating a truly immersive and personalized experience.
Haptic-tactile broadcasting is the E2E use of technology to capture, encode, and broadcast-transmit, transport, by any means-decode, convert, and deliver the "feeling" or "impact" or "motion" of a live event so that a remote viewer can experience the same haptic-tactile experience of the live event at a remote location.It is the addition of this third essence type, haptics, in addition to the capture and transmission of the audio and video essences that make haptic-tactile broadcasting different from traditional broadcasts or streaming.This use case aims to provide the means for haptic-tactile essence to be transported or transmitted as an integral part of a live broadcast event that is distributed to the end user over the internet.For the end user, whether at their home, at a sporting or eSports venue, cinema or other location, the haptic-tactile data are decoded and converted into a digital or analog signal that is used by the appropriate electromechanical haptic-tactile consumer electronics hardware so that the end user can experience substantially the same haptic-tactile effects as the event's original haptic-tactile event.
Cooperative Automated Driving: Currently, most selfdriving vehicles rely on single-vehicle sensing/control functionalities, which have limited perception/ maneuvering performance.Without cooperation, in fact, the field of perception of the vehicle is limited to the local coverage of the onboard sensors.Furthermore, having no knowledge on how neighboring vehicles will behave, the automated control system needs to allocate a safety margin into the planned trajectory that in turn reduces the traffic flow.To guarantee safety and traffic efficiency at the same time, especially in envisioned scenarios with high density of self-driving vehicles, a paradigm shift is required from single-vehicle to multivehicle perception/ control.This will be enabled by the TI for vehicle-tovehicle/infrastructure (V2V/V2I) or vehicle-to-any (V2X) communications.TI V2X enables a fast and reliable exchange of highly detailed sensor data between vehicles, along with haptic information on driving trajectories, opening the door to the so-called cooperative perception and maneuvering functionalities [28], [29].By the TI connectivity, vehicles can perform a cooperative perception of the driving environment based on fast fusion of highdefinition local and remote maps collected by the onboard sensors of the surrounding vehicles (e.g., video streaming from camera, radar, or lidar).This allows to augment the sensing range of each vehicle and to extend the time horizon for situation prediction, with huge benefits for safety [30].
Furthermore, in cooperative maneuvering, continuous sharing and negotiation of the planned trajectories allow vehicles to synchronize to a common mobility pattern [31].Since the uncertainty on the neighboring vehicles' dynamics is reduced, the space headway can be lowered in safety forming tight autonomous convoys, with clear benefits in traffic efficiency.Although the existing V2X standards (i.e., IEEE 802.11p/WAVE and ETSI ITS-G5) support driver assistance and partial automation services, but they are not able to cover the requirements for higher levels of automation.For example, in the existing 1G V2X systems, a data rate is limited to 3-27 Mb/s (only exchange of highly aggregated information is supported), the message update rate is 10 Hz, and the E2E latency ranges from 100 ms down to 20 ms [32], [33].On the other hand, a latency of 1-10 ms is needed for realizing the stable control of a convoy of vehicles [34].The data rate for cooperative perception ranges from a few tens of megabits per second up to 1 Gb/s (in perspective), depending on the resolution of the exchanged maps.Furthermore, the onboard sensors in today self-driving cars generate data flows up to 1 GB/s [35], [36].All these requirements call for new network architectures interconnecting vehicles and infrastructure utilizing ultralow-latency networks based on the TI for cooperative driving services.

A. Overall Commentary on the Use Cases
Based on these use cases and their analysis, first, it is noted that, generally speaking, the IEEE P1918.1 TI standards work captures almost the complete range of expectations and performance requirements of the URLLC applications in 5G, perhaps with the exception of 5G capacity and data rates expectations.At one end of the extreme requirements of TI, for example, consider the teleoperation use case as shown in Fig. 3.This use case demands extremely high-reliability requirements to avoid any risk of significant (expensive) damage in industrial or teleoperation scenarios, or even worse where the damage could lead to fatality in the remote surgery case.Moreover, a machine with very fast reactivity (rather than a human) might act as the local control (i.e., client of the haptic service), and the remote environment might be highly dynamic, in which case the toughest latency requirements (1-ms round-trip) might also come into play.The remote environment in such cases will be more difficult to emulate, given the higher degree of required reliability and potentially other aspects such as dynamicity.
The interpersonal communication case shown in Fig. 4 could be seen as an intermediate example in terms of challenges for the underlying TI-enabled communication network.In this use case, the requirements are generally more relaxed in terms of reliability and E2E latency (5 ms or more will be acceptable given the human user element and the associated slower reactivity).Moreover, remote modeling will be simplified in such cases, given the r e d u c e dr e l i a b i l i t ya s p e c t .T h i si sr e l e v a n ta st h i su s ec a s e provides a good example of the potential use of a local edge network TI support (i.e., the "SE," a term we define later as part of our architecture) through local models of the remote participants being maintained at each end.
Finally, one example of a TI use case with highly relaxed requirements might be live haptic-enabled broadcast, which is illustrated in Fig. 5. Here, the communication is unidirectional, and the give-or-take requirements on how "live" the content is, latencies of hundreds of milliseconds, or even seconds, might be acceptable.However, this is as long as all components in the playback stream meet synchronization requirements (preferably synchronized with errors in nanosecond scales) as the haptic feedback must be synchronized as well.It is imperative that the end users associate haptic-tactile effects with both the video and the audio content broadcasted in the programs.In the case of high-action video content, users may associate haptic effects even more closely with what they see on their screens than with what they hear.Their expectation becomes that they should "feel" or "experience" visually depicted events as they occur, regardless of whether the event is heard.Thus, synchronization of audio, video, and haptic data becomes very crucial.This might, incidentally, be achieved by receiver buffering-thereby removing entirely the challenge for the communication network in achieving the required latency (e.g., jitter).Nevertheless, synchronization of data from different modalities in all the use cases would always be of paramount importance for users' quality of experience (QoE).In the case of hapticenabled broadcast, reliability is also significantly relaxed, even to the extent where there is a unidirectional channel hence no feedback or other recovery mechanism for reliability, although it is noted that the broadcast communication medium with extensive coding, or multiconnectivity broadcast solutions, can still lead to a high degree of reliability and are (in the case of multiconnectivity) even considered as prominent reliability solutions for 5G.

V. ARCHITECTURE
This section details some key aspects of the architecture being defined within the IEEE 1918.1 baseline standard, as derived out of the use cases and their requirements and other foundational aspects introduced in Sections II-IV.

A. System and Functional Architecture
The development of a system and functional architecture for the TI has been one of the key work items of IEEE 1918.1.The architecture is required to be generic and modular to support the wide range of TI use cases.It should be interoperable with various network interconnectivity options, including wired and wireless in addition to dedicated and shared network technologies.In order to meet the stringent E2E QoE requirements, the architecture should also provide advanced operation and management functionalities such as lightweight signaling protocols, distributed computing and caching with predictive analytics, intelligent adaptation with load and network conditions, and integration with external application service providers (ASPs).
The IEEE P1918.1 architecture is summarized in Figs. 6 and 7, which cover the various modes of interconnectivity network domains between two tactile edges.Each tactile edge consists of one or multiple tactile devices (TDs), where TDs in tactile edge A communicate tactile/haptic information with TDs in tactile edge B through a network domain, to meet the requirements a given TI use case.The network domain can be either a shared wireless network (e.g., 5G radio access and core network), shared wired network (e.g., Internet core network), dedicated wireless network (e.g., point-to-point microwave or millimeter wave link), or dedicated wired network (e.g., point-to-point leased line or fiber optic link) [2], [45], [46].This flexibility in terms of the network domain comes with major challenges in terms of meeting the quality requirements of tactile use cases and thus requires innovative solutions and effective intelligence for the nodes in the tactile edge.Moreover, it presumes that the network domain is able to provide an adequate level of performance under certain conditions; otherwise, meeting the E2E requirements can become impossible.
Each TD can support one or multiple of the following functions: sensing, actuation, haptic feedback, or control via one or multiple corresponding entities.A sensor (S) or actuator (A) entity refers to a device that performs sensing or actuation functions, respectively, without networking module; these entities can be from thirdparty vendors independent of the specifications of the IEEE P1918.1 standard.A sensor node (SN) or actuator node (AN) refers to a device that performs sensing or actuation functions, respectively, with an IEEE P1918.1 air interface network connectivity module.In order to connect S to SN or A to AN, a sensor gateway or actuator gateway entity should be used, respectively; these gateways provide a generic interface to connect to third-party sensing and actuation devices and another interface compliant with the IEEE P1918.1 standard to connect to SNs and ANs.A TD can also serve as a human-system interface node, which can convert human input into haptic output, or as a controller node (CN), which runs control algorithms for handling the operation of a system of SNs and ANs, with the necessary IEEE P1918.1 network connectivity module.
The gateway node (GN) is an entity with enhanced networking capabilities that reside at the interface between the tactile edge and the network domain and is mainly responsible for user plane data forwarding.The GN is accompanied by a network controller (NC) that is responsible for control plane processing including intelligence for admission and congestion control, service provisioning, resource management and optimization, and connection management in order to achieve the required QoS for the TI session.The GN and CN (together labeled as GNC) can reside either in the tactile edge side (as shown in Fig. 6) or in the network domain side (as shown in Fig. 7), depending on the network design and configuration.
The GNC is a central node as it facilitates interoperability with the various possible network domain options; this is essential for compatibility between the IEEE P1918.1 standard and other emerging standards such as the 3GPP 5G NR specifications.Allowing the GNC to reside in the network domain, for example under 5G, intends to support the option of absorbing its functionality into management and orchestration functionalities already therein.In Figs. 6 and 7, the network domain is shown to be composed of a radio access point or base station connected logically to control plane entities (CPEs) and user plane entities in the network core.
Another pioneering node in the architecture is the SE that provides both computing and storage resources for improving the performance of the tactile edges and meeting the delay and reliability requirements of the E2E communications.The SE will run advanced algorithms, employing AI techniques, among others, to offload processing operations that are too resource and/or energy intensive to be done in the TD (e.g., haptic rendering, motion trajectory prediction, and sensory compensation [47]).The goal is to enable the perception of real-time connectivity using predictive analytics while overcoming the challenges and uncertainties along the path between the source and destination TDs, dynamically estimate network load and rate variations over time to optimize resource utilization, and allow sharing of learned experiences about the environment among different TDs.On the other hand, the SE will also provide intelligent caching capabilities which can be very impactful in reducing the E2E traffic load and thus reducing the data transmission delays [48].The SE can reside locally within the tactile edge to enhance therespon serateforrequ estsfromTDsorGN C,an d/ori t can reside remotely in the cloud while providing services to the tactile edges and network domain.Moreover, the SE can be either centralized or distributed.Each of these options has its own pros and cons in terms of delay, reliability, capabilities, cost, and practical feasibility.
Each tactile edge may include multiple TDs that can communicate/cooperate among each other to further enhance performance.This can include TD-to-TD direct communications without going through the GNC or the network domain, e.g., in use cases that require information sharing among nearby TDs.This can also include cooperation in the form of relaying whereby, for example, a TD that is close to the GNC can act as a relay to another remote TD to reduce transmission delays, or in the form of distributed computing to reduce processing delays.This TD-to-TD connectivity is reflected in the architecture via a defined interface and would be managed by the central GNC node as it requires tight coordination and management to optimize the performance benefits.
The communications between the two tactile edges can be unidirectional or bidirectional, can be based on clientserver or peer-to-peer models and can belong to any of the use cases shown in Table 1 with their corresponding reliability and delay requirements.To this end, the tactile service manager (TSM) plays a critical role in defining the characteristics and requirements of the service between the two tactile edges and in disseminating this information to key nodes in the tactile edge and network domain.The TSM will also support functions such as registration and authentication and will provide an interface to external TI ASPs.In the future, TI applications can be provided either as value added services by network operators or as external services by ASPs; in the latter case, TDs would need to subscribe and authenticate with external servers as well in order to be able to run the corresponding applications and initiate E2E sessions.
In terms of scalability, the proposed architecture can support more than two tactile edges communicating among each other over a common network domain as part of a given TI use case.In addition, two tactile edges can communicate with each other over multiple network domains simultaneously which can significantly enhance reliability due to redundancy and reduce latency due to traffic splitting [49].This is reflected in Fig. 6 where, for example, tactile edge A can communicate with tactile edge B using two interfaces simultaneously, a 5G wireless network domain and a dedicated low latency wired network domain.Again here, the GNC is the node responsible for managing and coordinating traffic splitting over such multinetwork connectivity to optimize performance gains and achieve the target QoE.

B. Interfaces
A number of basic interfaces have been defined to serve interactions among the key entities in the TI architecture, as shown in Figs. 6 and 7.The key identified physical interfaces include the following.
1) Access (A) Interface: It provides connectivity between the tactile edge and the network domain.It is the main reference point for the user plane and the control plane information exchange between the network domain and the tactile edge.Depending on the architecture design, the A interface can be either between the TD and the network domain or between the GNC and the network domain.

2) Ta c t i l e ( T ) I n t e r f a c e : It provides connectivity between
entities within the tactile edge.It is the main reference point for the user plane and the control plane information exchange between the entities of the tactile edge.The T interface is divided into two subinterfaces Ta and T b to support different modes of TD connectivity, whereby the Ta interface is used for TD-to-TD communications and the T b interface is used for TD-to-GNC communications when the GNC resides in the tactile edge.

6)
In terms of performance requirements, meeting the E2E QoS targets for active TI sessions imposes specific requirements on each of the interfaces along the path from source to destination TDs.The relationship between the E2E requirements and the per interface requirements is complex due to statistical variability per interface and interdependence among different interfaces.The KPIs for each interface include the following.
1) The reliability of an interface measures its packet delivery performance.It is defined as the capability of transmitting a fixed size protocol data unit within a predefined time duration with high success probability.
2) The latency of an interface is a measure of its responsiveness.It is defined as the capability to successfully deliver a protocol layer packet from a transmitter to the same protocol layer receiver point in order to satisfy the E2E latency requirements.The E2E latency is defined as the one-way delay to successfully deliver an application layer packet from a TD in tactile edge A to a TD in tactile edge B.
3) The scalability of an interface describes its capability to cope and perform under an increased number of devices.It is defined as the maximum number of devices that can be supported without deteriorating the availability, reliability, and latency requirements.Table 1 on TI use cases presents typical values for some of these KPIs, but for E2E requirements.Typical requirements per interface are summarized in [50] where two grades of service are defined: normal grade and ultragrade.This is in order to better capture the variability in requirements among different use cases.

C. Bootstrapping of the Tactile Internet Service and Architecture Instantiation
Over the course of the TI operation, it is critical to define how TI communication will be invoked, and the paradigms under which TI communication would be maintained and terminated.We hereby propose three paradigms for establishing TI communication, focusing on how two TI components will bootstrap their remote communication and operation.The design and implementation of these paradigms depend on a number of factors beyond reliability and latency, including availability of TI resources, locality and distance between TDs, the availability and cost of delivery over communication infrastructures, and the computing resources dedicated to TI operation, both at the core and edge of the network [2].We therefore aim to detail these three paradigms, with their varying degrees of dependence on underlying infrastructure availability, then proceed to contrast the requirements as well as the shortcomings of each.Table 2 summarizes the main features of all three paradigms, in light of what they require to establish E2E TI sessions.
The design of the IEEE P1918.1 standard has purposefully encompassed a number of use cases and scenarios that will evidently favor one paradigm over the other(s).
We hereby focus on the architectural aspects of delivering these TI communication paradigms and the ensuing implications on the bootstrapping process.
1) Omnipresent Tactile Internet Paradigm: Under this paradigm, a network of TI components will form an everpresent and readily accessible TI core network.This core will comprise of the TSM and CPE, as well as an alwayson and redundant distribution of NC modules strategically placed around the globe.The goal of this core network is to enable rapid association with the TI infrastructure, via predetermined "access" gateways that are geographically and strategically spread.This infrastructure is in lieu of the Internet architecture, with predetermined access points that allow "latching" onto the TI infrastructure.Such access points could be either predeployed network modules or overlaid components in software-defined networks.
This omnipresent paradigm enables quick setup and recovery of TI communication sessions, as the sole task of a TD device is identifying the most suitable (closest, most capable, SE-equipped, etc.) latching point to the TI infrastructure.On the other hand, there is a significant cost tied to deploying and managing the upkeep of such TI resources, especially as an overlay layer on the top of an ever-changing communication infrastructure.
2) Ad Hoc Tactile Internet Paradigm: A major challenge in maintaining an ever-present architecture is the deployment and maintenance of TI components to enable rapid TI latching.In many scenarios, TI operation is confined to a geographically limited area, or URLLC requirements mandate a close proximity between TDs engaging in TI operation.In these scenarios, among others, there is neither the need nor the support for long-distance communication over different TI components.For example, in a local operation on the scale of an industrial factory, there would be little to no need for the network domain, and perhaps all TDs involved in a TI scenario would be communicating under the control of a single GNC.
Thus, we present an ad hoc TI communication paradigm, which assumes no "online" infrastructure to start with, yet resorts to the GNC setting up a TI connection from the edge of the network.If the TI session is to remain within the confinement of a single TI edge, then only the GNC will take over and manage the connection establishment, maintenance, and tear down with other TDs in that edge.If the TI session is to span one or more remote tactile edges, then the initiating GNC will probe a TSM module, potentially from a list of previously configured ones, or initiate a TSM-discovery protocol, to find a capable TSM.The TSM module will then orchestrate E2E communication from the initiating tactile edge, and solicit/recruit the services of all primary TI components.That is, the TI components that need to exist-in operation-in every TI session.
In contrast to the omnipresent paradigm, this ad hoc one assumes that TI architecture is triggered by a tactile edge.At its core, this is a minimalistic paradigm that views TI operation as a strictly overlay architecture, which is invoked as needed, and one which reduces the overall maintenance of a TI backbone.The obvious challenge is that it would take significantly longer to setup E2E TI communication and operation, in comparison to the omnipresent paradigm, as all resources have to be fetched, recruited/committed, and initialized to bootstrap E2E communication.
3) Hybrid Tactile Internet Paradigm: AnumberofTIscenarios assume that a focal TI point will always be online, to start TI communication with.While the resources to realize an omnipresent TI paradigm may not always be available, these TI applications would require initial setup in a dormant state, whereby E2E TI communication is merely a sequence of invocations.For example, in a use case for orchestrating collaborative input for the collective control of a remote device (e.g., production arm), each collaborating tactile edge would require what we label as a rendezvous point in the TI architecture to be always "online."The device acting as the rendezvous point will enact a number of protocols to solicit needed resources (e.g., SE) and will keep track of ongoing TI sessions.
In the general scenario, under the hybrid TI paradigm, it would be essential to maintain an always-online rendezvous point.Again, this could be a predeployed device (with many surrogates) that is always on, keeping track of what other TI sessions and components are currently online, and managing incoming requests to join sessions or initiate new ones.The rendezvous point could also be set up as a virtual function on a network function virtualization architecture.Regardless of the implementation, the design of this paradigm would necessitate deterministic protocols for setting up the rendezvous TI device and maintaining a scalable discovery protocol to enable rapid discovery of its surrogates by TD from different TI edges.
Invoking an E2E communication thus would be a two-step process.First, finding the rendezvous TI device should be comparable in speed to the latching process in the omnipresent paradigm.The second step would be triggered by that rendezvous device to establish E2E communication from one edge to the other, which involves invoking other TI components needed to realize this TI session.This rendezvous device could possibly be incorporated into the operation of the TSM.
4) Contrasting Tactile Internet Bootstrapping Paradigms: Enabling E2E communication and maintaining it across a wide spectrum of use cases are evidently nontrivial.One of the inherent challenges is fluctuations in network performance, which hinder guarantees of URLLC communication.Despite recent efforts in exploiting multiple interfaces to improve URLLC performance [51], there are mapping challenges in adopting these for TI communication.
The TI design is inherently built on the notion of edge mandated operational settings and core-managed E2E sustenance.That is, the TD at the edge would state its communication and operational parameters (e.g., expected latency and reliability) and communicate that to the TI architecture, which will then engage the required resources to meet such requirements, both in bootstrapping setup and E2E communication.Such paradigms have been heavily investigated in pertinent literature, to enable ap r i o r isetup of URLLC paths, including the solicitation and management of underlying network resources [52].
It is important to note that recent advancements in tangent technologies could significantly improve TI operation, both at the edge and the core of the network.For example, recent work on software-defined networking and network coding could significantly impact access and communication latency [53], thereby rendering E2E access more resilient with less setup time.This would, for instance, allow for a more fluid operation under the ad hoc and hybrid paradigms.Moreover, recent advancements in fine-tuning offloading operations and building on cloud variants [54] will inevitably aid both core and edge TI components in carrying out their assigned tasks.That includes offloading computationally intensive or power-demanding TI applications in remote environments [55], even in scenarios where TI operation may involve edge mobility that could capitalize on mobile edge computing [56].
TI operation, especially in terms of bootstrapping power-limited devices at the edge, could capitalize on nearby IoT systems that are designed for reliable operation [57].The rise of fog computing architectures will enable rapid resource discovery in edge environments, enabling a previously untapped pool of resources that could be utilized even in mobile settings, with finetuned decision making on the cost of offloading [58].Recent advances in the development of fog-computingbased radio access network [59] could aid both edge and network domain bootstrapping processes.

D. Tactile Internet Operational States
The TI architecture is designed to modularly encompass a wide spectrum of use cases and applications.That spectrum ranges from use cases requiring ultralow reliability and latency to ones with the infrequent sampling of haptic data over less stringent networking modes.Thus, it is pivotal to define the operational states in which a TD would exist, over the course of its active involvement.That is, starting from when the TD is activated to join/start TI communication, until it returns back to the dormant/offline state.
The remainder of this section highlights the operational states of a generic TI device, and its interaction with the TI architecture.We specifically focus on the functional capacity allowed under each operational state, which was carefully designed as a limiting factor to avoid functional mismatch and/or operational failure, according to the pertinent state of the TD.These states are summarized in Table 3.Furthermore, the deterministic transitions between these states are depicted in Fig. 8.
A TD device would start in the registration phase, which is defined as the act of establishing communication with the TI architecture.Under the omnipresent TI paradigm, registration will take place with a GNC, potentially including TI components from the network domain, such as the TSM.Hereafter, the "latching" point of the TD to initiate registration will be referred to as the TI Anchor.At this stage, the TD is probing the TI architecture to invoke E2E communication and cannot perform any other functions beyond latching onto the TI architecture.In both the ad hoc and the hybrid models, this step will involve the TSM, potentially via the GNC in the former, to establish registration.
The next state depends on the type of the TD.If it is a lower end SN/AN, then the TD will have a designated "parent" in its close proximity, with which the TD will need to associate with first.This parent TI node will thereafter ensure reliable operation and assist in connection establishment and error recovery.If a TD device operates independently, then this would be an optional step.
Some mission-critical TDs, as well as new ones, may need to be authenticated prior to being allowed to join/start a TI session.The third phase is an optional state in which a TD would communicate with the authenticating agent in the TI infrastructure to carry out authentication.The TSM is the main module that could carry out this task, perhaps with assistance from the SE when needed, or with significant amounts of traffic.
The TD will then commence its E2E control synchronization, where it will probe and establish a link to the end tactile edge.At this state, the TD is not allowed to communicate operational data, yet would focus on relaying connection setup and maintenance parameters.This may include setting the parameters for the interfaces along the E2E path, which will aid the network domain in selecting the optimal path throughout the network to deliver the requested connection parameters.This is a critical state, as it encompasses the path establishment and route selection phases of TI operation.More importantly, it will typically involve multiple tiers of the TI architecture, which will communicate to ensure that a path that meets the minimum requirements set in the "setup" message is indeed available and reserved.
If the TD engaging in a TI session is targeting haptic communication, then the next state would encompass the specific communication and establishment of hapticspecific information, still before actual data communication.This state is pivotal in deciding on the codecs, session parameters, and messaging formats specific to this current TI session.While different use cases may mandate different haptic exchange frequencies, it is expected that every haptic communication will start with the haptic synchronization state to establish initial parameters.Future changes to codecs and other haptic parameters will then be handled as data communication in the "operation" state.This is critical to ensuring that all haptic communication will enforce an initial setup, regardless of future updates to the parameters which may be included in operational data payloads.All TD components will then transition to the operational state.At this state, the E2E path has been established, it has met all connection setup requirements, and the tactile edges are ready to exchange TI information.This is expected to be the most time-dominant state, as it will encompass all TI data communication.
During operation in this state, one TD may detect an intermittent network error, in which case the TD will transition into "recovery" mode, in which designated protocols will take over error checking and potential correction mechanisms to attempt to reestablish reliable communication.If the error proves to be intermittent and is resolved, then the TD will transition back to the operational state.If for any reason the error perseveres, then the TD will transition back to control synchronization and rediscover whether or not an E2E path is indeed available under the operational requirements set out by the edge user.
Finally, once the TI operation is successfully completed, the TD will transition to "termination" phase, in which all the resources that were previously dedicated to this TD are released back to the TI management plane.If that was initially handled by the NC, then the resources return to it.Most typically, the TSM would be involved in the provisioning of TI resources.
The transitions across all these states are depicted in the finite state machine (FSM) in Fig. 8.It is important to note that these transitions are from the view of a single TD which has transitioned from dormant/off to the initial registration phase, which is the first phase of joining a TI network.The paradigm of communication detailed earlier will dictate the TI entity; this TD will communicate with, and the overall expectation for latency and reliability in establishing this E2E communication.This FSM is not meant to capture the protocol each entity would invoke under each state; however, it is kept generic to capture all types of connections.

E. Interface Messages
Finally, the communication between any two TI devices will require a predetermined header format with clearly defined fields.Without loss of generality, we designed a detailed messaging standard that will encompass the key TI data communication, including the parameters requested by the initiating TD to establish the expected E2E path.We present below an ASN.1-based [60] definition of a message being sent from one TD node to another TI component in the TI network.The messages are designed to be generic to capture the various types of TI communication.However, as TD transitions into the operational state, it may negotiate with the receiver, at the end of the E2E path, to commit to a lighter weight version of these messages, to reduce the size of headers.These messages are depicted in Fig. 9 and elaborated upon the following.
The overall definitions are self-explanatory, spanning typical headers that identify the sender and receiver.The specific field Mode is designed to detail the expected mode of operation for the current TD initiating/maintaining communication.This includes the operational parameters (opParams) which identify the expected thresholds for each of the four performance metrics explained in the interfaces section.The "Compensation" field identifies whether or not the current TD is engaging any AI-based compensation techniques, such as those adopted to compensate for inevitable delay/lag in communication.Lower end nodes which would require a parent node to operate would have the ControllerADDR field set to the address of the designated parent, which will carry a specific type of Pnode.If there is no such parent (i.e., a higher end TD node), this field would be set to null.The list of TI components that could carry out the task of a parent node is detailed under the Pnode field.
In the transmission of every message, the TD will identify the current state it is operating under, to ease the bootstrapping phase and expedite path establishment.This is captured under the state message component.Finally, the Stack field is designed to capture different protocol stacks that may serve as the foundational communication infrastructure upon which the TI would operate.That is, as we design an agile architecture for TI operation, it is pivotal to allow for message definitions that would highlight whether the operation is on the typical TCP/IP protocol stack, or on a potentially more scalable architecture such as ICNs.Any such new type would be listed under StackType which would also detail the LayerName if it is operating on a different architecture from TCP/IP.
The lighter weight version of these TI messages should be employed in the "Operation" state and could remove headers that detail the type of Node, the Parent Node, as well as the Stack field since these would typically not change once the initial control and haptic synchronization have taken place.

VI. HAPTIC CODECS FOR THE TACTILE INTERNET
As stated, the "Haptic Codecs for the TI" task group (IEEE 1918.1.1 [61]) is the standards project within the IEEE 1918.1 WG that has already been initiated and is currently actively undertaking its work.In the paraphrased words of the scope of its PAR [62], the aim is to define HCs for the TI addressing application scenarios where the human is "in the loop" or the client of the haptic information (e.g., teleoperation or remote touch applications), as well as scenarios based on machine remote control.It defines (perceptual) data reduction algorithms and schemes for both closed-loop (kinesthetic information exchange) and open-loop (tactile information exchange) communication.The codecs are being designed such that they can be combined with stabilizing control and local communication architectures for time-delayed teleoperation.Furthermore, the standard aims to specify mechanisms and protocols for the exchange of capabilities among haptic devices, e.g., defining the workspace, the number of degrees of freedom of equipment, the amplitude range of each, and temporal and spatial resolution.This is because it is essential to understand such aspects in order for the codec to operate with an appropriate configuration and parameters based on the given equipment in the utilized TI scenario.
The HC Task Group defines its work in phases initially assessing the requirements for all types of codecs it is considering, then splitting the work into the definition of two types of codecs based on their requirements: kinesthetic and tactile.The identified requirements are summarized in detail in [63] in this special issue.Fig. 10 provides an overview of the structure of the codec development within the HC Task Group.
The separation into these two types of codecs stems out of their fundamental differences; Kinesthetic information typically occurs within a closed-loop communication scenario and hence requires very strict latency support by the network, or stabilizing control at the application layer in case the E2E delay exceeds 5 ms.Tactile information typically occurs within open-loop communication scenarios,  hence is less delay sensitive.It is noted that in addition to the definition of the codecs, there is the development of a reference system for verification, evaluation, and crossvalidation of the proposed codec designs, as well as the preparation of reference software for each of them to propel the standardized solutions into the market.
In the following, we will describe each part under investigation in more detail.
Kinesthetic Codec (KC) (Part I): This part involves developing a codec for kinesthetic information, which typically consists of 3-D position, velocity, force, and torque data.These data are captured by appropriate sensors and need to be exchanged between different nodes of the TI for instance to teleoperate a robotic system remotely.The main objective of a KC is to reduce the update rate (average packet rate) to be transmitted between the two nodes while maintaining a high QoE.QoE in this context is mainly determined by the transparency of the system where ideal transparency refers to the situation where a user cannot distinguish between local and remote interaction.In other words, the user is not aware of the technical system mediating the teleoperation.In this context, two cases need to be distinguished.In the absence of communication delay, the codec does not require a control mechanism which stabilizes the physical interaction.On the other hand, in the presence of communication delay (typically above 5 ms), a stabilizing control mechanism needs to be deployed.While conceptually it would be possible to separate the KC from the control approach, there are some benefits for tightly coupling the two.This is why P1918.1.1 considers two subparts (named PartI-1 and PartI-2) to address these two different scenarios.Below each subpart will be introduced.
Delay Intolerant KC (Part I-1): It addresses the exchange of kinesthetic data in the absence of communication delay.As mentioned before, the main goal is to reduce the average number of packets to be transmitted bidirectionally between the two TI nodes.In order to achieve this, a mathematical model of human kinesthetic perception is introduced which is used to decide for a new sensor reading whether the transmission of this sensor value would lead to a perceptually noticeable change at the other side.If no, the corresponding value is perceptually irrelevant and can be discarded.Otherwise, it needs to be transmitted.This sample selection process can be independently applied to the force/torque or position/velocity values flowing in the two different directions.The adopted approach is based in the original KC design proposed in [65]- [67].To evaluate its suitability, the HC Task Group has developed a reference software/hardware setup [64] which can easily be reproduced by interested parties and which can be downloaded from the link provided in [64].The described approach has already been cross-validated by several independent groups and has been approved by the TI WG for standardization.
Delay Tolerant KC (Part I-2): In comparison addresses, the scenario where communication delay is present.When applying the Part I-1 solution, stable interaction cannot be guaranteed due to the latency introduced in the global control loop connecting the two TI nodes.Hence, a modified version, which incorporates a control mechanism to stabilize the system in the presence of network delay, is required.A similar evaluation procedure will be used to evaluate and cross-validate contributions addressing the requirements of this part.At the time of writing this paper, work in this direction has not been initiated.In the literature, a variety of approaches which are candidates for this part have been proposed (see [63] of this special for an extensive review).
Tactile Codec (TC) (Part II): The communication of tactile data, in comparison to kinesthetic communication, is open loop which leads to different requirements for TC development.Open-loop interaction in this context means that in particular the delay requirements are relaxed.This opens the opportunity for codec components, which cannot be used in KC design such as for example blockbased processing or frequency-domain models of human tactile perception.Although the tactile modality consists of several submodalities (hardness, thermal conductivity, friction, microroughness, and macroroughness), the HC Task Group has decided to start with vibrotactile signals which mainly address microroughness and friction.
In order to allow different groups to reproduce the evaluation procedure for the vibrotactile codec development, a reference hardware/software setup has been developed [68].In addition, vibrotactile reference data traces have been recorded which allow participation in the crossvalidation even without reproducing the reference setup.Again, in the literature, several approaches for (perceptual) vibrotactile coding have been proposed.These existing approaches, in addition to novel contributions, are to be evaluated and cross-validated by the HC Task Group.At the time of writing this paper, the corresponding Call for Contributions has just been published.Since tactile interaction can be single point or multipoint, again two subparts are addressed.
Single-Point TC (Part II-1): Here, the input to the TC is a 1-D vibrotactile signal (e.g., 100 Hz, 16 bit).The codec splits the vibrotactile signal into small segments and encodes these segments independently.Ideally, a model of vibrotactile perception is used to hide coding artifacts below the perceptual thresholds.In this sense, this coding process shares many similarities with speech/audio coding.Ideally, the codec is rate tunable.
Multipoint TC (Part II-2): As the extension of the singlepoint TC, multipoint tactile coding addressed the simultaneous stimulations of the human skin at several points.This will lead to more realistic (area-based) experiences.From a codec perspective, additionally to temporal correlation in the vibrotactile signal, now interchannel or spatial correlation can be exploited for maximum compression performance.
As the IEEE 1918.1 HCs Standard work is covered in more detail in another paper in this special issue (see [63]), we limit our description of it here.

VII. CONCLUSION
For reasons such as economies of scale and facilitation of user adoption, harmonization is needed of the behaviors of end devices and other components of the TI.This includes their interactions, deployments structures, and other aspects.Such harmonization, generally toward developing an overall system with expected actions and performances, etc., is achieved through internationally adopted standardization.
This paper has described the IEEE 1918.1 TI standards WG, including its philosophy and reasoning as well as the standards being defined therein.It has concentrated on the aspects of its developing baseline IEEE 1918.1 standard, including the standard's use cases and the requirements of the use cases which the standard must serve, and the standard's architecture in particular.It has also hinted at some of the work on "Haptic Codecs for the TI" for/within the IEEE 1918.1.1 standard and task group, including a detailing of different flavors and modes of operation of the IEEE 1918.1.1HCs.As further foundational information, this paper has discussed some of the fundamental aspects of the TI, including its nature and assumptions, as well as its differential factors compared with what is already out there in terms of standards and technologies.
It is intended for the 1918.1 and 1918.1.1 standards to be completed in early 2019 or perhaps shortly after, aiming to hit the market with pioneering TI applications at the time of, or before, the bulk of actual deployments of 5G networks-thereby taking advantage of the 5G capabilities such as URLLC therein.It is noted, however, that IEEE 1918.1 and its various standards activities will be communication system agnostic, not intended to run solely over 5G networks.Indeed, any communication network or combination of networks that satisfy the E2E performance requirements (e.g., latency, reliability, security, and availability) and required characteristics for a given TI use case could realize that use case using the IEEE 1918.1 standards as key aspects toward that.
As is covered through this paper, the IEEE 1918.1 WG provides the foundations for a family of standards on the topic of the TI, with IEEE 1918.1 acting as the baseline of those standards-although noting that some of the standards might be defined in a way that they might also operate in a stand-alone fashion, an example being IEEE 1918.1.1.To this end, there are various future topics and additional standards that might be developed in the WG toward the realization of the TI.Examples include AI capabilities and more detailed definition of computing support for the TI, and a radio interface particularly to serve the TI, among others.To these ends, any interested parties, manufacturers or other stakeholders that see themselves as having a TI/Haptics-related technology that should be standardized, or see a wider need for standardization of a particular aspect of TI, are invited to contact the Chair of IEEE 1918.1 (oliver.holland@ieee.org) to discuss the potential formulation of such a new standards project if it is deemed appropriate for the project to be taken forward.

Fig. 2 .
Fig. 2. TI standards WG and its baseline standard as a foundation for further TI standards.Note that all standards projects indicated are possible examples except for IEEE 1918.1 and IEEE 1918.1.1 which are already initiated and for which work is ongoing.

Fig. 6 .
Fig. 6.IEEE P1918.1 architecture with the GN and the NC residing as part of the tactile edge.

Fig. 7 .
Fig. 7. IEEE P1918.1 architecture with the GN and the NC residing as part of the network domain.

3 )Tab l e 2
Open (O) Interface: It provides connectivity between any architectural entity and the SE. 4) Service (S) Interface: It provides connectivity between the TSM and the GNC.The S interface carries control plane information only.5) Network Side (N) Interface: It refers to any interface providing internal connectivity between network domain entities.This is normally covered as part of the network domain standards and can include subinterfaces for both user plane and control plane entities.Contrasting the Operation and Architectural Requirements of the Three TI Communication Paradigms, Focusing on Resource Management, to Enable E2E TI Communication

Tab l e 3
Describing the Operational States of a General TI Device, With Respect to Initiating Communication With Another TI Device

Fig. 8 .
Fig. 8. FSM depicting the deterministic state transitions for a TD establishing, maintaining and terminating E2E communication withanother TI component.

Fig. 9 .
Fig. 9. ASN.1-based definitions of TI messages, exchanged between any two entities in the TI architecture.Evidently, some fields may be superfluous, depending on the interaction.Some fields are intentionally left as OPTIONAL, rendering them TI component specific.

Fig. 10 .
Fig. 10.Structure of the Haptic Codec for the TI Task Group activity.