WO2011087510A1 - Procédé d'assistance à un appel d'urgence au moyen d'un réseau maillé - Google Patents

Procédé d'assistance à un appel d'urgence au moyen d'un réseau maillé Download PDF

Info

Publication number
WO2011087510A1
WO2011087510A1 PCT/US2010/021222 US2010021222W WO2011087510A1 WO 2011087510 A1 WO2011087510 A1 WO 2011087510A1 US 2010021222 W US2010021222 W US 2010021222W WO 2011087510 A1 WO2011087510 A1 WO 2011087510A1
Authority
WO
WIPO (PCT)
Prior art keywords
msta
emergency call
peer
emergency
path
Prior art date
Application number
PCT/US2010/021222
Other languages
English (en)
Inventor
Rene Waraputra Purnadi
Stephen Mccann
Original Assignee
Research In Motion Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research In Motion Limited filed Critical Research In Motion Limited
Priority to PCT/US2010/021222 priority Critical patent/WO2011087510A1/fr
Publication of WO2011087510A1 publication Critical patent/WO2011087510A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/50Connection management for emergency connections

Definitions

  • a traditional wireless telecommunications network typically includes a base station, access point, node B, evolved node B, or other central component that acts as a controller and coordinator for control plane and user plane traffic to and from the clients in the network.
  • a mesh network can be defined as a group of wireless telecommunications devices capable of communicating directly with one another instead of or in addition to communicating with the central component.
  • a mesh network typically includes a plurality of wireless devices such as laptop computers, handheld computers, mobile phones or mobile handsets, personal digital assistants, and similar devices. When used in a mesh network, such devices are referred to as mesh stations (MSTAs). In some cases, one or more MSTAs in a mesh network may also act as a portal or an access point to another network.
  • the MSTAs in a mesh network form a stand-alone network that is not connected to a portal or an access point. In these cases, one of the MSTAs typically acts as a root MSTA. Details regarding mesh networks can be found in the WLAN standard amendment document IEEE 802.11s Draft 3.0, which is incorporated herein by reference as if included in its entirety.
  • Figure 1 illustrates a typical mesh network architecture according to IEEE 802.11s Draft 3.0.
  • An MSTA can collocate with an access point or with a portal to other local area networks. These MSTAs form a mesh basic service set (MBSS).
  • MBSS mesh basic service set
  • 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 disclosure.
  • Figure 3 illustrates an embodiment of a call flow diagram for an emergency call in a mesh network for an unauthenticated MSTA, according to an embodiment of the disclosure.
  • Figure 4 illustrates an embodiment of a call flow diagram for an emergency call in a mesh network for an authenticated MSTA, according to an embodiment of the disclosure.
  • Figure 5 illustrates an embodiment of a flow chart for path discovery for an emergency call in a mesh network, according to an embodiment of the disclosure.
  • Figure 6 illustrates a processor and related components suitable for implementing the several embodiments of the present disclosure.
  • Embodiments of the present disclosure provide methods and mechanisms for managing emergency calls in a mesh network. More specifically, an Emergency Indicator (El) is used to indicate that an emergency call is being initiated or is ongoing in a mesh network. As described in more detail below, the El can be used during path establishment for the emergency call, during the authentication process for the emergency call, and/or in the data frame of the emergency call for prioritization purposes.
  • El an Emergency Indicator
  • the term "emergency call” might refer to a voice call, such as a 911 call (in North America) or a 112 call (in most of Europe), or a multimedia emergency call, such as a NG911 (Next Generation 911) which includes text based and video messages, that might be handled by a Public Safety Answering Point (PSAP).
  • a voice call such as a 911 call (in North America) or a 112 call (in most of Europe)
  • NG911 Next Generation 911
  • PSAP Public Safety Answering Point
  • the ESC Error Service Capability
  • the UESA Unauthenticated Emergency Service Accessible
  • the UESA is a parameter that is 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 particular network, the UESA can be set to "1" for that network to indicate that emergency calls can pass through that network without authentication.
  • an access point advertises the availability of the emergency alert message by including an Emergency Alert element for that message in its Beacon and Probe response frames.
  • the access point includes one instance of an Emergency Alert element in its Beacon and Probe response frames for each active emergency alert system message.
  • each MSTA in the mesh network is made aware of when the emergency call is initiated and when the emergency call is occurring (that is, when the MSTA is receiving and/or forwarding an emergency call payload). This ensures that each MSTA will properly handle the emergency call.
  • an MSTA might load balance, prioritize, and/or drop other calls to accommodate the emergency call when resources are inadequate, might proactively search for a new link earlier when the link metric drops below a certain threshold, might not go to a sleep or power save mode when it is in the path of the emergency call, might report its location when it is available, might accept an emergency call request from an unauthenticated neighboring MSTA, and/or might warn the user not to turn the MSTA off when the MSTA is involved in the emergency call. 2
  • a new flag for mesh operation is specified and might be referred to as the Emergency Indication (El) flag.
  • the El might be a single bit or multiple bits that indicate that a call is an emergency call. In countries or other jurisdictions where a single number, such as 911 , can be used to reach multiple emergency services, such as police, ambulance, or fire services, a single bit may suffice for the El. In countries or other jurisdictions where different numbers are used to reach different emergency services, a plurality of bits may be used for the El. For example, if a user presses an emergency call button indicating "police”, the El might be set to "00", and the portal might forward the emergency call to a local police station. If a user presses an emergency call button indicating a hospital, the El might be set to "01", and the portal might forward the emergency call to a local hospital.
  • the El will be referred to as a single bit.
  • the El When the El is set to a first value such as "1”, the El indicates that an emergency call is initiating (in the emergency call peering and path establishment action frames) or is ongoing (in the emergency call data frames). Some or all of the special mesh emergency behavior mentioned above might then be implemented.
  • a second value such as "0”
  • no emergency call is requested, no data frame belongs to an emergency call, and no special mesh emergency behavior is performed. Setting the El equal to the first value might be referred to herein as including the El, and setting the El equal to the second value might be referred to herein as not including the El.
  • the MSTA when an MSTA initiates an emergency call, the MSTA sets the El to "1". The MSTA then includes the El in a frame it sends to a neighbor MSTA that is capable of supporting an emergency call. When an MSTA is acting as an intermediary to an emergency call, the MSTA receives the El from a neighbor MSTA and then includes the El in a frame it sends to a neighbor MSTA that is capable of supporting an emergency call.
  • An MSTA that initiates an emergency call or that sends emergency call-related frames to another MSTA might be referred to herein as a source MSTA.
  • the El is included in the action frame during the mesh peering procedure, in the action frame during the path establishment procedure, and in the data frame that carries the emergency call payload.
  • an El set to "1" allows an MSTA to engage in mesh peering with a neighbor MSTA without undergoing an authentication procedure, if an unauthenticated emergency call is allowed.
  • an El set to "1" informs the neighbor MSTA in the emergency call path to find the best path, to prioritize resources for the emergency call, to proactively find a better path before the link conditions deteriorate below a certain threshold, and/or to change some of the MSTA's behavior (for example, to disable the power save feature).
  • An El set to "1" in the data frame allows the neighboring MSTA in the emergency call path to receive data from an unauthenticated peer MSTA and forward the data to an unauthenticated peer MSTA and to direct the data only to a PSAP in the portal to another network.
  • An El set to "1" also indicates that the frame is entitled to have the highest quality of service (QoS) possible.
  • the behavior of the emergency indicators already specified in 802.11, such as the ESC and the UESA might be modified for an emergency call in a mesh network. Details will now be provided for the use of the El in the peering procedure, the path establishment procedure, and the data forwarding procedure, and for the modified behavior of the existing emergency indicators.
  • links may need to be established between pairs of MSTAs in the mesh network.
  • This link establishment procedure is known as peering.
  • a pair of MSTAs might exchange identity and security information in order to authenticate one another.
  • the MSTA starts a link establishment and authentication procedure with the peer MSTA. If the authentication is successful, peering is established and the MSTA becomes a member of the mesh network to which the peer MSTA belongs.
  • emergency peering is a special case of peering, purely for emergency calls.
  • a source MSTA sets the El to "1", and (as described below) the access category that the MSTA is authorized to use is set to the maximum. If the UESA is set to "1" (no authentication for emergency call), the authentication procedure can be skipped during emergency peering. That is, the peering 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 emergency call), authentication is included during emergency peering. The authenticated emergency peering uses the same procedures as in the current IEEE 802.11s draft. Regardless of the UESA, during mesh peering, an El set to "1 " activates a default emergency call profile stored in an MSTA that is capable of supporting an emergency call.
  • the El allows an MSTA to engage in mesh peering with a peer MSTA regardless of whether or not the peer MSTA is in a state of accepting a new peer.
  • the peer MSTA may need to drop one of its established peers.
  • the El is also used in the path establishment procedure for an emergency call through a mesh network.
  • At least three different path establishment procedures are currently used in mesh networks: the on demand mode, the proactive tree building mode, and the portal announcement mode. The use of the El in each of these procedures will now be described.
  • the source MSTA broadcasts a PREQ (Path Request) to its peer MSTAs, and each peer MSTA further broadcasts PREQ to their peer MSTAs until the destination MSTA is reached.
  • PREQ Policy Request
  • Each intermediate MSTA in the path and the destination MSTA may receive several PREQ copies and each copy traces a unique path with a corresponding cumulative air link metric value (accumulated from each traversed link in the path, based on the air link value).
  • Each intermediate MSTA also stores each sender of the PREQ as a candidate for a forwarding node in the reverse path (from destination to source).
  • the destination MSTA selects the PREQ with the best cumulative air link metric and then sends a unicast PREP (Path Reply) to the source MSTA by tracing back the unique path that has been followed by the PREQ with the corresponding cumulative air link metric.
  • Each intermediate MSTA that receives the PREP stores the sender of the PREP as a node in the forward path (from source to destination) and the receiver of the PREP (among the candidates for forwarding in the reverse path) as a node in the reverse path, eliminating the other candidates from its memory.
  • An intermediate MSTA that never receives the PREP will also eliminate these candidates forwarding in the reverse path from its memory when a timer expires.
  • the source MSTA sends a maintenance PREQ, and the destination responds with a PREP.
  • the source MSTA is periodically looking for and updating the path with the best cumulative air link metric value.
  • the El is added in a PREQ and is set to "1".
  • Each intermediate MSTA stores the El for each path.
  • the intermediate MSTA sends a PERR (Path Error) to the source MSTA that transmitted the PREQ so that the source MSTA can find another MSTA to which to forward the PREQ.
  • the PERR can include a reason code to indicate that an emergency call is not supported.
  • the El can also serve as an indication of how each MSTA in the selected emergency call path should behave. For example, an El set to "1" can indicate that an intermediate MSTA is not allowed to go into an 802.11s power save mode and/or can indicate that this MSTA may set itself to a more aggressive path discovery mode in order to find a better link before the current link deteriorates below a certain threshold called the "EI_threshold”. This is an air link metric threshold for supporting emergency calls and preventing a particular link from failing (even before the maintenance PREQ from the source MSTA arrives).
  • the path discovery procedure is not only triggered when the path to the destination is not known or for periodic path maintenance, but also to maintain a link if that link metric falls below the Eljhreshold. Once the new path discovery is completed, the new path immediately becomes the active path.
  • the El allows the MSTA to engage in path establishment with a peer MSTA regardless of whether the peer MSTA has enough resources to support the emergency call.
  • the peer MSTA may need to drop an established call, even if that call has the highest QoS (e.g., AC_VO, as described below).
  • the root MSTA, the mesh portal, or the mesh access point broadcasts a proactive PREQ or RANN (Root Announcement) to its peer MSTAs that they further propagate to their peer MSTAs until all MSTAs in the mesh network are reached or the TTL (Time To Live) has reached its maximum, resulting in each MSTA knowing the path to the root.
  • each MSTA may receive multiple proactive PREQ or RANN, where each proactive PREQ or RANN traverses a unique path with a corresponding cumulative air link metric.
  • the MSTA may respond with a proactive PREP (if the MSTA received a proactive PREQ) or a PREQ (if the MSTA received a RANN).
  • the proactive PREP or the PREQ follows the path of the proactive PREQ or the RANN, respectively, with the best cumulative air link metric. Since this is not a beacon or probe response, the proactive PREQ and RANN will be propagated only to each MSTA that has a peering with the sender.
  • the mesh portal, mesh access point or root MSTA if the mesh portal, mesh access point or root MSTA supports emergency calls, it propagates a 'Proactive PREQ' message with the El set to "1".
  • the Proactive PREQ message is accompanied by a Proactive PREP bit set to "0" to allow the receiving MSTA to postpone sending the Proactive PREP until a bidirectional path to the root MSTA is needed.
  • Each MSTA along the path knows the capability of the path to the root MSTA (e.g., to support emergency call, VoIP, etc.).
  • the intermediate MSTA sets the El to "0" (becomes the weakest link) and the propagated proactive PREQ has the El set to "0" from then on. That is, the Proactive PREQ is propagated from the originator (mesh access point, mesh portal or root MSTA) over multiple paths. Any MSTA that cannot support an emergency call resets the El from ⁇ " to "0", and the path becomes unable to support emergency calls. The other paths that do not include those particular MSTAs can still support emergency calls (El remains "1") and the MSTA uses this path to initiate an emergency call.
  • the MSTA selects the one with the best cumulative air link metric and/or the least number of hops. If an intermediate MSTA is unable to support the same capability as in an incoming proactive PREQ or RANN, the intermediate MSTA sends a PERR to the latest sender of the proactive PREP or PREQ so that the sender can find another path.
  • a proactive PREP (as a response to proactive PREQ) with the El set to "1" follows the path that is capable of supporting the emergency call that the MSTA requests.
  • the ESC and UESA are added to the RANN element, and when an MSTA needs to establish a bi-directional path with the root MSTA that sent the RANN, the MSTA sends a PREQ with El set to "1" to the originator of the RANN and receives a PREP with the El also set to "1" from the originator of the RANN.
  • a portal mesh can initiate or propagate a Portal Announcement (PANN).
  • PANN is particularly used by a portal connected to another network
  • RANN is used by a root MSTA that is not necessarily connected to another network.
  • the portal mesh broadcasts a PANN, in a beacon or Mesh Interworking action frame using a group address, to neighboring MSTAs that will further propagate the PANN to their neighboring MSTAs until all MSTAs in the mesh network are reached or the TTL (Time to Live) has reached its maximum, resulting in each MSTA knowing the path to the portal.
  • each MSTA may receive multiple PANNs, where each PANN traverses a unique path, but a PANN does not have cumulative air link metric information. That is, a PANN allows the mesh portal to let all MSTAs know how to reach it.
  • an MSTA When an active path is needed, an MSTA initiates a PREQ to the portal.
  • This PREQ carries the cumulative air link metric.
  • the portal responds with a PREP that also carries the cumulative air link metric.
  • the acceptance rules in the current IEEE 802.11s Draft 3.0 only indicate that an MSTA should not accept and process a PANN if the PANN sequence number is lower than the previously received PANN. Therefore, each MSTA will keep multiple PANNs as long as the PANN sequence number is not lower than the previously received one.
  • the portal sets ESC to "1 " and adds the appropriate UESA to the PANN element if the portal supports emergency calls.
  • the PSAP might call the MSTA back.
  • the MSTA might pass a suitable address or identifier in the emergency media set up signaling message.
  • the El is also used for prioritization of emergency calls.
  • Different call types have different Class of Service (CoS) access priorities in a mesh network.
  • the prioritization in the current mesh network has a mandatory EDCA ⁇ Enhanced Distributed Control Access) access priority and an optional MCCA (Mesh Coordination Control Access) access priority to provide CoS for different types of access category.
  • the access categories in order of decreasing priority, are VoIP (AC VO), video streaming (AC_VI), Best Effort (AC_BE), and background (AC BK).
  • an MSTA uses the highest available level of access priority. When resources are insufficient to accommodate the required CoS for supporting an emergency call, the MSTA may drop other ongoing calls, including another AC_VO ongoing call.
  • the peer MSTA After the emergency peering and path establishment procedures are complete and an emergency call is connected between a source MSTA and a peer MSTA, the peer MSTA verifies each data frame it receives for emergency call use. If a data frame does not have El set to "1", that data frame is not forwarded. The mesh portal or root MSTA that supports emergency calls forwards to the PSAP only those data frames with El set to "1".
  • the one octet Mesh Flags in the Mesh Control field have four reserved bits (bits 4 - 7).
  • bits 4 - 7 can be used to indicate the four access categories (AC_VO, AC_VI, AC BE and AC BK) and bit 7, for example, might indicate the El. If an access category is not specified and only emergency calling is supported, only bit 7 is used to indicate an emergency call data frame.
  • the emergency peer forwards only those data frames with the El set to "1 ".
  • the mesh portal or root MSTA forwards to the PSAP only those data frames with the El set to
  • the two existing IEEE 802.11 emergency call indicators, ESC and UESA are still utilized, but their behaviors may be modified.
  • a source MSTA may modify the ESC before propagating it to a peer MSTA if the source MSTA cannot support the emergency call for some reason. For example, the source MSTA may change the ESC from "1" to "0" to indicate that emergency calling will not be supported on a path through that MSTA.
  • a source MSTA does not change its support for emergency calling when an emergency call is ongoing through that MSTA. In a mesh network, both authenticated and unauthenticated emergency call access is possible. Therefore, the UESA bit is propagated from MSTA to MSTA.
  • An MSTA that supports emergency calls advertises the ESC and UESA bits originating from a mesh access point, mesh portal or root MSTA with similar support.
  • an MSTA that cannot support an emergency call changes these bits from "1 " to "0" in its beacon or probe response.
  • an MSTA that advertises that ESC equals "0" is not used in an emergency call path.
  • the ESC and UESA bits indicate a path for emergency calls through to a PSAP.
  • any MSTA in the path that cannot support emergency calls resets 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 may change 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.
  • FIG. 2 A system in which these embodiments might be implemented is illustrated in Figure 2.
  • a mesh portal 220 or mesh access point connects to a PSAP 230.
  • a root MSTA for a stand alone MBSS
  • MSTA 240a might initiate an emergency call, and a path for the emergency call might be established with MSTA 240b.
  • MSTA 240a sets the El 250 to "1" in the mesh peering and path establishment element and passes the El to MSTA 240b.
  • MSTA 240b then knows that the call is an emergency call.
  • MSTA 240b If MSTA 240b is capable of handling the emergency call, MSTA 240b sets the El to "1" whenever MSTA 240b attempts to connect to another MSTA for the purpose of establishing a path for the emergency call. A path for the emergency call is then established through MSTA 240b, and any MSTAs to which MSTA 240b connects then know that the call is an emergency call. If MSTA 240b is not capable of handling the emergency call, MSTA 240a does not establish an emergency call path through MSTA 240b. MSTA 240b might send a PERR to MSTA 240a with El set to "0" to inform MSTA 240a that a path for the emergency call is not to be established through MSTA 240b.
  • FIG. 3 illustrates an embodiment of a call flow diagram for an emergency call in a mesh network for an unauthenticated MSTA (UESA is set to "1").
  • beacon messages are sent from a root MSTA, through one or more intermediary MSTAs, to a source MSTA.
  • ESC and UESA are both set to "1", indicating that emergency calls are supported for unauthenticated MSTAs.
  • the source MSTA sends a PeeringOpen message to a first MSTA and includes an El set to "1". If the source MSTA is not authenticated, the first MSTA accepts the PeeringOpen message only when El is set to "1".
  • the first MSTA returns a PeeringConfirm message to the source MSTA.
  • PREQ messages that include the El set to "1" are sent from the source MSTA, through one or more intermediary MSTAs, to the root MSTA.
  • the root MSTA and a PSAP exchange Session Initiation Protocol (SIP) messages.
  • SIP Session Initiation Protocol
  • PREP messages that include the El set to "1” are sent from the root MSTA, through one or more intermediary MSTAs, to the source MSTA.
  • data frames that include the El set to "1" are exchanged between the source MSTA and the PSAP through the root MSTA and one or more intermediary MSTAs.
  • FIG. 4 illustrates an embodiment of a call flow diagram for an emergency call in a mesh network for an authenticated MSTA (UESA is set to "0").
  • beacon messages are sent from a root MSTA, through one or more intermediary MSTAs, to a source MSTA.
  • ESC is set to "1”
  • UESA is set to "0”
  • the source MSTA sends a PeeringOpen message to a first MSTA and includes an El set to "1 " and its authentication credentials.
  • the first MSTA returns a PeeringConfirm message to the source MSTA.
  • PREQ messages that include the El set to "1" are sent from the source MSTA, through one or more intermediary MSTAs, to the root MSTA.
  • the root MSTA and a PSAP exchange SIP messages.
  • PREP messages that include the El set to "1” are sent from the root MSTA, through one or more intermediary MSTAs, to the source MSTA.
  • data frames that include the El set to "1" are exchanged between the source MSTA and the PSAP through the root MSTA and one or more intermediary MSTAs.
  • FIG. 5 illustrates an embodiment of a flow chart for path discovery for an emergency call in a mesh network.
  • an MSTA initiates an emergency call.
  • the MSTA determines if ESC is equal to "1" in any peer. If ESC does not equal ⁇ " in any peer, an emergency call is not possible, as shown at block 590. If is set to "1" in at least one peer, the flow proceeds to block 530, where it is determined whether UESA is equal to "0" in a peer that had ESC set to "1". If UESA does equal "0" in the peer, then mesh authentication credentials are exchanged at block 540.
  • UESA does not equal "0" in the peer, or after mesh authentication credentials are exchanged at block 540, the flow proceeds to block 550, where it is determined whether a Proactive PREQ was received. If a Proactive PREQ was received, a Proactive PREP is transmitted to the peer at block 570 with El set to ⁇ ". If a Proactive PREQ was not received, a PREQ with El set to "1" is transmitted to the peer and a PREP with El set to "1 " is received from the peer at block 560. After either the PREP is received or the Proactive PREP is transmitted at either block 560 or block 570, respectively, the emergency call is initiated at block 580.
  • FIG. 6 illustrates an example of a system 1300 that includes a processing component 1310 suitable for implementing one or more embodiments disclosed herein.
  • the system 1300 might include network connectivity devices 1320, random access memory (RAM) 1330, read only memory (ROM) 1340, secondary storage 1350, and input/output (I/O) devices 1360.
  • RAM random access memory
  • ROM read only memory
  • secondary storage 1350 secondary storage
  • I/O input/output
  • These components might communicate with one another via a bus 1370. In some cases, some of these components may not be present or may be combined in various combinations with one another or with other components not shown.
  • DSP digital signal processor
  • the processor 1310 executes instructions, codes, computer programs, or scripts that it might access from the network connectivity devices 1320, RAM 1330, ROM 1340, or secondary storage 1350 (which might include various disk-based systems such as hard disk, floppy disk, or optical disk). While only one CPU 1310 is shown, multiple processors may be present. Thus, while instructions may be discussed as being executed by a processor, the instructions may be executed simultaneously, serially, or otherwise by one or multiple processors.
  • the processor 1310 may be implemented as one or more CPU chips.
  • the network connectivity devices 1320 may take the form of modems, modem banks, Ethernet devices, universal serial bus (USB) interface devices, serial interfaces, token ring devices, 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) radio transceiver devices, worldwide interoperability for microwave access (WiMAX) devices, digital subscriber line (xDSL) devices, data over cable service interface specification (DOCSIS) modems, and/or other well-known devices for connecting to networks.
  • These network connectivity devices 1320 may enable the processor 1310 to communicate with the Internet or one or more telecommunications networks or other networks from which the processor 1310 might receive information or to which the processor 1310 might output information.
  • the network connectivity devices 1320 might also include one or more transceiver components 1325 capable of transmitting and/or receiving data wirelessly in the form of electromagnetic waves, such as radio frequency signals or microwave frequency signals. Alternatively, the data may propagate in or on the surface of electrical conductors, in coaxial cables, in waveguides, in optical media such as optical fiber, or in other media.
  • the transceiver component 1325 might include separate receiving and transmitting units or a single transceiver. Information transmitted or received by the transceiver component 1325 may include data that has been processed by the processor 1310 or instructions that are to be executed by processor 1310.
  • Such information may be received from and outputted to a network in the form, for example, of a computer data baseband signal or signal embodied in a carrier wave.
  • the data may be ordered according to different sequences as may be desirable for either processing or generating the data or transmitting or receiving the data.
  • the baseband signal, the signal embedded in the carrier wave, or other types of signals currently used or hereafter developed may be referred to as the transmission medium and may be generated according to several methods well known to one skilled in the art.
  • the RAM 1330 might be used to store volatile data and perhaps to store instructions that are executed by the processor 1310.
  • the ROM 1340 is a non-volatile memory device that typically has a smaller memory capacity than the memory capacity of the secondary storage 1350. ROM 1340 might be used to store instructions and perhaps data that are read during execution of the instructions. Access to both RAM 1330 and ROM 1340 is typically faster than to secondary storage 1350.
  • the secondary storage 350 is typically comprised of one or more disk drives or tape drives and might be used for non-volatile storage of data or as an over-flow data storage device if RAM 1330 is not large enough to hold all working data. Secondary storage 1350 may be used to store programs that are loaded into RAM 1330 when such programs are selected for execution.
  • the I/O devices 1360 may include liquid crystal displays (LCDs), touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, printers, video monitors, or other well-known input/output devices.
  • the transceiver 1325 might be considered to be a component of the I/O devices 1360 instead of or in addition to being a component of the network connectivity devices 1320.
  • a method for managing an emergency call in a mesh network.
  • the method comprises an MSTA receiving an El indicating that a call is an emergency call.
  • an MSTA in a mesh network includes a processor configured such that the MSTA receives an El indicating that a call is an emergency call.
  • an MSTA in a mesh network includes a processor configured such that the MSTA includes in a frame transmitted by the MSTA an emergency indicator indicating that a call being initiated by the MSTA is an emergency call.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention porte sur un procédé de gestion d'un appel d'urgence dans un réseau maillé. Le procédé comprend une station maillée recevant un indicateur d'urgence indiquant qu'un appel est un appel d'urgence.
PCT/US2010/021222 2010-01-15 2010-01-15 Procédé d'assistance à un appel d'urgence au moyen d'un réseau maillé WO2011087510A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2010/021222 WO2011087510A1 (fr) 2010-01-15 2010-01-15 Procédé d'assistance à un appel d'urgence au moyen d'un réseau maillé

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2010/021222 WO2011087510A1 (fr) 2010-01-15 2010-01-15 Procédé d'assistance à un appel d'urgence au moyen d'un réseau maillé

Publications (1)

Publication Number Publication Date
WO2011087510A1 true WO2011087510A1 (fr) 2011-07-21

Family

ID=42562950

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2010/021222 WO2011087510A1 (fr) 2010-01-15 2010-01-15 Procédé d'assistance à un appel d'urgence au moyen d'un réseau maillé

Country Status (1)

Country Link
WO (1) WO2011087510A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014049911A (ja) * 2012-08-30 2014-03-17 Panasonic Corp 無線装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006108133A1 (fr) * 2005-04-04 2006-10-12 Qualcomm Incorporated Systeme et procede pour la formation de groupe de multidiffusion a base de localisation ponctuelle
US20080009262A1 (en) * 2006-05-12 2008-01-10 Interdigital Technology Corporation Method and apparatus for supporting an emergency call in a wireless metropolitan area network
WO2008027750A2 (fr) * 2006-08-29 2008-03-06 At & T Mobility Ii Llc Moyens de communication ad-hoc pour premiers répondants
US20080247366A1 (en) * 2006-09-26 2008-10-09 Ulrico Celentano Forced silencing of transmitting device
US20080309486A1 (en) * 2005-09-20 2008-12-18 Selflink Llc Self-configuring emergency event alarm system having connection to a public safety answering point
DE102008004176A1 (de) * 2008-01-11 2009-07-23 Annette Diefenthaler Informations- und Kommunikationssystem für den Katastrophenfall

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006108133A1 (fr) * 2005-04-04 2006-10-12 Qualcomm Incorporated Systeme et procede pour la formation de groupe de multidiffusion a base de localisation ponctuelle
US20080309486A1 (en) * 2005-09-20 2008-12-18 Selflink Llc Self-configuring emergency event alarm system having connection to a public safety answering point
US20080009262A1 (en) * 2006-05-12 2008-01-10 Interdigital Technology Corporation Method and apparatus for supporting an emergency call in a wireless metropolitan area network
WO2008027750A2 (fr) * 2006-08-29 2008-03-06 At & T Mobility Ii Llc Moyens de communication ad-hoc pour premiers répondants
US20080247366A1 (en) * 2006-09-26 2008-10-09 Ulrico Celentano Forced silencing of transmitting device
DE102008004176A1 (de) * 2008-01-11 2009-07-23 Annette Diefenthaler Informations- und Kommunikationssystem für den Katastrophenfall

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HIERTZ G R ET AL: "IEEE 802.11s: The WLAN Mesh Standard", IEEE WIRELESS COMMUNICATIONS, IEEE SERVICE CENTER, PISCATAWAY, NJ, US LNKD- DOI:10.1109/MWC.2010.5416357, vol. 17, no. 1, 1 February 2010 (2010-02-01), pages 104 - 111, XP011289808, ISSN: 1536-1284 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014049911A (ja) * 2012-08-30 2014-03-17 Panasonic Corp 無線装置

Similar Documents

Publication Publication Date Title
US9088883B2 (en) Method to support emergency call through mesh network
US9468032B2 (en) Inter-device session connectivity enhancement
JP5526236B2 (ja) 無線通信ネットワーク内でのピア発見のための方法および装置
JP6158198B2 (ja) 高速初期ネットワークリンクセットアップのためのシステムおよび方法
JP6147935B2 (ja) アクセスポイントとワイヤレスデバイスとの間のリンク確立に関するシグナリングメッセージを送信するときのオーバーヘッドを削減するための方法、アクセスポイント、およびワイヤレスデバイス
JP2016530841A (ja) メンバー局プロキシサービス通知を用いたマルチホップサービス発見のためのシステムおよび方法
JP6239636B2 (ja) ワイヤレス通信のレンジ拡大(rangeextension)のためのシステム、装置、および方法
JP6430252B2 (ja) 高速初期ネットワークリンクセットアップのためのシステムおよび方法
US8634327B2 (en) Method for switching channel in mesh network
JP2018524910A (ja) ネイバーアウェアネットワークデータリンク存在指示
JP2016541163A (ja) ワイヤレスデバイスのリレー動作を変更するためのシステム、方法およびデバイス
JP5858464B2 (ja) 無線通信装置、無線通信装置制御方法、無線通信装置制御プログラム、無線通信システム、無線通信システム制御方法、制御装置、制御装置制御方法、及び、制御装置制御プログラム
US20150365202A1 (en) Communication apparatus and communication method
JP7400121B2 (ja) プロトコルアーキテクチャ決定方法、装置及び機器
JP2008277919A (ja) 無線lanアクセスポイントおよび無線lan端末
WO2011087510A1 (fr) Procédé d'assistance à un appel d'urgence au moyen d'un réseau maillé
US10356676B2 (en) Resource switching method, apparatus, and system
US20160308600A1 (en) Base station apparatus, terminal apparatus, and wireless access system
US20230292098A1 (en) Sidelink device discovery

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10701081

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10701081

Country of ref document: EP

Kind code of ref document: A1