Patent Application
20110037590
The present invention relates generally to the operation of mobile wireless networks, and more particularly to methods and systems for delivering emergency alerts as a broadcast service.
Wireless communication technologies have seen explosive growth over the past few years. This growth has been fueled by wireless services providing freedom of movement to the mobile public, and cutting the tether to hardwired communication systems. As a result of service enhancements, the popularity of wireless services is expected to continue to grow rapidly. A recent addition to wireless communication services has been the ability to broadcast television and other content to receiver devices. FLO broadcast services allow users to view TV programming, as well as receive mobile editions of news, entertainment, sports, business, and other programming, using their cell phone or other wireless receiver device configured to receive the mobile broadcast transmissions. The growth of multimedia broadcast services represents an attractive communication platform for delivering emergency alert messages to the public.
The various embodiments enable mobile multimedia receiver devices to receive emergency alert messages from forward link only broadcast networks. Alert messages may be organized in alert sessions identified by an alert session ID. An alert record information may be included in the overhead information symbol (OIS) channel including the session ID and information enabling a receiver device to obtain an alert data message from an alert session in the multicast logic channel (MLC). The alert record may also be included in the MLC as an embedded OIS in a first superframe. The alert record may include the number of alert data packets in the alert session so receiving devices can determine when they have received all data packets associated with a particular alert. By storing the alert session identifier in memory, receiving devices can ignore subsequent broadcasts of the same alert, thereby enabling them to conserve battery power.
The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the features of the invention.
The various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations.
The term “receiver device” is used herein to refer to any one or all of mobile media broadcast receivers, cellular telephones, personal data assistants (PDA's), palm-top computers, wireless electronic mail receivers (e.g., the Blackberry® and Treo® devices), multimedia Internet enabled cellular telephones (e.g., the Blackberry Storm®), Global Positioning System (GPS) receivers, wireless gaming controllers, personal television devices, receivers within vehicles (e.g., automobiles) and similar personal electronic devices which include a programmable processor and memory and FLO broadcast receiver circuitry for receiving and processing FLO broadcast transmissions such as MediaFLO® broadcasts.
The word “broadcast” is used herein to mean the transmission of data (information packets) so that it can be received by a large number of receiving devices simultaneously. Examples of a broadcast message are mobile television service broadcast signals, including content broadcasts (content flow) and overhead information broadcasts (overhead flow) such as metadata messages.
Mobile multimedia receiver devices are different from traditional television sets in that the receiver devices are portable. Consequently, receiver devices configured to receive FLO broadcast services must be self-contained and designed to operate for extended periods of time on battery power. The need to be battery powered presents unique challenges to FLO broadcast systems. FLO broadcast networks broadcast information in formats that enable receiver devices to selectively tune-in to receive desired content or to de-energize their broadcast receiver whenever the desired content is not being broadcast. To address this need, information about programs and content are broadcast in advance in an overhead flow so that receiver devices can determine just when to tune-in to receive a selected service within the content flow. As a result of this data transmission structure, mobile multimedia receiver devices typically activate their receiver circuitry for a small percentage of the time, thereby reducing the amount of power required to receive desired content.
FLO broadcast services, such as services provided by FLO broadcast networks, enable mobile receiver devices to be self-contained by broadcasting information about the programs and content that will be broadcast in the future. The information about upcoming programs is broadcast in a portion of broadcast transmissions dedicated to carrying overhead information, which is referred to herein as the “Overhead Information Symbol” channel or OIS channel. Programs and content are carried in the data channel which is referred to herein as the “Multicast Logic Channel” or MLC channel. In operation, receiver devices use information carried in the OIS channel about the content to be broadcast in the MLC channel to discover how and when to receive selected content. Information in the OIS channel informs receiver devices about the location within the MLC channel that particular content can be obtained, as well as its transmission characteristics. More information regarding the structure of the OIS and MLC channels is provided below with reference to
The various embodiments enable the transmission of emergency alert messages in an emergency alert service flow by a Forward Link Only (FLO) multimedia broadcast network for reception and prompt processing by receiver devices. The embodiments may be implemented in any broadcast network using both a content channel and an overhead channel, but are particularly applicable to a FLO broadcast network as defined in the Telecommunications Industry Association specifications TIA-1120 and TIA-1099, which are both hereby incorporated by reference in their entirety.
In the various embodiments, an alert message received from a governmental alert gateway, or other source of alerts, may be used to generate alert data that may be transmitted within a stream of the MLC channel and alert message acquisition information which will be transmitted in the OIS channel. Transmitting the alert message acquisition information in the OIS channel ensures that any receiver device accessing the OIS channel will immediately receive the alert message data included in the MLC channel. To ensure reception occurs within two superframes of broadcast transmissions, alert message acquisition information may also be included within content in the MLC channel in a first superframe, so that receiver devices monitoring content in the MLC channel will be informed that the next superframe will include alert message data. The alert message acquisition information within the OIS channel indicates the physical channel on which the receiver device can acquire the alert stream within the MLC channel and the transmission characteristics of the physical channel carrying messages. To enable receiver devices to conserve battery power by avoiding the need to monitor alert messages that have already been received, alert messages may be identified with an alert session ID which may be included in the alert message acquisition information in the OIS channel. To facilitate acquisition of the entire alert message, the alert message acquisition information in the OIS channel may indicate the number of alert messages within a particular alert session (i.e., associated with a particular alert session ID). Using the session ID and alert message number information in the alert message acquisition information, a receiver device can determine whether it has already received a particular alert message, and thus activate its radio receiver only when necessary to receive a new alert message. To more efficiently utilize broadcast bandwidth, the various embodiments may enable multiplexing alert messages with other data streams within the MLC channel.
The various embodiments enable receiver devices to efficiently receive emergency alert messages by monitoring the emergency alert service flow. Alert messages may be received from an external alert gateway that is part of the FLO broadcast network using standard alert ingress interfaces, such as CMAS-C and NCMEC Amber Alert. A wide variety of alert messages may be handled by the system, including earthquake warnings, tsunami warnings, severe weather alerts, flash flood alerts, evacuation alerts, terror event warnings, pollution alerts and general public advisories. The alert messages may be received via an emergency alert service application layer in an alert server within a broadcast system. The alert server may indicate the FLO broadcast network components that will broadcast the alert messages for the requested duration at an appropriate quality of service (QoS) through deployment specific interfaces. Alert messages may be processed in an alert session layer in the alert server which prefixes emergency alert service session headers to alert messages to generate alert session packets that are provided to the transport layer of the FLO broadcast network. Alert session packets may be fragmented by the transport layer into transport layer frames which are delivered to the physical layer for broadcast. The physical layer broadcasts the transport layer frames as physical layer packets.
In the various embodiments the alert message data may be transmitted in an alert session layer as an alert session. An alert session may include a set of alert messages, which may include alerts specific to particular geographic regions. Since a mobile multi-media broadcast system may generate broadcast signals in a multiplex signal generated in a headband facility at a central location, different alert sessions may be generated for each regional or local broadcast content. For example, there may be an emergency alert service session for a West Coast broadcast area and an East Coast broadcast area. There also may be an emergency alert service session for each local broadcast area, such as an emergency alert service session for San Diego and a different emergency alert service session for New York City. Regional and local OIS channel flows may provide information for the alert sessions in each location. An alert may also be received at a local broadcaster and inserted as an alert session into a local broadcast content, such as by an alert server within the local broadcast network.
The alert session layer at the head end facility or in a local broadcast network may provide the alert message delivery function to an application layer of the system. For example, the alert session layer may direct the application layer to start delivering alert messages in a particular region at a particular repetition rate, and terminate such messages at the appropriate time. The alert message session layer may also modify alert messages handled by the emergency alert system application layer by issuing commands to stop an earlier alert message and to start a new message, for example. Similarly, an alert message cancellation may be achieved by the application layer by the alert session layer issuing a stop command related to the earlier alert message and a start command related to a new alert message, for example.
An alert session layer within the receiver device may receive multiple copies of alert messages which may be processed in an emergency alert system application layer operating within the receiver device software. The emergency alert system application layer within the receiver device may be responsible for detecting duplicate alert messages to avoid generating multiple alerts for users as well as conserve battery power.
Example components of a typical FLO broadcast system 1 are illustrated in
In addition to the normal content delivery system, the FLO broadcast network 1 may also include an alert server 5 for connecting to an alert gateway 9. In a typical implementation, the alert gateway 9 may be one or more servers operated by a government agency or other entity under contract to the government to delivery emergency alert messages, such as emergency broadcast alerts, Amber Alerts, etc. A form of alert gateway 9 already exists to deliver emergency messages to radio and television stations for broadcast to the public. The alert server 5 may be a commercially available server configured with software according to the embodiments to receive emergency alert notifications from the alert gateway 9 and to configure the information for broadcast via the FLO broadcast network 1, as described herein. The alert server 5 may connect to the alert gateway 9 via the Internet and/or another network (e.g., the Emergency Broadcasting System) similar to how other types of broadcast systems couple to the alert gateway 9.
Referring to
Receiver devices which are not actively accessing a particular session or content will monitor the OIS channel 32 to receive information about the content being broadcast or that will be broadcast in the future. Receiver devices that are battery-powered typically monitor the OIS channel 32 periodically, such as once every 5 seconds, so that the receiver can be turned off for the majority of the time when the device is not actively receiving a particular service. Receiver devices that are not battery-power limited, such as receivers within automobiles, may monitor the OIS channel 32 at all times. Receiver devices that are receiving a service data flow (i.e., a particular program or content feed carried within the MLC channel) need not receive the OIS channel 32, since the receiver can get the OIS information from the embedded OIS information in the MLC channel it is receiving to obtain the service data flow.
In view of this typical operational pattern of FLO broadcast networks, various embodiments may place information about alert messages within the OIS channel 32 and within the MLC channel (38a, 38b, 38c) as illustrated in
An example of the data fields that may be added to the OIS channel to carry the alert message acquisition information is illustrated in Table 1 below.
The example data structure for the alert message acquisition information illustrated in Table 1 illustrates how a single bit, namely the AlertSessionActive field, can be used to indicate whether there are alert messages being transmitted. For example, if a ‘1’ appears in the AlertSessionActive field, the OIS may include the additional listed information including, e.g., the alert session ID, the number of alert message packets within the alert session, the MLC ID, information regarding the message transmission characteristics needed to be able to receive the alert messages, and the Stream identifier which indicates the stream within the MLC where the alert packets can be found.
An example packet definition for an alert service session packet is illustrated in the following XML definition:
In this example data structure, the packet type (PacketType) may be an eight bit value which may be set equal to zero. The SessionID field may be a 32-bit identifier for every alert session that uniquely identifies the combined set of alert messages of the session. The head end will not reuse session IDs across the significant period of time. (Note that even if a session is created every second the 32-bit session ID length can provide enough unique identifiers for 136 years.) The packet ID may be a unique identifier which identifies a particular alert packet within an alert session. The packet ID may have values from 0 to 1 less than the number of alert packets, and can be used by the receiver device to place received packets in order and confirm that all alert packets have been received. As noted above, the number of alert packets may be sent in the OIS so the receiving device knows how many alert packets to receive. The head end need not assign the same packet ID to the same alert message across two different sessions. The AlertType may be a unique identifier identifying the type of emergency alert associated with the message (e.g., weather, earthquake, tsunami, Amber, etc.) and may be used to identify an appropriate alert application that the receiving device can use to receive and display the alert message. The alert type value may also be used to filter alerts so that only those relevant to the particular user are displayed, as described more fully below with reference to
In order to minimize the time delay from the activation of an alert to reception by receiver devices, the various embodiments enable reception of an alert message within two superframes following the initial processing of alert information from an alert gateway. In a first embodiment illustrated in
If the session ID is stored in memory (i.e., determination step 84=“Yes”), the receiving device has already received and processed the alert messages associated with the alert session ID, and thus there is no need to receive the same alert message packets, so the receiving device can continue with normal processing, step 83. However, if the receiving device determines that the received alert session ID is not stored in memory (i.e., determination step 84=“No”), this indicates that a new alert message is being received, in which case the receiving device may activate its receiver, if necessary, to receive and decode the MLC stream carrying the alert message data, step 85. The receiving device continues receiving the alert data until it collects all of the alert data packets for all of the alerts identified within the alert session, step 86. This process may extend beyond one superframe if the alert data is expansive or if there are several alert messages included in the same alert session.
Once all of the alert data packets for a particular alert message have been assembled, the receiving device may activate an appropriate alert application to display the relevant data to the user, step 87. Different applications may be used to process and display different types of alert messages, such as to provide different types of display graphics or enable user responses as may be appropriate for particular types of alerts. For example, due to the urgency and geographically limited nature of a tsunami, a tsunami warning alert may activate an application which can check the location of the receiver device to determine if it is in a threat area and, if so, activate a loud and vibrating alarm along with the display of evacuation directions. On the other hand, an air pollution alert, for which there is no real urgency, may activate a display that indicates the predicted hazard level without generating an audible warning. The receiver device may determine the appropriate alert application to invoke by using the alert type data included within the alert message data header. It is envisioned that application developers may coordinate with the authorities that issue alert warnings to agree upon a standard set of alert types that can be associated with alert applications and display/warning sounds which may be included in the software receiver devices.
Once the appropriate alert application has been activated in step 87, that application may be responsible for generating the appropriate displays, vibrations and sounds, as well as interacting with the user, such as, e.g., to receive an acknowledgment of the warning. Since there may be no need to receive the same alert message a second time, the receiving device may store the session ID of the particular alert session in memory, step 88. At this point, the receiver device may return to normal processing including receiving the next superframe to access the OIS or continue receiving a service flow in an MLC channel.
Since many alert messages will be relevant to only limited geographic areas, such as earthquake, tornado, tsunami or wildfire alerts, the receiver device may be configured to location information to identify relevant alert messages and to ignore irrelevant messages.
Since many alert messages will be of little importance to some individuals, receiver devices may also be configured to filter alert messages for their relevance based on the type of alert being issued. For example, a user who has no respiratory ailments may have no interest in receiving air pollution alert messages.
Referring to the right-hand side of
Typical receiver devices 10 suitable for use with the various embodiments will have in common the components illustrated in
The processor 131 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described herein. In some receiver devices, multiple processors 131 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory 132 before they are accessed and loaded into the processor 131. In some receiver devices, the processor 131 may include internal memory sufficient to store the application software instructions. In some receiver devices, the secure memory may be in a separate memory chip coupled to the processor 131. The internal memory 132 may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to all memory accessible by the processor 131, including internal memory 132, removable memory plugged into the device, and memory within the processor 131 itself.
A number of the embodiments described above may also be implemented with any of a variety of commercially available remote server devices, such as the server 5 illustrated in
The server processor 141 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described herein. Typically, software applications may be stored in the internal memory 142, 143 before they are accessed and loaded into the processor 141. The internal memory 142, 143 may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to all memory accessible by the server processor 141, including internal memory 142, 143, remote memory and disc drives accessible by the server, removable memory plugged into the server, and memory within the processor 141 itself.
The foregoing embodiments provide an efficient and prompt mechanism for delivering alert messages to FLO broadcast network receivers that enable battery-operated receivers to process alerts without draining their battery. By providing the alert record in the OIS channel and using the embedded OIS option receiver devices can be informed of the presence of an alert message within two superframes after the system latency. The alert record in the OIS channel indicates the physical channel that the receiving device can use to acquire the alert data from the MLC stream, as well as the transmission characteristics of the corresponding physical channel. By providing alert messages in alert sessions identified by an alert session ID and indicating a number of alert data packets as well as number of alerts within the session in the alert data packets, receiving devices can determine quickly when they have received all data packets associated with a particular alert so that the receiving device can ignore subsequent broadcasts of the same alert, thereby enabling it to avoid draining the battery by receiving redundant alert messages. This enables the FLO broadcast network to broadcast alerts frequently in order to inform receiver devices as soon as they are turned on without draining the batteries of other receiver devices from unnecessary processing of redundant alert messages or constant monitoring for detecting alerts. The embodiments also enable effective utilization of broadcast bandwidth for delivering alert messages by enabling alert messages to be multiplexed with other streams. Thus, if an alert message does not fill the minimum size for an MLC (e.g., 16 kilobits per superframe), the alert can be multiplexed with other streams into an MLC to effectively utilize the available bandwidth. Alert session packet tags can be used to identify packets associated with alert data messages so that the packets can be multiplexed with packets of different types of content into a stream.
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing embodiments may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.
The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.
In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a tangible computer-readable storage medium. Computer-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer-readable medium, which may be incorporated into a computer program product.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.
This application claims the benefit of priority to U.S. Provisional Application No. 61/233,224 entitled “System And Apparatus For Delivering Emergency Alert Messages As A Service Content In A Broadcast Network” filed Aug. 12, 2009, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61233224 | Aug 2009 | US |
