Patent Grant
8917706
This application claims the benefit under 35 U.S.C. §119(a) of Korean Patent Application No. 10-2005-0074011 entitled “Method and Apparatus for Transmitting/Receiving Access Information of Broadcast Service in a Broadcasting System, and System thereof”, filed in the Korean Intellectual Property Office on Aug. 11, 2005, Korean Patent Application No. 10-2005-0074534 entitled “Method and Apparatus for Transmitting/Receiving Access Information of Broadcast Service in a Broadcasting System, and System thereof”, filed in the Korean Intellectual Property Office on Aug. 12, 2005, and Korean Patent Application No. 10-2006-0064116 entitled “Method and Apparatus for Transmitting/Receiving Access Information of Broadcast Service in a Broadcasting System, and System thereof”, filed in the Korean Intellectual Property Office on Jul. 7, 2006, the entire disclosures of each of which are hereby incorporated by reference.
1. Field of the Invention
The present invention relates generally to a method and apparatus for providing broadcast services in a broadcasting system. In particular, the present invention relates to an access information transmission/reception method and apparatus for efficiently achieving access to broadcast services, and a system and terminal thereof.
2. Description of the Related Art
The mobile communication market continuously requires production of new services through for example, the recombination or integration of existing technologies. Today, with the development of communication and broadcast technologies, the conventional broadcasting system or mobile communication system has reached the phase of providing broadcast services through portable terminals (or mobile terminals), such as mobile phones and personal digital assistants (PDAs). Due to the latent and actual market needs and the increasing demand for multimedia services, the service providers' intended strategies for providing new services such as broadcast service in addition to the existing voice service, and the identified interests of Information Technology (IT) companies which are bolstering their mobile communication businesses to meet the user's demands, convergence of the mobile communication service and the Internet Protocol (IP) has become the mainstream of development of the next generation mobile communication technologies.
The Open Mobile Alliance (OMA), one of the standardization groups for broadcast services, was established in June, 2002, by about 200 companies including Nokia, NTT and IBM, to perform research on the standard for interworking between individual mobile solutions. The OMA mainly serves to define various application standards for mobile games and Internet services. Of the working groups belonging to the OMA, the Open Mobile Alliance Browser and Content Mobile Broadcast Sub Working Group (OMA BAC BCAST) is now performing research on the technology for providing broadcast services using mobile terminals. A brief description will now be made of the broadcasting system which is under discussion in the OMA.
In a BCAST system, which is a broadcasting system proposed by the OMA, a mobile terminal desiring to receive a broadcast service should receive so-called service guide information containing description information for the service, billing information for the service, and information on a receiving method for the service. The mobile terminal receives the service according to the information provided through the service guide information. A description will now be made of the conventional broadcast service access method with reference to the BCAST system as an example of the general broadcasting system using the service guide.
The administrative group 100 is a group for providing basic information needed 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), identification information of the service provider that generated and transmitted the service guide, and the entire information on the service guide. The service guide delivery descriptor fragment 102 provides a channel capable of receiving fragments for a plurality of service guides, scheduling information, and update information to a mobile terminal so that the mobile terminal may receive only the necessary service guide at an appropriate time.
The provisioning group 110 is a group for providing fee information for service reception and includes a purchase item fragment 111, a purchase data fragment 112, and a purchase channel fragment 113. The purchase item fragment 111 provides fee information for a service or a service bundle, the purchase data fragment 112 provides information indicating how a service user can pay the fee, and the purchase channel fragment 113 provides information on the system where the service user can actually purchase the service.
The core group 120 is a group for providing information on 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 which content the service can be configured. The schedule fragment 122 provides information on the time at which the service can be provided and used. The content fragment 123 provides information on a plurality of contents constituting the service.
The access group 130 includes an access fragment 131 and a session description fragment 132, and provides service access information indicating how to receive the services provided through the core group 120, and detailed information on the session in which the contents constituting the corresponding service are transmitted, so as to allow the mobile terminal to access the corresponding service. The access fragment 131 provides a plurality of access methods for one service to the mobile terminal, thereby providing a method capable of accessing various additional services based on one service. The session description fragment 132 provides session information for the service defined in one access fragment.
The service guide information, as shown in
With reference to Table 1 to Table 7 below, a description will now be made of the details of the access fragment defined in the conventional OMA BCAST by way of example. Table 1 to Table 7 are divided from one table, for convenience, and a definition of items in each table follows the definition of Table 1.
In Table 1, a first item “Name” indicates names of attributes or elements of an access fragment, and a second item “Type” indicates whether each object included in the access fragment corresponds to Attribute (A) or Element (E). As to a difference between the attribute and the element, the attribute is a value indicating an attribute of an access fragment and its element, and the element is a value indicating the information actually used. A third item “Category” indicates whether the attribute or element is a mandatory value (M) or an optional value (O). A fourth item “Cardinality” indicates whether the attribute or element is repeated, and a fifth item “Description” indicates a description of the attribute or element. Finally, a sixth item “Data Type” indicates a data type of the attribute or element.
In Table 1, reference numeral 201 indicates what the attribute or element included in the access fragment comprises.
In Table 2, reference numeral 202 denotes an identifier of the access fragment, and this is an attribute for enabling a mobile terminal to uniquely identify a corresponding access fragment when it refers to the corresponding access fragment in other fragments. Reference numeral 203 denotes an attribute indicating a version of the access fragment, and enables indication of whether the mobile terminal has received an access fragment of the same version or an access fragment of a new version.
The “validFrom” attribute denoted by reference numeral 204 and “validTo” denoted by reference numeral 205 are attributes indicating a valid period of the information included in the access fragment, and “ServiceProtection” denoted by reference numeral 206 is an attribute indicating whether there is a need for a separate authentication procedure during access, as the service that can be accessed through information of the access fragment is service-protected.
In Table 3, “AccessType” denoted by reference numeral 207 is an attribute indicating in which method the mobile terminal capable of receiving broadcast service can receive the broadcast service that provides access information in the access fragment, and 10 Access Types are currently defined. Therefore, it is undesirably necessary to newly define Access Type every time a service of a new type occurs.
In Table 4, “AudioLanguage” denoted by reference numeral 208 is used to indicate a language of an audio stream transmitted through the access fragment, and “ExtensionURL” denoted by reference numeral 209 is used to indicate an address of an extended fragment. The “ServiceID” denoted by reference numeral 210 is an element indicating an identifier of the service that can be accessed through information of the access fragment, and “UsageInfo” denoted by reference numeral 211 is an element that provides information capable of indicating the usage and correlation of a plurality of corresponding access fragments for users when there are multiple access fragments capable of providing various access information so as to receive various types of additional services for one service, and provides an attribute “Lang” denoted by reference numeral 212 so that it can be provided in various languages.
In Table 5, “AccessURI” denoted by reference numeral 213 is an element indicating an address of the place where information on the session in which the service indicated by the access fragment is transmitted can be acquired, and has, for example, an attribute “Type” denoted by reference numeral 214. The Type 214 is an attribute indicating the type of session information and supports a Session Description Protocol (SDP) type, which is a protocol of the current IEFT, and a session information type used in Multimedia Broadcast Multicast Service (MBMS), which is portable broadcast technology specified by the asynchronous mobile communication standardization group. The “SDP” 215 is an element providing information on actual session description, and “InteractiveAccessURL” 216 is an element notifying an address so that a mobile terminal can receive the service through an interaction channel.
In Table 6, “TerminalCapabilityRequirement” denoted by reference numeral 217 is an element indicating the software and hardware requirements of a mobile terminal for receiving the service that can be accessed through information of the access fragment, and based on this, a mobile terminal having a portable broadcast receiving function can determine whether it has the capability of receiving the corresponding service. In addition, “BandwidthRequirement” denoted by reference numeral 218 is an element indicating a data rate in a wireless environment of the service that can be accessed through the access fragment, and enables selection of the data rate required by the mobile terminal among several data rates, and reception of the service at the selected data rate. The “ApplicationSpec” 219 is an element providing separate information capable of receiving the service defined in MIME type.
In Table 7, “MediaInformation” denoted by reference numeral 220 is an element providing preview information of the service indicated by the access fragment by the mobile terminal that received the access fragment, and has an attribute “usage” 221 and an attribute “id” 222. The attribute “usage” indicates whether it will use information of the fragment associated with the attribute “id” as preview information or background information. Reference numeral 223 denotes an element or attribute capable of providing other information that is not provided through the access fragment.
The access fragment of the conventional BCAST system, shown in Table 1 to Table 7, has the following problems.
First, because “AccessType” conceptually defines Access Type for an actual service in Table 3, Access Type should be newly defined every time a new service occurs. Second, most broadcast services provided to the mobile terminal are multimedia services requiring a high data rate, and should efficiently use radio resources in order to support high-speed transmission. Therefore, most broadcast technologies for the mobile terminal introduce the multicast concept used in the Internet Protocol, and support a method for enabling the service only in the place where the user is located. However, this method is not currently supported for the Access Type. Third, in the currently proposed broadcasting system, there is no method for simply providing to the mobile terminal a transmission scheme or transmission topology supported in the broadcasting system for access to the broadcast service.
Accordingly, a need exists for a system and method for efficiently transmitting/receiving access information of broadcast services in a broadcasting system.
Embodiments of the present invention are provided to substantially solve the above and other problems, and provide a method and apparatus for efficiently transmitting/receiving access information of broadcast services in a broadcasting system, and a system thereof.
Further, embodiments of the present invention provide a method and apparatus for transmitting/receiving access information of a broadcast network or an interaction network via which broadcast services are transmitted in a broadcasting system, and a system thereof.
Further, 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 broadcasting system, and a system thereof.
Moreover, embodiments of the present invention provide an access fragment format for efficiently providing access information for broadcast services in a broadcasting system.
According to one aspect of embodiments of the present invention, a method is provided for transmitting access information of a broadcast service in a transmitter of a broadcasting system. The method comprises the steps of generating access information for at least one of a broadcast network and an interaction network, via which broadcast service is transmitted, and transmitting the access information to a terminal via a specific communication network.
According to another aspect of embodiments of the present invention, an apparatus is provided for transmitting access information of a broadcast service in a transmitter of a broadcasting system. The apparatus comprises an access information generator for generating access information for at least one of a broadcast network and an interaction network, via which broadcast service is transmitted, and a transmitter for transmitting the access information to a terminal via a specific communication network.
According to 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 broadcasting system. The method comprises the steps of receiving, via a specific communication network, access information for at least one of a broadcast network and an interaction network, from which broadcast service is transmitted, and receiving the broadcast service from the at least one of the broadcast network and the interaction network according to the received access information.
According to yet 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 broadcasting system. The apparatus comprises a receiver for receiving, via a specific communication network, access information for at least one of a broadcast network and an interaction network from which broadcast service is transmitted and receiving the broadcast service from the at least one of the broadcast network and the interaction network according to the received access information.
According to still another aspect of embodiments of the present invention, a broadcasting system is provided for providing access information of a broadcast service. The system comprises a transmission apparatus for generating access information for at least one of a broadcast network and an interaction network, from which broadcast service is transmitted, and transmitting the access information to a terminal via a specific communication network, and a reception apparatus for receiving, via a specific communication network, the access information of the broadcast service and receiving the broadcast service from the at least one of the broadcast network and the interaction network according to the received access information.
The above and other objects, features and advantages of embodiments of the present invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which:
Throughout the drawings, like reference numerals will be understood to refer to like parts, components and structures.
Exemplary embodiments of the present invention will now be described in detail with reference to the annexed drawings. In the following description, a detailed description of known functions and configurations incorporated herein has been omitted for clarity and conciseness.
In the following description, exemplary embodiments of the present invention will be presented to accomplish the above and other objects. Although the exemplary embodiments will be described based on the BCAST system, which is one of many portable broadcast technology standards, embodiments of the present invention are not limited thereto, and the following descriptions are not provided to restrict the possible scope of the present invention. In this specification, it should be construed that the broadcasting system comprises various communication systems supporting IP-based broadcast services, such as the BCAST system and the DVB-H system. In addition, although a receiver of the BCAST system will herein be described as a mobile terminal for convenience, embodiments of the present invention are not limited thereto, and it would be obvious to those skilled in the art that the technical spirit of the present invention can also be applied to wired communication systems supporting IP-based broadcast services.
Although the term “service guide” will be used herein as the information including, for example, relevant description and receiving method for the broadcast service of the BCAST system, and “access fragment” will be used herein as the information including an access method of broadcast services, the terms “service guide” and “access fragment” are subject to change according to type of corresponding broadcasting system.
The present invention provides a number of embodiments, including the exemplary first to third embodiments described below. In the first exemplary embodiment, the BCAST system proposes a new access fragment efficiently configured to indicate an access method for a specific service in service guide information that the mobile terminal receives to receive the service. In the first embodiment, the access fragment is configured such that it includes only the attribute related to the service access. Further, in the first embodiment, the access fragment is configured to indicate whether the service is transmitted over a broadcast channel or an interaction channel of the mobile communication network, without individually configuring “AccessType” providing access information of the service for each service as shown in Table 3.
The second exemplary embodiment proposes an efficient access fragment format in which information of the same access fragment can be used for a plurality of different services. Finally, the third exemplary embodiment proposes another embodiment capable of simply providing access information for service transmission through the broadcast network and service transmission through the interaction network using the access fragment. In addition, it should be noted that the first to third embodiments show various types of exemplary access fragment formats, and commonly include features of the present invention of providing the detailed access information of the broadcast network and the interaction network via which the services are transmitted.
Herein, the first exemplary embodiment will be described with reference to Table 8 to Table 14, the second exemplary embodiment will be described with reference to Table 15 to Table 18, and the third exemplary embodiment will be described with reference to Table 19 to Table 37. Although operations of a transmission apparatus of
Table 8 to Table 14 show by way of example, a format of an access fragment according to the first exemplary embodiment of the present invention. Table 8 to Table 14 are divided from one table, for convenience, and a definition of items in each table follows the definition of Table 8. In addition, the definition of each item in Table 8 to Table 14 is substantially equal to the definition of Table 1, and a detailed description of the same parts throughout Table 1 to Table 7, and Table 8 to Table 14, will be omitted.
An access fragment of the first embodiment comprises attributes of “Id” 302, “version” 303 and “validFrom” 304 in Table 8, and “validTo” 305 in Table 9. These four attributes represent unique attributes for the access fragment, and their functions are substantially equal to those of the attributes having the same names in Table 2. However, as to the difference between the conventional access fragment described in Table 2 and the access fragment proposed in embodiments of the present invention, the conventional access fragment has, as attributes, even the values not associated with the attributes of the access fragment, whereas the proposed access fragment is configured such that it has only the attributes associated with the access fragment, and has changed the other attributes to the elements matched to the corresponding characteristics.
The access fragment of the first embodiment, as presented in Table 8, comprises “ServiceID” 306 in Table 9, and “UsageInfo” 319, “SessionDescriptionURI” 321, “SDP” 323, “ApplicationSpec” 324 and “MediaInformation” 325 in Table 12 to Table 14, as sub-elements.
In Table 9, “ServiceID” denoted by reference numeral 306 is a service identifier with which a mobile terminal can obtain access information of a service through the access fragment, and has “ServiceProtection” 307 as its attribute. The “ServiceID” has “TerminalCapabilityRequirement” 308 in Table 9, and “BandwidthRequirement” 309 and “AccessType” 310 in Table 10, as its sub-elements. Therefore, in the first embodiment, because the element “ServiceID” has all access information of the service, being coincident with the corresponding service, the proposed access fragment has higher efficiency than the conventional access fragment in terms of the format.
The “TerminalCapabilityRequirement” 308 in Table 9 and “BandwidthRequirement” 309 in Table 10 have substantially the same functions as those of the conventional access fragment.
The “AccessType” 310 in Table 10, provided to indicate in which method the mobile terminal can receive the service, is used to indicate whether the service is transmitted over the broadcast channel or transmitted over the interaction channel provided in the mobile communication network, and also indicate with which protocol or system the mobile terminal transmits the service. For this purpose, in the first embodiment, the “AccessType” is comprised of one attribute and two sub-elements.
That is, “Transmission_Media” 312 in Table 10 is an attribute indicating whether the service is transmitted over the broadcast channel or is provided from a communication network capable of bidirectional communication, and a type of the sub-element that can be included in the “AccessType” is determined according to a value of the attribute. For example, if the “TransmissionMedia” indicates that the service is transmitted over the broadcast channel, “AccessType” comprises “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 over the broadcast channel will be transmitted in a broadcast mode or a multicast mode. The broadcast mode and the multicast mode are used in Internet Protocol, and if the “Transmission_Topology” indicates the broadcast mode, it means that the service is transmitted to a particular area regardless of the position of the service recipient. If the “Transmission_Topology” indicates the multicast mode, it means that the service is transmitted to the place where the service recipient is located in the serviceable area according to location information of the service recipient. In addition, when the “Transmission_Topology” indicates the multicast mode, the mobile terminal capable of receiving the broadcast service preferably should make a subscription application to an IP address of the multicast mode and receive the broadcast service.
The “IP_Address” 314 in Table 11, because the service is transmitted to mobile terminals in the form of IP flow in the BCAST system, is an attribute indicating an address for the IP flow. The “IP_Address” becomes an IP broadcast address or an IP multicast address according to a value of the “Transmission_Topology” in Table 10. Commonly, an IP address of the service is indicated in the session description. However, when the session description is not transmitted together with the access fragment, it should be provided to the mobile terminal for identification of the service on the IP level.
If the attribute “Transmission_Media” 312 in Table 10 indicates Interaction Channel, “Transmission_Scheme” 315 in Table 11 is included in the “AccessType” of Table 10, and the “Transmission_Scheme” comprises “AccessServerIPAddress” 316, “AccessServerURL” 317, and “AccessServerPhoneNumber” 318 as its sub-elements.
The “Transmission_Scheme” is an element indicating the communication system or protocol used in the interaction channel, when it is possible to access the service through the interaction channel. Although OMA BCAST currently specifies, for example, Web Browsing, Multimedia Messaging Service (MMS), Wireless Application Protocol 1.0 (WAP1.0), Wireless Application Protocol 2.x (WAP 2.x), Short Messaging Service (SMS), and Hyper Text Transmission Protocol (HTTP) as the communication systems or protocols that can be used for the interaction channel, further communication systems and protocols that can be used for the interaction channel can be added in the future.
In Table 11, “AccessServerIPAddress” 316, “AccessServerURL” 317, and “AccessServerPhoneNumber” 318 are elements indicating an address of the server that provides the service over the interaction channel in order to indicate whether the mobile terminal receiving the access fragment can access the service through the interaction channel in any place. Because an addressing system used in each communication system or protocol is different, the representative addressing system of the communication system and protocol, currently adapted to support the interaction channel, is presented.
The “AccessServerIPAddress” 316 is an element indicating a position of the server based on Internet Protocol, the “AccessServerURL” 317 is an element indicating a position of the server that uses the communication system or protocol supporting Web or URL, and the “AccessServerPhoneNumber” 318 is an element indicating a position of the server that enables access to the service using MMS or SMS. Further, in embodiments of the present invention, a new communication system or protocol is added to the “Transmission_Scheme” 315 in Table 11, and if the addressing system of the communication system or protocol is different from the currently provided one, a new addressing system can be added as a sub-element of the “Transmission_Scheme”.
The “UsageInfo” 319 in Table 12 is an element for giving a description of the characteristic of the access fragment to the user of the mobile terminal, especially an element that can be used for describing the characteristic and correlation of each access fragment for the user even when there are a plurality of access fragments for one service, providing sub-services having different characteristics. The “UsageInfo” has “Lang” 320 as an attribute.
The “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 substantially the same functions as those of the conventional access fragment, so a detailed description thereof will be omitted.
With reference to
Referring to
The transmission apparatus of
Referring to
In step 305, the access fragment generator 201 sets a service ID corresponding to the information provided by the access fragment, and sets a basic attribute of the service corresponding to the service ID. The basic attribute comprises at least one of information indicating whether to apply the service protection, information indicating the requirements of the mobile terminal for receiving the service, and information indicating a data rate at which the service is transmitted in a wireless environment, all of which have been described in connection with Table 9 and Table 10. In step 307, the access fragment generator 201 determines whether the service will be transmitted over a broadcast channel or an interaction channel. If the service is to be transmitted over the interaction channel, the access fragment generator 201 proceeds to step 309. However, if the service is to be transmitted over the broadcast channel, the access fragment generator 201 proceeds to step 315.
The access fragment generator 201 sets a transmission scheme for a communication system or protocol to be used, in step 309, and sets an address for the corresponding communication system or protocol in step 311. Thereafter, in step 313, the access fragment generator 201 sets service usage information “UsageInfo”, and if there is characteristic description for the corresponding access fragment and a plurality of access fragments for one service, the access fragment generator 201 adds description of characteristic and correlation for each of them to the access fragment so that a broadcast service recipient may detect the difference.
In step 315, the access fragment generator 201 sets transmission topology information indicating whether the corresponding service will be transmitted in a broadcast mode or a multicast mode. The mode-related information is determined by a transmission entity or a service providing entity, and the access fragment generator 201 receives the mode-related information provided from the corresponding entity, and sets the mode depending on the mode-related information. In step 317, the access fragment generator 201 sets IP information of an IP flow where the service is transmitted. Thereafter, in step 313, the access fragment generator 201 sets service usage information “UsageInfo”.
In step 319, the access fragment generator 201 sets information on the session in which the service, whose access information is provided through the corresponding access fragment, is transmitted. The session information comprises an IP address of a sender, an IP address of a recipient, a type of data transmitted through the session, and a codec used. Session Description Protocol defined by IETF is a typical example of the session information. Thereafter, in step 321, the access fragment generator 201 sets the other information constituting the access fragment, and then ends the operation.
Referring to
Referring to
In step 505, the access fragment analyzer 405 determines a service ID that can be accessed through access information provided by the access fragment, and determines whether the corresponding service undergoes service protection before being transmitted. When the service undergoes service protection, the access fragment analyzer 405 prepares to perform a related operation so as to correctly receive the corresponding service. In addition, the access fragment analyzer 405 checks a basic attribute for the corresponding service ID, compares a performance condition of the mobile terminal requiring the corresponding service with a performance condition of the current mobile terminal to determine whether the service is receivable, and selects an appropriate channel taking into account a bandwidth provided by the service.
In step 507, the access fragment analyzer 405 determines whether the service will be transmitted over a broadcast channel or an interaction channel based on the access information provided by the access fragment. If the service is to be transmitted over an interaction channel, the access fragment analyzer 405 proceeds to step 509. However, if the service is to be transmitted over a broadcast channel, the access fragment analyzer 405 proceeds to step 515.
In step 509, the access fragment analyzer 405 checks a transmission scheme and recognizes a communication system or protocol to be used. After recognizing that it preferably should receive the service using the determined communication system or protocol, the access fragment analyzer 405 analyzes, in step 511, an address of the server that transmits the service over the interaction channel, and prepares to transmit a service request. The addressing system may differ according to communication system and protocol using the interaction channel. Thereafter, in step 513, the access fragment analyzer 405 checks service usage information “UsageInfo”, and if there is characteristic description for the access fragment and a plurality of access fragments for one service, the access fragment analyzer 405 recognizes characteristic and correlation for each of them, and the mobile terminal displays the corresponding description for the user who will receive the service so as to allow the user to make an appropriate selection.
In step 515, the access fragment analyzer 405 checks the transmission topology, analyzes the information indicating whether the service will be transmitted in the broadcast mode or the multicast mode, and prepares to perform an operation appropriate for the analysis result. For the service transmitted in the broadcast mode, the mobile terminal can receive the corresponding service without joining in the service. However, for the service transmitted in the multicast mode, the mobile terminal preferably should perform a Join process for a multicast IP address group of an IP flow where the service is transmitted, in order to receive the service.
In step 517, the access fragment analyzer 405 checks an address of the IP flow where the service is transmitted. The address of the IP flow is very important for the mobile terminal scheduled to receive the service in the process of distinguishing an IP flow where the service is transmitted. If the address of the IP flow is not provided, the mobile terminal preferably should perform an operation of receiving all IP flows transmitted through the broadcast channel and determining whether the corresponding service is a desired service, for every IP flow. The address of the IP flow is connected to a communication bearer under an IP layer and indicates which communication bearer the mobile terminal should receive in order to receive the IP flow. The method may be different in each broadcast system providing the broadcast channel and departs from the scope of the present invention, so a detailed description thereof will be omitted.
After step 513, the access fragment analyzer 405 checks, in step 519, information on the session where the service, whose access information is provided from the access fragment, is transmitted, and allows the mobile terminal to prepare to receive the session where the service is actually transmitted. Thereafter, in step 521, the access fragment analyzer 405 analyzes the other information provided from the access fragment and uses the related information for an appropriate purpose. In step 523, the access fragment analyzer 405 prepares to access and receive the service according to the information analyzed from the access fragment, and then ends the operation.
With reference to Table 15 to Table 18 and
Table 15 to Table 18 show by way of example, a format of an access fragment according to the second embodiment of the present invention. A difference in the access fragment between the first embodiment and the second embodiment is in that information of the same access fragment is used for a plurality of different services, and an efficient structure thereof will be proposed in the second embodiment. A definition of items in each table is substantially equal to the definition of Table 1, and a detailed description of the same parts throughout Table 15 to Table 18 and Table 8 to Table 14 will be omitted.
In addition, compared with the attributes or elements defined in Table 8 to Table 14, the unchanged parts of Table 15 to Table 18 will not be shown for simplicity.
In Table 15, the access fragment proposed by the second embodiment comprises attributes of “Id” *02, “version” *03, “validFrom” *04, “validTo” *05, and “ServiceProtection” *06, as specified in “Access” denoted by reference numeral *01. The five attributes represent unique attributes for the access fragment, and their functions are substantially equal to those of the attributes having the same names in Table 2. Further, the access fragment proposed in the second embodiment comprises “TerminialCapabilityRequirement” *07, “BandwidthRequirement” *08, “AccessType” *09, “ServiceID” *17, “ExtensionURL” *18, “UsageInfo” *19, “SessionDescriptionURI” *21, “SDP” *23, “ApplicationSpec” *24, and “MediaInformation” *25 as its sub-elements, as specified in the “Access” *01.
The “TerminalCapabilityRequirement” *07 in Table 16 indicates the requirement for the mobile terminal that accesses the service through the access fragment, and “BandwidthRequirement” *08 indicates the bandwidth in the wireless channel of the service accessed through the access fragment. The “AccessType” *09, provided to indicate in which method the mobile terminal will receive the service, is used to indicate whether the service is transmitted over the broadcast channel or transmitted over the interaction channel provided in the mobile communication network, and also indicate with which protocol or system the mobile terminal transmits the service. For this purpose, in the second embodiment, the “AccessType” is comprised of one attribute and two sub-elements.
That is, “Transmission_Media” *10 in Table 16 is an attribute indicating whether the service is transmitted over the broadcast channel or is provided from a communication network capable of bidirectional communication, and a type of the sub-element that can be included in the “AccessType” is determined according to a value of the attribute. If the “Transmission_Media” indicates that the service is transmitted over the broadcast channel, “AccessType” comprises “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 over the broadcast channel will be transmitted in a broadcast mode or a multicast mode. The broadcast mode and the multicast mode are used in Internet Protocol, and if the “Transmission_Topology” indicates the broadcast mode, it means that the service is transmitted to a particular area regardless of the position of the service recipient.
If the “Transmission_Topology” indicates the multicast mode, it means that the service is transmitted to the place where the service recipient is located in the serviceable area according to location information of the service recipient. In addition, when the “Transmission_Topology” indicates the multicast mode, the mobile terminal capable of receiving the broadcast service preferably should make a subscription application to an IP address of the multicast mode and receive the broadcast service.
The “IP_Address” *12 in Table 16, because the service is transmitted to mobile terminals in the form of IP flow in the broadcasting system, is an attribute indicating an address for the IP flow. The “IP_Address” becomes an IP broadcast address or an IP multicast address according to a value of the “Transmission_Topology”. Commonly, an IP address of the service is indicated in the session description. However, when the session description is not transmitted together with the access fragment, it preferably should be provided to the mobile terminal for identification of the service on the IP level.
If the attribute “Transmission_Media” *10 in Table 16 indicates Interaction Channel, “Interaction_Scheme” *13 is included in the “AccessType” *09, and the “Interaction_Scheme” has a substantially equivalent meaning to the “Transmission_Scheme” described in the first embodiment. In the second embodiment, the “Transmission_Scheme” has “AccessServerIPAddress” *14, “AccessServerURL” *15, and “AccessServerPhoneNumber” *16 as its sub-elements.
The “Transmission_Scheme” is an element indicating the communication system or protocol used in the interaction channel, when it is possible to access the service through the interaction channel. Although OMA BCAST currently specifies, for example, Web Browsing, Multimedia Messaging Service (MMS), Wireless Application Protocol 1.0 (WAP1.0), Wireless Application Protocol 2.x (WAP 2.x), Short Messaging Service (SMS), and Hyper Text Transmission Protocol (HTTP) as the communication systems or protocols that can be used for the interaction channel, further communication systems and protocols that can be used for the interaction channel can be added in the future.
In Table 17, “AccessServerIPAddress” *14, “AccessServerURL” *15, and “AccessServerPhoneNumber” *16 are elements indicating an address of the server that provides the service over the interaction channel in order to indicate whether the mobile terminal receiving the access fragment can access the service through the interaction channel in any place. Because an addressing system used in each communication system or protocol is different, the representative addressing system of the communication system and protocol, currently adapted to support the interaction channel, is presented.
The “AccessServerIPAddress” *14 is an element indicating a position of the server based on Internet Protocol, the “AccessServerURL” *15 is an element indicating a position of the server that uses the communication system or protocol supporting Web or URL, and the “AccessServerPhoneNumber” *16 is an element indicating a position of the server that enables access to the service using MMS or SMS. Further, a new communication system or protocol is added to the “Interaction_Scheme” *13 in Table 16, and if the addressing system of the communication system or protocol is different from the one currently provided, a new addressing system can be added as a sub-element of the “Interaction_Scheme”.
In Table 17, “ServiceID” *17 indicates an identifier of the service that can be accessed using access information provided from the access fragment, and when a plurality of services use the same access, a plurality of the “ServiceIDs” may exist. The “UsageInfo” *19 is an element for giving a description of the characteristic of the access fragment to the user of the mobile terminal, especially an element that can be used for describing the characteristic and correlation of each access fragment for the user, even when there are a plurality of access fragments for one service, providing sub-services having different characteristics. The “UsageInfo” has “Lang” *20 as an attribute.
In Table 17 and Table 18, the “SessionDescriptionURI” *21, “Type” *22, “SDP” *23, “ApplicationSpec” *24, “MediaInformation” *25, “Usage” *26, “Id” *27, and “<proprietary elements/attributes>” *28 have substantially the same functions as those of the conventional access fragment, so a detailed description thereof will be omitted.
Referring to
In step 605, the access fragment generator 201 determines whether the service that can be accessed through the corresponding access fragment will be transmitted over a broadcast channel or an interaction channel. If the service is to be transmitted over the interaction channel, the access fragment generator 201 proceeds to step 607. However, if the service is to be transmitted over the broadcast channel, the access fragment generator 201 proceeds to step 613.
The access fragment generator 201 sets a transmission scheme for a communication system or protocol to be used, in step 607, and sets an address for the corresponding communication system or protocol in step 609. Thereafter, in step 611, the access fragment generator 201 sets at least one service ID that can be accessed with the information provided in the access fragment.
In step 613, the access fragment generator 201 sets transmission topology information indicating whether the corresponding access or the service using the access will be transmitted in a broadcast mode or a multicast mode. The mode-related information is determined by a transmission entity or a service providing entity, and the access fragment generator 201 receives the mode-related information provided from the corresponding entity, and sets the transmission topology information depending on the mode-related information. In step 615, the access fragment generator 201 sets IP information of an IP flow where the service is transmitted, and then proceeds to step 611.
Thereafter, in step 617, the access fragment generator 201 sets service usage information “UsageInfo”, and if there is characteristic description for the corresponding access fragment and a plurality of access fragments for one service, the access fragment generator 201 adds description of characteristic and correlation for each of them to the access fragment so that a broadcast service recipient may detect the difference.
In step 619, the access fragment generator 201 sets information on the session in which the service, whose access information is provided through the corresponding access fragment, is transmitted. The session information comprises an IP address of a sender, an IP address of a recipient, a type of data transmitted through the session, and a codec used. Session Description Protocol defined by IETF is a typical example of the session information. Thereafter, in step 621, the access fragment generator 201 sets the other information constituting the access fragment, and then ends the operation.
Referring to
In step 705, the access fragment analyzer 405 determines whether the access information for receiving at least one service is for the broadcast channel or the interaction channel. If the access information is for the interaction channel, the access fragment analyzer 405 proceeds to step 707. However, if access information is for the broadcast channel, the access fragment analyzer 405 proceeds to step 713.
In step 707, the access fragment analyzer 405 checks a transmission scheme and recognizes a communication system or protocol to be used. After recognizing that it should access the corresponding service using the determined communication system or protocol, the access fragment analyzer 405 analyzes, in step 709, an address of the server that provides the corresponding service over the interaction channel, and prepares to transmit a service request. The addressing system may differ according to communication system and protocol using the interaction channel.
Thereafter, in step 711, the access fragment analyzer 405 checks service usage information “UsageInfo” for at least one service that can be accessed with the access information, and if there is characteristic description for the access fragment and a plurality of access fragments for one service, or if there is one access fragment for a plurality of services, the access fragment analyzer 405 recognizes characteristic and correlation for each of them, and the mobile terminal displays the corresponding description for the user who will receive the service so as to allow the user to make an appropriate selection.
In step 713, the access fragment analyzer 405 checks the transmission topology, analyzes the information indicating whether the service will be transmitted in the broadcast mode or the multicast mode, and prepares to perform an operation appropriate for the analysis result. For the service transmitted in the broadcast mode, the mobile terminal can receive the corresponding service without joining in the service. However, for the service transmitted in the multicast mode, the mobile terminal preferably should perform a Join process for a multicast IP address group of an IP flow where the service is transmitted, in order to receive the service.
In step 715, the access fragment analyzer 405 checks an address of the IP flow from the access information with which access to the corresponding service is possible. The address of the IP flow is very important for the mobile terminal scheduled to receive a corresponding service in the process of distinguishing an IP address with which access to the service is possible. If the address of the IP flow is not provided, the mobile terminal preferably should perform an operation of receiving all IP flows transmitted through the broadcast channel and determining an IP address for the desired service. The address of the IP flow is connected to a communication bearer under an IP layer and indicates which communication bearer the mobile terminal should receive in order to receive the IP flow. The method may be different in each broadcast system providing the broadcast channel and departs from the scope of the present invention, so a detailed description thereof will be omitted.
After determining an address of the IP flow in step 715, the access fragment analyzer 405 proceeds to step 711 where it checks and displays a service ID and service usage information. In step 717, the access fragment analyzer 405 checks information on the session where the service(s), whose access information is provided from the access fragment, is transmitted, and allows the mobile terminal to prepare to receive the session where the service is actually transmitted. Thereafter, in step 719, the access fragment analyzer 405 analyzes the other information provided from the access fragment and uses the related information for an appropriate purpose. In step 721, the access fragment analyzer 405 prepares to access and receive the service according to the information analyzed from the access fragment, and then ends the operation.
With reference to Table 19 to Table 37, a description will now be made of a method for providing access information for service transmission via a broadcast network and service transmission via an interaction network according to a third exemplary embodiment of the present invention.
As described in the first and second exemplary embodiments, the access fragment provides access information that the mobile terminal uses to have access to the service.
In Table 19 and Table 20 below, “Id”, “version”, “validFrom”, and “validTo” indicate basic information of ID, version and valid period for the access fragment, respectively. In Table 20, “AccessType” comprises detailed access information of the broadcast network or interaction network for the service. In Table 26, “KeyManagementSystem” comprises information indicating during service access whether the corresponding service is encrypted or whether the corresponding content is encrypted, and also comprises information on the method used for the encryption. In Table 29, “AlternativeAccessURL” comprises information on an address, access to which is possible via the interaction network, in case the mobile terminal has difficulty in accessing the corresponding broadcast network when the “AccessType” of Table 20 comprises broadcast network information. The “TerminalCapabilityRequirement” in Table 30 and “BandwidthRequirement” in Table 35, indicate the requirement of the mobile terminal for having access to the corresponding service, and bandwidth information of the service, respectively.
In Table 35, “ServiceClass” indicates the purposes of using the corresponding access fragment, i.e. service guide reception, file transmission, stream transmission, and so forth. In Table 37, “NotificationReception” comprises address information for reception of notification messages.
The “AccessType” in Table 20 according to embodiments of the present invention will now be described in greater detail. The “AccessType” comprises detailed information for the service access. That is, the corresponding “AccessType” indicates whether it is access information for the broadcast network or access information for the interaction network according to “transmissionMedia” information in Table 20. If the “transmissionMedia” is access information for the broadcast network, the “AccessType” comprises only the “BroadcastServiceDelivery” information of Table 20, and if the “transmissionMedia” is access information for the interaction network, the “AccessType” comprises only the “UnicastServiceDelivery” information of Table 24.
In Table 20, the “transmissionMedia” used for distinguishing between the broadcast network and the interaction network can be optionally included in the “AccessType”. Even when the “transmissionMedia” is not included, only one of the “BroadcastServiceDelivery” information of Table 20 for access to the broadcast network, and the “UnicastServiceDelivery” information of Table 24 for access to the interaction network, is included in the “AccessType”, so the mobile terminal can determine whether it will have access to the broadcast network or the interaction network by determining which information is included in the “AccessType”.
The “BroadcastServiceDelivery” information comprises detailed access information related to the broadcast network, and based on “bdsType” of Table 21, the mobile terminal can determine through which broadcast network the service is received. For example, if the “bdsType” has a value of 0, the mobile terminal is serviced through DVB-H IPDC, and the values specified in the “BroadcastServiceDelivery” comprise the detailed information that the mobile terminal uses to access the DVB-H IPDC and receive the service.
The “destinationIPAddress” in Table 21 denotes an IP address used for receiving the service via the broadcast network, and the mobile terminal accesses the corresponding address and receives the service. The corresponding address information is used when “SessionDescriptionReference” or SDP information of Table 22 is not included. When the “SessionDescriptionReference” or SDP is included, the mobile terminal checks the address value and detailed access information in the corresponding SDP information, and accesses the broadcast network.
The “UnicastServiceDelivery” in Table 24 denotes access information for the case where the mobile terminal receives the service via the interaction network. The detailed address information used by the mobile terminal to receive the service is specified in “AccessServerURL” of Table 24. In addition, “transmissionSchemeType” in Table 25 indicates a transport mechanism used for accessing the corresponding “AccessServerURL” and downloading the service, and the transport mechanism indicates information on HTTP, MMS, WAP, and so forth. For example, if the “transmissionSchemeType” is 0, the mobile terminal accesses the corresponding address “AccessServerURL” using the HTTP, and receives the service.
As can be understood from the foregoing description, embodiments of the present invention can provide detailed access information of the broadcast network or the interaction network, via which the broadcast service is transmitted, in the broadcasting system providing IP-based broadcast services.
Embodiments of the present invention can provide detailed access information of the broadcast network or the interaction network, via which the service is transmitted to the mobile terminal, by providing an efficient access fragment format in the broadcasting system providing IP-based broadcast services.
Further, embodiments of the present invention can provide an efficient access fragment format when accessing a plurality of services through one access fragment.
In addition, embodiments of the present invention provide an access fragment transmission/reception method and apparatus for efficiently supporting the transmission scheme/transmission topology and protocol for each individual channel over which the service is transmitted, in the process of configuring Access Type of the access fragment, thereby allowing the mobile terminal to efficiently access the service.
Moreover, embodiments of the present invention provide IP multicast transmission information to the mobile terminal in the broadcasting system requiring a high data rate, contributing to a reduction in the wireless resources.
While the invention has been shown and described with reference to certain exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims and their equivalents.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10-2005-0074011 | Aug 2005 | KR | national |
| 10-2005-0074534 | Aug 2005 | KR | national |
| 10-2006-0064116 | Jul 2006 | KR | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 6466552 | Haumont | Oct 2002 | B1 |
| 6711623 | Furukawa et al. | Mar 2004 | B1 |
| 20020141591 | Hawkes et al. | Oct 2002 | A1 |
| 20050070277 | Hu | Mar 2005 | A1 |
| 20060018319 | Palin et al. | Jan 2006 | A1 |
| 20070206530 | Lee et al. | Sep 2007 | A1 |
| Number | Date | Country |
|---|---|---|
| 1 562 322 | Aug 2005 | EP |
| 1753166 | Feb 2007 | EP |
| 2 192 095 | Oct 2002 | RU |
| 2 233 034 | Jul 2004 | RU |
| WO 02080449 | Oct 2002 | WO |
| WO 02080609 | Oct 2002 | WO |
| WO 03045064 | May 2003 | WO |
| WO 2007 018415 | Feb 2007 | WO |
| Entry |
|---|
| Open Mobile Alliance (OMA), “Service Guide for Mobile Broadcast Services”, Draft Version 1.0, Aug. 5, 2005, pp. 1-49. |
| Open Mobile Alliance, “Service Guide for Mobile Broadcast Services, Draft Version 1.0”, Aug. 5, 2005, pp. 1-49, Open Mobile Alliance Ltd. |
| 3rd Generation Partnership Project, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Architecture and Functional Description (Release 6)”, Dec. 2004, pp. 1-44, 3rd Generation Partnership Project. |
| 3rd Generation Partnership Project, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service; Protocols and Codecs (Release 6)”, Sep. 1, 2004, pp. 1-31, Release 6 (3GPP TS 26.346 V1.0.0), 3GPP Organizational Partners. |
| Handley, M. et al., “SDP: Session Description Protocol”, Apr. 1998, pp. 1-42, RFC 2327, The Internet Society (Network Working Group). |
| Number | Date | Country | |
|---|---|---|---|
| 20070036102 A1 | Feb 2007 | US |
