Patent Description:
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings that form a part of this document: Copyright Intel, Inc. , All Rights Reserved.

Multimedia Broadcast Multicast Services (MBMS) is a point-to-multipoint system utilized on cellular networks operating in accordance with one of the cellular standards promulgated by the Third Generation Partnership Project (3GPP). It is designed for efficient delivery of popular content to many receivers based on broadcast and multicast techniques and was first introduced in release six of the 3GPP Universal Mobile Telecommunications System (UMTS) specification as an optional feature, and was further optimized in the later 3GPP releases based on several enhancements such as multicast broadcast single frequency network (MBSFN) functionality. At the service layer, MBMS also defines delivery protocols for both streaming of multimedia content and reliable download of files. MBMS has been adopted as the enhanced MBMS (eMBMS) mode in 3GPP-based Long Term Evolution (LTE) standards development corresponding to 3GPP releases eight and onwards.

D1 describes the usage of IMS protocols to initiate and control Packet Switch Streaming and Multimedia Broadcast and Multicast Service streaming and Download User Services based applications, including methods to switch MBMS streaming to PSS streaming and vice versa.

Unlike unicast delivery, MBMS-based transmissions do not benefit from data recovery mechanisms based on retransmission of erroneously received data blocks, such as those based on automatic repeat request (ARQ) and hybrid automatic repeat request (HARQ) based on acknowledgement (ACK) and negative acknowledgment (NACK) signaling from the user equipment (UE) and consequently during data transmission to the user equipment (UE), data may be lost or corrupted. To increase the reliability of MBMS transmissions, application-layer forward error correction (AL-FEC) codes are used in addition to the traditional channel coding in order to (at least partially) recover packet erasures, with AL-FEC examples including Reed Solomon codes, Fountain codes and Raptor codes.

The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services. IMS promises to enable rich blended services such as voice, video, data, and multimedia applications within a converged IP platform. Such services would simplify the communication and entertainment experience of users and create a value-based market for service providers. IMS intends to enable the creation of innovative personalized applications and the faster deployment of these applications. The IP multimedia core network subsystem is a collection of different core network and access network functions, linked by standardized interfaces, which grouped form one IMS administrative network. To ease the integration with the Internet, IMS uses the broadly adopted Session Initiation Protocol (SIP). Several roles of Session Initiation Protocol (SIP) servers or proxies, collectively called Call Session Control Function (CSCF), are used to process SIP signaling packets in the IMS. In 3GPP, IMS was first introduced during Release <NUM> into UMTS within its core network, and IMS support was further enhanced during the LTE standards development. It consists of specifications on the essential requirements and signaling for controlling multimedia sessions, including those for the protocols and procedures for establishing, managing and tearing down sessions for MBMS-based streaming and download services. Fixed access (e.g., Digital Subscriber Line (DSL), cable modems, Ethernet), mobile access, e.g., WCDMA, CDMA2000, GSM, GPRS, and wireless access, e.g. WLAN, WiMAX, are all supported in the IMS framework. Other phone systems like plain old telephone service (POTS-the old analogue telephones), H. <NUM> and non IMS-compatible VoIP systems, are supported through gateway.

The file download delivery service over MBMS provides a file-repair feature that enables UEs that have not received enough symbols to properly decode a file to request additional symbols. This allows the network to deliver specific symbols to particular UEs over unicast bearers and not load broadcast bearers in the cases where the aggregate load needed to deliver symbols to particular UEs over unicast is moderate.

The file-repair feature relies on file-repair servers in the network to service the repair requests of UEs. The current architecture requires dedicated servers that are specially designed to service the UE requests. This approach can be costly and does not scale well with large deployments.

An enhancement to the current file-repair feature that enables the use of conventional HyperText Transfer Protocol (HTTP) web servers <NUM> to handle file-repair requests rather than rely on the broadcast multicast service center (BMSC) is shown in <FIG>. The MBMS broadcast service provided by the BMSC <NUM> transmits a file or other media <NUM> to a user equipment (UE) over a cellular network <NUM>. For recovery of source symbols, the UE <NUM> may contact an HTTP server <NUM> using standardized HTTP requests/responses. This approach takes advantage of the existing, scalable, standardized and widely- deployed web-based infrastructure for the repair service. In some examples, the system may realize a good performance-complexity tradeoff in terms of server complexity, scalability, caching efficiency, and HTTP request overhead perspectives by intelligently performing repair symbol transmission over the MBMS (repair symbols are redundant symbols sent to the UE that allow the UE to repair the file without actually retransmitting the missing pieces of the file - e.g., symbols produced by an AL-FEC scheme) while allowing for recovery of source symbols by a limited number of HTTP requests. The operator does not have to use specialized file-repair servers and can use the same web servers used to deliver content. Therefore, the BMSC is no longer needed for file repair procedures which are now handled by HTTP servers. The HTTP servers only have to store the content and do not have to spend resources for FEC coding which will allow the system to achieve good cache and network efficiencies with low complexity which will allow the operator to leverage the scalability, reliability, and readily available content provided by using conventional web-servers in the network or Internet.

Disclosed in some examples are systems, methods, and machine-readable media which realize an MBMS file repair procedure over Internet Protocol Multimedia Subsystem (IMS)-based MBMS services. This involves modifications to the IMS-based MBMS download delivery method, in particular, to the associated recovery procedures following the initial broadcast of the file, e.g., after the File Delivery over Unidirectional Transport (FLUTE) session is received by the UE over MBMS bearers from the BMSC which broadcasted the file. If a correction is needed (i.e., the UE is unable to decode the file based on the correctly-received set of source and repair symbols), the UE disconnects from the BMSC and establishes a session switch to an HTTP web server in order to retrieve the missing components of the file using HTTP (rather than remaining connected to the BMSC for MBMS file repair service, which is currently the procedure).

<FIG> shows a number of functional blocks for the IMS-based MBMS service architecture as defined in 3GPP Technical Specification (TS) <NUM> (this diagram is based on a similar diagram in TS <NUM> and may also show additional IMS-based service functions that may not be relevant for an IMS-based MBMS service, such as the functional blocks related to packet-switched streaming (PSS)). IMS Core Network Subsystem <NUM> (IM CN Subsystem) may be a subsystem at least partially defined in 3GPP Technical Specification (TS) <NUM> and which supports user registration and authentication, mobility and roaming, control of multimedia sessions, QoS control, policy control, charging, and interworking with circuit switched networks. UE <NUM> contains the IMS-based MBMS client functionality, which performs service discovery and selection, handles service initiation, modification and termination, receives, and presents the content to the user. The Service Control Function (SCF) <NUM> provides service logic and functions required to support execution of such logic. It does service authorization during session initiation and session modification, which includes checking the MBMS user's service subscription in order to allow or deny access to the service and it selects the relevant MBMS media functions. For HTTP-based delivery, the SCF acts as a proxy or back-to-back user agent (B2BUA). For MBMS, the SCF acts as a terminating user agent (UA). HTTP/SIP adapter <NUM> correlates SIP sessions with HTTP incoming requests. HTTP server <NUM> is described in 3GPP TS <NUM>, and may provide source symbols upon request for file repairs using standard HTTP protocols. UPF <NUM> handles all broadcast multicast service center (BMSC) user plane sub-functions (UPF). <FIG> illustrates the BMSC sub-functional architecture and associated interfaces between the UE and BMSC, according to 3GPP TS <NUM>. Policy and Charging Rules Function (PCRF) <NUM> as specified in 3GPP TS <NUM>, controls the charging and the establishment of resources in the Radio Access Network (RAN) and Packet Switched (PS) core network. Service Selection Function (SSF) <NUM> provides a list of available user services, including HTTP-based Dynamic Adaptive Streaming over HTTP (DASH), MBMS User Services, and relevant user service description information. The list can also be personalized to the client's identity.

<FIG> is intended to be an example of a functional schematic of a particular example IMS-based MBMS system (while also showing the UE, the Evolved Packet Core (EPC), and the radio access network or RAN). One skilled in the art with the benefit of Applicants' disclosure will realize that various combinations and permutations of functional groupings may be used to implement the various examples herein disclosed. For example, multiple components may be executed in the same location and/or on the same physical hardware.

Turning now to <FIG>, a block diagram <NUM> of a BMSC is shown. User Service Discovery and Announcement <NUM> provides announcements to UEs through a response to an HTTP request sent by the UE (facilitated by the interactive announcement functions <NUM>), through service announcements using MBMS bearers (facilitated through the MBMS Delivery functions <NUM> of the Session and Transmit Function <NUM>) or through Push announcements using MBMS Push capabilities. These announcements contain the necessary information for a UE to receive the announced services. The announcements may include service identifiers, IP multi-cast addresses, and media descriptions.

The session and transmission function <NUM> includes all content transmission related functions. MBMS delivery functions <NUM> deliver files (via the MBMS download services) or streams (via the MBMS streaming service). The session and transmission function <NUM> communicates with the UE over UDP and real-time transmission protocol (RTP) as well as File Delivery over Unidirectional Transport (FLUTE). Associated delivery functions <NUM> include auxiliary procedures such as file repair procedures.

Key Management Function <NUM> includes key request functions <NUM> and key distribution functions <NUM> which handle authentication and key distribution to the UE. Content Provider/Multicast Broadcast Source <NUM> is a content provider's network that provides the content which is broadcast or multicast over the MBMS network.

Turning now to <FIG>, an example message sequence chart diagramming an MBMS file repair using HTTP is shown. At operation <NUM>, the UE generates an initial SIP INVITE message and sends it to the IM CN Subsystem, indicating the chosen MBMS Download Service. A SDP offer may be included in the SIP INVITE message. The IM CN Subsystem forwards the SIP INVITE message and SDP offer to the SCF. The Request-URI in the SIP INVITE request may be the well known PSI (Public Service Identifier) of the MBMS Download Service, the "to" header may contain the same URI as in the Request-URI, and the "from" header may indicate the public user identity of the user. An SDP offer may be included in the request and may be done in accordance with the parameters received during UE service selection procedure and with media capabilities and required bandwidth available for the MBMS download service.

At operation <NUM>, upon receipt of a SIP INVITE request, the SCF examines the SDP parameters in the SDP offer and performs service authorization procedures to check the service rights of the requested MBMS download service according to the user subscription information. If the user is authorized, the SCF may answer with a SIP <NUM> OK including the SDP answer. The SDP answer may contain the fdt_address:uri to indicate the address of the File Delivery Table (FDT) and the repair-server-address:uri to indicate the address of the repair server.

At operation <NUM>, upon receipt of the SIP response, the UE may examine the FLUTE session parameters in the received SDP, and receive the MBMS download data accordingly. In case the FDT is unavailable, the UE may get the FDT according to fdt_address attribute in the SDP Answer. The FDT contains content description information for the files delivered in the FLUTE session.

In case of incomplete download, the UE may execute the file repair procedures towards the repair server indicated by repair-server-address attribute in the SDP Answer from the SCF. In order to switch from MBMS download to HTTP-based delivery of the repair service from the web server, a session initiation protocol (SIP) Re-INVITE is issued by the UE and sent to the IM CN subsystem at operation <NUM>. A session description protocol (SDP) offer and Request-URI pointed to the repair server may be included in the SIP Re-INVITE message to activate the file repair. The IM CN subsystem may forward the SIP Re-INVITE message to the SCF. The Request-URI is related to the HTTP-based file repair session from the web server that the user wishes to activate. The Request-URI may be composed of a user and domain part as defined as follows: The user part contains the content identifier, retrieved from user service description information from SSF. The content identifier may be retrieved from service selection information. The domain part is the Service Provider domain name, obtained from SSF. The 'to' header may contain the repair server address URI. The 'from' header may indicate the public user identity of the user. The content identifier can be retrieved from the service selection information. An SDP offer may be included in the Re-INVITE request, in accordance with media capabilities and policies available for the file repair session and with the parameters received from the SSF during service selection procedure or during the procedure for retrieving missing parameters by SIP OPTIONS.

At operation <NUM>, responsive to receiving the SIP modification request, the SCF may determine if the program currently broadcasted has MBMS/FLUTE to HTTP switching support for file repair purposes. If MBMS to HTTP switching is not available for the UE, the session modification is rejected and the old MBMS session (along with the previous reserved resources) is maintained. If MBMS to HTTP switching is available for the UE, the SCF acting as a B2BUA, may check the user rights for the requested content upon reception of the SIP Re-INVITE message from the UE, identify that the request is for MBMS file repair procedures, select an HTTP/SIP adapter and forward the SIP INVITE request to the HTTP/SIP adapter which is in charge of the file repair service by changing the "Request-URI" accordingly. When receiving a <NUM> or <NUM> response from the HTTP/SIP adapter, the SCF may not forward this message to the UE.

If the Request-URI contains a content identifier in the user part and a domain name in the domain part, the SCF may select a suitable HTTP/SIP adapter and generate a SIP INVITE request to the selected HTTP/SIP adapter. The 'to' header of the SIP INVITE request may contain the same content identifier as in the Request-URI of the SIP modification request received from the UE. At operation <NUM>, the SCF may send the SIP INVITE request to the HTTP/SIP Adapter with the SDP parameters and may tear down the FLUTE-based MBMS download session between the BMSC. UPF and UE.

Upon reception of the MBMS file repair activation request, the HTTP/SIP adapter may examine the content identifier present in the user-part of the 'to' header and the media parameters in the SDP and select an HTTP Server according to the Request URI. The HTTP/SIP adapter sends an HTTP POST message to the HTTP server at operation <NUM>, including the IP address of the UE. The HTTP/SIP adapter may decide to redirect the request to another HTTP/SIP adapter server. In this case the HTTP/SIP adapter may return a <NUM> response if the content is not managed by this HTTP/SIP adapter or a <NUM> response for any other reasons (e.g. load balancing). The redirecting HTTP/SIP adapter may indicate one or more destination HTTP/SIP adapter addresses in the contact header.

At operation <NUM>, upon reception of the HTTP POST message received from the HTTP/SIP adapter, the HTTP server may answer to the HTTP/SIP adapter with an HTTP <NUM> OK response. The HTTP/SIP adapter returns the SIP <NUM> OK message to the SCF at operation <NUM>, including the SDP answer. The SDP answer may describe the MBMS file repair session including a download URL of the requested content file. The differences with the SDP answer defined for streaming is the absence of media line corresponding to the control protocol (Real Time Streaming Protocol (RTSP)), the indication of TCP transport and HTTP-based download method instead of streaming, and the indication of an HTTP URL instead of an RTSP URI. If the content that the user has selected cannot be found, the HTTP/SIP adapter may reply with an appropriate SIP error code (e.g., <NUM> Not Found) response.

At operation <NUM>, the SCF may forward the SIP <NUM> OK to the IM CN subsystem. The IM CN subsystem may forward the SIP <NUM> OK to the UE at operation <NUM>.

At operation <NUM>, after receiving the SIP <NUM> OK, the UE may leave the multicast channel and start the MBMS file repair by sending an HTTP GET (or HTTP partial GET for byte range requests) request to the URL obtained from the SIP <NUM> OK message. The HTTP server may deliver the content file in the HTTP response to the UE at operation <NUM>.

<FIG> shows a flowchart of an IMS-based MBMS file repair method utilizing an HTTP server according to some examples. At operation <NUM> the UE establishes a session with an IMS network to receive an MBMS service. In some examples the UE may send a SIP invite with an SDP offer message to an IM CN subsystem. The IM CN subsystem may then forward the SIP invite with the SDP offer to the SCF. The SCF may then send a SIP OK message to the IM CN subsystem, the IM CN Subsystem may then forward the SIP OK to the UE, thus establishing the session with the IMS network to receive the MBMS service.

At operation <NUM>, the UE then receives the media over the MBMS bearers. In some examples, the UE communicates with the network (and receives the media) through a Long Term Evolution wireless network consistent with a 3rd Generation Partnership Project (3GPP) family of standards. In other examples, the UE communicates with the network (and receives the media) through a Universal Mobile Telecommunications System (UMTS) wireless network consistent with a 3GPP family of standards. In still other examples, other types of wireless networks may be used.

At operation <NUM>, the UE determines that one or more of the encoded symbols cannot be properly decoded and hence file repair procedures are required. At operation <NUM>, in order to have the symbols re-sent (and thus repair the media), the UE may re-establish the session with the IMS network requesting HTTP-based file repair over unicast. In some examples, the UE may do this by sending a SIP Re-Invite request with an SDP offer to an IM CN subsystem. The IM CN subsystem may forward this to a SCF component. The SCF component may then setup a SIP to HTTP adapter which may contact a designated HTTP repair server. If the HTTP repair server replies affirmatively, the IMS network replies to the mobile that the session is properly setup.

At operation <NUM> the UE then contacts the HTTP server and re-downloads the proper symbols using the information in the reply message sent from the IMS network.

Turning now to <FIG>, a flowchart of a file repair method utilizing an HTTP server from an IMS network perspective according to some examples is shown. At <NUM> the SCF receives a repair request from a UE. The repair request may take the form of a session re-establishment message such as a SIP re-invite with an SDP offer. The SCF determines at operation <NUM> if the repair operation may be done using HTTP. If the repair operation may be done using HTTP, the request is forwarded to an HTTP to SIP adapter at operation <NUM>. At operation <NUM>, the HTTP to SIP adapter may contact the HTTP Server to setup the file repair by sending an HTTP post message. The reply message from the HTTP server is then translated into a SIP reply message by the HTTP to SIP adapter and forwarded back to the SCF. At operation <NUM>, the UE's FLUTE session is torn down, and at <NUM> the SCF forwards the reply message from the HTTP/SIP adapter to the UE. If the reply message indicates a successful transition to an HTTP session, then the UE may download the file over HTTP, in some examples by using the information (e.g., a Uniform Resource Locator (URL)) included in the reply.

In some examples, the term IMS network is used for convenience and generally refers to any component used to deliver IMS-based MBMS services and may include certain elements of the core network (e.g., an evolved packet core network - EPC).

<FIG> shows an example of a block diagram of a user equipment device (UE) <NUM> according to some examples of the present disclosure. UE <NUM> may include (in addition to other modules and/or functionality) an input and/or output module <NUM> which receives input from the user, for example, through a touch sensitive display interface, a keyboard, a track ball, a mouse, or the like. Input and/or output module <NUM> also displays output to the user by controlling one or more graphical displays, an audio reproduction device (e.g., a speaker), or the like. Input and/or output module <NUM> may display media, files, or other data received from the IMS network and may receive input from the user of the UE <NUM> on which content available at the IMS network to receive.

UE <NUM> may have a TX/RX module <NUM> which may implement the wireless physical layer functions including modulation, coding, transmission, reception, demodulation and unencoding. The UE may also have a control module <NUM> which may implement other layers of the wireless protocol stack (e.g., Layer <NUM> and Layer <NUM>). For example, the control module <NUM> may register for, de-register for, and receive data from the IMS network. Control module <NUM> may also control the file repair procedures, including contacting an HTTP server to repair the media or files. The control module <NUM> may also respond to user input from the input/output module <NUM> and cause output to be sent to a display or other output device through input/output module <NUM>.

<FIG> illustrates a block diagram of an example machine <NUM> upon which any one or more of the techniques (e.g., methodologies) discussed herein can be performed. In alternative embodiments, the machine <NUM> can operate as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine <NUM> can operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine <NUM> can act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine <NUM> can be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. For example, an eNodeB, a UE, or other components of an LTE system may be, or include components of, machine <NUM>. For example, the functions of the machine <NUM> can be distributed across multiple other machines in a network.

Examples, as described herein, can include, or can operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities capable of performing specified operations and can be configured or arranged in a certain manner. In an example, circuits can be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors can be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside (<NUM>) on a non-transitory machine-readable medium or (<NUM>) in a transmission signal.

For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as one or more modules that can change over time. Software can accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

Machine (e.g., computer system) <NUM> can include a hardware processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory <NUM> and a static memory <NUM>, some or all of which can communicate with each other via a bus <NUM>. The machine <NUM> can further include a display unit <NUM>, an alphanumeric input device <NUM> (e.g., a keyboard), a user interface (UI) control device <NUM>, and/or other input devices. In an example, the display unit <NUM> and UI control device <NUM> can be a touch screen display. The machine <NUM> can additionally include a storage device (e.g., drive unit) <NUM>, a signal generation device <NUM> (e.g., a speaker), and a network interface device <NUM>.

The storage device <NUM> can include a machine-readable medium <NUM> on which is stored one or more sets of data structures or instructions <NUM> (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions <NUM> can also reside, completely or at least partially, within the main memory <NUM>, within static memory <NUM>, or within the hardware processor <NUM> during execution thereof by the machine <NUM>. In an example, one or any combination of the hardware processor <NUM>, the main memory <NUM>, the static memory <NUM>, or the storage device <NUM> can constitute machine readable media.

While the machine-readable medium <NUM> is illustrated as a single medium, the term "machine readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that configured or arranged to store the one or more instructions <NUM>.

The term "machine-readable medium" can include any tangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine <NUM> and that cause the machine <NUM> to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine-readable medium examples can include solid-state memories, and optical and magnetic media. Specific examples of machine-readable media can include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD- ROM disks.

The instructions <NUM> can further be transmitted or received over a communications network <NUM> using a transmission medium via the network interface device <NUM>. Network interface device <NUM> may connect the machine <NUM> to a network of other machines in order to communicate with the other machines in the network by utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks can include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) <NUM> family of standards known as Wi-Fi®, IEEE <NUM> family of standards known as WiMax®), peer-to-peer (P2P) networks, among others. In an example, the network interface device <NUM> can include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network <NUM>. In an example, the network interface device <NUM> can include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine <NUM>, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

The drawings show, by way of illustration, specific embodiments which can be practiced.

In the appended claims, the terms "including" and "in which" are used as the plain- English equivalents of the respective terms "comprising" and "wherein. " Also, in the following claims, the terms "including" and "comprising" are openended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim.

Claim 1:
A method for operating a cellular network (<NUM>), the method comprising:
at a core network element of the cellular network:
causing a radio access network, RAN, to transmit, to a User Equipment device, UE (<NUM>), a file via a Multimedia Broadcast Multicast Service ,MBMS download session;
receiving, from the UE, a Session Initiation Protocol, SIP, re-invite requesting initiation of a file repair of the file; and
in response to the SIP re-invite requesting initiation of the file repair:
selecting a HyperText Transfer Protocol to SIP, HTTP/SIP, adapter and generating a SIP INVITE request to the selected HTTP/SIP adapter, wherein a 'to' header of the SIP INVITE request includes a same Request- Uniform Resource Identifier (URI) of the SIP re-invite request; and
sending the SIP INVITE request to the selected HTTP/SIP Adapter; and tearing down the MBMS download session responsive to the SIP re-invite request.