WO2019224574A1

WO2019224574A1 - Ims-based streaming framework

Info

Publication number: WO2019224574A1
Application number: PCT/IB2018/053584
Authority: WO
Inventors: George Foti
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-05-21
Filing date: 2018-05-21
Publication date: 2019-11-28

Abstract

Methods and systems for providing Internet Protocol (IP) Multimedia Subsystem (IMS)-based streaming are provided. According to one aspect of the present disclosure, a method for IMS-based streaming is performed at a Streaming Proxy Control Plane (SPCP) within an IMS that operates as a conduit for streaming data, e.g., via a Real Time Streaming Protocol (RTSP) session or a Hypertext Transfer Protocol (HTTP) session, between a User Equipment (UE) and a Streaming Application Server (SAS). In some embodiments, the UE communicates with the SPCP using Session Initiation Protocol (SIP) signaling to set up the streaming session. In some embodiments, the SPCP operates as a streaming proxy between the UE and the SAS.

Description

IMS-BASED STREAMING FRAMEWORK

Technical Field

[0001] The present disclosure relates to Internet Protocol (IP) Multimedia Subsystem (IMS) framework for providing IMS-based Real Time Streaming Protocol (RTSP) or Hyper Text Transport Protocol (HTTP) streaming.

Background

[0002] Network operators provide a medium for streaming traffic, e.g., provided by Over-the-Top (OTT) content providers, but can’t generate revenue from any streaming service due to the need for specialized networks that are expensive to set up and maintain. The current Internet Protocol (IP) Multimedia Subsystem (IMS) network does not support streaming, being optimized for Voice over Long Term Evolution (VoLTE) messaging and for providing video within the context of an ongoing voice session.

[0003] Operators who want to offer content streaming to its customer base are forced either to create a separate network for streaming, such as the case for service providers offering IPTV, or to become a transport pipe for OTT services such as Netflix, owning the end user and using the cellular and broadband network for delivering the content to the end user.

Summary

[0004] Solutions are provided herein that enable interconnecting an existing Internet Protocol (IP) Multimedia Subsystem (IMS) network with Over- the-Top (OTT) content providers. The IMS service provider can interwork with OTT content providers and be able to handle all authentication, authorization, and billing for them as an additional source of revenue without requiring these OTT providers to do any adaptation to their servers for their applications and requiring little to no modification of the User Equipments (UEs). In addition, the IMS service provider can offer streaming services to its own users in direct competition.

[0005] According to one aspect of the present disclosure, a method for IMS-based streaming performed at a Streaming Proxy Control Plane (SPCP) within an IMS comprises: receiving, from a registered UE, a Real Time Streaming Protocol (RTSP) request that includes a Uniform Resource Identifier (URI) of a desired streaming content; selecting an RTSP Streaming Application Server (SAS); and sending the RTSP request to the selected RTSP SAS.

[0006] In some embodiements, receiving the RTSP request comprises receiving the request within a first Session Initiation Protocol (SIP) message.

[0007] In some embodiments, the first SIP message comprises a SIP INFO message or a SIP MESSAGE message.

[0008] In some embodiments, selecting the RTSP SAS comprises selecting the RTSP SAS based on at least one of the URI of the desired streaming content and a location of the RTSP SAS relative to the UE.

[0009] In some embodiments, sending the RTSP request to the selected RTSP SAS comprises: extracting, from the RTSP request, RTSP information for forwarding; establishing a first RTSP session between the UE and the SPCP and a second RTSP session between the SPCP and the selected RTSP SAS; and sending the RTSP request to the selected RTSP SAS via the second RTSP session.

[0010] In some embodiments, the method further comprises: receiving, from the selected RTSP SAS, an RTSP response; and sending, to the UE, the RTSP response within a second SIP message.

[0011] In some embodiments, the first or second SIP message comprises a SIP MESSAGE message or a SIP INFO message.

[0012] According to another aspect of the present disclosure, a method for IMS-based streaming performed at a SPCP within an IMS comprises:

establishing a Message Session Relay Protocol (MSRP) session with a registered UE; receiving, from the UE via the MSRP session, a Hypertext Transfer Protocol (HTTP) request that includes a Uniform Resource Locator (URL) of a desired streaming content; selecting an HTTP SAS; and sending the HTTP request to the selected HTTP SAS.

[0013] In some embodiments, establishing the MSRP session comprises establishing the MSRP session in response to receiving, from the UE, a request to establish the MSRP session.

[0014] In some embodiments, receiving the request to establish the MSRP session comprises receiving the request within a SIP message. [0015] In some embodiments, the SIP message comprises a SIP INVITE message.

[0016] In some embodiments, selecting the HTTP SAS comprises selecting the HTTP SAS based on at least one of the URL of the desired streaming content and a location of the HTTP SAS relative to the UE.

[0017] In some embodiments, sending the HTTP request to the selected HTTP SAS comprises: extracting, from the HTTP request, HTTP information for forwarding; establishing a first HTTP session between the UE and the SPCP; establishing a second HTTP session between the SPCP and the selected HTTP SAS; and sending the HTTP request to the selected HTTP SAS via the second HTTP session.

[0018] In some embodiments, the method further comprises: receiving, from the selected HTTP SAS, an HTTP response; and sending, to the UE, the HTTP response via the MSRP session.

[0019] According to another aspect of the present disclosure, a method for IMS-based streaming performed at a SPCP within an IMS comprises:

receiving, from a UE, a request to start a HTTP streaming session, the request including a URL of a desired streaming content; creating an HTTP SPCP URL to be used by the UE for the HTTP streaming session and binding the HTTP SPCP URL to the URL of the desired streaming content; and sending, to the UE, the HTTP SPCP URL.

[0020] In some embodiments, receiving the request to start the HTTP streaming session comprises receiving a SIP message.

[0021] In some embodiments, receiving the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

[0022] In some embodiments, the method further comprises: receiving, from the UE, an HTTP request sent to the HTTP SPCP URL; determining an HTTP SAS; and sending the HTTP request to the determined HTTP SAS.

[0023] In some embodiments, determining the HTTP SAS comprises: upon a determination that an HTTP SAS has already been selected for the UE, using the HTTP SAS that was already selected for the UE; and upon a determination that an HTTP SAS has not yet been selected for the UE:

selecting an HTTP SAS; maintaining an association between a first HTTP session between the SPCP and the UE and a second HTTP session between the SPCP and the selected HTTP SAS; and using the selected HTTP SAS.

[0024] In some embodiments, selecting the HTTP SAS comprises selecting the HTTPS SAS based on at least one of the URL of the desired streaming content and a location of the HTTP SAS relative to the UE.

[0025] In some embodiments, the method further comprises: receiving, from the determined HTTP SAS, an HTTP response; identifying the first HTTP session between the SPCP and the UE; and sending the HTTP response to the UE via the identified first HTTP session.

[0026] According to another aspect of the present disclosure, a method for IMS-based streaming performed at a SPCP within an IMS comprises:

receiving, from a UE, a request to start a HTTP streaming session; sending, to the UE, information for setting the SPCP as a HTTP proxy; receiving, from the UE, an HTTP request that includes a URL of a desired streaming content; determining an HTTP SAS; and proxying the HTTP request to the determined HTTP SAS.

[0027] In some embodiments, receiving the request to start the HTTP streaming session comprises receiving a SIP message.

[0028] In some embodiments, receiving the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

[0029] In some embodiments, sending the information for setting the SPCP as the HTTP proxy comprises sending an SPCP URL.

[0030] In some embodiments, determining the HTTP SAS comprises: upon a determination that an HTTP SAS has already been selected for the UE, using the HTTP SAS that was already selected for the UE; and upon a determination that an HTTP SAS has not yet been selected for the UE, selecting an HTTP SAS and using the selected HTTP SAS.

[0031] In some embodiments, selecting the HTTP SAS comprises selecting the HTTPS SAS based on at least one of the URL of the desired streaming content and a location of the HTTP SAS relative to the UE.

[0032] In some embodiments, the method further comprises: receiving, from the determined HTTP SAS, an HTTP response; and proxying the HTTP response to the UE. [0033] According to another aspect of the present disclosure, a SPCP for providing IMS-based streaming comprises: a network interface; one or more processors; and memory storing instructions executable by the one or more processors, whereby the SPCP is operable to perform any of the methods described herein.

[0034] According to another aspect of the present disclosure, a SPCP for providing IMS-based streaming is adapted to perform any of the method described herein.

[0035] According to another aspect of the present disclosure, a SPCP for providing IMS-based streaming comprises means for performing any of the methods described herein.

[0036] According to another aspect of the present disclosure, a SPCP for providing IMS-based streaming comprises one or more modules operable to perform any of the methods described herein.

[0037] According to another aspect of the present disclosure, a non- transitory computer readable medium stores software instructions that when executed by one or more processors of a SPCP cause the SPCP to perform any of the methods described herein.

[0038] According to another aspect of the present disclosure, a computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to perform any of the methods described herein.

[0039] According to another aspect of the present disclosure, a carrier comprises the computer program above, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0040] According to another aspect of the present disclosure, a method for IMS-based streaming, performed at a UE within an IMS, the method comprising: sending, to a SPCP, a RTSP request that includes a URI of a desired streaming content; receiving, from the SPCP, a RTSP response that identifies a RTSP SAS; and receiving at least a portion of the desired streaming content from the identified RTSP SAS.

[0041] In some embodiments, sending the RTSP request comprises sending the request within a first SIP message. [0042] In some embodiments, the first SIP message comprises a SIP INFO message or a SIP MESSAGE message.

[0043] In some embodiments, receiving the RTSP response comprises receiving the response within a second SIP message.

[0044] In some embodiments, the second SIP message comprises a SIP INFO message or a SIP MESSAGE message.

[0045] According to another aspect of the present disclosure, a method for IMS-based streaming performed at a UE within an IMS comprises:

establishing a MSRP session with a SPCP; sending, to the SPCP via the MSRP session, a HTTP request that includes a URL of a desired streaming content; and receiving, from the SPCP via the MSRP session, a HTTP response comprising at least a portion of the desired streaming content.

[0046] In some embodiments, the MSRP session is established using at least one SIP message.

[0047] In some embodiments, the at least one SIP message comprises a SIP INVITE message.

[0048] According to another aspect of the present disclosure, a method for IMS-based streaming performed at a UE within an IMS comprises: sending, to a SPCP, a request to start a HTTP streaming session, the request including a URL of a desired streaming content; receiving, from the SPCP, an HTTP SPCP URL to be used by the UE for the HTTP streaming session; sending, to the SPCP, an HTTP request sent to the HTTP SPCP URL; and receiving, from the SPCP, an HTTP response comprising at least a portion of the desired streaming content.

[0049] In some embodiments, sending the request to start the HTTP streaming session comprises sending a SIP message.

[0050] In some embodiments, sending the SIP message comprises sending a SIP MESSAGE message or a SIP INFO message.

[0051] In some embodiments, receiving an HTTP SPCP URL comprises receiving the HTTP SPCP URL via a SIP message.

[0052] In some embodiments, receiving the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

[0053] According to another aspect of the present disclosure, a method for IMS-based streaming performed at a UE within an IMS comprises: sending, to a SPCP, a request to start a HTTP streaming session; receiving, from the SPCP, information for setting the SPCP as a HTTP proxy; setting the SPCP as an HTTP proxy using the received information; sending, to the SPCP, an HTTP request that includes a URL of a desired streaming content; and receiving, from the SPCP, an HTTP response comprising at least a portion of the desired streaming content.

[0054] In some embodiments, sending the request to start the HTTP streaming session comprises sending a SIP message.

[0055] In some embodiments, sending the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

[0056] In some embodiments, receiving the information for setting the SPCP as the HTTP proxy comprises receiving an SPCP URL.

[0057] In some embodiments, receiving the information for setting the SPCP as the HTTP proxy comprises receiving a SIP message.

[0058] In some embodiments, receiving the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

[0059] According to another aspect of the present disclosure, a UE for supporting IMS-based streaming comprises: one or more radio transceivers; one or more processors; and memory storing instructions executable by the one or more processors, whereby the UE is operable to perform any of the UE methods described herein.

[0060] According to another aspect of the present disclosure, a UE for supporting IMS-based streaming is adapted to perform any of the UE methods described herein.

[0061] According to another aspect of the present disclosure, a UE for supporting IMS-based streaming comprises means for performing any of the UE methods described herein.

[0062] According to another aspect of the present disclosure, a UE for supporting IMS-based streaming comprises one or more modules operable to perform any of the UE methods described herein.

[0063] According to another aspect of the present disclosure, a non- transitory computer readable medium stores software instructions that, when executed by one or more processors of a UE for supporting IMS-based streaming, cause the UE to perform any of the UE methods described herein. [0064] According to another aspect of the present disclosure, a computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to perform any of the UE methods described herein.

[0065] According to another aspect of the present disclosure, a carrier comprises the computer program above, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

Brief Description of the Drawings

[0066] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0067] Figure 1 A illustrates the operation of an Internet Protocol (IP) Multimedia Subsystem (IMS)-based streaming framework according to some embodiments of the present disclosure, showing Hyper Text Transport Protocol (HTTP) streaming via IMS control nodes;

[0068] Figure 1 B illustrates the operation of an IMS-based streaming framework according to some embodiments of the present disclosure, showing HTTP streaming that bypasses IMS control nodes;

[0069] Figure 2 illustrates an exemplary call flow for User Equipment (UE)- initiated Real-Time Streaming Protocol (RTSP) streaming within an IMS- based streaming framework according to some embodiments of the present disclosure;

[0070] Figure 3 illustrates an exemplary call flow for UE-initiated HTTP streaming through an IMS-based streaming framework according to some embodiments of the present disclosure;

[0071] Figure 4 illustrates an exemplary call flow for UE-initiated direct HTTP streaming that bypasses IMS control nodes within an IMS-based streaming framework according to some embodiments of the present disclosure;

[0072] Figure 5 illustrates an exemplary call flow for UE-initiated proxy HTTP streaming that bypasses IMS control nodes within an IMS-based streaming framework according to some embodiments of the present disclosure;

[0073] Figure 6 illustrates an exemplary call flow for server-initiated HTTP streaming within an IMS-based streaming framework according to some embodiments of the present disclosure;

[0074] Figure 7 illustrates one example of a cellular communications network according to some embodiments of the present disclosure;

[0075] Figure 8 is a schematic block diagram of a radio access node according to some embodiments of the present disclosure;

[0076] Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node of Figure 8 according to some embodiments of the present disclosure;

[0077] Figure 10 is a schematic block diagram of the radio access node of Figure 8 according to some other embodiments of the present disclosure;

[0078] Figure 1 1 is a schematic block diagram of a UE according to some embodiments of the present disclosure;

[0079] Figure 12 is a schematic block diagram of the UE of Figure 1 1 according to some other embodiments of the present disclosure;

[0080] Figure 13 illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some

embodiments of the present disclosure;

[0081] Figure 14 is a generalized block diagram of a host computer communicating via a base station with a UE over a partially wireless connection in accordance with some embodiments of the present disclosure;

[0082] Figure 15 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment of the present disclosure;

[0083] Figure 16 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment of the present disclosure;

[0084] Figure 17 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment on the present disclosure; and [0085] Figure 18 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment of the present disclosure.

Detailed Description

[0086] The present disclosure presents a solution that enables interconnecting an existing Internet Protocol (IP) Multimedia Subsystem (IMS) network with Over-the-Top (OTT) content providers and at the same time enabling an IMS service provider to offer streaming services to its own users in direct competition. The streaming services may use Hyper Text Transport Protocol (HTTP)-based streaming, Real Time Streaming Protocol (RTSP)-based streaming, streaming based on other protocols, or some combination of the above. In some embodiments, the IMS service provider can interwork with OTT content providers and be able to handle all authentication, authorization, and billing for them as an additional source of revenue without requiring these OTT providers to do any adaptation to their servers for their applications. In some embodiments, the User Equipments (UEs) may require minor adaptation, and can be achieved fairly easily with new downloadable clients.

[0087] The present disclosure proposes a framework that enables existing IMS networks to perform the following capabilities:

[0088] Interworking with OTT content providers. In some

embodiments, the IMS provider performs the necessary authentication and authorization, and provides the billing information. This usually requires cooperation between the IMS provider and the OTT provider. In some embodiments, this results in eliminating all the backend operations from the OTT provider, which is an important expense for OTT providers that can now be avoided.

[0089] RTSP Streaming. For RTSP streaming protocol, in some embodiments the IMS network transparently transports the RTSP control signaling information between the UE and the OTT content provider servers.

In some embodiments, the actual streaming may take place between the UE and servers without involvement of the IMS nodes. [0090] HTTP Streaming. For HTTP streaming two approaches are presented. In the first approach, IMS control nodes are bypassed completely for HTTP traffic, and the HTTP traffic is exchanged between the UE and the media servers via an Application Server (AS), acting as an intermediary, according to embodiments disclosed herein acting as a proxy in between. In the second approach, HTTP traffic flows via the IMS control planes and the AS. Note that in HTTP streaming HTTP is used to transfer media files for streaming at the UE.

[0091] IMS as Streaming Services Provider. Finally, the framework enables IMS service providers to provide streaming services as well using the above described options.

[0092] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

Terms and Definitions

[0093] Radio Node: As used herein, a“radio node” is either a radio access node or a wireless device.

[0094] Radio Access Node: As used herein, a“radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.

[0095] Core Network Node: As used herein, a“core network node” is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), or the like.

[0096] Wireless Device: As used herein, a“wireless device” is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a UE in a 3GPP network and a Machine Type Communication (MTC) device.

[0097] Network Node: As used herein, a“network node” is any node that is either part of the radio access network or the core network of a cellular communications network/system.

[0098] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0099] Note that, in the description herein, reference may be made to the term“cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

IMS-Based Streaming: Architecture

[0100] Figure 1 A illustrates the operation of an IMS-based streaming framework according to some embodiments of the present disclosure, showing HTTP streaming via IMS control nodes.

[0101] In the embodiment illustrated in Figure 1A, an IMS network 100 connects content providers 102 with content consumers via an access network 104. In the embodiment illustrated in Figure 1A, the IMS network 100 includes an AS, called the Streaming Proxy Control Plane (SPCP) 106, which enables direct streaming between a content consumer (e.g., a UE) and a Streaming Application Server (SAS). In the embodiment illustrated in Figure 1A, the IMS network 100 also includes two control nodes: a Serving Call / Session Control Function (S-CSCF) 108, and a Proxy Call / Session Control Function (P-CSCF) 1 10, as well as a Unified Data Management (UDM) /

Home Subscriber Server (HSS) 1 12. It will be understood that the IMS network 100 may include other nodes not shown in Figure 1A. [0102] In the embodiment illustrated in Figure 1 A, three content providers 102 are shown: a first HTTP SAS 1 14, a second HTTP SAS 1 16, and a RTSP SAS 1 18. It will be understood that other types of content providers 102 may also be supported by the subject matter of the present disclosure, and that the number and type of content providers 102 illustrated in Figure 1 A are intended to be illustrative and not limiting.

[0103] In the embodiment illustrated in Figure 1 A, three content consumers are registered to the access network 104: a first UE 120, a second UE 122, and a third UE 124. It will be understood that the other types of content consumers may also be supported by the subject matter of the present disclosure, and that the number and type of content consumers illustrated in Figure 1 A are intended to be illustrative and not limiting.

[0104] RTSP Streaming. In the example illustrated in Figure 1 A, the RTSP control path 126A, 126B, and 126C (which may be collectively referred to herein as“RTSP control path 126”) goes through the SPCP 106 and the IMS control plane entities (also referred to herein as“control nodes”) S-CSCF 108 and P-CSCF 1 10, but the RTSP data path 128 does not, instead directly connecting the RTSP SAS 1 18 to the UE 124, and bypassing the IMS control plane entirely.

[0105] As shown in the example illustrated in Figure 1 A, the RTSP control path 126 may use Session Initiation Protocol (SIP) for the portion of the control path 126A between the UE 124 and the S-CSCF 108, may use the IMS Centralized Services (ICS) interface for the portion of the control path 126B between the S-CSCF 108 and the SPCP 106, and may use RTSP for the portion of the control path 126C between the SPCP 106 and the RTSP SAS 1 18.

[0106] Thus, one function of the SPCP 106 is to terminate the IMS SIP signaling, extract the control signaling for RTSP, and transport that extracted control signaling to its destination. In one embodiment, the SPCP 106 may use SIP messages as the vehicle to convey RTSP signaling, as can be seen in the portion of the control path 126A in Figure 1 A and as will be described in more detail in other figures below.

[0107] HTTP Streaming, option 1. In the example illustrated in Figure 1 A, the HTTP SAS 1 14 is providing HTTP streaming content (shown as data path 130) to the UE 120 and also providing HTTP streaming content (shown as data path 132) to the UE 122. In Figure 1 A, control signaling is

represented as a thin“dash and dot” line while data is represented by a thick solid line. In HTTP streaming, the control and data are generally transmitted together, but in Figure 1A, the data path 130 is conceptually represented as separate control and data paths, as is the data path 132. In the example illustrated in Figure 1A, the HTTP data streams go through the SPCP 106, the P-CSCF 1 10, and the S-CSCF 108. In alternative embodiments, however, the HTTP data streams may bypass the S-CSCF 108 and the P-CSCF 1 10. These alternative embodiments will be described in more detail below with regard to other figures. In HTTP streaming files are typically transported to the UE and streamed there (e.g., buffered by the UE), so the strong real-time requirements are relaxed.

[0108] Figure 1 B illustrates the operation of an IMS-based streaming framework according to some embodiments of the present disclosure, showing HTTP streaming that bypasses IMS control nodes. Elements in Figure 1 B, including RTSP streams 126 and 128, are the same or essentially the same as their like-numbered counterparts in Figure 1 A and therefore their descriptions will not be repeated here.

[0109] HTTP Streaming, option 2. In the embodiment illustrated in Figure 1 B, a first HTTP SAS 1 14 is providing HTTP-based streaming content to UE 120 (shown as data path 134) and a second HTTP SAS 1 16 is providing HTTP-based streaming content to UE 122 (shown as data path 136). In the embodiment illustrated in Figure 1 B, however, the HTTP data paths 134 and 136 bypass the S-CSCF 108 and the P-CSCF 1 10. In this manner, the HTTP traffic including media bypasses the IMS control nodes and goes from the UE (120 and 122, respectively), through the SPCP 106, and to the HTTP SAS (1 14 and 1 16, respectively). In this option, the IMS session is set up to exchange the IP addresses and/or Fully Qualified domain name of the SPCP 106 needed for HTTP traffic routing. The advantage of this option is that, by having the data stream bypass the IMS control nodes, the performance of the media stream is improved (e.g., lower latency) and the traffic load handled by the S-CSCF 108 or other IMS control plane entity is greatly reduced. [0110] Although not explicitly shown in Figure 1A or Figure 1 B, in some embodiments, the end user is owned by the IMS provider, and normal IMS authentication applies.

[0111] It should be noted that for some of the following figures, the P- CSCF 1 10 is not shown in order to display a simplified call flow for ease of discussion. Moreover, it should be presumed that, unless explicitly stated otherwise, signals going through the S-CSCF 108 also go through the P- CSCF 1 10, and signals not going through the S-CSCF 108 also do not go through the P-CSCF 1 10. In other figures, signals going though both the S- CSCF 108 and the P-CSCF 1 10 (in either direction) may be represented as going through a node labeled“CSCF 108/1 10,” which represents either separate P-CSCF and S-CSCF nodes or a single node combining the functions of a P-CSCF and an S-CSCF.

IMS-Based Streaming: RTSP

[0112] Figure 2 illustrates an exemplary call flow for UE-initiated RTSP streaming within an IMS-based streaming framework according to some embodiments of the present disclosure. In the embodiment illustrated in Figure 2, the process includes the following:

[0113] At step 200, a UE 120 performs a normal IMS registration over any access network. For the embodiment illustrated in Figure 2, it is presumed that access authorization has already been performed in the access network 104 and therefore is not shown here.

[0114] At step 202, The UE then establishes an IMS session with the SPCP 106 using a Public Service Identity (PSI) that represents the SPCP 106. The UE 120 may be configured or provisioned with the PSI by off-line means. In some embodiments, the UE may include its geolocation information as part of the IMS session setup.

[0115] At step 204, in response to being notified of the registration, the SPCP 106 fetches subscription information for the UE 120, e.g., from a UDM, HSS, or similar node 1 12.

[0116] At step 206, the UE 120 then transports RTSP-related signaling to the SPCP 106 in a SIP MESSAGE. In the embodiment illustrated in Figure 2, the SIP MESSAGE includes an RTSP Request that includes a RTSP Uniform Resource Identifier (URI) of the desired streaming content, hereinafter referred to as the“RTSP URI.”

[0117] At step 208, the SPCP 106 responds with a SIP 200 OK.

[0118] At step 210, the SPCP 106 extracts the RTSP signaling information from the SIP MESSAGE.

[0119] At step 212, the SPCP 106 selects an appropriate RTSP SAS, e.g., by identifying an RTSP SAS that can supply the requested streaming content, and, if more than one RTSP SAS can supply the requested streaming content, finding one that is close to the user (e.g., RTSP SAS 1 18 in the embodiment illustrated in Figure 2). In one embodiment, the SPCP 106 then binds the registered UE with a first RTSP session between the UE 120 and the SPCP 106, transported via SIP signaling, and a second RTSP session between the SPCP 106 and the RTSP SAS 1 18. The SPCP 106 in essence emulates the UE 106 via the second RTSP session. Other subscription information for the UE 120 may also be bound along with the RTSP sessions. Thus, in some embodiments, the SPCP 106 needs to understand at least enough of the RTSP to be able to look for the needed information to locate the proper RTS SAS based on the requested RTSP URI. In the embodiments illustrated in Figure 1A and in Figure 2, the SPCP 106 does not participate in any RTSP data exchanges between the UE 120 and selected RTSP SAS 1 18.

[0120] At step 214, the SPCP 106 then forwards the received RTSP signaling to the RTSP SAS 1 18. In the embodiment illustrated in Figure 2, that is shown as RTSP Request containing the RTSP URI. In some embodiments, the SPCP 106 forwards the RTSP signaling received from the UE without any alteration.

[0121] At step 216, the RTSP SAS 1 18 sends a RTSP response to the SPCP 106.

[0122] At step 218, upon receiving the RTSP response 216, the SPCP 106 inserts the response in a new SIP MESSAGE. In some embodiments, the SIP MESSAGE includes the RTSP response as received from the RTSP SAS without any alteration.

[0123] At step 220, the SPCP 106 sends the new SIP MESSAGE to the UE 120. [0124] At step 222, the UE 120 responds with a SIP 200 OK.

[0125] At step 224, the RTSP streaming content is transmitted from the RTSP SAS 1 18 to the UE 106.

[0126] At some point in time, the UE terminates the RTSP session, at which point the UE 120 sends the applicable RTSP request to the SPCP 106, e.g., within another SIP MESSAGE, which will be detected by the SPCP 106, and forwarded unchanged to the RTSP SAS 1 18. Once the RTSP SAS 1 18 accepts the session termination and sends the appropriate response back to the UE 120 via the SCPC 106, the SCPC 106 then removes the binding created in step 212. This aspect is not shown in Figure 2.

[0127] As illustrated in Figure 2, in this manner RTSP signaling may be exchanged using SIP MESSAGE in both directions. Other SIP methods, such as SIP INFO, may also be used. In the example illustrated in Figure 2, a Session Description Protocol parameter included in the IMS session setup may be used to indicate that the session is for RTSP signaling. Alternatively, the UE subscription information may include the UE entitlement for such a service. It should be noted that the specific order of steps illustrated in Figure 2 are exemplary and not limiting, and that in alternative embodiments the specific messages as well as the specific sequence may vary according to different implementation details.

IMS-Based Streaming: HTTP Option 1

[0128] Figure 3 illustrates an exemplary call flow for UE-initiated HTTP streaming within an IMS-based streaming framework according to some embodiments of the present disclosure. In the embodiment illustrated in Figure 3, the process starts with the UE performing a normal IMS registration, the UE establishing an IMS session with the SPCP 106, and the SPCP 106 fetching subscription information for the UE 120, as described in steps 200, 202, and 204, respectively, of Figure 2, the descriptions of which will not be repeated here. In some embodiments, the SDP parameters included in the IMS session setup process may indicate that the session is for a HTTP streaming option that goes through control nodes in the IMS network 104, such as S-CSCF 108. In some embodiments, the subscription information for UE 120 may include the UE entitlement for such a service. [0129] At step 300, the UE 120 sends to the SPCP 106 a SIP INVITE for the purpose of setting up a Message Session Relay Protocol (MSRP) session.

[0130] At step 302, the SPCP 106 responds with a SIP 200 OK.

[0131] At step 304, the UE 120 sends a SIP ACK. At this point, a MSRP session is established between the UE 120 and the SPCP 106, which the UE 120 may now use as the conduit for an HTTP session between the UE 106 and the SPCP 106.

[0132] At step 306, the UE 120 sends to the SPCP 106 an MSRP SEND that includes the HTTP Request for the streaming session the UE desires. In the embodiment illustrated in Figure 3, the HTTP Request includes the Uniform Resource Locator (URL) of the desired streaming content, hereinafter referred to as“the streaming content URL.”

[0133] At step 308, the SPCP 106 responds by sending a MSRP OK to the UE 120. Other SIP methods could be used, such as SIP INFO, with a proper SIP INFO Package to convey the same information.

[0134] At step 310, the SPCP 106 stores the received HTTP Request for forwarding to a soon-to-be-selected SAS, and binds it with the UE

subscription information and the IMS session. In the embodiment illustrated in Figure 3, the SPCP 106 then selects an appropriate streaming application server for the UE, e.g., based on the streaming content URL and the location of the HTTP SAS, e.g., HTTP SAS 1 14. In the embodiment illustrated in Figure 3, the SPCP 106 binds a first HTTP session that connects the UE 120 and the SPCP 106 and a second HTTP session that connects the SPCP 106 and the HTTP SAS 144 with the UE subscription information and the IMS session.

[0135] At step 312, the SPCP 106 then sends the HTTP Request to the selected SAS, i.e., to the HTTP SAS 1 14.

[0136] At step 314, the HTTP SAS 1 14 sends an HTTP Response to the SPCP 106.

[0137] At step 316, the SPCP 106 inserts the HTTP Response into a new MSRP message for the UE 120.

[0138] At step 318, the SPCP 106 then sends to the UE 120 a MSRP message that includes the HTTP Response.

[0139] At step 320, the UE 120 sends a MSRP 200 OK to the SPCP 106. [0140] In the embodiment illustrated in Figure 3, steps 306 through 320 are repeated for every UE-initiated HTTP Request to fetch a file.

[0141] At step 322, the SIP session is dismantled after all of the files are fetched.

[0142] In this manner, HTTP signaling is exchanged in both directions between the UE 120 and the SPCP 106 via the S-CSCF 108 and the P-CSCF 1 10 using a first HTTP session transported via SIP MSRP, and between the SPCP 106 and HTTP SAS 1 14 using a second HTTP session.

[0143] In the embodiment illustrated in Figure 3, the HTTP Response provided to the UE 120 via MSRP, e.g., in step 318, includes streaming data (which may also be referred to herein as“streaming media” or“streaming content”) provided by the HTTP SAS 1 14. Since MSRP traffic between the UE 120 and the HTTP SAS 1 14 goes through the S-CSCF 108 and the P- CSCF 1 10, it can be seen that in HTTP Option 1 , the streaming data goes through the S-CSCF 108 and the P-CSCF 1 10 (and perhaps other IMS control plane entities as well).

[0144] Using MSRP as a vehicle for streaming content suffers some inefficiencies, e.g., that the HTTP traffic containing the streaming content first goes from the HTTP SAS 114 to the SPCP 106, where it is inserted into new MSRP messages and sent to the UE 120. At the UE 120, the streaming content must be extracted from the MSRP messages, buffered, and assembled to reconstruct the HTTP streamlining traffic before it can be streamed on the UE’s display.

[0145] Thus, in an alternative embodiment, SIP INFO messages, which can hold a large payload, may be used instead. In one embodiment, a SIP INFO package may be created to have a specific syntax such that the client can immediately see the HTTP traffic within the SIP INFO message, e.g., no reassembly or reconstruction, and less signalling is required. In this alternative embodiment also, the SIP INFO traffic will go through the S-CSCF 108, but in a different format, e.g., one that may be more easily processed or that requires less processing.

[0146] In yet another alternative embodiment, the streaming content bypasses the IMS control plane entities entirely. In such embodiments, streaming content would be processed by fewer nodes and thus may have improved latency and/or throughput. Examples of such embodiments will now be described. It should be noted that the specific order of steps illustrated in Figure 3 are exemplary and not limiting, and that in alternative embodiments the specific messages as well as the specific sequence may vary according to different implementation details.

IMS-Based Streaming: HTTP Option 2 (bypass, direct)

[0147] Figure 4 illustrates an exemplary call flow for UE-initiated direct FITTP streaming that bypasses IMS control nodes within an IMS-based streaming framework according to some embodiments of the present disclosure. In the embodiment illustrated in Figure 4, the process starts with the UE performing a normal IMS registration, the UE establishing an IMS session with the SPCP 106, and the SPCP 106 fetching subscription information for the UE 120, as described in steps 200, 202, and 204, respectively, of Figure 2, the descriptions of which will not be repeated here.

In some embodiments, the SDP parameters included in the IMS session setup process may indicate that the session is for a direct FITTP streaming option that bypasses control nodes in the IMS network 104, such as S-CSCF 108. In some embodiments, the subscription information for UE 120 may include the UE entitlement for such a service.

[0148] At step 400, the UE 120 sends to the SPCP 106 a SIP MESSAGE that indicates that the UE desires to start an FITTP streaming session (e.g., the SIP MESSAGE may include a request to start an FITTP streaming session). In the embodiment illustrated in Figure 4, the SIP MESSAGE also includes the URL of a desired streaming content, also referred to as the “streaming content URL.”

[0149] At step 402, the SPCP 106 responds with a SIP 200 OK message.

In alternative embodiments, other SIP methods (e.g., SIP INFO) may be used.

[0150] At step 404, the SPCP 106 creates SPCP information for enabling the FITTP streaming session, such as an FITTP SPCP URL to be used by the UE 120 for the FITTP streaming session, binds this information to the streaming content URL, and binds the FITTP SPCP URL and streaming content URL to the UE IP address and IMS session. The UE 106 uses the HTTP SPCP URL as the destination for all subsequent HTTP requests for the streaming session requested in step 400.

[0151] At step 406, the SPCP 106 then sends to the UE 120 a SIP MESSAGE that contains the SPCP information for setting up an HTTP session (e.g., the HTTP SPCP URL).

[0152] At step 408, the UE 120 responds by sending a SIP 200 OK to the SPCP 106.

[0153] At step 410, the UE 120 sends to the SPCP 106 an HTTP Request that is sent to the HTTP SPCP URL.

[0154] At step 412, the SPCP 106 receives the HTTP Request. If this is the first request, the SPCP 106 stores the UE IP address, selects an appropriate HTTP SAS, e.g., based on the stored streaming content URL, the location of the HTTP SAS, etc., and binds everything to the IMS session. In the embodiment illustrated in Figure 4, HTTP SAS 1 14 is selected. In the embodiment illustrated in Figure 4, the SPCP 106 maintains the association between a first HTTP session between the UE 120 and the SPCP 106 and a second HTTP session between the SPCP 106 and the selected HTTP SAS 1 14. For subsequent HTTP Requests, the SPCP 106 fetches the selected HTTP SAS based on the UE IP address.

[0155] At step 414, the SPCP 106 forwards the HTTP request towards the selected HTTP SAS 1 14.

[0156] At step 416, the SPCP 106 receives from the selected HTTP SAS 1 14 an HTTP Response.

[0157] At step 418, the SPCP 106 locates the UE HTTP session to which to forward the HTTP response.

[0158] At step 420, the SPCP 106 forwards the HTTP response to the UE 120.

[0159] In the embodiment illustrated in Figure 4, steps 410 through 420 are repeated for every UE-initiated HTTP Request to fetch a streaming file.

These subsequent HTTP requests will target the HTTP SPCP URL and include the requested streaming content URL.

[0160] Thus, in the embodiment illustrated in Figure 4, the URL of the desired requested streaming content is included in the request to set up the HTTP streaming session at step 400. The actual request for the streaming content in step 410 will be sent to the address received in the SPCP HTTP URL in step 406, which is typically a URL that resolves to a specific IP address and port. In the embodiment illustrated in Figure 4, only the first request (step 400) is not sent to the SPCP HTTP URL.

[0161] In alternative embodiments (not shown in Figure 4), the request to set up the HTTP streaming session (step 400) does not specify a desired streaming content URL - instead, that information is included in the first HTTP request in step 410. There are still two HTTP sessions employed.

[0162] It should be noted that the specific order of steps illustrated in Figure 4 are exemplary and not limiting, and that in alternative embodiments the specific messages as well as the specific sequence may vary according to different implementation details.

IMS-Based Streaming: HTTP Option 3 (bypass, proxy)

[0163] Figure 5 illustrates an exemplary call flow for UE-initiated proxy HTTP streaming that bypasses IMS control nodes within an IMS-based streaming framework according to some embodiments of the present disclosure. In the embodiment illustrated in Figure 5, the process starts with the UE performing a normal IMS registration, the UE establishing an IMS session with the SPCP 106, and the SPCP 106 fetching subscription information for the UE 120, as described in steps 200, 202, and 204, respectively, of Figure 2, the descriptions of which will not be repeated here.

In some embodiments, the SDP parameters included in the IMS session setup process may indicate that the session is for a proxy HTTP streaming option that bypasses control nodes in the IMS network 104, such as S-CSCF 108. In some embodiments, the subscription information for UE 120 may include the UE entitlement for such a service.

[0164] At step 500, the UE 120 sends to the SPCP 106 a SIP MESSAGE that contains a Request to start an HTTP streaming session.

[0165] At step 502, the SPCP 106 responds with a SIP 200 OK message.

In alternative embodiments, other SIP methods (e.g., SIP INFO) may be used.

[0166] At step 504, the SPCP 106 sends to the UE 120 a SIP MESSAGE that contains SPCP information for setting up an HTTP proxy. [0167] At step 506, the UE 120 responds by sending a SIP 200 OK to the SPCP 106.

[0168] At step 508, the UE 120 sets the SPCP 106 as an HTTP proxy.

[0169] At step 510, the UE 120 issues an HTTP request for desired streaming content. In the embodiment illustrated in Figure 5, the HTTP request includes the URL of the desired streaming content. In this case the SPCP 106 acts as an HTTP proxy receiving streaming content from the HTTP SAS 1 14 and proxying it to the UE 120, which connects to the SPCP 106 using the SPCP information for setting up an HTTP proxy (e.g., a URL) provided by the SPCP 106 to the UE 120.

[0170] At step 512, upon receiving the first HTTP Request, the SPCP 106 extracts and stores the IP address of the UE 120, and choses an HTTP SAS for the UE 120 based on its location. In the embodiment illustrated in Figure 4, for example, the SPCP 106 chooses HTTP SAS 1 14. In the embodiment illustrated in Figure 4, the SPCP 106 binds all necessary and pertinent information to the IMS session and UE subscription information. In the embodiment illustrated in Figure 5, the SPCP 106 operates as an HTTP proxy.

[0171] At step 514, the SPCP 106 proxies the HTTP Request to the HTTP SAS 1 14.

[0172] At step 516, the HTTP SAS 1 14 responds to the HTTP Request by sending an HTTP Response message.

[0173] At step 518, the SPCP 106 proxies the HTTP Response message to the UE 120.

[0174] In the embodiment illustrated in Figure 5, elements 510 through 518 are repeated for every UE-initiated HTTP Request to fetch a file.

[0175] It should be noted that the specific order of steps illustrated in Figure 5 are exemplary and not limiting, and that in alternative embodiments the specific messages as well as the specific sequence may vary according to different implementation details.

[0176] Figure 6 is a schematic block diagram of a core network node 600 according to some embodiments of the present disclosure. The core network node may be, for example, a SPCP 106. As illustrated, the core network node 600 includes one or more processors 602 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field

Programmable Gate Arrays (FPGAs), and/or the like), memory 604, and a network interface 606 for communicating with the core network. The one or more processors 602 are also referred to herein as processing circuitry. In one embodiment, the one or more processors 602 operate to provide one or more functions of a SPCP 106 as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 604 and executed by the one or more processors 602.

Other Embodiments

[0177] Figure 7 illustrates one example of a cellular communications network 700 according to some embodiments of the present disclosure. In the embodiments described herein, the cellular communications network 700 is a 5G NR network. In this example, the cellular communications network 700 includes base stations 702-1 and 702-2, which in LTE are referred to as eNBs and in 5G NR are referred to as gNBs, controlling corresponding macro cells 704-1 and 704-2. The base stations 702-1 and 702-2 are generally referred to herein collectively as base stations 702 and individually as base station 702. Likewise, the macro cells 704-1 and 704-2 are generally referred to herein collectively as macro cells 704 and individually as macro cell 704. The cellular communications network 700 also includes a number of low power nodes 706-1 through 706-4 controlling corresponding small cells 708-1 through 708-4. The low power nodes 706-1 through 706-4 can be small base stations (such as pico or femto base stations) or Remote Radio Pleads (RRPIs), or the like. Notably, while not illustrated, one or more of the small cells 708-1 through 708-4 may alternatively be provided by the base stations 702. The low power nodes 706-1 through 706-4 are generally referred to herein collectively as low power nodes 706 and individually as low power node 706. Likewise, the small cells 708-1 through 708-4 are generally referred to herein collectively as small cells 708 and individually as small cell 708. The base stations 702 (and optionally the low power nodes 706) are connected to a core network 710.

[0178] The base stations 702 and the low power nodes 706 provide service to wireless devices 712-1 through 712-5 in the corresponding cells 704 and 708. The wireless devices 712-1 through 712-5 are generally referred to herein collectively as wireless devices 712 and individually as wireless device 712. The wireless devices 712 are also sometimes referred to herein as UEs.

[0179] Figure 8 is a schematic block diagram of a radio access node 800 according to some embodiments of the present disclosure. The radio access node 800 may be, for example, a base station 702 or 706. As illustrated, the radio access node 800 includes a control system 802 that includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. In addition, the radio access node 800 includes one or more radio units 810 that each includes one or more transmitters 812 and one or more receivers 814 coupled to one or more antennas 816. The radio units 810 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 810 is external to the control system 802 and connected to the control system 802 via, e.g., a wired connection (e.g., an optical cable). However, in some other

embodiments, the radio unit(s) 810 and potentially the antenna(s) 816 are integrated together with the control system 802. The one or more processors 804 operate to provide one or more functions of a radio access node 800 as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 806 and executed by the one or more processors 804.

[0180] Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 800 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures.

[0181] As used herein, a“virtualized” radio access node is an

implementation of the radio access node 800 in which at least a portion of the functionality of the radio access node 800 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 800 includes the control system 802 that includes the one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and/or the like), the memory 806, and the network interface 808 and the one or more radio units 810 that each includes the one or more transmitters 812 and the one or more receivers 814 coupled to the one or more antennas 816, as described above. The control system 802 is connected to the radio unit(s) 810 via, for example, an optical cable or the like. The control system 802 is connected to one or more processing nodes 900 coupled to or included as part of a network(s) 902 via the network interface 808. Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 906, and a network interface 908.

[0182] In this example, functions 910 of the radio access node 800 described herein are implemented at the one or more processing nodes 900 or distributed across the control system 802 and the one or more processing nodes 900 in any desired manner. In some particular embodiments, some or all of the functions 910 of the radio access node 800 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s)

900. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 900 and the control system 802 is used in order to carry out at least some of the desired functions 910. Notably, in some embodiments, the control system 802 may not be included, in which case the radio unit(s) 810 communicate directly with the processing node(s) 900 via an appropriate network interface(s).

[0183] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the radio access node 800 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). [0184] Figure 10 is a schematic block diagram of a network node 1000 according to some other embodiments of the present disclosure. The network node 1000 includes one or more modules 1002, each of which is implemented in software. The module(s) 1002 provide the functionality of a network node 1000 described herein, such as the functionality of an SPCP 106 described herein or the functionality of the radio access node 800 described herein.

This discussion is equally applicable to the processing node 900 of Figure 9 where the modules 1000 may be implemented at one of the processing nodes 900 or distributed across multiple processing nodes 900 and/or distributed across the processing node(s) 900 and the control system 802.

[0185] Figure 1 1 is a schematic block diagram of a UE 1 100 according to some embodiments of the present disclosure. As illustrated, the UE 1 100 includes one or more processors 1 102 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1 104, and one or more transceivers 1 106 each including one or more transmitters 1 108 and one or more receivers 1 1 10 coupled to one or more antennas 11 12. The processors 1 102 are also referred to herein as processing circuitry. The transceivers 1 106 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 1 100 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1 104 and executed by the processor(s) 1 102. Note that the UE 1 100 may include additional components not illustrated in Figure 1 1 such as, e.g., one or more user interface components (e.g., a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like), a power supply (e.g., a battery and associated power circuitry), etc.

[0186] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 1 100 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0187] Figure 12 is a schematic block diagram of the UE 1 100 according to some other embodiments of the present disclosure. The UE 1 100 includes one or more modules 1200, each of which is implemented in software. The module(s) 1200 provide the functionality of the UE 1 100 described herein.

[0188] Figure 13 illustrates a communication system according to some embodiments of the present disclosure. In the embodiment illustrated in Figure 13, a communication system includes a telecommunication network 1300, such as a 3GPP-type cellular network, which comprises an access network 1302, such as a Radio Access Network (RAN), and a core network 1304. The access network 1302 comprises a plurality of base stations 1306A, 1306B, 1306C, such as NBs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area 1308A, 1308B,

1308C. Each base station 1306A, 1306B, 1306C is connectable to the core network 1304 over a wired or wireless connection 1310. A first UE 1312 located in coverage area 1308C is configured to wirelessly connect to, or be paged by, the corresponding base station 1306C. A second UE 1314 in coverage area 1308A is wirelessly connectable to the corresponding base station 1306A. While a plurality of UEs 1312, 1314 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1306.

[0189] The telecommunication network 1300 is itself connected to a host computer 1316, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer 1316 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 1318 and 1320 between the telecommunication network 1300 and the host computer 1316 may extend directly from the core network 1304 to the host computer 1316 or may go via an optional intermediate network 1322. The intermediate network 1322 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 1322, if any, may be a backbone network or the Internet; in particular, the intermediate network 1322 may comprise two or more sub-networks (not shown).

[0190] The communication system of Figure 13 as a whole enables connectivity between the connected UEs 1312, 1314 and the host computer 1316. The connectivity may be described as an OTT connection 1324. The host computer 1316 and the connected UEs 1312, 1314 are configured to communicate data and/or signaling via the OTT connection 1324, using the access network 1302, the core network 1304, any intermediate network 1322, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1324 may be transparent in the sense that the participating communication devices through which the OTT connection 1324 passes are unaware of routing of uplink and downlink communications. For example, the base station 1306 may not or need not be informed about the past routing of an incoming downlink communication with data originating from the host computer 1316 to be forwarded (e.g., handed over) to a connected UE 1312. Similarly, the base station 1306 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1312 towards the host computer 1316.

[0191] Figure 14 illustrates a communication system according to other embodiments of the present disclosure. The UE, base station, and host computer discussed in the preceding paragraphs will now be described with reference to Figure 14. In a communication system 1400, a host computer 1402 comprises hardware 1404 including a communication interface 1406 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1400. The host computer 1402 further comprises processing circuitry 1408, which may have storage and/or processing capabilities. In particular, the processing circuitry 1408 may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The host computer 1402 further comprises software 1410, which is stored in or accessible by the host computer 1402 and executable by the processing circuitry 1408. The software 1410 includes a host application 1412. The host application 1412 may be operable to provide a service to a remote user, such as a UE 1414 connecting via an OTT connection 1416 terminating at the UE 1414 and the host computer 1402. In providing the service to the remote user, the host application 1412 may provide user data which is transmitted using the OTT connection 1416. [0192] The communication system 1400 further includes a base station 1418provided in a telecommunication system and comprising hardware 1420 enabling it to communicate with the host computer 1402 and with the UE 1414. The hardware 1420 may include a communication interface 1422 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1400, as well as a radio interface 1424 for setting up and maintaining at least a wireless connection 1426 with the UE 1414 located in a coverage area (not shown in Figure 14) served by the base station 1418. The communication interface 1422 may be configured to facilitate a connection 1428 to the host computer 1402. The connection 1428 may be direct or it may pass through a core network (not shown in Figure 14) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1420 of the base station 1418 further includes processing circuitry 1430, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The base station 1418 further has software 1432 stored internally or accessible via an external connection.

[0193] The communication system 1400 further includes the UE 1414 already referred to. The UE’s 1414 hardware 1434 may include a radio interface 1436 configured to set up and maintain a wireless connection 1426 with a base station serving a coverage area in which the UE 1414 is currently located. The hardware 1434 of the UE 1414 further includes processing circuitry 1438, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The UE 1414 further comprises software 1440, which is stored in or accessible by the UE 1414 and executable by the processing circuitry 1438. The software 1440 includes a client application 1442. The client application 1442 may be operable to provide a service to a human or non human user via the UE 1414, with the support of the host computer 1402. In the host computer 1402, the executing host application 1412 may

communicate with the executing client application 1442 via the OTT connection 1416 terminating at the UE 1414 and the host computer 1402. In providing the service to the user, the client application 1442 may receive request data from the host application 1412 and provide user data in response to the request data. The OTT connection 1416 may transfer both the request data and the user data. The client application 1442 may interact with the user to generate the user data that it provides.

[0194] It is noted that the host computer 1402, the base station 1418, and the UE 1414 illustrated in Figure 14 may be similar or identical to the host computer 1316, one of the base stations 1306A, 1306B, 1306C, and one of the UEs 1312, 1314 of Figure 13, respectively. This is to say, the inner workings of these entities may be as shown in Figure 14 and independently, the surrounding network topology may be that of Figure 13.

[0195] In Figure 14, the OTT connection 1416 has been drawn abstractly to illustrate the communication between the host computer 1402 and the UE 1414 via the base station 1418 without explicit reference to any intermediary devices and the precise routing of messages via these devices. The network infrastructure may determine the routing, which may be configured to hide from the UE 1414 or from the service provider operating the host computer 1402, or both. While the OTT connection 1416 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

[0196] The wireless connection 1426 between the UE 1414 and the base station 1418 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various

embodiments improve the performance of OTT services provided to the UE 1414 using the OTT connection 1416, in which the wireless connection 1426 forms the last segment. More precisely, the teachings of these embodiments may improve the capability of the network by providing a framework for IMS- based streaming services and thereby provide benefits such as allowing an IMS service provider to interwork with OTT content providers and be able to handle all authentication, authorization, and billing for them as an additional source of revenue without requiring these OTT providers to do any adaptation to their servers for their applications and requiring little to no modification of the UEs. In addition, the IMS service provider can offer streaming services to its own users in direct competition [0197] A measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1416 between the host computer 1402 and the UE 1414, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 1416 may be implemented in the software 1410 and the hardware 1404 of the host computer 1402 or in the software 1440 and the hardware 1434 of the UE 1414, or both. In some embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1416 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which the software 1410, 1440 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1416 may include message format, retransmission settings, preferred routing, etc.; the reconfiguring need not affect the base station 1414, and it may be unknown or imperceptible to the base station 1414. Such procedures and functionalities may be known and practiced in the art. In certain embodiments,

measurements may involve proprietary UE signaling facilitating the host computer 1402’s measurements of throughput, propagation times, latency, and the like. The measurements may be implemented in that the software 1410 and 1440 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1416 while it monitors propagation times, errors, etc.

[0198] Figure 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The

communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 15 will be included in this section. In step 1500, the host computer provides user data. In sub-step 1502 (which may be optional) of step 1500, the host computer provides the user data by executing a host application. In step 1504, the host computer initiates a transmission carrying the user data to the UE. In step 1506 (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1508 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0199] Figure 16 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The

communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 16 will be included in this section. In step 1600 of the method, the host computer provides user data. In an optional sub-step (not shown) the host computer provides the user data by executing a host application. In step 1602, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1604 (which may be optional), the UE receives the user data carried in the transmission.

[0200] Figure 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The

communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 17 will be included in this section. In step 1700 (which may be optional), the UE receives input data provided by the host computer. Additionally or

alternatively, in step 1702, the UE provides user data. In sub-step 1704 (which may be optional) of step 1700, the UE provides the user data by executing a client application. In sub-step 1706 (which may be optional) of step 1702, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in sub-step 1708 (which may be optional), transmission of the user data to the host computer. In step 1710 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

[0201] Figure 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The

communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 18 will be included in this section. In step 1800 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 1802 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 1804, the host computer receives the user data carried in the transmission initiated by the base station.

[0202] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Radio Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.

In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0203] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0204] Advantages of the subject matter of the present disclosure include that it provides a simple solution that makes possible new business opportunities for IMS service providers, including providing a revenue stream for streaming services provided by the IMS service provider or by a third party (e.g., OTT) provider.

[0205] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

3GPP Third Generation Partnership Project

5G Fifth Generation

AP Access Point

AS Application Server

ASIC Application Specific Integrated Circuit

CPU Central Processing Unit

CSCF Call / Session Control Function

DSP Digital Signal Processor

eNB Enhanced or Evolved Node B

FPGA Field Programmable Gate Array

gNB New Radio Base Station

HSS Home Subscriber Server

HTTP Hyper Text Transport Protocol

ICS Internet Protocol Multimedia Subsystem Control

Services

IMS Internet Protocol Multimedia Subsystem

IP Internet Protocol

LTE Long Term Evolution

MME Mobility Management Entity

MSRP Message Session Relay Protocol

MTC Machine Type Communication

NR New Radio OTT Over-the-Top

P-CSCF Proxy Call / Session Control Function

P-GW Packet Data Network Gateway

PSI Public Service Identity

RAM Random Access Memory

RAN Radio Access Network

ROM Read Only Memory

RRH Remote Radio Head

RTSP Real Time Streaming Protocol

· SAS Streaming Application Server

SCEF Service Capability Exposure Function

S-CSCF Serving Call / Session Control Function

SIP Session Initiation Protocol

SPCP Streaming Proxy - Control Plane

· UDM Unified Data Management

URI Uniform Resource Identifier

URL Uniform Resource Locator

UE User Equipment

VoLTE Voice over Long Term Evolution

[0206] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims What is claimed is:

1. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a Streaming Proxy Control Plane, SPCP, (106) within an IMS (100), the method comprising:

receiving (206), from a registered User Equipment, UE (120), a Real Time Streaming Protocol, RTSP, request that includes a Uniform Resource Identifier, URI, of a desired streaming content;

selecting (212) an RTSP Streaming Application Server, SAS (1 18); and sending (214) the RTSP request to the selected RTSP SAS (1 18).

2. The method of claim 1 wherein receiving (206) the RTSP request comprises receiving the request within a first Session Initiation Protocol, SIP, message.

3. The method of claim 2 wherein the first SIP message comprises a SIP INFO message or a SIP MESSAGE message.

4. The method of any of claims 1 - 3 wherein selecting (212) the RTSP SAS (1 18) comprises selecting the RTSP SAS (1 18) based on at least one of the URI of the desired streaming content and a location of the RTSP SAS relative to the UE (120).

5. The method of any of claims 1 - 4 wherein sending (214) the RTSP request to the selected RTSP SAS (1 18) comprises:

extracting (210), from the RTSP request, RTSP information for forwarding;

establishing (212) a first RTSP session between the UE (120) and the SPCP (106) and a second RTSP session between the SPCP (106) and the selected RTSP SAS (1 18); and

sending (214) the RTSP request to the selected RTSP SAS (1 18) via the second RTSP session.

6. The method of any of claims 1 - 5 further comprising: receiving (216), from the selected RTSP SAS (1 18), an RTSP response; and

sending (220), to the UE (120), the RTSP response within a second SIP message.

7. The method of any of claims 1 - 6 wherein the first or second SIP message comprises a SIP MESSAGE message or a SIP INFO message.

8. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a Streaming Proxy Control Plane, SPCP, (106) within an IMS (100), the method comprising:

establishing (300, 302, 304) a Message Session Relay Protocol,

MSRP, session with a registered User Equipment, UE (120);

receiving (306), from the UE (120) via the MSRP session, a Hypertext Transfer Protocol, HTTP, request that includes a Uniform Resource Locator, URL, of a desired streaming content;

selecting (310) an HTTP Streaming Application Server, SAS (114); and sending (312) the HTTP request to the selected HTTP SAS (1 14).

9. The method of claim 8 wherein establishing the MSRP session comprises establishing the MSRP session in response to receiving (300), from the UE (120), a request to establish the MSRP session.

10. The method of claim 9 wherein receiving (300) the request to establish the MSRP session comprises receiving the request within a Session Initiation Protocol, SIP, message.

1 1. The method of claim 10 wherein the SIP message comprises a SIP INVITE message.

12. The method of any of claims 8 - 1 1 wherein selecting (310) the HTTP SAS (1 14) comprises selecting the HTTP SAS (1 14) based on at least one of the URL of the desired streaming content and a location of the HTTP SAS relative to the UE (120).

13. The method of any of claims 8 - 12 wherein sending (312) the HTTP request to the selected HTTP SAS (1 14) comprises:

extracting (310), from the HTTP request, HTTP information for forwarding;

establishing (310) a first HTTP session between the UE (120) and the SPCP (106);

establishing (310) a second HTTP session between the SPCP (106) and the selected HTTP SAS (1 14); and

sending (312) the HTTP request to the selected HTTP SAS (1 14) via the second HTTP session.

14. The method of any of claims 8 - 13 further comprising:

receiving (314), from the selected HTTP SAS (1 14), an HTTP response; and

sending (318), to the UE (120), the HTTP response via the MSRP session.

15. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a Streaming Proxy Control Plane, SPCP, (106) within an IMS (100), the method comprising:

receiving (400), from a User Equipment, UE, (120), a request to start a Hypertext Transfer Protocol, HTTP, streaming session, the request including a Uniform Resource Locator, URL, of a desired streaming content;

creating (404) an HTTP SPCP URL to be used by the UE (120) for the

HTTP streaming session and binding the HTTP SPCP URL to the URL of the desired streaming content; and

sending (406), to the UE (120), the HTTP SPCP URL.

16. The method of claim 15 wherein receiving (400) the request to start the

HTTP streaming session comprises receiving a Session Initiation Protocol, SIP, message.

17. The method of claim 16 wherein receiving (400) the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

18. The method of any of claims 15 - 17, further comprising:

receiving (410), from the UE (120), an HTTP request sent to the HTTP SPCP URL;

determining (412) an HTTP Streaming Application Server, SAS (1 14); and

sending (414) the HTTP request to the determined HTTP SAS (1 14).

19. The method of claim 18, wherein determining (412) the HTTP SAS (1 14) comprises:

upon a determination that an HTTP SAS has already been selected for the UE (120), using the HTTP SAS that was already selected for the UE (120); and

upon a determination that an HTTP SAS has not yet been selected for the UE (120):

selecting an HTTP SAS;

maintaining an association between a first HTTP session between the SPCP (106) and the UE (120) and a second HTTP session between the SPCP (106) and the selected HTTP SAS (1 14); and

using the selected HTTP SAS (1 14).

20. The method of claim 19 wherein selecting the HTTP SAS comprises selecting the HTTPS SAS based on at least one of the URL of the desired streaming content and a location of the HTTP SAS relative to the UE (120).

21. The method of any of claims 15 - 19 further comprising:

receiving (416), from the determined HTTP SAS (1 14), an HTTP response;

identifying (418) the first HTTP session between the SPCP (106) and the UE (120); and sending (420) the HTTP response to the UE (120) via the identified first HTTP session.

22. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a Streaming Proxy Control Plane, SPCP, (106) within an IMS (100), the method comprising:

receiving (500), from a User Equipment, UE, (120), a request to start a Hypertext Transfer Protocol, HTTP, streaming session;

sending (504), to the UE (120), information for setting the SPCP (106) as a HTTP proxy;

receiving (510), from the UE (120), an HTTP request that includes a Uniform Resource Locator, URL, of a desired streaming content;

determining (512) an HTTP Streaming Application Server, SAS (1 14); and

proxying (514) the HTTP request to the determined HTTP SAS (1 14).

23. The method of claim 22 wherein receiving (500) the request to start the HTTP streaming session comprises receiving a Session Initiation Protocol, SIP, message.

24. The method of claim 23 wherein receiving (500) the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

25. The method of any of claims 22 - 24 wherein sending (504) the information for setting the SPCP (106) as the HTTP proxy comprises sending an SPCP (106) Uniform Resource Locator, URL.

26. The method of any of claims 22 - 25 wherein determining (512) the HTTP SAS comprises:

upon a determination that an HTTP SAS has already been selected for the UE (120), using the HTTP SAS that was already selected for the UE (120); and upon a determination that an HTTP SAS has not yet been selected for the UE (120), selecting an HTTP SAS and using the selected HTTP SAS (1 14).

27. The method of claim 26 wherein selecting the HTTP SAS comprises selecting the HTTPS SAS based on at least one of the URL of the desired streaming content and a location of the HTTP SAS relative to the UE (120).

28 The method of any of claims 22 - 26 further comprising:

receiving (516), from the determined HTTP SAS (1 14), an HTTP response; and

proxying (518) the HTTP response to the UE (120).

29. A Streaming Proxy Control Plane, SPCP (106, 600) for providing Internet Protocol Multimedia Subsystem, IMS, -based streaming, the SPCP, (106) comprising:

a network interface (606);

one or more processors (602); and

memory (604) storing instructions executable by the one or more processors, whereby the SPCP (106) is operable to perform the method of any of claims 1 -28.

30. A Streaming Proxy Control Plane, SPCP, (106, 600) for providing Internet Protocol Multimedia Subsystem, IMS, -based streaming, the SPCP (106, 600) being adapted to perform the method of any of claims 1 -28.

31 . A Streaming Proxy Control Plane, SPCP, (106, 600) for providing Internet Protocol Multimedia Subsystem, IMS, -based streaming, the SPCP (106, 600) comprising means for performing the method of any of claims 1 -28.

32. A Streaming Proxy Control Plane, SPCP, (106, 600) for providing Internet Protocol Multimedia Subsystem, IMS, -based streaming, the SPCP (106, 600) comprising one or more modules operable to perform the method of any of claims 1 -28.

33. A non-transitory computer readable medium storing software instructions that when executed by one or more processors of a Streaming Proxy Control Plane, SPCP, (106, 600) cause the SPCP (106, 600) to perform the method of any of claims 1 -28.

34. A computer program comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method of any of claims 1 -28.

35. A carrier comprising the computer program of claim 34, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

36. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a User Equipment, UE, (120) within an IMS (100), the method comprising:

sending (206), to a Streaming Proxy Control Plane, SPCP, (106), a Real Time Streaming Protocol, RTSP, request that includes a Uniform Resource Identifier, URI, of a desired streaming content;

receiving (220), from the SPCP (106), a RTSP response that identifies a RTSP Streaming Application Server, SAS, (1 18); and

receiving (224) at least a portion of the desired streaming content from the identified RTSP SAS (1 18).

37. The method of claim 36 wherein sending (206) the RTSP request comprises sending the request within a first Session Initiation Protocol, SIP, message.

38. The method of claim 37 wherein the first SIP message comprises a SIP INFO message or a SIP MESSAGE message.

39. The method of claim 36 wherein receiving (220) the RTSP response comprises receiving the response within a second Session Initiation Protocol, SIP, message.

40. The method of claim 39 wherein the second SIP message comprises a SIP INFO message or a SIP MESSAGE message.

41. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a User Equipment, UE, (120) within an IMS (100), the method comprising:

establishing (300, 302, 304) a Message Session Relay Protocol,

MSRP, session with a Streaming Proxy Control Plane, SPCP, (106);

sending (306), to the SPCP (106) via the MSRP session, a Hypertext Transfer Protocol, HTTP, request that includes a Uniform Resource Locator, URL, of a desired streaming content; and

receiving (318), from the SPCP (106) via the MSRP session, a HTTP response comprising at least a portion of the desired streaming content.

42. The method of claim 41 wherein the MSRP session is established using at least one Session Initiation Protocol, SIP, message.

43. The method of claim 42 wherein the at least one SIP message comprises a SIP INVITE message.

44. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a User Equipment, UE, (120) within an IMS (100), the method comprising:

sending (400), to a Streaming Proxy Control Plane, SPCP, (106), a request to start a Hypertext Transfer Protocol, HTTP, streaming session, the request including a Uniform Resource Locator, URL, of a desired streaming content;

receiving (406), from the SPCP (106), an HTTP SPCP URL to be used by the UE (120) for the HTTP streaming session; sending (410), to the SPCP (106), an HTTP request sent to the HTTP SPCP URL; and

receiving (420, from the SPCP (106), an HTTP response comprising at least a portion of the desired streaming content.

45. The method of claim 44 wherein sending (400) the request to start the HTTP streaming session comprises sending a Session Initiation Protocol,

SIP, message.

46. The method of claim 45 wherein sending (400) the SIP message comprises sending a SIP MESSAGE message or a SIP INFO message.

47. The method of claim 44 wherein receiving (406) an HTTP SPCP URL comprises receiving the HTTP SPCP URL via a Session Initiation Protocol, SIP, message.

48. The method of claim 47 wherein receiving (406) the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

49. A method for Internet Protocol Multimedia Subsystem, IMS, -based streaming, performed at a User Equipment, UE, (120) within an IMS (100), the method comprising:

sending (500), to a Streaming Proxy Control Plane, SPCP, (106), a request to start a Hypertext Transfer Protocol, HTTP, streaming session; receiving (504), from the SPCP (106), information for setting the SPCP (106) as a HTTP proxy;

setting (508) the SPCP (106) as an HTTP proxy using the received information;

sending (510), to the SPCP (106), an HTTP request that includes a Uniform Resource Locator, URL, of a desired streaming content; and

receiving (518), from the SPCP (106), an HTTP response comprising at least a portion of the desired streaming content.

50. The method of claim 49 wherein sending (500) the request to start the HTTP streaming session comprises sending a Session Initiation Protocol,

SIP, message.

51. The method of claim 50 wherein sending (500) the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

52. The method of claim 49 wherein receiving (504) the information for setting the SPCP (106) as the HTTP proxy comprises receiving an SPCP (106) Uniform Resource Locator, URL.

53. The method of claim 52 wherein receiving (504) the information for setting the SPCP (106) as the HTTP proxy comprises receiving a Session Initiation Protocol, SIP, message.

54. The method of claim 53 wherein receiving (504) the SIP message comprises receiving a SIP MESSAGE message or a SIP INFO message.

55. A User Equipment, UE, (120, 1 100) for supporting Internet Protocol Multimedia Subsystem, IMS, -based streaming, the UE (120, 1 100) comprising:

one or more radio transceivers (1 106);

one or more processors (1 102); and

memory (1 104) storing instructions executable by the one or more processors, whereby the UE (120, 1 100) is operable to perform the method of any of claims 36-54.

56. A User Equipment, UE, (120, 1 100) for supporting Internet Protocol Multimedia Subsystem, IMS, -based streaming, the UE (120, 1 100) being adapted to perform the method of any of claims 36-54.

57. A User Equipment, UE, (120, 1 100) for supporting Internet Protocol Multimedia Subsystem, IMS, -based streaming, the UE (120, 1 100) comprising means for performing the method of any of claims 36-54.

58. A User Equipment, UE, (120, 1 100) for supporting Internet Protocol Multimedia Subsystem, IMS, -based streaming, the UE (120, 1 100) comprising one or more modules operable to perform the method of any of claims 36-54.

59. A non-transitory computer readable medium storing software instructions that when executed by one or more processors of a User Equipment, UE, (120, 1 100) for supporting Internet Protocol Multimedia Subsystem, IMS, -based streaming, cause the UE (120, 1 100) to perform the method of any of claims 36-54.

60. A computer program comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method of any of claims 36-54.

61. A carrier comprising the computer program of claim 60, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.