FR3052318A1 - METHOD FOR ACCESSING A SERVICE TRANSMITTED IN TELE-BROADCAST MODE ON A MOBILE NETWORK - Google Patents

Abstract

A method for accessing a content delivery service (SVC), real-time or delayed, accessible on a content server, the method being implemented in a user terminal (UM) connected to a mobile or wireless network, and comprising the steps of: obtaining an access address to a service, transmitting to a service broadcast server (BMS) a metadata request containing the service access address, if the service is available in broadcast mode, receiving service metadata (MTD) containing service access data in broadcast mode and broadcast schedule data, and receiving the content corresponding to the service in broadcast mode to a moment in accordance with the broadcast schedules.

Description

METHOD FOR ACCESSING A SERVICE TRANSMITTED IN TELE-BROADCAST MODE ON A MOBILE NETWORK

The present invention relates to the transmission of data such as multimedia data broadcast in real time (live) or delayed, on demand. In particular, the present invention relates to the provision of Multimedia Broadcast and Multicast Service (MBMS) content or services via mobile or cellular networks.

Mobile communication networks are widely deployed to provide a variety of communication services, such as voice communication services, messaging services, video transmission services, or data in the form of packets. These mobile networks are generally multi-access networks, capable of supporting a large number of users by sharing available resources.

The mobile communication networks may comprise base stations providing communication between the mobile networks and the user terminals, each user terminal being able to have in a network an upstream communication link from the user terminal to a station base, and a downlink communication link, from the base station to the user terminal.

The 3GPP-LTE (Third Generation Partnership Project - Long Term Evolution) project is a major advance in the field of cellular network technologies such as GSM (Global System for Mobile Communications) and UMTS (Universal Mobile Telecommunications System). LTE refers to a physical layer providing an efficient means of transmitting both data and control information between the base stations and the user terminals.

In particular, the 3GPP-LTE project defines two modes of communication between user terminals and base stations, namely unicast or unicast, multicast, or multicast. broadcast (broadcast). In the unicast mode, information carrying signals are transmitted directly to a single user terminal. In the multicast and broadcast modes, one or more base stations broadcast information-bearing signals in a synchronized manner to all user terminals within range of the base stations. Receiving terminals are identified in the multicast mode, but not in the broadcast mode. Multicast and broadcast modes make it possible to use network resources more efficiently than unicast mode, when the same information is requested at the same time by several users, such as information relating to an event, transmitted live or in real time. The demand for services based on the multicast or television broadcasting mode tends to develop rapidly, in particular to limit the saturation of mobile networks.

The transmission of information such as video contents can be carried out by various means in the communication networks. In the case of video content for example, this transmission can be performed from the source of the content on the display screen in different ways depending on the unicast mode, or multicast or television broadcasting. In unicast mode, the content is transmitted directly to a targeted user terminal. For this purpose, the targeted terminal must have a URL (Uniform Resource Locator) of the source of the content, typically a video server, and may issue an HTTP GET command to the video server. In response to this command, the content can be transmitted in unicast mode as small file sequences called "segments" such as Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS). to restore the contents during its acquisition and / or to store it for a later restitution.

Multicast or broadcast transmissions, such as those offered by the eMBMS service (Evolved Multimedia Broadcast / Multicast Service), have different specificities because they are performed with several receiving terminals. To establish such transmissions, the receiving terminals can obtain information on broadcast content before the relevant application installed in the terminals is activated to obtain this information. Each receiving terminal can store this information in a local cache. When the affected application is enabled and transmits a URL to request this information, the generated URL may point to information already stored in the local cache rather than to the server providing the content, as in unicast mode. The DASH environment combined with the File Delivery over Unidirectional Transport (FLUTE) file transport mode can be used in multicast or broadcast mode. According to this combination, content can be converted into DASH segments that are assembled into packets by a FLUTE FLUTE engine (FLUTE Package Engine) which transmits the packets into the network. The structure of the DASH segments is specified by the ISO Base Media File Format (ISOBMFF) format or the MPEG2 TS (MPEG Transport Stream) format.

A MooD (MBMS operation on Demand) method has been proposed to broadcast on the fly, in a transparent manner for the user, from the unicast mode to the broadcast mode and vice versa, when transmitting content in real time or in real time. direct, in particular depending on the number of users requesting the content in a region where the user's terminal is located. This method is specified in particular in the documents 3GPP TS 26.346 and 3GPP TR 26.849). According to this method, the passages between the unicast and television broadcasting modes are carried out at the initiative of the network according to the number of requests for the same content, issued by the users.

When accessing new content, the terminal may need to determine whether the content is broadcast in broadcast mode. For this purpose, the user terminal must request the list of contents broadcast in this mode or likely to be. It can also access an address broadcasting all content currently accessible in broadcast mode. These operations make it possible to obtain metadata relating to each available content, including notably access data to content broadcast in broadcast mode and broadcast schedule data. It turns out that the metadata transmitted for a single content is large. The number of content that can be broadcast in a broadcast region tends to increase and may become important in the near future. As a result, the acquisition of this data for all possible contents may represent for the user terminals a considerable burden in terms of the volume of data to be received, processed, and stored, and thus in terms of the power consumption for terminals and bandwidth consumption for networks. In addition, when switching from unicast mode to broadcast mode, the user terminal already has all the metadata necessary to access content in broadcast mode, except access address metadata. content in broadcast mode.

It also turns out that the list of contents likely to be broadcast in broadcast mode is fixed may vary very frequently, and does not contain in particular content transmitted deferred and content accessible by bypass ("over-the-top services"). "), that is to say, contents not referenced by the network operator ensuring the distribution of contents. This includes, for example, video content broadcast by content providers such as YouTube or Netflix.

It is therefore desirable to allow the user terminals to be able to simply determine whether a particular content is available in broadcast mode and to request the data necessary to access this content, without having to receive information about all the other content available in the broadcast mode. broadcast mode. It may also be desirable to allow a server providing access to unicast content to easily determine the number of user terminals to access the same content, in order to transmit the content in unicast or broadcast mode based on that number. . It may also be desirable to be able to broadcast content in broadcast mode, even when the content is not produced in real time or broadcast live.

Embodiments are directed to a method of accessing a content delivery service, real-time or delayed, accessible on a content server, the method being implemented in a user terminal connected to a mobile network or without wire, and comprising the steps of: obtaining an access address to a service, transmitting to a service delivery server, a metadata request containing an access address to a service accessible in unicast mode, and if the service is available in broadcast mode, receiving service metadata containing service access address data in broadcast mode and broadcast schedule data, and receiving content corresponding to the service in broadcast mode at a mutually agreeable time the broadcast schedule data.

According to one embodiment, the method comprises a step of reception by the user terminal of a notification indicating that the requested service may be available in television broadcasting mode after a waiting period specified in the notification, if the service may become available in broadcast mode.

According to one embodiment, the method comprises a step of programming the transmission to the broadcast server of a new service access metadata request, taking into account the waiting time received in the notification.

Embodiments may also relate to a computer program product directly loadable into an internal memory of a terminal and comprising portions of code that when executed by the terminal configure the terminal to implement the steps of the defined method previously.

Embodiments may also relate to a method for providing a content delivery service, real-time or delayed, accessible on a content server, implemented by a broadcast server via a mobile network or wirelessly, the method comprising the steps of: receiving from a user terminal a metadata request containing an access address to a service accessible in unicast mode, determining whether the service is available in broadcast mode, and whether the service is available in broadcast mode, transmitting service metadata to the user terminal, containing service access address data in broadcast mode and broadcast schedule data, and transmitting content in broadcast mode corresponding to the service at a time consistent with the broadcast schedule data.

According to one embodiment, the method comprises a step of transmission by the broadcast server to the user terminal of a notification indicating that the requested service may be available in broadcast mode after a specified waiting period. in the notification, if the service may become available in broadcast mode,

According to one embodiment, the method comprises a step of storage by the broadcast server that the service has been requested from an area of the mobile network defined by a location data item in the metadata request, in connection with the location data and service identifiers.

According to one embodiment, the method comprises the steps of: counting by the broadcast server a number of user terminals having issued a request for access to the service from the network area defined by the location data, and when the number of user terminals having issued a service access request in the area of the mobile network exceeds a threshold value, programming by the broadcast server broadcasting the service in broadcast mode to a broadcast schedule.

According to one embodiment, broadcasting the service in broadcast mode comprises the steps of: downloading and memorizing by the broadcast server metadata relating to the service, updating by the broadcast server the metadata relating to the service to give the service a new access address corresponding to the broadcast server, and to mention broadcasting times of the service in broadcast mode, download by the broadcast server the content provided by the service from a content server identified in the downloaded metadata, and storing the content locally for transmission in broadcast mode within a time specified by the broadcast schedule data.

According to one embodiment, the service belongs to a group of services including: real-time content access services, streaming services, file download services, and services providing RSS or Atom feeds.

According to one embodiment, the metadata request comprises at least one of the following data: data relating to the capabilities of the user terminal, a language desired for the provision of the service, a waiting time or a time slot of availability of a user of the terminal for accessing the service, location data of the user terminal, a start date of content to be transmitted in the event that the service provides an RSS or Atom feed, and a reference to a part of the content provided by the service, expected by the user of the terminal.

In one embodiment, the metadata includes identification data of a mobile or wireless network in which the service will be provided in broadcast mode, and optionally, network location data.

Embodiments may also relate to a computer program product directly loadable into an internal memory of a server and including portions of code that when executed by the server configure the server to implement the steps of the set method. implemented by a broadcast server, defined above.

Embodiments may also relate to a broadcast server and a terminal configured to implement the previously defined methods.

Exemplary embodiments of the invention will be described in the following, without limitation in connection with the accompanying figures in which: Figure 1 schematically shows a system providing unicast and television broadcasting services content, Figure 2 represents schematically different software layers implemented in a mobile terminal to access content transmitted in unicast or television broadcast, Figure 3 shows steps of a content transmission method between a content server and a mobile terminal, according to a method of FIG. 4 represents structured data transmitted to the mobile terminal for accessing content, FIG. 5 represents steps of a method of transmitting content between a content server and a mobile terminal, according to another embodiment of the invention. embodiment, FIG. 6 represents steps of a story transmission method. between a content server and a mobile terminal, according to another embodiment,

FIG. 1 represents a system offering content delivery services such as streaming multimedia content or by downloading files, these contents being transmitted by unicast or television broadcasting. The system includes one or more CNTP content servers, one or more Internet Protocol (IP) packet-based IPN networks, one or more BMS servers providing Multimedia Broadcast and Multicast Service (MBMS) or Extended MBMS (eMBMS) services. ), connected to the CNTP content servers by one or more of the IPN networks, MNT mobile networks, one or more MGW gateways each establishing a link between one of the IPN networks and one of the mobile networks, and UM mobile terminals. each connected to one or more of the MNT mobile networks. Mobile networks can include cellular networks such as 3G, LTE (4G), 5G, or wireless networks such as WiFi, Wimax, Bluetooth.

The content broadcast by the content servers may be multimedia data (video, audio, web pages), or files containing such multimedia data or an application that may be installed in one of the UM terminals, or streams RSS (Really Simple Syndication or Rich Site Summary) or Atom. The UM terminals can be "smart" phones (smartphones) or digital tablets, or any type of computer having circuits for connecting to one of the MNT mobile networks and for rendering multimedia content provided by one of the CNTP content servers,

FIG. 2 represents various software layers implemented in a mobile terminal UM for accessing content transmitted in unicast or television broadcasting. These software layers correspond to network layers as defined in the Open System Interconnection (OSI) model. These software layers include an APPS application layer that includes all the applications installed in the mobile terminal and accessing content reception service layers. The receiving service layers are of two types for receiving content either exclusively in UC unicast mode, or in MBMS mode implementing one or other of the UC / BC mono- and television broadcasting modes. These layers include security related items that are not represented.

Starting from the highest level, under the APPS application layer, the UC unicast mode specific software layers include, in parallel, an advertisement SANU providing content metadata provided by content services, ADPU procedures services. associated provisioning services, including a file repair FREP service for processing transmission errors, and a reception quality report RAPR service providing statistical data relating to the reception which can be transmitted for example to the BMS server. The data produced by the SANU and ADPU layers is transmitted by a UHT layer implementing the HTTP protocol (HyperText Transfer Protocol). The data transmitted by the UHT layer are encapsulated and transmitted by a transport UTCP layer implementing the Transmission Control Protocol (TCP). The data transmitted by the UTCP layer is packaged by a network IPUC layer implementing the IP protocol. Finally, a PTPB point-to-point link layer corresponding to the implementation of a radio transmission channel transmits the data. IP packets produced by the IPUC layer.

Starting from the highest level under the APPS application layer, MBMS mode specific software layers (UC / BC) include, in parallel, an SANN service for announcing the available streams, in particular the streams transmitted in broadcast mode, a DWL service. downloading files of different formats, ADP services of associated delivery procedures, and streaming STCD services in continuous mode. STCD services include audio, video, voice, text, etc. CODECs, and a stream receiving DSHC service implementing the DASH protocol. The ADP service includes a file repair FMRP service for handling transmission errors in broadcast mode. Below the STCD layer is a transmission stream formatting RTPF service, including SRTP, RTP, real-time stream transport transport control and RTCP services, secure or not, and an FEC repair service. files to correct any transmission errors. Below the DSHC layer is a HTPC layer that implements the HTTP protocol. Below the DSHC, DWL, FMRP and SANN layers is a FLT layer implementing the FLUTE protocol including an FFEC transmission error correction service. Below the RTPF (FEC) and FLT layers is a MUDP layer that implements the User Datagram Protocol (UDP). Below the HTPC layer is an MTC layer that implements the TCP protocol. Below the MUDP and MTC layers is an IPMU network layer that implements IP in either point-to-point or point-to-multipoint mode. Finally, a point-to-point or multi-point MTB layer provides the transmission of IP packets generated by the IPMU layer.

FIG. 3 represents steps S1 to S16 of an access procedure by a mobile terminal UM to a service for providing content broadcast in real time or in deferred time, the content being accessible on a content server CNTS. In the UM terminal, this procedure is implemented by an APP application for accessing and returning content, a DSHC module configured to receive DASH or HLS content, a LHPC caching module for temporarily storing data. received, and an MBMC module implementing the MBMS protocol. The UM communicates with the CNTS content server via a BMS server including a PXSF proxy server function and a SANF advertisement function of available content delivery services, in connection with the SANU announcement service. or SANN (Figure 2). The BMS server is configured to provide a link between all the mobile terminals located in a geographical area of a MNT mobile network linked to a mobile network operator and content servers connected to the IPN network. The APP application can be configured to give access to content by file download or in continuous mode. The contents may be for example multimedia content (audio, video, HTML pages, etc.) or applications to download and install in the UM mobile terminal.

Steps S1 to S4 are executed successively. In step S1, the APP application issues an access request to an SVC service to obtain a particular content transmitted in real time or delayed time. A real-time transmission designates a transmission carried out with a latency, as the case may be, of a few tens of milliseconds to a few tens of seconds between the production of the content and the reception thereof by the terminal UM.

According to one embodiment, the request includes MURI data making it possible to identify the requested service. In step S2, this request is received by the DSHC module which sends a request to the MBMC module to determine whether the requested SVC service can transmit the required content in broadcast mode. In step S3, the MBMC module receives this request containing the identification data MURI of the service, and sends a broadcast data request in the form of metadata, relating to the SVC service identified by the MURI data, to the server BMS providing the link between the IPN network and the region (group of cells) of the MNT network where the UM terminal is located. In step S4, the SANF advertisement function of the BMS server receives this request and searches for the service identifier SVC in a list of services excluded from the broadcasting mode. If the service corresponding to the service identifier SVC can not be transmitted in broadcast mode, steps S13 to S16 are executed, otherwise steps S5 to S12 are executed. In step S13, the SANF advertisement function issues an ERR error message. The error message ERR is received by the MBMC module of the terminal UM and retransmitted to the DSHC module in step S14. In step S15, the DSHC module retransmits the error message to the APP application. In step S16, the APP application conventionally accesses the SVC service in UC unicast mode, either in streaming mode, or by downloading one or more files including the required content. For this purpose, the DSHC module directly accesses the content server CNTS, the MBMC module not being requested. However, mechanisms are provided for notifying a terminal accessing a service in unicast mode that this service is now accessible in broadcast mode. These mechanisms also allow the terminal to switch to the broadcast mode in a manner transparent to the user.

It should be noted that in step S2, the terminal UM can already store the metadata relating to the requested SVC service. This means that the service is or will be available in broadcast mode. In this case, only steps S9 to S11 can be executed following step S2. Moreover, the request sent in step S1 can also enable the terminal UM to obtain metadata necessary for access to the SVC service in unicast mode. This request is then processed by the content server CNTS. In step S5, the SANF advertisement function determines whether the BMS server has the MTD data (metadata) relating to the required SVC service corresponding to the MURI identification data of the SVC service. The BMS server stores in a database MB (Figure 1) metadata relating to services being broadcast in broadcast mode, or programmed to be transmitted in broadcast mode or may be broadcast in this mode. Metadata for a service scheduled to broadcast in broadcast mode specifies programming times during which the service will be broadcast in broadcast mode. If the MTD metadata is available on the BMS server for the SVC service, steps S8 to S12 are executed, otherwise steps S6 to S12 are executed. In step S6, the BMS server transmits a request for the MTD metadata to the designated CNTS content server in the SID identification data of the SVC service. In step S7, the BMS server receives from the CNTS server the MTD metadata corresponding to the SVC service. In step S8, the SANF advertisement function of the BMS server can determine based on the received MTD metadata for the SVC service, if this may be available broadcast mode. Thus, a service can be determined not available in broadcast mode, in particular according to criteria of content size, bit rate, codecs, type of compression, broadcasting schedule, and according to whether the corresponding content is produced in real time or not. If the thus identified SVC service can not be transmitted in broadcast mode, the steps S13 to S16 are executed, otherwise, the SANF advertisement function of the BMS server stores the received metadata in the database MB, and the steps S9 to S12 are executed. In step S9, the MTD metadata relating to the SVC service is transmitted to the mobile terminal UM. The MTD metadata are received and stored by the MBMC module of the terminal UM and transmitted to the DSHC module in step S10, then to the APP application, in step S11. In step S12, the APP application accesses the SVC service in a conventional manner, either in BC broadcast mode if the BMS server is already broadcasting the service in this mode, or in UC unicast mode.

Steps S6 and S7 are executed notably in the case where the requested SVC service is not known to the BMS server, such as content bypass (OTT).

The MURI data transmitted in step S3, making it possible to identify the requested SVC service, can comprise a service Uniform Resource Identifier (URI) of the service, such as a URL (Uniform Resource Locator) access to MPD metadata. related to the service, or a URL of the content on the CNTS content server, in the case of a download file or a continuously accessible content. It can also be a URL address of an RSS 2.0 or Atom feed.

The MURI data contained in the request sent in step S1 may also comprise: data relating to the capabilities of the terminal UM (screen resolution, available coded, etc.); location data of the terminal UM in the terminal; mobile MNT and / or geographical network (eg GPS point), - one or more languages desired for the content, in the form of voice or subtitles, - a time-out period or a time slot specifying when the user is available to access the SVC service, - a start date of the expected content for an RSS or Atom feed, - a reference of a part of the content to be transmitted, for example in the form of a start segment number and / or end, of a set of segments of the content to be transmitted, or in the form of a percentage with respect to the total duration or the total size of the content, from the beginning and / or the end of the content, to not to receive.

The MURI data can be part of the URI or the URL, for example in a format associating a key ky with a value kyVal "? Ky =" + "kyVal", the character "?" being used as the separator of the different data specified in the identifier UR, and the key ky specifying the type of the data whose value is specified by kyVal. This data can also be mentioned in an HTTP request header.

Multiple access services to the same content can be implemented to take into account the capabilities of the different mobile terminals that can access the content, each service providing the content in a manner adapted to the capabilities of a given type of terminal. Thus, in step S4, the BMS server can check whether the requested SVC service is available taking into account the capabilities of the UM terminal and the desired language data contained in the MURI data. Thus, the step S13 can be executed if the requested service SVC is not available taking into account the capacities of the terminal, or if it is not available during the time slot specified in the data MURI.

After step S3 and before step S8, the BMS server can respond to the request sent in step S1 by providing in the metadata MPD one or more time slots during which the content corresponding to the SVC service will be broadcast in broadcast mode . After step S1 and before the content corresponding to the service is available in broadcast mode, the terminal UM may issue a notification to indicate to the BMS server that it no longer wishes to access the SVC service.

FIG. 4 represents the structure of the database MB containing the MTD metadata relating to the various services that can be transmitted in broadcast mode by the BMS server. The MB database includes a USDL list containing one or more service description elements USR1, USR2, ... USRn. Each of these elements can reference a FECD stream repair metadata instance by FEC. Each USRi service description element includes a content presentation description MPDR element, at least one content delivery method DELM element, and at most one SCHR programming element. Each MPDR element includes an identifier referencing MPD metadata for describing a content. Each DELM element references SESD session description metadata, security description SECD metadata, and associated provisioning procedure ADPD metadata. Each SCHR programming element references programming description SCHD metadata and the SCHD metadata may include a reference to filter description FLTD metadata. The content description MPD metadata may include one or more ISGD metadata references for description of an initialization segment.

The BAT metadata relating to a service may also include an identifier of the mobile or wireless network giving access to the service, and possibly geographical location data of the network if it is present only locally, for example in a city, a city or a city. city district or building. In this way, if the user is near the network, he can be informed that he can have access to a service by going to a specific place.

Fig. 5 shows steps S21 through S40 of a method of accessing a content delivery service, required by a mobile terminal UM, according to one embodiment. The service concerned provides access to a stream transmitted in real time, or in deferred time as a file to download or content accessible in continuous mode. It can also be an RSS 2.0 or Atom feed. The steps S21 to S24 which are executed successively, correspond to the steps S1 to S4. In step S21, the APP application issues an access request to an SVC service to obtain a particular content, the request containing MURI data to identify the requested service.

In steps S22 and S23, this request is transmitted to the BMS server via the MBMC module. In step S24, the SANF advertisement function of the BMS server receives this request and searches for the service identifier SVC in the list of services excluded from the broadcasting mode and in the metadata base MB of the services in progress or likely to be transmitted in broadcast mode by the BMS server. Several services for accessing the same content can be implemented to take into account the capabilities of the different mobile terminals that can access the content, each service providing the content in a manner adapted to the capabilities of a given type of terminal. Thus, in step S24, the BMS server can check whether the requested SVC service is available taking into account the capabilities of the UM terminal and the desired language data contained in the MURI data. Steps S13 to S16 can be performed if the requested SVC service is excluded from the broadcast mode or if it is not available depending on the capabilities of the terminal, or if it is not available during the time slot specified in the MURI data, and / or in the region of the MNT network where the terminal is located. Steps S25 to S28 are executed if the service corresponding to the SVC service identifier is not excluded from the broadcast mode.

If the service corresponding to the SVC service identifier can be accessed in broadcast mode, but does not appear in the MB database, steps S25 to S28 are executed, otherwise step S40 is executed. In step S25, the BMS server (for example the SANF advertisement function of the BMS server) stores in an MB database that the terminal UM has requested access to the SVC service. In step S26, the server BMS transmits to the terminal UM a response message RetL indicating that the requested service SVC is not currently accessible in broadcast mode, but can be later, especially if a sufficient number user terminals request access to the SVC service. The RetL message may mention a waiting time after which the terminal UM may reissue the request issued in step S21. This message is received by the MBMC module of the terminal UM, then retransmitted to the DSHC module in step S27, and finally transmitted to the APP application in step S28. After step S28, the user of the terminal UM can then decide to wait for the SVC service to be accessible in broadcast mode, or else decide to access the SVC service in unicast mode by executing step S16 (FIG. 3). .

The RetL message can also indicate whether the UM terminal should provide consumption reports of the requested service. If the user of the terminal UM decides to access the service SVC without waiting for the time specified in the message RetL, that is to say in unicast mode, the terminal can provide consumption reports of the service according to what is indicated in the RetL message and the ADPD data of the service metadata. Thus, ADPD data can specify in particular which information should be included in the consumption reports, and at which address and at which times these reports should be transmitted.

In parallel with the steps S21 to S28, the BMS server counts (step S25) the service requests of the users received in the step S23 and executes the steps S29 to S38. In particular, the SANF function counts the number of UM terminals that have requested access to the same service for providing the same content for each location information (in the MURI data) received from the terminals. In step S29, the BMC server determines whether a service is requested by a sufficient number of terminals to justify giving access to the service in broadcast mode. For this purpose, the SANF function of the BMS server compares this number of terminals with a threshold value. In step S30, as long as the number of UM terminals accessing the same service does not exceed the threshold value in an area of the MNT network, step S29 is executed again. Otherwise steps S31 to S38 are executed. In step S31, the SANF function of the BMS server sends a request for MTD metadata relating to the SVC service for which transmission in broadcast mode is justified. In step S32, the metadata request is transmitted by a STF function of the BMS server to the content server CNTS providing the SVC service. In step S32, the BMS server may also request ISGD boot segments of the service. In step S33, the CNTS server receives the metadata request and transmits in response to the BMS server the MTD metadata (SVC) requested for the SVC service. In step S34, an STF of the BMS server receives the metadata and generates unified UMTD metadata from the received MTD metadata. For this purpose, the BMS server defines one or more time slots during which the content will be broadcast in broadcast mode. The UMTD unified metadata is derived from the received MTD metadata by specifying in particular a URL where the service will be accessible in broadcast mode, as well as information relating to broadcast schedules. This metadata is stored in the MB database. From the received MTD metadata, the server can check the size of the content corresponding to the service. In step S35, the UMTD metadata is transmitted to the SANF server function of the BMS server. In the case where the requested service SVC is a service for downloading a file, the BMS server can generate itself the metadata corresponding to the service. In step S36, the SANF function updates the MB database containing the service access metadata that can be transmitted in broadcast mode, by entering the received UMTD metadata and the received ISGD boot segments. In parallel with step S36, the STF function sends the CNTS server a CNT content request corresponding to the SVC service. In step S38, the CNTS server transmits the requested CNT content (SVC) to the BMS server. The BMS server locally stores the CNT content to make it available to UM terminals located in a service area of the BMS server in the mobile network MNT. In step S39 which is identical to step S23, the MBMC module again requests the MTD metadata of the SVC service. This step may be executed following step S26 after a waiting time specified in the RetL message. In step S40 following step S39, the UMTD metadata that is now available in the MB database managed by the SANF, is transmitted from the BMS server to the MBMC module of the terminal UM, in response to the request sent to step S39. The UM terminal thus has metadata allowing it to access the SVC service in broadcast mode, as soon as it is broadcast in this mode.

It should be noted that the SVC service may be transmitted in broadcast mode before the schedule schedule specified in the RetL message. In this case, if the UM terminal already accesses the SVC service in unicast mode, it can then switch to broadcast mode in the conventional manner, transparent to the user. At the time announced in the transmission MTD metadata of the content corresponding to the service in broadcast mode, the UM terminal can also trigger access to the service itself in this mode.

FIG. 6 represents steps S41 to S47 of a method of accessing a service for providing content required by a mobile terminal UM in broadcast mode, according to another embodiment. Upon receiving the metadata for the SVC service in step S40, the terminal UM (the application function) controls the MBMC module to activate a FLUTE session for the SVC service. The MBMC module then waits for segments of the content corresponding to the service. In step S41, at the time indicated in the SVC service MTD metadata scheduling data, the BMS server transmits the CNT content corresponding to the SVC service in a FLUTE session as segments. In step S42, the MBMC module receives these segments which are stored for example in a cache memory by the LFIPC module of the terminal UM. In step S43, the LHPC module notifies the APP application that the requested service is accessible in broadcast mode. The APP application of the terminal UM may signal the receipt of this notification to the user of the terminal. In step S44, the user commands the terminal to use the received CNT content, for example by displaying it on a screen of the terminal (in the case of an image, a video content, a a text or multimedia file), or by broadcasting it through loudspeakers (in the case of video or audio content), or by performing it (in the case of an application or program of installing an application).

It should be noted that steps S29, S30 can be executed continuously when the user terminals access services, particularly in unicast mode. Thus, in step S29, the BMS server counts the number of UM terminals accessing the same service for providing the same content in unicast mode, and determines whether a service is requested by a sufficient number of terminals to justify giving access to the service in broadcast mode. If this is the case, steps S31 to S38 are executed. When a service is made available to the terminals in broadcast mode, the terminals accessing the service in unicast mode may be notified of the provision of the service in broadcast mode. The UM terminals can then access the service in broadcast mode by requesting the corresponding UMTD metadata (step S40), and switch from the unicast mode to the broadcast mode at the time when the service is available in this mode.

Steps S29 and S30 can also be executed to process service consumption notifications transmitted by the UM user terminals in the area covered by the BMS server, the consumption notifications being processed to evaluate the number of terminals accessing a service. in unicast or broadcast mode. In particular, the consumer notifications issued by the user terminals enable the BMS server to determine when a user terminal is accessing or no longer accessing a service, whether in unicast mode or in broadcast mode. The BMS server can thus also make the decision to stop the transmission of content in broadcast mode when the number of user terminals accessing the content is insufficient to justify the broadcast mode. Each user terminal may regularly send a notification of use of a service and / or issue such a notification when it opens and closes access to a service. In step S40, the BMS server can transmit to the terminal UM not the MTD metadata of the service requested in step S21, but simply a URL where the metadata are available. This URL can be determined by the BMS server from the service MTD metadata obtained in step S33. This URL may specify a service identifier, a file name in the case of a file download service, and schedule information of the service, such as start and end times of the content broadcast. corresponding to the service in broadcast mode. The URL address thus transmitted may allow the terminal to receive the service metadata transmitted in broadcast mode.

In the case where the MURI data references part of the content corresponding to the requested SVC service, the BMS server also checks in step S4, S24, whether the requested part of the content is or will be available in broadcast mode. During the step S11, only the requested part of the content can be downloaded by the terminal UM.

An RSS or Atom feed is in the form of a list of elements, each element referencing a content that can be transmitted in unicast or broadcast mode. Thus, step S24 is executed for each element of an RSS or Atom feed, this step being followed by steps S13 to S16 if the content can not be transmitted in broadcast mode, steps S39 to S47 if the content is transmitted. in this mode, and steps S25 to S28 if the contents can in the near future be transmitted in this mode.

It will be apparent to those skilled in the art that the present invention is capable of various alternative embodiments and various applications. In particular, the invention is not limited to the combination of a storage operation by the BMS broadcast server of the metadata request (step S25), and a transmission operation of the RetL notification indicating that the requested service may be available later (steps S26 to S28). Indeed, the terminal UM, in particular the MBMC module, can emit for example periodically the metadata request for access to the service in broadcast mode (steps S23, S39) without needing to receive the RetL notification, and the BMS server. can determine that the number of terminals having requested a service is sufficient to transmit it in broadcast mode from service consumption notifications transmitted by the user terminals accessing a service in unicast mode.

Claims (15)

A method for accessing a content delivery service (SVC), in real time or delayed, accessible on a content server, the method being implemented in a user terminal (UM) connected to a mobile network or wireless (DTM), and comprising the steps of: obtaining an access address to a service, transmitting to a service broadcast server (BMS) a metadata request containing a service access address ( SVC) accessible in unicast mode, and if the service is available in broadcast mode, receive service metadata (MTD) containing service access address data in broadcast mode and broadcast schedule data. and receiving the content corresponding to the service in broadcast mode at a time consistent with the broadcast schedule data. 2. Method according to claim 1, comprising a step of reception by the user terminal (UM) of a notification (RetL) indicating that the requested service (SVC) may be available in broadcast mode at the end of a the timeout period specified in the notification, if the service may become available in broadcast mode. 3. Method according to claim 2, comprising a step of programming the transmission to the broadcast server (BMS) of a new service access metadata request, taking into account the waiting time received in the notification (RetL ). 4. Computer program product directly loadable in an internal memory of a terminal and comprising portions of code that when executed by the terminal configure the terminal to implement the steps of the method according to one of claims 1 at 3. A method for providing a content delivery service (SVC), real-time or delayed, accessible on a content server, implemented by a broadcast server (BMS) via a mobile network or wireless (MNT), the method comprising the steps of: receiving from a user terminal a metadata request containing a service access address (SVC) accessible in unicast mode, determining whether the service is available in broadcast mode, and if the service is available in broadcast mode, transmitting to the user terminal service-related metadata (MTD) containing service access address data in broadcast mode and schedule data of broadcast, and transmit in broadcast mode content corresponding to the service at a time consistent with the broadcast schedule data. 6. The method of claim 5, including a step of transmission by the broadcast server to the user terminal of a notification (RetL) indicating that the requested service may be available in broadcast mode after a period of time. specified in the notification, if the service may become available in broadcast mode, The method of claim 6, including a step of storing by the broadcast server (BMS) that the service (SVC) has been requested from a mobile network area (MNT) defined by a location data item contained in the metadata request, in relation to the location data and service identifiers. 8. Method according to one of claims 5 to 7, comprising the steps of: counting by the broadcast server (BMS) a number of user terminals (UM) having issued a request for access to the service (SVC) from the network area defined by the location data, and when the number of user terminals having issued a service access request in the area of the mobile network exceeds a threshold value, set by the server of broadcasting the broadcast of the service in broadcast mode to a broadcast schedule. 9. Method according to one of claims 5 to 8, wherein the broadcasting of the service in broadcast mode comprises steps of: download and store by the broadcast server (BMS) metadata (MTD) relating to the service, set to by the broadcast server the metadata relating to the service to give the service a new access address corresponding to the broadcast server, and to mention broadcast times of the service in broadcast mode, download by the broadcast server the content ( CNT) provided by the service from a content server (CNTS) identified in the downloaded metadata, and locally storing the content for transmission in broadcast mode within a time specified by the broadcast schedule data. 10. Method according to one of claims 1 to 9, wherein the service (SVC) belongs to a group of services comprising: access services to content transmitted in real time, content delivery services transmitted in mode continuous, file download services, and services providing RSS or Atom feeds. The method according to one of claims 1 to 10, wherein the metadata request comprises at least one of the following data: data relating to the capabilities of the user terminal (UM), a language desired for the provision of the service (SVC), a waiting time or a time slot of a user of the terminal to access the service, location data of the user terminal, a start date of content to be transmitted in the case where the service provides an RSS or Atom feed, and a reference to some of the content provided by the service, expected by the user of the terminal. The method according to one of claims 1 to 11, wherein the metadata (MTD) comprises identification data of a mobile or wireless network (MNT) in which the service will be provided in broadcast mode, and optionally, network location data. 13. Computer program product directly loadable in an internal memory of a server and comprising portions of code that when executed by the server configure the server to implement the steps of the method according to one of claims 5 at 12. Broadcast server (BMS) configured to implement the method according to one of claims 5 to 13. 15. User terminal configured to implement the method according to one of claims 1 to 3.