RU2372742C1 - Method and device for transmitting/receiving of information about access of broadcasting service in broadcasting system and corresponding system - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: there is offered broadcasting system for supplying information about access of broadcasting service in which transmission device generates information about access for at least one network among broadcasting network and interactive network from which broadcasting service is transmitted and supplies information about access to terminal through specified communication network. Receiver receives information about access of broadcasting service via communication network, analyses the received information about access for determination of network, from which broadcasting service is provided, among broadcasting network and interactive network and determines access address for receiving of broadcasting service.

EFFECT: effective transmitting/receiving of information about access of broadcasting services in broadcasting system.

65 cl, 7 dwg, 37 tbl

Description

FIELD OF THE INVENTION

The invention relates, generally speaking, to a method and apparatus for providing communication services in a broadcast system. In particular, the present invention relates to a method for transmitting / receiving access information and a device for effectively accessing broadcast services, as well as to a corresponding system and terminal.

State of the art

The mobile market continuously requires the production of new services through, for example, updating or integrating existing technologies. Currently, with the development of broadcasting and broadcasting technologies, a conventional broadcasting system or a mobile communication system has reached the state of providing communication services via portable terminals (or mobile terminals), for example, mobile phones and personal digital assistants (PDAs). Due to the needs of the potential and real market and the increasing demand for multimedia services, service providers chart strategies for providing new services, such as mailing services in addition to the existing voice service, and identify the interests of the Information Technology (IT) companies that support their mobile companies communications to meet user demand, the combination of mobile services and the Internet Protocol (IP) has become a significant trend in the development of next-generation mobile communications technologies tions.

The Open Community of Mobile Telecommunications Manufacturers (OMA), one of the broadcast service standardization groups, was organized in June 2002 by approximately 200 companies, including Nokia, NTT and IBM, to carry out a study on the standard for harmonizing individual mobile communications solutions. OMA mainly serves to define various application standards for mobile games and Internet services. Of the OMA-owned working groups, the Mobile Manufacturers Open Community Browser and the Mobile Content Broadcasting Working Subgroup (OMA BAC BCAST) are now doing research on technology for providing broadcast services using mobile terminals. The following is a brief description of the broadcast system under consideration by OMA.

In the BCAST system, which is a broadcast system proposed by OMA, a mobile terminal requesting a broadcast service must receive so-called service guide information containing a description of the service, settlement information for the service, and information regarding the method of receiving the service. The mobile terminal receives the service in accordance with the information provided in the service guide information. The following describes a conventional method for accessing a broadcast service in connection with a BCAST system, as an example of a general broadcast system using a service guide. Figure 1 shows a block diagram of the structure of a service explorer used to receive a broadcast service in a conventional broadcast system. This structure is proposed for providing broadcast services to a mobile terminal in the BCAST system. One service guide consists of many groups, each having its own task, and all groups are classified into four groups according to usage, as shown in FIG. Figure 1 shows an exemplary service explorer consisting of an administrative group 100 providing groups 110, a main group 120, and an access group 130.

Administrative group 100 is a group for providing basic information required by a mobile terminal to receive a service guide, and includes a service guide context fragment 101 and a service guide delivery descriptor fragment 102. The service guide context fragment 101 provides a service guide identifier (ID), service provider identification information that the service guide produces and transmits, and all information regarding the service guide. A fragment 102 of the service guide delivery descriptor provides a channel suitable for receiving fragments for a plurality of service conductors, distributing information and updating information on the mobile terminal so that the mobile terminal can only receive the necessary service guide at the appropriate time.

The provisioning group 110 is a group for providing information on payment for receiving a service and includes a purchase item fragment 111, a purchase data fragment 112 and a purchase channel fragment 113. A fragment of a purchase item 111 provides payment information for a service or service package, a fragment 112 of the purchase data provides information indicating how a user of a service can pay, and a fragment 113 of a purchase channel provides information regarding a system where a user of a service can actually buy a service.

The main group 120 is a group for providing information about the service itself and includes a service fragment 121, a schedule fragment 122, and a content fragment 123. The service fragment 121 provides a description of the service itself that the user will receive, and also provides information indicating with what content the service can be generated. Fragment 122 of the schedule provides information regarding the time at which the service can be provided and used. The content fragment 123 provides information regarding the plurality of content constituting the service.

The access group 130 includes an access fragment 131 and a communication session description fragment 132, and provides service access information indicating how to receive services provided through the main group 120 and detailed information regarding a communication session in which contents constituting the corresponding service are transmitted so as to allow the mobile terminal access to the corresponding service. The access fragment 131 provides many access methods for one service to a mobile terminal, thereby providing a method suitable for arranging access to various additional services based on one service. Session description fragment 132 provides session information for a service defined in one access fragment.

The service guide information, as shown in FIG. 1, may further include a preview data fragment 124 that provides a preview and image for the service and content in addition to the previous four fragments.

In connection with Tables 1-7 below, details of the access fragment defined by the conventional OMA BCAST as an example are discussed. Tables 1-7 are highlighted from one table for convenience, and the definition of the items in each Table follows the definitions of Table 1.

Table 1 Name Type of Category Cardinal number Description Data type 201 Access
( E ABOUT 0 ... N Access fragment
Contains the following attributes:
id
version
validFrom
validTo
ServiceProtection
AccessType
AudioLanguage
Contains the following subelements:
ExtensionURL
AccessType
ServicelD
Usageinfo
SessionDescriptionURI
SDP
InleractiveAccessURI
TerminalCapabilityRcquirement
BandwidthRequirement
ApplicationSpec
Mediainformation

In Table 1, the first “Name” indicates the names of the attributes or elements of the access fragment, and the second “Type” indicates whether each object included in the access fragment is Attribute (A) or Element (E). As for the difference between an attribute and an element, the attribute is a value indicating the attribute of the access fragment and its element, and the element is a value indicating the information actually used. The third “Category” item indicates whether the attribute or element is a required value (M) or a possible value (O). The fourth point “Cardinal number” indicates whether the attribute or element is repeated, and the fifth paragraph “Description” indicates the description of the attribute or element. Finally, the sixth paragraph “Data Type” indicates the data type of the attribute or element.

In Table 1, numeral 201 indicates which attribute or element is included in the access fragment.

table 2 202 id A M one Access fragment id Integer 203 version A M one Version of this snippet A newer version, once received, cancels the old version Byte (8 bit) 204 validFrom A O 0 ... 1 The first moment when this fragment is valid. If this is not the case, it is assumed that admissibility begins at some point in the past. An integer (32 bits) expressed as NTP time. 205 validTo A O 0 ... 1 The last moment when this fragment is valid. If this is not the case, it is assumed that admissibility ends at an indefinite time in the future. An integer (32 bits) expressed as NTP time. 206 ServiceProtection A O 0 ... 1 If true, this indicates that the service is protected; if false, it indicates that this service is open. Boolean

In Table 2, the number 202 denotes the identifier of the access fragment, and this is an attribute that allows the mobile terminal to uniquely identify the corresponding access fragment when it refers to the corresponding access fragment in other fragments. The number 203 denotes an attribute indicating the version of the access fragment, and allows you to indicate whether the mobile terminal received the access fragment of the same version, or the access fragment of the new version.

The validFrom attribute, indicated by the number 204 and validTo, indicated by the number 205, are attributes indicating the valid period of the information included in the access fragment, and the ServiceProtection, indicated by the number 206, is an attribute indicating whether there is a need for a separate authentication procedure during access, because a service that can be accessed through access fragment information is protected from unauthorized access.

Table 3 207 AccessType A M one Defines the type of access. Possible Values Integer 1. The default access object; must exist for A / V
service flow (e.g. television, radio, etc.). it
used by default in the case of multiple accesses associated with the required SDP.
2. A striped access object associated with the required SDP.
3. File carousel used for the scheduled download file and the carousel-type service file; associated with the necessary SDP.
4. Download the file used to download the file over an interactive network; associated with the necessary AccessURI.
5. Service_SMS; this type of access is used to generate various SMS-based services (voting, etc.); no related SDP.
6. Service_web_local; this type of access is used to point to locally stored web pages; no related SDP.
7. Service_web; this type of access is used to indicate Internet services; no related SDP.
8. Service_voice_call; This type of access is used to make a phone call.
9. Service_MMS; this type of access is used to generate various MMS-based services (voting, etc.); no related SDP.
10. Service_java_app; This type of access is used to run Java applications. (8 bit)

In Table 3, the "AccessType", denoted by the number 207, is an attribute indicating in which manner a mobile terminal suitable for receiving a broadcast service can receive a broadcast service that provides access information in an access fragment, and 10 Access Types are determined. Therefore, it is not optional to redefine the Access Type each time a new type of service appears.

Table 4 208 AudioLanguage A M 0..N Sound Stream Language 3-byte ISO 639 language codes 209 ExtensionURL E1 O 0..N URI containing additional information in the extension fragment. AnyURI 210 ServicelD E1 M 1..N Link to the service fragment (s) to which the access fragment belongs Integer 211 Usageinfo E1 O 0 ... N This text helps the user understand what difference he makes to use one or the other access fragment. This is necessary if more than one access fragment is available over time at a given point.
Possibly provided in multiple languages.
Attributes:
Lang 212 Lang A O 0 ... 1 Language 3-byte ISO 639 language codes

In Table 4, “AudioLanguage”, indicated by the number 208, is used to indicate the language of the audio stream transmitted through the access fragment, and “ExtensionURL”, indicated by the number 209, is used to indicate the address of the extended fragment. “ServicelD”, indicated by 210, is an element indicating a service identifier that can be selected through access fragment information, and “UsageInfo”, indicated by 211, is an element that provides information suitable for indicating the use and correlation of a plurality of corresponding access fragments for users when there are multiple access fragments suitable for providing various access information in order to receive various types of additional services for one service, and provided a "Lang" attribute, indicated at 212, that it could be provided in different languages.

Table 5 213 Accessuri E1 O 0 ... 1 URI for SG submission of unit (s), which contains a description of the communication session, so that the application in the terminal uses the service for access. In the case of a non-broadcast service, AccessURI contains information on how this separate service can be obtained.
Attribute:
Type of
Note; Using either AccessURI or SDP is required. AnyURI 214 Type of A M one AccessURI Type:
1 - SDP; AccessURI is the basis for describing SDP;
2 - MBMS-USD; AccessURI is the basis for the MBMS Custom Service Description (MEMS-USD), as defined in [26.346] section 5.2. It may contain one or more SDP descriptions. Integer 215 SDP E1 O 0 ... 1 Session Description in SDP (IFTF Session Description Protocol) format String (in SDP format) 216 Interactive AccessURI E1 O 0 ... N Define an alternative content URI for restoring it through an interactive channel if the content cannot be received through the broadcast channel AnyURI

In Table 5, the “AccessURI”, indicated by the number 213, is an element indicating the address of the place where information regarding the communication session in which the service indicated by the access fragment is transmitted can be collected, and has, for example, the “Type” attribute, indicated by the number 214 Type 214 is an attribute indicating the type of session information and supports the type of Session Description Protocol (SDP), which is the protocol of the current IEFT, and the type of session information used in the Multimedia Multicast (Multicast) Broadcast Service ge (MBMS), which is a portable broadcast technology defined by an asynchronous mobile standardization group. "SDP" 215 is an element providing information regarding a description of an actual communication session, and "InteractiveAccessURI" 216 is an element that registers an address so that the mobile terminal can receive the service through an interactive channel.

Table 6 217 TerminalCapabilityRequirement E1 O 0 ... 1 A specification of the required capabilities of the terminal, for example, protocols, codecs, bit rate, and processing memory; UAprof is used to express opportunities. Line 218 Bandwidthrequirement E1 ABOUT 0 ... 1 Specification of the required network bandwidth. A broadcast service may include multiple access streams (the same content) with different bandwidths so that the terminal can make a choice depending on its current reception mode Integer 219 ApplicationSpec E1 ABOUT 0 ... N The type of application that can consume a service using this access specification defined by the MIME type. Line

In Table 6, "TerminalCapabilityRequirement", indicated by the number 217, is an element indicating the software and equipment requirements of the mobile terminal for receiving a service that can be received through access fragment information, and based on this, a mobile terminal having the function of a portable broadcast receiver, can determine if he is able to receive the corresponding service. In addition, the "BandwidthRequirement", indicated by the number 218, is an element indicating the data transfer rate in the wireless transmission service environment, which can be received through the access fragment, and allows the selection of the data transfer rate required by the mobile terminal among several data transfer rates, and reception services at the selected data rate.

"ApplicationSpec" 219 is an element providing separate information suitable for receiving a service defined in the MIME type.

Table 7 220 Mediainformation E1 ABOUT 0 ... N Possible link to an image, icon, animation or sound. This uses PreviewData or a link to PreviewData.
Attributes:
usageid 221 using A M one Possible values; background, image (for example) Integer (8 bits) 222 id A M one PreviewData Slice ID Integer (8 bits) 223 <proprietary elements / attributes> E1 or lower.
A O 0 ... N Any number of internal or application-defined elements or attributes that are not defined in this specification.

In Table 7, "MediaInformation", indicated by 220, is an element providing service preview information indicated by the access fragment by the mobile terminal that received the access fragment, and has a usage attribute 221 and an id attribute 222. The usage attribute indicates whether he will use the fragment information associated with the id attribute as preview information or background information. The number 223 denotes an element or attribute suitable for providing other information that is not provided through the access fragment.

The access fragment of the conventional BCAST system shown in Tables 1-7 has the following problems.

First, because the “AccessType” conceptually defines the Access Type for the actual service in Table 3, the Access Type must be re-defined each time a new service appears. Secondly, most of the broadcast services provided to the mobile terminal are multimedia services that require high data rates and must effectively use radio resources in order to support high-speed transmission. Therefore, most broadcast technologies for a mobile terminal introduce the multicast concept used in the Internet Protocol and support a method for enabling a service only at the location where the user is located. However, this method is not currently supported for the Access Type. Thirdly, in the currently proposed broadcast system, there is no way to simply provide the transmission scheme or transmission topology supported on the broadcast system for accessing the broadcast service to the mobile terminal.

Accordingly, for the system and method, there is a need for efficient transmission / reception of information about access to broadcast services in a broadcast system.

SUMMARY OF THE INVENTION

Embodiments of the present invention are provided to solve essentially the above and other problems, and provide a method and apparatus for efficiently transmitting / receiving broadcast access information in a broadcast system, and a corresponding system.

In addition, embodiments of the present invention provide a method and apparatus for transmitting / receiving access information of a broadcast network or an interactive network through which broadcast services are transmitted in a broadcast system, and a corresponding system.

In addition, embodiments of the present invention provide a method and apparatus for transmitting / receiving an access fragment including access information of broadcast services in an IP-based broadcast system, and a corresponding system.

In addition, embodiments of the present invention provide an access fragment format for efficiently providing access information for broadcast services in a broadcast system.

In accordance with one aspect of embodiments of the present invention, a method is provided for transmitting broadcast service access information in a transmitter of a broadcast system. The method comprises the steps of generating access information for at least one network from a broadcast network and an interactive network through which a broadcast service is transmitted, and transmitting access information to a terminal via a predetermined communication network.

In accordance with another aspect of embodiments of the present invention, an apparatus is provided for transmitting broadcast service access information in a transmitter of a broadcast system. The device comprises an access information generator for generating access information for at least one network from a broadcast network and an interactive network through which a broadcast service is transmitted, and a transmitter for transmitting access information to the terminal via a predetermined communication network.

In accordance with another aspect of embodiments of the present invention, a method is provided for receiving access information of a broadcast service in a terminal of a broadcast system. The method comprises the steps of receiving access information through a predetermined communication network for at least one network from a broadcast network and an interactive network from which a broadcast service is being transmitted, and receiving a broadcast service from at least one network from a broadcast network and an interactive network in accordance with the accepted access information.

In accordance with another aspect of embodiments of the present invention, an apparatus is provided for receiving access information of a broadcast service in a terminal of a broadcast system. The device comprises a receiver for receiving access information through at least one network from the broadcast network and the interactive network from which the broadcast service is transmitted, and receiving the broadcast service from the at least one network from the broadcast network and interactive network through a predetermined communication network. network in accordance with the accepted access information.

In accordance with yet another aspect of embodiments of the present invention, a broadcast system is provided for providing broadcast service access information. The system comprises a transmitting device for generating access information for at least one network from a broadcast network and an interactive network from which a broadcast service is transmitted, and transmitting access information to a terminal through a predetermined communication network, and a receiving device for receiving through a predetermined network communicating access information of the broadcast service and receiving the broadcast service from at least one network from the broadcast network and the interactive network in accordance with the received access information.

Brief Description of the Drawings

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

Figure 1 depicts a block diagram of the structure of a service conductor used to receive broadcast services in a common broadcast system.

FIG. 2 is a block diagram of a structure of a transmitter for generating an access fragment and transmitting an access fragment to a mobile terminal in a broadcast system in accordance with an exemplary embodiment of the present invention.

3 is a flowchart of a process for generating and transmitting an access fragment in a broadcast system in accordance with a first exemplary embodiment of the present invention.

4 is a block diagram of a structure of a receiving device for receiving an access fragment in a broadcast system in accordance with an exemplary embodiment of the present invention.

5 is a flowchart of a process for receiving and analyzing an access fragment in a broadcast system in accordance with a first exemplary embodiment of the present invention.

6 is a flowchart of a process for generating and transmitting an access fragment in a broadcast system in accordance with a second exemplary embodiment of the present invention.

7 is a flowchart of a process for receiving and analyzing an access fragment in a broadcast system in accordance with a second exemplary embodiment of the present invention.

In all the drawings, like numerical designations correspond to like parts, elements, and structures.

Detailed description of exemplary embodiments of the invention

Exemplary embodiments of the present invention are discussed in detail below in connection with the respective drawings. In the following description, a detailed description of known functions and configurations used is omitted for clarity and conciseness.

In the following description, exemplary embodiments of the present invention are presented to solve the above and other problems. Although exemplary embodiments will be described in connection with the BCAST system, which is one of many standards for portable broadcast technologies, the embodiments of the present invention are not limited thereto, and the following descriptions are not intended to limit the possible applications of the present invention. In this description, the broadcast system includes various communication systems supporting IP-based broadcast services, for example, the BCAST system and the DVB-H system. In addition, although the BCAST system receiver is considered here as a mobile terminal for convenience, embodiments of the present invention are not limited to this, and it will be apparent to those skilled in the art that the technical principles of the present invention can also be applied to wired communication systems supporting broadcast services. based on IP.

Although the term "service guide" is used here as information including, for example, an appropriate description and reception method for a broadcast service of the BCAST system, and the "access fragment" is used here as information including a method of access to broadcast services, the terms "service guide "and" access fragment "may be replaced in accordance with the type of the corresponding broadcast system.

The present invention provides many embodiments, including the exemplary first through third embodiments described below. In a first exemplary embodiment, the BCAST system proposes a new access fragment efficiently configured to indicate the access method for a particular service in the service guide information that the mobile terminal receives to receive the service. In the first embodiment, the access fragment is configured so that it includes only the attribute associated with the access of the service. In addition, in the first embodiment, the access fragment is configured to indicate whether the service is transmitted via a broadcast channel or an interactive channel of a mobile communication network without separately configuring “AccessType”, providing service access information for each service, as shown in Table 3.

A second exemplary embodiment provides an effective access fragment format in which information of the same access fragment can be used for many different services. Finally, a third exemplary embodiment proposes a different embodiment suitable for easily providing access information for transmitting a service through a broadcast network and transmitting the service through an interactive network using an access fragment. In addition, it should be noted that all of the first through third embodiments show various types of exemplary access fragment formats, and typically include features of the present invention providing detailed information about access to the broadcast network and the interactive network through which services are transmitted.

Further, a first exemplary embodiment is considered in connection with Tables 8-14, a second exemplary embodiment is considered in connection with Tables 15-18, and a third exemplary embodiment is considered in connection with Tables 19-37. Although the actions of the transmitter in FIG. 2 and the receiver in FIG. 4 are considered for convenience based on the first embodiment, the device structure in FIG. 2 and 4 may also be applied to the second, third, and other embodiments.

First exemplary implementation

Tables 8-14 show, for example, the format of the access fragment in accordance with the first exemplary embodiment of the present invention. Tables 8-14 are obtained by dividing one Table, for convenience, and the definition of the items in each Table follows the definition of Table 8. In addition, the definition of each item in Tables 8-14 essentially coincides with the definition of Table 1, and a detailed description of the same parts by all Tables 1-7 and Tables 8-14 will be omitted.

Table 8 Name Type of Category Cardinal number Description Data type 301 Access E O 0 ... N Access fragment
Contains the following attributes:
Id
Version
ValidFrom
validTo
Contains the following subelements:
ServicelD
Usageinfo
SessionDescriptionURI
SDP
ApplicationSpec
Mediainformation 302 Id A M one Access Fragment ID Integer 303 version A M one Version of this snippet. A newer version cancels the old one as soon as it is received Byte (8 bit) 304 validFrom A O 0 ... 1 The first time this fragment is valid. If not, admissibility is assumed to have begun at some point earlier Integer (32 bits) expressed as NTP time

The access fragment of the first embodiment contains the attributes "Id" 302, "version" 303 and "validFrom" 304 in Table 8 and "ValidTo" 305 in Table 9. These four attributes are unique attributes for the access fragment, and their functions essentially coincide with those for attributes having the same names in Table 2. However, the difference between the regular access fragment described in Table 2 and the access fragment proposed in the embodiments of the present invention is that the ordinary access fragment has as not even related to the attributes of the access fragment, while the proposed access fragment is configured so that it has only the attributes associated with the access fragment and changes the other attributes to elements that are consistent with the corresponding characteristics.

The access fragment of the first embodiment, as shown in Table 8, contains "ServiceID" 306 in Table 9 and "UsageInfo" 319, "SessionDescriptionURI" 321, "SDP" 323, "ApplicationSpec" 324 and "MediaInformation" 325 in Tables 12-14 as subelements.

Table 9 305 validTo A O 0 ... 1 The last time this fragment is valid. If not, admissibility is assumed to end at an indefinite time in the future. Integer (32 bits) expressed as NTP time 306 Serviceid E1 M 1 ... N Link to the service fragment (s) to which the access fragment belongs.
Contains the following Attribute:
ServiceProtection
Contains the following elements:
TerminalCapabilityRequirement
BandwidthRequirement
AccessType 307 ServiceProtection A M 0 ... 1 "1" indicates that this service is protected, "0" indicates that this service is open Boolean 308 TerminalCapability Requirement E2 O 0 ... 1 A specification of the required capabilities of the terminal, for example, protocols, codecs, bit rate, processing, and memory. UAprof is used to express opportunities Line

In Table 9, “ServicelD”, indicated by the number 306, is the service identifier with which the mobile terminal can obtain service access information through the access fragment, and has “ServiceProtection” 307 as its attribute. "ServicelD" has a "TerminalCapabilityRequirement" 308 in Table 9 and a "BandwidthRequriement" 309 and an "AccessType" 310 in Table 10 as its sub-elements. Therefore, in the first embodiment, since the "ServiceID" element has all the information about accessing the service, coinciding with the corresponding service, the proposed access fragment has higher efficiency than a regular access fragment in terms of the format.

The “TerminalCapabilityRequirement" 308 in Table 9 and the “BandwidthRequirement" 309 in Table 10 have essentially the same functions as for a regular access fragment.

Table 10 309 BandwidthRequirement E2 O 0 ... 1 Specification of the required network bandwidth.
A broadcast service may include multiple available streams (of the same content) with different bandwidths so that the terminal can make a choice depending on its current reception mode. Integer 310 AccessType E2 M one Defines the type of access.
Possible values;
Contains the following attributes:
TransmissionMedia
Contains the following elements:
TransmissionTopology
TransmissionScheme Line 312 TransmissionMedia A M one 0: broadcast channel
1: Interactive Channel ENUM 313 Transmission_Topology E3 O 0 ... 1 0: Broadcast mode
1: Multicast mode
Contains the following attributes:
IP Address ENUM

The "AccessType" 310 in Table 10, provided to indicate in which way the mobile terminal can receive the service, is used to indicate whether the service is transmitted on a broadcast channel or on an interactive channel provided on a mobile communication network, and also indicates with which protocol or The system transmits the mobile terminal service. To this end, in the first embodiment, an “AccessType” consists of one attribute and two subelements.

Thus, the “Transmission_Media” 312 in Table 10 is an attribute indicating whether the service is broadcast or provided from a communication network suitable for bidirectional communication, and the type of sub-element that can be included in the “AccessType” is determined according to the value attribute. For example, if TransmissionMedia indicates that a service is broadcast, AccessType contains Transmission_Topology 313 in Table 10 and IP_Address 314 in Table 11 as its sub-elements.

The "Transmission_Topology" in Table 10 is an element indicating whether the service transmitted on the broadcast channel is transmitted in broadcast mode or multicast mode. The broadcast mode and multicast mode are used in the Internet Protocol, and if "Transmission_Topology" indicates the broadcast mode, this means that the service is transferred to a specific area regardless of the position of the recipient of the services. If "Transmission_Topology" indicates a multicast mode, this means that the service is transmitted to the place where the recipient of the service is located within the service area in accordance with the location information of the recipient of the service. In addition, when "Transmission_Topology" indicates a multicast mode, a mobile terminal suitable for receiving a broadcast service should preferably make a subscription request for the IP address of the multicast mode and receive the broadcast service.

Table 11 314 IP_Adress A O 0 ... 1 IP address of the IP stream that transports the Service over the Broadcast channel.
If the Transfer Topology is 0, then the IP Address Type is the IP Broadcast Address. If the Transfer Topology is l, then the IP Address Type is IP Broadcast Address Line 315 Transmission_Scheme E3 O 0 ... 1 1: Interactive channel provided by Interactive Network
2: MMS
3: WAP 1.0
4: WAP 2 x
5: SMS
6: HTTP
7: Service Provider defined Transfer Scheme ENUM 316 Access ServerIPAddress E4 O 0 ... N The IP address of the Server that provides various access (via the Interactive channel) of the Service. Line 317 AccessServerURI E4 O 0 ... N ULR Server, which provides various access (through the Interactive channel) Services. AnyURI 318 AccessServerPhoneNumber E4 O 0 ... N Server phone number that provides various access (via the Interactive channel) of the Service.

“IP_Address” 314 in Table 11, since the service is transmitted to the mobile terminals as an IP stream in the BCAST system, is an attribute indicating an address for the IP stream. "IP_Address" becomes the IP broadcast address or IP multicast address in accordance with the value "Transmission_Topology" in Table 10. Typically, the IP address of the service is indicated in the description of the communication session. However, when the description of the communication session is not transmitted along with the access fragment, it should be provided to the mobile terminal to identify the service at the IP level.

If the attribute "Transmission_Media" 312 in Table 10 indicates the Interactive Channel, "Transmission_Scheme" 315 in Table 11 is included in the "AccessType" of Table 10, and "Transmission_Scheme" contains "AccessServerIPAddress" 316, "AccessServerURL" 317, and "AccessServerPhoneNumber is 318 in it subelements.

"Transmission_Scheme" is an element indicating a communication system or protocol used in an interactive channel when service access through the interactive channel is possible. Although OMA BCAST currently defines, for example, Web Browsing, the Multimedia Transmission Service (MMS), the Wireless Application Protocol 1.0 (WAP 1.0), the Wireless Application Protocol 2.x (WAP 2.x), the Service Short Message Service (SMS), and Hypertext Transfer Protocol (HTTP), as communication systems or protocols that can be used for an interactive channel, further communication systems and protocols that can be used for an interactive channel, may be added in the future.

In Table 11, "AccessServerIPAddress" 316, "AccessServerURL" 317, and "AccessServerPhoneNumber" 318 are elements indicating the address of a server that provides a service via an interactive channel to indicate whether a mobile terminal receiving an access fragment can access the service through an interactive channel in anywhere. Since the addressing system used in each communication system or protocol is different, a representative addressing system for the communication system and protocol is proposed, which is currently being adapted to support an interactive channel.

"AccessServerIPAddress" 316 is an element indicating a server location based on the Internet Protocol, "AccessServerURL" 317 is an element indicating a server location that uses a communication system or protocol supporting a Web or URI, and "AccessServerPhoneNumber" 318 is an element indicating a server position which allows access to the service using MMS or SMS. Additionally, in embodiments of the present invention, a new communication system or protocol is added to "Transmission_Scheme" 315 in Table 11, and if the addressing system of the communication system or protocol is different from that currently provided, the new addressing system can be added as a sub-element of "Transmission_Scheme".

Table 12 319 Usageinfo E1 O 0 ... N The text explains the characteristic of this access fragment to the User. This text also contains information about other fragments of the Service Access, if there is more than 1 fragment of the Access, possibly provided in many languages.
Attributes:
Lang 320 Lang A ABOUT 0 ... 1 Language 3-byte ISO
639 language codes 321 SessionDescriptionURI E1 O 0 ... 1 The URI to the SG delivery unit (s), which contains a description of the communication session that the media application in the terminal uses to access the service. In the case of a non-broadcast service, AccessURI contains information on how this particular service can be accessed.
Contains the following attribute and element:
Type of
Note: Using AccessURI or SDP is required. AnyURI

"UsageInfo" 319 in Table 12 is an element for providing a description of the characteristics of the access fragment to the user of the mobile terminal, especially an element that can be used to describe the characteristics and correlation of each access fragment for the user, even when there are many access fragments for one service, providing sub-services, having different characteristics. "UsageInfo" has a "Lang" 320 as an attribute.

"SessionDescriptionURI" 321 in Table 12, and "Type" 322, "SDP" 323, "ApplicationSpec" 324, "MediaInformation" 325, "Usage" 326, "Id" 327, and "<proprietary elements / attributes>" 328 in Table 13 and Table 14 have essentially the same functions as those of a regular access fragment and, therefore, a detailed description thereof is not given.

Table 13 322 Type of A M one AccessURI Type:
1 - SDP; AccessURI is the basis of the SDP description;
2 - MBMS-USD; AccessURI is the basis of the user MBMS service description (MBMS-USD), as defined in [26.346] section 5.2. It may contain one or more SDP descriptions. Integer 323 SDP E1 O 0 ... 1 Session Description in SDP (IETF Session Description Protocol) format. String (in SDP format) 324 Application spec E1 O 0 ... N The type of application that can consume a service using this access specification defined by the MIME type Line

Table 14 325 MediaInformation E1 O 0 ... N An additional link to an image, icon, animation, or sound. This uses PreviewData or a link to PreviewData.
Attributes:
usage
id 326 Usage A M one Possible values: background, image (for example) Integer (8 bits) 327 Id A M one PreviewData Slice ID Integer (8 bits) 328 <proprietary elements / attributes> E1 or lower.
A O 0 ... N Any number of internal or application-defined elements or attributes that are not defined in this specification.

Below, in connection with FIG. 2-5, a description is given of the structure and operation of a transmitting device for generating and transmitting an access fragment configured in the format of Tables 7-14, and a receiving device for receiving an access fragment to receive a desired service.

FIG. 2 shows a block diagram of a structure of a transmitter for generating an access fragment and transmitting an access fragment to a mobile terminal in a broadcast system in accordance with an exemplary embodiment of the present invention. The transmitting device comprises an access fragment generator 201, a service guide generator 203, and a transmitter 205.

2, an access fragment generator 201 creates an access fragment configured in the format of Tables 7-14. The service guide generator 203 creates the service guide information having the structure of FIG. 1 using the access fragment output from the access fragment generator 201, and the transmitter 205 transmits the service guide information to the mobile terminal via the transmission network. A transmission network may be a network providing a broadcast channel, or a network providing an interactive channel.

The transmitter of FIG. 2 can be applied to a transmitter of a BCAST system. Alternatively, a transmitter can also be used for a transmitter of any number of communication systems that provide IP-based broadcasting services to multiple users, similar to a DVB-H system.

FIG. 3 is a flowchart of a process for generating and transmitting an access fragment in a broadcast system in accordance with a first exemplary embodiment of the present invention. This process corresponds to the action of the access fragment generator 201 in FIG. 2.

Regarding FIG. 3, the access fragment generator 201 determines in step 301 whether there is a need to produce a new access fragment. If there is a need to produce a new access fragment, this means that a new service is starting, or that there is a need to provide a new additional service or a new access method for the current service to a mobile terminal receiving a broadcast service. If it is determined in step 301 that there is a need to produce a new access fragment, the access fragment generator 201 sets the basic information for the access fragment in step 303. The basic information contains at least one of “Id”, “version” and “validFrom” and "validTo", both associated with the validity of the access fragment described in connection with Table 8 and Table 9.

At step 305, the access fragment generator 201 sets the service ID corresponding to the information provided by the access fragment and sets the main service attribute corresponding to the service ID. The main attribute contains at least one of - information indicating whether to apply service protection, information indicating the requirements of the mobile terminal for receiving the service, and information indicating the data rate at which the service is transmitted in a wireless communication environment - all of them have been described in connection with Table 9 and Table 10. At step 307, the access fragment generator 201 determines whether the service will be transmitted on a broadcast channel or an interactive channel. If the service is transmitted over the interactive channel, the access fragment generator 201 proceeds to step 309. However, if the service is transmitted over the broadcast channel, the access fragment generator 201 proceeds to step 315.

The access fragment generator 201 sets the communication system transmission scheme or the protocol used, in step 309, and sets the address for the corresponding communication system or protocol in step 311. Then, in step 313, the access fragment generator 201 sets the UsageInfo service usage information, and if there is a characteristic description for the corresponding access fragment and multiple access fragments for one service, the access fragment generator 201 adds a description of the characteristic and correlation for each of them to the fragments NTU access so that the recipient of a broadcast service can detect the difference.

In step 315, the access fragment generator 201 sets transmission topology information, indicating whether the corresponding service will be transmitted in broadcast mode or multicast mode. The information corresponding to the mode is determined by the transmission object or the service providing the object, and the access fragment generator 201 receives the information corresponding to the mode provided from the corresponding object and sets the mode depending on the information corresponding to the mode. At step 317, the access fragment generator 201 sets the IP information of the IP stream in which the service is transmitted. After that, at step 313, the access fragment generator 201 sets the UsageInfo service usage information.

At step 319, the access fragment generator 201 sets information regarding a communication session in which a service is transmitted whose access information is provided through the corresponding access fragment. Session information contains the IP address of the sender, the IP address of the recipient, the type of data transmitted in the communication session, and the codec used. The Session Description Protocol defined by the IETF is a typical example of session information. After that, in step 321, the access fragment generator 201 sets up other information constituting the access fragment, and then completes the operation.

FIG. 4 shows a block diagram of a structure of a receiver for receiving a service conductor containing an access fragment for receiving a broadcast service in a broadcast system in accordance with an exemplary embodiment of the present invention. The receiving device comprises a receiver 401, a reverse assembler 403 of the service conductor and an access fragment analyzer 405.

With respect to FIG. 4, the receiver 401 receives the service guide information transmitted from the transmitter of the broadcast system through the transmission network, and outputs the received service guide information to the reverse assembler of the service guide 403. The reverse assembler of the service guide 403 extracts each fragment from the received information of the service guide and delivers the extracted fragment to the corresponding fragment analyzer. Figure 4 shows only the access fragment analyzer 405 associated with embodiments of the present invention, of all possible fragment analyzers. An access fragment analyzer 405 analyzes a received access fragment having the format of Tables 7-14 included in the service guide information in accordance with the operation of FIG. 5 described below, and the mobile terminal performs a service reception operation based on the analysis result.

5 is a flowchart for receiving and analyzing an access fragment in a broadcast system in accordance with a first exemplary embodiment of the present invention. This process corresponds to the operation of the access fragment analyzer 405 in FIG. 4.

Regarding FIG. 5, the access fragment analyzer 405 determines in step 501 whether there is any new received access fragment. The definition criterion is the "version" attribute of the received access fragment. If it is determined in step 501 that an access fragment has been received, the access fragment analyzer 405 analyzes, in step 503, the basic information of the access fragment, determines the available period of the access fragment in the basic information and recognizes that the information provided by the access fragment is available only during the access period.

At step 505, the access fragment analyzer 405 determines a service ID that can be obtained through the access information provided by the access fragment, and determines whether the corresponding service is protected against unauthorized access before being transmitted. When the service is protected against unauthorized access, the access fragment analyzer 405 prepares to perform a related operation in order to correctly receive the corresponding service. In addition, the access fragment analyzer 405 checks the main attribute for the ID of the corresponding service, compares the operation mode of the mobile terminal requiring the corresponding service with the operation mode of the current mobile terminal, to determine whether the service is being received, and selects the appropriate channel taking into account the frequency band provided by the service .

At step 507, the access fragment analyzer 405 determines whether the service will be transmitted on the broadcast channel or on the interactive channel based on the access information provided by the access fragment. If the service is transmitted over the interactive channel, the access fragment analyzer 405 proceeds to step 509. However, if the service is transmitted over the broadcast channel, the access fragment analyzer 405 proceeds to step 515.

At step 509, the access fragment analyzer 405 checks the transmission scheme and recognizes that a communication system or protocol is being used. After recognizing that it is preferable to accept the service using a particular communication system or protocol, the access fragment analyzer 405 analyzes, in step 511, the address of the server that transmits the service via an interactive channel, and prepares to transmit the service request. The addressing system may differ in accordance with a communication system and a protocol using an interactive channel. After that, at step 513, the access fragment analyzer 405 checks the UsageInfo service usage information, and if there is a characteristic description for the access fragment and many access fragments for one service, the access fragment analyzer 405 recognizes the characteristic and correlation for each of them, and mobile the terminal displays a corresponding description for the user who will receive the service so as to allow him to make the appropriate choice.

At step 515, the access fragment analyzer 405 checks the transmission topology, analyzes information indicating whether the service will be broadcast or multicast, and is prepared to perform an operation appropriate for the analysis result. For a service transmitted in the broadcast mode, the mobile terminal can receive the corresponding service without joining the service. However, for a service transmitted in multicast mode, the mobile terminal should preferably perform the Joining process for the IP multicast group of the IP stream in which the service is transmitted to receive it.

At step 517, the access fragment analyzer 405 checks the IP address of the stream in which the service is being transmitted. The IP address of the stream is very important for the mobile terminal assigned to receive the service in the process of distinguishing between the IP stream in which the service is transmitted. If an IP stream address is not provided, the mobile terminal preferably should perform the operation of receiving all IP streams transmitted over the broadcast channel, and the operation of determining whether the corresponding service is the desired service for each IP stream. The IP stream address is connected to the communication channel by the IP layer and indicates which communication channel the mobile terminal should receive in order to receive the IP stream. The method may be different for each broadcast system providing a broadcast channel, which is beyond the scope of the present invention, and therefore the corresponding detailed description of this is not given.

After step 513, the access fragment analyzer 405 checks, at step 519, information regarding a communication session in which a service for which access information is provided from the access fragment is transmitted, and allows the mobile terminal to prepare to receive a session in which the service is actually transmitted. Thereafter, at step 521, the access fragment analyzer 405 analyzes other information provided from the access fragment and uses the associated information for an appropriate purpose. At step 523, the access fragment analyzer 405 prepares to access and receive the service in accordance with the information analyzed from the access fragment, and then ends the operation.

Second exemplary implementation

Further, in connection with Tables 15-18 and FIG. 6 and 7, a description is given of a method for transmitting / receiving an access fragment in accordance with a second exemplary embodiment of the present invention.

In Tables 15-18, for example, shows the format of the access fragment in accordance with the second embodiment of the present invention. The difference in the access fragment between the first embodiment and the second embodiment is the information of the same access fragment that is used for many different services, and an effective structure for this is proposed by the second embodiment. The definition of the items in each Table essentially coincides with the definition of Table 1, and therefore, a detailed description of the same parts in Tables 15-18 and Tables 8-14 is not given.

In addition, compared with attributes or elements defined in Tables 8-14, unchanged portions of Tables 15-18 are not shown for simplicity.

Table 15 Name Type of Category Cardinal number Description Data type * 01 Access A O 0 ... N Access fragment
Contains the following attributes:
id
version
validFrom
validTo
ServiceProtection
Contains the following subelements:
TerminalCapabilityRequirement
Bandwidthrequirement
AccessType
Service id
ExtensionURL
Usageinfo
SessionDescriptionURI
SDP
ApplicationSpec
Mediainformation * 02 Id A M one Access Fragment ID Integer * 03 version E M one Version of this snippet. A newer version cancels the old one as soon as it is received. Byte (8 bit) * 04 validFrom A O 0 ... 1 The first moment when this fragment is valid. If not, accessibility is assumed from some time in the past. Integer (32 bits) expressed as NTP * 05 validTo A O 0 ... 1 The last moment when this fragment is valid. If this is not the case, availability is assumed to end at an undetermined time in the future. Integer (32 bits) expressed as NTP time * 06 ServiceProtection A M one If true, this indicates that this access associated with the corresponding service is protected from unauthorized access by the OMA BCAST Protection Service; if false, then this indicates that this access associated with the corresponding service is not protected by OMA BCAST Protection Service Boolean

In Table 15, the access fragment proposed by the second embodiment contains the attributes "Id" * 02, "version" * 03, "validFrom" * 04, "validTo" * 05, and "ServiceProtection" * 06, as defined in "Access", indicated number * 01. Five attributes represent unique attributes for an access fragment, and their functions essentially coincide with those of the attributes having the same names in Table 2. Additionally, the access fragment proposed in the second embodiment contains "TerminialCapabilityRequirement" * 07, "BandwidthRequirement" * 08, "AccessType" * 09, "ServiceID" * 17, "ExtensionURL" * 18, "UsageInfo" * 19, "SessionDescriptionURI" * 21, "SDP" * 23, "ApplicationSpec" * 24 and "MediaInformation" * 25 , as its subelements, as defined in "Access" * 01.

Table 16 * 07 TerminalCapabilityRequirement E1 O 0 ... 1 A specification of the necessary terminal capabilities for this access, for example, protocols, codecs, bit rate, processing and memory; Line * 08 Bandwidthrequirement E1 O 0 ... 1 The specification of the required network bandwidth for access described in this snippet.
A broadcast service may include multiple available streams (of the same content) with different bandwidths so that the terminal can make a choice depending on its current reception mode. Integer * 09 AccessType E1 M one Defines the type of access;
Contains the following attributes:
TransmissionMedia
Contains the following elements:
TransmissionTopology
TransmissionScheme *10 Transmission_Media A M one This attribute indicates which channel is used to deliver services whose IDs are listed in this Access Fragment.
0: Broadcast Channel
1: Interactive Channel Integer *eleven Transmission_Topology E2 O 0 ... 1 This item is used to indicate the IP broadcast mode of the Broadcast Channel.
There are two possible modes.
0: Broadcast Mode
one; Multicast Mode
Contains the following attributes:
IP Address Integer *12 IP_Address A O 0 ... 1 IP address of the IP stream that carries the Service over the Broadcast Channel. If the Transfer Topology is 0, then the IP Address Type is the IP Broadcast Address.
If the Transmission Topology is 1, then the IP Type is a multicast IP address.
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. Line *13 Interaction Scheme E2 O 0 ... 1 This element indicates which communication system, or protocol, is used for Interaction. Integer

"TerminalCapabilityRequirement" * 07 in Table 16 indicates the requirement for a mobile terminal that receives a service through an access fragment, and "BandwidthRequirement" * 08 indicates a frequency band in a wireless service channel received through an access fragment. "AccessType" * 09, provided to indicate in which way the mobile terminal will receive the service, is used to indicate whether the service is transmitted on a broadcast channel or transmitted on an interactive channel provided on a mobile communication network, and also to indicate with which protocol or The system transmits the mobile terminal service. To this end, in the second embodiment, an “AccessType” consists of one attribute and two subelements.

Thus, the "Transmission_Media" * 10 in Table 16 is an attribute indicating whether the service is broadcast or provided from a communication network suitable for bidirectional communication, and the type of sub-element that can be included in the "AccessType" is determined in accordance with attribute value. If "Transmission_Media" indicates that the service is broadcast, "AccessType" contains "Transmission_Topology" * 11 and "IP_Address" * 12 as its sub-elements.

The "Transmission_Topology" in Table 16 is an element indicating whether the service transmitted on the broadcast channel is transmitted in broadcast mode or multicast mode. The broadcast mode and multicast mode are used in the Internet Protocol, and if "Transmission_Topology" indicates the broadcast mode, this means that the service is transmitted to a specific area regardless of the position of the recipient of the service.

If "Transmission_Topology" indicates a multicast mode, this means that the service is transmitted to the place where the recipient of the service is located within the service area in accordance with the location information of the recipient of the service. In addition, when "Transmission_Topology" indicates a multicast mode, a mobile terminal suitable for receiving a broadcast service should preferably make a subscription request for the IP address of the multicast mode and receive the broadcast service.

"IP_Address" * 12 in Table 16, since the service is transmitted to the mobile terminals as an IP stream in a broadcast system, is an attribute indicating an address for the IP stream. "IP_Address" becomes the IP broadcast address or multicast IP address in accordance with the value of "Transmission_Topology". Usually, the IP address of the service is indicated in the session description. However, when the session description is not transmitted along with the access fragment, it should preferably be provided to the mobile terminal to identify the service at the IP level.

If the attribute "Transmission_Media" * 10 in Table 16 indicates an Interactive Channel, "Interaction_Scheme" * 13 is included in "AccessType" * 09, and "Interaction_Scheme" has a substantially equivalent "Transmission_Scheme" value described in the first embodiment. In the second embodiment, "Transmission_Scheme" has "AccessServerIPAddress" * 14, "AccessServerURL" * 15, and "AccessServerPhoneNumber" * 16, as its subelements.

"Transmission_Scheme" is an element indicating a communication system or protocol used in an interactive channel when it is possible to accept access to a service through an interactive channel. Although OMA BCAST currently defines, for example, Web Browsing, Multimedia Messaging Service (MMS), Wireless Access Protocol 1.0 (WAP1.0), Wireless Access Protocol 2.x (WAP 2.x), Short Message Service ( SMS) and Hypertext Transfer Protocol (HTTP) as communication systems or protocols that can be used for an interactive channel, further communication systems and protocols that can be used for an interactive channel, may be added in the future.

Table 17 Channel.
1: Interactive Channel provided by Interactive Network
2: MMS
3: WAP 1.0
4: WAP 2 x
5: SMS
6: HTTP
7: Service Provider defines Transfer Scheme *fourteen AccessServerIPAddress E3 O 0 ... N The IP address of the Server that provides various access (via the Interactive Channel) Services. Line *fifteen AssServerURL E3 O 0 ... N ULR Server, which provides various access (Interactive Channel) Services. AnyURI *16 AsserServerPhoneNumber E3 O 0 ... N Phone number of the Server that provides various access (via the Interactive Channel) Services Integer * 17 Serviceid E1 M 0 ... N Link to the service fragment (s) to which the access fragment belongs. Integer *eighteen ExtensionURL E1 O 0 ... N URL containing additional information in the extension fragment. AnyURI *19 Usageinfo E1 O 0 ... N This text helps the user understand what is the difference in the use of one or the other access fragment. This is necessary if more than one access fragment is available at a given time point.
Possibly provided in multiple languages.
aAttributes:
Lang *twenty Lang A O 0 ... 1 Language 3-byte ISO 639 language code * 21 SessionDescriptionURI E1 O 0 ... 1 URIs to the delivery unit (s) SG, which contain a session description that the application environment in the terminal uses to access the service. In the case of a non-broadcast service, SessionDescriptionURI contains information on how this particular service may be available.
Contains the following Attribute: AnyURI

In Table 17, "AccessServerIPAddress" * 14, "AccessServerURL" * 15 and "AccessServerPhoneNumber" * 16 are elements indicating the address of the server that provides the service via the interactive channel to indicate whether the mobile terminal receiving the access fragment can accept the service through the interactive channel anywhere. Since the addressing system used in each communication system or protocol is different, a representative addressing system for the communication system and protocol is presented, and is being adapted to maintain an interactive channel.

"AccessServerIPAddress" * 14 is an element indicating the location of the server based on the Internet Protocol, "AccessServerURL" * 15 is an element indicating the location of a server that uses a communication system or protocol that supports a Web or URL, and "AccessServerPhoneNumber" * 16 is an element, indicating the location of the server, which allows access to the service using MMS or SMS. Additionally, a new communication system or protocol is added to "Interaction_Scheme" * 13 in Table 16, and if the addressing system of the communication system or protocol is different from the one currently provided, then the new addressing system can be added as a sub-element of "Interaction_Scheme".

In Table 17, “ServicelD” * 17 indicates a service identifier that can be accessed using access information provided from an access fragment, and when multiple services use the same access, multiple “ServiceIDs” may exist. "UsageInfo" * 19 is an element for providing the user with a description of the characteristics of the access fragment of the mobile terminal, especially an element that can be used to describe the characteristics and correlation of each access fragment for the user, even when there are many access fragments for one service, providing sub-services having different characteristics . "UsageInfo" has "Lang" * 20 as an attribute.

Table 18 Type of
Note: Using either SessionDescriptionURI or SDP is required. * 22 Toure A M one Type AccessURI
1 - SDP; AccessURI is a reference for describing SDP;
2 - MBMS-USD; AccessURI is a reference for the MBMS Custom Service Description (MBMS-USD), as defined in [26.346] section 5.2. May contain one or more SDP descriptions. Integer * 23 SDP E1 O 0 ... 1 Session Description in SDP (IETF Session Description Protocol) format. String (in SDP format) * 24 ApplicationSpec E1 O 0 ... N The type of application that can consume a service using this access specification defined by the MIME type. Line * 25 Mediainformation E1 O 0 ... N Possible link to an image, icon, animation or sound. PreviewData or a link to PreviewData are used here.
Attributes:
usage
id * 26 Usage A M one Possible values: background, image (for example). Integer (8 bits) * 27 Id A M one ID of the PreviewData fragment. Integer (8 bits) * 28 <proprietary elements / attributes> E1 or lower. A O 0 ... N Any number of internal or application-defined elements or attributes that are not defined in this specification.

In Table 17 and Table 18, "SessionDescriptionURI" * 21, "Type" * 22, "SDP" * 23, "ApplicationSpec" * 24, "MediaInformation" * 25, "Usage" * 26, "Id" * 27 and " <proprietary elements / attributes> "* 28 have essentially the same functions as those of a regular access fragment, and therefore a detailed description of them is not given.

6 is a flowchart of a process for generating and transmitting an access fragment in an OMA broadcast system in accordance with a second embodiment of the present invention. This process corresponds to the operation of the access fragment generator 201 in the transmitter of FIG. 2.

With respect to FIG. 6, the access fragment generator 201 determines in step 601 whether there is a need to produce a new access fragment. If there is a need to produce a new access fragment, this means that a new service is starting, or that there is a need to provide a new additional service or a new access method for the current service to a mobile terminal receiving a broadcast service. If it is determined in step 601 that there is a need to produce a new access fragment, the access fragment generator 201 sets the basic information for the access fragment in step 603. The basic information contains at least one of “Id”, “version”, “validFrom” and "validTo", all related to the validity of the access fragment, "ServiceProtection" indicating whether the Service Protection is applied, "TerminalCapabilityRequirement" indicating the requirement of the mobile terminal intending to have access to the service, and "BandwidthRequirement" indicating the data transfer rate of the service to the demon rovodnom channel - all described in connection with Table 15 and Table 16.

In step 605, the access fragment generator 201 determines whether a service that can be accessed through the corresponding access fragment will be transmitted on a broadcast channel or an interactive channel. If the service is transmitted on an interactive channel, the access fragment generator 201 proceeds to step 607. However, if the service is transmitted on a broadcast channel, the access fragment generator 201 proceeds to step 613.

The access fragment generator 201 sets the transmission scheme for the used communication system or protocol in step 607 and sets the address for the corresponding communication system or protocol in step 609. Then, in step 611, the access fragment generator 201 sets at least one service ID that can be accessible using the information provided in the access fragment.

At step 613, the access fragment generator 201 sets transmission topology information indicating whether the corresponding access or service using the access is transmitted in broadcast mode or multicast mode. The mode-related information is determined by the transmission entity or the service providing the entity, and the access fragment generator 201 receives the regime-related information provided from the corresponding entity and sets transmission topology information depending on the information associated with the mode. At step 615, the access fragment generator 201 sets the IP information of the IP stream in which the service is transmitted, and then proceeds to step 611.

Then, at step 617, the access fragment generator 201 sets the UsageInfo service usage information, and if there is a characteristic description for the corresponding access fragment and the multiple access fragments for one service, the access fragment generator 201 adds a description of the characteristic and correlation for each of them to the access fragment so that the recipient of the broadcast service can detect the difference.

At step 619, the access fragment generator 201 sets information regarding a communication session in which a service is transmitted whose access information is provided through the corresponding access fragment. Session information contains the IP address of the sender, the IP address of the recipient, the type of data transmitted in the communication session, and the codec used. The Session Description Protocol defined by the IETF is a typical example of session information. Then, at step 621, the access fragment generator 201 sets up other information constituting the access fragment, and then ends the operation.

7 is a flowchart of a process for receiving and analyzing an access fragment in a broadcast system in accordance with a second embodiment of the present invention. This process corresponds to the operation of the access fragment analyzer 405 in the receiver of FIG. 4.

Regarding FIG. 7, the access fragment analyzer 405 determines in step 701 whether there is any new received access fragment. The definition criterion is the "version" attribute of the received access fragment. If it is determined at step 701 that there is any received access fragment, the access fragment analyzer 405 analyzes, at step 703, the basic information of the access fragment, determines the valid period of the access fragment in the basic information, and recognizes that the information provided through the access fragment valid only during the valid period. Using basic information, the access fragment analyzer 405 determines whether the service provided by the access fragment has been protected against unauthorized access before being transmitted. If the service has been protected against unauthorized access, the access fragment analyzer 405 prepares to perform the corresponding operation so that it is possible to correctly accept the service provided through the relevant access information. In addition, the access fragment analyzer 405 checks the basic attribute for the corresponding access information and compares the operational state of the mobile terminal required by the service based on the access information with the operational state of the current mobile terminal to determine if the service is being received. Additionally, if there are several access fragments for the same service, taking into account the frequency band in the wireless channel in which the service is provided based on access information, the access fragment analyzer 405 may select the corresponding access fragment determined taking into account the operation of the mobile terminal and accept service in accordance with the information provided from the access fragment.

At 705, the access fragment analyzer 405 determines whether the access information for receiving at least one service is information for a broadcast channel, or for an interactive channel. If the access information is information for the interactive channel, the access fragment analyzer 405 proceeds to step 707. However, if the access information is information for the broadcast channel, the access fragment analyzer 405 proceeds to step 713.

At step 707, the access fragment analyzer 405 checks the transmission scheme and recognizes the communication system or protocol used. After recognizing that there should be access to the corresponding service using a specific communication system or protocol, the access fragment analyzer 405 analyzes, at step 709, the address of the server that provides the corresponding service via an interactive channel, and prepares to transmit the service request. The addressing system can be distinguished in accordance with the communication system and protocol using an interactive channel.

Then, at step 711, the access fragment analyzer 405 checks the UsageInfo service usage information for at least one service that may be available with access information, and if there is a characteristic description for the access fragment and multiple access fragments for one service , or if there is one access fragment for many services, the access fragment analyzer 405 recognizes the characteristic and correlation for each of them, and the mobile terminal shows a corresponding description for the user who received Provides a service to allow the user to make an appropriate choice.

At step 713, the access fragment analyzer 405 checks the transmission topology, analyzes information indicating whether the service will be broadcast or multicast, and is prepared to perform an operation corresponding to the analysis result. For a service transmitted in the broadcast mode, the mobile terminal may receive the corresponding service without combining it with the service. However, for a service transmitted in a multicast mode, the mobile terminal preferably should perform the Unification process for the group IP address of the IP stream in which the service is transmitted in order to receive the service.

At step 715, the access fragment analyzer 405 checks the IP address of the stream against access information at which access to the corresponding service is possible. The IP address of the stream is very important for the mobile terminal assigned to receive the corresponding service in the process of distinguishing the IP address from which access to the service is possible. If an IP stream address is not provided, the mobile terminal should preferably perform the operation of receiving all IP streams transmitted over the broadcast channel and determining the IP address for the desired service. The IP stream address is connected to the communication channel at the IP level and indicates which carrier of the communication channel the mobile terminal should receive in order to receive the IP stream. The method may be different in each communication system providing a broadcast channel, which is beyond the scope of the present invention, and therefore, a detailed description is not given.

After determining the IP address of the stream at step 715, the access fragment analyzer 405 proceeds to step 711, where it checks and displays the service ID and service usage information. At step 717, the access fragment analyzer 405 checks information regarding the communication session in which the service (s) is transmitted, the access information of which is provided from the access fragment, and allows the mobile terminal to prepare to receive the communication session in which the service is actually transmitted. Then, at step 719, the access fragment analyzer 405 analyzes other information provided from the access fragment and uses the corresponding information for the corresponding task. At step 721, the access fragment analyzer 405 prepares to access and receive the service in accordance with the information analyzed from the access fragment, and then ends the operation.

Third Exemplary Embodiment

Next, in connection with Tables 19-37, a method for providing access information for transmitting a service through a broadcast network and transmitting a service through an interactive network in accordance with a third exemplary embodiment of the present invention is described.

As described in the first and second exemplary embodiments, the access fragment provides access information that the mobile terminal uses to access the service.

In Table 19 and Table 20 below, "Id", "version", "validFrom" and "validTo" indicate the basic ID information, version and valid period for the access fragment, respectively. In Table 20, the "AccessType" contains detailed information about the access of the service in the broadcast network, or in the interactive network. In Table 26, the KeyManagementSystem contains information indicating during service access whether the corresponding service is encrypted or whether the corresponding content is encrypted, and also contains information regarding the method used to encrypt. In Table 29, “AlternativeAccessURI” contains information regarding the address that can be accessed through the interactive network in case the mobile terminal has difficulty accessing the corresponding broadcast network when the “AccessType” of Table 20 contains information of the broadcast network. The “TerminalCapabilityRequirement" in Table 30 and the "BandwidthRequirement" in Table 35 indicate the requirement of the mobile terminal to access the corresponding service and information about the service bandwidth, respectively.

In Table 35, “ServiccClass” indicates the purpose of using the corresponding access fragment, that is, receiving the service guide, file transfer, stream transfer, etc. In Table 37, “NotificationReception” contains address information for receiving notification messages.

Next, the “AccessType” in Table 20 is described in more detail in accordance with embodiments of the present invention. "AccessType" contains detailed information for access services. That is, the corresponding “AccessType” indicates whether the access information is for the broadcast network, or for the interactive network, according to the “transmissionMedia” information in Table 20. If “transmissionMedia” is the access information for the broadcast network, the “AccessType” contains only the "BroadcastServiceDelivery" information of Table 20, and if "transmissionMedia" is access information for the interactive network, the "AccessType" contains only the "UnicastServiceDelivery" information of Table 24.

In Table 20, "transmissionMedia" used to distinguish between a broadcast network and an interactive network can be included in the "AccessType" if necessary. Even when "transmissionMedia" is not enabled, only one "BroadcastServiceDelivery" information of Table 20 for access to the broadcast network and "UnicastServiceDelivery" information of Table 24 for access to the interactive network is included in the "AccessType", and the mobile terminal can determine whether it will have access to the broadcast network, or to the interactive network, by determining what information is included in the "AccessType".

The BroadcastServiceDelivery information contains detailed access information related to the broadcast network, and based on the “bdsType” of Table 21, the mobile terminal can determine through which broadcast network the service is received. For example, if "bdsType" is 0, the mobile terminal is served through the DVB-H IPDC, and the values defined in "BroadcastServiceDelivery" contain detailed information about what the mobile terminal uses the DVB-H IPDC for access and accepts the service.

"destinationIPAddress" in Table 21 denotes the IP address used to receive the service through the broadcast network, and the mobile terminal has access to the corresponding address and receives the service. Corresponding address information is used when the “SessionDescriptionReference” or Table 22 SDP information is not included. When the "SessionDescriptionReference" or SDP is turned on, the mobile terminal checks the address value and detailed access information in the corresponding SDP information, and has access to the broadcast network.

"UnicastServiceDelivery" in Table 24 indicates access information for a case where a mobile terminal receives a service through an interactive network. The detailed address information used by the mobile terminal to receive the service is defined in the “AccessServerURL” of Table 24. In addition, the “transmissionSchemeType” in Table 25 indicates the transport mechanism used to access the corresponding “AccessServerURL” and download the service, and the transport mechanism indicates information regarding HTTP , MMS, WAP, etc. For example, if "transmissionSchemeType" is 0, the mobile terminal has access to the corresponding "AccessServerURL" address using HTTP and accepts the service.

Table 19 Name Type of Category Cardinal number Description Data type Access E Access fragment
Contains the following attributes:
id
version
validFrom
validTo
Contains the following subelements:
AccessType
ServiceAcces sNotificationURL
KeyManagementSystem
TerminalBindingKeyID
ExtensionURL
SeiviceIDRef
Scliedulereference
Usageinfo
AlternativeAccessURL
TerminallCapabilityRequirement
Bandwidthrequirement
Serviceclass
PreviewDataIDRef
NotificationReception Id A NM / TM one Access fragment ID globally unique Any URI version A NM / TM one Version of this snippet. A newer version cancels the old one as soon as it is accepted. unsigned int (32 bits) validFrom A NO / TM 0 ... 1 The first moment when this fragment is valid. If this is not the case, accessibility is assumed to begin at some point in the past. (32 bits), expressed as NTP time.

Table 20 validTo A NO / TM 0 ... 1 The last moment when this fragment is valid. If this is not the case, availability is assumed to end at an undetermined time in the future. An integer (32 bits) expressed as NTP time. AccessType E1 NM / TM one Defines the type of access.
Contains the following Attribute:
transmissionMedia
Contains the following elements:
BroadcastServiceDelivery
UnicastserviceDelivery transmissionMedia A NM / TM one This attribute indicates which channel is used to deliver the service.
0: Broadcast Channel
1: Interactive Channel Boolean BroadcastServiceDelivery E2 NO / TM 0 ... 1 This item is used to indicate IP transmission.
This item may be present only when:
TransmissionMedia = 0.
Contains the following Attribute:
bdsType
destinationIPAddress
Contains the following elements:
SessiouDescriptionReference
SDP

Table 21 bdsType A NO / TM 0 ... 1 The identifier of the type of the main distribution system to which this access fragment belongs. This attribute can only be present when:
TransmissionMedia = 0.
Specific values
0: DVB-H IPDC
1: 3GPP MBMS Rel-6
2: 3GPP MBMS Rel-7
3: 3GPP2 BCMCS (lx)
4: 3GPP2 BCMCS (HRPD)
5: 3GPP2 Advanced BCMCS (HRPD)
6-127: saved for future use
128-255: saved for internal use unsignedByte destinationIPAddress A NO / TM 0 ... 1 DestinationIP address of the IP stream that transports the A 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. line

Table 22 Communication session
Description
Link E3 NO / TM 0 ... N The link to SessionDescription this access refers to.
Note: SessionDescription itself can be delivered in two ways - through broadcasting, or through a call through an interactive channel.
In the case of broadcast delivery, the SessionDescription fragment is either delivered to the SGDU or placed in this Access fragment. In the latter case, the SDP element is used instead of the Session Description Label.
If AuxiliaryDescription fragments are provided, they are referred to as SessionDescriptionReference.
In the case of an interactive call, a Session Description can be obtained by URI access (given as an attribute of this element).
Contains the following attributes:
type
uri
idRef

Table 23 type A NM / TM one The type of session description indicated by this SessionDescriptionReference.
0 - SDP
1 - Description of the MBMS User Services (MBM3-USD), as defined in [26.346] section 5.2. It may contain one or more SDP descriptions.
2 - AssociatedDeliveryProcedure for File Distribution
3 - AssociatedDeliveryProcedure for Stream Distribution
4-127 Saved for future use.
128-255 Saved for internal use. Unsigned byte uri A NO / TM 0 ... 1 The URI for the file containing the SessionDescription that the application environment in the terminal uses to access the service or the URI for the associatedDeliveryProcedure for File and Stream Distribution. anyURI idRef A NO / TM 0 ... 1 The id of the SessionDescription fragment accessed by this access is globally unique. anyURI SDP E3 NO / TM 0 ... 1 Session Description in SDP (IETF Session Description Protocol) format. line

Table 24 UnicastServiceDelivery E2 NO / TM 0 ... N This element indicates which server and / or protocol are used to deliver the service over the Interactive Channel.
This item may be present only when:
TransmissionMedia = 1.
Contains the following elements:
AccessServerURL AccessServerURL E3 NO / TM 0 ... N The URL of the server from which the terminal can receive the service through the Interactive Network.
For example, AccessServerURL could be an HTTP URL that points to downloadable content, or an RTSP URL that points to a streaming server to start a streaming session.
Contains the following Attribute:
transmissionSchemeType anyURI

Table 25 transmissionSchemeType A NM / TM one Defines the transport mechanism used for this access.
0-http
1 - MMS
2-WAP 1.0
3 - WAP 2.x
4 - RTP
5 - 3GPP-PSS (3GPP packet-switched streaming service)
6 - 3GPP2-MZU (3GPP2 multimedia streaming services)
unsignedByte
7 - 3GPP CS video telephony (3GPP Switchable H324m Calling Scheme)
8 - FLUTE
9-127 Saved for future use.
128-255 Saved for internal use.
(Note: Another protocol or communication system may be added based on the interactive OMA Service function). unsignedByte ServiceAccessNotificationURL E1 NO / TM 0 ... N The URL that the terminal can use to notify when it accesses (switches to) this service. The terminal should not use this URI for notification without the consent of the user.
Note: This URL can, for example, be used to initiate server-controlled channel switching in unicast transmission. anyURI

Table 26 KeyManagementSystem E1 NO / TM 0 ... N Identifies the type of Key Management System (s) that can be used to contact Right Issuer and GBA, or GBA_U is required, or GBA_ME or GBA_U can be used.
Note that Right Issuer can support more than one KMS.
If KeyManagementSystem is not defined, this means that protection is not applied.
Values:
oma-bcast-drm-pki
Indicates OMA DRM PKI (Public Key Infrastructure);
oma-bcast-gba_u-mbms
Indicates GBA_U 3GPP MBMS SKI (Symmetric Key Infrastructure);
oma-bcast-gba_me-mbms
Indicates GBA_ME 3GPP, MBMS SKI, that is, either GBA_ME or GBA_U can be used;
oma-bcast-gba_u-mbms
Indicates GBA_U 3GPP2 BCMCS SKI;
oma-bcast-gba_me-mbms
Indicates GBA_ME 3GPP2, BCMCS SKI, that is, either GBA_ME or GBA_U can be used;
oma-bcast-prov-bcmcs
Indicates provided by 3GPP2 BCMCS SKI.
Contains the following attributes:
ProtectionType
RightsIssuerURI

Table 27 ProtectionType A NM / TM 1 ... 2 Defines the type of protection offered by KMS.
Values:
1 Content Protection Only
2 Protection Services Only
3 Both content protection and Service Protection
4 Using terminal binding (smart card profile only)
5-127 Saved for future use.
128-255 Saved for internal use unsignedByte (8 bits) RightsIssuerURI A NM / TM one Defines URI RightsIssuer anyURI TerminalBindingKeyID E1 NO / TM one A number that identifies the Terminal Binding Key ID (TBK ID) that is required to access the service.
TM for terminals with a smart card profile.
Not applicable to DRM profile.
Contains the following possible Attribute:
RightsIssuerURI integer (32 bits) RightsIssuerURI A NO / TM 0 ... 1 Defines the RightsIssuer URI for the TerminalBindingKey if it is different from the RightsIssuerURI specified in the KeyManagementSystem element.
that is, if the attribute is not present, the same RightsIssuerURI is used to get both SEK / REC and TerminalBindingKey. anyURI

Table 28 ServiceIDRef E1 NO / TM 0 ... N Link to the service fragment (s) to which the access fragment belongs.
Either ServiceIDRef, or ScheduleIDRef, but not both together, must be assigned.
Note: Implementation in an XML Schema using <choice>.
Each fragment of the Services will be associated with at least one Access fragment in order to allow the terminal to have access to the Service. anyURI ScheduleReference E1 NM / TM 0 ... N Link to the schedule fragment (s) to which the access fragment belongs.
This provides a link to the Schedule fragment to temporarily override the default Access fragment of the Service addressed by the Schedule.
Either ServiceIDRef or ScheduleIDRef, but not both should be assigned together. Note: Implementation in an XML Schema using <choice>.
Contains Attribute:
idRef
Contains subelement:
DistributionWindowID

Table 29 idRef A NM / TM one Identification of the Schedule fragment to which the Access fragment relates. anyURI DistributionWindowID E2 NO / TM 0 ... N A reference to the DistributionWindowID relation to which the access fragment belongs.
The DistributionWindowID declared in this element must be the complete collection or subset of the DWids declared in the Schedule fragment to which "idRef" belongs. whole Usageinfo E1 NO / TM 0 ... N This text helps the user understand what difference is made to use one or the other access fragment. Mandatory if more than one access fragment is available at a given time point.
Possibly provided in multiple languages. The language is expressed using the built-in xml attribute XML: lang with this element. line AlternativeAccessURL E1 NO / TM 0 ... N Define an alternative URL for the content to be restored through the interactive channel (for example, if the content cannot be received through the broadcast channel). anyURI

Table 30 TerminalCapabilityRequirement E1 NO / TM 0 ... 1 Terminal capabilities required to consume a service or content.
For video and sound, the medium type and the corresponding attribute type in the SDP (see section 5.1.2.5) of the audio / video decoder signal. In this case, these parameters complement TerminalCapabilityRequirement. Additionally, the complexities of audio / video streams are described here if they differ from the complexities that can be obtained from the environment attributes in the SDP (e.g. level). In this case, the parameters defined in the Access fragment take precedence.
Subelements:
Video
Sound
Downloadfile Video E2 NO / TM 0 ... 1 Corresponding requirements of video codec capabilities.
Subelements:
Complexity

Table 31 Complexity E3 NO / TM 0 ... 1 Accounting for the complexity of the video decoder. It is recommended that this item be included if the complexity indicated by the MIME type parameters in the SDP is different from the actual complexity.
Subelements:
Bit rate
Resolution
MinimumBufferSize Bit rate E4 NO / TM 0 ... 1 Full bit rate of the video stream
Attributes:
average
maximum average A NO / TM 0 ... 1 Average data rate Kbps unsigned Short (16 bit) maximum A NO / TM 0 ... 1 Maximum data rate Kbps unsigned Short (16 bit)

Table 32 Resolution E4 NO / TM 0 ... 1 Video resolution.
Attributes:
horizontal
vertical horizontal A NM / TM one Horizontal video resolution unsigned Short (16 bit) vertical A NM / TM one Vertical resolution video unsigned Short (16 bit) Minimum BufferSize E4 NO / TM 0 ... 1 The minimum decoder buffer size required to process video content in kilobytes. unsigned integer (32 bits) Sound E2 NO / TM 0 ... 1 Possibility of audio codec.
Subelements:
Complexity

Table 33 Complexity E3 NO / TM 0 ... 1 The complexity of the audio decoder is taken into account. It is recommended that this item be enabled if the complexity indicated by the MIME type parameters in the SDP is different from the actual complexity.
Subelements:
Bit rate
MinimumBufferSize Bit rate E4 NO / TM 0 ... 1 Full bit rate of the audio stream.
Attributes:
average
maximum average A NO / TM 0 ... 1 Average bit rate in Kbps. unsignedShort (16 bit) maximum A NO / TM 0 ... 1 Maximum bit rate in Kbps unsignedShort (16 bit) MinimumBufferSize E4 NO / TM 0 ... 1 The minimum decoder buffer size required to process video content in kilobytes. unsignedInt (32 bits)

Table 34 Downloadfile E2 NO / TM 0 ... 1 Required file upload capability.
Subelements:
MIMETypeSet MIMETypeSet E3 NO / TM 0 ... N Assuming that a service download consists of a series of files with various MIME types that together make up the service, the terminal must support all of these MIME types in order to be able to provide the service to the user.
MIMETypeSet lists all of these MIME types. If the terminal does not support one or more MIME types, then it will probably not be able to provide the service.
Subelements:
Type Type E4 NO / TM 0 ... N One type of MIME in a MIMETypeSet. The format of this line must follow the syntax of the Content in [RFC 2045].
Contains the following attributes:
Codec line

Table 35 Codec A NO / TM 0 ... 1 Codec parameters for the corresponding MIME type. If the definition of the MIME file type defines the required parameters, they should be included in this line. Additional parameters containing information that can be used to determine whether the terminal can use the file should be included in the string. One example of the parameters defined for audio / 3GPP, audio / 3GPP2, video / 3GPP, video / 3GPP2 is given in [RFC4281]. line Bandwidthrequirement E1 NO / TM 0 ... 1 The specification of the required network bandwidth for access described in this snippet;
A broadcast service may include multiple available streams (of the same content) with different bandwidths so that the terminal can make a choice depending on its current reception status. integer Serviceclass E1 NM / TM 1.N ServiceClass identifies the class of service. This identification is more detailed than the type attribute in the service fragment, and allows connection with the service / access combination for specific applications. line

Table 36 PreviewDataIDRef E1 NO / TM 0 ... N Link to the PreviewData fragment that defines the image, icon, animation or sound,
Attribute:
usage anyURI usage A NM / TM one Possible values:
0. not set
1. background
2. Image / logo
3. emblem
4. trailer
5. heading
6. choice of service / channel
7-127. saved for future use
128-255. saved for internal use
Note: only usage = 6 (service / channel selection) is a valid value when the preview data is associated with the Access fragment. unsignedByte (8 bits)

Table 37 Reception Notice E1 NO / TM 0 ... 1 Reception information for Notification Messages.
NotificationPort is mandatory because the configured UDP Port must be used to deliver a notification message through an ongoing communication session or a designated communication session, while NotificationAddress may be used to deliver a Notification Message through a designated multicast or broadcast communication session.
Contains the following attributes:
NotificationPort
NotificationAddress
NotifiсationRequestURL
NotificationPollURL Port Notification A NO / TM 0 ... 1 Service-specific delivery of UDP Port Number Notification Messages. integer Notification Address A NO / TM 0 ... 1 Service-specific delivery of IP Multicast IP Notification Message.
Note: If the Notification Message is delivered via an interactive channel, this attribute must be combined with the NotificationPort. RequestURL Notification A NO / TM 0 ... 1 URL through which the terminal can subscribe to the Notification Messages defined for the service. anyURI PollURL notice A NO / TM 0 ... 1 The URL through which the terminal can poll service-specific Notification Messages. anyURI <internal elements / attributes> E1 or lower
A NO / TO 0 ... N Any number of internal elements or application-defined elements or attributes that are not defined in this specification.

As can be understood from the above description, embodiments of the present invention can provide detailed information about access to a broadcast network or an interactive network through which a broadcast service is transmitted in a broadcast system providing IP-based broadcast services.

Embodiments of the present invention can provide detailed access information of a broadcast network or an interactive network through which a service is transmitted to a mobile terminal by providing an effective access fragment format in a broadcast system providing IP-based broadcast services.

Additionally, embodiments of the present invention can provide an effective access fragment format when accessing multiple services through a single access fragment.

In addition, embodiments of the present invention provide a method and device for transmitting / receiving an access fragment to efficiently maintain the topology of the scheme / transmission and protocol for each individual channel over which the service is transmitted during the configuration of the Access Type of the access fragment, thereby allowing the mobile terminal to efficiently access to the service.

In addition, embodiments of the present invention provide multicast IP transmission to a mobile terminal in a broadcast system requiring a high data rate, contributing to the reduction of required wireless resources.

Although the invention has been considered in connection with certain exemplary embodiments, it will be apparent to those skilled in the art that various changes in form and detail are possible without departing from the spirit and scope of the invention, as defined in the appended claims and their equivalents.

Claims (65)

1. A method for transmitting information about access to a broadcast service in a transmitter of a broadcast system, comprising the steps of:
generating access information for at least one network from the broadcast network and the interactive network through which the broadcast service is transmitted, and
transmit access information to the terminal through a given communication network. 2. The method according to claim 1, wherein when the broadcast service is provided through a broadcast network, the access information comprises an Internet Protocol (IP) address for accessing the broadcast service. 3. The method of claim 1, wherein when the access information comprises a Session Description Protocol (SDP), the IP address in the SDP is used as the IP address. 4. The method according to claim 2, in which the IP address contains a multicast IP address. 5. The method according to claim 2, in which the IP address contains the broadcast IP address. 6. The method according to claim 1, wherein when the broadcast service is provided through an interactive network, the access information comprises an address of server information for access to the broadcast service. 7. The method according to claim 6, in which information about a unified index of an information resource (URL) is used as server address information. 8. The method according to claim 6, in which the IP address is used as server address information. 9. The method according to claim 6, in which the server address information is provided to the terminal using the multimedia messaging service (MMS) / short message service (SMS). 10. The method of claim 1, wherein the broadcast system comprises an IP based broadcast system. 11. The method of claim 1, wherein the access information further comprises information indicating a network through which the broadcast service is provided among the broadcast network and the interactive network. 12. The method according to claim 1, in which the access information further comprises at least one information from the required information for the terminal to be able to receive the broadcast service and bandwidth information of the broadcast service. 13. The method according to claim 1, in which there is a lot of access information for one broadcast service. 14. The method of claim 1, wherein the broadcast system comprises a browser of an open community of mobile communications manufacturers and a mobile content broadcasting system (OMA BCAST). 15. The method according to claim 1, in which the access information comprises an access fragment and an access fragment is transmitted to the terminal through a service explorer for receiving a broadcast service. 16. A device for transmitting information about access to a broadcast service in a transmitter of a broadcast system, comprising
an access information generator for generating access information for at least one network from a broadcast network and an interactive network through which the broadcast service is transmitted; and
a transmitter for transmitting access information to the terminal via a predetermined communication network. 17. The device according to clause 16, in which, when the broadcast service is provided through the broadcast network, the access information contains an Internet Protocol (IP) address for access to the broadcast service. 18. The device according to clause 16, in which, when the access information contains a session description protocol (SDP), the IP address in the SDP is used as the IP address. 19. The device according to 17, in which the IP address contains a multicast IP address. 20. The device according to 17, in which the IP address contains the broadcast IP address. 21. The device according to clause 16, in which, when the broadcast service is provided through an interactive network, the access information contains server address information for access to the broadcast service. 22. The device according to item 21, in which the information of a unified information resource pointer (URL) is used as server address information. 23. The device according to item 21, in which the IP address is used as server address information. 24. The device according to item 21, in which the server address information is provided to the terminal using the multimedia messaging service (MMS) / short message service (SMS). 25. The device according to clause 16, in which the broadcast system contains a broadcast system based on IP. 26. The device according to clause 16, in which the access information further comprises information indicating a network through which the broadcast service is provided, among the broadcast network and the interactive network. 27. The device according to clause 16, in which the access information further comprises at least one information from the required information for the terminal to be able to receive broadcast services and information about the bandwidth of the broadcast service. 28. The device according to clause 16, in which there is a lot of access information for one broadcast service. 29. The device according to clause 16, in which the broadcast system contains a browser of an open community of mobile communication manufacturers and a mobile content broadcasting system (OMA BCAST) 30. The device according to clause 29, in which the access information contains an access fragment and the access fragment is transmitted to the terminal through the service guide to receive the broadcast service. 31. A method for receiving information about access to a broadcast service in a terminal of a broadcast system, comprising the steps of:
receive access information for the at least one network from the broadcast network and the interactive network from which the broadcast service is transmitted through a predetermined communication network; and
receive a broadcast service from at least one network from a broadcast network and an interactive network in accordance with the received access information. 32. The method of claim 31, further comprising determining a network from which the broadcast service is transmitted in accordance with the received access information, and establishing an access address for receiving the broadcast service. 33. The method according to p, in which, when the broadcast service is provided through a broadcast network, the access information contains an Internet Protocol (IP) address for access to the broadcast service,
moreover, the establishment step comprises the step of setting the access address as an IP address. 34. The method of claim 32, wherein when the access information comprises a Session Description Protocol (SDP), the IP address in the SDP is used as the IP address,
moreover, the establishment step comprises the step of setting the access address as the IP address in the SDP. 35. The method according to p, in which the IP address contains a multicast IP address. 36. The method according to p, in which the IP address contains the broadcast IP address. 37. The method according to p, in which, when the broadcast service is provided through an interactive network, the access information contains server address information for access to the broadcast service,
moreover, the establishment step comprises the step of setting the access address as the server address. 38. The method according to clause 37, in which the information of a unified index of an information resource (URL) is used as server address information. 39. The method according to clause 37, in which the IP address is used as server address information. 40. The method according to clause 37, further comprising the steps of receiving the server address information via the multimedia messaging service (MMS) / short message service (SMS) in accordance with the access information. 41. The method of claim 31, wherein the broadcast system comprises an IP based broadcast system. 42. The method of claim 31, wherein the access information further comprises information indicating a network through which the broadcast service is provided among the broadcast network and the interactive network. 43. The method according to p, in which the access information further comprises at least one information from the required information for the terminal to be able to receive the broadcast service and information about the bandwidth of the broadcast service,
wherein the terminal accesses at least one broadcast service based on said required information and bandwidth information. 44. The method of claim 31, wherein there is a plurality of access information for one broadcast service. 45. The method of claim 31, wherein the broadcast system comprises a browser of an open community of mobile communications manufacturers and a mobile content broadcasting system (OMA BCAST). 46. The method of claim 31, wherein the access information comprises an access fragment and an access fragment is received through a service explorer for a broadcast service. 47. A device for receiving information about access to a broadcast service in a terminal of a broadcast system, comprising
a receiver for receiving, through a predetermined communication network, access information for at least one network from a broadcast network and an interactive network from which a broadcast service is transmitted, and receiving a broadcast service from at least one network from a broadcast network and an interactive network in according to accepted access information. 48. The device according to clause 47, further comprising
an access information analyzer for determining the network from which the broadcast service is provided among the broadcast network and the interactive network in accordance with the received access information, and establishing an access address for receiving the broadcast service. 49. The device according to p, in which, when the broadcast service is provided through a broadcast network, the access information contains an Internet Protocol (IP) address for access to the broadcast service,
wherein the access information analyzer sets the access address as an IP address. 50. The device according to p, in which, when the access information contains a Protocol description of the session (SDP), the IP address in SDP is used as the IP address
wherein the access information analyzer sets the access address as the IP address in the SDP. 51. The device according to p, in which the IP address contains a multicast IP address. 52. The device according to p, in which the IP address contains the broadcast IP address. 53. The device according to p, in which, when the broadcast service is provided through an interactive network, the access information contains server address information for access to the broadcast service,
wherein the access information analyzer sets the access address as the server address. 54. The device according to item 53, in which the information of the unified index of the information resource (URL) is used as the server address information. 55. The device according to item 53, in which the IP address is used as server address information. 56. The device according to item 53, in which the access information analyzer is adapted to analyze access information and then receives the server address information through the multimedia messaging service (MMS) / short message service (SMS). 57. The device according to clause 47, in which the broadcast system contains a broadcast system based on IP. 58. The apparatus of claim 47, wherein the access information further comprises information indicating a network through which the broadcast service is provided among the broadcast network and the interactive network. 59. The device according to p, in which the access information further comprises at least one information from the required information for the terminal to be able to receive broadcast services and information about the bandwidth of the broadcast service,
in which the access information analyzer accesses the broadcast service based on at least one of said required information and bandwidth information. 60. The device according to clause 47, in which, when many different additional services are provided for one broadcast service, there is a lot of access information for one broadcast service. 61. The device according to clause 47, in which the broadcast system contains a browser of an open community of creators of mobile communications and a system for mobile broadcasting content (OMA BCAST). 62. The apparatus of claim 61, wherein the access information comprises an access fragment and the receiver is configured to receive an access fragment through a service explorer for a broadcast service. 63. A broadcast system providing access information for a broadcast service, comprising
a transmitting device for generating access information for at least one network from the broadcast network and the interactive network from which the broadcast service is transmitted, and transmitting access information to the terminal through a predetermined communication network; and
a receiver for receiving, through a predetermined communication network, information about access to a broadcast service and receiving a broadcast service from at least one network from a broadcast network and an interactive network in accordance with the received access information. 64. The broadcast system according to item 63, in which the receiving device is additionally designed
to determine the network from which the broadcast service is provided among the broadcast network and the interactive network in accordance with the received access information and establish an access address for receiving the broadcast service. 65. The broadcast system of claim 63, wherein the access information comprises an access fragment and the receiver is configured to receive the access fragment through a service explorer for the broadcast service.

Images