RU2378795C2 - Method and device to output warning message in broadcasting transmission system - Google Patents

Abstract

FIELD: radio communication.

SUBSTANCE: invention relates to broadcasting transmission systems. Broadcasting transmitter, first, transmits first access data including first network address for general warning message transmission, and second access data context-coupled with broadcasting transmission control system, to broadcasting system receiver. If originates general warning event, general warning message is formed to be transmitted to aforesaid receiver via one of broadcasting transmission networks and network of cooperation with the help of first network address. Broadcasting system receiver receives general warning message reading the first network address in data received by broadcasting system transmitter.

EFFECT: reception of warning message.

61 cl, 21 dwg, 12 tbl

Description

FIELD OF THE INVENTION

The present invention generally relates to a broadcast system supporting broadcast services. More specifically, the present invention relates to a method and apparatus for providing a notification message in a broadcast system supporting mobile broadcast services.

State of the art

A mobile broadcast system includes several processes, including: terminal detection of a service configured to receive mobile broadcast services; subscription to the service by the terminal; providing various management information for receiving services; service transfer and service reception by the terminal. In the process of receiving mobile broadcast services from the mobile broadcast system, the terminal receives an alert message containing various control information for the broadcast service.

An example of such a mobile broadcast system is disclosed in detail in Patent Application (Korea) No. 2005-16650, registered by the applicant, which is incorporated herein by reference in its entirety. In this broadcast system, changes can occur due to various reasons while the terminal is receiving the broadcast. Some of the changes may be information about which the terminal should be notified. For example, the change information may include a change in the time of the mobile broadcast service and a change in information for receiving the mobile broadcast service.

The disclosed broadcast system is an architecture for mobile broadcast alerts. However, a terminal capable of receiving a mobile broadcast service cannot receive an alert message, since there is no definition of basic information for receiving an alert message, as well as the actual transmission / reception of an alert message. Therefore, there is a need to define these specific elements of information.

Disclosure of invention

Exemplary embodiments of the present invention solve at least the above problems and / or disadvantages and provide at least the advantages described below. Accordingly, an aspect of the present invention is to provide a system and method for transmitting a control message in a broadcast system supporting a mobile broadcast service.

Another aspect of an exemplary embodiment of the present invention is to provide a system and method for generating and transmitting an alert message to a terminal when serving in a broadcast system supporting mobile broadcast services.

A further further aspect of an exemplary embodiment of the present invention is to provide a device and method for transmitting a notification message to a terminal that is idle or accessing another communication system in a broadcast system supporting mobile broadcast services.

According to one aspect of an exemplary embodiment of the present invention, there is provided a method for providing broadcast services in a transmitter of an Internet Protocol (IP) -based broadcast system. The method comprises the steps of: (a) transmitting first access information including a first network address for transmitting a general notification message to a broadcast receiver that receives a broadcast service, and second access information associated with controlling the broadcast system, a broadcast receiver by one of a broadcast network and an interaction network; and (b) generating a general alert message and transmitting the generated general alert message to the broadcast receiver by one of the broadcast network and the interaction network using the first network address if a general alert event occurs.

According to another aspect of an exemplary embodiment of the present invention, there is provided a transmission apparatus of an Internet Protocol (IP) broadcasting system. The transmitting device comprises first means for transmitting first access information including a first network address for transmitting a general alert message and second access information associated with controlling a broadcast system via one of the broadcast network and the interaction network; and second means for generating, if a general notification event occurs, a general notification message and transmitting the generated general notification message through one of the broadcast network and the interaction network using the first network address.

According to a further aspect of an exemplary embodiment of the present invention, there is provided a method for receiving broadcast services in a broadcast receiver of an Internet Protocol (IP) -based broadcast system. The method comprises the steps of (a) receiving first access information including a first network address for receiving a general notification message and second access information associated with controlling a broadcast system from a broadcast transmission device via one of the broadcast network and the network interactions; and (b) receiving a general alert message based on the first network address in the data received from the broadcast transmitter.

According to yet another aspect of an exemplary embodiment of the present invention, there is provided a broadcast receiver of an Internet Protocol (IP) -based broadcast system. The broadcast receiver comprises first means for receiving first access information including a first network address for receiving a general notification message and second access information associated with controlling a broadcast system from a broadcast transmitter via one of the broadcast network and networking; and second means for receiving a general alert message based on the first network address in the data received from the broadcast transmitter.

According to yet another aspect of an exemplary embodiment of the present invention, there is provided a method for providing broadcast services in a network-based broadcast system using an Internet Protocol (IP). The method comprises the steps of: (a) transmitting, by a broadcast transmitter, a first access information including a first network address for transmitting a general notification message to a broadcast receiver, and second access information associated with controlling the broadcast system, to the broadcast receiver by one of the broadcast network and the interaction network; (b) if a general notification event occurs, generating a general notification message and transmitting the generated general notification message to the broadcast receiver by one of the broadcast network and the interaction network using the first network address; and (c) receiving a general alert message based on the first network address in the data received from the broadcast transmitter.

According to yet another aspect of an exemplary embodiment of the present invention, there is provided a network-based broadcast system using an Internet Protocol (IP). The broadcast system comprises a broadcast transmitter for transmitting first access information including a first network address for transmitting a general notification message and second access information associated with controlling a broadcast system to a broadcast receiver, and if event of general notification, generation of a general notification message and transmission of the generated general notification message to the receiving e broadcasting device via one of the broadcast network and the interaction network using the first network address; and a broadcast receiver for receiving a general alert message based on the first network address in data received from the broadcast transmitter.

According to yet another aspect of an exemplary embodiment of the present invention, there is provided a computer-readable recording medium storing a program for implementing a method for providing broadcast services in a receiver of an Internet Protocol (IP) -based broadcast system. The method includes the step of (a) transmitting first access information including a first network address for transmitting a general alert message to a broadcast receiving device that receives a broadcast service, and second access information associated with controlling the broadcast system, to the broadcast receiver by one of the broadcast network and the interaction network. The method further includes the step of (b) generating a general notification message and transmitting the generated general notification message to the broadcast receiver by one of the broadcast network and the interaction network using the first network address if a general notification event occurs.

According to yet another aspect of an exemplary embodiment of the present invention, there is provided a computer-readable recording medium storing a program for implementing a method for receiving broadcast services in a broadcast transmission apparatus of an Internet Protocol (IP) broadcasting system. The method includes the step of (a) receiving first access information including a first network address for receiving a general notification message and second access information associated with controlling a broadcast system from a broadcast transmission device via one of the broadcast network and networking. Additionally, the method includes the step of (b) receiving a general alert message based on the first network address in the data received from the broadcast transmitter.

Other aspects, advantages and pronounced features of the invention should become apparent to those skilled in the art from the following detailed description, which, when taken in conjunction with the accompanying drawings, discloses exemplary embodiments of the invention.

Brief Description of the Drawings

The above and other objectives, features and advantages of specific embodiments of the present invention should become more apparent from the following detailed description, taken in conjunction with the accompanying drawings, of which:

FIG. 1 is a diagram illustrating a functional architecture for transmitting a notification message in a mobile broadcast system according to a first exemplary embodiment of the present invention;

FIG. 2 is a flowchart illustrating a method for generating and transmitting SGDDs according to an exemplary embodiment of the present invention;

FIG. 3 is a flowchart illustrating a method for receiving an SGDD by a terminal in a mobile broadcast system according to an exemplary embodiment of the present invention;

FIG. 4 is a block diagram illustrating a broadcast system for transmitting a general alert message in a mobile broadcast system according to an exemplary embodiment of the present invention;

FIG. 5 is a flowchart illustrating a process for transmitting a general alert message in a mobile broadcast system according to an exemplary embodiment of the present invention;

FIG. 6 is a flowchart illustrating a process for receiving a general alert message in a client alert function of a mobile broadcast system according to an exemplary embodiment of the present invention;

FIG. 7 is a flowchart illustrating a process for receiving a general alert message in a client alert function when it is connected to an interaction network or system having a standby terminal of a mobile broadcast system according to an exemplary embodiment of the present invention;

FIG. 8 is a diagram illustrating a data model architecture in a service guide offered for mobile broadcasting in OMA BAC BCAST, one of the standard groups for mobile broadcasting technology;

FIG. 9 is a flowchart illustrating a method of generating and transmitting an access fragment in a mobile broadcast system according to an exemplary embodiment of the present invention;

FIG. 10 is a flowchart illustrating a method of receiving and processing an access fragment in a terminal of a mobile broadcast system according to an exemplary embodiment of the present invention;

FIG. 11 is a diagram illustrating the architecture of a digital video broadcast convergence network of broadcast and mobile transmission services (DVB-CBMS) according to a second exemplary embodiment of the present invention;

FIG. 12 is a diagram illustrating a data model of an electronic service guide (ESG) in a DVB-CBMS according to a second exemplary embodiment of the present invention;

FIG. 13 is a diagram illustrating an operation for delivering an ESG to a DVB-CBMS according to a second exemplary embodiment of the present invention;

FIG. 14 is a flowchart illustrating a schematic process for transmitting / receiving a notification message according to a second exemplary embodiment of the present invention;

FIG. 15 is a flowchart illustrating an operation of generating and delivering an ESG self-descriptor in a broadcast system according to a second exemplary embodiment of the present invention;

FIG. 16 is a flowchart illustrating an operation of receiving channel information of a notification message in an ESG self-descriptor by a terminal in a broadcast system according to a second exemplary embodiment of the present invention;

FIG. 17 is a flowchart illustrating an operation of generating and delivering channel information of a notification message in an ESG Acquisition fragment in a broadcast system according to a second exemplary embodiment of the present invention;

FIG. 18 is a flowchart illustrating an operation of receiving channel information of a notification message in an ESG Acquisition fragment by a terminal in a broadcast system according to a second exemplary embodiment of the present invention;

FIG. 19 is a flowchart illustrating a general alert message delivery operation in a broadcast system according to a second exemplary embodiment of the present invention;

FIG. 20 is a flowchart illustrating an operation of receiving a notification message by a terminal notification client function in a mobile broadcast system according to a second exemplary embodiment of the present invention; and

FIG. 21 is a flowchart illustrating a process for receiving a notification message in a client notification function of a terminal when it is connected to an interaction network in a broadcast system according to a second exemplary embodiment of the present invention.

In all the drawings, the same reference numbers of the drawings should be understood to mean the same elements, features and structures.

DETAILED DESCRIPTION OF THE INVENTION

Aspects indicated in the description, such as a detailed structure and elements, are provided in order to help in a comprehensive understanding of the embodiments of the present invention, and are merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications to the embodiments described herein can be made without departing from the scope and spirit of the invention. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

An exemplary embodiment of the present invention includes an apparatus and method for generating and transmitting a notification message to a terminal receiving a mobile broadcast service when changes associated with the service / system occur in a broadcast system supporting the mobile broadcast service, or there is a need to notify emergency situation. In addition, an exemplary embodiment of the present invention provides a method for delivering a notification message regardless of whether or not the terminal is receiving a service. In the following description, a mobile communication system supporting a mobile broadcast service is referred to as a “mobile broadcast system”.

For clarity and brevity, after an exemplary embodiment of a mobile broadcast system is presented, a notification message format according to exemplary embodiments of the present invention and a mobile broadcast system to which a message format is applied is described. Next, a description is given of a device and method for generating and transmitting a notification message in a mobile broadcast system according to an exemplary embodiment of the present invention. The first exemplary embodiment is described with reference to the broadcast system defined in the Third Generation Partnership Project (3GPP), which is a standardization group for asynchronous mobile communications, or the Open Mobile Alliance (OMA), which is a standardization group of terminal applications. A second exemplary embodiment is described with reference to a digital video broadcast convergence system for broadcast and mobile transmission services (DVB-CBMS) defined by another group of standards for mobile broadcasting.

The following is a description of a mobile broadcast system according to a first exemplary embodiment to provide an understanding of an alert message. Although the names of objects used in the OMA mobile broadcast system are used in the first exemplary embodiment, the use of names and the OMA standard should not limit the scope of exemplary embodiments of the present invention, and the first exemplary embodiment can be applied to any system having a similar level technicians.

FIG. 1 is a diagram illustrating a functional architecture for transmitting a notification message in a mobile broadcast system according to a first exemplary embodiment of the present invention. The system shown in FIG. 1 is defined by the OMA BAC BCAST, one of the standardization groups for mobile broadcast terminals, by the working group on broadcasting and viewing mobile content of the OMA BAC BCAST. Although an exemplary embodiment of the present invention is described with reference to the OMA BCAST broadcast notification architecture, it can also be applied to another mobile broadcast system having a function of transmitting alert messages from Internet Protocol (IP) broadcast systems, and this exemplary embodiment implementation does not limit the scope of an exemplary embodiment of the present invention. In addition, an exemplary embodiment uses a “service guide” as information including, for example, a description associated with receiving a broadcast service and a method for receiving a BCAST system. An “access fragment” is also used as information including a method for accessing a broadcast service. The terms “service guide” and “access fragment” can be defined as various terms according to the type of broadcast system.

Referring to FIG. 1, the content creation unit 101 is a broadcast service provider (hereinafter referred to as a BCAST service). A BCAST service may include a traditional audio / video broadcasting service, a file download service (music files or data files), and the like. If there is any problem in providing the BCAST service or any changes to the content of the service, the content creation unit 101 notifies of a change to the notified event function (NTE) 102-1 in the BCAST service application 102.

The BCAST service application 102 has a function of receiving data for the BCAST service provided from the content creating unit 101, processing the received data in a form suitable for the broadcast network, and generating the BCAST service data. The BCAST service application 102 also has the function of generating standardized metadata necessary for managing mobile broadcasts. In addition, the BCAST service application 102 receives the change to the BCAST service notified by the content creation unit 101 and notifies the change to the alert generation function 104-1 located in the BCAST subscription control unit 104.

The BCAST service distribution / adaptation unit 103 has the function of establishing a unidirectional channel for transmitting the BCAST service data provided from the BCAST service application 102, a function for determining a transmission schedule for the BCAST service, and a function for generating a mobile broadcast guide. The BCAST service distribution / adaptation unit 103 is connected to a distribution broadcasting system (BDS) 106 capable of providing a BCAST service, or an interaction network 107 supporting interworking communication. In addition, the BCAST service distribution / adaptation unit 103, including the alert distribution / adaptation function (NTDA) 103-1, receives the notification message from the BCAST subscription management unit 104 and transmits the notification message to one or a plurality of users via the BDS 106 or the network 107 interactions.

The BCAST subscription management unit 104 controls subscription information for receiving the BCAST service, service provisioning information, and device information for the device receiving the BCAST service. In particular, the BCAST subscription control unit 104, since it includes an alert generation function 104-1, generates an alert message using the alert event information received from the content creation unit 101 or the BDS 106, or generates an alert message for the BCAST- event services.

The BDS service distribution unit 105 has a function of distributing all received BCAST services through a broadcast channel or an interaction channel. The BDS service distribution unit 105 is an object that may or may not be present according to the type of BDS 106 implemented.

BDS 106 is a network for transmitting BCAST services, and it can be, for example, DVB-H, 3GPP Broadcast and Multicast Service (MBMS), 3GPP2 Broadcast and Multicast Service (BCMCS), and the like. In addition, if there is a change in the transmission of a particular BCAST service, if an X-1 interface 131 or a BDS service distribution unit 105 exists, the BDS 106 notifies the change to the BCAST service distribution / adaptation unit 103 by NT-B1- interface 124.

The interaction network 107 transmits BCAST services on a point-to-point basis, or interactively exchanges control information and additional information related to receiving BCAST services, and may, for example, be an existing cellular network.

Terminal 108 allows reception of a BCAST service and may have a function of accessing a cellular network according to its characteristics. It is assumed here that terminal 108 is a terminal capable of accessing a cellular network. The terminal 108 receives the alert message transmitted via the NT-5 interface 125 using the alert client function (NTC) 108-1, and performs the corresponding operation according to the received alert message. Alternatively, the terminal 108 receives the alert message transmitted via the NT-6 interface 126 and performs the corresponding operation according to the received alert message.

The following is a description of the interfaces between the above objects.

NT-1 interface 121 is the interface between the alert event function 102-1 located in the BCAST service application 102 and the content creation unit 101. The NT-1 interface 121 is used to deliver the corresponding alert event to the alert event function 102-1 when an alert event occurs at the content creation unit 101.

The NT-3 interface 122 is an interface between the alert event function 102-1 located in the BCAST service application 102 and the alert generation function 104-1 of the BCAST subscription control unit 104. The NT-3 interface 122 delivers the information required to notify of an event or to generate an alert message so that the alert generation function 104-1 can generate an alert event.

The NT-4 interface 123 is the interface between the alert generation function 104-1 located in the BCAST subscription control unit 104 and the alert distribution / adaptation function 103-1 for the BCAST service distribution / adaptation unit 103. The NT-4 interface 123 is used to transmit the notification event to the alert distribution / adaptation function 103-1 to transmit the alert message generated in the alert generation function 104-1 to the BDS 106 or the interaction network 107. Instead, the NT-4 interface 123 can be used by the alert distribution / adaptation function 103-1 to transmit an alert message for an event that occurs in the BDS 106.

The NT-5 interface 125 is an interface used when an alert message provided from the alert distribution / adaptation function 103-1 for the BCAST service distribution / adaptation unit 103 is directly transmitted to the terminal 108 via a broadcast channel through the BDS 106. NT -5 interface 125 is used to transmit an alert message to one or multiple terminals.

NT-6 interface 126 is an interface used when an alert message provided from alert distribution / adaptation function 103-1 for BCAST service distribution / adaptation unit 103 is directly transmitted to terminal 108 via a dedicated channel to terminal 108 via network 107 interaction or through a broadcast channel provided by the interaction network 107. An NT-6 interface 126 is used to transmit an alert message to one or multiple terminals 108.

The NT-B1 interface 124 is the interface between the BCAST service distribution / adaptation unit 103 and the BDS service distribution unit 105, and it is used as the transmission path of the BCAST service distribution / adaptation unit 103 in the BDS 106 or as the information receiving path events generated in BDS 106.

The X-1 interface 131 is an interface used as a transmission path that the BCAST service distribution / adaptation unit 103 should use in the BDS, or it is used as the event information reception path generated in the BDS 106 when the BDS distribution unit 105 -service is missing. However, when the BDS service distribution unit 105 exists, the X-1 interface 131 is used as an interface between the BDS 106 and the BDS service distribution unit 105 to notify that an event has occurred in the BDS 106.

The X-2 interface 132 is an interface used to establish a transmission path that the BCAST service distribution / adaptation unit 103 should use in the interaction network 107 when the BDS service distribution unit 105 is not available. However, when the BDS service distribution unit 105 exists, the X-2 interface 132 is used as the interface between the BDS 106 and the interaction network 107 to establish a unidirectional channel in which the notification event should be used on the interaction network 107, as well as to send an event to alert.

The X-3 interface 133, the interface between the BDS 106 and the terminal 108, is used for the BCAST service or all messages transmitted over the broadcast channel.

The X-4 interface 134 is a broadcast channel interface between the BDS service distribution unit 105 and the terminal 108.

The X-5 interface 135 is the interface of the communication channel between the BDS service distribution unit 105 and the terminal 108.

The X-6 interface 136 is an interaction interface through which the interaction network 107 can transmit control information associated with a BCAST service.

The alert event function 102-1 has a function of providing the information required to generate an alert message through the alert generation function 104-1, and upon detecting the occurrence of an alert requiring an event, provides event information to the alert generation function 104-1. The alert generation function 104-1 generates an alert message using the information and event required to generate the alert message received from the alert event function 102-1. When the alert generation function 104-1 receives an alert event from the BDS 106 through the alert distribution / adaptation function 103-1, it generates an alert message and transmits the alert message to the alert distribution / adaptation function 103-1. In the process of generating an alert message, if there is a need to re-indicate the start of the service, the alert generation function 104-1 receives an alert indicating a change in the service information from the content creation unit 101. Therefore, one case is specified when there is a need to transmit a new mobile broadcast guide, and another case when a specific event occurs in the BDS 106.

The alert distribution / adaptation function 103-1 serves to transmit an alert message via an NT-5 interface 125 or an NT-6 interface 126, and also to deliver an alert event indicating a change in information on a particular mobile broadcast service from BDS 106 to the function 104-1 of generating alerts on the NT-4 interface 123. In this case, a change in the information on the broadcast service may include, for example, adjusting the data rate or the inability to provide the service due to wireless Water network environment.

Before a detailed description of a method for receiving an alert message is provided, the types of alert messages are first described.

An alert message can roughly be divided into two types.

The first alert message is a general alert message that is delivered to all users for general purposes. This alert message is used by the service provider to provide information to broadcast failures or system changes to users.

The second alert message is a specific alert message that is limited to a particular service. This alert message is only transmitted to users receiving the corresponding service and is used to indicate the change and the start of the service.

The following is a description of the transmission of the general alert message or the first alert message.

The ServiceGuideDeliveryDescriptor (SGDD), or service guide delivery message, according to an exemplary embodiment of the present invention is explained below. A general alert message according to an exemplary embodiment of the present invention is shown in Table 1 and Table 2 below. Table 1 and Table 2 illustrate the elements and attributes of the ServiceGuideDeliveryDescriptor (SGDD) used for OMA broadcast. For convenience, table 1 and table 2 are separated from one table.

Table 1 Name Type of Category Amount of elements Description ServiceGuideDeliveryDescriptor E M 1 ... N Service Guide Delivery Descriptor DescriptorEntry E1 M 1 ... N An entry in the delivery descriptor of the service guide. Transport E2 M one A pointer to a transport session delivering fragments of the service guide as part of the service guide delivery modules specified in this DescriptorEntry. Ipaddress A M one The IP address of the target delivery session. Port A M one Port of the target delivery session. Sessionid A M one ID of the target delivery session. AlternativeAccessURL E2 O 0 ... N An alternate URL for retrieving service guide delivery modules through an interaction channel. ServiceGuideDeliveryUnit E2 M 1 ... N Group of fragments. transportObjectID A O 0 ... 1 The identifier of the transport object of the service guide delivery module that carries the advertised fragments within this fragment group. validFrom A M one The first point in time when this group of fragments of the service guide is valid. The format is NTP. validTo A M one The last point in time when this group of fragments of the service guide is valid. The format is NTP.

table 2 Name Type of Category Amount of elements Description Fragment E3 M 1 ... N Announcement of a fragment of a service guide that is available on a broadcast channel. Fragmentid A M one ID of the advertised snippet of the service guide. Fragmentmentersion A M one Version of the announced snippet of the service guide.
Note. The scope of the FragmentVersion is limited to the specified transport session. The value of FragmentVersion changes from 2 ^ 32-1 to 0. Type A M one An enumerated value indicating the schema or MIME type for the fragment. When the most significant bit == 1, the user-defined type is allowed. NotificationEntry E1 M one The entry for the alert message in the delivery descriptor of the service guide. NotificationPort A M one Alert message delivery port. NotificationAddress A O one Alert message delivery IP address.

The terms used in table 1 and table 2 are described below. “Name” means the names of the element values and attribute values that make up the corresponding message. "Type" indicates whether the corresponding name matches the element value or attribute value. The element value has the values E1, E2, E3 and E4. E1 means the value of the top element for the entire message, E2 means the value of the child element E1, E3 means the value of the child element E2, and E4 means the value of the child element E3. The attribute value is indicated by A, and A means the attribute value of the corresponding element. For example, A according to E1 means the value of the attribute E1.

A "category" is used to indicate whether the corresponding element value or attribute value is mandatory, and has a value of M if the value is mandatory and a value of O if the value is optional. "Number of elements" means the relationship between the elements, and has the meanings "0", "0 ... 1", "1", "0 ... n", "1 ... n", where 0 means an optional relationship, 1 means a mandatory relation, and n means the possibility of having multiple values. For example, "0 ... n" means the possibility that there is no corresponding element value or that there are n corresponding element values.

Description describes the meaning of the corresponding value of an element or attribute.

Referring to Table 1, illustrated are the elements and attributes of a ServiceGuideDeliveryDescriptor (SGDD) used for OMA broadcast. Before describing SGDD, a service guide (SG) is described. A service guide is used to indicate what service is currently being provided to a user in a mobile broadcast system. The information provided through the service manual may include information on the service itself, information on purchasing the service, information on receiving the service, and information on the service provider and communication system.

The service guide consists of several fragments according to the characteristics of the information provided in it. Therefore, in order to configure one complete service guide, many fragments must be accepted. The purpose of SGDD is to provide information on the transmission schedule and transmission channels of a plurality of fragments, thereby allowing the terminal designated to receive fragments of the service guide to efficiently receive fragments of the service guide.

Referring to table 1 and table 2, DescriptorEntry provides information available for receiving arbitrary fragments of a service guide in SGDD, and there may be multiple DescriptorEntry.

Transport contains the position information for the transport session for the delivery of the service guide and is specified through the following three attributes. The IPAddress attribute, one of the attributes of the Transport element, indicates the Internet Protocol (IP) address of the transport session. The Port attribute, one of the attributes of the Transport element, indicates the port number of the transport session. The SessionID attribute, one of the attributes of the Transport element, indicates the transport session identifier (ID).

AlternativeAccessURL, when it is not possible to receive fragments of the service guide through the broadcast channel in the channel indicated by DescriptorEntry, indicates the position where it is possible to receive fragments of the service guide so that the mobile broadcast terminal can receive fragments of the service guide through the interaction network 107, and AlternativeAccessURL indicated by a universal information resource indicator (URL).

ServiceGuideDeliveryUnit indicates a package of several pieces of data that make up the service guide, and consists of 3 available attributes and many elements. The number of elements in ServiceGuideDeliveryUnit is a proportion of the number of data fragments. TransportObjectID, one of the attributes of the ServiceGuideDeliveryUnit element, specifies the object identifier for the delivery of the service guide. ValidFrom, one of the attributes of the ServiceGuideDeliveryUnit element, indicates the valid start time for the corresponding piece of data in the service guide. ValidTo, one of the attributes of the ServiceGuideDeliveryUnit element, indicates the valid end time for the corresponding piece of data in the service guide.

Fragment is an element owned by ServiceGuideDeliveryUnit, and many Fragment can exist. Fragment, which is an information fragment for the currently available service guide, has 3 attributes. FragmentID, one of the attributes of the Fragment element, indicates the identifier of the information fragment. FragmentVersion, one of the attributes of the Fragment element, indicates version information of the information fragment. Type, one of the attributes of the Fragment element, specifies the schema or type of Multipurpose Internet Email Extensions (MIME) for the information fragment.

The NotificationEntry element has two attributes: NotificationPort and NotificationAddress. NotificationPort and NotificationAddress indicate information about the channel through which the terminal can receive the general notification message. Most mobile broadcasts discuss the use of IP as a data technology. If the way the terminal can receive the general notification message assuming that IP is used, provides information on the IP address at which the general notification message should be delivered, and provides information on the user datagram protocol (UDP) port number under the assumption that If UDP is used over IP, the terminal can receive a general alert message. The reason for using UDP is as follows. Although other transport protocols, such as TCP, can also be used, the UDP transport header has less overhead and does not support acknowledgment, so the UDP transport protocol is suitable for unidirectional broadcast service characteristics. NotificationPort has the UDP port number previously allocated so that the network provider or service provider uses the UDP port number when it sends a general notification message. The terminal receiving the message transmitted via the UDP port indicated for using the general notification message can immediately detect the corresponding packet as a general notification message and process the packet because it knows the UDP port for the general notification message via SGDD.

The alert function 102-1 or the alert propagation / adaptation function 103-1 of FIG. 1 is available as an object for generating a delivery message to deliver a general alert message. A device for generating a delivery message has information on all sessions where the service is currently being transmitted. Those. You can attach a general alert message to an existing transport session without creating a separate transport session.

The basic session identification module consists of an IP address, and the general alert message uses the IP address of the current session. If the mobile broadcast system delivers a general alert message through the current IP session by simply distinguishing the UDP port, the terminal can immediately receive the general alert message without the need to separately monitor the session. NotificationPort can be used when the terminal receives a mobile broadcast service and wants to deliver a general alert message via an IP stream (or IP transport path) where the mobile broadcast service is transmitted.

NotificationAddress is used when it is intended to allocate a special IP address during the delivery of a general notification message and deliver a general notification message through a stream (or transport path) having an IP address. NotificationAddress provides an IP address to deliver a general alert message to a terminal receiving a mobile broadcast service, or inactive mode terminals not receiving a mobile broadcast service to save power. A terminal designated to receive a general notification message has information on NotificationPort and NotificationAddress and receives a general notification message, since an entity wishing to deliver a terminal status or a general notification message sets the reception address of the general notification message.

The following is a description of a method for delivering an SGDD message using the system of FIG. 1 as a mobile broadcast system according to an exemplary embodiment of the present invention.

FIG. 2 is a flowchart illustrating a method for generating and transmitting SGDDs according to an exemplary embodiment of the present invention.

Referring to FIG. 2, the BCAST service distribution / adaptation unit 103 indicates SGDD elements and attributes to be delivered to the terminal 108 in step 201. In step 201, NotificationEntry, NotificationPort, and NotificationAddress values are indicated according to an exemplary embodiment of the present invention. In this case, the SGDD elements and attributes are predetermined in accordance with the broadcast provider or the system environment. After step 201, the BCAST service distribution / adaptation unit 103 generates SGDD in step 202. Then, the BCAST service distribution / adaptation unit 103 transmits the generated SGDD to the terminal 108 in step 203. Although the indication and generation of SGDD is performed here by the BCAST- distribution / adaptation unit 103 services, it can also be carried out by the function 102-1 events for alerts.

FIG. 3 is a flowchart illustrating a method for receiving SGDDs by terminal 108 in a mobile broadcast system according to an exemplary embodiment of the present invention.

According to FIG. 3, terminal 108 executes the broadcast service upon user request in step 301 and determines in step 302 whether there is a service guide (SG) in terminal 108 to display the service guide for the user. If there is a previously accepted service guide in step 302, the terminal 108 displays the service guide on the display in step 306. However, if there is no service guide, the terminal 108 receives the SGDD transmitted from the BCAST service distribution / adaptation unit 103 to step 303.

In step 304, the terminal 108 receiving the SGDD decrypts the SGDD to receive information for receiving the service guide, and establishes the reception of the service guide using the received information. In particular, in an exemplary embodiment of the present invention, the terminal 108 receives the NotificationEntry, NotificationPort, and NotificationAddress values required to receive the general notification message, in addition to the general settings. Then, the terminal 108 immediately receives the service guide at step 305. After receiving sufficient service guide data, the terminal 108 displays the received service guide on its display to the user at step 306.

A terminal 108 receiving an SGDD establishes a reception for broadcast and then receives a broadcast. Then, the terminal 108 exchanges a general alert message during the reception of the broadcast, and the broadcast system for messaging is described below.

FIG. 4 is a block diagram illustrating a broadcast system for transmitting a general alert message in a mobile broadcast system according to an exemplary embodiment of the present invention. A detailed structure of the alert distribution / adaptation function 103-1 and the alert client function 108-1 of FIG. 1 is illustrated in the drawing. The client alert function 108-1, one functional block of terminal 108, may be considered as terminal 108.

Referring to FIG. 4, the alert distribution / adaptation function 103-1 serves to deliver a general alert message to a terminal or group of terminals, and includes an UDP packet generator 402 and an IP packet generator 403. The UDP packet generator 402, if there is a general alert message delivered from the alert event function 102-1, generates a UDP packet using the alert port previously sent to the terminal via SGDD, and then delivers the generated UDP packet to the IP generator 403 packages. In this case, the notification port is the value specified in the NotificationPort received through SGDD. The reason that the general alert message is immediately entered into the UDP layer is because when transport protocols of the other higher layers are used, the size of the protocol headers is larger than the size of the message to be transmitted, thereby reducing efficiency.

The IP packet generator 403 generates a packet using the IP address of the current running session when receiving an alert indicating the UDP packet transmitted from the UDP packet generator 402. Although you can send a general alert message simply by using the UDP port number, as described above, there is a need for a separate IP session to wake up the terminal from the standby state and allow the terminal to receive the general alert message. This is because the terminal, when woken up from the idle state, does not have a running session. When considering this situation, the IP packet generator 403 not only generates a packet for the IP address of the currently running session, but also generates a packet using the IP address of the NotificationAddress and transmits the generated packet.

The generated IP packets are transmitted to the notification client function 108-1 via a distribution broadcast system or interaction network 404. Moreover, the distribution broadcasting system or the interaction network 404 is shown in a single block for convenience. Those. the selection of device 404 is performed in accordance with the broadcast provider or system environment.

The client alert function 108-1 decrypts the general alert message by decapsulating the IP packet data transmitted from the alert distribution / adaptation function 103-1. Therefore, the client alert function 108-1 includes an IP packet decoder 406, UDP packet decoder 407, and a general alert message decoder 408.

The IP packet decoder 406 determines whether the IP packet received by the distribution broadcast system or the interaction network 404 corresponds to the current session in progress, or if the receiving address of the general notification message is indicated. Those. if the IP packet matches NotificationAddress, the IP packet decoder 406 generates a UDP packet by decapsulating the IP header and delivers the generated UDP packet to the UDP packet decoder 407. However, if the IP packet does not match NotificationAddress, the IP packet decoder 406 discards the corresponding packet.

The UDP packet decoder 407 delivers the UDP packet provided from the IP packet decoder 406 to the upper layer only when the UDP packet corresponds to the current session in progress. However, when the received UDP packet previously had a general notification message port number generated by NotificationPort for SGDD, the UDP packet decoder 407 delivers the received UDP packet to the general notification decoder 408 without decapsulating the received UDP packet and delivering it to the upper level. The general alert message decoder 408 receives the unpacked packet to decrypt the general alert message, and determines the future operation of the terminal according to the decryption result. Decoder 408 messages General alerts can also be implemented in the controller.

With reference to FIG. 5, a description will now be made of a method for transmitting a general alert message according to an exemplary embodiment of the present invention.

FIG. 5 is a flowchart illustrating a process for transmitting a general alert message in a mobile broadcast system according to an exemplary embodiment of the present invention.

Referring to FIG. 5, the BCAST service distribution / adaptation unit 103 receives the general alert message containing the contents of the alert from the event function 102-1 for the notification in step 501. At step 502, the BCAST service distribution / adaptation unit 103 then generates a UDP packet using the specific UDP port and the received general alert message. The format of the general notification message, since it is transmitted at the level of the service provider, is not directly related to the transmission, so that the corresponding general notification message is immediately generated in a UDP packet.

Meanwhile, it is possible to standby terminals that are connected to the interaction network 107, as shown in FIG. 4, or they may receive a paging message after receiving a received general notification message, but the broadcast receiver is disabled. Therefore, the terminal 108 in this state should “wake up” the standby broadcast receiver (not shown) by making a paging using the interaction network 107 or another method. To this end, the BCAST service distribution / adaptation unit 103 generates a paging message to wake up the broadcast receiver in standby mode at step 504 and sends a call message through the interaction network 107 or another method at step 505, thereby waking up the terminal broadcast receiver .

A packet for transmitting a general alert message is generated using the previously specified UDP port number, i.e. NotificationPort, for using alert delivery. This serves to enable terminal 108 to recognize the received packet as a general alert message. At step 503, the generated UDP packet is formed into an IP packet using the IP address of the current session in progress or the IP address for delivery of the general notification message, i.e. NotificationAddress. The alert distribution / adaptation function 103-1 may obtain the IP address of the current session in progress because it is controlled by the party to transmit the services in the BCAST service distribution / adaptation 103. The generated IP packets are delivered to the lower layer transmitting device. In this case, the general alert message may be re-delivered to the lower level transmitter several times according to the needs of the network provider or service provider, given the situation in which there is packet loss or packet reception may fail.

FIG. 6 is a flowchart illustrating a process for receiving a general alert message in a client alert function 108-1 of a mobile broadcast system according to an exemplary embodiment of the present invention.

Referring to FIG. 6, in step 601, the notification client function 108-1 receives the received IP packet and decrypts the IP packet header. The notification client function 108-1 determines in step 602 whether the IP address of the packet is identical to the IP address of the current session in progress as a result of decryption of the header. The reason for performing the IP check is that the notification client function 108-1 does not need to receive a packet that is irrelevant for the current session in progress. Therefore, if the IP header address is different from the address of the current session in progress as a result of the IP check, the client notification function 108-1 discards the currently received packet in step 606.

However, if the address of the received IP packet is identical to the IP address of the currently running session, the notification client function 108-1 proceeds to step 603, where it decrypts the UDP packet header obtained by unpacking the IP packet. Then, the notification client function 108-1 determines in step 604 whether the UDP port number obtained by decrypting the UDP packet header is the specified UDP port by determining that it is identical to the port number predetermined by SGDD, as shown in FIG. 3. I.e. the notification client function 108-1 determines whether the received packet is a general notification message or a packet of a general broadcast session.

If it is determined in step 604 that the port number of the received UDP packet header is identical to the UDP port number intended to receive the general notification message, the notification client function 108-1 unpacks the received UDP packet to open the working data of the general notification message, and decrypts the corresponding message to perform the desired operation at step 605. However, if the port number of the received UDP packet is different from the predetermined UDP port number, the notification client function 108-1 proceeds to step 607, on which it processes the received UDP packet, considering it as a packet of an existing broadcast session.

FIG. 7 is a flowchart illustrating a process for receiving a general alert message in a notification client function 108-1 when it is connected to an interaction network 404 or a system having a standby terminal of a mobile broadcast system according to an exemplary embodiment of the present invention.

Referring to FIG. 7, in step 701, the notification client function 108-1 receives the paging message according to the block of the interaction network 404 or the paging block or another method. At step 702, the client alert function 108-1 activates a standby broadcast receiver by means of a paging message and prepares for reception. Preparing to receive includes forming a session using NotificationPort and NotificationAddress, transmitted via SGDD, and switching to ready mode. At 703, the client alert function 108-1 in standby mode decrypts the header of the received IP packet after receiving the IP packet from the alert distribution / adaptation function 103-1.

The notification client function 108-1 determines, at step 704, whether the IP packet address is identical to the IP address for the general notification message specified from the NotificationAddress obtained by SGDD. If it is determined that the address in the IP packet header is different from the address in NotificationAddress, the notification client function 108-1 discards the packet in step 708. However, if the IP packet IP address is identical to the NotificationAddress IP address, client function 108-1 alerts decrypts the header of the UDP packet obtained by unpacking the IP packet at step 705.

After that, the notification client function 108-1 determines at step 706 whether the UDP port number obtained by decrypting the UDP packet header is identical to the NotificationPort UDP port number obtained by SGDD. Step 706 is performed to determine if the received packet is a general notification message or an incorrectly transmitted packet.

If it is determined at 706 that the port number of the received UDP packet header is identical to NotificationPort, i.e. to the UDP port number intended to receive the general notification message, the notification client function 108-1 unpacks the received UDP packet to open the operational data of the general notification message and decrypts the corresponding message to perform the desired operation, at step 707. Thereby however, if the port number of the received UDP packet is different from the NotificationPort port number, the notification client function 108-1 discards the received UDP packet at step 708, considering it to be an incorrectly received UDP packet.

The following is a description of a specific alert message or a second alert message.

FIG. 8 is a diagram illustrating a data model architecture in a service guide offered for mobile broadcasting in OMA BAC BCAST, one of the standard groups for mobile broadcasting technology. In FIG. 8, each line connecting fragments represents a reciprocal link to each corresponding fragment.

Referring to FIG. 8, one service guide consists of fragments having their own unique object, and is divided into 4 large groups according to use.

Administrative group 800, a group for providing basic information available for receiving a service guide, consists of ServiceGuideContext 801 and ServiceGuideDeliveryDescriptor 802. ServiceGuideContext 801 provides the identity of the service provider that generated and transmitted the service guide identifier and service guide, and general information service guide. ServiceGuideDeliveryDescriptor 802 provides the terminal with information capable of receiving a plurality of fragments of the service guide, as well as scheduling information and update information for the channel, so that the terminal can only receive the necessary service guide at the appropriate time.

The service provisioning group 810, a group for providing information on payment for the reception of services, consists of Purchase Item 811, Purchase Data 812, and Purchase Channel 813. Purchase Item 811 provides information on payment for services or a service package, and Purchase Data 812 provides information indicating how the user of the service can pay. Purchase Channel 813 provides information on a system from which a service user can actually acquire a service.

The base group 820, a group for providing information about the service itself, consists of Service 821, Schedule 822, and Content 823. Service 821 provides a description of the service itself that the user should receive and information indicating how the service can be configured. Schedule 822 provides information on the time at which a service can be provided and used. Content 823 provides information on each of the many content options that make up the service.

The access group 830 consists of Access 831 and Session Description 832 and provides service access information indicating how to receive the services of the base group 820, as well as detailed information on the session in which the content constituting the service is transmitted to enable the terminal access the service. Access 831 provides the terminal with multiple access methods for a single service, in order to provide a way in which the terminal can access several additional services based on one service. Session Description 832 provides session information for a service transmitted by accessing a service specified in a single access fragment.

In addition to the 4 groups, there is an 824 Preview Data fragment, and an 824 Preview Data fragment provides thumbnails and icons for the service and content.

Tables 3-11 illustrate the detailed contents of the access fragment currently defined in OMA BCAST.

Table 3 Name Type of Category Amount of elements Description Data type Access E O 0 ... N Fragment of access.
Contains the following attributes:
- id
- version
- validFrom
- validTo
- ServiceProtection
- AudioLanguage
Contains the following subordinate elements:
- AccessType
- ExtensionURL
- ServiceIDRef
- ScheduleIDRef
- UsageInfo
- AlternativeAccessURL
- TerminalCapabilityRequirement
- BandwidthRequirement
- ApplicationSpec
- MediaInformation id A M one Access fragment identifier globally unique. anyURI version A M one Version of this snippet. A newer version overrides the older one as soon as it is accepted. unsignedInt (32 bits) validFrom A O 0 ... 1 The first moment when this fragment is valid. If not provided, it is assumed that validity started some time ago. Integer (32 bits), expressed as NTP time

Table 4 Name Type of Category Amount of elements Description Data type validTo A O 0 ... 1 The last moment when this fragment is valid. If not provided, it is assumed that validity ends at an undetermined time in the future. Integer (32 bits), expressed as NTP time ServiceProtection A O 0 ... 1 If true, this indicates that the access associated with the associated service is protected by OMA BCAST Service Protection; if false, this indicates that this access associated with the associated service is not protected by OMA BCAST Service Protection. Boolean AudioLanguage A O 0 ... 1 This attribute describes the language used in the audio stream if the access type refers to A / V access.
Note. Language information can be provided for each audio stream in the SDP, which describes all language options. But current multimedia players do not offer an API for language selection. Language AccessType E1 M one Specifies the type of access.
Contains the following attribute:
- TransmissionMedia
Contains the following elements:
- BroadcastTransmission
- InteractiveTransmissionScheme

Table 5 Name Type of Kate
goria Amount of elements Description Data type TransmissionMedia A M one This attribute indicates which channel is used to provide the service:
0 - broadcast channel
1 - interaction channel Integer Broadcast
Transmission E2 O 0 ... 1 This item is used to indicate IP transmission.
Contains the following attribute:
- ipaddress
Contains the following elements:
- SessionDescriptionReference
- SDP Ipaddress A O 0 ... 1 The IP address of the receiver of the IP stream that transports the service over the broadcast channel.
Note. This attribute is used when SDP is not included in the access fragment.
If the SDP in the access fragment exists, the IP address of the receiver in the SDP is used. String

Table 6

Name Type of Category Amount of elements Description Data type SessionDescriptionReference E3 O 0 ... 1 Link to the SessionDescription to which this access belongs.
Note. SessionDescription itself can be delivered in two ways through broadcast or through sampling on the interaction channel.
In the case of broadcast delivery, the SessionDescription is either delivered to the SGDU or encapsulated in this access fragment. In the second case, this element is not used, and instead the SDP element is used.
In the case of sampling on the interaction channel, SessionDescription can be obtained by accessing the URI (specified as an attribute of this element).
Attributes:
- Type
- URI
- id SessionDescriptionReference

Table 7

Name Type of Category Amount of elements Description Data type Type A M one The type of session description indicated by this SessionDescriptionReference:
1 - SDP 2 - MBMS description of the user service (MBMS-USD), as indicated in [26.346] section 5.2. It may contain one or more SDP descriptions. Integer URI A O 0 ... 1 URI to a file containing SessionDescription, which the multimedia application in the terminal uses in order to access the service. Any URI idRef A O 0 ... 1 The SessionDescription fragment identifier referenced by this access is globally unique. Any URI SDP E3 O 0 ... 1 Session Description in SDP (IETF Session Description Protocol). String (in SDP format) Interactive
TransmissionScheme E2 O 0 ... 1 This element indicates which communication system or protocol is used for the communication channel.
Contains the following attribute:
- TansmissionSchemeType
Contains the following elements:
- AccessServerIPaddress
- AccessServerURL
- AccessServerPhoneNumber

Table 8

Name Type of Category Amount of elements Description Data type TransmissionSchemeType A M one 1 - interaction channel provided through the interaction network
2 - MMS
3 - WAP 1.0
4 - WAP 2.x
5 - SMS
6 - HTTP Integer 7 - voice call
8 - transmission scheme defined by the service provider
Note. Another protocol or communication system may be added based on the OMA service interworking function. AccessServerIPaddress E3 O 0 ... N The IP address of the server that provides other access (via the interaction channel) of the service. String Access server
URL E3 O 0 ... N The URL of the server that provides other access (via the interaction channel) of the service. anyURI AccessServerPhoneNumber E3 O 0 ... N The telephone number of the server that provides other access (via the interaction channel) of the service.
Note. MMS and SMS use a phone number as an address. Integer ExtensionURL E1 O 0 ... N A URL containing additional information related to this snippet on a web page. The terminal may retrieve additional information by accessing this URL. anyURI

Table 9

Name Type of Category Amount of elements Description Data type ServiceIDRef E1 O 0 ... N Link to the service fragment (s) to which this access fragment belongs.
Any one of ServiceIDRef and ScheduleIDRef, but not both, MUST be specified. Note. XML implementation anyURI schema using <choice>.
Each service fragment MUST be associated with at least one access fragment in order to provide terminal access to the service. ScheduleIDRef E1 O 0 ... N Link to the schedule fragment (s) to which this access fragment belongs.
It provides a link to a schedule snippet to temporarily override the default service access snippet specified by the schedule.
Any one of ServiceIDRef and ScheduleIDRef, but not both, MUST be specified. Note. Implementation in an XML Schema with <choice>. anyURI Usageinfo E1 O 0 ... N This text helps the user understand the difference in using one or the other access fragment. In this case, it is imperative that more than one access fragment is available at a given time.
Available in several languages. The language is expressed using the xml: lang built-in XML attribute using this element. String

Table 10

Name Type of Category Amount of elements Description Data type AlternativeAccessURL E1 O 0 ... N Specifies an alternative content URL for retrieving it through an interaction channel if the content cannot be retrieved through the broadcast channel. For example, due to poor-quality radio environment, either the terminal is outside the service area. anyURI Terminalcapability
Requirement E1 O 0 ... 1 A specification of the required terminal characteristics for this access, such as protocols, codecs, bit rate, processing, storage;
UAprof is used to express characteristics. String Bandwidthrequirement E1 0 0 ... 1 The specification of the required network bandwidth for access described in this snippet.
A broadcast service may include several available streams (the same content) with different bandwidths, so that the terminal can make a choice depending on the current state of reception. Integer ApplicationSpec E1 O 0 ... N The type of application that can consume a service using this access specification defined by the MIME type. String Mediainformation E1 O 0 ... N An optional link to an icon, icon, animation, or audio. PreviewData or link to PreviewData is used here.
Attributes:
- usage
- idRef

Table 11 Name Type of Category Amount of elements Description Data type Usage A M one Possible values: background, icon (for example) Integer (8 bits) idRef A M one ID of the PreviewData fragment. anyURI <custom elements / attributes> E1 or lower, A O 0 ... N Any number of user-defined or application-specific elements or attributes that are not specified in this specification. NotificationEntry E1 M one The entry for the alert message in the delivery descriptor of the service guide. NotificationPort A M one Alert message delivery port. NotificationAddress A O one Alert message delivery IP address.

The description of the "Category" in Tables 3-11 is identical to its description in Table 1 and Table 2, and a detailed description of Tables 3-11 is disclosed in the description document contained on the website at http://www.openmobilealliance.org/ftp/ Public documents / BAC / BCAST / Permanent documents / OMA-TS-TS-BCAST ServiceGuide-Vl 0 0-20050930-D.zip for OMA, which is fully contained in this document by reference. The referenced document was the latest version at the time this description of the invention was being prepared, and if the document was subsequently updated, an exemplary embodiment of the present invention can be applied to the updated version.

In Tables 3–11, the last three elements are newly defined in this document for the notification specified in Table 1 and Table 2. The NotificationEntry element has two NotificationPort and NotificationAddress attributes. NotificationPort and NotificationAddress indicate information about the channel through which the terminal can receive the notification message. The use of IP as a technology for transmitting data for mobile broadcasting is described below. If the way the terminal can receive the alert message on the assumption that IP is being used, provides information on the IP address at which the alert message should be delivered, and provides information on the UDP port number on the assumption that UDP is used over IP, then the terminal can receive an alert message. The reason for using UDP is as follows. Although other transport protocols such as TCP can also be used, the UDP transport header has less overhead and does not support acknowledgment. Thus, the UDP transport protocol is suitable for unidirectional broadcast service characteristics.

NotificationPort has a UDP port number previously allocated so that the network provider or service provider uses the UDP port number when it sends an alert message for a particular service. The terminal receiving the message transmitted via the UDP port indicated for using the notification message can immediately detect the corresponding packet as the notification message and process the packet because it knows the UDP port for the notification message through the access fragment. Since an access fragment exists for each service, NotificationPort in the access fragment provides the ability to receive an alert message for the corresponding service.

The alert function 102-1 or the alert propagation / adaptation function 103-1 of FIG. 1 is available as an object for generating a delivery message to deliver an alert message. A device for generating a delivery message has information on all current sessions. Those. it is possible to attach an alert message to an alert requiring a transport session, i.e. a session of a particular service connected to an arbitrary access fragment without forming a separate new session. The basic session identification module consists of an IP address, and the notification message uses the session IP address of the ongoing service connected to the access fragment requiring notification. Since the mobile broadcast system delivers the alert message through a specific IP session in progress by simply distinguishing between the UDP ports, the terminal can immediately receive the alert message associated with the current session in progress, without the need to separately monitor the session. NotificationPort can be used when the terminal receives a mobile broadcast service and wants to deliver a notification message through an IP stream (or IP transport path) in which a mobile broadcast service is transmitted.

NotificationAddress is used when it is intended to allocate a special IP address during the delivery of the notification message and deliver the notification message via a stream (or transport path) having an IP address. NotificationAddress provides an IP address to deliver an alert message for a particular service connected to the access fragment to a terminal receiving a mobile broadcast service, or inactive mode terminals not receiving a mobile broadcast service in order to save electricity. The terminal designated to receive the notification message has NotificationPort and NotificationAddress information and receives the notification message, since the object that wants to deliver the terminal status or the notification message sets the receiving address of the notification message.

FIG. 9 is a flowchart illustrating a method of generating and transmitting an access fragment in a mobile broadcast system according to an exemplary embodiment of the present invention.

Referring to FIG. 9, the BCAST service distribution / adaptation unit 103 indicates the elements and attributes of the access fragment to be delivered to the terminal 108, in step 901. In particular, in step 901, NotificationEntry, NotificationPort, and NotificationAddress are indicated according to an exemplary embodiment of the present invention. In this case, the elements and attributes of the access fragment are predefined in accordance with the broadcast provider or the system environment. After step 901, the BCAST service distribution / adaptation unit 103 generates an access fragment in step 902. Then, in step 903, the BCAST service distribution / adaptation unit 103 provides the access fragment generated in step 902 to the terminal 108.

FIG. 10 is a flowchart illustrating a method of receiving and processing an access fragment in a terminal 108 of a mobile broadcast system according to an exemplary embodiment of the present invention.

Referring to FIG. 10, terminal 108 receives the access fragment through its receiver in step 1001. In step 1002, the terminal 108 receiving the access fragment decrypts the access fragment to obtain information available for receiving a particular service associated with the access fragment and sets up the reception of a specific service using the information received. In particular, in an exemplary embodiment of the present invention, the terminal 108 receives the NotificationEntry, NotificationPort, and NotificationAddress values required to receive the notification message, in addition to the general settings.

A terminal 108 receiving an access fragment receives a specific service after a reception is received for a specific service. After that, the terminal 108 transmits / receives the notification message during the reception of a particular service, and the broadcast system for this is described below.

The procedure for delivering an alert message associated with the access fragment is similar to the procedure described in FIG. 5, but the NotificationPort and NotificationAddress used should be values applicable only to the service connected to the access fragment, and not values used for a common purpose. The above values are determined by the service provider or network provider.

The operation of terminal 108 for receiving a notification message for a particular service by means of an access fragment is identical to the operation described in FIG. 6 and 7, so its description is omitted.

FIG. 11 is a diagram illustrating a digital video broadcast convergence network architecture of broadcast and mobile transmission services (DVB-CBMS) according to a second exemplary embodiment of the present invention.

Referring to FIG. 11, a content creation unit (CC) 1101 is a BCAST service provider, and the BCAST service may include an audio / video broadcast service, a file download service (music files or data files), etc. Block 1101 content creation, if there is any problem in the provision of BCAST services or any changes in the content of the service, reports a problem or a change in function 1102a events for notification (NTE) in the application 1102 BCAST services. The alert event function 1102a delivers an alert message event to the alert generation function (NGF) 1103a based on the received event.

The BCAST service application 1102 has a function of receiving content data for a BCAST service provided from the content creating unit 1101, processing the received content data in a form (eg, streaming audio / video or downloading movies) suitable for the broadcast network, and generating data BCAST services. For example, the BCAST service application 1102 has a function for generating standardized metadata required for broadcast guidance, and has a function for generating user billing information. In addition, the BCAST service application 1102 receives the change in the BCAST service notified by the content creation unit 1101, delivers an alert event to the alert generation function 1103a located in the service control (SM) 1103, and provides service guide attribute information used for generating an alert message to alert generation function 1103a.

The service control unit 1103 has a function of determining a transmission schedule of the BCAST service provided from the BCAST service application 1102 and a function of generating a service guide. A service control unit 1103 is connected to a broadcast distribution system 1106 supporting a BCAST service, and an interaction network 1107 supporting interaction communication. In addition, the service control unit 1103 including the alert distribution / adaptation (NTDA) function 1103b receives the alert message from the service control unit 1103 and transmits the alert message to one terminal or group of terminals via the broadcast distribution system 1106 or the interaction network 1107. The service control unit 1103 has session information required by the alert generation function 1103a to generate an alert message for use by the terminal, and the alert distribution / adaptation function 1103b transmits the session information to the alert generation function 1103a.

A service control unit 1103 manages subscriber information for receiving a BCAST service, service provisioning information such as information indicating whether the subscriber has acquired related content, and device information for terminals receiving the BCAST service. Those. a service management unit 1103 provides billing information to users in a BCAST service application 1102. The service control unit 1103 also provides subscription information, service provision information, and device information to the broadcast distribution system 1106 and the interaction network 1107. In particular, the service control unit 1103, since it includes an alert generation function 1103a, generates an alert message for an alert event or generates an alert message for information indicating that the content is provided from the BCAST service when there is an event that has occurred, indicating the addition of a new function or a change in an existing function provided from the content creation unit 1101, the BCAST service application 1102, the service management unit 1103, and the broadcast distribution system 1106 seamless transmission. For example, an alert message may be associated with the event itself, indicating that a corresponding broadcast will be provided after a certain amount of time has passed.

Distribution broadcast system 1106 is a network for transmitting a BCAST service. In this exemplary embodiment, the broadcast distribution system 1106 is based on DVB-H as an example. The broadcast distribution system 1106, if a change occurs during the transmission of the BCAST service, reports the change in the service control unit 1103 via the CBMS-6 interface 1124a or the X-3 interface 1124b.

The interconnect network 1107 transmits BCAST services on a point-to-point basis, or interactively exchanges control information and additional information related to the reception of BCAST services, and may be an existing cellular network, such as a 3GPP code division wideband multiple access network (WCDMA).

Terminal 1108 is a terminal device capable of receiving a BCAST service, and it may have a function of accessing the interaction network 1107 using an interaction channel according to the characteristics of the terminal device. This document assumes that terminal 1108 is a terminal that allows access to a cellular network, as an example of an interoperability network 1107, via X-2 1134. Terminal 1108 receives an alert message transmitted by a client alert function (NTC) 1108a via CBMS- 3-interface 1125, and performs the corresponding operation according to the received alert message. Alternatively, terminal 1108 receives the alert message transmitted via CBMS-4 interface 1126 and performs the corresponding operation according to the received alert message.

The following is a description of the interfaces between the block elements of a mobile broadcast system according to a second exemplary embodiment of the present invention.

CBMS-7 interface 1122, the interface between the alert event function 1102a located in the BCAST service application 1102 and the alert generation function 1103a of the service control unit 1103 transfers information (e.g., service guide attribute information) required to generate the alert or alert messages for the event so that alert generation function 1103a can generate an alert message.

CBMS-5 interface 1125, the interface used when the alert message transmitted from the alert distribution / adaptation function 1103b of the service control unit 1103 is directly delivered to the terminal 1108 via the broadcast channel through the broadcast distribution system 1106, used to transmit the alert message to one or multiple terminals 1108.

CBMS-4 interface 1126, an interface used when an alert message transmitted from the alert distribution / adaptation function 1103b of the service control unit 1103 is directly delivered to the terminal 1108 via a dedicated channel to the terminal 1108 via the interaction network 1107 or via a broadcast channel, provided through the interaction network 1107 is used to transmit an alert message to one or a plurality of terminals 1108.

CBMS-6 interface 1124a, the interface between the service control unit 1103 and the broadcast distribution system 1106, is used as the transmission path to be used by the service control unit 1103 in the broadcast distribution system 1106, or the reception path of event information generated in the system 1106 broadcast distribution.

The X-3 interface 1124b is an interface used to establish a transmission path to be used between the service control unit 1103 and the interaction network 1107.

CBMS-1 interface 1133 is an interface used when a control signal of a broadcast distribution system 1106 is delivered to terminal 1108. For example, in DVB-H, a control signal called program specific information / service information (PSI / SI), corresponds to a control signal.

The X-2 interface 1134 is an interface between the interaction network 1107 and the terminal 1108.

The alert event function 1102a has a function of providing the information required for generating an alert message to the alert generation function 1103a, and upon detecting the occurrence of an alert requiring an event, provides event information to the alert generation function 1103a. The alert generation function 1103a generates an alert message using the information and event required to generate the alert message received from the alert event function 1102a. When the alert event function 1102a receives an alert event from the broadcast distribution system 1106 through the alert distribution / adaptation function 1103b, it generates an alert message and transmits the alert message to the alert distribution / adaptation function 1103b. In the process of generating an alert message, if there is a need to re-indicate the start of the service, the alert generation function 1103a receives an alert indicating a change in the service information from the content creating unit 101, specifying one case when there is a need to transmit a new guide for mobile broadcasting, and another case where a particular event occurs in a broadcast distribution system 1106.

The alert distribution / adaptation function 1103b serves to transmit an alert message via the CBMS-5 interface 1125 or CBMS-4 interface 1126, as well as deliver an alert event indicating a change in information on a particular mobile broadcast service from the distribution system 1106 broadcast to alert generation function 1103a. Moreover, a change in information on a broadcast service may include adjusting the data rate or inaccessibility of the service due to the wireless network environment.

FIG. 12 is a diagram illustrating a data model of an electronic service guide (ESG) in a DVB-CBMS according to a second exemplary embodiment of the present invention.

Referring to FIG. 12, each block represents a piece of ESG data. Those. The ESG data model includes a Service fragment 1202, a Schedule Event fragment 1204, a Content fragment 1206, an Acquisition fragment 1208, a Service Bundle fragment 1210, a Purchase fragment 1212, and a Purchase Channel fragment 1214.

Fragment 1202 Service includes a full description of the service. Fragment 1204 Schedule Event presents information about the service according to time. Fragment 1208 Acquisition includes information access to the service that you need to know in order to receive these services. Fragment 1210 Service Bundle includes information on the occasion when several services are grouped into a single service package. Fragment 1212 Purchase indicates price information for the acquisition of a service package. Fragment 1214 Purchase Channel indicates information on the system that must be used in order to obtain the right to purchase.

Each fragment of the data model can reference other fragments, and the arrow between the fragments represents the relation of the link. The phrase “making a link” refers to a process in which the current fragment provides information associated with it using information delivered from another fragment. Those. when one service consists of several content options, the Service fragment 1202 includes only a complete description of the service, for example, the name and language of the service, but does not include a description of the content transmitted through the service. However, the Content fragment 1206 of the corresponding content makes reference to the Service fragment of the corresponding service. In addition, in order to obtain various information required for receiving a service, for example, session information used for a transmission protocol, the terminal can obtain information by receiving an Acquisition fragment 1208 to which the Service fragment 1202 refers and demodulating the received Acquisition fragment 1208.

ESG data is delivered to the terminal using a separate IP stream at a time different from the time of the actual data stream. Therefore, a service provider can provide information before a service is delivered that a user must receive before accepting the service using the ESG data model. By receiving the ESG stream, the terminal obtains the information required to receive the service provided by the service provider, and when the user selects a particular service, the terminal accesses the data stream, where the service is delivered using the received information, and then receives the data. Information is required by the terminal in order to access the service data stream transmitted by the Acquisition fragment 1208, as described in FIG. eleven.

In the ESG data model, several fragments are packaged and placed in one container, and each container is considered as one object in a FLUTE session during its transfer.

FIG. 13 is a diagram illustrating an operation for delivering an ESG to a DVB-CBMS according to a second exemplary embodiment of the present invention.

Referring to FIG. 13, the transmitter provides channel information of the ESG initialization session 1310 to the terminal via the PSI / SI signal for ESG delivery. The terminal accesses the channel according to the channel information, and then receives the initialization information. The initialization information consists of an ESG provider descriptor 1312 and an ESG access descriptor 1313 (or an ESG initialization descriptor). The file description table instance 1311 (full FDT) is the FDT used in the FLUTE protocol, and it is a table including parameters describing file objects transmitted in the FLUTE session.

The ESG provider descriptor 1312 includes related information, such as the ESG provider identifier, name and logo, and the ESG access descriptor 1313 includes information of the ESG notification channel 1320, information on the number of IP sessions in which the ESG is delivered, and address information IP sessions.

The ESG notification channel 1320 carries the ESG initialization container 1340 and ESG index information, and the information carried by the ESG initialization container 1340 is as follows. Container header 1332 is included. The ESG initialization message 1333 includes a decoder option for decoding the ESG, and the separation information 1334 includes session separation criteria information and channel information of each session when the ESG is transmitted through multiple sessions. Index list 1335 and index structure 1336 include transmission ESG fragments and correspondence information between containers 1340-1-1340-n. Moreover, an instance of 1321 file description table (full FDT) is further included.

An ESG is contained in several containers during its transfer, as shown in FIG. 13, and each container consists of fragment control information indicating information on fragments constituting the corresponding container and ESG fragments.

Before the operation of receiving the notification message according to the second exemplary embodiment is described, the types of notification messages are first described. An alert message can roughly be divided into two types.

The first alert message is a general alert message that is delivered to all users for general purposes. This alert message is used by the service provider to provide information to broadcast failures or system changes to users.

The second alert message is a specific alert message that is limited to a particular service. This alert message is only transmitted to users who accept a particular service and can be used to indicate the change and the start of the service. A specific notification message can also be generated and transmitted separately for each individual specific group of users, and not for each individual service. A “specific user group” may be a group of users formed by subscribing to an alert service, or a group of users formed when the network seeks to deliver an alert message to a specific area. When it is intended to deliver an alert message to a group of users formed by subscribing to a service, it is possible to transmit an alert message on a point-to-point basis, since the information for each subscriber is managed. When there is no intention to deliver the notification message separately to each individual specific zone, the group of users located in this particular zone is not controlled separately.

When receiving / transmitting an alert message, a common flow according to a second exemplary embodiment of the present invention is shown in FIG. 14. As shown in FIG. 14, the present invention generally includes an alert message channel information delivery / receipt operation A (1410), alert message transmission / reception operation B (1420), and operation C (1430), in which the terminal receives and decrypts the alert message and performs operation according to him. Operation A (1410) is described in the second exemplary embodiment, operation B (1420) is described with reference to FIG. 21-26, and the description of operation C (1430) is omitted for clarity and conciseness.

I. Operation A (1410)

In the DVB-CBMS system according to the second exemplary embodiment, the channel information of the alert message is transmitted to the terminal using the ESG, and the terminal detects that the received packet includes the alert message using the channel information.

With reference to table 12 below, a description will be made of the channel information of the alert message applied to the DVB-CBMS system according to an exemplary embodiment of the present invention.

Table 12 Name Type of Category Description NotificationEntry E M Record for alert message NotificationPort A M Alert message delivery port NotificationAddress A O Alert Message Delivery IP Address

A description of the terms used in table 12 is provided. “Name” means the names of the element values and attribute values that make up the corresponding message. "Type" indicates whether the corresponding name matches the element value or attribute value. The element value has the values E1, E2, E3 and E4. E1 means the value of the top element for the entire message, E2 means the value of the child element E1, E3 means the value of the child element E2, and E4 means the value of the child element E3. The attribute value is indicated by A, and A means the attribute value of the corresponding element. For example, A according to E1 means the value of the attribute E1.

A "category" is used to indicate whether the corresponding element value or attribute value is mandatory, and has a value of M if the value is mandatory and a value of O if the value is optional. Description describes the meaning of the corresponding value of an element or attribute.

The NotificationEntry element has two attributes: NotificationPort and NotificationAddress. NotificationPort and NotificationAddress indicate information about the channel through which the terminal can receive the notification message. The use of IP as a data transfer technology is described below. If the way the terminal can receive the alert message on the assumption that IP is being used, provides information on the IP address at which the alert message should be delivered, and provides information on the UDP port number on the assumption that UDP is used over the IP layer, then the terminal may receive an alert message. The reason for using UDP is as follows. Although other transport protocols such as TCP can also be used, the UDP transport header has less overhead and does not support acknowledgment. Thus, the UDP transport protocol is suitable for the characteristics of a unidirectional broadcast service.

When the alert message is delivered on a point-to-point basis, TCP can be used instead of UDP. Therefore, it should be understood that TCP is used as the port of the alert message in a point-to-point scheme, unless otherwise indicated. Although the UDP port is used as the alert message port in the further description, the TCP port can be used as the alert message port in a point-to-point scheme, as described above.

NotificationPort has the UDP port number previously allocated so that the network provider or service provider uses the UDP port number when it sends the notification message. The terminal receiving the message transmitted via the UDP port indicated for using the notification message can immediately detect the corresponding packet as the notification message and process the packet because it knows the UDP port for the notification message.

The operation of generating an alert message as a transmitted message may be performed in the alert function 1102a for alerts or the alert propagation / adaptation function 1103b of FIG. 11. The object for generating the notification message has information on all ongoing sessions. Those. You can attach a notification message to an existing transport session without creating a separate transport session. The basic session identification module consists of an IP address, and the alert message uses the IP address of the current session. At the same time, the current session can be associated with a specific service connected to the Acquisition fragment that needs to be notified.

Since the mobile broadcast system delivers the alert message through an ongoing IP session by simply distinguishing between the UDP ports, the terminal can immediately receive the alert message (general alert message or specific alert message associated with the ongoing session service) without having to separately monitor the session. NotificationPort can be used when the terminal receives a mobile broadcast service and wants to deliver a notification message via an IP stream (or IP transport path) where the mobile broadcast service is transmitted.

NotificationAddress is used when it is intended to allocate a special IP address during the delivery of the notification message and deliver the notification message via a stream (or transport path) having an IP address. NotificationAddress provides an IP address to deliver a general or specific alert message to a terminal receiving a mobile broadcast service, or inactive mode terminals not receiving a mobile broadcast service in order to save power. Using NotificationPort and NotificationAddress, the terminal receives the alert message according to the receive address for the alert message of the entity wishing to deliver the terminal status or alert message.

In a broadcast system according to an exemplary embodiment of the present invention, since a terminal that has already accessed the broadcast service receives the PSI / SI signal, the transmitter does not separately transmit channel information of the alert message.

The following is a description of a method for delivering a notification message in a broadcast system according to an exemplary embodiment of the present invention.

For a general alert message, the transmitter enters the channel information of table 12 into the ESG self-tuning descriptor 1313 of FIG. 13 before the transfer. To report a specific alert, the transmitting device inserts the channel information of table 12 into the Acquisition fragment 1208 of FIG. 12.

With reference to FIG. 15 and 16, a transmission / reception description of a self-tuning ESG descriptor 1313 in a broadcast system according to a second exemplary embodiment of the present invention is described below.

FIG. 15 is a flowchart illustrating an operation of generating and delivering an ESG self-tuning descriptor 1313 in a broadcast system according to a second exemplary embodiment of the present invention.

Referring to FIG. 15, the alert propagation / adaptation function 1103b denotes the elements and attributes of the general alert message channel information as self-tuning information of the ESG to be delivered to the terminal 1108, at step 1501. In particular, at step 1501, the NotificationEntry, NotificationPort, and NotificationAddress values described above. In this case, the elements and attributes of the information channel of the general notification message are predefined in accordance with the broadcast provider or the system environment. After step 1501, the alert propagation / adaptation function 1103b generates an ESG self-descriptor 1313, including general alert message channel information, at step 1502. After that, at step 1503, the alert propagation / adaptation function 1103b delivers the generated ESG self-tuning descriptor 1313 to terminal 108. Although the generation of the general alert message channel information in this document is performed by the alert distribution / adaptation function 1103b, but may also be performed by the alert event function 1102a.

FIG. 16 is a flowchart illustrating an operation of receiving channel information of a notification message in an ESG self-descriptor 1313 by terminal 1108 in a broadcast system according to a second exemplary embodiment of the present invention.

Referring to FIG. 16, terminal 1108 executes the broadcast service by the user in step 1601, and then receives the ESG self-descriptor 1313 transmitted from the alert distribution / adaptation function 1103b, in step 1602. After receiving the ESG self-descriptor 1313, terminal 1108 decodes the ESG self-descriptor 1313 at step 1603, and receives the NotificationEntry, NotificationPort, and NotificationAddress required to receive the general notification message, at step 1604. Then, terminal 1108 proceeds to operation B (1420) of FIG. fourteen.

With reference to FIG. 17 and 18, a transmission / reception description of an ESG Acquisition fragment 1208 in a broadcast system according to a second exemplary embodiment of the present invention is described.

FIG. 17 is a flowchart illustrating an operation of generating and delivering channel information of a notification message in ESG Acquisition fragment 1208 in a broadcast system according to a second exemplary embodiment of the present invention.

Referring to FIG. 17, the alert distribution / adaptation function 1103b denotes the elements and attributes of the specific alert message channel information as the ESG Acquisition fragment information to be delivered to the terminal 1108, at step 1701. In particular, the values NotificationEntry, NotificationPort and NotificationAddress are indicated at step 1701, described above. Moreover, the elements and attributes of the message channel information of a particular alert are predetermined in accordance with the broadcast provider or system environment. After step 1701, the alert distribution / adaptation function 1103b inserts the specific alert message channel information into the Acquisition ESG fragment 1208 in step 1702. After that, the alert propagation / adaptation function 1103b terminates the ESG by combining the ESG Acquisition fragment 1208 with other fragments in step 1703, and then delivers ESG to the terminal 1108 at step 1704. Although the generation of the message information channel of the specific alert is performed in this document by the alert distribution / adaptation function 1103b, it can yatsya function 1102a events for notification.

FIG. 18 is a flowchart illustrating an operation of receiving channel information of a notification message in an ESG Acquisition fragment 1208 by a terminal 1108 in a broadcast system according to a second exemplary embodiment of the present invention.

Referring to FIG. 18, terminal 1108 executes the broadcast service by the user in step 1801, and then receives the ESG self-descriptor 1313 transmitted from the alert propagation / adaptation function 1103b, in step 1802. After receiving the ESG self-descriptor 1313, terminal 1108 decodes the ESG self-descriptor 1313 at step 1803. Then, at step 1804, terminal 1108 obtains information available for receiving ESG, performs hardware and software settings for receiving ESG using the received information, and then immediately receives ESG. At step 1805, terminal 1108 receives and checks the NotificationEntry, NotificationPort, and NotificationAddress, which are required to receive a particular alert message and are included in the Acquisition fragment 1208 for the ESG. Then, terminal 1108 proceeds to operation B (1420) of FIG. fourteen.

As yet another example, terminal 1108 can detect a specific service associated with the alert message by receiving the alert message and decrypting the Service_ID inserted in the alert message without receiving channel information of the specific alert message through the Acquisition fragment 1208 for the ESG, as is done in FIG. 17 and 18. Preferably, the Service_ID has the same meaning as the service identifier in the ESG.

II. Operation B (1420)

With reference to FIG. 19, the following is a description of the transmission of a general alert message according to a second exemplary embodiment of the present invention. Since the general alert message and the specific alert message are identical with respect to the transmission method, they do not differ in the description of FIG. 19.

FIG. 19 is a flowchart illustrating a general alert message delivery operation in a broadcast system according to a second exemplary embodiment of the present invention.

Referring to FIG. 19, the alert distribution / adaptation function 1103b receives a general alert message containing the contents of the alert (i.e., an alert event) from function 1102a in step 1901. At step 1902, the alert distribution / adaptation function 1103b then generates a UDP packet using specific UDP port and general alert messages. The format of the general notification message, since it is set at the level of the service provider, is not directly related to the transmission, so the general notification message is immediately generated in a UDP packet. After that, at step 1903, the alert distribution / adaptation function 1103b generates a packet according to the ongoing broadcast session and the previously indicated alert IP address using the generated alert message and delivers the generated packet to the terminals. Meanwhile, in the service area, it is possible that there are standby terminals when they are connected to the interaction network 1107 or can receive the radio call service, but their broadcast receiver is disabled. For terminals in this mode, the system must “wake up” the broadcast receivers in standby mode (not shown) for the terminals by using the communication channel of the communication network 1107 or making a radio call by another means. To this end, the system generates a radio call message to wake the standby broadcast receiver in step 1904 and sends the radio call message to the terminals via the interaction network 1107 or another method in step 1905, thereby awakening the terminal broadcast receiver.

A packet for transmitting a general alert message is generated using the previously specified UDP port number, i.e. NotificationPort, for using alert delivery. This serves to enable terminal 1108 to recognize the received packet as a general alert message. The generated UDP packets are formed into IP packets using the IP address of the current running session or IP address for delivery of a general notification message, i.e. NotificationAddress. The IP address of the current ongoing session can be obtained since the alert distribution / adaptation function 103-1 for generating the alert delivery message exists in the service control 1103 for managing all the transmissions. Full IP packets are delivered to the downstream transmitter. In this case, the general alert message may be re-delivered to the lower level transmitter several times according to the needs of the network provider or service provider, given the situation in which there is packet loss or packet reception may fail.

With reference to FIG. 20 and 21, a description will now be made of a reception operation of a notification message in a broadcast system according to a second exemplary embodiment of the present invention. Since the general alert message and the specific alert message are identical to each other with respect to the reception method, they do not differ in the following description.

FIG. 20 is a flowchart illustrating an operation of receiving a notification message by a notification client function 1108a at a terminal in a mobile broadcast system according to a second exemplary embodiment of the present invention.

Referring to FIG. 20, after receiving channel information of the alert messages in operation A (1410) of FIG. 14, the notification client function 1108a receives the IP packet and decrypts the IP packet header in step 2001. The notification client function 1108a determines in step 2002 whether the packet IP address is identical to the desired IP address as a result of decryption of the header. Here, “required IP address” means the IP address of the current session in progress or a specific IP address, i.e. NotificationAddress assigned to the notification message. Therefore, if the IP address in the header is not the desired IP address as a result of the IP check, the notification client function 1108a discards the received IP packet in step 2006.

However, if the address of the received IP packet is identical to the desired IP address, the notification client function 1108a proceeds to step 2003, where it receives the UDP packet by unpacking the IP packet and decrypting the header of the UDP packet. Next, the notification client function 1108a determines in step 2004 whether the UDP port number obtained by decrypting the UDP packet header is identical to the NotificationPort port number of the predetermined notification message channel information previously obtained by the self-tuning descriptor 1313 of the ESG or PSI / SI signal. Those. the alert client function 1108a determines whether the received packet is a general alert message or a packet of a general broadcast session.

If it was determined at step 2004 that the port number of the received UDP packet header is identical to the UDP port number for receiving the alert message, the alert client function 1108a unpacks the received UDP packet to receive a general alert message included in the operational data, and decrypts the notification message to perform the desired operation in step 2005, and then proceeds to operation C (1430) of FIG. 14. However, if the port number of the received UDP packet is different from the predetermined UDP port number, the notification client function 1108a proceeds to step 2007, where it processes the received UDP packet for the broadcast service, treating it as an existing packet broadcast session, or ignores the received UDP packet if it is not the desired alert message.

FIG. 21 is a flowchart illustrating a process for receiving a notification message in a client notification function of a terminal 1108a when it is connected to an interaction network in a broadcast system according to a second exemplary embodiment of the present invention. This process can be applied not only to the interaction network, but also to a terminal connected to a system capable of controlling the terminal in standby mode.

Referring to FIG. 21, after receiving channel information of the alert message in operation A (1410) of FIG. 14, the alert client function 1108a receives a radio call message according to a radio call unit of an interaction network or other system in step 2101. At step 2102, the alert client function 1108a activates a standby broadcast receiver by means of a radio call message and prepares to receive it. Preparation for reception includes forming a session using NotificationPort and NotificationAddress, transmitted by the method described in the second exemplary embodiment, and the transition to the standby mode. After entering the ready mode, the notification client function 1108a decrypts the header of the received IP packet after receiving the IP packet from the notification distribution / adaptation function 1103b in step 2103.

The notification client function 1108a determines in step 2104 whether the IP packet address is identical to the IP address specified from NotificationAddress. If it is determined that the address in the IP packet header is different from the address in NotificationAddress, the notification client function 1108a discards the packet in step 2108. However, if the IP address of the IP packet is identical to the NotificationAddress IP address, the notification client function 1108a decrypts the UDP header the packet extracted by decapsulating the IP packet in step 2105.

The notification client function 1108a determines in step 2106 whether the UDP port number obtained by decrypting the UDP packet header is identical to the UDP port number of NotificationPort. Step 2106 is performed to determine if the received packet is a general notification message or an incorrectly transmitted packet.

If it is determined in step 2106 that the port number of the received UDP packet header is identical to NotificationPort, i.e. A UDP port number for receiving a general alert message, the alert client function 1108a unpacks the UDP packet to receive an alert message included in the operation data, and decrypts the alert message to perform the desired operation, in step 2107, and then proceeds to operation C (1430) of FIG. 14. However, if the port number of the received UDP packet is different from the NotificationPort port number, the notification client function 1108a discards the received UDP packet in step 2108, considering it to be an incorrectly transmitted UDP packet. Then, the terminal proceeds to operation C (1430) of FIG. 14. Operation C does not relate to the essence of an exemplary embodiment of the present invention, therefore, its description is omitted.

From the above description, it should be understood that an exemplary embodiment of the present invention sets the IP address and UDP port for delivery of notification messages in SGDD, to prevent the need to decrypt all headers of the received signal, reducing the amount of system overhead and providing the ability to deliver an alert message, even when the terminal is in standby mode or is interacting with another system.

Exemplary embodiments of the present invention can be implemented in a general-purpose computer by executing a program from a computer-readable medium, including, but not limited to, storage devices such as magnetic storage devices (ROM, RAM, floppy disks, magnetic tapes, etc. .), optically readable storage devices (CD-ROM, DVD, etc.), and wave media (transmission over the Internet).

Although specific exemplary embodiments of the invention are shown and described with reference to specific preferred embodiments herein, those skilled in the art will appreciate that various changes in form and content can be made without departing from the spirit and scope of the invention, given the attached claims and its equivalents.

Claims (61)

1. A method for providing a broadcast service in a transmitter of an Internet Protocol (IP) -based broadcast system, the method comprising the steps of: (a) transmitting first access information including a first network address for transmitting a general message alerts to the broadcast receiver, and second access information for transmitting a specific alert message associated with a particular broadcast service, through one of ty broadcast and interworking networks; and (b) generating a general notification message and transmitting the generated general notification message to the broadcast receiver by one of the broadcast network and the interaction network using the first network address if a general notification event occurs. 2. The method of claim 1, wherein the second access information further includes a second network address for transmitting a specific alert message associated with a particular broadcast service. 3. The method according to claim 2, further comprising the step of generating a specific alert message and transmitting the generated specific alert message through one of the broadcast network and the interaction network using the second network address if a specific alert event occurs. 4. The method of claim 1, wherein the first network address includes an alert port indicating a user datagram protocol (UDP) port used to transmit the general alert message. 5. The method according to claim 1, in which the first network address contains:
Alert port indicating the UDP port used to transmit the general alert message and an alert address indicating an IP address if an IP address is used to transmit a general alert message. 6. The method of claim 1, further comprising transmitting the paging message before transmitting the first access information. 7. The method according to claim 4, in which step (b) comprises the steps of: generating a UDP packet including a UDP port for a general alert message; and form an IP packet including the current IP address for the generated UDP packet. 8. The method according to claim 5, in which step (b) comprises the steps of: generating a UDP packet including a UDP port for a general alert message; and form an IP packet including an IP address for the generated UDP packet. 9. The method according to claim 3, in which the second network address includes an alert port indicating a UDP port used to transmit a specific alert message. 10. The method according to claim 3, in which the second network address comprises: an alert port indicating a UDP port used to transmit a specific alert message; and an alert address indicating an IP address if an IP address is used to transmit a specific alert message. 11. The method according to claim 9, in which step (b) comprises the steps of: generating a UDP packet including a UDP port for reporting a specific alert; and form an IP packet including the current IP address for the generated UDP packet. 12. The method according to claim 10, in which step (b) comprises the steps of: generating a UDP packet including a UDP port for reporting a specific alert; and form an IP packet including an IP address for the generated UDP packet. 13. The method of claim 2, wherein if the broadcast system supports broadcasting and viewing mobile content of the Open Mobile Alliance (OMA BAC BCAST), the first network address is included in the service guide delivery descriptor (SGDD), and the second network address included in the access fragment of the service guide. 14. The method according to claim 2, in which if the broadcast system supports digital video broadcasting (DVB), the first network address is included in the self-descriptor of the electronic service guide, and the second network address is included in the fragment of obtaining electronic service guide (ESG). 15. A transmitter of an Internet Protocol (IP) -based broadcast system, comprising: first means for transmitting first access information including a first network address for transmitting a general alert message and second access information for transmitting a specific alert message, associatively associated with a particular broadcast service, through one of the broadcast network and the interaction network; and second means for generating, if a general notification event occurs, a general notification message and transmitting the generated general notification message through one of the broadcast network and the interaction network using the first network address. 16. The transmitter of claim 15, wherein the second access information further includes a second network address for transmitting a specific alert message associated with a particular broadcast service. 17. The transmitting device according to clause 16, in which, if a specific alert event occurs, the second means generates a specific alert message and transmits the generated specific alert message through one of the broadcast network and the interaction network using the second network address. 18. The transmitter of claim 15, wherein the first network address includes an alert port indicating a user datagram protocol (UDP) port used to transmit the general alert message. 19. The transmitter of claim 15, wherein the first network address comprises: an alert port indicating a UDP port used to transmit a general alert message; and an alert address indicating an IP address if an IP address is used to transmit a general alert message. 20. The transmitter of claim 15, wherein the first means further transmits a paging message before transmitting the first access information. 21. The transmitter of claim 18, wherein the second means comprises: a UDP packet generator for generating a UDP packet including a UDP port for a general alert message; and an IP packet generator for generating an IP packet including the current IP address for the generated UDP packet. 22. The transmitter of claim 19, wherein the second means comprises: a UDP packet generator for generating a UDP packet including a UDP port for a general alert message; and an IP packet generator for generating an IP packet, including an IP address, for the generated UDP packet. 23. The transmitter of claim 17, wherein the second network address includes an alert port indicating a UDP port used to transmit a specific alert message. 24. The transmitter of claim 17, wherein the second network address comprises: an alert port indicating a UDP port used to transmit a specific alert message; and an alert address indicating an IP address if an IP address is used to transmit a specific alert message. 25. The transmitter of claim 23, wherein the second means comprises: a UDP packet generator for generating a UDP packet including a UDP port for reporting a specific alert; and an IP packet generator for generating an IP packet including a current IP address for the generated UDP packet. 26. The transmitter of claim 24, wherein the second means comprises: a UDP packet generator for generating a UDP packet including a UDP port for reporting a specific alert; and an IP packet generator for generating an IP packet including an IP address for the generated UDP packet. 27. The transmitter of claim 16, wherein if the broadcast system supports broadcasting and viewing mobile content of the Open Mobile Alliance (OMA BAC BCAST), the first network address is included in the service guide delivery descriptor (SGDD), and the second network address included in the access fragment of the service guide. 28. The transmitting device according to clause 15, in which if the broadcast system supports OMA BAC BCAST, the second tool acts as a function of distribution / adaptation alerts (NTDA). 29. The transmitter of claim 16, wherein, if the broadcast system supports digital video broadcasting (DVB), the first network address is included in the self-descriptor of the electronic service guide, and the second network address is included in the fragment for receiving the electronic service guide (ESG) . 30. The transmitting device according to clause 15, in which if the broadcast system supports DVB, the second tool acts as one of the functions of the distribution / adaptation of alerts (NDAF) and the function of generating alerts (NGF). 31. A method for receiving broadcast services in a broadcast receiver of a broadcast system based on Internet Protocol (IP), comprising the steps of: (a) receiving first access information including a first network address to receive a general alert message , and second access information for receiving a specific alert message associated with a particular broadcast service via one of the broadcast network and the interaction network I am; and (b) receiving a general alert message based on the first network address. 32. The method of claim 31, wherein the second access information further includes a second network address for receiving a specific alert message associated with a particular broadcast service. 33. The method of claim 32, further comprising the step of: if the broadcast receiver receives a particular broadcast service, a specific alert message is received based on the second network address. 34. The method of claim 31, wherein the first network address includes an alert port indicating a user datagram protocol (UDP) port used to receive the general alert message. 35. The method of claim 31, wherein the first network address comprises: an alert port indicating a UDP port used to receive a general alert message; and an alert address indicating an IP address if an IP address is used to receive a general alert message. 36. The method of claim 31, further comprising receiving a paging message before receiving the first access information if the broadcast receiver is in a standby state. 37. The method according to clause 34, in which step (b) comprises the steps of: generating a UDP packet by unpacking the data received from the current IP, if the first network address is the current IP address; determining whether the UDP packet includes a UDP port; and recognizing the received UDP packet as a general notification message if the UDP packet includes a UDP port. 38. The method according to clause 35, in which step (b) comprises the steps of: generating a UDP packet by unpacking the data received from the IP address, if the first network address is an IP address; determining whether the UDP packet includes a UDP port; and recognizing the received UDP packet as a general notification message if the UDP packet includes a UDP port. 39. The method of claim 33, wherein the second network address includes an alert port indicating a UDP port used to receive a specific alert message. 40. The method according to claim 33, wherein the second network address comprises: an alert port indicating a UDP port used to receive a specific alert message; and an alert address indicating an IP address if an IP address is used to receive a specific alert message. 41. The method according to § 39, in which step (b) comprises the steps of: generating a UDP packet by unpacking the data received from the current IP, if the first network address is the current IP address; determining whether the UDP packet includes a UDP port; and recognizing the received UDP packet as a specific alert message if the received UDP packet includes a UDP port. 42. The method according to claim 40, wherein step (b) comprises the steps of: generating a UDP packet by decompressing the data received from the IP address if the first network address is an IP address; determining whether the UDP packet includes a UDP port; and recognizing the received UDP packet as a specific alert message if the received UDP packet includes a UDP port. 43. The method of claim 32, wherein the broadcast system supports broadcasting and viewing mobile content of the Open Mobile Alliance (OMA BAC BCAST), the first network address is included in the service guide delivery descriptor (SGDD), and the second network address is turned on into the access fragment of the service guide. 44. The method of claim 32, wherein if the broadcast system supports digital video broadcasting (DVB), the first network address is included in the self-descriptor of the electronic service guide, and the second network address is included in the fragment for receiving the electronic service guide (ESG). 45. A broadcast receiver of an Internet Protocol (IP) -based broadcast system, comprising: first means for receiving first access information including a first network address, for receiving a general alert message, and second access information for receiving a specific alert message, associated with a particular broadcast service, through one of the broadcast network and the interaction network; and second means for receiving a general alert message based on the first network address. 46. The broadcast receiver of claim 45, wherein the second access information further includes a second network address for receiving a specific alert message associated with a particular broadcast service. 47. The broadcast receiver of claim 46, wherein the second means further receives a specific alert message based on the second network. 48. The broadcast receiver of claim 45, wherein the first network address includes an alert port indicating a user datagram protocol (UDP) port used to receive the general alert message. 49. The broadcast receiver of claim 45, wherein the first network address comprises: an alert port indicating a UDP port used to receive a general alert message; and an alert address indicating an IP address if an IP address is used to receive a general alert message. 50. The broadcast receiver of claim 45, wherein the first means further receives a paging message prior to receiving the first access information if the broadcast receiver is in a standby state. 51. The broadcast receiver of claim 48, wherein the second means comprises: an IP packet decoder for generating a UDP packet by decompressing the data if the data is received using the current IP address; a UDP packet decoder to determine if the packet includes a UDP port, and unpack the UDP packet if the UDP packet includes a UDP port; and an alert message decoder to recognize the decompressed UDP packet as a general alert message, thereby decrypting the UDP packet. 52. The broadcast receiver of claim 49, wherein the second means comprises: an IP packet decoder for generating a UDP packet by decompressing the data if the data is received using the IP address; a UDP packet decoder to determine if the UDP packet includes a UDP port, and unpack the UDP packet if the UDP packet includes a UDP port; and an alert message decoder to recognize the decompressed UDP packet as a general alert message, thereby decrypting the UDP packet. 53. The broadcast receiver of claim 47, wherein the second network address includes an alert port indicating a UDP port used to receive a specific alert message. 54. The broadcast receiver of claim 47, wherein the second network address comprises: an alert port indicating a UDP port used to receive a specific alert message; and an alert address indicating an IP address if an IP address is used to receive a specific alert message. 55. The broadcast receiver of claim 53, wherein the second means comprises: an IP packet decoder for generating a UDP packet by decompressing the data if the data is received using the current IP address; a UDP packet decoder to determine if the UDP packet includes a UDP port, and unpack the UDP packet if the UDP packet includes a UDP port; and an alert message decoder to recognize the decompressed UDP packet as a specific alert message, thereby decrypting the UDP packet. 56. The broadcast receiver of claim 54, wherein the second means comprises: an IP packet decoder for generating a UDP packet by decompressing the data if the data is received using the IP address; a UDP packet decoder to determine if the UDP packet includes a UDP port, and unpack the UDP packet if the UDP packet includes a UDP port; and an alert message decoder to recognize the decompressed UDP packet as a specific alert message, thereby decrypting the UDP packet. 57. The broadcast receiver of claim 46, wherein if the broadcast system supports broadcasting and viewing mobile content of the Open Mobile Alliance (OMA BAC BCAST), the first network address is included in the service guide delivery descriptor (SGDD), and the second the network address is included in the access fragment of the service guide. 58. The broadcast receiver of claim 45, wherein the second means includes a client alert function. 59. The broadcast receiver of claim 46, wherein if the broadcast system supports digital video broadcasting (DVB), the first network address is included in the self-descriptor of the electronic service guide and the second network address is included in the fragment for receiving the electronic service guide (ESG ) 60. A computer-readable recording medium storing a program for implementing a method for providing broadcast services in a transmitter of an Internet Protocol (IP) -based broadcast system, the method comprising the steps of: (a) transmitting first access information including a first network address for transmitting a general alert message to a broadcast receiving device that receives a broadcast service, and second access information associated with for transmitting a specific alert message associated with a particular broadcast service to a broadcast receiver through one of the broadcast network and the interaction network; and (b) generating a general notification message and transmitting the generated general notification message to the broadcast receiver by one of the broadcast network and the interaction network using the first network address if a general notification event occurs. 61. A computer-readable recording medium storing a program for implementing a method of receiving broadcast services in a broadcast receiver of a broadcasting system based on Internet Protocol (IP), the method comprising the steps of: (a) receiving first access information including the first network address for receiving a general alert message, and the second access information associated with transmitting a specific alert message associated with a particular a broadcast service from a transmitting broadcast device by one of a broadcast network and an interaction network; and (b) receiving a general alert message based on the first network address in the data received from the broadcast transmitter.

Images