Method and device for communication between mission-critical (MCX) device and non-MCX devices

Abstract

Disclosed herein is a method (500) for communication between a mission-critical (MCX) device (224) and at least one non-MCX device (202). The method (500) includes transmitting (502), by the MCX device (224), a scan request comprising a scan ID to at least one non-MCX device (202). Further, the method (500) includes receiving (504), by the MCX device (224), an acceptance message comprising non-MCX device information and a preferred channel of communication from the at least one non-MCX device (202). Further, the method (500) includes establishing (506), by the MCX device (224), a communication channel with the at least one non-MCX device (202) using the preferred channel of communication. The method (500) includes transmitting (508), by the MCX device (224), MCX data to the at least one non-MCX device (202) using the established communication channel.

Description

METHOD AND DEVICE FOR COMMUNICATION BETWEEN MISSION-CRITICAL (MCX) DEVICE AND NON-MCX DEVICES

[0001] The present disclosure relates to mission-critical (MCX) devices, and more particularly, to a method and system for communication between MCX devices and non-MCX devices.

[0002] Mission-critical (MCX) services are essential for ensuring public safety, especially during emergency situations such as earthquakes, fires, or floods. In such situations, it becomes critical to coordinate rescue operations with effective communication between first responders and affected individuals. Conventionally, such communication is performed by standard voice or text-based alerts, which allows the first responder to provide guidance to the affected individuals. However, with the growing adoption of immersive technologies like Virtual See-Through (VST), Augmented Reality (AR), Virtual Reality (VR), and other Extended Reality (XR) technologies, new challenges have emerged. Users who get deeply engaged in virtual environments may become unaware of their surroundings, making it difficult for them to receive announcements or other notifications of emergencies.

[0003] Recent technological advancements in VST, AR, and XR devices have significantly improved user experiences by enabling immersive, real-time interactions across various fields, including entertainment, training, and remote collaboration. These devices allow users to fully engage in digital environments (for example, a metaverse), often leading to a disconnect from real-world events. Furthermore, the limitations of existing communication channels in reaching all users effectively can be problematic, as individuals in an affected area may be experiencing different types of emergencies. Hence, a personalized guide for different impacted users is required. Further, the users in affected locations such as shopping centers, office buildings, or apartments are usually connected to different service providers / operator networks via different devices such as a mobile phone, or a device with SIM provision such as a Tablet, or a VST device. This results in a situation where conventional techniques are unable to effectively and efficiently support all impacted users. Moreover, nearby user device information changes dynamically and is unavailable, as there is no common database that can provide specific area / floor-wise information about the affected users / devices. This further leads to ineffective communication with all the affected users / devices.

[0004] Currently, in a MCX architecture or framework, normal users, i.e., non MCX users, are not added to a MCX first responders (FR) group. The MCX FR group, in case of unfortunate tragic incidents, e.g., fire, earthquake, flood, etc. as illustrated in Figure 1B, may not be able to rescue the non-MCX users, as the MCX FR group is not able to discover devices of the non-MCX users immersed in the virtual environment. The communication between a discoverer and an advertiser is described in Figure 1A.

[0005] Figure 1A illustrates a sequence flowchart 100 depicting discovery of nearby devices between the advertiser and the discoverer, in accordance with a conventional technique. A device discovery process allows a client device, i.e., the non-MCX user devices, for example, a mobile, a tablet, a VST, or an application to discover wireless devices within a range / coverage area. The client devices play multiple roles during the discovery phase. For instance, a device is an advertiser where the device is responsible for announcing itself so that the neighboring devices can detect the device. In another instance, the device acts as a discoverer responsible for listening to the environment to detect potential advertisers. When two devices discover each other, the discoverer sends a connection request to the advertiser, which triggers a symmetric　authentication flow where both the devices independently accept or reject the connection request.　For discovery and data transfer short-range wireless communications may be used. The short-range wireless communications may include multiple known methods / technologies, a few of the widely used technologies are mentioned below and in Table 1.

[0006] Bluetooth: Range :10m [Max Bitrate 0.72Mbps]. Wi-Fi : Range :100m [ Max Bitrate 54Mbps]. ZigBee : Range :10-100m [ Max Bitrate 0.25Mbps]. Ultra-Wide band[UWB] : Range :10m [ Max Bitrate 110Mbps].

[0007] StandardZigBeeBluetoothWi-FiUWBIEEE standard802.15.4802.15.1802.11a / b / g802.15.3aFrequency band868 / 915 MHz, 2.4 GHz2.4 GHz2.4 GHz, 5 GHz3.1-10.6 GHzMax signal rate250Kb / s1Mb / s54Mb / s110Mb / sNormal range10-100m10m100m10m

[0008] Figure 1B illustrates an exemplary scenario 102 depicting communication between the MCX user / device and the non-MCX users / devices in case of a gas leak and a fire incident in an apartment or a mall, in accordance with a conventional technique. As depicted, a user AA and a user BB are on a third floor, and both are wearing VR / XR headsets and are immersed in virtual environments. A user CC is on a second floor wearing the VR / XR headset and giving a presentation in a virtual environment. A user DD is on a first floor and is walking and not wearing the VR / XR headset and a user EE is watching a movie on a display device without any immersive head mounted gear. In case of the fire incident, the users (DD and EE) identify fire but are unable to coordinate with the FRs or with fire-fighters because the users (DD and EE) are not aware of other nearby users and means to communicate with them. Further, the FRs may not be able to assist the users (DD and EE) together or individually due to lack of wireless communication between users (DD and EE) and the FRs. In case, if the user EE gets help from the FRs, he / she cannot assist the user DD as there is no communication between the user DD and the user EE.

[0009] Considering another scenario where the users AA, BB and CC immersed in the virtual environment wearing the VR / XR headsets and unaware of the fire incident at first, later identify may still not coordinate with FRs due to the reasons mentioned in case of the users DD and EE. In an instance, during foggy or smoky conditions and a lot of noise, when normal eyes cannot find a safe path or miss the important announcements, the FRs could have shared floor wise safe path details to the users AA, BB, and CC, and individually assist the users AA, BB, and CC virtually to reach the safe zone. However, this is currently not possible because a normal user cannot be added to a MCX FR Metaverse as the current MCX FR group is exclusive only for FRs, and the FRs communicate with each other in the MCX FR group, and the normal users are assisted by FRs by using mic / speaker. Also, nearby user device information which changes dynamically is not available as there is no common database available which gives specific area / floor wise effected user details. Therefore, the lack of synchronization among affected users immersed in the virtual world in emergency is a major concern that needs to be addressed.

[0010] Therefore, in view of the above-mentioned problems, it is advantageous to provide an improved system and method that can overcome the above-mentioned problems and limitations associated with the communication between MCX devices and non-MCX devices.

[0011] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the invention nor is it intended for determining the scope of the invention.

[0012] According to an embodiment of the present disclosure, a method for performed by a mission-critical (MCX) device (224) for communication with at least one non-MCX device is provided. The method may comprise transmitting a scan request. The method may comprise receiving an acceptance message comprising information about a preferred channel from the at least one non-MCX device, in response to the scan request. The method may comprise establishing a communication channel with the at least one non-MCX device based on the information about the preferred channel. The method may comprise transmitting MCX data to the at least one non-MCX device using the established communication channel.

[0013] The method may comprise updating a device table based on non-MCX device information included in the acceptance message. The MCX data may be tramnsmitted to the at least one non-MCX device (202) based on the updated device table.

[0014] The method may comprise receiving an update from the at least one MCX device upon establishing the communication channel, wherein the update comprises information about one or more other non-MCX devices connected with the at least one non-MCX device. The method may comprise updating the device table based on the received update.

[0015] The acceptance message may be received upon verification of the MCX device.

[0016] Transmitting the MCX data may comprise creating a multiverse in the vicinity of the at least one non-MCX device. Transmitting the MCX data may comprise transmitting the MCX data in the multiverse.

[0017] Transmitting the MCX data may comprise transmitting the MCX data based on non-MCX device information included in the acceptance message.

[0018] The acceptance meesage may comprise non-MCX device information including at least one of an internet protocol, IP, address of the at least one non-MCX device, a unique identification, ID, of the at least one non-MCX device, a location information of the non-MCX device, a connection type, or type of services supported by the at least one non-MCX device.

[0019] The MCX device may be a pre-authenticated device with a unique MCX authentication ID.

[0020] The MCX data may include at least one of a virtual route associated with a location of the at least one non-MCX device, a virtual map associated with the location of the at least one non-MCX device, a metaverse joining link, exit details associated with the location of the at least one non-MCX device, or assistance information.

[0021] Tthe scan request may includes a scan identifier (ID).

[0022] According to an embodiment of the present disclosure, a mission-critical (MCX) device for communication with at least one non-MCX device is provided. The MCX device may comprise memory storing instructions, and at least one processor. The instructions, when executed by the at least one processor, may cause the MCX device to transmit a scan request. The instructions, when executed by the at least one processor, may cause the MCX device to receive an acceptance message comprising information about a preferred channel from the at least one non-MCX device, in response to the scan request. The instructions, when executed by the at least one processor, may cause the MCX device to establish a communication channel with the at least one non-MCX device based on the information about the preferred channel. The instructions, when executed by the at least one processor, may cause the MCX device to transmit MCX data to the at least one non-MCX device using the established communication channel.

[0023] According to an embodiment of the present disclosure, a non-transitory computer readable storage medium storing instructions is provided. The instructions, when executed by at least one processor of a mission-critical (MCX) device, may cause the MCX device to transmit a scan request. The instructions, when executed by the at least one processor, may cause the MCX device to receive an acceptance message comprising information about a preferred channel from the at least one non-MCX device, in response to the scan request. The instructions, when executed by the at least one processor, may cause the MCX device to establish a communication channel with the at least one non-MCX device based on the information about the preferred channel. The instructions, when executed by the at least one processor, may cause the MCX device to transmit MCX data to the at least one non-MCX device using the established communication channel.

[0024] To further clarify the advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawing. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.

[0025] These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

[0026] Figure 1A illustrates a sequence flowchart depicting discovery of nearby devices between an advertiser and a discoverer, in accordance with a conventional technique;

[0027] Figure 1B illustrates an exemplary scenario depicting communication between a mission critical (MCX) device and a non-MCX device in case of gas leak and fire incident in an apartment or a mall, in accordance with a conventional technique;

[0028] Figure 2A illustrates a system environment depicting communication between an MCX device and one or more non-MCX devices, in accordance with an embodiment of the present disclosure;

[0029] Figure 2B illustrates a block diagram depicting communication between the MCX device and the one or more non-MCX devices, in accordance with an embodiment of the present disclosure;

[0030] Figure 3 illustrates an exemplary scenario depicting a communication flow between the MCX device and the one or more non-MCX devices, in accordance with an embodiment of the present disclosure;

[0031] Figure 4A and Figure 4B illustrate a sequence flow depicting identification and grouping of nearby devices, in accordance with an embodiment of the present disclosure; and

[0032] Figure 5 illustrates a flowchart depicting a method for communication between the MCX device and the one or more non-MCX devices, in accordance with an embodiment of the present disclosure; and

[0033] Figure 6 illustrates an exemplary scenario depicting communication among the MCX device and the one or more non-MCX devices, in accordance with an embodiment of the present disclosure.

[0034] Further, skilled artisans will appreciate those elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help and improve understanding of aspects of the present disclosure. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0035] It should be understood at the outset that although illustrative implementations of the embodiments of the present disclosure are illustrated below, the present invention may be implemented using any number of techniques, whether currently known or in existence. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0036] The term "some", "one or more embodiment", "one or more example embodiments", as used herein is defined as "one, or more than one, or all." Accordingly, the terms "one," "more than one," "more than one, but not all" or "all" would all fall under the definition of "some." The term "some embodiments" may refer to one embodiment, several embodiments, or to all embodiments. Accordingly, the term "some embodiments" is defined as meaning "one embodiment, or more than one embodiment, or all embodiments."

[0037] The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the spirit and scope of the claims or their equivalents.

[0038] More specifically, any terms used herein such as but not limited to "includes," "comprises", "has", "have", and grammatical variants thereof do not specify an exact limitation or restriction and certainly do not exclude the possible addition of one or more features or elements, unless otherwise stated, and must not be taken to exclude the possible removal of one or more of the listed features and elements, unless otherwise stated with the limiting language "must comprise" or "needs to include."

[0039] Whether or not a certain feature or element was limited to being used only once, either way, it may still be referred to as "one or more features", "one or more elements", "at least one feature" or "at least one element." Furthermore, the use of the terms "one or more" or "at least one" feature or element does not preclude there being none of that feature or element unless otherwise specified by limiting language such as "there needs to be one or more ..." or "one or more element is required."

[0040] The terms "A or B," "at least one of A or / and B," or "one or more of A or / and B" used in the various embodiments of the present disclosure include any and all combinations of words enumerated with it. For example, "A or B," "at least one of A and B," or "at least one of A or B" means (1) including at least one A, (2) including at least one B, or (3) including both at least one A and at least one B.

[0041] Although the terms such as "first" and "second" used in various embodiments of the present disclosure may modify various elements of various embodiments, these terms do not limit the corresponding elements. For example, these terms do not limit an order and / or importance of the corresponding elements. These terms may be used for the purpose of distinguishing one element from another element. For example, a first user device and a second user device all indicate user devices and may indicate different user devices. For example, a first element may be named a second element without departing from the scope of right of various embodiments of the present disclosure, and similarly, a second element may be named a first element.

[0042] The expression "configured to (or set to)" used in various embodiments of the present disclosure may be replaced with "suitable for," "having the capacity to," "designed to," "adapted to," "made to," or "capable of" according to the situation. The term "configured to (set to)" does not necessarily mean "specifically designed to" as hardware. Instead, the expression "apparatus configured to . . . " may mean that the apparatus is "capable of . . . " along with other devices or parts in a certain situation. For example, "a processor configured to (set to) perform A, B, and C" may be a dedicated processor, for example, an embedded processor, for performing a corresponding operation, or a generic-purpose processor, for example, a Central Processing Unit (CPU) or an application processor (AP), capable of performing a corresponding operation by executing one or more software programs stored in a memory device.

[0043] A term "module" used in the present document may imply a unit including, for example, one of hardware, software, and firmware or a combination of two or more of them. The "module" may be interchangeably used with a term such as a unit, a logic, a logical block, a component, a circuit, and the like. The "module" may be a minimum unit of an integrally constituted component or may be a part thereof. The "module" may be a minimum unit for performing one or more functions or may be a part thereof. The "module" may be mechanically or electrically implemented. For example, the "module" of the present disclosure may include at least one of an Application-Specific Integrated Circuit (ASIC) chip, a Field-Programmable Gate Arrays (FPGAs), and a programmable-logic device, which are known or will be developed, and which perform certain operations.

[0044] Unless otherwise defined, all terms, and especially any technical and / or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

[0045] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein.

[0046] As is traditional in the field, embodiments may be described and illustrated in terms of modules that carry out a described function or functions. These modules, which may be referred to herein as units or blocks or the like, or may include blocks or units, are physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware and software. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the invention. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the invention.

[0047] The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.

[0048] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings.

[0049] The objective of the present disclosure is to provide a method and a system to assist non Mission Critical (MCX) users immersed in Video See Through (VST) / Augmented Reality (AR) / Virtual Reality (VR) environment in emergency situations such as fire, flood, etc. The present disclosure further provides a virtual connected network of nearby devices / users to send an initial communication message. The information received in the initial communication message is used by a non MCX users to enter a MCX virtual environment and seek help from first responders.

[0050] For the sake of clarity, the first digit of a reference numeral of each component of the present disclosure is indicative of the Figure number, in which the corresponding component is shown. For example, reference numerals starting with digit "1" are shown at least in Figure 1. Similarly, reference numerals starting with digit "2" are shown at least in Figure 2.

[0051] Figure 2A illustrates a block diagram of a system 200 for communication between a mission-critical (MCX) device MCX device 224 and one or more non-MCX devices 202, in accordance with an embodiment of the present disclosure.

[0052] In an embodiment, the MCX device 224 may be referred to as a first responder (FR), for example a fire fighter, etc. In one embodiment, each of the one or more non MCX devices 202 may correspond to a user equipment (UE). The system 200 may be implemented over the MCX device 224 or over a remote server 222. The one or more non-MCX devices 202 may be communicatively coupled to the server 222 through a network 220. In an embodiment, the system 200 may include the MCX device 224 in communication with multiple nearby devices (for example, the non-MCX device 202 through the server 222. In an embodiment, the multiple nearby devices may correspond to one or more UEs located at various positions in the vicinity of the MCX device 224. For the sake of clarity, one of the multiple nearby devices, one or more non-MCX devices, or user devices, may correspond to the non-MCX device 202 and may be used throughout the detailed description.

[0053] The MCX device 224 may include a processor 204, a display 206, a memory, a communication interface 216, and input / output ports 218. The memory 208 may include an operating system 210, a database 212, and modules 214. In an embodiment, the system 200 may provide a solution for enhanced communication for identification and grouping of multiple nearby devices, for example, multiple non-MCX devices 202, by the MCX device 224. Further, the system 200 may facilitate communication between the MCX device 224 and an affected user, i.e., the non-MCX device 202, after grouping of the multiple nearby devices.

[0054] The system 200 may be configured to connect the multiple nearby devices, for example, the non-MCX device 202, to a MCX metaverse. The system 200 may be implemented over the MCX device 224 and the MCX device 224 may be configured to perform operations in different phases. At first, the MCX device 224 may perform a scanning operation to detect nearby users / devices, i.e., the non-MCX device 202, in need of assistance. In an embodiment, the MCX device 224 may utilize one or more scanning techniques having an enhanced signal strength and minimal interference. For example, the one or more scanning techniques may be Wi-Fi / Bluetooth / Zigbee / ultra-wide band (UWB).

[0055] Further, the MCX device 224 may be configured to identify and group the multiple nearby devices. The MCX device 224 may detect the non-MCX device 202 and the associated information. The information may include connection details for example, IP / Port, and supported service information, for example, Short Messaging Service (SMS), calling, or metaverse. Further, the MCX device 224 may determine whether the information may be supported from nearby devices, i.e., non-MCX device 202. The non-MCX device 202 may be added to a FR routing table. In an embodiment, the FR routing table may correspond to a database of the MCX device 224 that may be configured to store data related to the non-MCX device 202. The non-MCX device 202, which may be referred to as an identified device, may start scanning to find any new device that may not be yet been added to the routing table. The process of scanning and adding to the FR routing table may continue until the last device details are added to the FR routing table. Further, the identified connected device information may be propagated back to the server 222 which in turn may store information of the non-MCX devices 202.

[0056] Further, the MCX device 224 may be configured to initiate initial communication between the MCX device 224 and the non-MCX device 202. The MCX device 224 may be configured to create a virtual route or map for the multiple nearby devices after identifying the multiple nearby devices. Further, the MCX device 224 may create a temporary metaverse and then initiate emergency communication messages intended for all users using the multiple nearby devices. The emergency communication message may indicate that the plurality of nearby devices covered by the MCX device 224. The emergency communication message may be a simple SMS or some text or a barcode. In an embodiment, the emergency communication message may contain a MCX Metaverse joining link or a floor or area map with safe exit details or phone number / emergency contact details whom a user may call and get assistance.

[0057] Further, the MCX device 224 may be configured to indicate to the multiple nearby devices regarding joining the MCX Metaverse. The non-MCX device 202 may receive and process the emergency communication message. In one case, when the non-MCX device 202 may support the metaverse, then the non-MCX device 202 may use the joining link present in the received emergency communication message to join the MCX Metaverse. The MCX device 224 may be configured to guide the non-MCX device 202 joined to reach a safe exit path. In an embodiment, the non-MCX device 202 after reaching a safe location may be removed from the MCX Metaverse and access permission may be revoked. The communication between the MCX device 224 and the multiple nearby devices is described in further detail in later embodiments.

[0058] The processor 204 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and / or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 204 may be configured to fetch and execute computer-readable instructions and data stored in the memory 208 and / or the modules 214. At this time, the processor 204 may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, and an AI-dedicated processor such as a neural processing unit (NPU). The processor 204 may control the processing of input data in accordance with a predefined operating rule or artificial intelligence (AI) model stored in the non-volatile memory and the volatile memory, i.e., the memory 208. The predefined operating rule or artificial intelligence model is provided through training or learning. Further, the processor 204 may be operatively coupled to each of the memory, the I / O Interface. The processor 204 may be configured to process, execute, or perform a plurality of operations described herein.

[0059] The memory 208 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and / or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 208 is communicatively coupled with the processor to store processing instructions for completing the process. Further, the memory 208 may include the operating system 210 for performing one or more tasks of the system, as performed by an operating system 210 in a computing domain. The memory 208 is operable to store instructions executable by the processor 204.

[0060] As discussed, the MCX device 224 may include the processor 204, e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both. The processor 204 may be a component in a variety of systems. For example, the processor 204 may be part of a standard personal computer or a workstation. The processor 204 may be one or more general processors, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. The processor 204 may implement a software program, such as code generated manually (i.e., programmed).

[0061] As mentioned above, the MCX device 224 may include the memory 208, such as a memory 208 that can communicate via a bus. The memory 208 may include, but is not limited to, computer-readable storage media such as various types of volatile and non-volatile storage media, including, but not limited to, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, memory 208 includes a cache or random-access memory for the processor 204. In alternative examples, the memory 208 is separate from the processor 204, such as a cache memory of a processor, the system memory, or other memory. The memory 208 may be an external storage device or database for storing data. The memory 208 is operable to store instructions 206 executable by the processor 204. The functions, acts or tasks illustrated in the figures or described may be performed by the programmed processor 204 for executing the instructions 206 stored in the memory 208. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro-code and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like.

[0062] As shown, the MCX device 224 may or may not further include the display 206, such as a liquid crystal display (LCD), an organic light-emitting diode (OLED), a flat panel display, a solid-state display, a cathode ray tube (CRT), a projector, a printer or other now known or later developed display device for outputting determined information. The display 206 may act as an interface for the user to see the functioning of the processor 204, or specifically as an interface with the software stored in the memory 208.

[0063] The present invention contemplates a computer-readable medium that includes memory 208 having executable instructions responsive to a propagated signal so that a device connected to the network 220 can communicate voice, video, audio, images, or any other data over the network 220. Further, the instructions 208 may be transmitted or received over the network 220 via the communication interface 216 or the input / output ports 218. The communication interface 216 may be a part of the processor 204 or maybe a separate component. The communication interface 216 may be created in software or maybe a physical connection in hardware. The communication interface 216 may be configured to connect with the network 220, external media, the display 206, or any other components in MCX device 224, or combinations thereof. The connection with the network 220 may be a physical connection, such as a wired Ethernet connection or may be established wirelessly as discussed later. Likewise, the additional connections with other components of the MCX device 224 may be physical or may be established wirelessly.

[0064] The network 220 may include wired networks, wireless networks, Ethernet AVB networks, or combinations thereof. The wireless network may be a cellular telephone network, an 802.11, 802.16, 802.20, 802.1Q, or WiMax network. Further, the network 220 may be a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to, TCP / IP based networking protocols. The MCX device 224 may not be limited to operation with any particular standards and protocols. For example, standards for Internet and other packet-switched network transmissions (e.g., TCP / IP, UDP / IP, HTML, and HTTP) may be used.

[0065] The processor 204 may be configured to transmit a scan request comprising a scan ID to at least one non-MCX device. The non-MCX device 202 may be the non-MCX device 202 as discussed earlier, and the MCX device 224 may be configured to transmit the scan request and the scan request may be associated with the scan ID. In an embodiment, each of the MCX device and the non-MCX device 202 may be assigned with a device ID. The device ID is described further in conjunction with Figure 2B. Referring to Figure 2B, the MCX device 224 may be assigned with the device ID as 0001 and the user device A as 0002, user device B as 0003, user device C as 0004, user device D as 0005 and user device E as 0006. The communication between the MCX device 224 and the non-MCX device 202 is described further in conjunction with Figure 2B later.

[0066] Further, the processor 204 may be configured to receive an acceptance message comprising non-MCX device information and a preferred channel of communication from the non-MCX device 202. The processor 204 may be configured to receive the acceptance message upon verification of the MCX device. As discussed earlier, the non-MCX device information may include connection details (for example, IP / Port), and supported service information (for example, SMS, Calling or Metaverse). Further, the processor 204 may be configured to establish a communication channel with the non-MCX device 202 using the preferred channel of communication and transmit MCX data to the non-MCX device 202 using the established communication channel.

[0067] Further, the processor 204 may be configured to update a device table based on the received non-MCX device information and transmit the MCX data to the non-MCX device 202 based on the updated device table. For updating the device table, the processor 204 may receive an update from the MCX device 202 upon establishing the communication channel. The update comprises the non-MCX device information corresponding to one or more other non-MCX devices connected with the non-MCX device 202. The device table may be updated based on the received update. In an embodiment, the processor 204, in order to transmit the MCX data to the non-MCX device 202, may create a multiverse in the vicinity of the non-MCX device 202 and transmit the MCX data in the multiverse. The MCX data may be transmitted based on the non-MCX device information.

[0068] In an embodiment, the non-MCX device information includes at least one of an internet protocol (IP) address of the non-MCX device 202, a unique identification (ID) of the non-MCX device 202, a location information of the non-MCX device 202, a connection type, and type of services supported by the non-MCX device 202. The MCX device is a pre-authenticated device with a unique MCX authentication ID. The MCX data includes at least one of a virtual route associated with a location of the non-MCX device 202, a virtual map associated with the location of the non-MCX device 202, a metaverse joining link, exit details associated with the location of the non-MCX device 202, and assistance information. The preferred communication channel includes at least one of a Bluetooth, Wi-Fi, Zigbee, and Ultra-Wideband channel.

[0069] Figure 2B illustrates a block diagram depicting communication between the MCX device 224 and the non-MCX device 202, in accordance with an embodiment of the present disclosure.

[0070] As illustrated, the MCX device 224 may be in communication with the multiple nearby devices, e.g., user devices A-E. The emergency communication message sent from the MCX device 224 may contain the MCX metaverse joining link, or the floor / area map with the safe exit details. For example, the emergency communication message may be first received by the user device A and user device B. Further, the user device A sends the emergency communication message to the user device C and the user device C sends the emergency communication message to the user device E. Similarly, the user device B sends the emergency communication message to the user device D. In one embodiment, user devices A-D support Metaverse, except the user device E. In this case, the user devices A-D may use the metaverse joining link to join the MCX metaverse and user device E may use the map received in the emergency communication message and find the safe exit path. In an embodiment, the emergency communication message may a simple SMS, a text message, a barcode. In another embodiment, the emergency communication message may have an expiry timer, such that the message may be non-accessable after the expiry time.

[0071] As mentioned earlier, the MCX device 224 may be assigned with the device ID as 0001 and the user device A as 0002, user device B as 0003, user device C as 0004, user device D as 0005 and user device E as 0006. The MCX device 224 may transmit the scan request containing the scan ID. The scan ID may be unique for each scan request. In case, there are multiple MCX devices on different floors, the scan requests transmitted by each MCX device may be different.

[0072] Figure 3 illustrates an exemplary scenario 300 depicting communication between the MCX device 224 and the non-MCX device 202, in accordance with an embodiment of the present disclosure.

[0073] The architecture 300 may include a MCX application server (AS) 302 having connected to the MCX device, i.e., the MCX device 224. The MCX AS 302 may be in communication with the Metaverse AS 304, i.e., the MCX Metaverse as discussed earlier. Further, the MCX AS 302 may communicate with the multiple nearby devices, i.e., the non-MCX devices or the non-MCX device 202, through the MCX device 224. The non-MCX device 202 may be communicatively coupled to the Metaverse AS 304.

[0074] For example, a user with the non-MCX device 202may be in a nearby range of each other and may be virtually connected and after entering the MCX Metaverse 304 and a user may get assistance from the MCX device 224.

[0075] At step 306, the MCX device 224 enters emergency session and may start scanning to find the nearby devices, i.e., the non-MCX devices 202, who may need assistance.

[0076] At step 308, the MCX device 224 may fetch Metaverse context or session ID from the Metaverse AS 304 through MCX AS 302..

[0077] At step 310, information collected in Step 308 [Metaverse context, the session ID, or the joining link] send to the MCX device 224 from the MCX AS 302 .

[0078] At step 312, the MCX device 224 may be configured to detect or discover nearby devices and share the Metaverse context to the detected or discovered nearby devices, i.e., the non-MCX devices 202. Further, the detected devices, i.e., the non-MCX devices 202, may start scanning to find any new device that may not yet be added to the FR routing table. In an embodiment, the step 312 may continue until the last device details are added to the FR routing table.

[0079] As discussed earlier, the virtual route may be created from the MCX device 224 to all other devices, i.e., the non-MCX devices 202, after all devices may be identified. At step 314, the MCX device 224 may create the temporary metaverse and sends a joining link and procedure over message to the non-MCX devices 202. At step 316, the Metaverse AS 304 may provide guidance to the non-MCX devices 202. In one case, when the non-MCX device 202 supports Metaverse, the non-MCX device 202 may use the link to join the MCX Metaverse to receive guidance to reach the safe exit path.

[0080] Figure 4A and Figure 4B illustrate a sequence flow 400 depicting identification and grouping of the multiple nearby devices, i.e., the non-MCX devices 202, in accordance with an embodiment of the present disclosure.

[0081] In this environment, users A-D may be trapped in a specific area (for example, in a building), in case of an emergency (for example, fire in the building). The users A-D may correspond to the multiple nearby devices or the non-MCX devices 202 and for the sake of clarity, user A-user D may be used herein. In this environment, the MCX device 224 may be a scanning device, and the users A-D may be scanned devices, and during scanning of a nearby device, any user of the users A-D may become a parent device to scan another nearby device, which may be a child device.

[0082] At step 402, the MCX device 224 may reach designated locations or floors to help users with the non-MCX devices 202. In an exemplary embodiment, a fire fighter reaches a location, i.e., a building, where a fire accident took place, and 4 individuals (A, B, C, and D) are trapped inside the building.

[0083] At step 404, the MCX device 224 may start scanning for the nearby devices, i.e., the non-MCX devices 202. The MCX device 224 may transfer scan requests with unique scan ID initiated from the MCX device 224. In an embodiment, the unique scan ID may be required to avoid adding the same UE details more than once. For example, only user A is in the scanning range of the MCX device 224, therefore, the scanning request from the MCX device 224 may reach only the user A.

[0084] At step 406, the user A may accept the scanning request and location, and information may be transmitted to the MCX device 224. The FR routing table may be updated with the location and information of the user A. In an embodiment, the MCX device 224 may have a scan ID with a unique signature which the non-MCX device 202 may not have. The FR scan ID may be regulated by government / standards body. The scan ID may help the non-MCX device 202 to avoid responding to all scan requests and respond to only genuine requests from the MCX device 224 only. In one case, when the non-MCX device 202 does not recognize the unique scan request from the MCX device 224, then the non-MCX device 202 may be kept outside as the UE may not be capable to use the advance saving method.

[0085] In another case, when the non-MCX device 202 may recognize a unique scan request and the non-MCX device 202 may respond positively, when the non-MCX device 202 receives a request first time. The first time request may be decided based on unique scan ID. The first time request may be received from the MCX device 224 and specific device detail may be added to that particular the FR routing table. In an embodiment, the FR routing table may contain IP and listening port of the non-MCX device 202, unique ID of non-MCX device 202, distance / location information of the non-MCX device 202, connection type, for example, Wi-Fi / Bluetooth etc., and different services supported by the non-MCX device 202, for example, SMS, calling, metaverse etc.

[0086] The MCX device 224 may scan using all possible options, for example, Wi-Fi / Bluetooth / Zigbee / UWB, and may select which ever has good signal strength and less interference.

[0087] At step 408, the user A may automatically initiate scanning to find new users, e.g., user B -and user C in the range of the user A. In an embodiment, a newly identified normal user device, i.e., the non-MCX device 202 or the user A, may automatically initiate scanning, if supported by the non-MCX device 202 of the user A, for the nearby devices in a chained mode. In the scan request, the user A may use the same unique scan ID which the MCX device 224 used.

[0088] At step 410, the user B and user C may accept the scanning request from the user A and may share the location and device information to the user A which is added to user A routing table. The user A is a scanning device in this case.

[0089] In an embodiment, in a chainned fashon now user B and user C starts scanning for new nearby device , user D is in scanning range of user C and C is in scanning range of B, when a user-device, for example, user D, has not received any scan request earlier or the user D is not part of any nearby group. In this case, the user D may send a positive acknowledgement with device and location information to the scanning device so that the device and location information of the user D may be added to the scanning device routing table. For example, the user C routing table may be updated with the device and location information of the user D, as the user C is the nearby device to the user D and therefore, may act as the scanning device for the user D.

[0090] At step 412, the user B may initiate a scan request with the same unique scan ID as used by the user A and the MCX device 224, for scanning nearby device, for example, the user C.

[0091] At step 414, the user C responds with a rejection of the request to the user B. The rejection of the request may be due to previous acceptance of the request by the user C to the scan request from the user A. The user C checks the scan ID and rejects or ignores the scan request as the scan ID is the same as the previous one used by the user A and more previously by the MCX device 224.

[0092] In another case, when the scan ID is different, that means user C may be connected from two FRs. In this case, based on signal strength, the user C may be connected to the closest FR. Accordingly, the user C and the FR routing table may be updated.

[0093] At step 416, the user A may share the location and device information of the user B and the user C to the MCX device 224. The FR routing table may be updated with the device and location information of the user B and the user C.

[0094] At step 418, the user C may initiate a scan request with the same unique scan ID to the user D. At step 420, the user D may respond with acceptance and share the device and location information to the user C. In this case, the user C may act as the scanning device to scan the nearby device, i.e., the user D. Further, the user C routing table may be updated with the device and location information of the user D.

[0095] At step 422, the device and location information of the user D may be shared with the user A. The user A routing table may be updated with the device and location information of the user D. At step 424, the device and location information of the user D may be transmitted to the MCX device 224. The FR routing table may be updated with the device and location information of the user D.

[0096] In an embodiment, all devices, the MCX device 224 and the non-MCX device 202 may periodically scan and update routing tables in case a new device may be added or some device removed, i.e., moved out of range.

[0097] Figure 5 illustrates a flowchart depicting a method 500 for communication between the MCX device 224 and the non-MCX device 202, in accordance with an embodiment of the present disclosure.

[0098] At step 502, the method 500 may include transmitting, by the MCX device, i.e., the MCX device 224, the scan request comprising the scan ID to the non-MCX device 202.

[0099] At step 504, the method 500 may include receiving, by the MCX device, the acceptance message comprising the non-MCX device information and the preferred channel of communication from the non-MCX device 202.

[0100] At step 506, the method 500 may include establishing, by the MCX device, the communication channel with the non-MCX device 202 using the preferred channel of communication.

[0101] At step 508, the method 500 may include transmitting, by the MCX device, MCX data to the non-MCX device 202 using the established communication channel.

[0102] Figure 6 illustrates an exemplary scenario 600 depicting communication among the MCX device and the non-MCX device 202, in accordance with an embodiment of the present disclosure.

[0103] In an exemplary scenario, users AA, BB, CC, DD, EE are on the 4th floor of a building which is affected by a fire accident. The user AA and the user BB are both wearing VR / XR headsets and are enjoying gaming in a virtual environment. The user CC is wearing the VR / XR headset and giving presentations in the virtual environment. The user DD is walking and the user EE is watching movies on the 4thfloor, both the user DD and the user EE are not using any VR / AR / XR device.

[0104] The MCX device 224 has been assigned a job to assist the users AA, BB, CC, DD, EE on the 4thfloor and the users, i.e., the users AA, BB, CC immersed in the virtual environment, are not even aware about the fire incident. The MCX device 224 reaches the designated location, i.e., the 4thfloor and starts scanning to find nearby devices using all possible scanning options, like, Wi-Fi or Bluetooth or Zigbee or UWB, and finally selects which option has good signal strength and less interference.

[0105] The users AA and BB are in the scanning range of the FR. The FR transmits a request indicating the incident, i.e., the fire accident on the 4thfloor. Further, the user details, such as IP, port, supported service details are added to the FR routing table, after the acceptance of the request. The user CC in the scanning range of the user AA, and the user details of the user CC are stored in the user AA and further transmitted to the FR routing table. Similarly, the user DD is in the scanning range of the user BB, and the user details of the user DD are stored in the user BB and further transmitted to the FR routing table. Further, the user EE is in the scanning range of the user CC and the user details of the user EE are stored in the user CC and further transmitted to the FR routing table. The MCX device 224 may create a virtual path till the last identified node.

[0106] As the MCX device 224 receives all the user details, the MCX device 224 may either choose a hop-to-hop method or a broadcast method to share important information. In the hop-to-hop method, the information is forwarded to an immediate child or neighbour which internally forwards to their immediate child or neighbour, and this continues till the last user is covered. In the broadcast method, the MCX device 224 sends a single message which reaches all connected users at once.

[0107] As soon as the virtual path is created, the MCX device 224 sends the emergency message, which contains: FR creates a temporary metaverse and sends a joining link and procedure over the emergency message and floor or area map with safe exit details.

[0108] If the hop-to-hop method is selected, then the emergency message is first received by the users AA and BB. The user AA further sends the emergency message to the user CC, and CC sends the emergency message to the user EE, the user BB sends the emergency message to the user DD. In case, except the user EE, rest of all the users AA, BB, CC, and DD, support metaverse so the users AA, BB, CC, and DD may use the link to join MCX Metaverse, once the users AA, BB, CC, and DD join the metaverse session the users AA, BB, CC, and DD get help from the MCX device 224. Once the users AA, BB, CC, and DD reach a safe place, the users AA, BB, CC, and DD are removed from the temporary MCX Metaverse. The user E uses the map received in the emergency message and find the safe exit path.

[0109] The present disclosure offers a mechanism to assist or guide non-mission critical (MCX) users immersed in Video See Through (VST) / Augmented Reality (AR) / Virtual Reality (VR) service in emergency situations such as fire, flood etc, towards a safety exit. The present disclosure further provides a virtual connected network of nearby devices / users to send initial communication message. The information received in the message is used by non MCX User to enter Mission critical metaverse and get help from first responders. The mechanism proposed by the present disclosure may be implemented over new and existing extended reality devices, irrespective of networks to which these devices are connected.

[0110] Although specific units / modules have been illustrated in the figure and described above, it should be understood that the system may include other hardware modules or software modules or combinations as may be required for performing various functions.

[0111] The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. Various modifications and changes may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.

[0112] Those skilled in the art will appreciate that the operations described herein in the present disclosure may be carried out in other specific ways than those set forth herein without departing from essential characteristics of the present invention. The above-described embodiments are therefore to be construed in all aspects as illustrative and not restrictive. The scope of the invention should be determined by the appended claims, not by the above description, and all changes coming within the meaning of the appended claims are intended to be embraced therein.

[0113] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.

[0114] Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

[0115] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

Claims

1.A method performed by a mission-critical, MCX, device (224) for communication with at least one non-MCX device (202), the method comprising:transmitting (502) a scan request;receiving (504) an acceptance message comprising information about a preferred channel from the at least one non-MCX device (202), in response to the scan request;establishing (506) a communication channel with the at least one non-MCX device (202) based on the information about the preferred channel; andtransmitting (508) MCX data to the at least one non-MCX device (202) using the established communication channel.2.The method of claim 1, further comprising:updating a device table based on non-MCX device information included in the acceptance message,wherein the MCX data is tramnsmitted to the at least one non-MCX device (202) based on the updated device table.3.The method of claim 2, further comprising:receiving an update from the at least one MCX device upon establishing the communication channel, wherein the update comprises information about one or more other non-MCX devices connected with the at least one non-MCX device (202); andupdating the device table based on the received update.4.The method of claim 1, wherein the acceptance message is received upon verification of the MCX device (224).5.The method of claim 1, wherein transmitting the MCX data comprises:creating a multiverse in the vicinity of the at least one non-MCX device (202); andtransmitting the MCX data in the multiverse.6.The method of claim 1, wherein transmitting the MCX data comprises:transmitting the MCX data based on non-MCX device information included in the acceptance message.7.The method of claim 1, wherein the acceptance meesage comprises non-MCX device information including at least one of an internet protocol, IP, address of the at least one non-MCX device (202), a unique identification, ID, of the at least one non-MCX device (202), a location information of the non-MCX device, a connection type, or type of services supported by the at least one non-MCX device (202).8.The method of claim 1, wherein the MCX device (224) is a pre-authenticated device with a unique MCX authentication ID.9.The method of claim 1, wherein the MCX data includes at least one of a virtual route associated with a location of the at least one non-MCX device (202), a virtual map associated with the location of the at least one non-MCX device (202), a metaverse joining link, exit details associated with the location of the at least one non-MCX device (202), or assistance information.10.The method of claim 1, wherein the preferred channel includes at least one of a Bluetooth, Wi-Fi, Zigbee, or Ultra-Wideband channel.11.The method of claim 1, wherein the scan request includes a scan identifier, ID.12.A mission-critical, MCX, device (224) for communication with at least one non-MCX device (202), the MCX device comprising:memory (208) storing instructions; andat least one processor (204), wherein the instructions, when executed by the at least one processor (204), cause the MCX device (224) to:transmit a scan request,receive an acceptance message comprising information about a preferred channel from the at least one non-MCX device (202), in response to the scan request,establish a communication channel with the at least one non-MCX device (202) based on the information about the preferred channel, andtransmit MCX data to the at least one non-MCX device (202) using the established communication channel.13.The MCX device of claim 12, wherein the instructions, when executed by the at least one processor (204), cause the MCX device (224) further to be operated according to a method in one of claims 2 to 11.14.A non-transitory computer readable storage medium storing instructions which, when executed by at least one processor (204) of a mission-critical, MCX, device (224), cause the MCX device (224) to:transmit a scan request,receive an acceptance message comprising information about a preferred channel from the at least one non-MCX device (202), in response to the scan request,establish a communication channel with the at least one non-MCX device (202) based on the information about the preferred channel, andtransmit MCX data to the at least one non-MCX device (202) using the established communication channel.15.The non-transitory computer readable storage medium device of claim 14, wherein the instructions, when executed by the at least one processor (204), cause the MCX device (224) further to be operated according to a method in one of claims 2 to 11.

Images