Method to support emergency call through mesh network

Method to support emergency calls via mesh network

METHOD TO SUPPORT EMERGENCY CALL THROUGH MESH NETWORK

A typical wireless telecommunications network usually includes a base station, access point, node B, evolved node B or serves as one of control plane traffic and user plane traffic to and from the clients in the network Other central components of the controller and coordinator. On the other hand, a mesh network can be defined as a group of wireless telecommunication devices capable of communicating directly with each other (instead of communicating with or in addition to communicating with the central component). A mesh network usually includes a plurality of wireless devices, such as laptop computers, handheld computers, mobile phones or mobile phones, personal digital assistants, and similar devices. When these devices are used in a mesh network, they are referred to as mesh stations (MSTA). In some cases, one or more MSTAs in a mesh network can also serve as an entrance or an access point to another network. In other cases, the MSTAs in a mesh network form an independent network that is not connected to an entrance or an access point. In these cases, one of the MSTAs usually serves as a single MSTA. Details about mesh networks can be found in the WLAN standard revision document IEEE 802.11s Draft 3.0, the full text of which is incorporated herein by reference. Figure 1 illustrates a typical mesh network architecture based on IEEE 802.11s Draft 3.0. An MSTA can be matched to an access point or an entrance of other local networks. These MSTAs form a Mesh Basic Service Set (MBSS).

The embodiments of the present disclosure provide methods for managing emergency calls in a mesh network Methods and mechanisms. More specifically, an emergency indicator (EI) is used to indicate that an emergency call is being initiated or is in progress in a mesh network. As described in more detail below, for the purpose of prioritization, the EI can be used during the emergency call path establishment, during the emergency call authentication procedure, and/or in the data frame of the emergency call. As used herein, the term "emergency call" can refer to a voice call (such as a 911 call (in North America) or a 112 call (in most European countries)) or can include a public safety answering point (PSAP) One multimedia emergency call based on text and video messages handled (such as an NG911 (Next Generation 911)).

In the existing IEEE 80.11 WLAN specification, three emergency service indicators are designated to manage emergency calls. ESC (Emergency Service Capability) is a parameter used to indicate emergency service support. Only if the system currently supports emergency calls, set ESC to "1". The ESC is intended to be a system deployment category parameter. UESA (Accessible for Unauthenticated Emergency Services) is a parameter set to "1" if Unauthenticated Emergency Service Access is available. That is, in some locations, an authentication procedure must be followed before an emergency call is allowed to pass through a wireless network. If this authentication procedure is not required in a specific network, the UESA can be set to "1" for the network to indicate that the emergency calls can pass through the network without authentication.

In addition, when an emergency warning message reaches the IEEE 802.11 infrastructure, an access point announces the availability of the emergency warning message by including an emergency warning element of the message in its beacon and probe response frame. For each current emergency warning system message, the access point includes an instance of an emergency warning element in its beacon and detection response frame.

These emergency call handling procedures of traditional wireless networks may not be suitable for mesh networks because of the different characteristics of mesh networks. That is, a mesh network can be ad hoc and topologically dynamic in these MSTAs, can be moved apart from each other, can sleep in a power saving mode, can be turned off by the user, and so on. Therefore, it is impossible to maintain a consistent path for an emergency call in a current mesh network, and a mesh network may require Some specific actions are used to support emergency calls from MSTA.

In one embodiment, when an emergency call occurs in a mesh network, each MSTA in the mesh network knows when to initiate the emergency call and when the emergency call occurs (that is, when the MSTA and when Receiving and/or forwarding an emergency call payload). This ensures that each MSTA will properly handle the emergency call. For example, when resources are insufficient, an MSTA can load balance, prioritize, and/or abandon other calls to accommodate the emergency call; when the link metric drops below a certain threshold, the MSTA can Initially search for a new link in advance; when the MSTA is in the emergency call path, the MSTA does not enter a sleep mode or power saving mode; when the MSTA is available, the MSTA reports its location; when the MSTA is available When the emergency call is involved, the MSTA may accept an emergency call request from an unidentified neighboring MSTA and/or may warn the user not to turn off the MSTA.

In one embodiment, a new flag of the mesh operation is specified and the new flag is referred to as an emergency indicator (EI) flag. The EI may be a single bit or multiple bits indicating that a call is an emergency call. In countries or other jurisdictions where a single number (such as 911) can be used to contact multiple emergency services (such as the police, ambulance, or fire department), a single digit may satisfy the EI. In countries or other jurisdictions that use different numbers to contact different emergency services, multiple bits can be used for the EI. For example, if a user presses an emergency call button indicating "police", the EI can be set to "00", and the entrance can forward the emergency call to a local police station. If a user presses to indicate an emergency call in a hospital, the EI can be set to "01", and the entrance can forward the emergency call to a local hospital. Hereinafter, the EI will be referred to as a single bit.

When the EI is set to a first value (such as "1"), the EI indicates that it is starting (in the emergency call peer interconnection and path establishment action frame) or in progress (in the emergency call data frame) ) An emergency call. Some or all of the special mesh emergency actions mentioned above can then be implemented. When the EI is set to a second value (such as "0"), no emergency call is requested The data frame does not belong to an emergency call and does not perform special mesh emergency actions. Setting the EI equal to the first value herein may refer to including the EI, and setting the EI value equal to the second value herein may refer to not including the EI.

In one embodiment, when an MSTA initiates an emergency call, the MSTA sets the EI to "1". The MSTA then includes the EI in a frame that it sends to a neighboring MSTA capable of supporting an emergency call. When an MSTA acts as an intermediary for an emergency call, the MSTA receives the EI from a neighboring MSTA and then includes the EI in a frame that it sends to a neighboring MSTA capable of supporting an emergency call. In this document, an MSTA that initiates an emergency call or sends a frame related to the emergency call to another MSTA may be referred to as a source MSTA.

In one embodiment, the EI is included in the action frame during the mesh peer interconnection process, the action frame during the path establishment process, and the data frame carrying the emergency call payload. During the mesh peer interconnection procedure, if an unauthenticated emergency call is allowed, set an EI of "1" to allow an MSTA to perform mesh peer interconnection with a neighboring MSTA without undergoing an authentication procedure. even. During the path establishment procedure, the EI set to "1" informs the neighboring MSTAs in the emergency call path to find the best path to prioritize the resources used for the emergency call, and when the link condition deteriorates Before a certain threshold is lowered, a better path is found in advance and/or to change the behavior of some MSTAs (for example, disable power saving features). The EI set to "1" in the data frame allows the neighboring MSTA in the emergency call path to receive data from an unauthorized-level MSTA and forward the data to an unauthorized-level MSTA and only The data is directed to a PSAP in the portal to another network. Setting EI to one of "1" also indicates that the frame is eligible to have the highest possible quality of service (QoS).

In addition, as described in detail below, it is possible to modify the behavior of emergency indicators specified in 802.11, such as ESC and UESA, for an emergency call in a mesh network. It will provide information on the process of the same level interconnection process, the path establishment process, and the data transfer process. Details of the use of the EI and the modified behavior of the existing emergency indicator in the preface.

Before a request can be made for a path of a call through a mesh network, it may be necessary to establish a link between a pair of MSTAs in the mesh network. This link establishment procedure is called peering. As part of this peer-level interconnection process, a pair of MSTAs can exchange identification and security information to authenticate each other. In the current IEEE 802.11s draft, when an MSTA searches for a peer with a matching mesh ID, the MSTA starts a link establishment and authentication procedure with one of the peer MSTAs. If the authentication succeeds, the peer interconnection is established and the MSTA becomes a member of the mesh network to which the peer MSTA belongs.

In one embodiment, the emergency peer interconnection system is purely used for a special peer interconnection situation of emergency calls. In establishing a link for an emergency call, a source MSTA sets the EI to "1", and (as described below) sets the access type authorized to use the MSTA to the maximum value. If the UESA is set to "1" (no emergency call authentication), the authentication procedure can be skipped during emergency peer interconnection. That is, the peer interconnection does not require a matching mesh ID or any authentication procedure, and security information is ignored. If the UESA is set to "0" (authentication is required in an emergency call), the authentication is included during the emergency peer interconnection. The authentication emergency peer interconnection uses the same procedure as in the current IEEE 802.11s draft. Regardless of the UESA, during the mesh peer interconnection, an EI set to "1" activates a preset emergency call profile stored in an MSTA capable of supporting an emergency call.

In one embodiment, during the peer interconnection procedure, the EI allows an MSTA to perform mesh peer interconnection with a peer MSTA, regardless of whether the peer MSTA is in a state of accepting a new peer. This peer MSTA may need to give up one of its established peers.

In one embodiment, the EI is also used in the path establishment procedure of an emergency call through a mesh network. At least three different path establishment procedures are currently used in mesh networks: on demand mode, proactive tree building mode, and portal announcement mode. Each of these procedures will now be described The use of the EI in the person.

In the on-demand mode of path establishment, the source MSTA broadcasts a PREQ (path request) to its peer MSTA, and each peer MSTA further broadcasts the PREQ to its peer MSTA until the destination MSTA is contacted. Each intermediate MSTA in the path and the destination MSTA can receive several copies of PREQ, and each copy has a corresponding cumulative air link metric value that is a unique path (based on the air link value from the path in the path). Each traversed link is accumulated).

Each intermediate MSTA also stores each sender of the PREQ as a candidate for a forwarding node in the opposite path (from destination to source). The destination MSTA selects the PREQ with the best cumulative air link metric and then unicasts a unicast PREP ( Path response) sent to the source MSTA. Each intermediate MSTA receiving the PREP stores: the sender of the PREP as a node in the forwarding path (from source to destination); and a receiver of the PREP (one of the candidates for forwarding in the reverse path) As a node in the opposite path, other candidates are eliminated from its memory. When a timer expires, an intermediate MSTA that has never received the PREP will also remove the candidates forwarded in the opposite path from its memory. Once the path is established, the source MSTA sends a maintenance PREQ, and the destination responds with a PREP. Therefore, the source MSTA periodically seeks and updates the path with the best cumulative air metric value.

In an embodiment of the on-demand mode of path establishment, for emergency call support, the EI is added to a PREQ and the EI is set to "1". Each intermediate MSTA stores the EI for each path. If an intermediate MSTA cannot support the EI for some reason, the intermediate MSTA sends a PERR (path error) to the source MSTA that transmits the PREQ, so that the source MSTA can find another MSTA and forward the PREQ to The other MSTA. The PERR may include a reason code to indicate that an emergency call is not supported.

The EI can also be used as an indicator of how each MSTA in the selected emergency call path should behave. One instruction. For example, an EI set to "1" may indicate that an intermediate MSTA is not allowed to enter an 802.11s power saving mode and/or may indicate that the MSTA may set itself to a more active path discovery mode to degrade the current link To find a better link before being lower than a certain threshold called "EI_Threshold". This is an air link metric threshold for supporting emergency calls and preventing a specific link failure (even before the maintenance PREQ from the source MSTA arrives). Therefore, not only is the path discovery procedure triggered when the path to the destination is unknown or for periodic path maintenance, but also if the link metric drops below the EI_threshold value, a link is maintained. Once the exploration of the new path is completed, the new path immediately becomes the active path.

In one embodiment, during the on-demand path establishment procedure, the EI allows the MSTA to establish a path with the same-level MSTA, regardless of whether the same-level MSTA has sufficient resources to support emergency calls. The peer MSTA may need to abandon the call once established, even if the call has the highest QoS (for example, AC_VO as described below).

In the pre-active tree construction mode of path establishment, the root MSTA, mesh portal, or mesh access point broadcasts a pre-active PREQ or RANN (root announcement) to its peer MSTA, and the equivalent MSTA is further propagated to Its peers will not contact all MSTAs in the mesh network or the TTL (time to live) has reached its maximum value, which results in each MSTA knowing the path to the root. Similarly, each MSTA can receive multiple pre-active PREQ or RANN, where each pre-active PREQ or RANN traverses a unique path with a corresponding cumulative air link metric. If an MSTA needs to establish a path with the root (for example, has a session to start, data to be sent, etc.), the MSTA can use a pre-active PREP (if the MSTA receives a pre-active PREQ) or a PREQ (if the MSTA receives a RANN) response. The pre-action PREP or the PREQ respectively follow the path of the pre-action PREQ or the RANN. Since this is not a beacon or probe response, only the pre-activated PREQ and the RANN are propagated to each MSTA with the same level of interconnection as one of the senders.

In an embodiment of the pre-movement tree construction mode for path establishment, if the mesh enters If the port, mesh access point, or root MSTA supports emergency calls, it will propagate a "pre-action PREQ" message with the EI set to "1". The pre-active PREQ message is accompanied by a pre-active PREP bit set to "0" to allow the receiving MSTA to postpone sending the pre-active PREP until a two-way path to the root MSTA is required. Each MSTA along the path knows the capabilities of the path to the root MSTA (for example, to support emergency calls, VoIP, etc.). If an intermediate MSTA cannot support the same capabilities as in the incoming pre-active PREQ for some reasons, the intermediate MSTA sets the EI to "0" (becomes the weakest link) and has been propagated since then The pre-action type PREQ has the EI set to "0". That is, the pre-activated PREQ is propagated from the originator (mesh access point, mesh entrance, or root MSTA) on multiple links. Any MSTA that cannot support emergency calls can reset the EI from "1" to "0", and the path becomes unable to support emergency calls. Other paths that do not include these specific MSTAs can still support emergency calls (EI maintains "1") and the MSTA uses this path to initiate an emergency call. If there are multiple paths to the root MSTA with emergency call capability, the MSTA selects the path with the best cumulative air metric and/or the smallest number of hops. If an intermediate MSTA cannot support the same capabilities as in an incoming pre-active PREQ or RANN, the intermediate MSTA sends a PERR to the latest sender of the pre-active PREQ or PREQ so that the sender can find another One path.

For emergency calls, when an MSTA needs to establish a two-way path with the root, a pre-active PREP with the EI set to "1" (as a response to the pre-active PREQ) can follow the MSTA's request The path of the emergency call. In the RANN element, add the ESC and the UESA to the RANN element, and when an MSTA needs to establish a two-way path with the root MSTA that sends the RANN, the MSTA will have a PREQ of EI set to "1" A PREP sent to the originator of the RANN and received from the originator of the RANN with the EI also set to "1".

In the portal announcement mode of path establishment, an portal mesh can initiate or propagate a portal announcement (PANN). Especially PANN is used from one of the entrances connected to another network, and at the same time RANN is used by a root MSTA that does not need to be connected to another network. The portal mesh broadcasts a PANN to neighboring MSTAs in a beacon or in a Mesh Interworking action frame using a group of addresses, and these neighboring MSTAs will further propagate the PANN to their neighboring MSTAs until they contact All MSTAs or TTLs (time-to-live) in the mesh network have reached their maximum value, which causes each MSTA to know the path to the entrance. Similarly, each MSTA can receive multiple PANNs, where the PANN traverses a unique path, but a PANN does not have accumulated air link metric information. That is, a PANN allows the mesh portal to let all MSTAs know how to contact the mesh portal. When an active link is needed, an MSTA starts to a PREQ of the entry. This PREQ carries the cumulative air link metric. The current acceptance rule in IEEE 802.11s Draft 3.0 only indicates that if the PANN sequence number is lower than the previously received PANN, then an MSTA should not accept and process a PANN. Therefore, as long as the PANN sequence number is not lower than the previous receiver, each MSTA will maintain multiple PANNs.

In this embodiment, if the portal supports emergency calls, the portal sets ESC to "1" and adds the appropriate UESA to the PANN element.

In any of the three modes of path establishment, if the PSAP loses the MSTA that originated the emergency call, the PSAP can call the MSTA back. In order to provide a callback number for emergency call control requirements, the MSTA can send a suitable address or identifier in the emergency media establishment signaling message.

In one embodiment, the EI is also used to prioritize emergency calls. In a mesh network, different call types have different levels of service (CoS) access priority. The current scheduling priority in mesh networks has a mandatory EDCA (Enhanced Distributed Control Access) access priority and an optional MCCA (Mesh Coordinated Control Access) access priority to provide access to different types CoS of the access category. Access categories with decreasing priority are VoIP (AC_VO), video streaming (AC_VI), best effort (AC_BE), and background (AC_BK).

In one embodiment, in order to support emergency calls, when the EI is set to "1", an MSTA uses the highest available access priority level. When resources are not adequate for support When CoS is required for an emergency call, the MSTA can abandon other ongoing calls, including another AC_VO ongoing call.

After the emergency peer interconnection and path establishment procedures are completed and an emergency call is connected between a source MSTA and the peer MSTA, the peer MSTA verifies that it receives each data frame used for emergency calls. If a data frame does not have an EI set to "1", the data frame will not be forwarded. The mesh portal or root MSTA that supports emergency calls only forwards the data frames with EI set to "1" to the PSAP.

For the mesh data frame, the octet mesh flag in the mesh control field has four reserved bits (bits 4 to 7). In one embodiment, two of these bits (for example, bits 5 to 6) can be used to indicate the four access types (AC_VO, AC_VI, AC_BE, and AC_BK), and bit 7 (for example) can indicate The EI. If an access type is not specified and only emergency calls are supported, only bit 7 is used to indicate an emergency call data frame. Emergency peers only forward those data frames with the EI set to "1". The mesh portal or root MSTA only forwards the data frames with the EI set to "1" to the PSAP.

In one embodiment, the two existing IEEE 802.11 emergency call indicators (ESC and UESA) are still used, but their behavior can be modified. If a source MSTA cannot support the emergency call for some reason, the source MSTA can modify the ESC before propagating the ESC to the same-level MSTA. For example, the source MSTA may change the ESC from "1" to "0" to indicate that the emergency call is not supported on a path through the MSTA. However, a source MSTA does not change its emergency call support when an emergency call is in progress and passes through the MSTA. In a mesh network, both authenticated emergency call access and non-authenticated emergency call access are possible. Therefore, the UESA bit is propagated from MSTA to MSTA.

An MSTA that supports emergency calls announces the ESC bit and UESA bit originated from a mesh access point, mesh entrance, or root MSTA with similar support. In one embodiment, an MSTA that cannot support an emergency call changes these bits in its beacon or probe response from "1" to "0". During emergency call mesh peer interconnection and path establishment, one MSTA notifies that the ESC equal to "0" is not used in an emergency call path. Therefore, in a mesh network, the ESC bit and the UESA bit indicate a path through an emergency call to a PSAP.

If ESC and UESA are added as a parameter in a PANN or RANN element, any MSTA in the path that cannot support emergency calls will reset the ESC bit to "0" before propagating the PANN or RANN. If multiple paths support emergency calls, an MSTA selects the path with the least number of hops. In a new PANN with a higher PANN sequence number, the MSTA in the path changes its support for emergency calls based on the latest conditions before propagating the PANN to its neighboring MSTAs. Each MSTA updates the ESC bit accordingly.

<p>210Mesh base station</p><p>220Mesh entrance</p><p>230Public Safety Answering Point</p><p>240aMesh platform</p><p>240bMesh platform</p><p>250Emergency indicator</p><p>1300System</p><p>1310Processor</p><p>1320Network connection device</p><p>1325Transceiver assembly</p><p>1330Random access memory</p><p>1340Read Only Memory</p><p>1350Auxiliary Storage Device</p><p>1360Input/Output (I/O) Device</p><p>1370Bus</p><p>1380Digital Signal Processor</p>

Figure 1 illustrates a mesh network architecture according to the prior art.

Figure 2 illustrates a mesh network architecture according to an embodiment of the present disclosure.

FIG. 3 illustrates an embodiment of a call flow chart of an emergency call of an unauthenticated MSTA in a mesh network according to an embodiment of the present disclosure.

FIG. 4 illustrates an embodiment of a call flow chart of an authenticated MSTA, an emergency call, and a call in a mesh network according to an embodiment of the present disclosure.

FIG. 5 illustrates an embodiment of a flowchart of a path search for an emergency call in a mesh network according to an embodiment of the present disclosure.

Figure 6 illustrates a processor and related components of one of several embodiments suitable for implementing the present disclosure.

For a more complete understanding of one of the contents of the present disclosure, the following brief description and detailed description are now referred to in conjunction with the accompanying drawings, in which the same reference numerals denote the same parts.

At the outset, it should be understood that although the following provides an illustrative implementation of one or more embodiments of the present disclosure, many techniques (whether currently known or existing) can be used to implement the disclosed system and/or method. The content of this explanation should never be limited to those illustrated by the illustrations The implementations, drawings, and the techniques illustrated below (including the exemplary designs and implementations illustrated and described herein), but within the scope of the accompanying patent application and the full scope of their equivalents This disclosure can be modified.

A system that can implement one of these embodiments is illustrated in FIG. 2. In an MBSS 210 that can support emergency calls, a mesh portal 220 or mesh access point is connected to a PSAP 230. Alternatively, an MSTA (for an independent MBSS) is directly connected to the PSAP 230. In this example, MSTA 240a can initiate an emergency call, and can establish a path for the emergency call with MSTA 240b. Once the emergency call is initiated, the MSTA 240a sets the EI 250 to "1" in the mesh peer interconnection and path establishment element and passes the EI to the MSTA 240b. Then, MSTA 240b knows that the call is an emergency call. If the MSTA 240b can handle the emergency call, then whenever the MSTA 240b tries to connect to another MSTA for the purpose of establishing a path of the emergency call, the MSTA 240b sets the EI to "1". Then, a path for the emergency call through MSTA 240b is established, and any MSTA connected to MSTA 240b then knows that the call is an emergency call. If MSTA 240b cannot handle the emergency call, MSTA 240a has not established an emergency call path through MSTA 240b. MSTA 240b can send a PERR with an EI set to "0" to MSTA 240a to notify MSTA 240a will not establish a path for the emergency call through MSTA 240b.

FIG. 3 illustrates an embodiment of a call flow chart of an emergency call of an unauthenticated MSTA (with UESA set to "1") in a mesh network. At Event 310, a beacon message is sent from a partial MSTA to a source MSTA through one or more intermediate MSTAs. Set both ESC and UESA to "1", which indicates that the unidentified MSTA supports emergency calls. At event 320, the source MSTA sends a PeeringOpen message to a first MSTA and includes an EI set to "1". If the source MSTA is not authenticated, the first MSTA accepts the PeeringOpen message only when the EI system is set to "1". At event 330, the first MSTA will confirm the peer-to-peer interconnection (PeeringConfirm) The message is sent back to the source MSTA. At Event 340, a PREQ message including the EI set to "1" is sent from the source MSTA to the root MSTA through one or more intermediate MSTAs. At event 350, the root MSTA and a PSAP exchange session initiation protocol (SIP) messages. At Event 360, a PREP message including the EI set to "1" is sent from the root MSTA to the source MSTA through one or more intermediate MSTAs. At Event 370, a data frame containing the EI set to "1" is exchanged between the source MSTA and the PSAP through the root MSTA and one or more intermediate MSTAs.

FIG. 4 illustrates an embodiment of a call flow chart of an emergency call of an authenticated MSTA (with UESA set to "0") in a mesh network. At Event 410, a beacon message is sent from a partial MSTA to a source MSTA through one or more intermediate MSTAs. Set ESC to "1" and UESA to "0", which means that only the authenticated MSTA supports emergency calls. At event 420, the source MSTA sends a PeeringOpen message to a first MSTA and includes an EI set to "1" and its authentication certificate. At Event 430, the first MSTA sends a PeeringConfirm message back to the source MSTA. At Event 440, a PREQ message including the EI set to "1" is sent from the source MSTA to the root MSTA through one or more intermediate MSTAs. At event 450, the root MSTA exchanges SIP messages with a PSAP. At Event 460, a PREP message including the EI set to "1" is sent from the root MSTA to the source MSTA through one or more intermediate MSTAs. At Event 470, a data frame containing the EI set to "1" is exchanged between the source MSTA and the PSAP through the root MSTA and one or more intermediate MSTAs.

FIG. 5 illustrates an embodiment of a flowchart of a path search for an emergency call in a mesh network. At block 510, an MSTA initiates an emergency call. At block 520, the MSTA determines whether the ESC in any peer is equal to "1". As shown in block 590, if the ESC in any peer is not equal to "1", then an emergency call is not feasible. If it is set to "1" in at least the same level, the flow proceeds to block 530, where it is determined that there is Whether the UESA in one of the same ESCs set to "1" is equal to "0". At block 540, if the UESA in the peer is indeed equal to "0", then the mesh authentication certificate is exchanged. In block 540, if the UESA in the peer is not equal to "0" or after the mesh authentication certificate is exchanged, the process proceeds to block 550, where it is determined whether to receive a pre-action PREQ. If a pre-action type PREQ is received, a pre-action type PREP with an EI set to "1" is transmitted to the peer in block 570. If a pre-action type PREQ is not received, the PREQ with the EI set to "1" is transmitted to the peer, and the PREQ with the EI set to "1" is received from the peer. After receiving the PREP or transmitting the pre-active PREP in block 560 or block 570, respectively, the emergency call is initiated in block 580.

The components described above may include instructions capable of performing the actions described above. Figure 6 illustrates an example of a system 1300 that includes a processing component 1310 suitable for implementing one or more of the embodiments disclosed herein. In addition to including the processor 1310 (which may be referred to as a central processing unit or CPU), the system 1300 may also include a network connection device 1320, a random access memory (RAM) 1330, and a read-only memory (ROM) 1340, an auxiliary storage device 1350, and an input/output (I/O) device 1360. These components can communicate with each other via a bus 1370. In some cases, some of these components may not exist or may be combined with each other or with other components not shown in various combinations. These components can be located in a single physical entity or in more than one physical entity. The processor 1310 alone or by the processor 1310 in conjunction with one or more components shown or not shown in the drawings (such as a digital signal processor (DSP) 1380) can take any of the methods described herein as taken by the processor 1310 action. Although the DSP 1380 is shown as a separate component, the DSP 1380 can be incorporated into the processor 1310.

The processor 1310 executes instructions and program codes that can be accessed from the network connection device 1320, RAM 1330, ROM 1340, or auxiliary storage device 1350 (which may include a variety of disk-based systems (such as hard disk, floppy disk, or optical disk)) , Computer program or script. Although only one CPU is shown 1310, but there can be multiple processors. Thus, although it can be discussed that instructions are being executed by one processor, instructions can be executed by one or more processors simultaneously, consecutively, or in addition. The processor 1310 may be implemented as one or more CPU chips.

The network connection device 1320 can take the following forms: modem, data unit, Ethernet device, universal serial bus (USB) interface device, serial interface, symbol ring device, fiber distributed data interface (FDDI) ) Devices, wireless local area network (WLAN) devices, radio transceiver devices (such as code division multiple access (CDMA) devices, global system for mobile communications (GSM) devices, global interoperability for microwave access (WiMAX) devices), digital users Loop (xDSL) devices, Cable Data Service Interface Specification (DOCSIS) modems, and/or other well-known devices used to connect to the Internet. These network connection devices 1320 enable the processor 1310 to communicate with the Internet or one or more telecommunication networks or other networks. The processor 1310 can receive information from the network or the processor 1310 can output information To the network.

The network connection device 1320 may also include one or more transceiver components 1325 capable of wirelessly transmitting and/or receiving data (such as radio frequency signals or microwave frequency signals) by means of electromagnetic waves. Alternatively, the data can be propagated in or on the surface of an electrical conductor, in a coaxial cable, in a waveguide, in an optical medium (such as an optical fiber), or in another medium. The transceiver component 1325 may include separate receiving unit and transmission unit or a single transceiver. The information transmitted or received by the transceiver component 1325 may include data that has been processed by the processor 1310 or instructions to be executed by the processor 1310. This information can be received from a network or output to a network in the form of, for example, a computer data baseband signal or a signal embedded in a carrier wave. Since data may need to be processed or generated or transmitted or received, the data can be sorted according to different sequences. Fundamental frequency signals, signals embedded in a carrier wave, or other types of signals currently used or developed in the future can be referred to as transmission media or can be generated according to several methods well known to those skilled in the art.

The RAM 1330 can be used to store volatile data and possibly instructions to be executed by the processor 1310. The ROM 1340 usually has a memory capacity larger than that of the auxiliary storage device 1350. A non-volatile memory device with a smaller memory capacity. The ROM 1340 can be used to store the instructions and possible data read during the execution of the instructions. Access to both RAM 1330 and ROM 1340 is generally faster than the auxiliary storage device 1350. The auxiliary storage device 1350 is usually composed of one or more disk drives or tape drives and can be used for non-volatile storage of data or if the RAM 1330 is not large enough to store all working data, it is used as an overflow data storage device. When the programs loaded into the RAM 1330 are selected for execution, the auxiliary storage device 1350 can be used to store these programs.

I/O device 1360 can include liquid crystal display (LCD), touch screen display, keyboard, switch, dial, mouse, cursor, voice recognizer, card reader, paper tape reader, printer, video monitor Or other well-known input/output devices. Similarly, the transceiver 1325 can be regarded as a component of the I/O device 1360, instead of a component of the network connection device 1320 or in addition to a component of the network connection device 1320.

In one embodiment, a method for managing an emergency call in a mesh network is provided. The method includes an MSTA receiving an EI indicating that a call is an emergency call.

In another embodiment, an MSTA in a mesh network is provided. The MSTA includes a processor that is configured to cause the MSTA to receive an EI indicating that a call is an emergency call.

In another embodiment, an MSTA in a mesh network is provided. The MSTA includes a processor that is configured so that the MSTA will indicate that a call being initiated by the MSTA is an emergency call and an emergency call indicator is included in a message transmitted by the MSTA Box.

Although the present disclosure has provided several embodiments, it should be understood that the disclosed system and method can be implemented in many other specific ways without departing from the spirit or scope of the present disclosure. The current embodiments are considered to be illustrative and non-limiting, and are not intended to be limited to the details given herein. For example, various elements or components may be combined or integrated in another system, or certain features may be omitted or not implemented.

Likewise, without departing from the scope of the present invention, the technologies, systems, subsystems and methods described and illustrated in various embodiments as discrete or separate can be combined with other systems, modules, technologies or methods Or integration. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicate through some interface, device, or intermediate component (whether electrically, mechanically, or otherwise). Other examples of changes, substitutions, and alterations can be determined by those familiar with the technology, and these changes, substitutions, and alterations can be made without departing from the spirit and scope disclosed in this article.