KR101540473B1 - Esg discovery apparatus and method in cbms - Google Patents

Abstract

A method of supporting mobility of a terminal in a server of a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), the method comprising: providing a broadcast service to a terminal in a predetermined IP platform and an Electronic Service Guide (ESG) Listing local IPDC operators; Generating roaming information for a local IPDC operator having a roaming partner among the local IPDC operators; And transmitting broadcasting service information including the roaming information through a broadcasting network, in a server of a mobile broadcasting system.

CMBS, ESG, IPDC, ESG discovery mechanism, PSI / SI, ESG bootstrap

Description

[0001] ESG DISCOVERY APPARATUS AND METHOD IN CBMS [0002]

The present invention relates to a CBMS (Convergence of Broadcast and Mobile Services) system for supporting mobility, and more particularly, to an electronic service guide (ESG) discovery method and apparatus.

The configuration of a general CBMS system is as shown in FIG.

Referring to FIG. 1, an Internet Protocol (IP) datacast on Digital Video Broadcasting-Handheld (DVB-H) includes a set of entities that cooperate to implement required performance. The service application unit 110 obtains content from a plurality of sources and their associated metadata to provide a specific service application. The service management unit 120 includes a plurality of lower-level entities for managing various kinds of services. The broadcast network 130 and the interactive network 135 are transmission bearers in the CBMS. The terminal 140 in the CBMS can receive services and signaling through the broadcast network 130 and can perform bidirectional communication via the bidirectional network 135. CBMS-x and X-x are reference points between different functional entities. CBMS-x is a reference point in the range of IP datacast in DVB-H, and X-x is a reference point outside of IP datacast in DVB-H.

This specification is based on the existing ESG specification. By the way, in order to extend the ESG specification to support the interactive ESG, a new version of the ESG specification is under development. Thus, for example, modifications to elements, locations, parameters, etc. may be required when introduced into a new version of the ESG specification.

The ESG discovery mechanism of the terminal in the CBMS system as described above is as follows.

1) receiving PSI / SI (Program Specific Information / Service Information)

2) Choose an IP platform,

3) Retrieve the ESG bootstrap for the selected IP platform,

4) Select ESG by ESGProviderDiscoveryDescriptor and ESGAccessDescriptor in ESG Bootstrap, and search for ESG.

That is, the terminal first selects one IP platform, and then selects the ESG in the IP platform. The service described in the ESG can belong to exactly one Internet Protocol Data Casting (IPDC) operator, and such information is given in the acquisition fragment. This means that after the terminal selects / retrieves the ESG, it can acquire information about the IPDC operator to which each service belongs. Currently, IPDC operators are identified by IDPSKMSID and IPDCOperatorID. However, if the identifier is changed in the future, the related identifier should also be replaced with a new identifier.

In general, there can be multiple IP platforms in one network. And, each IP platform 211 has its own ESG bootstrap 220, as shown in FIG. Within each ESG bootstrap 220, there may be multiple ESG providers. Each ESG provider provides multiple ESGs. Each ESG describes services from different IPDC operators 235.

However, in the ESG acquisition method as described above, the problem of mobility is not considered. 3, the terminal first selects its IP platform 320 in the PSI / SI 310 for the ESG bootstrap, and transmits the ESGProviceDiscoveryDescriptor information provided in the ESGProviderDiscoveryDescriptor and ESGAccessDescriptor and the ESGProviderDiscoveryDescriptor information provided in the ESGProvider, . After retrieving the ESG 340, the terminal obtains available IPDC operator information 350 and selects 350 an IPDC operator available from the IPDC operator included in the information.

4 is a signal flow diagram for explaining the operation of the terminal for ESG discovery as described above.

Referring to FIG. 4, the terminal acquires PSI / SI in step 405 and selects an available IP platform in step 410. In step 415, the terminal performs an ESG bootstrap from the selected IP platform. In step 420, the terminal selects an ESG from the ESGProviderDiscoveryDescriptor and the ESGAccessDescriptor, and acquires the ESG by accessing the selected ESGFLUTE (step 425).

In step 430, it is determined whether the terminal supports an available KMS (Key Management System) in the ESG. If it is determined in step 430 that the terminal supports the available KMS, it is determined in step 435 whether the terminal supports the available IPDC operator. If it is determined in step 435 that the terminal supports the available IPDC operator, the terminal selects one IPDC operator in step 440 and then accesses or purchases the service in step 445.

If it is determined in step 430 that the terminal does not support the available KMS, the terminal determines whether all the ESGs are checked in step 450. [ If it is determined in step 450 that all the ESGs are not checked, it is determined in step 455 whether the terminal desires another ESG check. As a result of step 455, if it is desired to confirm another ESG, the terminal proceeds to step 420 and terminates the operation if it is not desired.

If it is determined in step 450 that all the ESGs are checked, the UE determines in step 460 whether the ESG bootstrap of all the IP platforms is checked. If it is determined in step 460 that the ESG bootstrap of all the IP platforms is checked, the terminal terminates. Otherwise, the process proceeds to step 465.

In step 465, the terminal checks whether another ESG bootstrap check from another IP platform is desired. If it is determined in step 465 that another ESG bootstrap is desired to be checked, the process proceeds to step 410. Otherwise, the process is terminated.

However, if the terminal can only use a service from a specific IPDC operator (e.g., the terminal registers a service from the IPDC operator), the terminal knows which ESG has service information associated with the IPDC operator none. Accordingly, the terminal has to search for each ESG bootstrap information and perform a process of analyzing all the ESGs until it finds an expected service related to the expected IPDC operator.

In particular, in the case of a terminal which moves to a foreign country and is receiving a roaming service, it becomes more difficult to know the IPDC operator information to serve itself. That is, in the Phase 1 specification, the terminal must retrieve each ESG bootstrap information and search for and interpret each ESG to find an IPDC operator providing roaming service to the terminal.

SUMMARY OF THE INVENTION Accordingly, it is an object of the present invention to provide a method for acquiring an ESG quickly and easily.

According to an aspect of the present invention, there is provided a method of supporting mobility of a terminal in a server of a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), the method comprising: Listing local IPDC operators providing a broadcast service to a terminal in an Electronic Service Guide (ESG); Generating roaming information for a local IPDC operator having a roaming partner among the local IPDC operators; And transmitting broadcasting service information including the roaming information through a broadcasting network. The present invention provides a method of supporting mobility of a terminal in a server of a mobile broadcasting system.

The present invention also provides a method of supporting mobility in a terminal of a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), comprising the steps of: providing a broadcast service from a predetermined IP platform and an Electronic Service Guide (ESG) Receiving broadcast service information including information of local IPDC operators providing the broadcast service information through a broadcasting network; Analyzing the broadcast service information to obtain roaming information for a local IPDC operator having a roaming partner among the local IPDC operators; Searching for a specific local IDPC operator having the subscribed local IPDC operator as the roaming partner from the obtained roaming information when the broadcast service can not be provided through the subscribed local IDPC operator; And accessing the broadcast service using the ESG of the specific local IDPC operator when the specific local IPDC operator is found.
In addition, an embodiment of the present invention is a server apparatus for supporting mobility of a terminal in a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), the terminal apparatus comprising: A controller for listing local IPDC operators providing services and generating roaming information for a local IPDC operator having a roaming partner among the local IPDC operators; And a transmitter for transmitting broadcast service information including the roaming information generated from the controller through a broadcasting network.
In addition, an embodiment of the present invention is a terminal device supporting mobility in a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), which can provide a broadcasting service to a terminal in a predetermined IP platform and an Electronic Service Guide (ESG) A receiving unit for receiving broadcast service information including information of providing local IPDC operators through a broadcasting network; And analyzing the broadcast service information to obtain roaming information for a local IPDC operator having a roaming partner among the local IPDC operators, and when the broadcast service can not be provided through the affiliated local IDPC operator, And a control unit for accessing the broadcast service using the ESG of the specific local IDPC operator when the specific local IPDC operator is found, A terminal device supporting mobility in a broadcasting system is provided.
The present invention also provides a method of supporting mobility in a terminal of a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), comprising the steps of: providing a broadcast service from a predetermined IP platform and an Electronic Service Guide (ESG) Generating a request message including at least one key value requesting transmission of information to one local IPDC operator among the local IPDC operators providing the local IPDC operator; Transmitting a request message including the at least one key value requesting transmission of information to the local IPDC operator to the server through an interactive channel; And receiving, from the server, a response message including information on the local IPDC operator in response to the request message, in a terminal of a mobile broadcasting system.
Also, an embodiment of the present invention provides a method of supporting mobility to a terminal in a server of a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), comprising the steps of: providing a terminal with a predetermined IP platform and an Electronic Service Guide (ESG) Receiving, via an interactive channel, a request message of a terminal including at least one key value requesting transmission of information to one local IPDC operator among local IPDC operators providing a broadcast service; And generating and transmitting a response message including information on the local IPDC operator based on the at least one key value in response to the request message received from the terminal, Lt; RTI ID = 0.0 > mobility. ≪ / RTI >
In addition, an embodiment of the present invention is a terminal device supporting mobility in a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), which can provide a broadcasting service to a terminal in a predetermined IP platform and an Electronic Service Guide (ESG) A control unit for generating a request message including at least one key value requesting transmission of information to one local IPDC operator among the providing local IPDC operators; A transmitter for transmitting a request message including the at least one key value requesting transmission of information to the local IPDC operator to the server through an interactive channel; And a receiver for receiving a response message including information on the local IPDC operator in response to the request message from the server.
In addition, the embodiment of the present invention is a server apparatus for supporting mobility to a terminal in a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), wherein the terminal apparatus broadcasts the terminal apparatus in a predetermined IP platform and an Electronic Service Guide (ESG) A reception unit for receiving, through an interactive channel, a request message of a terminal including at least one key value requesting transmission of information to one local IPDC operator among local IPDC operators providing the service; A transmitter for transmitting a response message to the request message; And a controller for generating a response message including information on the local IPDC operator based on the at least one key value in response to the request message received from the terminal, And a server device.
In addition, according to an embodiment of the present invention, there is provided a method of supporting mobility of a terminal in a server of a mobile broadcasting system providing IPDC (Internet Protocol Data Casting), comprising the steps of: Generating broadcast service information including type information of an electronic service guide (ESG); And transmitting broadcasting service information including the type information of the ESG to a mobile station in a mobile broadcasting system.
In addition, according to an embodiment of the present invention, there is provided a method of supporting mobility in a terminal of a mobile broadcasting system providing Internet Protocol Data Casting (IPDC), wherein access types are classified according to availability of a roaming service Receiving broadcast service information including type information of an electronic service guide (ESG) from a server; And selecting a desired ESG based on the type information of the ESG. The present invention also provides a method of supporting mobility in a terminal of a mobile broadcasting system.
In addition, an embodiment of the present invention is directed to a server apparatus for supporting mobility of a terminal in a mobile broadcasting system providing IPDC (Internet Protocol Data Casting), in which an access type is classified according to availability of a roaming service A control unit for generating broadcast service information including type information of an electronic service guide (ESG); And a transmitter for transmitting broadcast service information including the type information of the ESG, in a mobile broadcasting system supporting a mobility of a terminal.
In addition, embodiments of the present invention provide a terminal device supporting mobility in a mobile broadcasting system providing IPDC (Internet Protocol Data Casting), in which an access type is classified according to availability of a roaming service A receiving unit for receiving broadcast service information including type information of an electronic service guide (ESG) from a server; And a controller for selecting a desired ESG based on the type information of the ESG. The terminal device supports mobility in a mobile broadcasting system.

In the present invention, in the case where mobility is provided, all ESGs as well as information in all ESG bootstrap have to be retrieved and searched in order to find corresponding IPDC operator information that can be accessed by the UE in the conventional method. However, Method has the advantage of being able to acquire the ESG more easily and quickly.

BRIEF DESCRIPTION OF THE DRAWINGS Specific exemplary embodiments of the present invention will now be described in more detail with reference to the accompanying drawings.

The present invention proposes a method for allowing a terminal to acquire an appropriate ESG more quickly and easily. Although the discussion below is based on the phase 1 ESG specification, the interactive ESG bootstrap and phase 2 ESG specification may have some differences and some modifications may be required.

Before describing an embodiment of the ESG discovery method as described above, two possible scenarios will be described according to the relationship between the IP platform and the IPDC operator.

<Scenario 1>

PSI / SI includes one or more IP platforms, there is more than one IPDC operator in the network, and each IPDC operator exists only on one IP platform. In other words, the same IPDC operator can not be found on different IP platforms.

An example of the first scenario is shown in Fig.

Referring to FIG. 5, there are two IP platforms, IP platform A 510 and IP platform B 520. There are four IPDC operators: IPDC Operator I (530), IPDC Operator II (540), IPDC Operator III (550), and IPDC Operator IV (560). Each IPDC operator is associated with only one IP platform. That is, IPDC Operator I 560 and IPDC Operator II 540 are in IP platform A 510 and IPDC Operator III 550 and IPDC Operator IV 560 are in IP Platform B 520

<Scenario 2>

PSI / SI includes one or more IP platforms, one or more IPDC operators in the network, and the same IPDC operator exists on more than one IP platform at the same time. In other words, the same IPDC operator can be found on different IP platforms.

An example of the second scenario is shown in Fig.

Referring to FIG. 6, there are two IP platforms, IP platform A 610 and IP platform B 620. There are three IPDC operators: IPDC Operator I (630), IPDC Operator II (640), and IPDC Operator III (650). Each IPDC operator may be associated with one or more IP platforms. That is, IPDC operator II 640 is associated with both IP platform A 610 and IPDC platform B 620.

Hereinafter, embodiments of various ESG discovery methods according to the present invention will be described in consideration of the two scenarios as described above.

&Lt; Embodiment 1 >

In the first embodiment, the IPDC operator information is included in the ESG bootstrap in advance. In the first embodiment, it is assumed that the ESG bootstrap is a constituent unit for each IP platform regardless of the number of IPDC operators existing in the IP platform.

The terminal only needs to select the IP platform that contains its IPDC operator for the ESG bootstrap. Here, whether the terminal finds the IP platform matched to itself is a separate problem. That is, the terminal may acquire the information by a provisioning channel or a specific signaling channel or a bidirectional channel.

When the terminal can not know which IP platform includes its IPDC operator, the terminal needs to interpret the ESG bootstrap information from each IP platform when applied to scenario 1 as shown in FIG. .

On the other hand, the terminal needs to interpret one or more ESG bootstrap information because each IPDC operator can be included in one or more IP platforms by applying to Scenario 2 as shown in FIG. If there is no prior knowledge of the IP platform to which the IPDC operator belongs, the terminal shall retrieve all ESG bootstrap from all IP platforms. If there is prior information about which IP platform each IPDC operator is on, the terminal only needs to retrieve the indicated ESG bootstrap from that IP platform. Comparing this with scenario 1, if the IPDC operator is on more than one IP platform, the terminal may need to retrieve one or more ESG bootstrap from different IP platforms.

Also, in the first embodiment, the IPDC operator information may be indicated in the ESG bootstrap.

&Lt; Example 1-1 >

In phase 1 ESG bootstrap, ESGProviderDiscoveryDescriptor and ESGAccessDescriptor provide ESG provider information and all ESG for each ESG provider. 9, based on two descriptors, ESGProviderDiscoveryDescriptor (910-1, 910-m) and ESGAccessDescriptor (920-1-1, 920-mn), and further, any IPDC operator 930 -1) is associated with each ESG provider / ESG. In this way, the terminal can search only the ESG associated with the expected IPDC operator.

The location of the IPDC operator information in the bootstrap may vary. In a bidirectional ESG bootstrap, it can be slightly different and can be modified / changed.

That is, it is possible to add a new descriptor to the AccessDescriptor as shown in Table 6, Table 8, or Table 10, or to add a new descriptor as shown in FIG. 11, as shown in Table 1 below.

Fig. 10 shows a structure in which IPDC operator information having these various positions is described. FIG. 10 shows a case where IPDC operator 1013 information is described in the ESG bootstrap 1010. An example of the ESG provider descriptor descriptor 1010 included in the ESG bootstrap 1010 is shown in Table 1 below.

Or IPDCType can be defined, so that it is as shown in Table 2 below.

The IPDCType is shown in Table 3 below.

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>

Or more specifically, as shown in Table 4 below.

<complexType name = "IPDCType">
<sequence>
<element name = "IPPlatformID" type = "positive Integer"/>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderID" type = "positive Integer"/>
<element name = "ESGURI" type = "anyURI"/>
</ sequence>
</ complexType>

If IPDCOperatorId can not be dictated, IPDCKMSId may someday help the terminal filter the ESG. In that case, an example of IPDCType is shown in Table 5 below.

<complexType name = "IPDCType">
<sequence>
<attribute name = "IPDCKMSId" type = "unsignedShort" use = required "/>
<attribute name = "IPDCOperatorId" type = "string" use = "optional"/>
</ sequence>
</ complexType>

There are various examples of adding the element of the present invention to the syntax of the ESGAccessDescriptor 1012 included in the ESG bootstrap 1010. Here, only three cases will be described.

1) syntax of the first ESGAccessDescriptor 1012,

Syntax ESG Access Descriptor { IPDCKMSId IPDCOperatorId   n_o_ESGEntries   for (i = 0; i <n_o_ESGEntries; i ++) { ESGEntry [i] () } }

Or Table 7 below.

Syntax ESG Access Descriptor {   IPDC   n_o_ESGEntries   for (i = 0; i <n_o_ESGEntries; i ++) {     ESGEntry [i] () } }

2) the syntax of the second ESGAccessDescriptor (1012)

Syntax ESG Access Descriptor { n_o_ESGEntries for (i = 0; i <n_o_ESGEntries; i ++) { ESGEntry [i] ()     IPDCKMSId     IPDCOperatorId } }

Or Table 9 below.

Syntax ESG Access Descriptor {   n_o_ESGEntries   for (i = 0; i <n_o_ESGEntries; i ++) {     ESGEntry [i] ()     IPDC } }

3) The syntax of the third ESGAccessDescriptor (1012)

Syntax ESGEntry  ESGEntryVersion  ESGEntryLength  MultipleStreamTransport  IPVersion6  Reserved  ProviderID if (IPVersion 6) { SourceIPAddress DestinationIPAddress } else { SourceIPAddress DestinationIPAddress }  Port  TSI  IPDCKMSId  IPDCOperatorId }

Or Table 11 below.

Syntax ESGEntry {   ESGEntryVersion   ESGEntryLength   MultipleStreamTransport IPVersion6   Reserved   ProviderID   if (IPVersion 6) { SourceIPAddress DestinationIPAddress   } else { SourceIPAddress DestinationIPAddress   }   Port   TSI   IPDC }

You can also add a new descriptor that contains IPDC operator information to the ESG bootstrap session as follows: Such new descriptors will carry information about each ESG provider and / or ESG's IPDC operator.

<element name = "IPDCOperator">
<complexType>
<sequence>
<element name = "IPDC" type = "esg: IPDCType" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>
</ element>

It may add a new descriptor 1110 that includes IPDC operator information to the ESG bootstrap session as shown in FIG. The new descriptor 1110 will contain information about each ESG provider and / or the IPDC operator of the ESG.

The operation of the terminal in the embodiment 1-1 of the present invention as described above with reference to FIG. 12 will now be described.

Referring to FIG. 12, in step 1205, the terminal acquires PSI / SI. In step 1210, the terminal selects an available IP platform. In step 1215, the terminal ESG bootstrap the terminal from the selected IP platform. In step 1220, the terminal recognizes all the available ESGs from the ESGProviderDiscoveryDescriptor and the ESGAccessDescriptor. In step 1225, the UE confirms the IPDC operator for each ESG. It is determined in step 1230 whether the terminal supports the available KMS in the ESG. If it is determined in step 1230 that the terminal supports the available KMS, it is checked in step 1235 whether the terminal supports the available IPDC operator.

If it is determined in step 1235 that the terminal supports available IPDC, the terminal selects one IPDC operator in step 1240. The terminal selects and accesses one ESG having the IPDC operator previously selected in step 1245, and then accesses or purchases the service in step 1250.

If it is determined in step 1230 that the terminal does not support the available KMS, the terminal determines in step 1255 whether all the IP platform ESG boot strains have been checked. As a result of the determination in step 1255, if the check is completed, the terminal ends the operation. If the check is not completed, the terminal determines in step 1260 whether it desires to check another ESG bootstrap from another IP platform. If it is determined in step 1260 that the user wants to check, the terminal proceeds to step 1210. Otherwise, the terminal ends the operation.

&Lt; Example 1-2 >

Embodiment 1-2 indicates ESG bootstrap information distinguished by the IPDC operator different from the IPDC operator information at the bootstrap level.

Currently, the terminal selects one ESG having the ESG provider by selecting the ESG provider, interpreting the ESGProviderDiscoveryDescriptor and ESGAccessDescriptor, and then the terminal searches for one ESG and then identifies the IPDC operator in the ESG.

In Embodiment 1-2, a new descriptor 1311 related to the IPDC operator is added to the bootstrap 1310, and the ESG provider and / or ESG information is classified by each IPDC operator standard. Respectively. And, the objects related to the descriptor of the bootstrap and each connection relation are shown in Fig.

Comparing this with FIG. 10, in the embodiment 1-2 of FIG. 14, it is different that the IPDCOperator information is checked first and then the ESGProviderDiscoveryDescriptor and the ESGAccessDescriptor are checked.

In the Phase 2 ESG specification, the ESG can be uniquely identified. Accordingly, another method is to provide the relationship between the IPDC provider and the ESG as shown in Fig.

An example of the syntax of the new destructor 1311 added to the ESG bootstrap 1310 is as follows.

<complexType name = "IPDCOperatorDescriptor">
<sequence>
<element name = "IPPlatformID" type = "positiveInteger"/>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderID" type = "positiveInteger"/>
<element name = "ESGURI" type = "anyURI"/>
</ sequence>
</ complexType>

Since each IPDC operator may be associated with more than one ESG, it can be as shown in Table 14 below.

<element name = "IPDCOperatorDiscovery">
<complexType>
<sequence>
<element name = "IPDCOperator" type = "IPDCOperatorType" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>
</ element>

The IPDCOperatorType is shown in Table 15 below.

<complexType name = "IPDCOperatorType">
<sequence>
<element name = "IPDC" type = "IPDCType"/>
<element name = "ProviderURI" type = "anyURI" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ESGURI" type = "anyURI""minOccurs=" 0 "maxOccurs =" unbounded "/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>

Or more specifically, as shown in Table 16 below.

<complexType name = "IPDCOperatorType">
<sequence>
<element name = "IPDC" type = "IPDCType"/>
<element name = "IPPlatformID" type = "positiveInteger" maxOccurs = "unbounded"/>
<element name = "ProviderURI" type = "anyURI" maxOccurs = "unbounded"/>
<element name = "ProviderID" type = "positive Integer" maxOccurs = "unbounded"/>
<element name = "ESGURI" type = "anyURI" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>

Next, the operation of the terminal according to the embodiment 1-2 of the present invention as described above with reference to FIG. 16 will be described.

Referring to FIG. 16, the terminal acquires the PSI / SI in step 1605 and selects an available IP platform in step 1610. In step 1615, the terminal bootstrap ESG from the selected IP platform. In step 1620, the terminal recognizes all the available IPDC operator information in the ESG by the IPDCOperatorDescriptor.

It is determined in step 1625 whether the terminal supports the available KMS in the ESG. If it is determined in step 1625 that the terminal supports the available KMS, it is checked in step 1630 whether the terminal supports the available IPDC operator.

If it is determined in step 1630 that the terminal supports the available IPDC operator, the terminal selects one IPDC operator in step 1635. In step 1640, the terminal selects an ESG associated with the selected IPDC operator from the ESG provider descriptor descriptor and the ESGA access descriptor, and accesses the ESG in step 1645. In step 1650, the terminal accesses or purchases a service.

On the other hand, if it is determined in step 1625 that the terminal does not support the available KMS, the terminal determines whether all the IP platform ESG boot strains have been checked in step 1655. As a result of the determination in step 1655, if the check is completed, the terminal ends the operation. If the check is not completed, the terminal determines in step 1660 whether it desires to check another ESG bootstrap from another IP platform. If it is determined in step 1660 that the UE desires to check, the process proceeds to step 1610. Otherwise, the process ends.

&Lt; Embodiment 2 >

In the second embodiment, IPDC operator information may be indicated in the PSI / SI. In the first embodiment, the IPDC operator information can be obtained by adding the IPDC operator information to the ESG bootstrap. However, because IPDC operator information is indicated at the ESG bootstrap level, the terminal can not know which ESG bootstrap contains its IPDC operator information. If there is no such information, the terminal shall attempt to retrieve all ESG bootstrap information until it finds the expected IPDC operator information.

However, in the second embodiment, the IPDC operator information is indicated at the PSI / SI level.

&Lt; Example 2-1 >

In Embodiment 2-1, regardless of the number of IPDC operators existing in the corresponding IP platform, an ESG bootstrap is set as a unit for each IP platform. If there is more than one IPDC operator in an IP platform, the ESG bootstrap is isolated for each IPDC operator on that IP platform.

To describe what ESG bootstrap is for an IPDC operator, a new IPDC operator descriptor is added to the INT table of PSI / SI as follows.

IP / MAC_notification_section {
Platform_id
target_descriptor_loop ()
target_ip_slash_descriptor () // => Fixed IP address for ESG bootstrap
IPDCOperator_descriptor () // => list all IPDC operator in this IP platform
operational_descriptor_loop ()
}

The syntax of the new IPDC operator descriptor is:

17 is a diagram for explaining Embodiment 2-1 of Scenario 1;

If the terminal already knows which IP platform includes its IPDC operator for the ESG bootstrap, the terminal can select the ESG bootstrap for that IP platform. Although the terminal can not know which IP platform contains its IPDC operator, the terminal can search for IPDC operator information on each IP platform until it finds it.

Fig. 18 is a diagram for explaining the embodiment 2-1 of the scenario 2; Fig.

If the same IPDC operator exists on more than one IP platform and there is more than one ESG bootstrap for that IPDC operator on a different IP platform, the terminal must retrieve more than one ESG bootstrap information.

The operation of the terminal according to the embodiment 2-1 of the present invention as described above with reference to FIG. 19 will now be described.

Referring to FIG. 19, the MS acquires the PSI / SI in step 1905, and analyzes the available IP platform in step 1910. In step 1915, the terminal verifies IPDC operator information for each IP platform.

It is determined in step 1920 whether the terminal supports the available KMS in the ESG. If it is determined in step 1920 that the terminal supports the available KMS, it is determined in step 1932 whether the terminal supports the available IPDC operator.

If it is determined in step 1925 that the terminal supports an available IPDC operator, the terminal selects an IP platform having a supported IPDC operator for the ESG bootstrap in step 1930.

In step 1935, the terminal selects an ESG from the ESGProviderDiscoveryDescriptor and the ESGAccessDescriptor, and accesses the selected ESG in step 1940. In step 1945, it is determined whether the terminal supports the available KMS in the ESG. If it is determined in step 1945 that the terminal supports the available KMS, it is determined in step 1950 whether the terminal supports the available IPDC operator. If it is determined in step 1950 that the terminal supports available IPDC, the terminal selects one IPDC operator in step 1955 and then accesses or purchases the service in step 1960.

On the other hand, if it is determined in step 1945 that the terminal does not support the available KMS, the terminal determines in step 1965 whether all the ESGs are checked. If it is determined in step 1965 that all the ESGs are not checked, it is determined in step 1970 whether the terminal desires to check another ESG. As a result of checking in step 1970, if it is desired to confirm another ESG, the terminal proceeds to step 1935, and if not desired, terminates the operation.

If it is determined in step 1965 that all the ESGs are checked, in step 1975, the terminal determines whether the ESG bootstrap of all the IP platforms is checked. As a result of the determination in step 1975, if the ESG bootstrap of all the IP platforms is checked, the terminal ends the operation. If not, the terminal proceeds to step 1980.

In step 1980, the terminal checks whether another ESG bootstrap check from another IP platform is desired. If it is determined in step 1980 that the MS desires to check another ESG bootstrap, the MS proceeds to step 1930. Otherwise, the MS terminates the operation.

Further, the embodiment 2-1 may be combined with the embodiment 1. [ This means that IPDC operator information is indicated simultaneously at the PSI / SI level and the ESG bootstrap level. The terminal can know from the IPDC operator information at the PSI / SI level which IP platform contains its IPDC operator and can select one for the ESG bootstrap. At the ESG bootstrap level, the added IPDC operator information helps the terminal to select the ESG with its IPDC operator.

However, because there is more than one IPDC operator in an ESG bootstrap, the terminal must distinguish IPDC operators for each ESG.

&Lt; Example 2-2 >

Example 2-2 assumes that the ESG bootstrap is a building block for each IPDC operator in each IP platform. If there is more than one IPDC operator in one IP platform, the ESG bootstrap is separated for each IPDC operator on that IP platform as follows. The following new IPDC operator descriptor is added to the INT table of PSI / SI to describe what ESG bootstrap is for which IPDC operator.

IP / MAC_notification_section {
Platform_id
target_descriptor_loop ()
target_ip_slash_descriptor () // => Fixed IP address for ESG bootstrap
IPDCOperator_descriptor () // for this IPDC operator in this IP platform
operational_descriptor_loop ()
}

The syntax of the added descriptor is as follows.

20 is a diagram for explaining Embodiment 2-2 applied to Scenario 1. When the terminal already knows which IP platform includes its IPDC operator for the ESG bootstrap, You can choose an ESG bootstrap for your IPDC operator. Even if the terminal does not know which IP platform contains its IPDC operator, the terminal can search for IPDC operator information on each IP platform until it finds it.

FIG. 21 is a view for explaining the embodiment 2-2 applied to the scenario 2. When the same IPDC operator exists in more than one IP platform and there is more than one ESG bootstrap for the IPDC operator in different IP platforms, The terminal may need to retrieve more than one ESG bootstrap information.

The operation of the terminal according to the embodiment 2-2 according to the present invention described above with reference to FIG. 22 will now be described.

Referring to FIG. 22, the MS acquires the PSI / SI in step 2205 and analyzes the available IP platform in step 2210. In step 2215, the UE checks all the available IPDC operator information in the ESG by the IPDCOperatorDescriptor.

It is determined in step 2220 whether the terminal supports the available KMS in the ESG. If it is determined in step 2220 that the available KMS is supported, it is determined in step 2225 whether the terminal supports the available IPDC operator.

If it is determined in step 2225 that the terminal supports the available IPDC operator, the terminal selects one IPDC operator in step 2230. In step 2235, the terminal bootstrap ESG from the selected IPDC operator on one IP platform. In step 2240, the terminal selects an ESG associated with the selected IPDC operator from the ESG provider descriptor descriptor and the ESGA access descriptor, and accesses the ESG in step 2245. In step 2250, the terminal accesses the service or makes a service purchase.

On the other hand, if it is determined in step 2220 that the terminal does not support the available KMS, the terminal determines in step 2255 whether all IP platform ESG boot straps have been checked. As a result of the determination in step 2255, the UE terminates the operation when the check is completed, and determines whether it desires to check another ESG bootstrap from another IP platform in step 2260 if the check is not completed. If it is determined in step 2260 that the terminal desires to check, the process proceeds to step 2210. If the terminal does not want to check, the operation ends.

&Lt; Third Embodiment >

In the third embodiment, the ESG bootstrap includes IPDC operator information in PSI / SI, which is a constituent unit for each IPDC operator.

In addition, the third embodiment assumes the following.

1) ESG bootstrap is the building block for each IPDC operator.

2) There may be the same IPDC operator on different IP platforms, and the terminal needs to retrieve more than one ESG information when searching for all IPDC operator related ESG information.

3) ESG bootstrap is changed to IPDC operator.

&Lt; Example 3-1 >

As shown in FIG. 23, each IPDC operator has its own unit ESG bootstrap. Therefore, an ESG bootstrap descriptor can be defined and added to the PSI / SI. In this new descriptor, IPDCOperator_descriptor describes which ESD bootstrap was derived from which IPDC operator. The ESG bootstrap IP address describes the IP address and port number in the ESG bootstrap for that IPDC operator. The ESGBootstrap_descriptor can be looped to list the ESG bootstrap information for all IPDC operators, for example:

The operation of the terminal according to the embodiment 3-1 of the present invention as described above with reference to FIG. 24 will now be described.

Referring to FIG. 24, the terminal acquires PSI / SI in step 2405, and analyzes the available IP platform in step 2410. In step 2415, the terminal interprets the IPDC operator in the ESGBootstrapDescriptor. It is determined in step 2420 whether the terminal supports the available KMS in the ESG. If it is determined in step 2420 that the terminal supports the available KMS, it is determined in step 2425 whether the terminal supports the available IPDC operator.

If it is determined in step 2425 that the terminal supports the available IPDC operator, the terminal selects one IPDC operator in step 2430. In step 2435, the terminal bootstrap ESG from the IPDC operator selected in the selected IP platform. In step 2440, the terminal selects an ESG associated with the IPDC operator previously selected from the ESGProviderDiscoveryDescriptor and the ESGAccessDescriptor. After accessing the ESG in step 2445, the terminal accesses or purchases the service in step 2450.

&Lt; Example 3-2 >

In the embodiment 3-2, as shown in Fig. 25, the ESG bootstrap is a constituent unit for each IP platform in each IPDC operator.

The ESGBootstrap_descriptor is further detailed in Example 3-2, an example of which is as follows.

The operation of the terminal according to the embodiment 3-2 of the present invention will now be described with reference to FIG.

Referring to FIG. 26, the MS acquires the PSI / SI in step 2605, and analyzes the available IP platform in step 2610. The UE confirms the IPDC operator information for each IP platform in step 2615.

It is determined in step 2620 whether the terminal supports the available KMS in the ESG. If it is determined in step 2620 that the terminal supports the available KMS, it is determined in step 2625 whether the terminal supports the available IPDC operator. If it is determined in step 2625 that the terminal supports the available IPDC operator, the terminal selects one IPDC operator in step 2630. In step 2635, the terminal selects one IP platform from the selected IPDC operator. In step 2640, the terminal bootstrap ESG from the IPDC operator selected in the selected IP platform. In step 2645, the terminal selects an ESG associated with the IPDC operator previously selected from the ESGProviderDiscoveryDescriptor and the ESGAccessDescriptor. In step 2650, the terminal accesses the ESG, and then accesses the service or purchases the service in step 2655.

In the current situation, the IPDC operator is treated as having authority to manage the service. In the future, if the authority is changed to another provider or operator who manages the service, the relevant parameters in each mechanism can also be changed to new related parameters. However, the mechanism may still work. That is, if the terminal can provide a way to find the proper ESG, in addition to the IPDC operator information, some other information may be similarly instructed. For example, geographic information, networks, and the like. GEOGRAPHIC INFORMATION Some ESGs may be dedicated to a specific area and should consider local services in different areas.

Table 23 and FIG. 27 show the case where geographical information is added in addition to the IPDC operator information. Table 24 shows cases where network information is added, Lt; / RTI &gt;

27 is a diagram showing an example of a specific ESG for a specific area.

Referring to FIG. 27, the geographical information on the ESG helps the terminal to select an appropriate ESG. Similar to the IPDC operator information, geographical information about the ESG can also be dictated in advance by defining a new element or descriptor. 27, ESG1 (ESGUIR = 1) is provided only for Area1 and ESG2 (ESGURI = 2) is provided for Area2 only. That is, geographical information such as Area1 and Area2 are required to select each ESG Information. Such new elements and descriptors may be indicated as IPDC operator information in the ESG bootstrap as in the first embodiment and may be indicated as IPDC operator information in the PSI / SI as in the second and third embodiments It is possible.

In the first embodiment, when the terminal analyzes the ESG bootstrap, it can be known that the geographical information for each ESG, for example, ESG1 is for Region 1 and ESG2 is for Region 2, which means that related information is added to the ESG bootstrap .

In the second and third embodiments, when the terminal analyzes the PSI / SI, it can be known that the geographical information for each ESG, for example, ESG1 is for Region 1 and ESG2 is for Region 2, SI.

Accordingly, the terminal can access the ESG1 when it is in the area 1 and can change it to ESG2 when it moves to the area 2. [

For example, geographic information about ESG can be as shown in Table 24 below.

<element name = "GeographicInformation" type = "GeographicInformationType"/>

<complexType name = "" IPDCRelatedInformationType ">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "NetworkID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "CellID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "MCC" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "MNC" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "GPS" type = "anyURI" minOccurs = "0" maxOccurs = "unbounded"
</ sequence>
</ complexType>
</ element>

Some ESGs can be delivered over any specific network.

28 shows an example of a specific ESG for a specific network.

Referring to FIG. 28, the access network information for the ESG helps the terminal to select an appropriate ESG. Similar to the IPDC operator information, it is also possible to dictate the access network information for the ESG in advance by defining a new element or descriptor. 28, ESG1 (ESGUIR = 1) is provided only for Network1 and ESG2 (ESGURI = 2) is provided only for Network2. That is, geographical information such as Network1 and Network2 is required to select each ESG Information. The new element and the descriptor may be indicated as IPDC operator information in the ESG bootstrap as in the first embodiment and may be indicated as IPDC operator information in the PSI / SI as in the second and third embodiments May be indicated.

On the other hand, relevant local information of ESG can also be indicated through ProviderURI or ESGURI. The local information can be defined in the format of networkID and cellID in the URI. For example, it can be expressed as ' http://www.dvb.org/cbms/kbs/network1/cell1/esg '. In the above example, the UE recognizes the network and the cell where the corresponding ESG is used based on the information of the ProviderURI. In this case, the terminal has an effect of knowing the local information directly related to the ESG through the URI.

The local information (NetworkID, cellID) can be specified inside the URI (ProviderURI, ESGURI), which can be in front of the URI (prefix), end (suffix), or any other location.

First, in the case of ProvierURI, ESG is identified as ProviderURI, as described in ETSI TS 102471 v.1.2.1. To indicate which ESG is for which cell, the ProviderURI is defined as:

cellIDFFFF / ESGProviderIdentifier

Where cellIDFFFF / is prefixed to the front of the URI, FFFF is the cell ID in hexadecimal format, and ESGProviderIdentifier is the identifier of the ESG Provider. For example, cellID0000 / mycompany1.example.com, cellID0001 / mycompany1.example.com, and cellID0002 / mycompany1.example.com represent ESGs of cell0, cell1, and cell2, respectively, which are ESGs separated by mycompany1.example.com Provided by the Provider.

If the same ESG and service are sent to different cells, each cellID can be listed one by one at the forefront of the URI. For example, cellID0001 / cellID0002 / mycompany1.example.com means that the same ESG is provided for cell 1 and cell 2.

In a similar manner, if a networkID is passed, the ProviderURI is defined as follows;

networkIDFFFF / cellIDFFFF / ESGProviderIdentifier

Where "networkFFFF /" exists at the forefront of the URI, where FFFF represents the network ID in hexadecimal form.

In the same way, local information can be specified even for ESGURI.

If the ESG Provider does not know the cell ID to which each ESG is to be transmitted, other types of local information may be used in place of the Cell ID in the prefix, suffix, or other location of the ESG Provider identifier. The local information may be any of satellite, local, city name, area code, GPS, and the like. When the terminal can identify the local information specified in the form of prefix, suffix, etc., the terminal selects the ESG for the specific area based on the local information. If the terminal can not know which ESG is transmitted for the area where the terminal is currently located, the terminal searches for the entry point of each ESG first. Then, after finding the service ID of the IP address of each entry point from the PSI / SI, it is possible to know from the SDT (Service Description Table) which entry point is for which area.

In the first embodiment, when the terminal analyzes the ESG bootstrap, it is determined that the access network information for each ESG, for example, ESG1 is for Network 1 and ESG2 is for Network 2, or that ESG1 in the DVB- And that ESG2 is for a terrestrial network, because the relevant information is added to the ESG bootstrap.

In the second and third embodiments, when the terminal analyzes the ESG PSI / SI, the access network information for each ESG, for example, ESG1 is for Network 1 and ESG2 is for Network 2, or ESG1 Is for this satellite network and ESG2 is for the terrestrial network, because the relevant information is added to the PSI / SI.

Therefore, the terminal can access the ESG1 when it is on the network 1, and can switch to the ESG2 when it moves to the network 2. [

Relevant information, particularly some mobility-related information, is summarized in Table 26 below. If desired, some of this information may be selected and used in the embodiments described above for mobility support. Any information that can aid the terminal in finding an appropriate ESG in an easy manner can be employed using the embodiments described above.

When the IPDC operator information is included in the bootstrap to easily find the ESG in the present invention, the above-described mechanisms may also simultaneously indicate their related information at the same time. The detailed location may be variable, such as ESG bootstrap, PSI / SI, etc., as in the first, second, and third embodiments.

1.ESG source identifier

First, an ESG source from which the terminal can know who is generating and possessing the corresponding ESG should be indicated. The origin identifier of such an ESG may be all or part of the following parameters: IP platform ID, provider URI, ESGURI, IPDCKMSID, IPDCOperatorID, provider ID, network ID, service provider URI, service provider ID, Any other parameters that can be used.

2.ESG access range type

Since the introduction of ESG-enabled roaming, there have been three types of ESG: local ESG, roaming user dedicated ESG, local and roaming combined ESG.

The local ESG means that the ESG carries only information about the service for the local user. An ESG dedicated to roaming users means that the ESG carries only information about services specifically targeted to roaming users.

The combination of local and roaming ESG means that a part of the service information of the ESG is targeted to a local user and another part is targeted to a roaming user.

3.ESG user object

An object of an ESG is any means that the ESG can do for all users, whether the user is a local user or a roaming user.

The ESG may be for only a specific roaming user. For example, the ESG is intended for roaming users from any particular IP operator. In that case, the detail identifier of the user object should be clearly indicated. If the ESG is to be available to a plurality of specific roaming user groups, the identifiers of each particular roaming user group must be specified in a list. The parameters that can identify the user object may be all or part of the following parameters: IPDCKMSID, IPDCOperatorID, IP platform ID, provider URI, provider ID, network ID, service provider URI, service provider ID, SM ID, Any other parameters that can identify the object.

4. ESG's Service Scope

Patent P2007-0048703 discloses that there can be three types of services for roaming users: local service, visited service, and service roaming service. The detailed information can be referred to the patent.

Therefore, what kind of roaming service information can be used in the ESG is the service range of the ESG. If there is information about the availability of the local service, an identifier of the operator of the local service is provided.

If there is information about availability of the visiting service, an identifier of the operator of the visiting service is provided.

If there is information about the availability of the service roaming service, an identifier of the operator of the service roaming service is provided. In each case, there may be more than one operator. Each operator's identifier must be specified in a list. All or some of the parameters of Table 1 may be used. If there is any new roaming service type, it can also be added here.

The above information is some useful information for easy ESG discovery methods. Indeed, the provider may use any of them, select some of them, or modify them to add some new indication information. Its main purpose is to provide instructional information about allowing the terminal to find the appropriate ESG more simply and easily. The format is as shown in Table 1426 above. In addition, the format of Table 26 may be modified, deleted or added if any matter is changed.

The syntax of the ESG attribute may be as shown in Table 27 below.

<element name = "ESGAttribute" type = "ESGAttributeType" maxOccurs = "unbounded"/>

<complexType name = "ESGAttributeType"/>
<sequence>
<element name = "ESGOriginIdentifier" type = "ESGOriginIdentifierType"/>
<element name = "ESGAccessScope" type = "ESGAccessScopeType"/>
<element name = "ESGUserObject" type = "ESGUserObjectType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ESGAccessScope" type = "ESGAccessScopeType"/> minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ServiceScope" type = "ServiceScopeType"/> minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "GographicInformation" type = "GeographicInformationType"/>
<element name = "AccessNetwork" type = "anyURI"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positiveInteger"/>
<element name = "SMID" type = "positiveInteger"/>
</ sequence>
</ complexType>

The syntax of the ESG source identifier is shown in Table 28 below.

<complexType name = "ESGOriginIdentifierType">
<sequence>
<element name = "IPPlatformID" type = "positiveInteger"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderID" type = "positiveInteger"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCType"/>
<element name = "NetworkID" type = "positiveInteger"/>
<element name = "CellID" type = "positive Integer"/>
<element name = "GographicInformation" type = "GeographicInformation Type"/>
<element name = "AccessNetwork" type = "anyURI"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positiveInteger"/>
<element name = "SMID" type = "positive Integer"/>
</ sequence>
</ complexType>

<complexTypename = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperator" type = "string"/>
</ sequence>
</ complexType>

Or Table 29 below.

<element name = "ESGAttribute" type = "ESGAttributeType"

<complexType name = "ESGAttributeType"/>
<sequence>
<element name = "ESGOriginIdentifier" type = "ESGOriginIdentifierType"/>
<element name = "ESGAccessScope" type = "ESGAccessScopeType"/>
<element name = "ESGUserObject" type = "ESGUserObjectType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ESGAccessScope" type = "ESGAccessScopeType"/> minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ServiceScope" type = "ServiceScopeType"/> minOccurs = "0" maxOccurs = "unbounded"/>

<element name = "GographicInformation" type = "GeographicInformationType"/>
<element name = "AccessNetwork" type = "anyURI"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positiveInteger"/>
<element name = "SMID" type = "positiveInteger"/>
</ sequence>
</ complexType>

The syntax of the ESG source identifier is shown in Table 30 below.

<complexType name = "ESGOriginIdentifierType">
<sequence>
<element name = "IPPlatformID" type = "positiveInteger"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderID" type = "positiveInteger"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "NetworkID" type = "positiveInteger"/>
<element name = "CellID" type = "positiveInteger"/>
<element name = "GographicInformation" type = "GeographicInformationType"/>
<element name = "AccessNetwork" type = "anyURI"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positiveInteger"/>
<element name = "SMID" type = "positiveInteger"/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>

Or Table 31 below.

<element name = "ESGAttribute" type = "ESGAttributeType"

<complexType name = "ESGAttributeType"/>
<sequence>
<element name = "ESGOriginIdentifier" type = "ESGOriginIdentifierType"/> minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ESGAccessScope" type = "ESGAccessScopeType"/>
<element name = "ESGUserObject" type = "ESGUserObjectType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ESGAccessScope" type = "ESGAccessScopeType"/> minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "ServiceScope" type = "ServiceScopeType"/> minOccurs = "0" maxOccurs = "unbounded"/>

<element name = "GographicInformation" type = "GeographicInformationTypeI"/>
<element name = "AccessNetwork" type = "anyURI"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positiveInteger"/>
<element name = "SMID" type = "positiveInteger"/>
</ sequence>
</ complexType>

The syntax of the ESG source identifier is shown in Table 32 below.

<complexType name = "ESGOriginIdentifierType">
<sequence>
<element name = "IPPlatformID" type = "positiveInteger"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderID" type = "positiveInteger"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCType" minOccurs = "0"/>
<element name = "NetworkID" type = "positiveInteger"/>
<element name = "CellID" type = "positiveInteger"/>
<element name = "GographicInformation" type = "GeographicInformation Type"/>
<element name = "AccessNetwork" type = "anyURI"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positiveInteger"/>
<element name = "SMID" type = "positiveInteger"/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>

The ESG access range type can be classified as shown in Table 33 below.

<ClassificationScheme uri = "urn: dvb: ipdc: esg: cs: ESGAccessScopeTypeCS:
<Term termID = "1.0" Name xml: lang = "en"> ESG access scope type </ Name>
<Definition xml: lang = "en"> Type of ESG access scope, eg local ESG, ESG only for roaming user, local and roaming combined ESG </ Definition>
<Term termID = "1.1>
<Name xml: lang = "en"> local ESG </ Name>
<Definition xml: lang = "en"> A local ESG </ Definition>
<Term termID = "1.2>
<Name xml: lang = "en" ESG only for roaming user </ Name>
<Definition xml: lang = "en" A ESG only for roaming user </ Definition>
<Term termID = "1.3>
<Name xml: lang = "en"> local and roaming combined ESG </ Name>
<Definition xml: lang = "en"> local and roaming combined ESG </ Definition>
</ Term>
</ Term>
</ ClassificationScheme>

Or Table 34 below.

<simpleType name = "ESGAccessScopeType">
<restriction base = "string">
<enumeration value = "local ESG"/>
<enumeration value = "ESG only for roaming user"/>
<enumeration value = "local and roaming combined ESG"/>
</ restriction>
</ simpleType>

The ESG user object is intended for all users or specific users.

If it is true, it means that the ESG is intended for all users, otherwise it means that the ESG is for a specific user only. The identifier of a particular user object must be specified as a list.

<complexType name = "ESGUserObjectType">
<sequence>
<element name = "IPPlatformID" type = "positive Integer"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderID" type = "positive Integer"/>
<element name = "Specific IPDC" type = "IPDCType"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "NetworkID" type = "positive Integer"/>
<element name = "CellID" type = "positive Integer"/>
<element name = "GographicInformation" type = "GographicInformation Type"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positive Integer"/>
<element name = "SMID" type = "positive Integer"/>
</ sequence>
<atteribute name = "AllPrSpecific" type = "Boolean"/>
</ complexType>

<compexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
<complexType>

The range of services in the ESG is shown in Table 36 below.

<element name = "ServiceScope" type = "ServiceScopeType"/>

<complexType name = "ServiceScopeType">
<sequence>
<element name = "LocalService" type = "anyURI" minOccurs = "0"/>
<element name = "VisitedService" type = "anyURI" minOccurs = "0"/>
<element name = "ServiceRoamingService" type = "anyURI" minOccurs = "0"/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPPlatformID" type = "positiveInteger"/>
element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderID" type = "positiveInteger"/>
<element name = "IPDC" type = "IPDCType"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "NetworkID" type = "positiveInteger"/>
<element name = "CellID" type = "positiveInteger"/>
<element name = "GographicInformation" type = "GographicInformation Type"/>
<element name = "ServiceProviderURI" type = "anyURI"/>
<element name = "ServiceProviderID" type = "positiveInteger"/>
<element name = "SMID" type = "positiveInteger"/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>

Or Table 37 below.

In the mobility scenario, rights management is the main parameter in the roaming concept. In the case of handover, it is within a single rights management area. In the case of roaming, it is in the scope of different rights management because of the problem of subscription and roaming agreements.

In the CBMS, it is judged that the IPDC operator (more specifically, the IPDC KMS system and the IPDC operator) plays a role of authority management. The identifiers are IPDCKMSID and IPDCOperatorID. In the future, roles responsible for subscription and rights management may change. However, it can still be applied to replace the IPDC KSM system and the IPDC operator with new parameters with some modifications of the ideas and embodiments of the present invention. In this specification, IPDC KSM system and IPDC operator manage authority.

A typical example is as shown in Fig. 29 below. 29, there is a local user, that is, terminal 1 2920 in area 1 2910. The local terminal 2920 is subscribed to an IPDC operator with an identifier of IPDCKSMID = 1 and IPDCOPeratorID = 1. Therefore, when the terminal 2920 accesses ESGURI = 1 (2930), it can find the IPD operator (IPDCIPDC KSM system = 1 and IPDC operator = 1) to which it is subscribed. Thus, the identifiers are the ESG source identifiers.

The IPDC KSM system and the IPDC operator (IPDCKSMID = 1, IPDCOperatorID = 1) 2940 may establish roaming agreements with other KSM TM systems and IPDC operators.

30 is an example of roaming. Here, IPDCKSMID = 1 and IPDCOperatorID = 1 (3010) are responsible for local authority management. Referring to FIG. 30, IPDCKSMID = 1 and IPDCOperatorID = 1 establish a roaming agreement with IPDCKSMID = 2 and IPDCOperatorID = 2 (3020). The subscribed terminal 3025 from IPDCKSMID = 2 and IPDCOperatorID = 2 can also access the service from IPDCKSMID = 1 and IPDCOperatorID = 1 (3010) due to the roaming agreement between them.

Therefore, the user object of ESGURI = 1 (3000) is not only for the subscribed user from IPDCKSMID = 1, IPDCOperatorID = 1 3010, but also for the subscribed user from IPDCKSMID = 2 and IPDCOperatorID = 2 Do.

Referring to FIG. 30, there is another IPDCKSMID = 3 and IPDCOperatorID = 3 (3030). Since the IPDCKSMID = 3 and IPDCOperatorID = 3 3030 do not have a roaming agreement with IPDCKSMID = 1 and IPDCOperatorID = 1 3010, the subscriber terminal 3035 subscribed from IPDCKSMID = 3 and IPDCOperatorID = 1, IPDCOperatorID = 1 (3010).

On the other hand, in order to support roaming, information about the roaming partner can be indicated in advance.

As described above, information about the roaming partner may be signaled by extending the PSI / SI, the ESG bootstrap (ESGProviderDiscoveryDescriptor, ESGA accessDescriptor, or newly defined descriptor), the ESG announcement carousel, . It is an example of an ESG user object. The local (or so-called original) IPDCKSMID and IPDCOperatorID in the ESG are indicated one by one. For each local (or so-called original) IPDCOperatorID, the roaming partners are listed one by one, an example of which is shown in Table 38 below.

Local IPDC KSM system and IPDC operator (original) Roaming partner (s) (user object) local
IPDCKSMID local
IPDCOperatorID roaming
IPDCKSMID roaming
IPDCOperatorID

One ESG may have more than one local IPDCKSMID and IPDCOperatorID. Each of them can have their own roaming partners. In that case, each of the local IPDCKSMID and IPDCOperatorID 3110 and its roaming partners (roaming IPDCKSMID and IPDCOperatorID) 3120 may be indicated one by one, as shown in Figure 31. This is because the PSI in the ESG bootstrap of the above embodiments / SI.

However, two IPDC operators currently belonging to the same IPDC KMS system can conclude a roaming agreement. Two IPDC operators from two different IPDC KMSs can not enter into roaming agreements. For example, IPDCKMSID = 1 and IPDCOperatorID = 1 may establish a roaming agreement with IPDCKMSID = 1 and IPDCOperatorID = 2. However, IPDCKMSID = 1 and IPDCOperatorID = 1 can not establish a roaming agreement with IPDCKMSID = 2 and IPDCOperatorID = 3. For simplicity and further expansion, i, j, k, m, n are used herein as symbols for IPDCKMSID and IPDCOperatorID. Detailed values and limitations may be signaled as required in practice.

Detailed information about all of the IPDC operators and their roaming partners can be indicated as shown in Table 39 below.

<element name = "RoamingInformation" type = "IPDCRelatedInformationType"/>

<complexType name = "IPDCRelatedInformationType">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCInfoType" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

<complexType name = "IPDCInfoType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "RoamingPartner" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>
</ element>
</ sequence>
</ complexType>
</ element>

Or the local IPDC operator and all roaming IPDC operators and may not indicate the relationship between each local IPDC operator and its roaming partner IPDC operator. An example of the syntax is shown in Table 40 below.

<element name = "RoamingInformation" type = "" IPDCRelatedInformationType "/>

<complexType name = "IPDCRelatedInformationType">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "RoamingPartner" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>
</ element>

Or Table 41 below. &Lt; tb > &lt; TABLE &gt;

<element name = "RoamingInformation" type = "" IPDCRelatedInformationType "/>

<complexType name = "" IPDCRelatedInformationType ">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "LocalIPDC" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "RoamingPartner" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>

</ element>

Or may be as shown in Table 42 below.

<element name = "RoamingInformation" type = "" IPDCRelatedInformationType "/>

<complexType name = "" IPDCRelatedInformationType ">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCOperatorInfoType" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

<complexType name = "IPDCOperaotorInfoType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
<attribute name = "LocalOrRoamingFlag" type = "Boolean"/>
</ complexType>

</ element>

If each local IPDC operator has multiple roaming IPDC operators, enumerating all roaming IPDC operator information one by one is a great burden. For that reason, you can list some roaming IPDC operators that are the most frequent and list them there.

Roaming partners 3120 are updated every moment. Newly joining roaming IPDC operator information can not be added to the ESG bootstrap, PSI / SI, or other location in advance for the ESG. In this case, if the terminal can not find the IPDC operator to which it is subscribed from the roaming IPDC operator list, the terminal may still attempt to access the ESG if it locally seeks the same IPDCKSMID. It is because, if the roaming agreement has already been concluded between them, the terminal still has a chance to access the service from the IPDC operator.

If the above information is added to the ESG bootstrap, the terminal operation may be as shown in FIG. The operation of the server may be as shown in FIG.

Referring to FIG. 32, the operation of the terminal according to the IPDCRelatedInformation will now be described.

Referring to FIG. 32, the terminal acquires the PSI / SI in step 3205, and selects an available IP platform for the ESG bootstrap in step 3210. In step 3215, the terminal analyzes IPDCRRelatedInformation.

If the IPDCKSMID and IPDCOperatorID of the terminal can be found in the local IPDCKSMID and IPDCOperatorID in step 3220, the terminal can access the associated ESG. In step 3225, the terminal selects an ESG having the IPDCKSMID and IPDCOperatorID. In step 3230, the terminal accesses the ESG. In step 3235, the terminal accesses the service or purchases the service.

If the IPDCKSMID and IPDCOperatorID of the terminal can be found in the roaming IPDCKSMID and IPDCOperatorID in step 3240, the terminal can access the ESG of the roaming partner. In step 3245, the terminal selects an ESG having IPDCKSMID and IPDCOperatorID of the roaming partner. In step 3250, the terminal accesses the ESG. In step 3255, the terminal accesses the service or purchases the service.

In step 3260, the terminal can find the IPDCKSMID in the local IPDCKSMID. If the IPDCKSMID can not be found in the local or roaming IPDC operator, the terminal selects the ESG having the IPDCKSMID for the attempt but having a different IPDCOperatorID in step 3265. In step 3270, the terminal accesses the ESG.

In step 3275, the terminal attempts to access the service or purchase the service. If the roaming contract is concluded, the terminal succeeds. If the roaming contract is not concluded, the terminal can not obtain the authority to access the service.

Next, the operation of the server according to IPDCRelatedInformation will be described with reference to FIG.

Referring to FIG. 33, in step 3305, the server lists the local IPDCKSMID and the IPDCOperatorID. In step 3310, the server selects a roaming partner for each local IPDC operator and lists it as roaming IPDCKSMID and IPDCOperatorID. In step 3315, the server writes local and roaming IPDC operator information to IPDCRelatedInforamtion.

To reduce the size of the proposed signaling, IPDCKMSID and IPDCOperatorID can be listed and assigned a number for each of them.

When listing local IPDC KMS and IPDC operators and describing roaming partners for each of them, the assigned number for each can be used instead of the correct IPDCKMSID and IPDCOperatorID. A roaming relationship as described above in the index list may be assigned to the ESG, and an example of the syntax may be as shown in Table 43 below.

<element name = "RoamingInformation" type = "IPDCRelatedInformationType"/>

<complexType name = "" IPDCRelatedInformationType ">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCInfoType" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

<complexType name = "IPDCInfoType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "RoamingPartner" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
</ sequence>
</ complexType>
</ element>
</ sequence>
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteg
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>

</ element>

If, however, the IPDC operator and all roaming IPDC operators are instructed and the relationship between each local IPDC operator and its partner roaming IPDC operator is not indicated, then the syntax may be as shown in Table 44 below.

<element name = "RoamingInformation" type = "" IPDCRelatedInformationType "/>

<complexType name = "" IPDCRelatedInformationType ">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "RoamingPartner" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded">
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
</ sequence>
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteger">
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>

</ element>

Or Table 45 below.

<element name = "RoamingInformation" type = "" IPDCRelatedInformationType "/>

<complexType name = "" IPDCRelatedInformationType ">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "LocalIPDC" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "RoamingPartner" type = "IPDCType" minOccurs = "0" maxOccurs = "unbounded">
</ sequence>
</ complexType>

<complexType name = "IPDCType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
</ sequence>
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteger">
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>

</ element>

Or may be the same as in <Table 46a>.

<element name = "RoamingInformation" type = "" IPDCRelatedInformationType "/>

<complexType name = "" IPDCRelatedInformationType ">
<sequence>
<element name = "ESGURI" type = "anyURI"/>
<element name = "IPDC" type = "IPDCOperatorInfoType" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

<complexType name = "IPDCOperaotorInfoType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
</ sequence>
<attribute name = "LocalOrRoamingFlag" type = "Boolean"
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteger">
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>
</ element>

Table 46a can be expressed in binary as shown in Table 46b below.

Equations (47) and (48) below can also be expressed in the same manner as described above.

One roaming terminal may find a plurality of local IPDC operators that have roaming agreements with the home IPDC operator of the roaming terminal. 34 is an example thereof.

First, the home operator of the roaming terminal is listed. Second, a local IPDC operator who has entered into a roaming agreement with the home operator of the roaming terminal is listed. Thirdly. Each associated ESG is listed.

34, IPDCKMSID and IPDCOperatorID of the home operator 3410 of the roaming terminal are described. That is, IPDCKMSIP = 1 and IPDCOperatorID = 1 in the first groove, and IPDCKMSID = m and IPDCOperatorID = m in the mth groove.

The respective homes are connected to a local IPDCKMSID and an IPDCOperatorID that have entered a roaming agreement with an operator of the roaming terminal.

In FIG. 34, the home operator of the roaming terminal and the local operator having entered a roaming agreement therewith may be as shown in Table 47 below.

<element name = "RoamingTerminalInformation" type = "RoamingTerminalRelatedInformationType"/>

<complexType name = "RoamingTerminalRelatedInformationType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "RoamingContract" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "ESGURI" type = "anyURI"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>
</ element>

However, if an index is used, the syntax can be as in Table 47 below.

<element name = "RoamingTerminalInformation" type = "RoamingTerminalRelatedInformationType"/>

<complexType name = "RoamingTerminalRelatedInformationType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "RoamingContract" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "ESGURI" type = "anyURI"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteger">
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>

</ element>

On the other hand, the roaming-related information may be placed in the PSI / SI.

If there is more than one IPDC operator in an IP platform, the ESG bootstrap is isolated for each IPDC operator on that IP platform.

IP / MAC_notification_section {
Platform_id
target_descriptor_loop ()
target_ip_slash_descriptor () => Fixed IP address for ESG bootstrap
IPDCOperator_descriptor () => list all IPDC operator in this IP platform
operational_descriptor_loop ()
}

The new descriptor adds an IPDC operator descriptor as shown in Table 50 below to indicate which IPDC operator the ESG bootstrap is for.

Syntax IPDCOperator descriptor {   LocalIPDCOperator descriptor {   IPDCKMSId   IPDCOperatorId   RoamingParter descriptor {     IPDCKMSId     IPDCOperatorId   } }   Reserved for other identifier }

If there is more than one IPDC operator in a single IP platform, the ESG bootstrap is isolated for each IPDC operator on that IP platform.

IP / MAC_notification_section {
Platform_id
target_descriptor_loop ()
target_ip_slash_descriptor () => Fixed IP address for ESG bootstrap
IPDCOperator_descriptor () for this IPDC operator in this IP platform
operational_descriptor_loop ()
}

The new descriptor The IPDC operator descriptor, shown below in Table 52, is added to indicate which ESG bootstrap is for which IPDC operator.

Syntax IPDCOperator descriptor {   LocalIPDCOperator descriptor {   IPDCKMSId   IPDCOperatorId RoamingParter descriptor {     IPDCKMSId     IPDCOperatorId   } }   Reserved for other identifier }

For each home (local) terminal, information about that roaming partner in the foreign network may be provided in advance. In this case, the terminal already has a lot of roaming information in its home network and can use the information when it actually moves to a foreign zone as shown in FIG.

Referring to FIG. 35, local terminals are shown in which IPDCKMSID and IPDCOperatorID are indicated. And roaming partners in a foreign network connected to each local terminal are shown.

The syntax of the roaming partner in the local IPDC operator and the foreign network in FIG. 35 may be as shown in Table 53 below.

<element name = "LocalTerminalRoamingOutsideInformation" type = "LocalTerminalRoamingOutsideRelatedInformationType"/>

<complexType name = "LocalTerminalRoamingOutsideRelatedInformationType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "RoamingPartnerOutside" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>
</ element>

If an index is used, the syntax may be as in Table 54 below.

<element name = "LocalTerminalRoamingOutsideInformation" type = "LocalTerminalRoamingOutsideRelatedInformationType"/>

<complexType name = "LocalTerminalRoamingOutsideRelatedInformationType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "RoamingPartnerOutside" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteger">
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>

</ element>

If the ESGURI in the foreign network can be known in advance, it may be indicated to the terminal. The syntax may be as shown in Table 55 below.

<element name = "LocalTerminalRoamingOutsideInformation" type = "LocalTerminalRoamingOutsideRelatedInformationType"/>

<complexType name = "LocalTerminalRoamingOutsideRelatedInformationType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "RoamingPartnerOutside" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "ESGURI" type = "anyURI"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>
</ element>

If an index is used, the syntax can be as follows.

<element name = "LocalTerminalRoamingOutsideInformation" type = "LocalTerminalRoamingOutsideRelatedInformationType"/>

<complexType name = "LocalTerminalRoamingOutsideRelatedInformationType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "RoamingPartnerOutside" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "IPPlatformID" type = "positiveInteger"/>
<element name = "NetworkID" type = "positiveInteger"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteger">
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>

</ element>

Other information besides ESGURI, such as an IP platform, may be indicated in advance. As such, it is determined by the application which information is to be indicated in advance. In addition, the information may be dictated in a manner similar to ESGURI.

If information about the IP platform, the ESG provider, the ESG, and the access network is indicated, the syntax may be as shown in Table 57 below.

<element name = "LocalTerminalRoamingOutsideInformation" type = "LocalTerminalRoamingOutsideRelatedInformationType"/>

<complexType name = "LocalTerminalRoamingOutsideRelatedInformationType">
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "RoamingPartnerOutside" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "IPPlatformID" type = "positiveInteger"/>
<element name = "NetworkID" type = "positiveInteger"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>
</ element>

If an index is used, the syntax may be as shown in Table 58 below.

<element name = "LocalTerminalRoamingOutsideInformation" type = "LocalTerminalRoamingOutsideRelatedInformationType"/>

<complexType name = "LocalTerminalRoamingOutsideRelatedInformationType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "RoamingPartnerOutside" minOccurs = "0" maxOccurs = "unbounded">
<complexType>
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<element name = "IDOfIPDCOperator" type = "positiveInteger"/>
<element name = "ESGURI" type = "anyURI"/>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "IPPlatformID" type = "positiveInteger"/>
<element name = "NetworkID" type = "positiveInteger"/>
</ sequence>
</ complexType>
</ sequence>
</ complexType>

<complexType name = "IPDCIDType">
<sequence>
<element name = "IDOfKMS" type = "positiveInteger"/>
<complexType>
<attribute name = "IPDCKMSId" type = "unsignedShort"/>
</ complexType>
</ element>
<element name = "IDOfIPDCOperator" type = "positiveInteger">
<complexType>
<attribute name = "IPDCOperatorId" type = "string"/>
</ complexType>
</ element>
</ sequence>
</ complexType>

</ element>

Based on the provided information, the terminal can select an appropriate IP platform among all the available IP platforms for bootstrapping, and select an appropriate ESG provider and ESG among a plurality of ESG providers and ESGs. The terminal may then select a service for access.

Next, a terminal / network for implementing the ESG discovery method according to the present invention will be described.

Fig. 36 shows the structure of the network, and Fig. 37 shows the structure of the terminal. Details are described in Table 59 below.

 Function object name  Explanation Service application
(3601) In order to provide a specific service application,
Collects content from the related metadata,
Provides head-end application logic,
The terminal informs by streaming or passing the file carousel
Which is responsible for the provision of content encoded in a format,
Generate service description metadata to be used in electronic service guide
do.
A conversation endpoint for a terminal that talks to a service application.
Provide service protection.
The service application objects are each provided to the IP datacast
Lt; / RTI &gt; applications.  Service Management (3602) It consists of four sub-entities that can be illustrated separately.
1. Service configuration and resource allocation (3405)
- the bandwidth of the broadcast bearer
Registration (e.g., one DVB-
H IP platform).
- services in terms of location (relative to the broadcast network topology), bandwidth
Width, and time according to schedule service.
One example of this sub-entity is the broadcast bandwidth contention domain
.
2. Service Guide Provisioning Application (3607)
- ESG (metadata information) pieces from service applications
collection.
- There can be multiple instances of this sub-entity.
3. Providing security / service protection (3609)
- Manage user access to service applications.
4. Location service (3611)
- The Service Management Entities are independent of the actual
Service (interactive bearer network function or GPS) service
You can provide location services to applications.  In the terminal 3701, Child objects:
1. DVB-H receiver 3703
Receive service or signaling over the broadcast network
2. Interactive adapter 3705
Transmitting or receiving services or signaling over an interactive network
3. MM (3707)
Mobility process jurisdiction
4. Subscription Management (3709)
Authorization acquisition management, authorization memory acquired for the terminal, and
Controlling the decoding process of service contents
5. Content consumption (3711)
Consuming services

The three embodiments described above describe how to find the appropriate ESG at the PSI / SI or bootstrap level.

If one ESG contains multiple IPDC operators, one subset of ESGs may be possible for one IPDC operator, and another subset of ESGs for another IPDC operator. One subset of ESGs may be possible for a particular region, and another subset of ESGs may be possible for another region. In addition, one subset of ESGs may be charged for a particular network or a particular type of network (e.g. DVB-H, DVB-3, 3GPP, WIMAX, etc.) May be charged. One problem is how the terminal can find the proper part in the ESG. Indicator information similar to that described above (such as Table 26) may also be used here, but only needs to be modified for the ESG subset of Table 26. [

And embodiments similar to those described above, but may be provided in different locations, e. G. In the ESG. The detailed location of the relevant information on the instruction information may vary. Here, two possible positions will be described. One example is to place in an ESG announce carousel, another example is to use an ESG partitioning mechanism.

<Fourth Embodiment>

The fourth embodiment of the present invention uses the ESG partitioning method as a method of recognizing each of the ESGs. In the DVB-CBMS, one ESG can be divided into a plurality of IP flows, and the information about how each IP flow is divided can be defined as shown in Table 61. In the future, if one ESG can be applied to two or more IP platforms, different parts of the ESG can be prepared for different IP platforms present in that ESG. In Table 61, if the value is 0x00 and 0x01 The remaining values are proposed in the present invention. By adding the IPDCKMSId value or the NetworkID value to the start_field_value and end_field_value values indicating the intervals of each partition, it is possible to determine whether the parts of each ESG are composed of only the services corresponding to the NetworkID, Services are configured as services.

value encoding meaning 0x00 0x0101 (unsigned short) The number of fragments are valid. This may be used to split the ESG into various schedule depths. 0x01 0x0000 (string) The URI of the Serivce fragments ServiceID. This may be used to carry all fragments relevants to a particular service. 0x30 0x0101 (unsigned short) /
0x0204 (boolean) Roaming ESG 0x40 0x0101 (unsigned short) IPDCKMSId 0x50 0x0000 (string) IPDCOperatorId 0x60 0x0000 (string) Access network type 0x70 0x0101 (positive Integer) Network ID 0x80 0x0101 (positive Integer) Cell id 0x90 0x0000 (string) GPS 0xA0  0x0101 (positive integer) IP platformID

To assist the terminal in finding the appropriate ESG or ESG part, some embodiments have already been described in terms of how to indicate ESG or sub ESG related information in the PSI / SI, ESG bootstrap, or within the ESG.

In addition, ESG or sub ESG related information such as those in Table 26 and Table 60 may be indicated differently, for example, by notification or by separate signaling.

<Fifth Embodiment>

The fifth embodiment of the present invention is a method of acquiring information proposed by the present invention using an HTTP request query to distinguish ESG. That is, the terminal sends information on its own to the server, inquires about a possible ESG list that can be used by using the information, and the server delivers the ESG list to the terminal using the information. That is, when the terminal transmits the information such as the Network ID, the Cell ID, the IPDC operator identifier, and the like stored in advance in the terminal to the server, the server interprets the information and transmits the ESG list to the terminal.

The terminal may query the ESG based on the IPDC operator, geographic information, access network, or other information described in Table 26 and Table 60.

1. ESG inquiry based on IPDC operator

The terminal desires to inquire an ESG according to a certain IPDC operator, for example, his / her home IPDC operator. The server sends the ESG associated with the specific IPDC operator to the terminal.

      Inquiry message             key             value For any specific IPDC operator
Request ESG via IA channel
For any specific IPDC operator
Request ESG via IA channel  IPDC operator IPDCKSMId
IPDCOperatorId

2. ESG inquiry based on geographical information

The terminal desires to inquire an ESG for a specific area, for example, one roaming network. The server transmits an ESG related to the specific area to the terminal.

      Inquiry message             key             value Request an ESG for any specific geography
For any particular geography
Request ESG  Geographic information Network id
Cell id
GPS
Reserved area for other geographic information

3. ESG inquiry based on access network

The terminal desires to inquire the ESG for a specific network, for example, DVB-H network 1 or 3GPP network 2. [ The server transmits an ESG related to the specific network to the terminal.

      Inquiry message             key             value Any specific access
For the network
Request ESG
Any specific access
For the network
Request ESG  Access network Network id
Network type:
1. DVB-H
2. DVB-S
3. 3GPP
4. Satellite network in DVB-SH
5. Terrestrial network in DVB-SH
A spare area for other access network information

  The inquired information may be combined. For example, the terminal can query the ESG from the IPDC operator 1 in the network 1.

      Inquiry message             key             value Across any particular network
Which in some specific area
For a specific IPDC operator
Request ESG via IA channel


Across any particular network
Which in some specific area
For a specific IPDC operator
Request ESG via IA channel  IPDC operator IPDCKSMId
IPDCOperatorId  Geographic information Network id
Cell id
GPS
Reserved area for other geographic information  Access network Network id
Network type:
1. DVB-H
2. DVB-S
3. 3GPP
4. Satellite network in DVB-SH
5. Terrestrial network in DVB-SH
For other access network information
Spare area

Therefore, it is proposed to add a new key and value to the inquiry message as shown in <Table 66>.

key value meaning  type ESGContainer
DeliveryList Type of expected response. For example, ESG DeliveryList or
Containers are requested.  containerID  16-bit positive integer The FLUTE FDT or DeliveryList signaled bar
ContainerID. Multiple values can be separated by commas.  fragmentID  16-bit positive integer The delivery FragmentID of the signaled to the DeliveryList.
Multiple values can be separated by commas.  IPDCKMSID  Unshown shortened type  Delivery IPDCKMSID of the signaled to the DeliveryList.
 Multiple values can be separated by commas.  IPDCOperatorID  String  Delivery IPDCOPeratorID of the signaled to the DeliveryList.
 Multiple values can be separated by commas.  NetworkID  16-bit positive integer  The NetworkID of the signaled delivery to the DeliveryList.
 Multiple values can be separated by commas.  CellID  16-bit positive integer  The CellID of the signaled delivery to the DeliveryList.
 Multiple values can be separated by commas.  DLVersion LASTUPDATED
datetime value
(NTP timestamp,
unsignedInt)  LASTUPDATED version of DeliveryList  Esguriy ProviderDiscovery
The signaled bar
ESG_URI  Transfer to "interactive" AccessPoint with ESG URI.

<Sixth Embodiment>

The sixth embodiment provides an ESG bootstrap for any particular IPDC operator via an interactive network. The terminal may request ESG bootstrap information for a particular IPDC operator, e.g., the IPDC operator to which it is subscribed. The server can collect the ESG bootstrap information associated only with that particular IPDC operator and send it to the terminal via the interactive network. Therefore, the terminal can easily obtain what it wants without analyzing all the bootstrap information.

If the terminal is to query the ESG bootstrap from one specific IPDC operator on a particular IP platform, the inquiry message may be as shown in Table 67 below.

      Inquiry message             key             value On any specific IP platform
To any specific IPDC operator
ESG bootstrap information for
Request via IA channel

To any specific IPDC operator
ESG bootstrap information for
Request via IA channel  IPDC operator IPDCKSMId
IPDCOperatorId  IP Platform  IP platform ID

If the terminal wants to query the ESG bootstrap from one specific IPDC operator on all IP platforms, the inquiry message may be as shown in Table 68 below.

      Inquiry message             key             value To any specific IPDC operator
ESG bootstrap information for
Request via IA channel
To any specific IPDC operator
ESG bootstrap information for
Request via IA channel  IPDC operator IPDCKSMId
IPDCOperatorId

The present embodiment may be used separately or in combination with an embodiment that indicates IPDC operator information in advance in a broadcast manner.

38 is a flowchart for explaining the operation of the UE according to the sixth embodiment of the present invention.

Referring to FIG. 38, in step 3805, the terminal transmits an ESG bootstrap inquiry message having a specific IPDC operator value. In step 3610, the terminal receives a response from the server. In step 3815, the UE determines whether the requested ESG bootstrap information is available.

If it is determined in step 3815 that the ESG bootstrap information is available, the ESG bootstrap information related to the IPDC operator inquired by the AT is analyzed in step 3820 and the corresponding ESG bootstrap is selected. If a plurality of IP platforms are available in step 3625, the terminal selects one IP platform for bootstrapping. In step 3830, the terminal selects an ESG from the ESGProviderDiscoveryDescriptor and the ESGAccessDescriptor. Then, in step 3835, the terminal accesses the ESG. In step 3840, the terminal accesses or purchases the service.

39 is a diagram for explaining the operation of the server according to the sixth embodiment of the present invention.

Referring to FIG. 39, in step 3905, the server receives an ESG bootstrap inquiry message having a specific IPDC operator value.

In step 3910, the server determines whether ESG bootstrap information is available for the specific IPDC operator requested.

If it is determined as a result of the determination in step 3910, the server collects all the ESG bootstrap information related to the IPDC operator requested in step 3915 and transmits it to the AT. However, if it is determined in step 3910 that it is impossible, the server returns a failure value in step 3920.

In the roaming scenario, even the local IPDC operator information is indicated in the ESG bootstrap, but perhaps roaming partners for each IPDC operator are not indicated or the list of fhakld partners may not be complete. In that case, it is difficult for the roaming terminal to select an appropriate ESG including an accessible service. However, the lookup mechanism here can be helpful.

The server will instruct all the local IPDC operator information, e.g., ESG bootstrap, for each ESG in advance. When the server receives an inquiry message from the terminal with some specific IPDC operator information, the server should check whether it is a roaming partner with a particular IPDC operator. If so, the server collects all ESG bootstrap information associated with the local IPDC operator and sends it to the terminal. Otherwise, it responds with failure information.

40 is a flowchart for explaining a server operation according to a combined sixth embodiment of the present invention.

Referring to FIG. 40, in step 4005, the server instructs the ESG bootstrap (or PSI / SI or another location) in advance of the local IPDCKSMID and IPDCOperatorID for each ESG. In step 4010, the server receives the ESG bootstrap inquiry message having the IPDCKSMID and the IPDCOperatorID from the terminal. In step 4015, the server checks whether the IPDCKSMID and IPDCOperatorID of the terminal are roaming partners with a local IPDC operator. If the IPDCKSMID and IPDCOperatorID are roaming partners, the server transmits all ESG bootstrap information associated with the local IPDC operator to the terminal, Otherwise, it responds with failure information.

FIG. 41 is a diagram for explaining the operation of the UE according to the combined sixth embodiment of the present invention.

Referring to FIG. 41, the terminal searches, for example, the local IPDC operator information already indicated in the ESG bootstrap. If the terminal can not find the IPDC operator information to which the terminal belongs, the terminal transmits the ESG bootstrap inquiry information having the IPDC operator information to the server. When the server locates its roaming partner at the local IPDC operator, the server sends all relevant ESG bootstrap information to the terminal, which then selects the ESG to access or purchase the service.

Referring to FIG. 41, in step 4105, the terminal acquires PSI / SI. In step 4110, the terminal selects an available IP platform for the ESG bootstrap. In step 4115, the terminal analyzes IPDCRelatedInformation. If the IPDCKSMID and IPDCOperatorID of the terminal can be found in the local IPDCKSMID and IPDCOperatorID in step 4120, the terminal can access the associated ESG. In step 4125, the terminal selects an ESG having the IPDCKSMID and IPDCOperatorID. In step 4130, the terminal accesses the ESG. In step 4135, the terminal accesses the service or purchases the service.

If the terminal can not find the IPDCKSMID in the local IPDCKSMID and the IPDCOperatorID in step 4140, the terminal can access its associated ESG. In step 4145, the terminal queries the ESG bootstrap information having its own IPDCKSMID and IPDCOperatorID. In step 4150, if the IPDC operator roaming partner is one of the local IPDC operators, the terminal can receive the ESG information associated with the local IPDC operator. In step 4155, the terminal accesses the ESG. In step 4160, the terminal accesses or purchases the service.

<Seventh Embodiment>

In the seventh embodiment, ESG sub-set-related information signaling is performed in the ESG announce scalar cell.

Roaming ESG related information as shown in Table 44 may be added to an ESG announcement carousel. Such parameters may be written to an ESG init container and a field called so-called attribute or ESG subset attribute, such as reference numeral "4010 &quot; in FIG. 40, may be assigned to them.

As shown by reference numeral 4240 in Fig. 42, a separate container called an attribute container may be allocated to store the subset ESG related information.

Or may be part of an inner container or any other existing container, and partly in a new container. The parameters may be in different locations in the ESG announcement carousel.

Figure 42 shows an ESG announcement carousel with a new element or container.

42, there may be one or more ESG announcement carousel FLUTE sessions 4210, 4230, wherein each ESG announcement carousel FLUTE session is associated with one ESG subset It is about.

As an example, one ESG announcement carousel FLUTE session is for the ESG subset over the satellite network, and the other ESG announcement carousel FLUTE session is for the ESG subset over the terrestrial network.

As a second example, one ESG announcement carousel FLUTE session is for a subset of ESGs associated with one IPDC operator (IPDCKSMID, IPDCOperatorID), and another ESG announcement carousel FLUTE session is for another IPDC operator IPDCKSMID, &lt; / RTI &gt; IPDCOperatorID).

As a third example, one ESG announcement carousel FLUTE session is for one ESG subset associated with one realm, and the other ESG announcement Carousel FLUTE session is for a subset of ESGs associated with the other realm .

As a fourth example, one ESG announcement carousel FLUTE session is for the ESG subset associated with the local user, and the other ESG announcement carousel FLUTE session is for the ESG subset associated with the roaming user. In the future, if one ESG can be applied to two or more IP platforms, a different ESG announcement carousel FLUTE session may be prepared for different IP platforms present in that ESG.

43, 4210 illustrates an ESG subset for one ESG subset with a particular type of attribute, e.g., a satellite-based ESG subset, an ESG subset associated with one IPDC operator, or an ESG announcer It may be a FLUTE session.

43, 4320 is an ESG subset for other ESG subsets having a particular type of attribute, e.g., an ESG subset over terrestrial, an ESG subset associated with another IPDC operator, or an ESG subset associated with another area Carousel Represents a FLUTE session.

Different ESG announcement carousel FLUTE sessions 4310 and 4330 may be indicated differently. As an example, the original ESG announcement carousel FLUTE session indicates access information regarding another ESG announcement carousel for another ESG subset, as shown in FIG. 44 below.

44, reference numeral 4410 denotes an ESG subset for one ESG subset with a particular type of attribute, e.g., a satellite-based ESG subset, an ESG subset associated with one IPDC operator, or an ESG subset associated with a particular region It can be an ESG announcement carousel FLUTE session.

4420 may include an ESG subset for other ESG subsets having certain types of attributes, e.g., a satellite-based ESG subset, an ESG subset associated with another IPDC operator, or an ESG announcement carousel FLUTE Session.

As another example, as shown in FIG. 45, an ESG access descriptor may indicate a respective IP address and a port number for it, TSI. In the CDP specification (ESTI TS 102 472), a combination of TSI and IP source address identifies a FLUTE session.

45, reference numeral 4510 denotes an ESG subset for one ESG subset with a particular type of attribute, e.g., a satellite-based ESG subset, an ESG subset associated with one IPDC operator, or an ESG subset associated with a particular region It can be an ESG announcement carousel FLUTE session.

4520 may be used for other ESG subsets having certain types of attributes, such as ESG subsets over terrestrial waves, ESG subsets associated with other IPDC operators, or ESG announcement carousel FLUTE Session.

 In the example of FIG. 45, different ESG announcement carousel FLUTE sessions are for different ESG subsets of the same ESG.

On the server side, different ESG announcement carousel FLUTE sessions are prepared for different ESG subsets with different attributes, e.g., for the satellite network and terrestrial network. Each of which has its own identifier.

There may be different ways to convey such an ESG announcement carousel FLUTE session.

First, multiple ESG announcement carousel FLUTE sessions are transmitted in a distributed manner.

A possible approach that can be taken in the first approach is to transmit all ESG announcement carousel FLUTE sessions in a distributed manner. For example, it may be implemented using multiple networks or multiple cells or may be implemented in any other manner. Each ESG announcement carousel FLUTE session is delivered according to its attributes and delivery conditions. For example, an ESG allocation carousel FLUTE session for a satellite network will be delivered when it passes through a satellite, and an ESG reception carousel FLUTE session for a terrestrial network will be delivered if it goes through a terrestrial network. Accordingly, when receiving a signal from a satellite network, the terminal receives the ESG announcement carousel and ESG subset for the satellite, and when receiving a signal from the terrestrial network, the terminal receives an EGS announcement carousel And an ESG subset.

In this scenario, it is not the complete ESG that the terminal receives, but only one subset of ESGs at a time. Which means that the terminal can receive different ESG data with the same ESGURI upon receipt at different times, such as reception from satellite and reception from terrestrial waves.

However, it is unclear how the terminal can know whether or not the ESG received by the terminal is complete and whether or not the terminal should update and receive a new subset of the ESG upon reception change.

Accordingly, it is proposed to add one label indicating whether the ESG announcement carousel FLUTE session for one ESG is transmitted in a distributed manner.

With this label, MultipleESGAnnouncementCarousel is added, which is a new element added to indicate whether multiple ESG announcement carousels are applied for a given ESG.

If the Multiple ESG AnnouncementCarousel is set to "1 ", it means that a plurality of ESG announcement carousels are applied to the ESG, and if the Multiple ESG announcementCarousel is set to" 0 ", only one ESG announcement carousel Cell is applied.

               field                 meaning  MultipleESGAnnouncementCarousel When set to "1 &quot;, a plurality of ESGs
Means that an announcement carousel is applied, and when set to "0", only one
ESG Announcement Carousel is applied.

The position of the label may vary, but some examples are given below, but the position of the label is not limited.

Tables 70 to 73 below show examples in which a new label is added to the ESGAccessDescriptor.

The new element may be signaled as shown in Table 70 below, MultipleESGAnnoucementCarousel is the new element.

Syntax ESGEntry {   ESGEntryVersion   ESGEntryLength   MultipleStreamTransport  MultipleESGAnnoucementCarousel   IPVersion6   Reserved   ProviderID   if (IPVersion 6) { SourceIPAddress DestinationIPAddress   } else { SourceIPAddress DestinationIPAddress   }   Port   TSI }

The second possible location is shown in Table 71 below.

Syntax ESG Access Descriptor {   n_o_ESGEntries   for (i = 0; i <n_o_ESGEntries; i ++) {     ESGEntry [i] () MultipleESGAnnoucementCarousel } }

The third possible location is shown in Table 72 below.

Syntax ESG Access Descriptor { MultipleESGAnnoucementCarousel   n_o_ESGEntries   for (i = 0; i <n_o_ESGEntries; i ++) {     ESGEntry [i] () } }

The new element may be added to the ESGProviderDiscoveryDescriptor as shown in Table 73 below.

<schema targetNamespace = "urn: dvb: ipdc: esgbs: 2005" xmlns = "urn: dvb: ipdc: esgbs: 2005" xmlns: mpeg7 = "urn: mpeg: mpeg7: //www.w3.org/2001/XMLSchema "elementFormDefault =" qualified "attributeFormDefault =" unqualified ">
<import namespace = "urn: mpeg: mpeg7: schema: 2001"/>

<complexType name = "ESGProviderType">
<sequence>
<element name = "ProviderURI" type = "anyURI"/>
<element name = "ProviderName" type = "mpeg7: TextualType"/>
<element name = "ProviderLogo" type = "mpeg7: TitleMediaType" minOccurs = "0"/>
<element name = "ProviderID" type = "positiveInteger"/>
<element name = "ProviderInformationURL" type = "anyURI" minOccurs = "0"/>
<element name = "PrivateAuxiliaryData" type = "anyType" minOccurs = "0"/>
<element name = "IPDCKMSId" type = "unsignedShort"/>
<element name = "IPDCOperatorId" type = "string"/>
</ sequence>
<attribute name = " MultipleESGAnnoucementCarousel " type = "Boolean"
</ complexType>

<element name = "ESGProviderDiscovery">
<complexType>
<sequence>
<element name = "ServiceProvider" type = "bs: ESGProviderType" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>
</ element>


</ schema>

In a second manner, attributes for multiple ESG announcement carousel FLUTE sessions are signaled.

It is also possible for multiple ESG announcement FLUTE sessions to be transmitted simultaneously. In that case, how to select the appropriate FLUTE session is left up to the terminal.

Therefore, it is proposed to signal the attributes for each ESG announcement carousel FLUTE session. For example, for satellite or terrestrial, for Region 1 or Region 2, for IPDC Operator 1 or IPDC Operator 2, for a local user or roaming user. Based on such signaling, the terminal selects an appropriate one for access.

Here, the DVB-Sh system is taken as an example. The network id and cell id can be signaled for each ESG access announcement kernels cell. Satellite and terrestrial cells use different areas of cell id. Accordingly, the UE can know whether it is a satellite cell or a terrestrial cell based on the cell id.

               field                 meaning Network id The target network in which the ESG subset is used
Specify. Cell id And specifies the target cell in which the ESG subset is used.

The location of the new element may vary. The new element "cell id" may be added to the ESGAccessDescriptor in various manners. An example of this is shown in Table 75 below.

Syntax ESGEntry { ESGEntryVersion ESGEntryLength MultipleStreamTransport MultipleESGAnnoucementCarousel IPVersion6 Reserved ProviderID if (IPVersion 6) { SourceIPAddress DestinationIPAddress } else { SourceIPAddress DestinationIPAddress } Port TSI Network id   Cell id }

Or Table 76 below.

Syntax ESG Access Descriptor {   n_o_ESGEntries   for (i = 0; i <n_o_ESGEntries; i ++) {     ESGEntry [i] () MultipleESGAnnoucementCarousel     Network id     Cell id } }

The cell information for each ESG announcement carousel FLUTE session can be signaled in detail as shown in Table 77 below.

               field                 meaning MultipleESGAnnouncementCarousel When set to "1 &quot;, a plurality of ESGs
Means that an announcement carousel is applied,
When set to "0 &quot;, only one ESG for that ESG
Which means that the announcement carousel is applied. MultipleESGAnnouncementCarouselAttributeIndication When set to "1 &quot;, multiple ESG announcements
Means that the attribute related to the carousel is indicated, and "0"
Once set, the number of ESG announcement carousels
The attribute is not indicated. n_o_AnnouncementCarousel ESG Announcement for ESG Carousel of FLUTE session
Specify the number. Network id The target network in which the ESG subset is used
Specify. Cell id And specifies the target cell in which the ESG subset is used.

Syntax ESGEntry {   ESGEntryVersion   ESGEntryLength   MultipleStreamTransport  MultipleESGAnnoucementCarousel MultipleESGAnnoucementCarouselAttributeIndication IPVersion6 Reserved ProviderID If ( MultipleESGAnnoucementCarousel ) { If ( MultipleESGAnnoucementCarouselAttributeIndication ) { For (i = 0; i < n_o_AnnoucmentCarousel i ++) {          if (IPVersion 6) {      SourceIPAddress      DestinationIPAddress          } else {      SourceIPAddress      DestinationIPAddress          }          Port          TSI          Network id          Cell id } else {       For (i = 0; i <n_o_AnnoucmentCarousel; i ++) {          if (IPVersion 6) {            SourceIPAddress            DestinationIPAddress          } else {            SourceIPAddress            DestinationIPAddress          }          Port          TSI      }   } else {        if (IPVersion 6) {          SourceIPAddress          DestinationIPAddress        } else {          SourceIPAddress          DestinationIPAddress          }          Port          TSI   } }

An example of the SH system has been described above. A number of ESG announcement carousel FLUTE sessions used for different purposes, e.g., for different IPDC operators, different regions, local users or roaming users, may be similarly applied.

An example of two cases is shown in Table 79 and Table 80 below.

           field     value              meaning MultipleESGAnnouncementCarouselAttributeIndication 0x01 For different cells, for example DVB-SH
For satellite and terrestrial cells in
Specifies a different ESG announcement carousel. 0x02 ESG announcements for different IPDC operators
Specifies the carousel. 0x03-0xFF Reserved area for future use

Syntax ESGEntry {   ESGEntryVersion   ESGEntryLength   MultipleStreamTransport  MultipleESGAnnoucementCarousel MultipleESGAnnoucementCarouselAttributeIndication IPVersion6 Reserved ProviderID If ( MultipleESGAnnoucementCarousel ) { If ( MultipleESGAnnoucementCarouselAttributeIndication == 0x1 ) { For (i = 0; i < n_o_AnnoucmentCarousel i ++) {          if (IPVersion 6) {      SourceIPAddress      DestinationIPAddress          } else {      SourceIPAddress      DestinationIPAddress          }          Port          TSI          Network id          Cell id       } else { If ( MultipleESGAnnoucementCarouselAttributeIndication == 0x2 ) { For (i = 0; i < n_o_AnnoucmentCarousel i ++) {              if (IPVersion 6) {                SourceIPAddress                DestinationIPAddress              } else {                SourceIPAddress                DestinationIPAddress              }              Port              TSI              IPDCKMSID              IPDCOperatorID          } else {            For (i = 0; i <n_o_AnnoucmentCarousel; i ++) {              if (IPVersion 6) {                SourceIPAddress                DestinationIPAddress              } else {                SourceIPAddress                DestinationIPAddress              }              Port              TSI         }      }   } else {        if (IPVersion 6) {          SourceIPAddress          DestinationIPAddress        } else {          SourceIPAddress          DestinationIPAddress          }          Port          TSI   } }

ESGProviderDiscoveryDescriptor and ESGAccessDescriptor are extended to cover ESGoIA. Based on such a new version, new elements may be modified.

Table 82 below shows an extension of ESGProviderDiscoveryDescriptor.

<schema xmlns: dl = "urn: dvb: ipdc: esg: 2008" xmlns = "http://www.w3.org/2001/XMLSchema"
targetNamespace = "urn: dvb: ipdc: esgbs: 2008" elementFormDefault = "qualified" attributeFormDefault = "unqualified">
<import namespace = "urn: dvb: ipdc: esgbs: 2005"/>

<complexType name = "ESGType">
<complexContent>
<sequence>
<element name = "ESG_URI" type = "anyURI"/>
<element name = "TargetAudienceType" type = "tva: ControlledTermType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "AccessPoint" type = "bs2: accessPointType" maxOccurs = "unbounded"/>
</ sequence>
<attribute name = "broadcastAccess" type = "bs2: AccessType" use = "optional" default = "required"
<attribute name = "interactiveAccess" type = "bs2: AccessType" use = "optional" default = "not required"/>
<attribute name = "ESG_ID" type = "unsignedInt"/>
<attribute name = "MultipleESGAnnoucementCarousel" type = "boolean" use = "optiona"/>
<attribute name = "n_o_AnnoucmentCarousel" type = "unsignedInt" use = "optiona"/>
</ extension>
</ complexContent>
</ complexType>

<complexType name = "ESGProviderExtensionType">
<complexContent>
<extension base = "bs: ESGProviderType"><sequence><element name = "ESG" type = "bs2: ESGType" maxOccurs = "unbounded"
</ extension>
</ complexContent>
</ complexType>

<simpleType name = "AccessType">
<restriction base = "string">
<enumeration value = "required">
<enumeration value = "not required">
</ restriction>
</ simpleType>


<complexType name = "accessPointType">
<attribute name = "accessPointID" type = "unsignedInt"/>
<sequence>
<element name = "MultipleESGAnnoucementCarouselAttribute" type = "tva: ControlledTermType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "NetworkID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "CellID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "IPDCKMSId" type = "unsignedShort" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "IPDCOperatorId" type = "string" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "IPPlatformID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

</ schema>

The meaning of the ESGProviderDiscoveryDescriptor is shown in Table 83 below.

The MultipleESGAnnouncementCarouselAttribute classification method is as follows.

<ClassificationScheme uri = "urn: dvb: ipdc: esg: cs: MultipleESGAnnoucementCarouselAttribute TypeCS">
<Term termID = "1">
<Name xml: lang = "en"> ESG Annoucement Carousel Attribute </ Name>
<Definition xml: lang = "en"> attribute of the ESG announcementcarousel </ Definition>
<Term termID = "1.1">
<Name xml: lang = "en"> Region </ Name>
<Definition xml: lang = "en"> access region </ Definition>
</ Term>
<Term termID = "1.2">
<Name xml: lang = "en"> IPDC operator </ Name>
<Definition xml: lang = "en"> IPDC operator </ Definition>
</ Term>
<Term termID = "1.3">
<Name xml: lang = "en"> IP platform </ Name>
<Definition xml: lang = "en"> IP platform </ Definition>
</ Term>
</ Term>
</ ClassificationScheme>

An independent descriptor such as the following Table 85 may be used for signaling the information.

<complexType name = "ESGComplementaryType">
<complexContent>
<sequence>
<element name = "ESG_URI" type = "anyURI"/>
<element name = "AccessPoint" type = "bs2: accessPointType" maxOccurs = "unbounded"/>
<attribute name = "MultipleESGAnnoucementCarousel" type = "boolean" use = "optiona"/>
<attribute name = "n_o_AnnoucmentCarousel" type = "unsignedInt" use = "optiona"/>
</ complexContent>
</ complexType>

<complexType name = "accessPointType">
<attribute name = "accessPointID" type = "unsignedInt"/>
<sequence>
<element name = "MultipleESGAnnoucementCarouselAttribute" type = "tva: ControlledTermType" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "NetworkID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "CellID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "IPDCKMSId" type = "unsignedShort" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "IPDCOperatorId" type = "string" minOccurs = "0" maxOccurs = "unbounded"/>
<element name = "IPPlatformID" type = "positiveInteger" minOccurs = "0" maxOccurs = "unbounded"/>
</ sequence>
</ complexType>

To support multiple ESG announcement carousels for partitions or different subsets of ESG, it may be necessary to indicate attributes within the fragment level. For example, a certain fragment may be for a satellite cell and a certain fragment may be for a terrestrial cell.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, Additions, and substitutions without departing from the scope of the appended claims.

1 shows a CBMD structure,

Fig. 2 shows the structure of ESG,

Figure 3 also shows the ESG discovery phase,

FIG. 4 is a flow chart of a current ESG discovery process in a terminal,

5 is a diagram showing an example of the first scenario,

6 is a diagram showing an example of a second scenario,

7 is a diagram for explaining the first embodiment applied to the first scenario,

8 is a diagram for explaining the first embodiment applied to the second scenario,

9 is a view for explaining the embodiment 1-1,

FIG. 10 illustrates an example of a structure in which IPDC operator information having various positions is described according to Embodiment 1-1; FIG.

11 is a drawing that includes IPDC operator information in an ESG bootstrap session,

12 is a flowchart of Embodiment 1-1 in a terminal,

13 is a view for explaining the embodiment 1-2,

FIG. 14 is a diagram showing the relationship between the objects related to the descriptor of the bootstrap according to the embodiment 1-2,

Figure 15 also shows the relationship between the IPDC provider and the ESG,

16 is a flowchart of Embodiment 1-2 in a terminal,

17 is a view for explaining the embodiment 2-1 of the scenario 1,

18 is a view for explaining the embodiment 2-1 of the scenario 2,

19A and 19B are flowcharts of the embodiment 2-1 in the terminal,

20 is a view for explaining the embodiment 2-2 applied to the scenario 1,

21 is a view for explaining the embodiment 2-2 applied to the scenario 2,

22 is a flowchart of Embodiment 2-2 in a terminal,

23 is a structural view for explaining Embodiment 3-1,

24 is a flowchart of Embodiment 3-2 in the terminal,

25 is a structural view for explaining Embodiment 3-1;

26 is a flowchart of Embodiment 3-2 in the terminal,

27 is a view showing an example of a specific ESG for a specific area,

28 shows an example of a specific ESG for a particular network,

29 is a diagram showing an example in which an IPDC KSM system and an IPDC operator manage rights;

30 is a view showing an example of roaming,

31 shows that each of the local IPDCKSMID and IPDCOperatorID and its roaming partners are indicated one by one in advance,

32 is a flowchart for explaining operations of a terminal according to IPDCRelatedInformation,

33 is a flowchart for explaining the operation of the server according to IPDCRelatedInformation,

34 is a diagram showing a home operator of a roaming terminal and a local operator having a roaming agreement with the home operator;

Figure 35 is a diagram illustrating the roaming partners in the local IPDC operator and the foreign network,

36 shows a network structure,

37 is a diagram showing a terminal structure,

38 is a flowchart for explaining the operation of the UE according to the sixth embodiment of the present invention;

39 is a view for explaining the operation of the server according to the sixth embodiment of the present invention;

40 is a flowchart for explaining a server operation according to the combined sixth embodiment of the present invention;

FIG. 41 is a view for explaining the operation of the UE according to the combined sixth embodiment of the present invention; FIG.

Figure 42 illustrates an ESG announcement carousel with a new element or container;

Figure 43 illustrates an example of an ESG announcement carousel having a new element or container,

Figure 44 illustrates another example of an ESG announcement carousel having a new element or container,

45 illustrates yet another example of an ESG announcement carousel having a new element or container;

Claims (54)

A method of supporting mobility of a terminal in a server of a mobile broadcasting system providing IPDC (Internet Protocol Data Casting) Listing local IPDC operators providing a broadcast service to a terminal in a predetermined IP platform and an electronic service guide (ESG); Generating roaming information for a local IPDC operator having a roaming partner among the local IPDC operators; And A method of supporting mobility of a terminal in a server of a mobile broadcasting system including broadcasting service information including roaming information through a broadcasting network. The method according to claim 1, Wherein the local IPDC operator having the roaming partner supports the mobility of the terminal in the server of the mobile broadcasting system providing the broadcasting service to the terminal subscribed to the local IPDC operator set as the roaming partner. The method according to claim 1, Wherein the broadcast service information includes an ESG bootstrap, Wherein the generating includes generating the ESG bootstrap by including the roaming information in the ESG bootstrap. The method of claim 3, Wherein the ESG bootstrap further comprises a separate descriptor for providing the roaming information. The method according to claim 1, Wherein the roaming information includes an identifier of a local IPDC operator that is configured as the roaming partner, Wherein the identifier supports an mobility of a terminal in a server of a mobile broadcasting system that is an IPDC KMS (Key Management System) identifier. A method for supporting mobility in a terminal of a mobile broadcasting system providing IPDC (Internet Protocol Data Casting) Receiving broadcasting service information including information of local IPDC operators providing a broadcasting service to a terminal in a predetermined IP platform and an electronic service guide (ESG) through a broadcasting network; Analyzing the broadcast service information to obtain roaming information for a local IPDC operator having a roaming partner among the local IPDC operators; Searching for a specific local IDPC operator having the subscribed local IPDC operator as the roaming partner from the obtained roaming information when the broadcast service can not be provided through the subscribed local IDPC operator; And And accessing the broadcast service using the ESG of the specific local IDPC operator when the specific local IPDC operator is found. The method according to claim 6, Wherein the broadcast service information includes an ESG bootstrap, and the ESG bootstrap further includes the roaming information. 8. The method of claim 7, Wherein the ESG bootstrap includes a separate descriptor for providing the roaming information. The method according to claim 6, Wherein the roaming information includes an identifier of a local IPDC operator that is configured as the roaming partner, Wherein the identifier is an IPDC KMS (Key Management System) identifier. A server apparatus for supporting mobility of a terminal in a mobile broadcasting system providing IPDC (Internet Protocol Data Casting) A local IPDC operator providing a broadcasting service to a terminal in a predetermined IP platform and an electronic service guide (ESG), and generating roaming information for a local IPDC operator having a roaming partner among the local IPDC operators ; And And a transmitter for transmitting broadcast service information including the roaming information generated from the controller through a broadcasting network. 11. The method of claim 10, Wherein the local IPDC operator having the roaming partner supports the mobility of the terminal in the mobile broadcasting system that provides the broadcasting service to the terminal subscribed to the local IPDC operator set as the roaming partner. 11. The method of claim 10, Wherein the broadcast service information includes an ESG bootstrap, Wherein the ESG bootstrap supports the mobility of the terminal in the mobile broadcasting system further including the roaming information. 13. The method of claim 12, Wherein the ESG bootstrap further comprises a separate descriptor for providing the roaming information. 11. The method of claim 10, Wherein the roaming information includes an identifier of a local IPDC operator that is configured as the roaming partner, Wherein the identifier is an IPDC KMS (Key Management System) identifier that supports mobility of a terminal in a mobile broadcasting system. A terminal device supporting mobility in a mobile broadcasting system providing IPDC (Internet Protocol Data Casting) A receiving unit for receiving, through a broadcasting network, broadcasting service information including information of local IPDC operators providing a broadcasting service to a terminal in a predetermined IP platform and an electronic service guide (ESG); And And analyzing the broadcast service information to obtain roaming information for a local IPDC operator having a roaming partner among the local IPDC operators, and if the broadcast service can not be provided through the affiliated local IDPC operator, And a controller for accessing the broadcast service using the ESG of the specific local IDPC operator when the specific local IPDC operator is found, searching for a specific local IDPC operator having the subscribed local IPDC operator as the roaming partner, A terminal device supporting mobility in a system. 16. The method of claim 15, Wherein the broadcast service information includes an ESG bootstrap, and the ESG bootstrap further supports the mobility in a mobile broadcast system including the roaming information. 17. The method of claim 16, Wherein the ESG bootstrap includes a separate descriptor for providing the roaming information. 16. The method of claim 15, Wherein the roaming information includes an identifier of a local IPDC operator that is configured as the roaming partner, Wherein the identifier is an IPDC KMS (Key Management System) identifier that supports mobility in a mobile broadcasting system. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete

Images