WO2009053111A1 - Delivering an emergency alert in mbms - Google Patents

Delivering an emergency alert in mbms Download PDF

Info

Publication number
WO2009053111A1
WO2009053111A1 PCT/EP2008/051046 EP2008051046W WO2009053111A1 WO 2009053111 A1 WO2009053111 A1 WO 2009053111A1 EP 2008051046 W EP2008051046 W EP 2008051046W WO 2009053111 A1 WO2009053111 A1 WO 2009053111A1
Authority
WO
WIPO (PCT)
Prior art keywords
emergency
content data
terminal
port number
mbms
Prior art date
Application number
PCT/EP2008/051046
Other languages
French (fr)
Inventor
Juan-Antonio Ibanez
Aurelie Zanin
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to JP2010529303A priority Critical patent/JP2011501923A/en
Publication of WO2009053111A1 publication Critical patent/WO2009053111A1/en

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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services

Definitions

  • the present invention relates to the provision of emergency services in the Multimedia Broadcast Multicast Service (MBMS).
  • MBMS Multimedia Broadcast Multicast Service
  • the invention relates to the delivery of emergency messages in MBMS.
  • Multimedia broadcast/multicast services are growing in importance, even more so since mobile handheld devices have become capable of receiving multimedia content via radio networks.
  • MBMS Multimedia Broadcast Multicast Service
  • UTRA UMTS Terrestrial Radio Access
  • MBMS logical transmission channels are defined and are mapped to physical ones. The basic logical channels are as follows:
  • MCCH MBMS point-to-multipoint Control Channel
  • MBMS point-to-multipoint Traffic Channel (MTCH): This logical channel is used for a PTM downlink transmission of user plane information between network and UEs.
  • MTCH MBMS point-to-multipoint Traffic Channel
  • MICH MBMS notification Indicator Channel
  • MBMS point-to-multipoint Scheduling Channel This logical channel is used for a PTM downlink transmission of MBMS service transmission schedule between network and UEs.
  • MBMS enables data to be sent from a single source to multiple recipients. This can be achieved by streaming the data (e.g. mobile TV), or by file downloading (e.g. pod casts).
  • An MBMS service can be uniquely identified by its Temporary Mobile Group Identity (TMGI).
  • TMGI Temporary Mobile Group Identity
  • a "service” represents a set of files, usually related to each other in accordance with the subscription model. For example, a user might subscribe to a particular show and regularly receive episodes of the show during his subscription period. All episodes would then share the same TMGI.
  • BM-SC Broadcast/Multicast Service Centre
  • the BM-SC provides five main functionalities: membership; security; session and transmission; proxy and transport; and service announcement.
  • the MBMS session could be left open during the life time of the service (which is the case when data is delivered by streaming), but this should be avoided for file download as it would result in a very inefficient use of network resources, the file data flow not being continuous.
  • the MBMS payload (the actual media content) is transported on the MTCH, whereas the information about the ongoing MBMS sessions in a cell, including their TMGIs, is carried on the MCCH.
  • the payload may include headers from other layers: MBMS considers anything above the IP layer as payload.
  • the UE gets the list of available services and associated TMGIs during a service announcement phase, which is typically at application start-up.
  • the TMGIs are embedded in a set of Session Description Protocol (SDP) files.
  • SDP Session Description Protocol
  • MCCH for TMGIs relevant to his subscription and, when one TMGI matches, the UE tunes to the MTCH channel in order to receive the actual content.
  • MBMS Multimedia Broadcast/Multicast Service
  • an Emergency alert service provided over MBMS.
  • the UE should preferably receive the Emergency alert and display it immediately. Not more than a few seconds should elapse between the reception of the emergency document by the operator and the display of the file on the end-user screen. Moreover, emergency alerts obviously cannot be pre-scheduled.
  • One way of implementing this would be to provide the emergency alert service over a dedicated MBMS bearer identified by a specific TMGI.
  • the UE When the alert is issued, the UE would detect on MCCH the TMGI corresponding to the Emergency alert service, stop any ongoing download or streaming session, receive the Emergency file and display it immediately.
  • This would require that the UE continuously monitors MCCH for the presence of the TMGI associated with the emergency alert service (to detect the start of an emergency session), even when it is receiving another service via MBMS.
  • This might not be a capability supported by all terminals, especially in the early phase of MBMS.
  • this would require that any other ongoing MBMS session is dropped if the terminal can only receive one at a time.
  • a method of delivering an emergency alert in a network operating a Multimedia Broadcast Multicast Service comprises a server which delivers MBMS content data, using a payload channel (an MBMS bearer), to a terminal listening to a MBMS session.
  • MBMS bearer a payload channel
  • the emergency alert is encoded as MBMS emergency content data by labelling it differently to any other MBMS content data.
  • the emergency content data is then transmitted on all established MBMS bearers.
  • a dedicated MBMS bearer identified by a specific TMGI is also established for transmitting the emergency content data to any terminal not already receiving MBMS content data for another service.
  • the terminal When the terminal receives the emergency content data, it may identify that it relates to an emergency alert, and should decode the emergency alert immediately and present it to the user, with a higher priority than any other content data.
  • the presentation to the user may be, for example, in the form of a graphical display and/or audio alert.
  • the emergency content data is preferably interleaved with the other content data, although it will be appreciated that, in some embodiments, the emergency content data may take the form of a single file or contiguous data block, in which case "interleaved" may simply mean that it is sent before, after or at the same time as the payloads of the other content data.
  • the emergency content data is allocated an emergency port number that is different to a port number allocated to the other content data. This means that the terminal can easily distinguish between emergency content data and other content data, and that both can be transmitted using one and the same payload channel.
  • the emergency port number may be indicated by the server at the start-up of the MBMS client in the terminal. For example it may be sent in a Session Description Protocol (SDP) file. Alternatively, the emergency port number may be predefined as a standard port number for use in all MBMS sessions or configured in the terminal by ad- hoc means (e.g. as a factory setting or via Over-The-Air (OTA) configuration).
  • SDP Session Description Protocol
  • OTA Over-The-Air
  • the emergency content data and other content data may be in the form of files downloaded by the terminal, or in the form of streamed data.
  • a server for use in a network operating a Multimedia Broadcast Multicast Service (MBMS).
  • the server comprises a transmitter arranged to deliver MBMS content data, using a payload channel, to a terminal listening to a MBMS session.
  • a receiver is arranged to receive an emergency alert from an external source.
  • a processor is operatively connected to the transmitter and receiver and arranged to encode the emergency alert as MBMS emergency content data and label the emergency content data as being different to any other content data.
  • the transmitter is also arranged to transmit the emergency content data to the terminal using the payload channel.
  • a terminal for use in a network operating a Multimedia Broadcast Multicast Service (MBMS).
  • the terminal comprises a receiver arranged to receive MBMS emergency content data and other content data, in a payload channel, from a server.
  • a processor is operatively connected to the receiver and arranged to distinguish between the emergency content data and the other content data and decode the MBMS emergency content data to recover an emergency alert.
  • a presentation device e.g. a display
  • the processor is operatively connected to the processor and arranged to present the emergency alert to the user.
  • Figure 1 is a schematic representation of traffic between a server and a UE in a prior art method of sending an emergency alert in MBMS;
  • Figure 2 is a schematic representation of traffic between a server and a UE in sending and displaying an emergency alert
  • Figure 3 is a schematic representation of an MBMS server
  • Figure 4 is a schematic representation of a UE
  • Figure 5 is a flow chart showing the delivery and display of an emergency alert.
  • Figure 1 illustrates one possible system for delivering emergency alerts.
  • Figure 1 is a schematic representation of traffic between a server 1 and UE 2.
  • an MBMS session is initially active 3, enabling transfer of content data (whether in the form of file downloads or streaming data) to the UE 2.
  • an emergency alert is received at the server 4
  • all ongoing MBMS sessions in the network are stopped 5, in order to force all users to stop their current download (if any).
  • the emergency session is then started 6 by the server: in this example it is labelled TMGM .
  • the emergency alert message is then sent 7, using the newly opened emergency session.
  • the previously active downloads fail, enabling the UE to switch to the emergency session and display the emergency alert.
  • this solution is both inelegant and inefficient: the file downloads would be abruptly stopped, which might generate heavy recovery procedures, and it is estimated that the whole process would take far more than a few seconds, which is not acceptable.
  • Figure 2 illustrates a preferred system for delivering emergency alerts and is a schematic illustration of the traffic between a server 21 and UE 22 in delivering content data using MBMS. It will be appreciated that other nodes (not shown) may be involved in the delivery of data between the server 21 and the UE 22. It will also be appreciated that there may be more than one UE receiving the same data from the server 21. Initially an MBMS session 23, to which the UE 22 is listening, is active. Figure 2 does not show the signalling required to set up such a session, but this is described in 3GPP TS 26.346.
  • the server 21 duplicates it and sends a copy on each active MBMS session (in addition to setting up a dedicated MBMS emergency session for the users not currently listening to any
  • the figure shows the active MBMS session 23 to which the UE 22 is listening, and the emergency alert is therefore sent 25 to the UE 22 using the active session.
  • the TMGI of the active session remains unchanged, but the emergency alert is sent with a different port number.
  • the emergency port number is [12346]. The UE knows that messages received on this port number are emergency messages, and they are presented to the user immediately
  • the presentation to the user may be in any suitable form, for example a graphical display or an audible signal.
  • the server may be providing many different services to different users, the emergency file(s) may be associated with different TMGIs, depending on which MBMS session it is sent on.
  • the Session Description file sent to the UE at service announcement must include information about the possibility that emergency files could be sent at any time within an active session, together with the port number associated with the emergency files. The UE should then prioritize the files received on that port number and present them immediately to the user.
  • the port number is already known by the UE. This may be achieved by pre-allocation of the port number by the Internet Assigned Numbers Authority (IANA) so that all messages sent on the allocated port number are emergency messages, and the UE will know to prioritise them.
  • the port number may be configured in the UE by ad-hoc means such as a factory setting or Over-The-Air (OTA) configuration.
  • OTA Over-The-Air
  • the UE receives an SDP file to describe the service.
  • IANA may assign a specific port number for emergency services.
  • the end user When receiving an MBMS service, the end user would both listen to the standard port for content data as indicated in the SDP file (as described above) and to the emergency port assigned by IANA.
  • the pre-allocated port may be configured in the terminal by ad- hoc means such as factory settings or OTA configuration.
  • FIG 3 is a schematic representation of a server 31 providing an MBMS service.
  • the server could be the server 21 shown in Figure 2.
  • the server includes a memory 32 for storing content data, and a microprocessor 33 for encoding the data.
  • a transmitter 34 transmits the data towards recipients.
  • a receiver 35 receives emergency alerts from the authorities, and this is recognised by the microprocessor 33.
  • the emergency alerts are transmitted by the transmitter 34, within the payload of an active session, as well as on a dedicated session established when the emergency alert is received by the receiver 35.
  • the emergency alert files (or data) are distinguished from other files or data by the port number associated with them.
  • FIG 4 is a schematic representation of a UE 41 receiving an MBMS service.
  • the UE could be the UE 22 shown in Figure 2.
  • the UE 41 includes a receiver 43 for receiving file downloads from a server.
  • the files may be stored in a memory 44 and processed by a microprocessor 45, before being presented to the user via a display 46 or other presentation interface.
  • the UE monitors two ports: a "regular content" port and an "emergency" port. Data delivered to the regular content port is stored, processed and displayed as normal. Data delivered to the emergency port is prioritised and presented immediately to the user.
  • Figure 5 is a flow chart showing the principal operations involved in sending an emergency alert to a UE.
  • the MBMS server allocates an emergency port number and includes it in the service announcements (i.e. in the SDP files) of all MBMS services. If an emergency port number has been assigned by the IANA or is provisioned by ad-hoc means in every UE, this step is not necessary.
  • S2 An emergency alert is received from the authorities at an MBMS server.
  • the emergency alert is encoded as emergency content data, ready for insertion into outgoing data flows.
  • the emergency content data is labelled as being different to the other content data transmitted by the server. This is preferably done by associating an emergency port number with the emergency content data.
  • the emergency port number is different to the port number(s) associated with the other content data transmitted by the server.
  • S5 The emergency content data is inserted into the outgoing data flow of all active MBMS sessions. If the delivery method is file download, this will involve informing UEs that a new file is available (e.g. by means of a File Delivery Table (FDT)), and the UEs receiving the file from the server.
  • FDT File Delivery Table
  • S6 The server establishes a dedicated MBMS session (identified by an "emergency" TMGI) so that the UEs that are not engaged in any MBMS session still receive the emergency alert. In practice, this will be done in parallel with step S5.
  • S7 The emergency alert is received by each listening UE, with the associated emergency port number.
  • Each UE knows that a file received on the emergency port number is an emergency alert. The file is therefore presented to the user immediately.
  • users will be able to receive emergency alert messages over MBMS regardless of the limitations of terminals regarding the ability to monitor multiple TMGIs when an MBMS session is ongoing and without having to abruptly release any active MBMS session.
  • the time between the reception of an emergency file by the operator (server) and the actual presentation to the user is significantly lowered when the UE already has an MBMS session active compared to the case where the UE has to establish an MBMS session before receiving the file.
  • the emergency alert file is inserted into the data flow of an active MBMS session, and the embodiments described involve its identification by the use of the UDP port number.
  • emergency messages could potentially be identified on layers above UDP/IP, for instance by means of the Content-Type field.
  • FLUTE session the transmission of a content file is always preceded by the transmission of a File Delivery Table (FDT) describing the attributes of the data file(s) being transferred: one of these attributes is the Content-Type.
  • FDT File Delivery Table
  • the emergency file may be a different format to the other content files: for example, the emergency file could be an audio file, while the other content files are video files.
  • the format of the emergency file could be indicated in the SDP file, although for file download it is usually indicated in the FDT.
  • a further advantage of indicating the file type in the FDT is that it is possible to change type between each emergency. Again, however, this requires receiving and processing the FDT before the nature of the file can be determined.
  • the FLUTE receiver needs to know on which port to listen for the reception of the files (including the FDT). Identifying emergency messages directly on the UDP layer allows identification as early as possible in the protocol stack, thus allowing a more efficient implementation.
  • the display or presentation of the emergency alert by the UE may be in the form of audio or visual data or a combination of both, and that the "display" of such data is intended to encompass playback of audio and/or visual data. It is not limited to the display of visual data.

Abstract

The invention provides a method and apparatus for delivering an emergency alert in a network operating a Multimedia Broadcast Multicast Service (MBMS). The network comprises a server which delivers MBMS content data, using a payload channel, to a terminal listening to a MBMS session. When an emergency alert is received at the server, it is encoded as MBMS emergency content data, and the emergency content data is labelled as being different to the other content data. The emergency content data is then transmitted to the terminal in the existing payload channel.

Description

Delivering an emergency alert in MBMS
Technical Field
The present invention relates to the provision of emergency services in the Multimedia Broadcast Multicast Service (MBMS). In particular, the invention relates to the delivery of emergency messages in MBMS.
Background
Multimedia broadcast/multicast services are growing in importance, even more so since mobile handheld devices have become capable of receiving multimedia content via radio networks.
However, delivering multimedia over a wireless channel to handheld devices is a highly non-trivial task. Subscribers may experience different channel quality while receiving the same content. In addition, each user wants the highest possible quality of delivered media.
The introduction of the Multimedia Broadcast Multicast Service (MBMS) (3GPP TS 23.246) in the UMTS Terrestrial Radio Access (UTRA) provides techniques for optimized transmission of a MBMS bearer service such as point-to-multipoint transmission, selective combining and transmission mode selection between Point-to- Multipoint (PTM) and Point-to-Point (PTP) bearers. MBMS logical transmission channels are defined and are mapped to physical ones. The basic logical channels are as follows:
(a) MBMS point-to-multipoint Control Channel (MCCH): This logical channel is used for a PTM downlink transmission of control plane information between network and User Equipments (UEs).
(b) MBMS point-to-multipoint Traffic Channel (MTCH): This logical channel is used for a PTM downlink transmission of user plane information between network and UEs. (c) MBMS notification Indicator Channel (MICH): This logical channel is used to notify listening UEs about upcoming changes of the information provided on MCCH.
(d) MBMS point-to-multipoint Scheduling Channel (MSCH): This logical channel is used for a PTM downlink transmission of MBMS service transmission schedule between network and UEs.
Thus MBMS enables data to be sent from a single source to multiple recipients. This can be achieved by streaming the data (e.g. mobile TV), or by file downloading (e.g. pod casts).
An MBMS service can be uniquely identified by its Temporary Mobile Group Identity (TMGI). When the delivery method used is file download, a "service" represents a set of files, usually related to each other in accordance with the subscription model. For example, a user might subscribe to a particular show and regularly receive episodes of the show during his subscription period. All episodes would then share the same TMGI.
In 3GPP, a logic component called the Broadcast/Multicast Service Centre (BM-SC) provides MBMS functionalities in the service layer for realizing the services. The BM- SC provides five main functionalities: membership; security; session and transmission; proxy and transport; and service announcement. Each time a new file or set of files is made available by the content provider for a particular service, the BM-SC opens an MBMS session for the corresponding TMGI, sends the file/set of files, and closes the MBMS session. It will be appreciated that the MBMS session could be left open during the life time of the service (which is the case when data is delivered by streaming), but this should be avoided for file download as it would result in a very inefficient use of network resources, the file data flow not being continuous.
On the radio interface the MBMS payload (the actual media content) is transported on the MTCH, whereas the information about the ongoing MBMS sessions in a cell, including their TMGIs, is carried on the MCCH. In this context it will be understood that the payload may include headers from other layers: MBMS considers anything above the IP layer as payload.
The UE gets the list of available services and associated TMGIs during a service announcement phase, which is typically at application start-up. The TMGIs are embedded in a set of Session Description Protocol (SDP) files. The UE listens to the
MCCH for TMGIs relevant to his subscription and, when one TMGI matches, the UE tunes to the MTCH channel in order to receive the actual content. This is described in more detail in 3GPP TS 26.346, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs".
There is a desire to define and support an "Emergency alert service" provided over MBMS. When an Emergency alert is issued, the UE should preferably receive the Emergency alert and display it immediately. Not more than a few seconds should elapse between the reception of the emergency document by the operator and the display of the file on the end-user screen. Moreover, emergency alerts obviously cannot be pre-scheduled.
One way of implementing this would be to provide the emergency alert service over a dedicated MBMS bearer identified by a specific TMGI. When the alert is issued, the UE would detect on MCCH the TMGI corresponding to the Emergency alert service, stop any ongoing download or streaming session, receive the Emergency file and display it immediately. This would require that the UE continuously monitors MCCH for the presence of the TMGI associated with the emergency alert service (to detect the start of an emergency session), even when it is receiving another service via MBMS. This might not be a capability supported by all terminals, especially in the early phase of MBMS. Moreover, this would require that any other ongoing MBMS session is dropped if the terminal can only receive one at a time.
One solution to that problem would be to force all of the ongoing MBMS sessions in the network to stop when an emergency alert is received, in order to force all UEs to stop their current download (if any). The emergency session would then be started, and the emergency alert message sent using the newly opened emergency session. The previously active downloads fail, enabling the UE to switch to the emergency session and display the emergency alert. However, this solution is both inelegant and inefficient: the file downloads would be abruptly stopped, which might generate heavy recovery procedures, and it is estimated that the whole process would take far more than a few seconds, which is not acceptable.
Summary
In accordance with one aspect of the present invention there is provided a method of delivering an emergency alert in a network operating a Multimedia Broadcast Multicast Service (MBMS). The network comprises a server which delivers MBMS content data, using a payload channel (an MBMS bearer), to a terminal listening to a MBMS session. When an emergency alert is received at the server, the emergency alert is encoded as MBMS emergency content data by labelling it differently to any other MBMS content data. The emergency content data is then transmitted on all established MBMS bearers.
Preferably, a dedicated MBMS bearer identified by a specific TMGI is also established for transmitting the emergency content data to any terminal not already receiving MBMS content data for another service.
When the terminal receives the emergency content data, it may identify that it relates to an emergency alert, and should decode the emergency alert immediately and present it to the user, with a higher priority than any other content data. The presentation to the user may be, for example, in the form of a graphical display and/or audio alert.
The emergency content data is preferably interleaved with the other content data, although it will be appreciated that, in some embodiments, the emergency content data may take the form of a single file or contiguous data block, in which case "interleaved" may simply mean that it is sent before, after or at the same time as the payloads of the other content data.
In a preferred embodiment, the emergency content data is allocated an emergency port number that is different to a port number allocated to the other content data. This means that the terminal can easily distinguish between emergency content data and other content data, and that both can be transmitted using one and the same payload channel.
The emergency port number may be indicated by the server at the start-up of the MBMS client in the terminal. For example it may be sent in a Session Description Protocol (SDP) file. Alternatively, the emergency port number may be predefined as a standard port number for use in all MBMS sessions or configured in the terminal by ad- hoc means (e.g. as a factory setting or via Over-The-Air (OTA) configuration).
The emergency content data and other content data may be in the form of files downloaded by the terminal, or in the form of streamed data.
In accordance with another aspect of the present invention there is provided a server for use in a network operating a Multimedia Broadcast Multicast Service (MBMS). The server comprises a transmitter arranged to deliver MBMS content data, using a payload channel, to a terminal listening to a MBMS session. A receiver is arranged to receive an emergency alert from an external source. A processor is operatively connected to the transmitter and receiver and arranged to encode the emergency alert as MBMS emergency content data and label the emergency content data as being different to any other content data. The transmitter is also arranged to transmit the emergency content data to the terminal using the payload channel.
In accordance with a further aspect of the present invention there is provided a terminal for use in a network operating a Multimedia Broadcast Multicast Service (MBMS). The terminal comprises a receiver arranged to receive MBMS emergency content data and other content data, in a payload channel, from a server. A processor is operatively connected to the receiver and arranged to distinguish between the emergency content data and the other content data and decode the MBMS emergency content data to recover an emergency alert. A presentation device (e.g. a display) is operatively connected to the processor and arranged to present the emergency alert to the user.
Brief Description of the Drawings Figure 1 is a schematic representation of traffic between a server and a UE in a prior art method of sending an emergency alert in MBMS;
Figure 2 is a schematic representation of traffic between a server and a UE in sending and displaying an emergency alert;
Figure 3 is a schematic representation of an MBMS server;
Figure 4 is a schematic representation of a UE; and
Figure 5 is a flow chart showing the delivery and display of an emergency alert.
Detailed Description
The service delivery aspects of MBMS are described in detail in 3GPP TS 26.346 and this description need not be reproduced here. However, file delivery will briefly be discussed. Broadcast and multicast are one-way transmissions in the downlink. Therefore, the transmission control protocol (TCP) cannot be employed because it requires a bidirectional unicast connection. However, the Internet Engineering Task Force (IETF) provides a framework for file delivery over unicast called File Delivery over Unidirectional Transport (FLUTE), and which can be reused in the broadcast case. FLUTE employs the user datagram protocol (UDP) as its underlying transport protocol.
Figure 1 illustrates one possible system for delivering emergency alerts. Figure 1 is a schematic representation of traffic between a server 1 and UE 2. As shown in Figure 1 , an MBMS session is initially active 3, enabling transfer of content data (whether in the form of file downloads or streaming data) to the UE 2. When an emergency alert is received at the server 4, all ongoing MBMS sessions in the network are stopped 5, in order to force all users to stop their current download (if any). The emergency session is then started 6 by the server: in this example it is labelled TMGM . The emergency alert message is then sent 7, using the newly opened emergency session. The previously active downloads fail, enabling the UE to switch to the emergency session and display the emergency alert. As previously discussed, this solution is both inelegant and inefficient: the file downloads would be abruptly stopped, which might generate heavy recovery procedures, and it is estimated that the whole process would take far more than a few seconds, which is not acceptable.
Figure 2 illustrates a preferred system for delivering emergency alerts and is a schematic illustration of the traffic between a server 21 and UE 22 in delivering content data using MBMS. It will be appreciated that other nodes (not shown) may be involved in the delivery of data between the server 21 and the UE 22. It will also be appreciated that there may be more than one UE receiving the same data from the server 21. Initially an MBMS session 23, to which the UE 22 is listening, is active. Figure 2 does not show the signalling required to set up such a session, but this is described in 3GPP TS 26.346.
Suppose an emergency alert 24 from the authorities is received at the server 21. At reception of the emergency file from the relevant government agency, the server 21 duplicates it and sends a copy on each active MBMS session (in addition to setting up a dedicated MBMS emergency session for the users not currently listening to any
MBMS session). In this example, the figure shows the active MBMS session 23 to which the UE 22 is listening, and the emergency alert is therefore sent 25 to the UE 22 using the active session. The TMGI of the active session remains unchanged, but the emergency alert is sent with a different port number. In the example shown in Figure 2, the emergency port number is [12346]. The UE knows that messages received on this port number are emergency messages, and they are presented to the user immediately
26. It will be appreciated that the presentation to the user may be in any suitable form, for example a graphical display or an audible signal.
It will be noted that, since the server may be providing many different services to different users, the emergency file(s) may be associated with different TMGIs, depending on which MBMS session it is sent on.
In order to ensure that the UE knows that a message received on port number [12346] is an emergency message, two main alternatives are provided. In the first, the Session Description file sent to the UE at service announcement must include information about the possibility that emergency files could be sent at any time within an active session, together with the port number associated with the emergency files. The UE should then prioritize the files received on that port number and present them immediately to the user. In the second alternative, the port number is already known by the UE. This may be achieved by pre-allocation of the port number by the Internet Assigned Numbers Authority (IANA) so that all messages sent on the allocated port number are emergency messages, and the UE will know to prioritise them. Alternatively, the port number may be configured in the UE by ad-hoc means such as a factory setting or Over-The-Air (OTA) configuration.
These two alternatives are now discussed in more detail.
1 : Port negotiation in SDP file
During service announcement (i.e. typically when the MBMS service is activated in the UE - not shown in Figure 2), the UE receives an SDP file to describe the service. An example, taken from 3GPP TS 26.346, is as follows: v=0 o=userl23 2890844526 2890842807 IN IP6 2201 : 056D : : 112E : 144A: 1E24 S=FiIe delivery session example t=2873397496 2873404696 a=mbms-mode: broadcast 1234 1 // 1234 is the TMGI a=FEC-declaration : 0 encodmg-id=l a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 a=flute-tsi:3 m=application 54321 FLUTE/UDP 0 // port number ^4321
C=IN IP6 FFlE: 03AD: : 7F2E: 172A: 1E24/1 b=64
To support Emergency service, the SDP file should be updated by adding the following exemplary lines: m=emergency 12346 FLUTE/UDP 0 // port number for emergency 12346 C=IN IP6 FFlE: 03AD: : 7F2E: 172A: 1E24/1
This confirms that any messages sent to port number 12346 are emergency messages and should be presented to the user immediately. It will be noted that the emergency port number is chosen by the server and broadcast to all users. When receiving the MBMS service (as described in Figure 2), the UE should listen both to port 54321 (on which regular content data is delivered) and to port 12346.
2: Pre-allocated port
It is envisaged that IANA may assign a specific port number for emergency services.
When receiving an MBMS service, the end user would both listen to the standard port for content data as indicated in the SDP file (as described above) and to the emergency port assigned by IANA.
As a further alternative, the pre-allocated port may be configured in the terminal by ad- hoc means such as factory settings or OTA configuration.
Figure 3 is a schematic representation of a server 31 providing an MBMS service. The server could be the server 21 shown in Figure 2. The server includes a memory 32 for storing content data, and a microprocessor 33 for encoding the data. A transmitter 34 transmits the data towards recipients. A receiver 35 receives emergency alerts from the authorities, and this is recognised by the microprocessor 33. The emergency alerts are transmitted by the transmitter 34, within the payload of an active session, as well as on a dedicated session established when the emergency alert is received by the receiver 35. The emergency alert files (or data) are distinguished from other files or data by the port number associated with them.
Figure 4 is a schematic representation of a UE 41 receiving an MBMS service. The UE could be the UE 22 shown in Figure 2. The UE 41 includes a receiver 43 for receiving file downloads from a server. The files may be stored in a memory 44 and processed by a microprocessor 45, before being presented to the user via a display 46 or other presentation interface. For any active MBMS session, the UE monitors two ports: a "regular content" port and an "emergency" port. Data delivered to the regular content port is stored, processed and displayed as normal. Data delivered to the emergency port is prioritised and presented immediately to the user. Figure 5 is a flow chart showing the principal operations involved in sending an emergency alert to a UE.
S1 : The MBMS server allocates an emergency port number and includes it in the service announcements (i.e. in the SDP files) of all MBMS services. If an emergency port number has been assigned by the IANA or is provisioned by ad-hoc means in every UE, this step is not necessary.
S2: An emergency alert is received from the authorities at an MBMS server.
S3: The emergency alert is encoded as emergency content data, ready for insertion into outgoing data flows.
S4: The emergency content data is labelled as being different to the other content data transmitted by the server. This is preferably done by associating an emergency port number with the emergency content data. The emergency port number is different to the port number(s) associated with the other content data transmitted by the server.
S5: The emergency content data is inserted into the outgoing data flow of all active MBMS sessions. If the delivery method is file download, this will involve informing UEs that a new file is available (e.g. by means of a File Delivery Table (FDT)), and the UEs receiving the file from the server.
S6: The server establishes a dedicated MBMS session (identified by an "emergency" TMGI) so that the UEs that are not engaged in any MBMS session still receive the emergency alert. In practice, this will be done in parallel with step S5.
S7: The emergency alert is received by each listening UE, with the associated emergency port number.
S8: Each UE knows that a file received on the emergency port number is an emergency alert. The file is therefore presented to the user immediately. Thus it can be seen that users will be able to receive emergency alert messages over MBMS regardless of the limitations of terminals regarding the ability to monitor multiple TMGIs when an MBMS session is ongoing and without having to abruptly release any active MBMS session.
Furthermore, the time between the reception of an emergency file by the operator (server) and the actual presentation to the user is significantly lowered when the UE already has an MBMS session active compared to the case where the UE has to establish an MBMS session before receiving the file.
It will be appreciated that variations from the above described embodiments may still fall within the scope of the invention. For example, the emergency alert file, or data, is inserted into the data flow of an active MBMS session, and the embodiments described involve its identification by the use of the UDP port number. It will be appreciated that other methods for identifying the emergency alert may also be envisaged. For example, emergency messages could potentially be identified on layers above UDP/IP, for instance by means of the Content-Type field. In a FLUTE session, the transmission of a content file is always preceded by the transmission of a File Delivery Table (FDT) describing the attributes of the data file(s) being transferred: one of these attributes is the Content-Type. It could therefore be envisaged that a new Content-Type, e.g. "emergency", could be specified, that clearly identifies the file as being an emergency message that has to be presented immediately. This, however, requires receiving and processing the FDT before the nature of the file can be determined.
Furthermore, it will be appreciated that the emergency file may be a different format to the other content files: for example, the emergency file could be an audio file, while the other content files are video files. The format of the emergency file could be indicated in the SDP file, although for file download it is usually indicated in the FDT. A further advantage of indicating the file type in the FDT is that it is possible to change type between each emergency. Again, however, this requires receiving and processing the FDT before the nature of the file can be determined.
In any event, the FLUTE receiver needs to know on which port to listen for the reception of the files (including the FDT). Identifying emergency messages directly on the UDP layer allows identification as early as possible in the protocol stack, thus allowing a more efficient implementation.
It will also be appreciated that the above embodiments have generally been described in the context of file downloads, with emergency alerts being transmitted as files. It will be appreciated that the invention is equally applicable to the delivery of streaming data: the packets into which the emergency alert is encoded are labeled with a different port number, and the receiver knows to decode these packets immediately and present the alert encoded therein.
Furthermore, reference has been made to the display or presentation of the emergency alert by the UE. It will be appreciated that the alert may be in the form of audio or visual data or a combination of both, and that the "display" of such data is intended to encompass playback of audio and/or visual data. It is not limited to the display of visual data.
Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above description should be read as implying that any particular element, step, or function is essential such that it must be included in the claims' scope. The scope of protection is defined by the claims.

Claims

CLAIMS:
1. A method of delivering an emergency alert in a network operating a Multimedia Broadcast Multicast Service "MBMS", the network comprising a server which delivers content data, using a payload channel, to a terminal listening to a MBMS session, the method comprising: at the server, receiving an emergency alert; encoding the emergency alert as emergency content data; labelling the emergency content data as being different to other content data; and transmitting the emergency content data to the terminal in the payload channel.
2. The method of claim 1 , wherein the emergency content data is interleaved with the other content data.
3. The method of claim 1 or 2, wherein the terminal receives the emergency content data, identifies that it relates to an emergency alert, and decodes and presents the emergency alert to a user immediately, with a higher priority than the other content data.
4. The method of claim 3, wherein the emergency alert is presented to the user in the form of a graphical display and/or audio alert.
5. The method of any preceding claim, wherein the emergency content data is labelled as being different to the other content data by being associated with an emergency port number that is different to a port number allocated to the other content data.
6. The method of claim 5, wherein the emergency port number is indicated by the server.
7. The method of claim 6, wherein the emergency port number is sent from the server to the terminal in a Session Description Protocol "SDP" file.
8. The method of claim 5, wherein the emergency port number is defined as a standard port number for use in all MBMS sessions.
9. The method of claim 5, wherein the emergency port number is configured in the terminal by ad-hoc means.
10. The method of any preceding claim, wherein the emergency content data and/or other content data are in the form of files downloaded by the terminal.
1 1. The method of any of claims 1 to 9, wherein the emergency content data and/or other content data are in the form of data packets of streaming data.
12. The method of any preceding claim, further comprising establishing a dedicated MBMS bearer, identified by a specific Temporary Mobile Group Identity "TMGI" for transmitting the emergency content data to any terminal not already receiving MBMS payloads for another service.
13. A server for use in a network operating a Multimedia Broadcast Multicast Service "MBMS", the server comprising: a transmitter arranged to deliver content data, using a payload channel, to a terminal listening to a MBMS session; a receiver arranged to receive an emergency alert; and a processor operatively connected to the transmitter and receiver and arranged to encode the emergency alert as emergency content data and label the emergency content data as being different to other content data; wherein the transmitter is further arranged to transmit the emergency content data to the terminal using the payload channel.
14. The server of claim 13, wherein the transmitter is arranged to transmit the emergency content data interleaved with the other content data.
15. The server of claim 13 or 14, wherein the processor is arranged to associate the emergency content data with an emergency port number that is different to a port number allocated to the other content data.
16. The server of claim 15, wherein the emergency port number is assigned by the server.
17. The server of claim 16, wherein the emergency port number is sent from the server to the terminal in a Session Description Protocol "SDP" file.
18. The server of claim 15, wherein the emergency port number is defined as a standard port number for use in all MBMS sessions.
19. The server of any of claims 13 to 18, wherein the emergency content data and/or other content data are in the form of files downloaded by the terminal.
20. The server of any of claims 13 to 18, wherein the emergency content data and/or other content data are in the form of data packets of streaming data.
21. A terminal for use in a network operating a Multimedia Broadcast Multicast Service "MBMS", the terminal comprising: a receiver arranged to receive content data, in a payload channel, from a server; a processor operatively connected to the receiver and arranged to distinguish between emergency content data and other content data and decode the emergency content data to recover an emergency alert; and a user interface operatively connected to the processor and arranged to present the emergency alert to a user.
22. The terminal of claim 21 , wherein the processor is arranged to allocate a higher priority to the emergency content data than to the other content data.
23. The terminal of claim 21 or 22, wherein the emergency content data is interleaved with the other content data.
24. The terminal of claim 21 , 22 or 23, wherein the processor distinguishes between the emergency content data and other content data because the emergency content data is associated with an emergency port number which is different from a port number associated with the other content data.
25. The terminal of claim 24, wherein the emergency port number is received by the terminal at activation of a MBMS service.
26. The terminal of claim 25, wherein the emergency port number is received from the server in a Session Description Protocol "SDP" file.
27. The terminal of claim 24, wherein the emergency port number is defined as a standard port number for use in all MBMS sessions.
28. The terminal of claim 24, wherein the emergency port number is configured in the terminal by ad-hoc means for use in all MBMS sessions.
29. The terminal of any of claims 21 to 28, wherein the emergency content data and/or other content data are in the form of files downloaded by the terminal.
30. The terminal of any of claims 21 to 28, wherein the emergency content data and/or other content data are in the form of data packets of streaming data.
PCT/EP2008/051046 2007-10-22 2008-01-29 Delivering an emergency alert in mbms WO2009053111A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010529303A JP2011501923A (en) 2007-10-22 2008-01-29 Delivery of emergency alerts in MBMS

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US98162007P 2007-10-22 2007-10-22
US60/981,620 2007-10-22

Publications (1)

Publication Number Publication Date
WO2009053111A1 true WO2009053111A1 (en) 2009-04-30

Family

ID=39577558

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/051046 WO2009053111A1 (en) 2007-10-22 2008-01-29 Delivering an emergency alert in mbms

Country Status (2)

Country Link
JP (1) JP2011501923A (en)
WO (1) WO2009053111A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102595327A (en) * 2011-01-12 2012-07-18 中兴通讯股份有限公司 MBMS (Multimedia Broadcasting/Multicast Service) triggering method and system
WO2014078228A1 (en) * 2012-11-13 2014-05-22 Qualcomm Incorporated Emergency alert using mbms and cell broadcasting
US20160127439A1 (en) * 2014-11-03 2016-05-05 Qualcomm Incorporated Interfacing multimedia public warning system alerts
WO2017053548A1 (en) 2015-09-22 2017-03-30 Blackberry Limited Receiving public warning system data
US9673944B2 (en) 2011-03-04 2017-06-06 Huawei Technologies Co., Ltd. Method for controlling packet access, network side device, terminal device and communication system
US10271182B2 (en) 2015-07-29 2019-04-23 Blackberry Limited Enhanced public warning system to provide rich content
US10652721B1 (en) 2019-02-27 2020-05-12 At&T Intellectual Property I, L.P. Providing multimedia wireless emergency alerts

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060058005A1 (en) * 2004-09-10 2006-03-16 Dolezal Anthony J Wireless communication device for receiving an emergency broadcast message
US20070086465A1 (en) * 2005-10-07 2007-04-19 Nokia Corporation Notification as a Service or as an Access to a Service
EP1829008A1 (en) * 2004-12-23 2007-09-05 Telefonaktiebolaget LM Ericsson (publ) Method for informing multiple mobile terminals of an emergency event

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007132918A1 (en) * 2006-05-17 2007-11-22 Kddi Corporation Information distribution device, reception/reproduction device, information distribution method, and reception/reproduction method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060058005A1 (en) * 2004-09-10 2006-03-16 Dolezal Anthony J Wireless communication device for receiving an emergency broadcast message
EP1829008A1 (en) * 2004-12-23 2007-09-05 Telefonaktiebolaget LM Ericsson (publ) Method for informing multiple mobile terminals of an emergency event
US20070086465A1 (en) * 2005-10-07 2007-04-19 Nokia Corporation Notification as a Service or as an Access to a Service

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102595327A (en) * 2011-01-12 2012-07-18 中兴通讯股份有限公司 MBMS (Multimedia Broadcasting/Multicast Service) triggering method and system
US9673944B2 (en) 2011-03-04 2017-06-06 Huawei Technologies Co., Ltd. Method for controlling packet access, network side device, terminal device and communication system
WO2014078228A1 (en) * 2012-11-13 2014-05-22 Qualcomm Incorporated Emergency alert using mbms and cell broadcasting
CN104798390A (en) * 2012-11-13 2015-07-22 高通股份有限公司 Emergency alert using MBMS and cell broadcasting
US10182330B2 (en) 2012-11-13 2019-01-15 Qualcomm, Incorporated Emergency alert using MBMS and cell broadcasting
US20160127439A1 (en) * 2014-11-03 2016-05-05 Qualcomm Incorporated Interfacing multimedia public warning system alerts
WO2016073101A1 (en) * 2014-11-03 2016-05-12 Qualcomm Incorporated Interfacing multimedia public warning system alerts
US10271182B2 (en) 2015-07-29 2019-04-23 Blackberry Limited Enhanced public warning system to provide rich content
CN108141734A (en) * 2015-09-22 2018-06-08 黑莓有限公司 Receive public warning system data
KR20180057659A (en) * 2015-09-22 2018-05-30 블랙베리 리미티드 Reception of public alarm system data
WO2017053548A1 (en) 2015-09-22 2017-03-30 Blackberry Limited Receiving public warning system data
US10326544B2 (en) 2015-09-22 2019-06-18 Blackberry Limited Receiving public warning system data
EP3332567A4 (en) * 2015-09-22 2019-07-10 BlackBerry Limited Receiving public warning system data
CN108141734B (en) * 2015-09-22 2021-01-12 黑莓有限公司 Receiving public alert system data
KR102555099B1 (en) 2015-09-22 2023-07-12 블랙베리 리미티드 Receipt of Public Alert System data
US10652721B1 (en) 2019-02-27 2020-05-12 At&T Intellectual Property I, L.P. Providing multimedia wireless emergency alerts
US10834566B2 (en) 2019-02-27 2020-11-10 At&T Intellectual Property I, L.P. Providing multimedia wireless emergency alerts

Also Published As

Publication number Publication date
JP2011501923A (en) 2011-01-13

Similar Documents

Publication Publication Date Title
EP2568629B1 (en) Method and Apparatus for Sending Notification about Broadcast Service in a Mobile Broadcast System
EP2737763B1 (en) Managing handoff triggering between unicast and multicast services
AU2007283554B2 (en) Application-layer combining of multimedia streams delivered over multiple radio access networks and delivery modes
WO2009053111A1 (en) Delivering an emergency alert in mbms
US20070280138A1 (en) Information broadcasting system and method
US20090252084A1 (en) Method and apparatus for broadcasting push-to-talk group sessions
US20080031245A1 (en) Uplink signaling for multicast transmission
US8724535B2 (en) Technique for controlling content distributions in point-to-multipoint enabled network environments
KR20100032425A (en) System and method for mbms to pss handover
KR20070021032A (en) System and method for transmitting notification message in mobile broadcasting system
WO2009106127A1 (en) Delivery of multicast data
KR20050073114A (en) Method and apparatus for providing of broadcast/multicast service in wireless telecommunication system
US9338802B2 (en) Method for accelerating the activation of a MBMS service
WO2006107164A1 (en) Apparatus and method for delivering stream in a mobile broadcast system
US7941503B2 (en) System and method for providing personalized multimedia broadcasting over a mobile telecommunications radio area network
US10095575B2 (en) User equipment node, server node and methods performed in such nodes for performing file repair procedure
WO2016142810A1 (en) Method and network node for delivering multimedia broadcast services
WO2015171029A1 (en) Method, apparatus and communication device for handling broadcasted or multicasted content
RU2378795C2 (en) Method and device to output warning message in broadcasting transmission system
WO2008039001A1 (en) Method and system for transmitting and receiving media according to importance of media burst
US20100100601A1 (en) Media content transmission method and network-side equipment
WO2007102060A2 (en) Uplink signaling for multicast transmission

Legal Events

Date Code Title Description
DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08708363

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010529303

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08708363

Country of ref document: EP

Kind code of ref document: A1