HK1112139A1 - Enhanced electronic service guide container - Google Patents

Abstract

The invention provides an efficient transportation of ESG fragments to a receiver through the formation of containers. In this sense, a container comprises at least one ESG fragment, but may contain a plurality of fragments. A fragment may be also carried in more than one container. Aspects of the present invention utilize a simple and extensible header structure apart from the fragments independent of the type and format of the individual fragments. In further embodiments, compression is applied over the entire container, including the fragments and any headers. In yet further embodiments, a 3GPP metadata envelope is carried within the container without the need for unnecessary repetition of parameters, such as for example, version, validity time, and identification. In further embodiments, a simplified container system allowing for the updating of previously received fragments is disclosed.

Description

Enhanced electronic guide container

The present invention is a continuation of the co-pending application entitled Enhanced Electronic Service Guide Container, attorney docket number 004770.00311, filed on 2.12.2004 and entitled Enhanced Electronic Service Guide Container, the entire contents of which are incorporated herein by reference.

Technical Field

The present invention relates generally to communication networks. More particularly, the present invention relates to signaling for data aggregation within a broadcast system.

Background

Typically, an Electronic Service Guide (ESG) enables a terminal to communicate which services are available to an end user and how to access the services. ESG fragments are independently existing parts of an ESG. Typically, EGS fragments contain XML documents, but more recently they have included a large number of items, such as SDP (Session description protocol) descriptions, text files, or images. The ESG fragments describe one or several aspects of currently (or future) available services or broadcast programs. Such aspects may include, for example: free text description, calendar, geographical availability, price, purchasing method, type, and supplemental information such as picture previews or clips. Audio, video and other types of data containing ESG fragments may be transmitted through various types of networks according to a number of different protocols. For example, data may be transmitted over a collection of networks commonly referred to as the "internet" using protocols of the internet protocol suite, such as Internet Protocol (IP) and User Datagram Protocol (UDP). Data is typically sent over the internet addressed to a single user. However, data may be addressed to a group of users, commonly referred to as multicasting. In case the data is addressed to all users, this is called broadcasting.

One way of broadcasting data is to use an IP datacasting (IPDC) network. IPDC is a combination of digital broadcast and internet protocol. Through such an IP-based broadcast network, one or more providers may provide different types of IP services, including online newspapers, radio, television. These IP services are organized into one or more media streams in the form of audio, video, and/or other types of data. To determine when and where these streams occur, the user refers to an Electronic Service Guide (ESG). One example for a Digital Video Broadcasting (DVB) stream is an Electronic Program Guide (EPG). One type of DVB is digital video broadcasting-handheld (DVB-H), a recently developed technology that increases the capabilities and services available on small handheld devices, such as mobile phones. DVB-H is designed to deliver 10Mbps of data to battery powered terminal devices.

DVB transport streams deliver compressed audio, video and data to users via third party delivery networks. Moving Picture Experts Group (MPEG) is a technology that multiplexes encoded video, audio, and data in a single program with other programs into a Transport Stream (TS). A TS is a packetized data stream with fixed length packets including headers. Each of the individual elements of the program, i.e., audio and video, is carried in packets having a unique Packet Identification (PID). In order to enable the receiver device to locate different elements of a particular program in the TS, Program Specific Information (PSI) embedded in the TS is provided. In addition, additional Service Information (SI), a set of tables attached to the MPEG private section syntax, is merged into the TS. This enables the receiver device to correctly process the data contained in the TS.

However, the present invention can also be applied to other conventional digital mobile broadcasting systems such as T-DAB, T/S-DMB, ISDB-T, ATSC, MediaFlow, and non-conventional systems such as 3GPP bms (multimedia broadcast/multicast service) and 3GPP2BCMCS (broadcast/multicast service).

Since images and other large files dominate the ESG transport, there is a need to efficiently transport ESG fragments across the required network to the end receiver. However, previous systems send the header before the ESG, which is inefficient because if the container carrying the EGS is sent before the header, the information cannot be accessed until the header arrives, and there is a risk that the header is not received and thus the information in the container is invalid. Current efforts focus on associating multiple segments, however, are largely unsuccessful due to the lack of unique identification of the segments, a valid header or indexing structure, or the need to provide repetitive parameters.

Disclosure of Invention

Aspects of the present invention allow for the efficient delivery of ESG fragments to a receiver through the formation of containers. In this sense, a container contains at least one ESG fragment, but may contain a plurality of fragments. Alternatively, the fragments may be carried in multiple containers. The containers are transmitted to a receiver, for example, by using Asynchronous Layer Coding (ALC)/Layered Coding Transport (LCT) such that a single ALC/LCT transport object corresponds to a single container. The fragments can be used by the receiver as soon as the entire container is received. Aspects of the present invention use a simple and extensible header structure separate from the fragments, regardless of the type and format of the individual fragments. In a further embodiment, compression is used for the entire container, including the fragments and any headers. In still further embodiments, other envelopes, such as 3GPP metadata envelopes, may be carried in the container without unnecessary repetition of parameters, such as version, time-to-live, and identification.

Metadata in a 3GPP (third generation partnership project) envelope or in any other form may include specific channels, specific programs, and/or specific groups of channels. Other types of metadata may include: packet data, purchase data such as operator identifier data and technical data for completing the transaction, e.g. address, protocol, packet/day, channel/minute, program/minute based price data; channel data such as text description for the user, content providing branding information/logos, category and rating data such as type and parental rating, channel SDP data such as description of capabilities required to use the service, e.g. audio and video format and bit rate information, start and end time, address, synchronized auxiliary information provision address, attribute extensions; and program data such as a user's text description, start and end times, and a reference to interactive services associated with the program. The metadata may be loaded by the operator or done automatically.

Drawings

A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:

FIG. 1 illustrates a block diagram of a wireless communication system in which various aspects of the present invention may be implemented;

FIG. 2 illustrates a block diagram of a mobile terminal in accordance with an aspect of the subject invention;

FIG. 3 illustrates a schematic diagram of an example transport object in accordance with an aspect of the subject invention;

FIG. 4 illustrates a method of sending multiple single object transfers in accordance with an aspect of the subject invention;

FIG. 5 illustrates a block diagram of an exemplary Electronic Service Guide (ESG) fragment descriptor entry in accordance with at least one aspect of the present invention;

fig. 6 illustrates a block diagram of an exemplary container having a plurality of ESG objects in accordance with at least one aspect of the present invention;

fig. 7 is a block diagram illustrating additional exemplary frames of Electronic Service Guide (ESG) fragment descriptor entries in accordance with at least one aspect of the present invention;

FIG. 8 is a block diagram of a simplified container system according to one embodiment of the invention configured for updating previously received fragments;

FIG. 9 is a block diagram illustrating container and fragment management in an update system according to one embodiment of the invention; and

FIG. 10 is a block diagram of a container update accomplished according to one embodiment of the invention.

Detailed Description

In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various exemplary embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.

The present invention may be used with a variety of networks and communication protocols. Fig. 1 shows an example of a wireless communication system 110 in which the systems and methods of the present invention may be used. One or more networked mobile devices 112, such as a Personal Digital Assistant (PDA), a cellular telephone, a mobile terminal, a personal video recorder, a portable television, a personal computer, a digital camera, a digital camcorder, a portable audio device, a portable radio, or a combination thereof, communicate with a service source 122 through a broadcast network 114 and/or a cellular network 116. Mobile terminal/device 112 may comprise a digital broadcast receiving device. The service source 122 may be connected to several service providers that provide actual program content or descriptions or information about their services and programs to the service source, which further provides the content or information to the mobile device 112, which may be used or displayed to the user as an electronic service guide for selecting their services and programs. The number of service providers may include, but is not limited to, one or more television and/or digital television service providers, AM/FM radio service providers, SMS/MMS push service providers, internet network content or access providers.

The broadcast network 114 may include wireless transmission of IP datacasting over DVB-H. The broadcast network 114 may broadcast a service, such as a digital or analog television signal, and additional content related to the service via a transmitter 118. The broadcast network may also comprise a radio, television or IP datacasting broadcast network. The broadcast network 114 may also transmit additional content, which may include television signals, audio and/or video streams, data streams, video files, audio files, software files, and/or video games. In the case of transmitting IP datacasting services, the service source 122 may transmit the actual program content to the user equipment 112 through the broadcast network 114, while additional information (e.g., user rights and access information) for the actual program content is transmitted through the cellular network 116.

The mobile device 112 may also contact the service source 122 through the cellular network 116. The cellular network 116 may include a wireless network and a base transceiver station transmitter 120. The cellular network may comprise a second/third generation (2G/3G) cellular data communications network, a global system for mobile communications network (GSM), or other wireless communications network such as a WLAN network.

According to an aspect of the invention, mobile device 112 may include a wireless interface configured to transmit and/or receive digital wireless communications in cellular network 116. The information received by mobile device 112 through cellular network 116 or broadcast network 114 may include user selections, applications, services, electronic images, audio clips, video clips, and/or other messages. As part of cellular network 116, one or more base stations (not shown) may support digital communications with receiver device 112 while the receiver device is located within the administrative domain of cellular network 116.

As shown in fig. 2, mobile device 112 may include processor 128 connected to user interface 130, memory 134, and/or other storage, and display 136. Mobile device 112 may also include battery 150, speaker 152, and antenna 154. The user interface 130 may further include a keyboard, touch screen, voice interface, one or more arrow keys, joystick, data glove (data glove), mouse, roller ball, touch screen, voice interface, and the like.

Computer-executable instructions and data used by processor 128 and other components within mobile device 112 may be stored in a computer-readable memory 134. The memory may be implemented using any combination of read only memory modules or random access memory modules, optionally including both volatile and nonvolatile memory, and optionally being detachable. Software 140 may be stored in memory 134 and/or storage to provide instructions to processor 128 for enabling mobile device 112 to perform various functions. Alternatively, some or all of mobile device 112 computer executable instructions may be embodied in hardware or firmware (not shown).

Mobile device 112 may be configured to receive, decode and process transmissions based on the Digital Video Broadcast (DVB) standard, such as DVB-H or DVB-MHP, through a specific DVB receiver 141. In addition, mobile device 112 may also be configured to receive, decode and process transmissions through FM/AM radio receiver 142, WLAN transceiver 143, and telecommunications transceiver 144. In one aspect of the invention, mobile device 112 may receive Radio Data Stream (RDS) messages.

In the example of the DVB standard, a 10Mbit/s DVB transmission may have 200 audio program channels of 50kbit/s or 50 video (TV) program channels of 200 kbit/s. Mobile device 112 may be configured to receive, decode and process transmissions based on the digital video handheld broadcast (DVB-H) standard or other DVB standards, such as DVB-satellite (DVB-S), DVB-terrestrial (DVB-T) or DVB-cable (DVB-C). Similarly, other digital transmission formats may alternatively be used to transmit content and information of additional service availability, such as ATSC (advanced television systems committee), NTSC (international television systems committee), ISDB (integrated services digital broadcasting), DAB (digital audio broadcasting), DMB (digital multimedia broadcasting), or DIRECTV. Furthermore, the digital transmission may be time sliced, for example in DVB-H technology. Time-slicing may reduce the average power consumption of the mobile terminal and may enable smooth and seamless handover. Time-slicing consists of sending data in bursts using a higher instantaneous bit rate than is required to send data using a conventional streaming mechanism. In this case, the mobile device 112 may have one or more buffer memories for storing the decoded time sliced transmission before presentation.

FIG. 3 is a schematic diagram of an example transport object in accordance with at least one aspect of the present invention. Typically, a single transport object 300 contains a container header 310 and a container payload 320. By combining the header 310 and the payload 320 in a single object 300, there is no longer a need to recombine each header with the location information of each container in a different transport object. Furthermore, there is no problem of which to transmit first as occurs in conventional systems. The container header 310 may contain configuration information about the header and/or the container payload 320. In one embodiment, the header 310 is encoded to inform the receiver of the entry length of the header.

In an exemplary embodiment, the header 310 may have a plurality of ESG fragment descriptor entries 330 that identify the ESG fragments 340 in the container payload 320 so that the receiver may determine the exact location and/or length of each contained ESG fragment 340. For example, in one embodiment, a field specifies where the particular ESG begins in the container payload 120 by providing, for example, an offset value 550, start and end points, or the like. In other embodiments, the metadata 350 may be associated with a single ESG fragment 340, proximate to or within the header 310, the descriptor entries 330, the ESG fragments 340, or a mixture thereof. In an exemplary embodiment, the association of a 3GPP metadata envelope with an ESG fragment 340 may replace or negate the need for additional metadata located in the header 310 in relation to the particular ESG fragment.

FIG. 4 illustrates a method of sending multiple single object transfers, wherein the transfers are in accordance with at least one aspect of the present invention. As shown in fig. 4, the Transport Object (TO) of the present invention may be carried in, for example, a FLUTE (file delivery over unidirectional transport) session or a pure ALC session. In the example of fig. 4, ESG root channel data, such as IP address, port number and Transport Session Identifier (TSI), is declared in the IP/MAC notification table (INT table). A FLUTE session of an ESG root channel contains a file delivery table and one or more delivery objects (TO) of the session. The transport object contains a mapping between different types of ESGs and access parameters of different ESG sessions in which ESG data is transmitted. The ESGs may be different from each other, e.g., in different languages and/or with different encoding and types. The access parameters include IP address, port number, TSI, start and end time, etc. The FLUTE session thus states how ESG data is distributed to different sessions. The TO of a FLUTE session carrying mapping data is described in the FDT of the FLUTE session. ESG mapping data may be transmitted in one or more TOs. The mapping may be implemented using XML schema, simple ASCII text, structured ASCII text such as multipart MIME or MIME headers, as a binary of enumerated types, or by other different means known in the art. In this embodiment, ESG data is transported in one or more TOs in an ESG session, which may be a pure ALC session. The ESG data may be transmitted in one or more ESG sessions. In some embodiments of the present invention, ESG data or a portion thereof may be transmitted in one or more FLUTE sessions in addition to or instead of an ACL session.

Fig. 5 is a block diagram illustrating exemplary frames of Electronic Service Guide (ESG) fragment descriptor entries in accordance with at least one aspect of the present invention. Frame 500 shows the format of a protocol frame for header 310. Frames 502A-D with descriptor entries are illustrative examples that include a type field 505 indicating the type and characteristics of an entry 330. The type field may be extended to allow for the addition of new types of entries. By entering the entry type in field 505, different information can be provided to the receiver. We have predefined specific metadata associated with the segments for the frame instances 502A-D. For example, in 502B, the offset field, the start field, the end field, and the base URI field are metadata for the relevant segments in the payload. In contrast, no metadata is associated in frame instance 502C for the segment it represents.

As described above, the payload may contain an envelope, or an entry of the type that provides predefined parameters of the ESG fragment located in the payload, wherein the envelope associates metadata with the fragment itself (both included in the envelope) or indicates that metadata is located in the header. Also, as shown in frame 502C, a single descriptor entry may be configured by its type to describe multiple ESG fragments, or even different versions of the same ESG fragment. For example, frame 502A is labeled as a type 1 entry and includes information about the ESG fragment such as location, format, version information, unique identifier. To illustrate this, the frame 502 may provide additional information fields regarding the ESG fragment 340 such as the format 510, version 520, and unique identifier 530. In an exemplary embodiment, the format field 510 specifies whether the ESG fragment 500 is text, video, and/or a picture. However, those skilled in the art will appreciate that the format field 510 may specify virtually any information of the type of media contained in the ESG fragment 340.

A version field 520 may be included to allow updating of previously received ESGs. For example, newer versions of ESGs may be automatically detected and executed, whereas expired ESG fragments specified by version field 520 may not be executed or executed as directed by the receiver user. This is also always useful when local services are available. For example, when a mobile terminal moves from one geographic area to another, some services may still be available, some may no longer be available, and some may become available. Thus, some ESG objects are valid in the new geographic area as they are in the original geographic area. In an embodiment, the terminal may identify the ESG objects available in the new geographic area and may store/cache the objects that are no longer valid. In another embodiment, the terminal may receive and store ESG objects from different frequencies, IP platforms, and network operators and then merge these objects with ESG objects from the current network in a unified ESG.

Optionally, the version field 520 may be combined with the validity field 570 or replace the validity field 570. The version field 520 may indicate whether the received ESG fragment is the most recent version or is configured to determine whether compatibility issues exist, while the validity field 570 may further distinguish unused or lower priority ESG fragments. As shown in fig. 5, one or more validity fields 570 may indicate a period of time for which the associated segment is valid. Alternatively, validity may be based on the hardware of the receiver, user-defined settings, and/or the presence of other ESGs. For example, the location where the node is loaded or the presence of a base URI, whether in the validity field 570 or other fields, may allow verification of the received ESG fragment. In other embodiments, the baseuri may allow a receiver to use the information located at the URI in conjunction with or in place of an ESG fragment.

The unique identifier field 530 allows identification of ESG fragments regardless of the information in the container header 310. This information is useful, for example, when multiple ESGs are received, executed, or no longer associated with a header, or need to be globally identifiable. Each of the above-described information fields 510, 520, 530 may optionally contain, among other fields used, a padding field 540 to compensate for portions that do not satisfy the byte rules of the entry. For example, if the location of the ESG fragment contains a base URI that does not provide enough bits for the entry, the required space may be filled with ASCII characters (e.g., 0) to meet the bit requirements. As disclosed, each ESG fragment may be encoded to a different bit rate than other ESG fragments. In yet another embodiment, different bit rates may be used for different parameters in a single ESG, for example in different information fields 510, 520, 530.

The position of the ESG fragment may be obtained by utilizing the offset field 550 alone or in conjunction with the entry length field 560, where the offset of the fragment may be measured from the header, an initial point in the payload, or any other point in the transport object. The fragment offset and length values may be measured in bits, bytes, or any similar counting system. As previously described, domains using different systems (e.g., 6 bits, 10 bits, 32 bits) may all be encoded in the same descriptor entry. Each descriptor entry 500 has a fragment identification field 530 that uniquely identifies the ESG fragment. In the exemplary descriptor entries 500C, 500D, 500E, the base URI is appended to the fragment identification in the payload container to create a globally unique identifier.

Fig. 6 illustrates a block diagram of an exemplary container having a plurality of ESG objects in accordance with at least one aspect of the present invention. Transport object 600 has a container header 610 preceding a container payload 620, together forming a single transport object. The header 610 contains a coded portion regarding the header length 630. The header 610 may optionally contain a signaling mechanism or transport encoding mechanism configured to signal that the transport object or a portion thereof is encoded or compressed. In one embodiment, the LCT codepoint located at the start of the header 610 may signal that the entire transmission including the header is compressed. In other embodiments, the reserved field may contain a codepoint that signals the encoding for the transport object 600. As an example, GZIP may be used for the above purpose; however, those skilled in the art will appreciate that a variety of other schemes are possible to accomplish the purpose of compression in the manner described. In embodiments with reserved fields, additional information may optionally be included, for example relating to the ESG, the header itself, or additional compressed or encoded information. The container payload 620 contains at least one ESG fragment 640 in which some or all of the fragments have metadata (as in fig. 3). In some instances, a fragment does not have metadata, but rather any necessary metadata may be found in the header 610 associated with the appropriate descriptor entry. The transport object may be stored in a memory of the transmitter, in an intermediate transport node, and/or in a different receiver.

Fig. 7 is a block diagram illustrating additional exemplary frames of an Electronic Service Guide (ESG) fragment descriptor entry in accordance with at least one embodiment of the present invention. Frames 700, 710, 720, 730, and 740 include a type field 750 to indicate the type of frame received. As described above, the type field 750 may be extensible to allow for the addition of new types of entries. Frame 700 represents a simple ESG descriptor entry for providing the location of an ESG fragment in the payload. In the illustrated embodiment, the offset values of the ESG fragments are used to locate the fragments.

Frames 710, 720 and 730 show different types of descriptor entries that are not associated with any container payload. And frames 710, 720, and 730 may be used to verify the ESG fragments that have been received. In other embodiments, such as that shown in frame 740, the descriptor entry may contain a declaration of a base URI for the entire container.

In another aspect, the present invention comprises a system and method for determining whether a newly transmitted container is a valid update of a previously received container without decoding or processing information in the container payload. In at least one embodiment, the transmitter is configured to update the plurality of segments as a unit. In yet another aspect, the present invention comprises a system and method for requiring only a single instance of a container type to determine a fragment combination in every other possible instance of the same type.

FIG. 8 is a block diagram of a simplified container system according to one embodiment of the invention configured for updating previously received fragments. The system is configured to determine whether a newly transmitted container is a valid update without decoding or reading information in the container payload. The update container 800 generally includes a container header 810 and a container payload 820. In an exemplary embodiment, the header 810 contains information related to the number of fragments in the payload 820 and an associated offset value, however, it is within the scope of the invention to contain information related to the header 810 and/or the payload 820. The payload contains data items 830, 840 with fragment updates. Although the present embodiment shows two data items, additional data items may be considered while transferring a single data item. Each data item includes an indication of its type 850.

The container may further indicate the presence of a payload header. For example, a type 1 data item may be a binary envelope with metadata associated with a predetermined fragment in the header, as shown. Type 2 may indicate 3GPP text envelopes associated with different fragments. The metadata is not fixed at the transport layer. In addition to the above examples, other container types may be defined.

The novel update system is implemented through the configuration and management of fragment and container instances. An "instance of a fragment" or "fragment instance" relates to a particular type and version of fragment, wherein an "instance of a container" or "container instance" relates to a container that holds a particular fragment instance. FIG. 9 is a block diagram illustrating container and fragment management in an update system according to one embodiment of the invention. In an exemplary embodiment, File Delivery Tables (FDTs) 900 and 910 declare instances of fragment groupings. The fragment types in each container type are determined by the receiver when the first container instance is initially received. All different container instances of the same type use the same signature-e.g., FDT content-location, but different Transport Object Identifiers (TOIs). In an exemplary embodiment, FIDT 900 has a TOI of 5 and FDT 910 has a TOI of 6, thus representing different container instances, however, the content type and content-location remain unchanged. Two different container instances may use different encodings, i.e. they have different content types. For example, the container holding fragment a of version a1 and fragment B of version B1 and the container holding fragment a of version a2 and fragment B of version B2 are of the same container type. Furthermore, the container holding fragment a (independent of the version) will have a distinct container type from the container holding fragments A, B and C (of any version). Additional optional fields, such as content-encoding, may also remain in an unchanged state according to the preferences of the transmitter. For example, if textual metadata is used, the entire container may be encoded using, for example, GZip or other technical mechanisms known in the art. Or only partially encoded.

Container coding and Forward Error Correction (FEC) may be declared through different mechanisms. For example, the FDT parameters may declare the encoding mechanism. In one embodiment, the coding and FEC are declared by using LCT extensions. The container is encoded so that a receiver can determine whether the container is decoded and processed without accessing or reading the container. FIG. 10 is a block diagram of performing a container update according to one embodiment of the invention. In this example, FDT 1010 has a TOI of 1 and corresponds to type a container 1020 having instance a1, where instance a1 may contain, for example, fragment 1: example 4 and fragment 2: example 3. The FDT 1010 and associated container 1020 are received at the terminal and processed or rejected at the terminal. The file delivery table 1030 provides updates to the FDT 1010 and is received after the FDT 1010 is received. The FDT still corresponds to type a container 1040, however it contains instance a2 instead of instance a1 and may contain variations such as fragment 1: example 4 no change but fragment 2: example 3 is changed to example 5. Once received, the terminal determines that instance A2 includes one or more fragment updates compared to instance A1. The terminal may further determine that a2 contains fragments of the same type as a 1. In one embodiment, the terminal further determines whether a2 is to be implemented based on a number of factors.

While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention as set forth in the appended claims.

Claims (8)

1. A method of receiving an electronic service guide, ESG, fragment of an electronic service guide in a mobile terminal, the mobile terminal comprising a processor, a display and a memory, the method comprising the steps of:

receiving a single transport object comprising a container payload and a container header, the container header comprising a container header length and an ESG fragment descriptor entry,

using the ESG fragment descriptor entries to determine information about the location of associated data in the container payload, an

And displaying the container payload on a display of the mobile terminal equipment.

2. The method of claim 1, wherein the ESG fragment descriptor entries further comprise metadata.

3. The method of claim 1 wherein the ESG fragments are assigned a unique identification code.

4. A method of receiving an electronic service guide, ESG, fragment of an electronic service guide in a mobile terminal, the mobile terminal including a display and a user interface device for presenting a graphical user interface, the method comprising the steps of:

receiving a single transport object comprising a container payload and a container header, the container header comprising a container header length and an ESG fragment descriptor entry,

using the ESG fragment descriptor entries to determine information about the location of associated data in the container payload, an

Presenting the container payload on a display of the mobile terminal via the graphical user interface.

5. A method of updating an electronic service guide, ESG, the method comprising the steps of:

receiving, by a receiving interface, a transport object comprising a container payload comprising data identifying a type of container payload, wherein the container payload further comprises an identifier defining an instance of the container payload; and

using the identifier to determine whether the container payload includes one or more ESG fragments for updating the ESG based on the instance.

6. The method according to claim 5, further comprising the steps of:

determining an ESG fragment combination based on the first instance of the container payload,

determining whether the container payload was previously received based on the instance of the container payload,

wherein if the receiving interface previously received the container payload, the ESG is made available without updating a combination of ESG fragments.

7. The method of claim 6, wherein the container payload is encoded and previously received by the receiving interface, the method further comprising the steps of:

determining whether an update to the ESG is to be performed based on the encoding and prior to accessing the container payload.

8. The method of claim 7, wherein the transport object is configured such that the ESG is to be updated based on all of the plurality of ESG fragments carried by the container payload.