Method and apparatus for transmitting/receiving access information of broadcast service in a broadcasting system, and system thereof
09578467 ยท 2017-02-21
Assignee
Inventors
- Sung-Oh Hwang (Gyeonggi-do, KR)
- Bo-Sun Jung (Gyeonggi-do, KR)
- Kook-Heui Lee (Gyeonggi-do, KR)
- Jai-Yong Lee (Seoul, KR)
- Byung-Rae Lee (Seoul, KR)
- Jong-Hyo Lee (Seongnam-si, KR)
Cpc classification
H04W80/10
ELECTRICITY
H04W4/06
ELECTRICITY
H04H20/93
ELECTRICITY
H04W80/12
ELECTRICITY
International classification
H04W4/06
ELECTRICITY
H04H20/93
ELECTRICITY
Abstract
A broadcasting system for providing access information of a broadcast service, wherein a transmission apparatus generates the access information for at least one of a broadcast network and an interaction network, from which the broadcast service is transmitted, and transmits the access information to a terminal via a specific communication network. A reception apparatus receives the access information of the broadcast service via the communication network, analyzes the received access information to determine a network from which the broadcast service is provided, among the broadcast network and the interaction network, and sets an access address for reception of the broadcast service.
Claims
1. A method for transmitting access information of a broadcast service in a transmitter of a broadcasting system, the method comprising: generating the access information comprising an access type for indicating either a broadcast delivery mode or a unicast delivery mode, by which the broadcast service is transmitted; and transmitting a service guide provided for the broadcast service to a terminal, wherein the access information is included in an access fragment and the access fragment is transmitted through the service guide provided for the broadcast service.
2. The method of claim 1, wherein when the broadcast service is provided by the broadcast delivery mode, the access information comprises an Internet protocol (IP) address for access to the broadcast service.
3. The method of claim 2, wherein the IP address comprises either a multicast IP address or a broadcast IP address.
4. The method of claim 1, wherein when the access information comprises a session description protocol (SDP), an IP address in the SDP is used as an IP address for access to the broadcast service.
5. The method of claim 1, wherein when the broadcast service is provided by the unicast delivery mode, the access information comprises address information of a server for access to the broadcast service.
6. The method of claim 5, wherein the address information of the server is provided to the terminal using at least one of multimedia messaging service (MMS) and short messaging service (SMS).
7. The method of claim 1, wherein the broadcasting system comprises an IP-based broadcasting system.
8. The method of claim 1, wherein the access information further comprises information indicating a network by which the broadcast service is provided, by either the broadcast delivery mode or the unicast delivery mode.
9. The method of claim 1, wherein the access information further comprises at least one of requirement information for a capability of the terminal receiving the broadcast service and bandwidth information of the broadcast service.
10. The method of claim 1, wherein there is a plurality of access information for one broadcast service.
11. The method of claim 1, wherein the broadcasting system comprises an Open Mobile Alliance browser and content mobile broadcast (OMA BCAST) system.
12. An apparatus for transmitting access information of a broadcast service in a broadcasting system, the apparatus comprising: at least one processor; and a transmitter coupled to the at least one processor, wherein the at least one processor is configured to generate the access information comprising an access type for indicating either a broadcast delivery mode or a unicast delivery mode, by which the broadcast service is transmitted, wherein the transmitter is configured to transmit a service guide provided for the broadcast service, and wherein the access information is included in an access fragment and the access fragment is transmitted through the service guide provided for the broadcast service.
13. The apparatus of claim 12, wherein when the broadcast service is provided by the broadcast delivery mode, the access information comprises an internet protocol (IP) address for access to the broadcast service.
14. The apparatus of claim 13, wherein the IP address comprises either a multicast IP address or a broadcast IP address.
15. The apparatus of claim 12, wherein when the access information comprises a session description protocol (SDP), an IP address in the SDP is used as an IP address for access to the broadcast service.
16. The apparatus of claim 12, wherein when the broadcast service is provided by the unicast delivery mode, the access information comprises address information of a server for access to the broadcast service.
17. The apparatus of claim 16, wherein the address information of the server is provided to a terminal using at least one of multimedia messaging service (MMS) and short messaging service (SMS).
18. The apparatus of claim 16, wherein the broadcasting system comprises an IP-based broadcasting system.
19. The apparatus of claim 12, wherein the access information further comprises information indicating a network by which the broadcast service is provided, by either the broadcast delivery mode or the unicast delivery mode.
20. The apparatus of claim 12, wherein the access information further comprises at least one of requirement information for a capability of a terminal receiving the broadcast service and bandwidth information of the broadcast service.
21. The apparatus of claim 12, wherein there is a plurality of access information for one broadcast service.
22. The apparatus of claim 12, wherein the broadcasting system comprises an Open Mobile Alliance browser and content mobile broadcast (OMA BCAST) system.
23. A method for receiving access information of a broadcast service in a terminal of a broadcasting system, the method comprising: receiving a service guide comprising the access information provided for the broadcast service; and receiving the broadcast service by either a broadcast delivery mode or a unicast delivery mode based on the received access information comprising an access type for indicating either the broadcast delivery mode or the unicast delivery mode, by which the broadcast service is transmitted, wherein the access information received through the service guide is included in an access fragment.
24. The method of claim 23, further comprising: determining a network by which the broadcast service is transmitted, by either the broadcast delivery mode or the unicast delivery mode according to the received access information; and setting an access address for reception of the broadcast service.
25. The method of claim 24, wherein when the broadcast service is provided by the broadcast delivery mode, the access information comprises an internet protocol (IP) address for access to the broadcast service, and wherein the setting step comprises the step of setting the access address as the IP address.
26. The method of claim 24, wherein when the access information comprises session description protocol (SDP), an IP address in the SDP is used as an IP address for access to the broadcast service, and wherein the setting step comprises the step of setting the access address as the IP address in the SDP.
27. The method of claim 24, wherein the IP address comprises either a multicast IP address or a broadcast IP address.
28. The method of claim 24, wherein when the broadcast service is provided by the unicast delivery mode, the access information comprises address information of a server for access to the broadcast service, and wherein the setting step comprises the step of setting the access address as the address information of the server for access to the broadcast service.
29. The method of claim 28, further comprising: receiving the address information of the server through at least one of multimedia messaging service (MMS) and short messaging service (SMS).
30. The method of claim 23, wherein the broadcasting system comprises an IP-based broadcasting system.
31. The method of claim 23, wherein the access information further comprises information indicating a network by which the broadcast service is provided, by either the broadcast delivery mode or the unicast delivery mode.
32. The method of claim 23, wherein the access information further comprises at least one of requirement information for a capability of the terminal receiving the broadcast service and bandwidth information of the broadcast service, and wherein the terminal achieves access to the broadcast service based on at least one of the requirement information and the bandwidth information.
33. The method of claim 23, wherein there is a plurality of access information for one broadcast service.
34. The method of claim 23, wherein the broadcasting system comprises an Open Mobile Alliance browser and content mobile broadcast (OMA BCAST) system.
35. An apparatus for receiving access information of a broadcast service in a terminal of a broadcasting system, the apparatus comprising: at least one processor; and a receiver coupled to the at least one processor, and the receiver configured to: receive a service guide comprising the access information provided for the broadcast service, and receive the broadcast service by either a broadcast delivery mode or a unicast delivery mode based on the received access information comprising an access type for indicating either the broadcast delivery mode or the unicast delivery mode, by which the broadcast service is transmitted, wherein the access information received through the service guide is included in an access fragment.
36. The apparatus of claim 35, wherein the receiver is further configured to: determine a network by which the broadcast service is transmitted, by either the broadcast delivery mode or the unicast delivery mode according to the received access information, and set an access address for reception of the broadcast service.
37. The apparatus of claim 36, wherein when the broadcast service is provided by the broadcast delivery mode, the access information comprises an internet protocol (IP) address for access to the broadcast service, and wherein the receiver is further configured to set the access address as the IP address.
38. The apparatus of claim 36, wherein when the access information comprises session description protocol (SDP), an IP address in the SDP is used as an IP address for access to the broadcast service, and wherein the receiver is further configured to set the access address as the IP address in the SDP.
39. The apparatus of claim 36, wherein the IP address comprises either a multicast IP address or a broadcast IP address.
40. The apparatus of claim 36, wherein when the broadcast service is provided by the unicast delivery mode, the access information comprises address information of a server for access to the broadcast service, and wherein the receiver is further configured to set the access address as the address information of the server for access to the broadcast service.
41. The apparatus of claim 40, wherein the receiver is further configured to analyze the access information and then receive the address information of the server through at least one of multimedia messaging service (MMS) and short messaging service (SMS).
42. The apparatus of claim 35, wherein the broadcasting system comprises an IP-based broadcasting system.
43. The apparatus of claim 35, wherein the access information further comprises information indicating a network by which the broadcast service is provided, by either the broadcast delivery mode or the unicast delivery mode.
44. The apparatus of claim 36, wherein the access information further comprises at least one of requirement information for a capability of the terminal receiving the broadcast service and bandwidth information of the broadcast service, and wherein the receiver is further configured to achieve access to the broadcast service based on at least one of the requirement information and the bandwidth information.
45. The apparatus of claim 35, wherein there is a plurality of access information for one broadcast service.
46. The apparatus of claim 35, wherein the broadcasting system comprises an Open Mobile Alliance browser and content mobile broadcast (OMA BCAST) system.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) 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:
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9) Throughout the drawings, like reference numerals will be understood to refer to like parts, components and structures.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
(10) 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.
(11) 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.
(12) 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.
(13) 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.
(14) 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.
(15) 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
First Exemplary Embodiment
(16) 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.
(17) TABLE-US-00008 TABLE 8 Data Name Type Category Cardinality Description Type 301 Access E O 0 . . . N Access fragment Contains the following attributes: id version validFrom validTo Contains the following sub- elements: ServiceID UsageInfo SessionDescriptionURI SDP ApplicationSpec MediaInformation 302 Id A M 1 ID of the Access fragment. Integer 303 version A M 1 Version of this fragment. The Byte newer version overrides the older (8 bits) one as soon as it has been received. 304 validFrom A O 0 . . . 1 The first moment when this Integer fragment is valid. If not given, the (32 bits), validity is assumed to have started expressed at some time in the past. as NTP time.
(18) 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.
(19) 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.
(20) TABLE-US-00009 TABLE 9 305 validTo A O 0 . . . 1 The last moment when this fragment is Integer valid. If not given, the validity is assumed to (32 bits), end in an undefined time in the future. expressed as NTP time. 306 ServiceID E1 M 1 . . . N Reference 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, Boolean 0 indicates that this service is free to air. 308 TerminalCapability E2 O 0 . . . 1 Specification of required terminal String Requirement capabilities, such as protocols, codecs, bit rate, processing, and memory. UAprof is used for expressing the capabilities.
(21) 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 BandwidthRequriement 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.
(22) The TerminalCapabilityRequirement 308 in Table 9 and BandwidthRequirement 309 in Table 10 have substantially the same functions as those of the conventional access fragment.
(23) TABLE-US-00010 TABLE 10 309 BandwidthRequirement E2 O 0 . . . 1 Specification of required network Integer bandwidth; A broadcast service can include multiple accessible streams (same content) with different bandwidth, so that the terminal can make a choice depending on its current reception condition. 310 AccessType E2 M 1 Defines the type of access. String Possible values; Contains the following Attributes: TransmissionMedia Contains the following elements: TransmissionTopology TransmissionScheme 312 Transmission _Media A M 1 0: Broadcast channel ENUM 1: Interaction channel 313 Transmission_Topology E3 O 0 . . . 1 0: Broadcast Mode ENUM 1: Multicast Mode Contains the following attributes: IP_Address
(24) 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.
(25) 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.
(26) 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.
(27) TABLE-US-00011 TABLE 11 314 IP_Address A O 0 . . . 1 IP address of IP stream, which String transport A Service over Broadcast channel. If Transmission Topology is 0, then Type of IP address is IP Broadcast address. If Transmission Topology is 1, then Type of IP address is IP Broadcast address. 315 Transmission_Scheme E3 O 0 . . . 1 1: Interaction Channel provided by ENUM Interaction Network 2: MMS 3: WAP 1.0 4: WAP 2 x 5: SMS 6: HTTP 7: Service Provider defined Transmission Scheme 316 AccessServerIPAddress E4 O 0 . . . N IP address of Sever, which provides String different access (over interaction Channel) of a Service. 317 AccessServerURL E4 O 0 . . . N ULR of Server, which provides AnyURI different access (over Interaction Channel) of a Service. 318 AccessServerPhoneNumber E4 O 0 . . . N Phone number of Server, which provides different access (over Interaction Channel) of a Service.
(28) 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.
(29) 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.
(30) 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.
(31) 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.
(32) 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.
(33) TABLE-US-00012 TABLE 12 319 UsageInfo E1 O 0 . . . N The text explains the characteristic of this access fragment for a User. This text also contains the information about other Access fragments of a Service if there exists more than 1 Access fragment. Possibly provided in multiple languages. Attributes: Lang 320 Lang A O 0 . . . 1 Language 3-byte ISO 639 language code 321 SessionDescriptionURI E1 O 0 . . . 1 The URI to the SG delivery unit(s) AnyURI which contains the session description that the media application in the terminal uses to access the service. In case of non-broadcast service, AccessURI contains information on how that particular service can be accessed. Contains following Attribute and element: Type Note; Using either AccessURI or SDP is mandatory.
(34) 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.
(35) 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.
(36) TABLE-US-00013 TABLE 13 322 Type A M 1 Type of the AccessURI: Integer 1 - SDP; AccessURI is a reference to SDP description; 2 - MBMS-USD; AccessURI is a reference to MBMS user service description (MBMS- USD) as specified in [26.346] section 5.2. It may contain one or several SDP descriptions. 323 SDP E1 O 0 . . . 1 A session description in SDP (IETF session String (in description protocol) format. SDP format) 324 ApplicationSpec E1 O 0 . . . N Application type that can consume the service String using this access spec defined by MIME type.
(37) TABLE-US-00014 TABLE 14 325 MediaInformation E1 O 0 . . . N Optional reference to an icon, pictogramme, animation or audio. PreviewData or reference to PreviewData is used here. Attributes: usage id 326 Usage A M 1 Possible values: background, Integer icon(e.g.). (8 bits) 327 Id A M 1 ID of the PreviewData fragment. Integer (8 bits) 328 <proprietary E1 O 0 . . . N Any number of proprietary or elements/attributes> or lower. application-specific elements or A attributes that are not defined in this specification.
(38) With reference to
(39)
(40) Referring to
(41) The transmission apparatus of
(42)
(43) Referring to
(44) 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.
(45) 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.
(46) 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.
(47) 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.
(48)
(49) Referring to
(50)
(51) Referring to
(52) 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.
(53) 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.
(54) 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.
(55) 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.
(56) 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.
(57) 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.
Second Exemplary Embodiment
(58) With reference to Table 15 to Table 18 and
(59) 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.
(60) 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.
(61) TABLE-US-00015 TABLE 15 Name Type Category Cardinality Description Data Type *01 Access E O 0 . . . N Access fragment Contains the following attributes: id version validFrom validTo ServiceProtection Contains the following sub- elements: TerminalCapabilityRequirement BandwidthRequirement AccessType ServiceID ExtensionURL UsageInfo SessionDescriptionURI SDP ApplicationSpec MediaInformation *02 Id A M 1 ID of the Access fragment. Integer *03 version A M 1 Version of this fragment. The Byte newer version overrides the (8 bits) older one as soon as it has been received. *04 validFrom A O 0 . . . 1 The first moment when this Integer fragment is valid. If not given, (32 bits), the validity is assumed to have expressed started at some time in the past. as NTP time. *05 validTo A O 0 . . . 1 The last moment when this Integer fragment is valid. If not given, (32 bits), the validity is assumed to end in expressed an undefined time in the future. as NTP time. *06 ServiceProtection A M 1 If true, this indicates that this Boolean access related to the associated service is protected by OMA BCAST Service protection; if false, this indicates this access related to the associated service is not protected by OMA BCAST Service protection.
(62) 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, Access Type*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.
(63) TABLE-US-00016 TABLE 16 *07 TerminalCapabilityRequirement E1 O 0 . . . 1 Specification of required terminal capabilities for String this access, such as protocols, codecs, bit rate, processing and memory; UAprof is used for expressing the capabilities. *08 BandwidthRequirement E1 O 0 . . . 1 Specification of required network bandwidth to Integer access described in this fragment. A broadcast service can include multiple accessible streams (same content) with different bandwidth, so that the terminal can make a choice depending on its current reception condition. *09 AccessType E1 M 1 Defines the type of access; Contains the following Attributes: TransmissionMedia Contains the following elements: TransmissionTopology TransmissionScheme *10 Transmission_Media A M 1 This attribute indicates which channel is used for Integer the delivery of services, whose IDs are listed in this Access Fragment. 0: Broadcast Channel 1: Interaction Channel *11 Transmission_Topology E2 O 0 . . . 1 This element is used for the indication of IP Integer transmission mode over Broadcast Channel. There are two possible modes. 0: Broadcast Mode 1: Multicast Mode Contains the following Attributes: IP_Address *12 IP_Address A O 0 . . . 1 IP address of IP stream, which transport A Service String over Broadcast channel. If Transmission Topology is 0, then Type of IP address is IP Broadcast address. If Transmission Topology is 1, then Type of IP address is IP Multicast address. Note: This attribute is used when SDP is not included in Access Fragment. If SDP in Access Fragment exists, IP address of the receiver IP address in SDP is used. *13 Interaction_Scheme E2 O 0 . . . 1 This element indicates which communication Integer system or protocol is used for Interaction.
(64) 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.
(65) 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.
(66) 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.
(67) 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.
(68) 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.
(69) 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.
(70) 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.
(71) TABLE-US-00017 TABLE 17 Channel. 1: Interaction Channel provided by Interaction network 2: MMS 3: WAP 1.0 4: WAP 2 x 5: SMS 6: HTTP 7: Service Provider defined Transmission Scheme *14 AccessServerIPAddress E3 O 0 . . . N IP address of Server, which provides String different access (over interaction Channel) of a Service. *15 AccessServerURL E3 O 0 . . . N ULR of Server, which provides AnyURI different access (over interaction Channel) of a Service. *16 AccessServerPhoneNumber E3 O 0 . . . N Phone number of Server, which Integer provides different access (over Interaction Channel) of a Service. *17 ServiceID E1 M 0 . . . N Reference to the service fragment(s) to Integer which the access fragment belongs. *18 ExtensionURL E1 O 0 . . . N URL containing additional information AnyURI in an extension fragment. *19 UsageInfo E1 O 0 . . . N This text helps the user understand what difference it makes to use one or the other access fragment. It is mandatory in case more than one access fragment is available at a given point in time. Possibly provided in multiple languages. Attributes: Lang *20 Lang A O 0 . . . 1 Language 3-byte ISO 639 language code *21 SessionDescriptionURI E1 O 0 . . . 1 The URI to the SG delivery unit(s) AnyURI which contain the session description that the media application in the terminal uses to access the service. In case of non-broadcast service, SessionDescriptionURI contains information how that particular service can be accessed. Contains the following Attribute:
(72) 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.
(73) 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.
(74) 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.
(75) TABLE-US-00018 TABLE 18 Type Note: Using either SessionDescriptionURI or SDP is mandatory. *22 Type A M 1 Type of the AccessURI Integer 1 - SDP; AccessURI is a reference to SDP description; 2 - MBMS-USD; AccessURI is a reference to MBMS user service description (MBMS-USD) as specified in [26.346] section 5.2. It may contain one or several SDP descriptions. *23 SDP E1 O 0 . . . 1 A session description in SDP (IETF String session description protocol) format. (in SDP format) *24 ApplicationSpec E1 O 0 . . . N Application type that can consume String the service using this access spec defined by MIME type. *25 Medialnformation E1 O 0 . . . N Optional reference to an icon, pictogramme, animation or audio. PreviewData or reference to PreviewData is used here. Attributes: usage id *26 Usage A M 1 Possible values: background, Integer icon(e.g.). (8 bits) *27 Id A M 1 ID of the PreviewData fragment. Integer (8 bits) *28 <proprietary E1 or O 0 . . . N Any number of proprietary or elements/attributes> lower. application-specific elements or A attributes that are not defined in this specification.
(76) 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.
(77)
(78) Referring to
(79) 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.
(80) 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.
(81) 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.
(82) 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.
(83) 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.
(84)
(85) Referring to
(86) 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.
(87) 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.
(88) 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.
(89) 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.
(90) 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.
(91) 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.
Third Exemplary Embodiment
(92) 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.
(93) 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.
(94) 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.
(95) 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.
(96) 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.
(97) 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.
(98) 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.
(99) 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.
(100) 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.
(101) TABLE-US-00019 TABLE 19 Name Type Category Cardinality Description Data Type Access E Access fragment Contains the following attributes: id version validFrom validTo Contains the following sub-elements: AccessType ServiceAccessNotificationURL KeyManagementSystem TerminalBindingKeyID ExtensionURL ServiceIDRef ScheduleReference UsageInfo AlternativeAccessURL TerminalCapabilityRequirement BandwidthRequirement ServiceClass PreviewDataIDRef NotificationReception Id A NM/ 1 ID of the Access fragment, globally anyURI TM unique. version A NM/ 1 Version of this fragment. The newer unsignedInt TM version overrides the older one as soon (32 bits) as it has been received. validFrom A NO/ 0 . . . 1 The first moment when this fragment int TM is valid. If not given, the validity is (32 bits). assumed to have started at some time expressed in the past. as NTP time.
(102) TABLE-US-00020 TABLE 20 validTo A NO/ 0 . . . 1 The last moment when this fragment is int TM valid. If not given, the validity is (32 bits), assumed to end in an undefined time in expressed the future. as NTP time. AccessType E1 NM/ 1 Defines the type of access. TM Contains the following Attribute: transmissionMedia Contains the following elements: BroadcastServiceDelivery UnicastserviceDelivery transmissionMedia A NM/ 1 This attribute indicates which channel Boolean TM is used for the delivery of service. 0: Broadcast Channel 1: Interaction Channel BroadcastServiceDelivery E2 NO/ 0 . . . 1 This element is used for the indication TM of IP transmission. This element may only be present when: TransmissionMedia == 0. Contains the following Attribute: bdsType destinationIPAddress Contains the following elements: SessionDescriptionReference SDP
(103) TABLE-US-00021 TABLE 21 bdsType A NO/ 0 . . . 1 Identifier of the type of underlying unsignedByte TM distribution system that this access fragment relates to. This attribute may only be present when: TransmissionMedia == 0. Defined values 0: DVB-H IPDC 1. 3GPP MBMS Rel-6 2: 3GPP MBMS Rel-7 3: 3GPP2 BCMCS (1x) 4: 3GPP2 BCMCS (HRPD) 5: 3GPP2 Enhanced BCMCS (HRPD) 6-127: reserved for future use 128-255: reserved for proprietary use destinationIPAddress A NO/ 0 . . . 1 DestinationIP address of IP stream, string TM which transport A Service over Broadcast channel. Note: This attribute is used when SDP is not included in Access Fragment. If SDP in Access Fragment exists, IP address of the receiver IP address in SDP is used.
(104) TABLE-US-00022 TABLE 22 Session E3 NO/ 0 . . . N The reference to the Description TM SessionDescription this access Reference relates to. Note: The SessionDescription itself may be delivered in two ways via broadcast or via fetch over interaction channel. In the case of broadcast delivery, the SessionDescription fragment is either delivered in SGDU or encapsulated in this Access fragment. In the latter case the SDP element is used instead of the Session Description Reference. If AuxiliaryDescription fragments are provided they are referenced by the SessionDescriptionReference. In the case of fetch over interaction channel, the Session Description can be acquired by accessing the URI (given as attribute of this element). Contains the following Attributes: type uri idRef
(105) TABLE-US-00023 TABLE 23 type A NM/TM 1 Type of the session description referred by this unsignedByte SessionDescriptionReference 0 - SDP 1 - MBMS User Service Description (MBMS- USD) as specified in [26.346] section 5.2. It may contain one or several SDP descriptions. 2 - AssociatedDeliveryProcedure for File Distribution 3 - AssociatedDeliveryProcedure for Stream Distribution 4-127 Reserved for future use 128-255 Reserved for proprietary use uri A NO/TM 0 . . . 1 The URI to the file containing anyURI SessionDescription that the media application in the terminal uses to access the service or the URI for associatedDeliveryProcedure for File and Stream Distribution. idRef A NO/TM 0 . . . 1 The id of the SessionDescription fragment this anyURI access refers to, globally unique. SDP E3 NO/TM 0 . . . 1 A session description in SDP (IETF session string description protocol) format.
(106) TABLE-US-00024 TABLE 24 UnicastServiceDelivery E2 NO/TM 0 . . . N This element indicates which server and/or protocol is used for delivery of service over Interaction Channel. This element may only be present when: TransmissionMedia == 1. Contains the following elements: AccessServerURL AccessServerURL E3 NO/TM 0 . . . N Server URL from which the terminal anyURI can receive the service via the Interaction Network. For example, AccessServerURL can be an HTTP URL pointing to downloadable content, or an RTSP URL pointing to a streaming server for starting a streaming session. Contains the following Attribute: transmissionSchemeType
(107) TABLE-US-00025 TABLE 25 transmission A NM/TM 1 Specifies transport mechanism that is used unsignedByte SchemeType 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-MSS (3GPP2 multimedia streaming services) 7 - 3GPP CS videotelephony (3GPP Circuit Switched H324m call) 8 - FLUTE 9-127 Reserved for future use 128-255 Reserved for proprietary use (Note: Other protocol or communication system may be added based on OMA Service interaction function). ServiceAccessNo- E1 NO/TM 0 . . . N URL that the terminal may use to notify anyURI tificationURL when it accesses (switches to) this service over this access. The terminal shall not use this URL for notification without user consent. Note: This URL can for example be used for initiating server-managed channel switching in unicast transmission.
(108) TABLE-US-00026 TABLE 26 KeyManage- E1 NO/ 0 . . . N Identifies the type of Key mentSystem TM Management System(s)(KMS) that can be used to contact the Rights Issuer and, for GBA, whether GBA_U is mandatory or whether either GBA_ME or GBA_U can be used. Note that the Rights Issuer can support more than one KMS. If KeyManagementSystem is not specified, it means no protection is 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 i.e. either GBA_ME or GBA_U can be used; oma-bcast-gba_u-bcmcs Indicates GBA_U 3GPP2 BCMCS SKI; oma-bcast-gba_me-bcmcs Indicates GBA_ME 3GPP2 BCMCS SKI i.e. either GBA_ME or GBA_U can be used; oma-bcast-prov-bcmcs Indicates provisioned 3GPP2 BCMCS SKI. Contains the following Attributes: ProtectionType RightsIssuerURI
(109) TABLE-US-00027 TABLE 27 ProtectionType A NM/TM 1 . . . 2 Specifies the protection type offered by the unsignedByte KMS. (8 bits) Values: 1 Content protection only 2 Service protection only 3 Both Content protection and Service Protection 4 Use of terminal binding (smartcard profile only) 5-127 Reserved for future use 128-255 Reserved for proprietary use RightsIssuerURI A NM/TM 1 Specifies the RightsIssuer URI. anyURI TerminalBinding E1 NO/TM 1 Number identifying the Terminal Binding int (32 bits) KeyID Key ID (TBK ID) that is needed to access the service. It is TM for terminals with the smartcard profile. It does not apply to the DRM profile. Contains the following optional Attribute: RightsIssuerURI RightsIssuerURI A NO/TM 0 . . . 1 Specifies the RightsIssuer URI for the anyURI TerminalBindingKey if it is different to the RightsIssuerURI indicated in the KeyManagementSystem element. i.e. If the attribute is not present, the same RightsIssuerURI is used to acquire both SEK/PEK and TerminalBindingKey.
(110) TABLE-US-00028 TABLE 28 ServiceIDRef E1 NO/TM 0 . . . N Reference to the service fragment(s) to which anyURI the access fragment belongs. Either one of the ServiceIDRef or ScheduleIDRef but not both shall be instantiated. Note: Implementation in XML Schema using <choice>. Each Service fragment shall be associated to at least one Access fragment to enable the terminal to access the Service. ScheduleReference E1 NM/TM 0 . . . N Reference to the schedule fragment(s) to which the access fragment belongs. This provides a reference to a Schedule fragment to temporarily override the default Access fragment of the Service addressed by the Schedule. Either one of ServiceIDRef or ScheduleIDRef but not both shall be instantiated. Note: Implementation in XML Schema using <choice>. Contains Attribute: idRef Contains sub-element: DistributionWindowID
(111) TABLE-US-00029 TABLE 29 idRef A NM/TM 1 Identification of the Schedule fragment anyURI which the Access fragment relates to. DistributionWindowID E2 NO/TM 0 . . . N Relation reference to the integer DistributionWindowID to which the access fragment belongs. The DistributionWindowIDs declared in this element shall be the complete collection or a subset of the DWids declared in the Schedule fragment, to which idRef reference belongs. UsageInfo E1 NO/TM 0 . . . N This text helps the user understand what string difference it makes to use one or the other access fragment. It is mandatory in case more than one access fragment is available at a given point in time. Possibly provided in multiple languages. The language is expressed using built-in XML attribute xml:lang with this element. AlternativeAccessURL E1 NO/TM 0 . . . N Specify alternative URL of the content for anyURI retrieving it via the interaction channel (e.g. if the content cannot be received via the broadcast channel).
(112) TABLE-US-00030 TABLE 30 TerminalCa- E1 NO/ 0 . . . 1 Terminal capabilities required pability TM to consume the service or content. Requirement For video and audio, the media type and the related type attributes in the SDP (see section 5.1.2.5) signal the audio/video decoder. This way, these parameters complement the TerminalCapabilityRequirement. Additionally, the complexities of the audio/video streams are described here if they differ from the complexities which can be derived from the media type attributes in the SDP (e.g. level). In this case, the parameters defined in the Access fragment take priority. Sub-elements: Video Audio DownloadFile Video E2 NO/ 0 . . . 1 Video codec capability related TM requirements Sub-elements: Complexity
(113) TABLE-US-00031 TABLE 31 Complexity E3 NO/TM 0 . . . 1 The complexity the video decoder has to deal with. It is recommended that this element is included if the complexity indicated by the MIME type parameters in the SDP differs from the actual complexity. Sub-elements: Bitrate Resolution MinimumBufferSize Bitrate E4 NO/TM 0 . . . 1 The total bit-rate of the video stream. Attributes: average maximum average A NO/TM 0 . . . 1 The average bit-rate in kbits/sec unsigned Short (16 bits) maximum A NO/TM 0 . . . 1 The maximum bit-rate in kbits/sec unsigned Short (16 bits)
(114) TABLE-US-00032 TABLE 32 Resolution E4 NO/TM 0 . . . 1 The resolution of the video. Attributes: horizontal vertical horizontal A NM/TM 1 The horizontal resolution of the video. unsignedShort (16 bits) vertical A NM/TM 1 The vertical resolution of the video. unsignedShort (16 bits) Minimum E4 NO/TM 0 . . . 1 The minimum decoder buffer size required to unsignedInt BufferSize process the video content in kbytes. (32 bits) Audio E2 NO/TM 0 . . . 1 The audio codec capability. Sub-elements: Complexity
(115) TABLE-US-00033 TABLE 33 Complexity E3 NO/TM 0 . . . 1 The complexity the audio decoder has to deal with. It is recommended that this element is included if the complexity indicated by the MIME type parameters in the SDP differs from the actual complexity. Sub-elements: Bitrate MinimumBufferSize Bitrate E4 NO/TM 0 . . . 1 The total bit-rate of the audio stream. Attributes: average maximum average A NO/TM 0 . . . 1 The average bit-rate in kbits/sec. unsignedShort (16 bits) maximum A NO/TM 0 . . . 1 The maximum bit-rate in kbits/sec. unsignedShort (16 bits) MinimumBuff- E4 NO/TM 0 . . . 1 The minimum decoder buffer size required unsignedInt erSize to process the video content in kbytes. (32 bits)
(116) TABLE-US-00034 TABLE 34 DownloadFile E2 NO/TM 0 . . . 1 The required capability for the download files. Sub-elements: MIMETypeSet MIMETypeSet E3 NO/TM 0 . . . N Assuming a download service consists of a set of files with different MIME types which together make up the service, the terminal must support all of these MIME types in order to be able to present the service to the user. A MIMETypeSet lists all of these MIME types. If a terminal does not support one or more of the MIME types, it will probably not be able to present the service. Sub-elements: Type Type E4 NO/TM 0 . . . N One MIME type in the MIMETypeSet. The format of string this string shall follow the Content-type syntax in [RFC 2045]. Contains the following Attributes: Codec
(117) TABLE-US-00035 TABLE 35 Codec A NO/TM 0 . . . 1 The codec parameters for the associated MIME string Media type. If the file's MIME type definition specifies mandatory parameters, these must be included in this string. Optional parameters containing information that can be used to determine as to whether the terminal can make use of the file should be included in the string. One example of the parameters defined for audio/3GPP, audio/3GPP2, video/3GPP, video/3GPP2 is specified in [RFC4281]. BandwidthRe- E1 NO/TM 0 . . . 1 Specification of required network bandwidth to integer quirement access described in this fragment; A broadcast service can include multiple accessible streams (same content) with different bandwidth, so that the terminal can make a choice depending on its current reception condition. ServiceClass E1 NM/TM 1 . . . N The ServiceClass identifies the class of service. This string identification is more detailed than the type attribute in the service fragment and allows the association of service/access combination to specific applications.
(118) TABLE-US-00036 TABLE 36 Pre- E1 NO/ 0 . . . N Reference to the PreviewData anyURI viewData TM fragment which specifies an IDRef icon, pictogramme, animation or audio. Attribute: usage usage A NM/ 1 Possible values: unsign- TM 0. unspecified edByte 1. background (8 bits) 2. icon/logo 3. poster 4. trailer 5. barker 6. service/channel zapping 7-127. reserved for future use 128-255. reserved for proprietary use Note: only usage = 6 (service/ channel zapping) is the valid value when the preview data is associated with Access fragment.
(119) TABLE-US-00037 TABLE 37 Notification E1 NO/TM 0 . . . 1 Reception information for Notification Reception Messages. NotificationPort is mandatory because a designated UDP Port shall be used to deliver the notification message through an on-going session or the designated session while NotificationAddress is optionally used for the delivery of Notification Messages through the designated multicast or broadcast session. Contains the following attributes: NotificationPort NotificationAddress NotificationRequestURL NotificationPollURL Notification A NO/TM 0 . . . 1 Service-specific Notification Message delivery integer Port UDP Port number. Notification A NO/TM 0 . . . 1 Service-specific Notification Message delivery string Address IP multicast address. Note: If Notification Message is delivered over interaction channel, this attribute should be combined with NotificationPort. Notification A NO/TM 0 . . . 1 URL through which the terminal can subscribe anyURI RequestURL to service-specific Notification Messages. Notification A NO/TM 0 . . . 1 URL through which the terminal can poll anyURI PollURL service-specific Notification Messages. <proprietary E1 or NO/TO 0 . . . N Any number of proprietary or application- elements/ lower, specific elements or attributes that are not attributes> A defined in this specification.
(120) 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.
(121) 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.
(122) Further, embodiments of the present invention can provide an efficient access fragment format when accessing a plurality of services through one access fragment.
(123) 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.
(124) 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.
(125) 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.