JP6418665B2 - Method of supplying presence information by presence server in IMS-based DASH service, and user equipment (UE) receiving presence information via presence server - Google Patents

Description

  Related Application This application is based on US provisional patent application serial number No. P53504Z filed Jan. 17, 2013. 61 / 753,914 is claimed and incorporated by reference.

  Wireless mobile communication technologies use a number of different standards and protocols to transmit data between a node (eg, a transmitting station) and a wireless device (eg, a mobile device). Some wireless devices communicate using orthogonal frequency division multiple access (OFDMA) in downlink (DL) transmission and single carrier frequency division multiple access (SC-FDMA) in uplink (UL) transmission . Multiple standards and multiple protocols that use Orthogonal Frequency Division Multiplexing (OFDM) for signal transmission are described in 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), WiMAX (Global Interoperability for Microwave Access). Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard (eg, 802.16e, 802.16m), commonly known to industry associations as operational), and IEEE 802.11 standard commonly known to industry associations as WiFi including.

  In multiple 3GPP Radio Access Network (RAN) LTE systems, a node is an evolved universal terrestrial radio access network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, improved Node B, eNodeB, or eNB) And a radio network controller (RNC) that communicates with a wireless device known as user equipment (UE). A downlink (DL) transmission may be a communication from a node (eg, eNodeB) to a wireless device (eg, UE). Uplink (UL) transmission may be communication from a wireless device to a node.

  Wireless devices can be used to receive multimedia distribution of Internet video using various protocols such as hypertext transfer protocol (HTTP) streaming. Protocols for providing HTTP-based delivery of video streaming can include dynamic adaptive streaming over HTTP (DASH).

The features and advantages of the present disclosure will become apparent from the detailed description set forth below when taken in conjunction with the accompanying drawings, which are illustrated by way of example, in a manner that illustrates the features of the present disclosure. I will.
FIG. 3 shows a block diagram of a client and multiple servers for dynamic adaptive streaming (DASH) with Hypertext Transfer Protocol (HTTP), according to an example. FIG. 3 shows a block diagram of a media presentation description (MPD) metadata file structure, according to an example. FIG. 3 shows a block diagram of an Internet Protocol (IP) Multimedia Subsystem (IMS) based packet switched streaming service (PSS) and Multimedia Broadcast Multicast Service (MBMS) functional architecture with a presence server, according to an example. FIG. 4 illustrates an example message flow chart of a presence server used in a Dynamic Adaptive Streaming (DASH) service with Internet Protocol (IP) Multimedia Subsystem (IMS) -based Hypertext Transfer Protocol (HTTP), according to an example. Example of user equipment (UE) operable to act as a presentity in Dynamic Adaptive Streaming (DASH) service over Internet Protocol (IP) Multimedia Subsystem (IMS) based Hypertext Transfer Protocol (HTTP) The function of a computer circuit is shown. FIG. 4 shows a flowchart of a method for supplying presence information by a presence server in a dynamic adaptive streaming (DASH) service according to an Internet Protocol (IP) Multimedia Subsystem (IMS) -based Hypertext Transfer Protocol (HTTP), according to an example. FIG. 4 shows a diagram of a presence server, a node (eg, eNB), and a user equipment (UE), by example. FIG. 3 shows a diagram of a wireless device (eg, UE), according to an example. Reference is used to describe a number of exemplary embodiments, and a specific language will be used to describe the same in this specification. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended.

  Before the present invention is disclosed and described, it is understood that the present invention is not limited to the specific structures, processing steps, or materials disclosed herein. However, it extends to equivalents recognized by those skilled in the art. It will also be understood that the terminology used in this disclosure is used for the purpose of describing only a plurality of specific examples and is not intended to be limiting. The same reference numbers in different drawings represent the same element. The numbers provided in the multiple flowcharts and multiple processes are provided for clarity in describing the multiple steps and multiple operations and do not necessarily indicate a particular order or sequence.

  Exemplary Embodiment

  An initial appearance of the plurality of technical embodiments is provided below, and then a plurality of specific technical embodiments are described in further detail later. This initial summary is intended to help multiple readers understand the technology faster, but it is intended to identify multiple important or essential features of the technology. Nor is it intended to limit the scope of claimed subject matter.

  Multiple presence services were developed by the Global System for Mobile Communications (GSM) Association (GSMA) to support multiple multimedia services via the Internet Protocol (IP) Multimedia Subsystem (IMS) It may be part of a rich communication service (RCS) profile. Multiple presence services can allow users to share presence information such as geolocation, multiple service functions, content consumption, multiple taglines, and multiple avatars. The user's client application provides presence information (eg, presence status) to a presence service (eg, via a presence server), and the presence information is stored in a personally available record (referred to as a presentity). Can be made available for provision to other users (referred to as watchers) to communicate the availability for communication of the presentity user. The presence server can receive, store, issue and supply presence information. IMS presence is based on the Session Initiation Protocol (SIP) and Extensible Markup Language (as defined by the Internet Engineering Task Force (IETF) and 3GPP), along with multiple logical network elements defined by the Open Mobile Alliance (OMA). (XML) Configuration Access Protocol (XCAP). In the 3GPP context, the architecture and functional description of multiple presence services can be specified in 3GPP Technical Specification (TS) 24.141V11.0.0 (2012-09). Protocols for multiple presence services, including end-user applications, are in Presence SIP Instant Messaging and Presence Leverage Extension (SIMPLE) Specification Version 1.0 (25 Jul 2006 OMA-TS-Presence_SIMPLE-V1_0-20060725-A). It can be specified by OMA.

  Hypertext Transfer Protocol (HTTP) streaming can be used as a form of multimedia distribution of Internet video. In HTTP streaming, a multimedia file can be divided into one or more segments and delivered to the client using the HTTP protocol. HTTP-based delivery can provide reliability and simplicity of deployment through wide adoption of both HTTP and multiple protocols underlying HTTP, including Transmission Control Protocol (TCP) / Internet Protocol (IP). HTTP-based delivery can enable an easy and easy streaming service by avoiding network address translation (NAT) and firewall traversal problems. HTTP-based delivery or streaming can also provide the ability to utilize multiple standard HTTP servers and caches instead of multiple specialized streaming servers. HTTP based delivery can provide scalability with minimal or reduced status information on the server side. Examples of multiple HTTP streaming technologies may include Microsoft IIS Smooth Streaming, Apple HTTP Live Streaming, and Adobe HTTP Dynamic Streaming.

  Dynamic Adaptive Streaming (DASH) over HTTP can be a standardized HTTP streaming protocol. In an example, DASH can be standardized in 3GPP Technical Specification (TS) 26.247 V11.1.0 (2012-12). In DASH, a media presentation description (MPD) metadata file can provide information about the structure and various versions of media content displays stored on a server, including different bit rates, frame rates, resolutions, or codec types. In addition, DASH can also specify multiple segment formats. The MPD metadata file contains initialization and media segment information (eg, media segment) to ensure mapping of multiple segments to the media presentation timeline for switching and simultaneous display with other representations. The media player can inspect the initialization segment to determine container format and media timing information). Based on this MPD metadata information describing the relationship of multiple segments in the formation of a media presentation, multiple clients (or multiple client devices) can use multiple methods of HTTP GET or partial GET to generate multiple segments. Can request. The client can fully control the streaming session. For example, the client manages a smooth playout of on-time requests and a sequence of multiple segments, potentially multiple bitrates (eg, to react to multiple changes in device status or user preferences) Several other attributes can be adjusted. DASH technology has also been standardized by several other organizations such as Moving Picture Experts Group (MPEG), Open IPTV Forum (OIPF), and Hybrid Broadcast Broadband TV (HbbTV).

  A DASH client can receive multimedia content by downloading multiple segments through a series of HTTP request-response transactions. DASH can provide the ability to dynamically switch between multiple different bit rate representations of media content as available bandwidth changes. For this reason, DASH changes multiple states of network and wireless links, multiple user preferences and device functions such as display resolution, the type of central processing unit (CPU) used, or available memory resources, etc. Allows you to adapt quickly.

  In DASH, as shown in FIG. 1, a media presentation description (MPD) metadata file can provide the structure and various versions of information of media content representations stored on the web and / or media server 212. Various versions of media content representations can include different bit rates, frame rates, resolutions, codec types, or other similar types of information. In addition, DASH also provides initialization and multiple media segments for the media engine to ensure mapping to multiple media presentation timelines for switching to multiple displays and simultaneous display. Multiple segment formats can be specified that can contain Based on MPD metadata information describing the relationship of multiple segments and how the multiple segments form a media presentation, client 220 requests multiple segments using an HTTP GET 240 message or a series of partial GET messages. it can. Clients manage multiple playouts of on-time requests and multi-segment sequences, or respond to multiple changes in device status or user preferences, multiple bit rates or other multiple attributes You can control streaming sessions that potentially adjust

  FIG. 1 shows a DASH-based streaming framework. Media encoder 214 at web / media server 212 can encode the input media from audio / video input 210 into a format for storage or streaming. The media segmenter 216 can be used 232 to split the input media into serial fragments or chunks that can be provided to the web server 218. Client 220 can request 234 new data in multiple chunks using multiple HTTP GET messages sent to a web server (eg, an HTTP server).

  For example, the web browser 222 of the client 220 can request multimedia content using an HTTP GET message 240. Web server 218 can provide MPD 242 for multimedia content to clients. The MPD can be used 252 to convey the index of each segment and the corresponding location of the segment, as indicated in the associated metadata information. The web browser can pull media from the server segment by a segment according to MPD 242 as shown at 236. For example, the web browser can request the first fragment using an HTTP GET URL (flag1req) 244. A uniform resource locator (URL) or universal resource locator can be used 254 to tell the web server which segment the client is requesting. The web server can provide a first fragment (eg, fragment 1 246). For subsequent fragments, the web browser can request fragment i using an HTTP GET URL (frag i req) 248, where i is the integer index of the fragment. As a result, the web server can provide fragment i 250. Multiple fragments may be presented to the client via a media decoder and / or player 224.

  As shown in FIG. 2, DASH is a media presentation that provides multiple media content display structures and various versions of information stored on a server, as well as multiple segment formats (or multiple fragment formats). A number of different formats for the description (MPD) metadata file 402 can be specified. In DASH, media presentation description (MPD) metadata 402 can provide information about the structure and various versions of multiple media content displays stored on the web and / or media server. In the example shown in FIG. 2, MPD metadata may be divided in time into a plurality of periods 404 having a predetermined length, such as 60 seconds in this example. Each period may include multiple adaptation sets 406. Each adaptation set can provide many encoded alternatives to information about one or more media components. For example, the adaptation set 0 of this example may include various audio alternatives that are encoded differently, such as different bit rates, mono, stereo, and surround sound. In addition to providing different quality audio for multimedia presentations over a period ID, the adaptation set may also include audio in multiple different languages. The different alternatives provided in the adaptation set may be referred to as multiple representations 408.

  In FIG. 2, adaptation set 1 is shown to provide video at multiple different bit rates, such as 5 megabits per second (Mbps), 2 Mbps, 500 kilobits per second (kbps), or trick mode. Trick mode can be used to make a seek, fast forward, rewind or other change in location in the multimedia streaming file. In addition, the video is also available in a number of different formats, such as 2D (2D) or 3D (3D) video, or portrait or landscape oriented video. Each representation 408 may include segment information 410. The segment information may include initialization information 412 and actual media segment data 414. In this example, an MPEG-4 (MP4) file is streamed from the server to the mobile device. While MP4 is used in this example, a wide variety of different codecs may be used. A codec is a device, application, element, or computer program capable of encoding or decoding a digital data stream or signal.

  The multimedia in the adaptation set may be further divided into smaller segments. In the example of FIG. 2, the 60 second video segment of adaptation set 1 is further divided into four sub-segments 414 of 15 seconds each. These examples are not intended to be limiting. The actual length of the adaptation set and each media segment or sub-segment depends on the media type, multiple system requirements, the potential type of interference, and so on. The plurality of actual media segments or the plurality of sub-segments can have a length of less than 1 second to less than a few minutes.

  The DASH content can be supplied using a multimedia broadcast multicast service (MBMS). MBMS is a point-to-multipoint interface specification for multiple cellular networks that can provide efficient delivery of broadcast and multicast services both in the core network and in the cell. Enhanced Multimedia Broadcast and Multicast Service (eMBMS) can be an LTE version of MBMS that can be deployed on multiple LTE networks. LTE eMBMS is the same using multiple subsets of available radio resources to all users in the cell (ie broadcast) or to a certain set of users in the cell (multiple subscribers) (ie multicast) While it is possible to provide multiple transfer functions for transmitting content information, the remaining available radio resources may be used to support transmission (eg, multiple unicast services) towards a specific user. it can.

  Multiple deployments of eMBMS can improve the performance and usability of multiple core MBMS user service functions. MBMS download delivery may be an alternative service for offloading HTTP-based unicast download delivery. Multiple benefits enable support for multiple non-real-time service types, provisioning of multiple content to supplement multiple MBMS streaming services, and leverage of increased storage capacity of multiple devices (eg, multiple servers) Can include. The DASH segment format that can also be used for unicast transfer by HTTP may be unclear whether the distribution environment is unicast or multicast. The MBMS user service specification (eg, 3GPP TS 26.346 V11.3.0 (2012-12)) may allow DASH format content to be transmitted using MBMS download delivery via the FLUTE protocol.

  FLUTE can be a protocol for unidirectional delivery of multiple files over the Internet, which can be specifically for multiple multicast networks. FLUTE can create a base protocol for large-scale scalable multicast delivery based on asynchronous layered coding (ALC). FLUTE can provide instantiation of layered coded transfer (LCT) building blocks. The ALC protocol can combine the LCT building block, the congestion control (CC) building block, and the forward error correction (FEC) building block to provide congestion-controlled reliable asynchronous delivery. LCT can provide transfer level support for reliable content delivery and stream delivery protocols. Streaming data or downloads are encapsulated in real time transfer protocol (RTP) and can be transferred using the FLUTE protocol when delivered by multiple MBMS bearers. RTP can be utilized in communications and entertainment systems, including streaming media, such as telephony, video teleconferencing applications, television services, and web-based push-to-talk capabilities.

  The presence server 130 for the IMS-based DASH service may be implemented in an IMS-based packet switched streaming service (PSS) and MBMS user service functional architecture, as shown in FIG. Various functional blocks or modules can be utilized for multiple DASH services (eg, by unicast / HTTP and MBMS / FLUTE transfer methods).

  For example, the IMS core network subsystem (IM CN subsystem) 120 includes user registration and authentication, mobility and roaming, control of multiple multimedia sessions, quality of service (QoS) control, policy control, charging, and circuit exchange. Can support interworking with the network. The functions of the IM CN subsystem can be further described in 3GPP TS 23.228 V11.7.0 (2012-12).

  User equipment (UE) 110 (eg, a presentity or watcher UE) can perform service discovery and selection, can handle service initiation, modification, and termination, and / or can receive and present content to the user. Generic Boost Wrapping Architecture (GBA), IMS, PSS, and / or MBMS client.

  SCF 132 can provide service logic and functionality to support execution of service logic. For example, the SCF can provide service authentication during session initiation and session change, which can include checking service contracts of PSS and MBMS users to allow or deny access to services. The SCF can select the relevant PSS and MBMS media functions. For HTTP-based delivery, the SCF can function as a proxy or back-to-back user agent (B2BUA). For MBMS, the SCF can function as a termination user agent (UA).

  The functionality of the HTTP / SIP adapter 150 can associate a SIP session with multiple HTTP input requests. The HTTP / SIP adapter can be connected to the IM CN subsystem 120, the SCF 132, the HTTP server 160, and the presence server 130 through an interface. The HTTP server can provide DASH format content for HTTP-based delivery. The functions of the HTTP server can be further described in 3GPP TS 26.247. As described above, the presence server can receive, store, issue, and supply presence information. In the example, the presence server may have multiple interfaces that are the same as the SCF.

  BMSC. The UPF 140 may include a broadcast multicast service center (BMSC) user plane subfunction (UPF). BMSC. UPF can provide DASH format content for MBMS download. BMSC. The UPF (or BM-SC.UPF) can communicate with and / or control the content provider / multicast broadcast source. BMSC or BMSC. The functions of UPF can be further described in 3GPP TS 26.246 V11.3.0 (2012-12).

  Policy and charging rule function (PCRF) 170 can control charging and configuration of multiple resources in RAN and packet switched (PS) core network 180. The functions of the PCRF can be further described in 3GPP TS 23.203 V11.8.0 (2012-12).

  A service selection function (SSF) 190 can provide a list of available PSSs (including HTTP-based DASH) and multiple MBMS user services and associated user service description information. The SSF module can be personalized towards the identity of the client.

  Presence servers for IMS-based packet-switched streaming service (PSS) and IMS-based DASH services within the MBMS user service functional architecture can combine IMS-based presence and multiple DASH services. FIG. 4 shows a call flow for an IMS-based presence service used in the context of multiple DASH services. In this example, UE1 112 may be a watcher and UE2 114 may be a presentity. UE 1 can communicate with presence server 130 via IM CN subsystem 122, and UE 2 can communicate with presence server via IM CN subsystem 124. In the example, UE2 may be in a list of multiple contacts for UE1. UE2 can request that the user of UE2 issue content that is currently being viewed.

  UE1 112 may subscribe to presence information including a list of contacts that may include UE2 114 by sending a SIP registration message 302 to presence server 130. The presence server can provide watcher authentication 304 and can reply with a SIP 200 OK message 306.

  After a trigger event, such as after initiating DASH delivery or after a content switch with DASH, UE2 114 may decide to publish the consumed content. UE 2 can send a SIP issue message 308 to presence server 130. The issue message may include additional attributes specific to DASH, such as DASH content consumed and DASH media presentation description (MPD). The presence server can provide publisher authentication 310 and can reply with a SIP 200 OK message 312.

  Upon receipt of the SIP issue message 308 and / or after publisher authentication 310, the presence server 130 sends content consumed (or viewed or published) by UE2 114 by sending a SIP notification message 314 to UE1 112. Can be notified. If the SIP notification message is successfully received, UE1 can respond with a SIP 200 OK message 316.

  In another example, a UE acting as a presentity (eg, UE2) may send a SIP issue upon receipt of the last SIP 200 OK for an HTTP / Unicast-based or MBMS / FLUTE-based DASH session initiation procedure (eg, DASH content ( That is, start watching the movie A)). In another example, during a DASH session, a UE (eg, UE2) can also switch from a content switch (eg, one DASH content (ie, Movie A using DASH) to another DASH content (ie, Movie B using DASH). After the switch is executed, an issue request can be transmitted. Multiple trigger event messages (or multiple trigger events) that can be used to publish content or send SIP publish messages are HTTP / Unicast based DASH content switch, MBMS / FLUTE based DASH content switch, HTTP / A switch of content distribution from unicast base to MBMS / FLUTE base, or a switch of content distribution from MBMS / FLUTE base to HTTP / unicast base may be included.

  In another example, a UE acting as a presentity may receive a third SIP Partnership Project (3GPP) upon receipt of the last SIP 200OK for the PSS Streaming Session Initiation Procedure (or SIP), upon receipt of the last SIP 200OK for the MBMS Streaming Session Initiation Procedure ) File format DASH (3GP-DASH) SIP issue may be sent upon receipt of the last SIP 200OK for the session initiation procedure, or upon receipt of the last SIP 200OK for the MBMS download session initiation procedure.

  During a streaming session (including DASH format content delivery), the UE also has a PSS content switch (for both PSS streaming and 3GP-DASH services), an MBMS content switch (for both MBMS streaming and MBMS download services). Switch from PSS to MBMS streaming due to channel change (eg different DASH content), switch from MBMS to PSS streaming due to channel change, switch from 3GP-DASH to MBMS download service due to channel change, or MBMS download due to channel change After the content switch is executed, which can include a switch from 3GP-DASH service to 3GP-DASH It may send the issue request.

  Published content can be set as follows. Request-URI, To (e.g. receiver) header and From (e.g. sender) header may be set to the user's public user identity. An event header may be set in the “Presence” event package. The content type can be set to “application / pidf + xml”. The uniform resource identifier (URI) may include a URL or a uniform resource name (URN).

  Additional elements specific to multiple DASH services may also be included in the SIP issue message. For example, in the case of a live DASH service (based on HTTP / Unicast or MBMS / FLUTE), several specific additional elements are the live TV (TV) channel and / or event currently being viewed, and the live content or current Information on TV programs of In the case of on-demand services, the specific additional elements may include on-demand content. In an example, the XML schema may be used when multiple presence documents or presence information is published by the UE.

  The UE acting as a watcher (eg UE1) then receives a SIP notification message containing information of the content consumed by the UE acting as a presentity (eg UE2) which content may contain the DASH MPD file. sell.

  Another example serves as a presentity in Dynamic Adaptive Streaming (DASH) services with Internet Protocol (IP) Multimedia Subsystem (IMS) -based Hypertext Transfer Protocol (HTTP) as shown in the flowchart of FIG. A function 500 of a user equipment (UE) computer circuit operable to provide A function may be implemented as a method, or a function may be executed as multiple instructions on a machine, where the multiple instructions are at least one computer-readable medium or one non-transitory machine-readable storage. Included on the medium. The computer circuit may be configured to generate a trigger event during the DASH session, as in block 510. As in block 520, the computer circuitry can be further configured to publish presence information that includes content consumed by the presence server, where the published content includes DASH content.

  The DASH content may include DASH attributes, media presentation description (MPD) metadata files, or DASH segments. In the example, the trigger event is a 3rd generation partnership project (3GPP) file format DASH (3GP-DASH) session start procedure, a multimedia broadcast multicast service (MBMS) download session start procedure, a 3GP-DASH service by channel change, and MBMS download. A switch to a service or a switch from an MBMS download service to a 3GP-DASH service by channel change can be included. In other examples, the trigger event is a switch between HTTP or unicast based DASH content, a switch between file delivery with MBMS or one-way transport based (FLUTE based) DASH content, HTTP or unicast based A switch from content delivery to MBMS or FLUTE based content delivery, or from MBMS or FLUTE based content delivery to HTTP or unicast based content delivery.

  In other configurations, computer circuitry configured to issue presence information can be further configured to send a session initiation protocol (SIP) issue message to a presence server having DASH content. In another example, the computer circuit can be further configured to receive DASH content via a DASH service and receive an acknowledgment from a presence server that authenticates the UE to publish the DASH content. The acknowledgment may include a Session Initiation Protocol (SIP) 200 OK message. In other configurations, a computer circuit configured to issue presence information may send presence information to the presence server via Session Initiation Protocol (SIP) or Extensible Markup Language (XML) Configuration Access Protocol (XCAP). It can be further configured to transmit. Presence information may include geolocation, multiple service functions, content consumption, multiple tag lines, or multiple avatars. The UE may include an antenna, camera, touch sensitive display screen, speaker, microphone, graphics processor, application processor, internal memory, or non-volatile memory port.

  Another example is presence information by a presence server in a Dynamic Adaptive Streaming (DASH) service with Internet Protocol (IP) Multimedia Subsystem (IMS) -based Hypertext Transfer Protocol (HTTP), as shown in the flowchart of FIG. A method 600 is provided. The method may be performed as a plurality of instructions in a machine or computer circuit. The plurality of instructions are included in at least one computer readable medium or one non-transitory machine readable storage medium. The method includes an operation of receiving presence information at a presence server from a presentity user equipment (UE) after content switching, as in block 610, wherein the presence information includes DASH content. The next operation of the method may be to authenticate the presentity UE to publish DASH content, as in block 620.

  In an example, the method can further include sending an acknowledgment to the presentity UE indicating that the presentity UE has been authorized to publish DASH content. The DASH content may include DASH attributes, media presentation description (MPD) metadata files, or DASH segments. In the example, the content switch is a third generation partnership project (3GPP) file format DASH (3GP-DASH) session initiation procedure for a presentity UE, multimedia broadcast multicast service (MBMS) download for a presentity UE. It may include a session initiation procedure, a switch from 3GP-DASH service to MBMS download service by channel change by the presentity UE, or a switch from MBMS download service to 3GP-DASH service by channel change by the presentity UE. In other configurations, the content switch is a switch between HTTP or unicast based DASH content by the presentity UE, file delivery of MBMS or one-way transport based (FLUTE based) DASH content by the presentity UE. Switch between HTTP, unicast based content delivery from MBMS or FLUTE based content delivery by presentity UE, or MBMS or FLUTE based content delivery by presentity UE to HTTP or unicast based content A switch to delivery can be included.

  In other examples, the operation of receiving presence information includes receiving presence information via session initiation protocol (SIP) or extensible markup language (XML) configuration access protocol (XCAP), storing presence information. Publishing presence information or providing presence information can be further included. Presence information may include geolocation, multiple service functions, content consumption, multiple tag lines, or multiple avatars. In another configuration, the method receives a registration message from the watcher UE, authenticates the watcher UE to receive DASH content, and sends an acknowledgment to the watcher UE so that the watcher UE can receive the DASH content. Further comprising indicating that it has been authenticated to receive. In another example, the method further includes sending a notification message to the watcher UE to indicate presence information of the presentity UE or to publish presence information including DASH content to the watcher UE to the watcher UE. be able to. In another configuration, the operation of receiving presence information includes a sender header and receiver header set in the public user identity of the presentity UE, an event header set in the presence event package, and a content set in application / pidf + xml. It may further include receiving a publish message that includes a type, a live television (TV) channel or event to be watched, live content information, a current TV program, or on-demand content.

  FIG. 7 shows example user equipment (UE) 720, IMS core, EPC, PS core, and / or node 710 in RAN 780, and presence server 730 for providing presence information in an IMS-based DASH service. The UE can operate as a watcher or presentity. For example, the UE may be operable to function as a presentity in an IMS-based DASH service, as described at 500 in FIG. In other configurations, the presence server may be configured to provide presence information in an IMS-based DASH service, as described at 600 in FIG. In the example, the UE can communicate with the presence server via the node. Node 710 includes base station (BS), node B (NB), evolved node B (eNB), baseband unit (BBU), remote radio head (RRH), remote radio equipment (RRE), remote radio unit (RRU) ), Or a central processing module (CPM).

  Client device 720 may include a processor 722 and a transceiver 724. The UE may be configured to receive presence information (eg, a watcher) via the presence server 730 in an IMS-based DASH service. The transceiver may be configured to receive a notification message from the presence server indicating presence information of the presentity UE after content switching by the presentity UE. Presence information can include DASH content. The processor may be configured to examine or process DASH content from the presentity UE via the presence server. The DASH content may include DASH attributes, media presentation description (MPD) metadata files, or DASH segments. In an example, the content switch initiates a third generation partnership project (3GPP) file format DASH (3GP-DASH) session initiation procedure, initiates a multimedia broadcast multicast service (MBMS) download session initiation procedure, channel change The switch from the 3GP-DASH service to the MBMS download service may be included, or the switch from the MBMS download service to the 3GP-DASH service by channel change may be included. In another example, the content switch is a switch between HTTP or unicast-based DASH content, a switch between file delivery with MBMS or one-way transport-based (FLUTE-based) DASH content, HTTP or unicast A switch from base content delivery to MBMS or FLUTE based content delivery, or from MBMS or FLUTE based content delivery to HTTP or unicast based content delivery may be included.

  In other configurations, the UE may be configured as a presentity. The processor may be further configured to perform a content switch during the DASH session. The transceiver can be further configured to publish presence information including content consumed by the presence server. Published content may include DASH content. In other examples, the transceiver may be further configured to send presence information to the presence server via Session Initiation Protocol (SIP) or Extensible Markup Language (XML) Configuration Access Protocol (XCAP). Presence information may include geolocation, multiple service functions, content consumption, multiple tag lines, or multiple avatars.

  FIG. 8 illustrates user equipment (UE), such as a mobile terminal (MT), mobile node, client device, mobile station (MS), mobile radio device, mobile communication device, tablet, handset, or other type of wireless device. An example diagram is provided. UE is a base station (BS), evolved node B (eNB), baseband unit (BBU), remote radio head (RRH), remote radio equipment (RRE), relay station (RS), radio equipment (RE), To communicate with a node, macro node, low power node (LPN) or transmitting station, such as a remote radio unit (RRU), central processing module (CPM), or other type of wireless wide area network (WWAN) access point Can include one or more antennas. The wireless device may be configured to communicate using at least one wireless communication standard including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth®, and WiFi. A wireless device can communicate using separate antennas for each wireless communication standard or multiple antennas common to multiple wireless communication standards. Wireless devices can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and / or a WWAN.

  FIG. 8 also provides an illustration of a microphone and one or more speakers that can be utilized for audio input and output from the UE. The display screen may be a liquid crystal display (LCD) screen or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen may use capacitive, resistive, or other types of touch screen technologies. The application processor and graphics processor can be coupled to internal memory to provide processing and multiple display capabilities. The non-volatile memory port can also be used to provide the user with multiple options for data input / output. The non-volatile memory port may also be used to expand the memory capacity of the wireless device. The keyboard may be integrated into the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard may be provided using a touch screen.

  Various technologies, some aspects or options thereof may be a floppy disk, compact disk read only memory (CD-ROM), hard drive, non-transitory computer readable storage medium, or any other machine readable medium The present invention may be embodied in the form of program code (for example, a plurality of instructions) implemented on a tangible medium such as a storage medium. When program code is loaded and executed by a machine such as a computer, the machine becomes a device that implements the various techniques. The circuitry may include hardware, firmware, program code, executable code, multiple computer instructions, and / or software. The non-transitory computer readable storage medium may be a computer readable storage medium that does not include signals. When program code is executed on multiple programmable computers, the computing device includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or multiple storage elements), at least one input A device, and at least one output device. Volatile and non-volatile memory and / or multiple storage elements include random access memory (RAM), erasable programmable read only memory (EPROM), flash drive, optical drive, magnetic hard drive, solid state drive, or electronic data Other media for storage may be used. Nodes and wireless devices also include transceiver modules (ie, transceivers), counter modules (ie, counters), processing modules (ie, processors), and / or clock modules (ie, clocks) or timer modules (ie, timers). It's okay. One or more programs that may implement or utilize the various techniques described herein may use application programming interfaces (APIs), reusable controllers, and the like. Such a plurality of programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program may be implemented in assembly or machine language, if desired. In any case, the language may be a compiler-type or interpreter language and may be combined with multiple hardware implementations.

  It should be understood that many of the multiple functional units described herein are named as multiple modules to particularly emphasize their independent implementation. For example, a module is implemented as a hardware circuit that includes off-the-shelf semiconductors such as multiple custom very large scale integration (VLSI) circuits or multiple gate arrays, multiple logic chips, multiple transistors, or multiple other individual components. It's okay. A module may also be implemented in multiple programmable hardware devices such as multiple field programmable gate arrays, programmable array logic, multiple programmable logic devices, or the like.

  Multiple modules may be implemented in software for execution by various types of processors. The identified modules of executable code may include, for example, one or more physical or logical blocks of computer instructions, which may be organized as objects, procedures, or functions, for example. Nonetheless, the executables of the identified modules need not be physically located together, but when logically concatenated together, include the modules and have different locations to achieve the above objectives for the modules. May include a plurality of different instructions stored in.

  In practice, a module of executable code may be a single instruction, or many instructions, distributed across several different code segments between different programs and across several memory devices. It ’s okay. Similarly, processing data may be identified and may be in multiple modules as illustrated herein, implemented in any suitable form, and organized into any suitable type of data structure. It's okay. The processing data may be grouped as a single data set or distributed at different locations including different storage devices and may exist at least in part as merely electronic signals on the system or network. It's okay. The plurality of modules includes a plurality of agents operable to perform a plurality of desired functions, and may be passive or active.

  "For example" or "example" as referred to throughout this specification means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present invention. Thus, the appearances of the term “in the example” and the word “example” in various places throughout this specification are not necessarily all referring to the same embodiment.

  As used herein, multiple items, structural elements, composite elements, and / or materials may be presented in a common list for convenience. However, these lists should be construed so that each member of the list is individually identified as a separate unique member. Thus, individual members of such a list are interpreted as factual equivalents of any other member of the same list, based on their presentation in a common group alone, without the opposite sign. It is not something. Moreover, various embodiments and examples of the invention may be referred to herein, along with alternatives to various components. It is understood that such embodiments, examples, and alternatives are not to be construed as being substantially equivalent to one another, but are considered as separate and independent representations of the invention.

  Furthermore, the described features, structures, and characteristics may be combined in any suitable manner in one or more embodiments. As set forth below, numerous specific descriptions are provided as illustrative of multiple locations, distances, example networks, etc., in order to provide a thorough understanding of embodiments of the invention. However, those skilled in the art will recognize that the invention may be practiced without one or more specific details or in other ways, components, arrangements, and the like. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the invention.

  While the above examples illustrate the principles of the present invention in one or more specific applications, various changes in implementation, use, and details may occur without the use of inventive features, and It will be apparent to those skilled in the art that it can be implemented without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited except as by the appended claims.

Claims (22)

  One or more processors and memory to serve as a presentity for Internet Protocol (IP) Multimedia Subsystem (IMS) based packet switched streaming service (PSS) or Multimedia Broadcast Multicast Service (MBMS) An operable user equipment (UE) device comprising:
  The one or more processors are:
    In the UE, configured to initiate a content switch between IMS-based PSS session or MBMS session or IMS-based content;
    Based on the start of a content switch between the IMS-based PSS session or MBMS session or IMS-based content to publish the content consumed by the UE, a session initiation protocol (SIP) issue message is sent to the presence server at the UE. The decision to send the SIP issuance message to the presence server is based on receiving a SIP acknowledgment message for the selected session initiation procedure, wherein the selected session initiation procedure is 3rd Generation Partnership Project (3GPP) File Format (3GP)-Dynamic Adaptive Streaming (3GP-DASH) with Hypertext Transfer Protocol (HTTP) Cushion the start of proceedings, or is one of the MBMS download service start procedure,
    Configured to encode the SIP issue message at the UE for transmission to the presence server, the SIP issue message having an indication of content consumed at the UE;
    A SIP acknowledgment message received from the presence server is configured to be decoded by the UE, wherein the SIP acknowledgment message is an acknowledgment of the SIP issue message received from the UE at the presence server;
  The device of a user equipment (UE), wherein the memory is configured to store the display of content consumed by the UE.   The apparatus of claim 1, further comprising a transceiver configured to send the SIP issue message to the presence server and receive the SIP acknowledge message from the presence server.   The one or more processors are configured to determine to send the SIP issue message to the presence server after performing the content switch between content-based IMSs;
  The content switch may switch from the 3rd Generation Partnership Project (3GPP) file format (3GPP) -Dynamic Adaptive Streaming (3GP-DASH) over Hypertext Transfer Protocol (HTTP) to the MBMS download service with channel change, or The apparatus of claim 1 including one of switching from MBMS download to 3GP-DASH with channel change.   The one or more processors are:
  Encoding the SIP issue message for transmission to the presence server via an IMS core network subsystem (IM CN subsystem);
  The apparatus of claim 1, configured to decode the SIP acknowledge message received from the presence server via the IM CN subsystem.   The apparatus according to claim 1, wherein the content consumed by the UE is on-demand content currently consumed by the UE.   The apparatus of claim 1, wherein the display of the content consumed at the UE in the SIP issue message follows an Extensible Markup Language (XML) schema.   Presence server apparatus utilized for Internet Protocol (IP) Multimedia Subsystem (IMS) based packet switched streaming service (PSS) or Multimedia Broadcast Multicast Service (MBMS) comprising one or more processors and memory Because
  The one or more processors are:
    The presence server is configured to decode a session initiation protocol (SIP) registration message received from a user equipment (UE) acting as a watcher, and the SIP registration message is sent to the UE acting as the watcher as a presentity Allows to apply for presence information for a list of multiple contents including a working UE;
    A SIP issuance message received from the UE acting as the presentity is configured to be decoded by the presence server, the SIP issuance message including an indication of content consumed by the UE acting as the presentity; The SIP issue message received from the UE that operates as the presentity is decoded after a content switch between IMS-based contents is executed by the UE that operates as the presentity, and the content switch includes a hypertext transfer protocol ( 3rd Generation Partnership Project (3GPP) File Format (3GP)-Dynamic Adaptive Streaming (3GP-DASH) from HTTP A further possible to switch to the MBMS download service with, and includes the MBMS download, one that switches to a 3GP-DASH with channel change,
    A SIP notification message is configured to be encoded at the presence server for transmission to the UE acting as the watcher, wherein the SIP notification message is for content consumed by the UE acting as the presentity. Including the display,
  An apparatus of a presence server, wherein the memory is configured to store the display of content consumed by the UE acting as the presentity.   Receiving the SIP registration message from the UE acting as the watcher, receiving the SIP issue message from the UE acting as the presentity, and sending the SIP notification message for transmission to the UE acting as the watcher The apparatus of claim 7, further comprising a transceiver configured to encode.   The one or more processors may include a third generation partnership project (3GPP) file format (3GP) -dynamic adaptive streaming (3GP-DASH) session start procedure or an MBMS download service start procedure according to Hypertext Transfer Protocol (HTTP). 8. The SIP issue message received from the UE acting as the presentity after sending a SIP acknowledge message to the UE acting as the presentity for one, configured to decode the SIP issue message. apparatus.   The one or more processors are:
  Decoding the SIP registration message received from the UE acting as the watcher via an IMS core network subsystem (IM CN subsystem);
  8. The apparatus of claim 7, configured to decode the SIP issue message received from the UE acting as the presentity via the IM CN subsystem.   8. The apparatus of claim 7, wherein the one or more processors are configured to encode the SIP notification message for transmission to the UE acting as the watcher via the IM CN subsystem.   A program for providing Internet Protocol (IP) Multimedia Subsystem (IMS) based packet switched streaming service (PSS) or Multimedia Broadcast Multicast Service (MBMS) to user equipment (UE) operating as a presentity There,
  Based on the start of an IMS-based PSS session, the start of an MBMS session or the start of a content switch between IMS-based contents to issue content consumed by the UE, a Session Initiation Protocol (SIP) issue message is sent at the UE Deciding to send to the presence server,
  Encoding the SIP issue message at the UE for transmission to the presence server; and
  Decoding the SIP acknowledgment message received from the presence server at the UE;
  To the UE,
  The decision to send the SIP issue message to the presence server is based on receipt of a SIP acknowledgment message for the selected session initiation procedure;
  The selected session initiation procedure is a third generation partnership project (3GPP) file format (3GP) -dynamic adaptive streaming (3GP-DASH) session initiation procedure or an MBMS download service initiation procedure according to Hypertext Transfer Protocol (HTTP). One of the
  The SIP issue message has an indication of the content being consumed by the UE;
  The program, wherein the SIP acknowledgment message is an acknowledgment of the SIP issue message received by the presence server from the UE.   Further causing the UE to determine to send the SIP issue message to the presence server after performing the content switch;
  The content switch may switch the third generation partnership project (3GPP) file format (3GP) -dynamic adaptive streaming (3GP-DASH) with hypertext transfer protocol (HTTP) to the MBMS download service with channel change, or 13. The program of claim 12, comprising one of switching MBMS download to 3GP-DASH with channel change.   Encoding the SIP issue message for transmission to the presence server via an IMS core network subsystem (IM CN subsystem); and
  Decoding the SIP acknowledgment message received from the presence server via the IM CN subsystem;
  The program according to claim 12, further causing the UE to execute.   The program according to claim 12, wherein the content consumed by the UE is on-demand content currently consumed by the UE.   The program according to claim 12, wherein the display of the content consumed by the UE acting as the presentity in the SIP issue message follows an extensible markup language (XML) schema.   A computer-readable storage medium storing the program according to any one of claims 12 to 16.   A program for providing an Internet Protocol (IP) Multimedia Subsystem (IMS) based packet switched streaming service (PSS) or Multimedia Broadcast Multicast Service (MBMS) from a presence server,
  Decoding a session initiation protocol (SIP) registration message received from a user equipment (UE) acting as a watcher;
  Decoding a SIP issue message received from the UE acting as a presentity; and
  Encoding a SIP notification message for transmission to the UE acting as the watcher;
  To the presence server,
  The SIP registration message allows the UE acting as the watcher to apply for presence information for a list of multiple contents including the UE acting as a presentity;
  The SIP issue message includes a display of content consumed by the UE acting as the presentity;
  The SIP issue message received from the UE acting as the presentity is decoded after a content switch between IMS-based content is performed at the UE acting as the presentity,
  The content switch may switch the third generation partnership project (3GPP) file format (3GP) -dynamic adaptive streaming (3GP-DASH) with hypertext transfer protocol (HTTP) to the MBMS download service with channel change, or , Including one of switching MBMS download to 3GP-DASH with channel change,
  The SIP notification message includes the display of content consumed by the UE operating as the presentity.   Causing the presence server to further decode the SIP issue message received from the UE acting as the presentity after a content switch is performed at the UE acting as a presentity;
  The content switch may switch the third generation partnership project (3GPP) file format (3GP) -dynamic adaptive streaming (3GP-DASH) with hypertext transfer protocol (HTTP) to the MBMS download service with channel change, or 19. The program of claim 18, comprising one of switching MBMS download to 3GP-DASH with channel change.   Decoding the SIP registration message received from the UE acting as the watcher via an IMS core network subsystem (IM CN subsystem); and
  Decoding the SIP issue message received from the UE acting as the presentity via the IM CN subsystem;
  The program according to claim 18, further causing the presence server to execute.   The program according to claim 18, further causing the presence server to encode the SIP notification message for transmission to the UE acting as the watcher via the IM CN subsystem.   A computer-readable storage medium storing the program according to any one of claims 18 to 21.

Images